@KarlL I think this message may just be a result of the streamer thread that manages the fifo looking for some samples but not finding any, which makes sense because we send them very infrequently. This message only appears frequently during program execution if the
flushPartialPacket flag is set to false.
@cmichal Thanks for the tips, I have added in the snippet to use only one PLL, however as expected nothing changed. May I ask why the timestamp must always be even?
With regards to the LimeSuite version, based off the git commit messages it looks like there have been lots of bug fixes for the Lime-Mini since January this year which makes me reluctant to revert back as it may introduce some errors elsewhere.
I have however made some progress. I flashed the original gateware back and made a short program to do the following:
- Setup streams and receive a few buffers to allow everything to stabilize
- Read a buffer of samples and record the timestamp
- Send a buffer of samples with a timestamp 256 * 1360 samples in the future
- Record the next 300 buffers and plot the output
The code can be found here:
An example output is:
Devices found: 1 0: LimeSDR Mini, media=USB 3.0, module=FT601, addr=24607:1027, serial=1D3AC940C7E517
Reference clock 40.00 MHz
RX Center frequency: 868 MHz
TX Center frequency: 868 MHz
Selected RX path 3: LNAW
Selected TX path 2: BAND2
Host interface sample rate: 30.72 MHz
RF ADC sample rate: 122.88MHz
RX LPF configured
RX LPF bandwitdh: 10 MHz
TX LPF configured
TX LPF bandwitdh: 10 MHz
Normalized RX Gain: 0.739726
RX Gain: 54 dB
Normalized TX Gain: 0.394737
TX Gain: 30 dB
Rx calibration finished
Tx calibration finished
RX Event at 199920
TX Scheduled for 548080
Delta = 348160
Final RX stamp: 606560
RX dropped: 0
TX dropped: 0
The output graph is:
tx_buffer is 1360 samples long. Here the burst lasts from sample 348260 to 349620 which gives a length of 1360 as required. I ran this program a few times, and in each case the TX event looked to start at 348260, which is 100 samples (or 3.26us) after the scheduled start of 348160. I wonder where this latency comes from, and if it can be predicted.
As before this only works if
flushPartialPacket is set to true, even if I make the stream FIFO and
tx_buffer the same size. I think I may have to look into the source to see what happens here.
Im also confused about the strange DC offset that has appeared in the output.
Anyway, I’ll keep trying at it and see what happens. I have a suspicion that it may not be wise to shedule a TX event at some point when the most current HW timestamp has the MSB set, so I may move that a few packets into the future.