[TangerineSDR] PSWS Time Stamping Concept

[Scotty Cowling]

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
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/tangerinesdr_lists.tapr.org/attachments/20191018/20a9a62d/attachment.html>