Re: DMR tier III trunking base station transceiver using GNU Radio as lower physical layer
One other important limitation I found and I forgot to mention. At the start of the execution of the flowgraph, there is a phenomenon which I interpret like this: before all downstream buffers are filled, there is no constraint on the speed of execution of the work() function in the source block, probably due to lack of back-pressure? So this resulted in lots of timeslot samples created in a very short amount of time (microseconds?) that push the initial latency to 10 seconds or more. So I've constrained the execution of the work() function at the startup which adds those 30 msec which are not caused by the flowgraph. Unfortunately I could not figure out how to lift that limitation once back-pressure takes effect (all downstream buffers are full). I hope that makes sense. Adrian
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
Re: DMR tier III trunking base station transceiver using GNU Radio as lower physical layer
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? Best, Marcus On 17.04.24 17:50, Adrian Musceac wrote: Hello, I would like to share with you the following page containing details of a project to create a DMR tier III trunked radio base transceiver station (usable for amateur radio digital voice comms and experimentation) in software defined radio: http://qradiolink.org/DMR-tier-3-trunked-radio-BTS-software-defined-radio.html It involves GNU Radio since the lower physical layer, concerned with frequency modulation and demodulation, filtering, resampling, as well as frequency division and time division multiplexing are performed in GNU Radio C++ flowgraphs and also using some custom blocks created for this purpose. I hope you find this interesting and on-topic for this list, and thanks for all the help received in the community discussion channels. Since it is likely the page and code may contain mistakes, I would welcome any corrections or additions. Best regards, Adrian YO8RZZ