On Friday, 19 April 2024 14:43:44 EEST Marcus Müller wrote: > Hi Adrian, > > that's definitely quite cool! Thanks for sharing it with us :) > > I gave it a quick skim, and it's a bit surprising how much latency you get; > this might have to do with GNU Radio's buffer sizes. The growing latency on > UHD does in fact worry me, but I think it would indeed need more > investigation (the good news is that there's no space for the USRP to store > that much signal for it to have that much latency on the hardware side, so > this must be something on the host). > > Out of interest: how long are these timeslots? >
Hi Marcus, Thank you for your interest in this. I'm sure some improvements can be made to the latency, based on previous experience with TDMA type transmissions. One DMR timeslot is 30 msec long, including the start and end guard times. That is quite a lot, certainly longer than TETRA or GSM. It should translate to 7200 samples per timeslot at my final sample rate (240 ksps). The latency figures I quoted (350 - 500 msec) are end-to-end, so this includes two rounds of passing through ZeroMQ buffers (which for MMDVM algorithm reasons need to be one full timeslot worth of samples), pseudo-TTY communication both ways, and two IP hops (not necessary on the same LAN host). I think the most meaningful figures here are experimentally determined burst delays required in the PMT timestamps, which cover only the flowgraph + the rest of the stack including USB transmission. I found the USRP to generally require less added delay, 40 msec worked, but not 100% reliable. The LimeSDR required 60 msec or more, with 100% reliability achieved for both at 80 msec delay. The LimeSDR stays at 0 % FIFO fill rate all the time, I'm not sure how to determine that number for gr-uhd. Out of these numbers, 30 msec are not related to actual delay, it is a requirement atm. in the source block to gather all timeslot samples and fill with zeros the carriers which are not used. So that leaves around 50 msec of actual latency for both types of devices. I was hoping based on experiences with GSM (Osmocom and gr-gsm) to see a delay of less than 5 to 10 msec per transmitted burst. I'm still trying to determine what causes this delay, I even tried setting some custom buffer sizes, unfortunately due to some legacy support required on my machines all the tests were done with GNU Radio 3.8 so far, so I may be missing some later optimizations. Best, Adrian
