[TangerineSDR] Updated Functional Specification for Local Host

[Rob Wiesler]

On Sat, Nov 09, 2019 at 16:12:28 +0000, Engelke, Bill via TangerineSDR wrote:
> Rob - I understand completely - what I should do is send them out both ways - with & without markup. I will start doing that.
> 
> For now, here is a pdf with the markup.  - thanks for your help & 73 - Bill

Thanks, Bill.

I notice in the Requirements Traceability Matrix (under Timestamping)
that the LH is listed as having the capability to send the current
system time to the DE.

My understanding (from Ryan Volz's email from Thu, 24 Oct 2019 13:48:35
-0400) is that the data obtained from the DE will *not* include a true
timestamp, but rather an integer relative to a time known by the LH.
Samples collected by the DE will be stamped with this integer, and the
LH will convert them to a true timestamp.

For convenience, this is what Ryan wrote:

| [...] I think the best approach is to use an integer sample tick or
| clock tick count in the data packet as the timestamp since it
| simplifies the interface between the SBC and DE. The SBC is going to
| know the tick rate, so all that's needed during initialization is to
| synchronize the tick count at a known time. The SBC can know what time
| it is, either with reasonable accuracy through NTP or good accuracy
| through a GPS clock. The DE can get a PPS signal, but otherwise it
| doesn't independently know anything about the time. So you have a
| method on the DE that gets called by the SBC that says "set the tick
| count to X at the next PPS". Then the DE just increments the tick
| count from that point and sends along the current value in the data
| packet. When the SBC gets the data packet, it can calculate the time
| corresponding to that tick from knowing the tick rate and the time at
| which the tick count was set to a known value.

| Now on the call we talked about initializing the tick count to match
| the Digital RF sample index (Unix time in seconds * sample rate), but
| perhaps that discussion was more confusing than it needed to be by
| linking the separate concepts of data packet timestamp and stored
| time.  Such a convention would be convenient since the SBC could just
| use the data packet timestamp directly as the Digital RF sample index
| when writing the data, but from my description above I hope it's clear
| that it's not necessary. In this scheme, the SBC can initialize the
| tick count (k0) on the DE to anything it wants as long as it keeps
| track of that value. It could always be 0, for instance. Then when it
| gets a packet with a tick count of k1, it knows the time as ( (k1 -
| k0) / tick_rate ) + (time_when_k0_was_set). All that matters is the
| difference between k0 and k1 and that the SBC knows the tick rate and
| the time at which it sets k0.

Under this scheme, it is pointless (and even counterproductive) for the
DE to know what time it is (except in that the LH needs to query the
GPSDO to determine the time, which may involve the DE).

Other than that, everything looks good to me.