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
>
>
>

Announcing the 2024 European GNU Radio Days at FAIR, Darmstadt, Germany

The 2024 edition of the European GNU Radio Days will be held at the
international accelerator facility FAIR in Darmstadt, Germany's
'City of Science', from August 27 to 31, 2024:
https://events.gnuradio.org/event/23

The conference aims at fostering collaboration between users and
developers of the free and open-source GNU Radio framework by helping
scientific, academic, industrial and hobbyist alike to discuss the
latest developments.

Focus of the Conference:

This edition is centered on the release of GNU Radio 4.0, with
tutorials designed to train newcomers on the advancements of this
framework reboot. We invite contributions on various topics, including:
* Digital Communication
* Satellite communication and space vehicle attitude analysis
* RADAR and Base-Band Signal Processing
* Hardware Enhancements, RF Frontend, and Backend accelerators (i.e.
SIMD, GPU, etc.) Advanced Signal Processing and Control
* Synchronization of distributed coherent SDR frameworks

Special Features of the Workshop:

The workshop will offer both plenary talks and introductory tutorials,
and two parallel tracks highlighting hands-on sessions specifically
tailored for GNU Radio users and C++ developers. To ensure personalized
guidance and effective learning, tutorials will be conducted in small
groups (4-8 participants). Due to this format, space is limited --
register early to secure your spot!

Registration and Contributions:

Early registration is encouraged as spaces are limited. The
registration deadline is July 15, 2024. Submit your contribution
proposals directly through the conference website at
https://events.gnuradio.org/event/23/abstracts/#submit-abstract
using the https://www.gnuradio.org/grcon.tar.gz template.
Submissions must be made by June 14, 2024.

For detailed calls for contributions and more information, visit:
https://events.gnuradio.org/event/23

The registration fee is set at 100 euros, covering the conference
reception and supporting GNU Radio's Educational Fund. Student
discounts and fee waivers are available for individuals who otherwise
would not be able to attend. Please contact us at info@gnuradio.org to
request a discount on your attendance. Proceedings will be published on
https://pubs.gnuradio.org/.

We look forward to welcoming you to Darmstadt for an engaging and
productive week at the European GNU Radio Days 2024.

Your European GNU Radio Days Organising Committee

Re: Passing Tags or Additional Port Data to Change Parameters of Downstream Blocks

Matt,

Take a look at my DVB-S2 OOT. This is a different version of the DVB-S2
transmitter that implements VCM (as opposed to the regular CCM version
included in GNU Radio).

https://github.com/drmpeg/gr-dvbs2

It implements exactly what you're talking about to achieve VCM (Variable
Coding and Modulation). In VCM, the coding and modulation parameters can
change on a frame by frame basis. To accomplish this, the parameters are
sent as stream tags.

To get you started, here's where the stream tag is first created. It bit
packs a 64-bit PMT with all the parameters.

https://github.com/drmpeg/gr-dvbs2/blob/master/lib/bbheader_bb_impl.cc#L496

Then it's sent downstream and all the subsequent blocks use it for
configuration (and also pass it downstream to the next block).

Ron

On 4/18/24 09:39, Matt Clemons wrote:
> Hello,
>
> I've been using the dtv/dvbt blocks in GnuRadio Companion to decode
> dvbt signal recordings. I noticed a lot of the blocks in the RX chain
> require the user to select the modulation parameters (Constellation,
> Hierarchy, Code Rate, etc.). My goal is to remove a lot of these user
> parameters with the use of Transmission Parameter Signals (TPS) data
> called out in the DVB-T spec. This would make the DVBT receiver more
> autonomous, and be better than brute forcing all the modulation
> settings until you get a recovered transport stream in the cases where
> you don't know the transmitter settings. This solution seems to be a
> worthwhile improvement to the current DVBT blocks by utilizing the TPS
> data called out in the spec. Implementing this in the c++ code is
> where I'm running into issues and where I'm looking for help/advice.
>
> In the DVB-T spec the Transmission Parameter Signals (TPS) data can be
> recovered which will tell you all the modulation parameters of the
> main signal. As long as you know the TX mode and Guard Time, you can
> configure the OFDM Symbol Acquisition block and the FFT block, which
> are the only 2 required blocks before the Demod Reference Signals
> (DRS) block. The DRS code already decodes the TPS data but is only
> looking at 2 of the total 68 bits to determine what the frame index
> is, and then clears the std::deque of TPS data.
>
> My goal is to use all of the TPS data and either pass it in a tag or
> pass through a new port so that all the remaining downstream blocks
> can get the modulation parameters from that data rather than a user.
> I've dug into the tags and the PMT types required to pass data, but I
> can't wrap my head around how I would configure the modulation
> parameters of the downstream blocks from the port or tag TPS data
> passed to it.
>
> For example, a lot of the DRS modulation parameters are not needed for
> the DRS block to work, and when you recover Constellation Type,
> Hierarchy Type, and Tx Mode you could then pass these parameters to
> the DVB-T Demap block instead of having to create the block with those
> parameters.
>
> If there are any examples of other blocks using tags or ports to
> change the functionality of another block, that would be useful. Since
> I am fairly new to GnuRadio and C++ these modifications seem difficult
> to me, hoping someone with more experience in both could point me in
> the right direction.
>
> thanks!

