[TangerineSDR] Updated Functional Specification for Local Host

[Engelke, Bill]

Rob - sorry about not replying to this earlier, busy week.  A couple of thoughts about the timekeeping...

- There will be some systems where the DE does not have a GPSDO attached. The LH will need to send the DE something, be it a Unix time, or counter, or what-have-you for the DE to use to put the time stamps into the data packet. That was the only reason for the idea of being able to send it a time. But you have a point that the DE could simply start counting up from zero, as long as the LH has a quite accurate time (which I understand could be achieved using NTP).

- Regarding how Digital RF records time: my understanding of this is still quite imperfect, but I don't think the LH has to convert the DE time stamp - I think it stores it as is, names the files accordingly, and when running in compression level zero (what we plan to use) requires only a single time stamp at the beginning of the run. By knowing the sample rate you can accurately infer the time of any sample. In working with the Digital RF examples, I just pass digital_rf_create_write_hdf5 a global_start_index (which is based on a Unix time), and it takes care of everything else.

As always, further comments & discussions are most welcome....   tnx - 73- Bill


-----Original Message-----
From: TangerineSDR <tangerinesdr-bounces at lists.tapr.org> On Behalf Of Rob Wiesler via TangerineSDR
Sent: Saturday, November 9, 2019 5:41 PM
To: TAPR TangerineSDR Modular Software Defined Radio <tangerinesdr at lists.tapr.org>
Cc: Rob Wiesler <robert.wiesler at case.edu>
Subject: Re: [TangerineSDR] Updated Functional Specification for Local Host

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.

--
TangerineSDR mailing list
TangerineSDR at lists.tapr.org
http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org