MeasureDelay.py and Limesdr

[ashtum]

Hi , Traceback (most recent call last): File "MeasureDelay.py", line 186, in <module> if __name__ == '__main__': main() File "MeasureDelay.py", line 183, in main dumpDir=options.dumpDir, File "MeasureDelay.py", line 145, in measure_delay raise Exception('correlation(%d) does not match argmax(%d), probably bad data'%(rxCoorIndex, rxArgmaxIndex)) Exception: correlation(1035) does not match argmax(6902), probably bad data

[guruofquality]

Can you replicate this setup?

python MeasureDelay.py --rate=10e6 --freq=1e9 --rxGain=20 --txGain=20 --rxAnt=LNAL --txAnt=BAND1

In the above example I just put some rubber duck antennas on channel A LNAL and BAND1 ports. Also make sure to use the latest stable/master branch as there were some recent fixes.

[ashtum]

Thanks for your quick reply . It's works , can Time delta be a negative number ?

Cleanup streams Time delta -1245.100000 us Done!

[guruofquality]

Hmm, probably junk data. Correlation should get a strong tone and it should give 8 us with those settings. Should be repeatable, but I can double check on recent master branch when I get home.

[ashtum]

I made a mistake , i connected antenna to LNAW . After connecting it to LNAL it works . Cleanup streams Time delta 7.799000 us Done! I want to measure the round trip delay due to tx and rx buffers in lime sdr board and driver . Do you have any suggestions? because , i made a tcp/ip modem by gnuradio blocks and some python code , it is working without problem with two lime sdr board and two laptops , but the problem is delay , round trip delay is near 2000ms when i use 3 Msample/s tx and rx , it is even worse when i use lower sample rates .

[guruofquality]

Not knowing very much about your specific test, it sounds like you have fully filled the limesdr fifos and the gnuradio buffers with samples. So you are measuring the time it takes to drain the internal fifos and not the latency. So thats why it takes longer when you lower the sample rate.

Transmissions should be bursty, or paced in someway from rx timestamps, samples, or events. What I see a lot is that some application dumps a continuous flow of samples into a tx modulator, and then when a message comes from the user, the flow graph modulates that message, but it pushes that important message into essentially a very long queue of junk samples which take priority.

So not sure what you are doing, just a guess, but I have seen that a lot, and its usually a source of problems for this type of application.

[ashtum]

Yes , exactly it's not a bursty transceiver . i use continuous transmitter and receiver because it's very simple for receiver to stay lock to carrier , i use dummy frames when there are no data for transmission , but i know this is not the source of delay (it add latency just 10 to 20 ms) . I want be sure the problem is from limesdr driver and FPGA big buffers and then try to find a way for reducing them .

[guruofquality]

You can modify the source in LimeSuite to lower the fifo size here: https://github.com/myriadrf/LimeSuite/blob/master/SoapyLMS7/Streaming.cpp#L123 I havent experimented with config.bufferLength very much, but if you set it to some smaller value, like a few packets worth.

In general, continuous transmission is fine, but you should maintain a window of samples in the queue. So you can initially push out N samples, and then wait for rx samples before pushing out more tx samples. Ideally they are both continuous and at the same rate, so it should work. This is how osmotrx works for example.

[ashtum]

Thank you very much , I set config.bufferLength to 1024 64 and round trip delay reduced from 1800ms to around 400ms . lower value of config.bufferLength than 1024 64 doesn't affect latency , at least at this sample rate (3msps) .

[guruofquality]

lower value of config.bufferLength than 1024 * 64 doesn't affect latency

1) I suspect that the gnuradio buffers dominate at this point which is why decreasing the hardware bufferers doesnt help any more.

2) While there are stream arguments for altering this fifo size, I suspect gr-osmosdr does not present stream arguments in the source/sink blocks, so I think we can also add to SoapyLMS device arguments which provide default fifo sizes. Its a hack, but it could be useful so you dont need to recompile LimeSuite. -- I will leave this open until I add this feature.

3) Carefully about calling this latency. I mean, from some perspective it kind of is. But latency is generally measured with empty fifos, but I'm not an expert on what this is called. The best I could find is this definition from here. So its kind of like you are measuring reverse latency, but in the forward direction.

The delay from the input to the output in an empty FIFO is defined as the forward latency and the delay from the output to the input in a full FIFO is defined as the reverse latency.

[guruofquality]

I added the following device arguments to LimeSDR: https://github.com/myriadrf/LimeSuite/commit/4f1122e416e97af92c61676aac5aeffcda01ea0b

You should be able to add "driver=lime,txBufferLength=65536, etc etc" to the osmosdr source/sink blocks to get the same effect. Let me know how that goes. Ty!