GPS PPS sync ?

[pjalocha]

Is there a chance a timestamp sync to the PPS from a GPS would be possible ?

[meexmachina]

hi @pjalocha, accepting a PPS signal (digital signal) and a TOD data from somewhere and maintaining a synced wall time? if this is the case so, yes. Through the PMOD connector with 8 digital signals, one of them may be a 1PPS signal input that synchronizes the system time while the TOD may be coming from the raspberry pi or from the PMOD as well. Some Verilog needs to be written though. not a biggy. David

[pjalocha]

I could imagine it this way:

1. There is a sample counter which just keeps counting the RF samples at the current sampling rate.
2. When the front edge of the PPS arrives it stores the sample counter which corresponds to this sample at this very moment
3. the sample counter and the stored counter value at the PPS is passed to the API on the RPI together with the sample data

The rest would be done with the software, thus it would take the system time, the samples counter and the counter value at the PPS and assign proper timestamp to the samples.

A related feature in demand: feeding an external 26MHz or other from a GPS, which is then possibly in sync with the PPS for precise timestamping, can be very useful for ADS-B/Mode-S MLAT receivers.

[meexmachina]

Yes it sounds like something that will work. Anyway, as part of the I/Q samples (which are 13 bits each) leave one reserved bit for the flow control and 2 other reserved bits (each value transaction is 16 bit and a complete I/Q is 32 bits). so the value to a signal input from a PMOD (say pmod[1:0]) may be embedded within the RX information. and then indeed the API can have all the information it needs. In general - it is probably possible and your proposal sounds great.

David

[pjalocha]

Yes, you could signal the PPS in the higher bits, but the specific counter is better, I think, as it requires less processing. Otherwise you need to pass each sample through a mask and a search for the PPS state which adds extensive processing because it needs to be done per every sample. Better to have clean signed integer samples.

[meexmachina]

so you say, offloading the cpu as much as possible. sounds right. ok @pjalocha i think thats a good idea. i will push it into our backlog of tasks.... i really like the comments here and the ideas. thanks a lot, i appreciate.

[mpbraendli]

Really cool. Also for transmitting at specific absolute timestamps:

Assuming you have separate control and data planes, you could issue the instruction "start TX streaming at time T" over the control plane, and the FPGA back-pressures streaming until the internal counter reaches this time.

From the application side, if SoapySDR is used, the idea would be

1. maybe call setClockSource and setTimeSource
2. call setHardwareTime with a what value that instructs the device to wait for the PPS rising-edge and then latch the specified counter value
3. call activateStream containing a timestamp that specifies the time of the first sample
4. start streaming, and let the device back-pressure until counter reaches timestamp value

writeStream also has a timeNs argument, but I'm not sure if it is needed.

That way you can get clock-accurate time of transmission, if your refclock and PPS signals are coming from the same clock domain.

If the timestamp cannot be respected (e.g. it is in the past), there should be an error condition.

I'd be happy to help you out on this feature. I'll try to install the FPGA build chain first :-)

See: https://pothosware.github.io/SoapySDR/doxygen/latest/classSoapySDR_1_1Device.html

[meexmachina]

Ok @mpbraendli - thanks for the help! Which RPI do you use? In RPI4 I installed the Icestorm toolchain for Ice40. I use Yosys for synthesis, NextPNR (not Arachne-PNR) for place and route. Follow the instructions in icestorm installation guide from sources. In RPI4 it takes around 20-30 minutes to compile everything with make -j8. Then building the "bin" files from Verilog is just using make in the firmware directory. The IceStorm open-source toolchain is really a great and handy fast tool. Synthesis + Place and route in RPI4 of the current code takes around 10 seconds - much faster than Lattice officiel IceCube toolchain, and the result is more compact!! its fantastic!

As for synchronizing the TX - see AT86RF215 DS. In the "4.5 Serial I/Q Data Interface" chapter (pg. 22) there is an interface description and they also detail a method to "flow-control" TX samples directly over the I/Q packets through a designated bit in the 32-bit sample. it is done by modifying I_data[0] LSB - see "4.5.4 Word Format" sub-chapter. The PPS synchronization as described by @pjalocha can be applied to Tx by also setting a synced slot-clock within the FPGA and syncing the TX bit (data[0]) to the starting point of the next slot.

It requires some neat design to make it work robustly, I appreciate your willingness to help. I'm not closing this issue as it has a lot to do with it.

[mpbraendli]

I installed the toolchain on my laptop and built top.bin

% md5sum top.bin
d8db02114dbde1a97a7ec615966a8fc6  top.bin

I have a RPi4 available for experiments here.

I might have some time to dig into the firmware in July, but I guess I won't be able to do much without hardware. I'll wait for availability through CrowdSupply.

[shaneshort]

I came here to make a similar request, as it's super helpful for Multilateration when doing ADS-B decoding. A stable GPS backed timestamp added to the incoming messages makes the entire process work much much better. I'm not super technical with the electronics required, but can someone confirm if using the above suggestions it'll be possible?

[meexmachina]

Thanks @shaneshort for the comment. It is possible to embed PPS information within the samples typically - on each pps rise edge, a "1" will be embedded in the reserved areas of the streamed I/Q packages to the RPI. So getting an tightly coupling of ADS-B decoding + GNSS signal synchronization is doable in software.

I'll get to it once I finalize other issues in the software / firmware.

Thanks, David