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

[Engelke, Bill]

Rob - OK, I have a handle on what to do for system updating. I will take out references to doing any of this using Central Control.



Now here is an implementation question for you:



- I'd like your recommendation on precisely how to handle the communication between the LH and the DE. The plan is to use sockets, but I need some more detail on that.



  1.  Let's say we use TCP. We need an approach that handles making connections, dealing with lost connections, ensuring communications get thru & recover from errors, thread safety, etc. I have seen packages such as Zeromq<https://zeromq.org/> and things like it, but those would require that the DE use an exactly compatible method (implemented in FPGA, I guess) - probably not possible, maybe not even desirable. What would you recommend?
  2.  Scotty has said he want to use UDP as much as possible. To me, this makes sense for sending acquired data, but for commands, I don't know.  Would UDP work for everything?  If so, do you know of something we can use that is an open source package, or do we need to write everything from scratch? Don't want to re-invent, etc.  Any thoughts?

-73- Bill



-----Original Message-----
From: Rob Wiesler <halcyone1024 at gmail.com> On Behalf Of Rob Wiesler
Sent: Monday, November 18, 2019 3:25 PM
To: Engelke, Bill <bill.engelke at ua.edu>
Cc: TAPR TangerineSDR Modular Software Defined Radio <tangerinesdr at lists.tapr.org>
Subject: Re: [TangerineSDR] Updated Detailed Design Specification for PSWS Local Host (v0.1)



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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/tangerinesdr_lists.tapr.org/attachments/20191120/c0dee844/attachment.html>