<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Bill,<br>
<br>
128-bit format should be no problem. Do you know what format VITA-49
uses?<br>
<br>
I don't like rollovers either. And I use lots more memory than 1MB.<br>
<br>
73,<br>
Scotty WA2DFI<br>
<br>
<div class="moz-cite-prefix">On 2019-10-21 12:56, Engelke, Bill via
TangerineSDR wrote:<br>
</div>
<blockquote type="cite"
cite="mid:1fcb82a159484fbaa83a9d92ec30927e@ua.edu">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle19
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal">Tom – thanks for bringing this up, I
definitely should have included it. Referring to
<a href="https://tools.ietf.org/html/rfc5905#section-6"
moz-do-not-send="true">https://tools.ietf.org/html/rfc5905#section-6</a>
.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">After thinking about this, I’m wondering:
<b>should we consider using the full 128-bit NTP date format</b>
(instead of the NTP Short format of 64 bits), with the idea
that we then
<b>don’t have to cope with the year 2036 rollover</b>? 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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Would anyone else like to weigh in on this
matter?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">73- Bill, AB4EJ<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b>From:</b> TangerineSDR
<a class="moz-txt-link-rfc2396E" href="mailto:tangerinesdr-bounces@lists.tapr.org"><tangerinesdr-bounces@lists.tapr.org></a>
<b>On Behalf Of </b>Tom McDermott via TangerineSDR<br>
<b>Sent:</b> Friday, October 18, 2019 4:29 PM<br>
<b>To:</b> TAPR TangerineSDR Modular Software Defined Radio
<a class="moz-txt-link-rfc2396E" href="mailto:tangerinesdr@lists.tapr.org"><tangerinesdr@lists.tapr.org></a><br>
<b>Cc:</b> Tom McDermott <a class="moz-txt-link-rfc2396E" href="mailto:tom.n5eg@gmail.com"><tom.n5eg@gmail.com></a><br>
<b>Subject:</b> Re: [TangerineSDR] PSWS Time Stamping Concept<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<p class="MsoNormal">HI Bill - thanks for documenting
this. The format of the 64-bit time stamp <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">should be referenced. My
recommendation is NTP format. We cannot use all of<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">the precision that affords, and thus
may want to consider setting the LSBs to zero below<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">some accuracy limit.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The format is documented in: IETF RFC
5905 Section 6, "NTP Timestamp format", figure 3.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">page 13.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <a
href="https://tools.ietf.org/html/rfc5905"
moz-do-not-send="true">https://tools.ietf.org/html/rfc5905</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">There are standard library tools to
manipulate it. Whilst UNIX time will rollover in 2037,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">my view is that standard methods,
procedures, and standard code will emerge to
consistently handle it.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">If we adopt a proprietary format,
then custom code would otherwise need to be crafted.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The fractional portion of one second
is encoded as a 32-bit integer. The LSB represents 0.233
nanoseconds.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">We could consider setting the 5 LSBs
to zero for the 50 nanosecond-ish accuracy. Then use
those LSBs<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">later if some GPS receiver in the
future had better accuracy.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">-- Tom, N5EG<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Fri, Oct 18, 2019 at 1:09 PM Scotty
Cowling via TangerineSDR <<a
href="mailto:tangerinesdr@lists.tapr.org"
moz-do-not-send="true">tangerinesdr@lists.tapr.org</a>>
wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC
1.0pt;padding:0in 0in 0in
6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">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<o:p></o:p></p>
<div>
<p class="MsoNormal">On 2019-10-17 17:37, Engelke, Bill
via TangerineSDR wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">To
all:
<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Attached
is our proposed concept for Time Stamping for PSWS
data – for your review and comment.<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Note
that this is primarily for the case where raw I/Q
data is being stored in Digital RF format.
<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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.<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Dave:
please post to TangerineSDR.com<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">TNX
ES 73 - W. D. Engelke (Bill), AB4EJ<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Center
for Advanced Public Safety<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Cyber
Hall<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">The
University of Alabama<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Tuscaloosa,
AL 35487<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Desk:
(205) 348-7244<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Mobile:
(205) 764-3099<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</blockquote>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">-- <br>
TangerineSDR mailing list<br>
<a href="mailto:TangerineSDR@lists.tapr.org"
target="_blank" moz-do-not-send="true">TangerineSDR@lists.tapr.org</a><br>
<a
href="http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org"
target="_blank" moz-do-not-send="true">http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org</a><o:p></o:p></p>
</blockquote>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
</blockquote>
<br>
</body>
</html>