Re: Passing Tags or Additional Port Data to Change Parameters of Downstream Blocks

Hi, 

That's a great idea! You may take a look at several blocks that are already in GNU Radio and are configurable through messages. Signal Source comes to my mind. More "sophisticated" blocks also use messages for configuration. For instance, UHD USRP Source, or some blocks of our OOT module gr-tempest (e.g. fine sampling synchronization). 

You should take a look at those, but it should be as "simple" as adding a setter method on the block for the parameter you want to change, and call it from the function that "listens" to messages. 

Hope that helps.

best

Federico

El jue, 18 abr 2024 a las 13:40, Matt Clemons (<mattclems11@gmail.com>) escribió:

Hello,

I've been using the dtv/dvbt blocks in GnuRadio Companion to decode dvbt signal recordings. I noticed a lot of the blocks in the RX chain require the user to select the modulation parameters (Constellation, Hierarchy, Code Rate, etc.). My goal is to remove a lot of these user parameters with the use of Transmission Parameter Signals (TPS) data called out in the DVB-T spec. This would make the DVBT receiver more autonomous, and be better than brute forcing all the modulation settings until you get a recovered transport stream in the cases where you don't know the transmitter settings. This solution seems to be a worthwhile improvement to the current DVBT blocks by utilizing the TPS data called out in the spec. Implementing this in the c++ code is where I'm running into issues and where I'm looking for help/advice.

In the DVB-T spec the Transmission Parameter Signals (TPS) data can be recovered which will tell you all the modulation parameters of the main signal. As long as you know the TX mode and Guard Time, you can configure the OFDM Symbol Acquisition block and the FFT block, which are the only 2 required blocks before the Demod Reference Signals (DRS) block. The DRS code already decodes the TPS data but is only looking at 2 of the total 68 bits to determine what the frame index is, and then clears the std::deque of TPS data.

My goal is to use all of the TPS data and either pass it in a tag or pass through a new port so that all the remaining downstream blocks can get the modulation parameters from that data rather than a user. I've dug into the tags and the PMT types required to pass data, but I can't wrap my head around how I would configure the modulation parameters of the downstream blocks from the port or tag TPS data passed to it.

For example, a lot of the DRS modulation parameters are not needed for the DRS block to work, and when you recover Constellation Type, Hierarchy Type, and Tx Mode you could then pass these parameters to the DVB-T Demap block instead of having to create the block with those parameters.

If there are any examples of other blocks using tags or ports to change the functionality of another block, that would be useful. Since I am fairly new to GnuRadio and C++ these modifications seem difficult to me, hoping someone with more experience in both could point me in the right direction.

thanks!

Passing Tags or Additional Port Data to Change Parameters of Downstream Blocks

Hello,

I've been using the dtv/dvbt blocks in GnuRadio Companion to decode dvbt signal recordings. I noticed a lot of the blocks in the RX chain require the user to select the modulation parameters (Constellation, Hierarchy, Code Rate, etc.). My goal is to remove a lot of these user parameters with the use of Transmission Parameter Signals (TPS) data called out in the DVB-T spec. This would make the DVBT receiver more autonomous, and be better than brute forcing all the modulation settings until you get a recovered transport stream in the cases where you don't know the transmitter settings. This solution seems to be a worthwhile improvement to the current DVBT blocks by utilizing the TPS data called out in the spec. Implementing this in the c++ code is where I'm running into issues and where I'm looking for help/advice.

In the DVB-T spec the Transmission Parameter Signals (TPS) data can be recovered which will tell you all the modulation parameters of the main signal. As long as you know the TX mode and Guard Time, you can configure the OFDM Symbol Acquisition block and the FFT block, which are the only 2 required blocks before the Demod Reference Signals (DRS) block. The DRS code already decodes the TPS data but is only looking at 2 of the total 68 bits to determine what the frame index is, and then clears the std::deque of TPS data.

My goal is to use all of the TPS data and either pass it in a tag or pass through a new port so that all the remaining downstream blocks can get the modulation parameters from that data rather than a user. I've dug into the tags and the PMT types required to pass data, but I can't wrap my head around how I would configure the modulation parameters of the downstream blocks from the port or tag TPS data passed to it.

For example, a lot of the DRS modulation parameters are not needed for the DRS block to work, and when you recover Constellation Type, Hierarchy Type, and Tx Mode you could then pass these parameters to the DVB-T Demap block instead of having to create the block with those parameters.

If there are any examples of other blocks using tags or ports to change the functionality of another block, that would be useful. Since I am fairly new to GnuRadio and C++ these modifications seem difficult to me, hoping someone with more experience in both could point me in the right direction.

thanks!