<div dir="ltr"><div dir="ltr"><div>HI Bill - thanks for documenting this. The format of the 64-bit time stamp </div><div>should be referenced. My recommendation is NTP format. We cannot use all of</div><div>the precision that affords, and thus may want to consider setting the LSBs to zero below</div><div>some accuracy limit.</div><div><br></div><div>The format is documented in: IETF RFC 5905 Section 6, "NTP Timestamp format", figure 3.</div><div>page 13.</div><div> <a href="https://tools.ietf.org/html/rfc5905">https://tools.ietf.org/html/rfc5905</a></div><div>There are standard library tools to manipulate it. Whilst UNIX time will rollover in 2037,</div><div>my view is that standard methods, procedures, and standard code will emerge to consistently handle it.</div><div>If we adopt a proprietary format, then custom code would otherwise need to be crafted.</div><div><br></div><div>The fractional portion of one second is encoded as a 32-bit integer. The LSB represents 0.233 nanoseconds.</div><div>We could consider setting the 5 LSBs to zero for the 50 nanosecond-ish accuracy. Then use those LSBs</div><div>later if some GPS receiver in the future had better accuracy.</div><div><br></div><div>-- Tom, N5EG</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div></div><br><div class="gmail_quote"><div class="gmail_attr" dir="ltr">On Fri, Oct 18, 2019 at 1:09 PM Scotty Cowling via TangerineSDR <<a href="mailto:tangerinesdr@lists.tapr.org">tangerinesdr@lists.tapr.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
<div bgcolor="#FFFFFF">
Hi Bill,<br>
<br>
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.<br>
<br>
Is there a requirement that the time stamp immediately precede
channel 0 I/Q data? For example, a packet could look like this:<br>
<br>
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)... <br>
...CH2_I(339), CH2_Q(339), CH0_I(340), CH0_Q(340)<br>
<br>
So you would start the next packet like this:<br>
CH1_I(340), CH1_Q(340), CH2_I(340), CH2_Q(340), CH0_I(341),
CH0_Q(341)...<br>
<br>
If I put the time stamp at the beginning:<br>
<sync><time stamp>CH1_I(340), CH1_Q(340), CH2_I(340),
CH2_Q(340), CH0_I(341), CH0_Q(341)...<br>
<br>
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).<br>
<br>
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.<br>
<br>
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.<br>
<br>
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?<br>
<br>
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.<br>
<br>
73,<br>
Scotty WA2DFI<br>
<br>
<div>On 2019-10-17 17:37, Engelke, Bill via
TangerineSDR wrote:<br>
</div>
<blockquote type="cite">
<div>
<p class="MsoNormal">To all: <u></u><u></u></p>
<p class="MsoNormal">Attached is our proposed concept for Time
Stamping for PSWS data – for your review and comment.<u></u><u></u></p>
<p class="MsoNormal">Note that this is primarily for the case
where raw I/Q data is being stored in Digital RF format.
<u></u><u></u></p>
<p class="MsoNormal">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.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Dave: please post to TangerineSDR.com<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">TNX ES 73 - W. D. Engelke (Bill), AB4EJ<u></u><u></u></p>
<p class="MsoNormal">Center for Advanced Public Safety<u></u><u></u></p>
<p class="MsoNormal">Cyber Hall<u></u><u></u></p>
<p class="MsoNormal">The University of Alabama<u></u><u></u></p>
<p class="MsoNormal">Tuscaloosa, AL 35487<u></u><u></u></p>
<p class="MsoNormal">Desk: (205) 348-7244<u></u><u></u></p>
<p class="MsoNormal">Mobile: (205) 764-3099<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<br>
<fieldset></fieldset>
</blockquote>
<br>
</div>
-- <br>
TangerineSDR mailing list<br>
<a href="mailto:TangerineSDR@lists.tapr.org" target="_blank">TangerineSDR@lists.tapr.org</a><br>
<a href="http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org" target="_blank" rel="noreferrer">http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org</a><br>
</blockquote></div>