[TangerineSDR] PSWS Time Stamping Concept: maybe we should use the 128-bit time

[Dan White]

A potential use case for the time stamps is to create a phased array from
independent receivers.  Think combining the recorded IQ from two (really
nice!) SatNOGS ground stations.  We already have discussions about
timestamping the waterfalls to improve orbit determination and sat
identification.

A 128b timestamp per packet is only 0.1% more overhead, so the disadvantage
is slight.

Plus, especially if the timestamp directly follows the sequence number, the
data stays aligned on 64-bit boundaries:

seqN(32), sync(32), time(128), ...

Doesn't affect the FPGA side much, but aligned data may make it easier for
a 64-bit CPU to deal with the stream efficiently.

>From the peanut gallery,
Dan White AD0CQ




On Mon, Oct 21, 2019, 2:57 PM Engelke, Bill via TangerineSDR <
tangerinesdr at lists.tapr.org> wrote:

> Tom – thanks for bringing this up, I definitely should have included it.
> Referring to https://tools.ietf.org/html/rfc5905#section-6 .
>
>
>
> After thinking about this, I’m wondering:   *should we consider using the
> full 128-bit NTP date format* (instead of the NTP Short format of 64
> bits), with the idea that we then *don’t have to cope with the year 2036
> rollover*?  The Era value will take care of it.  Since our time stamps
> don’t occur all that often, it doesn’t seem to me like a big cost.  Our
> experience has been that these software projects take on a life of their
> own and last much longer than anyone ever expects; thinking of it in that
> way, 2037 is right around the corner.
>
>
>
> Would anyone else like to weigh in on this matter?
>
>
>
> 73- Bill, AB4EJ
>
>
>
>
>
>
>
> *From:* TangerineSDR <tangerinesdr-bounces at lists.tapr.org> *On Behalf Of *Tom
> McDermott via TangerineSDR
> *Sent:* Friday, October 18, 2019 4:29 PM
> *To:* TAPR TangerineSDR Modular Software Defined Radio <
> tangerinesdr at lists.tapr.org>
> *Cc:* Tom McDermott <tom.n5eg at gmail.com>
> *Subject:* Re: [TangerineSDR] PSWS Time Stamping Concept
>
>
>
> HI Bill - thanks for documenting this.   The format of the 64-bit time
> stamp
>
> should be referenced.  My recommendation is NTP format.  We cannot use all
> of
>
> the precision that affords, and thus may want to consider setting the LSBs
> to zero below
>
> some accuracy limit.
>
>
>
> The format is documented in: IETF RFC 5905 Section 6, "NTP Timestamp
> format", figure 3.
>
> page 13.
>
>         https://tools.ietf.org/html/rfc5905
>
> There are standard library tools to manipulate it.  Whilst UNIX time will
> rollover in 2037,
>
> my view is that standard methods, procedures, and standard code will
> emerge to consistently handle it.
>
> If we adopt a proprietary format, then custom code would otherwise need to
> be crafted.
>
>
>
> The fractional portion of one second is encoded as a 32-bit integer. The
> LSB represents 0.233 nanoseconds.
>
> We could consider setting the 5 LSBs to zero for the 50 nanosecond-ish
> accuracy.  Then use those LSBs
>
> later if some GPS receiver in the future had better accuracy.
>
>
>
> -- Tom, N5EG
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Fri, Oct 18, 2019 at 1:09 PM Scotty Cowling via TangerineSDR <
> tangerinesdr at lists.tapr.org> wrote:
>
> Hi Bill,
>
> Just to be clear, if the number of channels does not divide evenly into
> 1024, then a packet might not start with channel 0 I/Q samples.
>
> Is there a requirement that the time stamp immediately precede channel 0
> I/Q data? For example, a packet could look like this:
>
> CH0_I(0), CH0_Q(0), CH1_I(0), CH1_Q(0), CH2_I(0), CH2_Q(0), CH0_I(1),
> CH0_Q(1), CH1_1(1), CH1_Q(1), CH2_I(1), CH2_Q(1), CH0_I(2)...
> ...CH2_I(339), CH2_Q(339), CH0_I(340), CH0_Q(340)
>
> So you would start the next packet like this:
> CH1_I(340), CH1_Q(340), CH2_I(340), CH2_Q(340), CH0_I(341), CH0_Q(341)...
>
> If I put the time stamp at the beginning:
> <sync><time stamp>CH1_I(340), CH1_Q(340), CH2_I(340), CH2_Q(340),
> CH0_I(341), CH0_Q(341)...
>
> Then the time stamp would apply to the first and second I/Q pairs (CH1 and
> CH2) as well as to the last I/Q pair of the previous packet (CH0).
>
> If I always put the time stamp before CH0, then the time stamp would apply
> to the last I/Q pair of one packet and also to the first two I/Q pairs of
> the next packet.
>
> So are the time stamps always before CH0, or can they be anywhere?  I
> think for proper synchronization, they will have to be before CH0 only.
>
> Also, while it is clear that time stamps are sent periodically, that
> period is not specified anywhere. I think we need to specify that, don't
> we? Maximum count between timestamps? Maximum number of packets?
>
> Did you want to expand on the two commands (or methods) used by the SBC to
> set the two times (GPSDO and "best effort")?  We talked about an "arm"
> command that causes the time to be set on the next 1 PPS transition and an
> "immediate" command that sets the time immediately upon reception of the
> command.
>
> 73,
> Scotty WA2DFI
>
> On 2019-10-17 17:37, Engelke, Bill via TangerineSDR wrote:
>
> To all:
>
> Attached is our proposed concept for Time Stamping for PSWS data – for
> your review and comment.
>
> Note that this is primarily for the case where raw I/Q data is being
> stored in Digital RF format.
>
> Data recording will be a bit different in the low-bandwidth case where the
> I/Q data is to be processed by GNURadio running on the SBC, and FFT
> (waterfall) results are uploaded to the database.
>
>
>
> Dave: please post to TangerineSDR.com
>
>
>
> TNX ES 73 - W. D. Engelke (Bill), AB4EJ
>
> Center for Advanced Public Safety
>
> Cyber Hall
>
> The University of Alabama
>
> Tuscaloosa, AL 35487
>
> Desk: (205) 348-7244
>
> Mobile: (205) 764-3099
>
>
>
>
>
>
>
> --
> TangerineSDR mailing list
> TangerineSDR at lists.tapr.org
> http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org
>
> --
> TangerineSDR mailing list
> TangerineSDR at lists.tapr.org
> http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/tangerinesdr_lists.tapr.org/attachments/20191021/0c017c04/attachment-0001.html>