Hi!
I’ve faced a challenge - synchronize two independent boards distributed in space.
Assume both PCs have clocks synced to 50us. I need to achieve 200us synchronization. USRP, AFAIK, has two methods for such case: set_time_now and set_start_time. After setting current time sample time of each sample can be extracted easily.
Does LimeSDR have something like that?
You can use one as the external clock if the other. Just connect the clock-out of one to the other’s clock-in and configure it as an a external clock input.
They are 50m away from each other, so this may be the problem.
You are synchronizing them for communication with each other or for receiving an external signal?
Receiving the same signal from multiple locations.
Do you control that signal or it’s 3rd party?
No, I have no control over that signal.
That’s more complicated. I can’t really help you with that, sorry.
Thank you anyway! The easiest way to do this, as I think, is to sample at a given time on both boards. But the question is does LimeSDR support hardware timestamping with absolute timestamps and if not, how hard it would be to implement it.
Are you using both TX/RX channels? Because one option would be to use the second TX/RX set to send a sync back and forth between the two transceivers.
Sounds like TODA task 
you can recognize the pattern of received signal from both…
This is not an option, unfortunately - receivers may hear desired signal but not each other. Also, I’m not allowed to talk in this part of the spectrum.
I’ve been poking around in the FPGA recently. It would not be a big deal to change the timestamp clock from being reset by the start of the RX stream (as at present) to an external input. Then your only problem would be to sync that external signal to 50 uS - which even a cheap GPS receiver PPS can manage.
Next time I have the source open I’ll see if any of the FPGA pins are available on connectors. I recall there being a GPIO spigot, but don’t know offhand if that’s connected to the NIOS (CPU on the FPGA) or to the LMS7002.
Thanks for sharing this! Would wait for your reply and will go to see the source code too.
This would be a great addition, especially if a GPIO output bit from one SDR could feed the ‘reset’ input GPIO bit on itself and on other SDRs.
There is a GPIO header which is connected to the FPGA and pins can be toggled/read via the API.
Awesome - that means one can be re-purposed as an external sync input.
I would offer to do this myself, but I’m in the middle of several other tasks just now. In a couple of weeks I’ll be back inside the FPGA (I think I’m going to need to make extensive changes for one of my applications). If you haven’t taken care of this by the end of the month, reach back out and I should be able to do something.
I have some related issues: I’m planning to have multiple boards that I would like timestamps synchronized on, but I’d also like to be able to have GPIO outputs change so they are predictably timed with the RF. I’m a complete FPGA novice - so my look through the FGPA source hasn’t helped much on even trying to evaluate how achievable this might be. But it looks to me as though the GPIO setting and the TX/RX streaming take very different paths through the FPGA.
Is there a way to set GPIO outputs at specific timestamps?
Did you just offered to add 1 PPS sync feature (that would work e.g. with GPS or rubid generators)? That would be really awesome, this is actually the only really important thing that LimeSDR is missing for now! 
I’m not an expert, but if it would be possible to route 1 PPS signal directly from external SMA connector to that GPIO input, it would be even better, then our rear panel will look just like in USRP (10 MHz + 1 PPS)
Thinking about this, I can do the hardware reset, but that’s the least of what needs to happen.
Just having the receive timestamp go to zero on a PPS doesn’t mean the high level software can tell what sample the PPS occurred on. The software only gets the timestamp once per readStream - you wouldn’t know the clock was zeroed until you noticed the next buffer’s timestamp wasn’t what you expected.
You could work it backward and figure out what sample the PPS occurred on, but that would be a pain. Also, I don’t know what error checking occurs in the driver - will it spot a suddenly changed timestamp? Will it care?
I’m willing, but a real PPS sync capability is going to take some thought.
For now, here’s a kludge that would probably work: run the PPS (yes, the pulse) into the second receive channel. Try through a 20 or 30 dB attenuator at first.
You will see something in the receiver on the rising edge of the PPS - how much, and at what frequency, depends on the risetime of the pulse. That will let you correlate PPS to sample number, which should do for the originally stated application.
In the meantime, should we perhaps start a PPS hack thread?