[TangerineSDR] Updated Detailed Design Specification for PSWS Local Host (v0.1)

[Rob Wiesler]

On Mon, Nov 18, 2019 at 16:38:17 +0000, Engelke, Bill wrote:
> - I had been figuring we would have a distributable image with
>   everything we need included in it. People could build their system
>   by downloading this and putting on eMMC/SDchip, or buy a pre-made
>   one from TAPR. You mentioned  that we should have a version of this
>   for desktop that is exactly the same as for the Odroid; seems fine,
>   but don't we have at least the difference that the Odroid is ARM and
>   the desktop would be x86/x64? Is everything we need going to work
>   the same on both architectures?

It shouldn't be an issue.  In particular, if there's an issue, then
there's a bug in our code.

> - On the FT8 decoder, I just picked the initial approach based on how
>   it is done in the Red Pitaya (Pavel Demin's "Notebook" code).  If we
>   have plenty of RAM, RAMdisk is fine. The FT8 files are about 2 MB
>   each, so decoding 8 bands would take 16 MB which is not that much
>   for the Odroid. BTW, I have the FT8 decoder source (mix of C and
>   Fortran), and it could probably be enhanced to use pipe or socket or
>   other more state-of-the-art method, but I would make that a lower
>   priority for Phase 1, since we do have a working solution.

Right.  Just so long as we're not messing the the lifetime of the SD
card or eMMC.

> - On Gmail, I have tried on several occasions to push outgoing mail to
>   it (and to AT&T also) , trying various methods with good SMTP
>   credentials, but have never been successful; always ended up using
>   SMTP2GO. If you can provide detailed guidance on how to actually
>   make that work, it would be great.

In Python:

	from smtplib import SMTP
	from email.mime.text import MIMEText

	SMTP_USERNAME = 'example at gmail.com'
	SMTP_PASSWORD = 'example password'
	SMTP_SERVER   = 'smtp.gmail.com:587'

	def email(subject, message, to_addrs, from_addr=None):
		if not from_addr:
			from_addr = SMTP_USERNAME
		msg = MIMEText(message)
		msg['Subject'] = subject
		msg['From']    = from_addr
		msg['To']      = ', '.join(to_addrs)
		s = SMTP(SMTP_SERVER)
		s.ehlo()
		s.starttls()
		s.login(SMTP_USERNAME, SMTP_PASSWORD)
		s.sendmail(from_addr, to_addrs, msg.as_string())
		s.quit()

	# Example:
	#
	# email( "Example of sending SMTP from Python via Gmail"
	#      , "This is line 1\n"
	#      + "This is line 2\n"
	#      , ('recipient at example.com',)
	#      )

I cribbed this from an old debug file I wrote for my company years ago.
There's absolutely nothing novel about it, so it's in the public domain.
It could be made significantly more sophisticated, but I never needed
to.

> - On frequency of clock updating, I based that merely on the
>   guidelines for setting up a system to update clock with Dimension 4;
>   updating clock every 15 or 30 minutes is quite sufficient for FT8 or
>   WSPR. We can have it update as often as deemed necessary.

I suspect we might be in violent agreement, but again, modern system
clocks governed by NTP only "update" the clock a maximum of once, if the
clock is significantly wrong when the system boots.  That's called
"stepping" the clock.  After that, NTP uses some external time source (a
GPS with a PPS output, a terrestrial atomic clock, or a pool of
Internet-connected hosts also running NTP) and a boatload of statistics
to track the minute differences in frequency between the system clock
and the external time source (which is presumed to be more
authoritative).  The system clock's frequency is adjusted very slightly
over time to match (and continue to match) the external time source as
closely as possible, except that the frequency is increased slightly if
the system clock is behind the true time, and decreased slightly if it
is ahead.  This is called "slewing" the clock.

> - Regarding "- You mention in the "Remote System Updates" section,
>   "Need to select a package for enabling this."  What do you mean by
>   that?"  --- Not knowing any better I had assumed that there would be
>   more than one way to distribute and apply system updates from the
>   Central Control system; this just refers to deciding how to apply
>   these.  I gather that you have a good handle on best practice here,
>   and can recommend how to do it.

It's basically just apt-get and friends.  The Central Control system
probably won't even have anything to do.  Rather, we'll update packages
in the repo, and each system will periodically check for and install
updates.