I have 2 LimeSDR Minis (v 2.4) that are connected to the same clock. I am running them simultaneously and am not surprised that their output is not synchronized in time. What does puzzle me is the following: there is a time offset between the two that is constant over multiple loops of LMS_SendStream - this is what is sending out the TX stream and even though the offset between the transmit streams (from the two different SDRs) varies from one initialization to the next (brought on by restarting the program).
In other words, I start the program and all of the stream set commands occur, then I start looping through the LMS_SendStream commands and observe a constant time offset between the SDRs that only changes if I stop the program and restart it. For that reason I can synchronize them by offsetting the TX timestamp of one relative to the other, but the actual time offset still varies from one initialization to the next, making the synchronization impossible. I want to make it clear I am not actually thinking I can synchronize them this way, but am trying to understand how they work.
I guess what I donât understand is why the time offset doesnât vary for each loop? I have tried restructuring the code I am running by giving the LMS_SendStream commands so they are given in a separate order, etc, however the relative offset of one particular SDR relative to the other remains (i.e. one SDR is always timed before the other, and the offset time is on the order of 4 msec).
Maybe I have described this poorly, but if anyone can explain to me why I see this (or give me any ideas), please let me know.
Thank you - I will take a look at this. For clarity, I am talking about 2 completely separate devices (separate usb connections) and not 2 channels on the same device.
You have both SDRs running off the same clock, so the samples counting will be synchronized on both boards, and assuming youâre sending the Tx packets with a designated timestamp when they should be transmitted, then there will be a constant offset in time between the boards, as they are running at the same rate, from the same clock source.
The time offset between the boards is the result of host system and USB data transmission latency. Each board hardware activates itâs own stream and starts counting samples once their FPGA register 0x000A[0] is set to 1.
So the time offset your seeing is the time difference between that register change in both boards.
Such huge time difference is a flaw of the legacy LimeSuite API, the LMS_StartStream() function is creating threads for data processing, which is a relatively expensive operation, thus it takes milliseconds. Therefore once the first board is started and already running, the second board start takes couple of milliseconds to create itâs threads and only then it activates. After that point due to shared clock the boards sampling rates are synchronized in time, but have different start points in time.
The new GitHub - myriadrf/LimeSuiteNG API creates threads preemptively, so the Start() operation is minimal, essentially just a write opration to that register. That would reduce the time offset significantly (to micro seconds), but the boards would still not be trully started at the same time.
The boards are independent from each other and the USB is a serial bus shared among all other connected devices, so there is no guaranteed way to send a time point synchronized command to both boards from the PC without having some latency.
The only way to trully synchronize both boards would have to involve something at the hardware level, like one board signaling the stream start to the other through GPIO or something like that.
Thank you very much for this explanation - it makes a lot of sense. I do realize that a hardware signal is needed ideally to synchronize the two boards, but I had not looked into LimeSuiteNG previously - I will do that now.
How would one go about trying to implement the GPIO trigger? I am trying to set up a similar system using GNU radio. New to SDRs but tryingg to my best to learn. Should I try to use limesuitNG instead of gnuradio if I am using limesdrs?
Okay, so after some initial tests, I am realizing that I have some issues with my setup that would go away if I could implement this HW trigger. Unfortunately I have done 1 course in Verilog 10 years ago⌠Would you dare make an estimate on how complex it would be to try and implement something like this? It sounds kind of easy but thatâs just me thinking about what would be needed, in order to do it in embedded c.
One update here before I forget: I did write up some LimeSuiteNG code and indeed the start streaming commands take much less time: on the order of 600 usec rather than close to 4.5 msec (MacBook M4 Pro). The variation in the time taken is also much less: on the order of 40 usec rather than 100âs of usec previously. So this is indeed a huge improvement - it gets the boards closer without hardware synchronization (and is even close enough for some applications), but doesnât get them all the way there as expected.
Hello again! I am finally about to test this, just want to double check how to revert it if I have to. Can I just flash the *_golden.bit file? I assume I just use the limeFLASH util?
