Re: DMR tier III trunking base station transceiver using GNU Radio as lower physical layer

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