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

[walter]

Hi Matt,

++props for Ron's example of PMT tagging in C++  :-)

Quick tip: as a person with strong/current Python skills and C++ expertise 
that's 20 years out-of-date, I've found that I can get "best results per unit 
time" by reading the C++ code/docs but coding my blocks and snippets in 
efficiently-written Python.  

I've found that well-written Python doesn't introduce bottlenecks, and I can 
apply the time saved to high-level organization of flowgraphs that optimizes 
throughput and latency. 

Getting acceptable performance in Python requires being comfortable with 
loop-free vector coding in numpy, as well as judicious use of itertools, 
functools, and other "straight-to-C" mechanisms.
A nice feature to be aware of is that GR sidesteps the Python GIL at a high 
level.  This provides a level of efficiency unavailable in ordinary Python 
environments.  

Hope this helps.

- W

Matt wrote:

> > Thank you Ron! This does look like exactly what I need.  ...
(and earlier)
>> > 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.

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

--
> On Apr 19, 2024, at 08:13, Matt Clemons  wrote:
> 
> Thank you Ron!
> ...
> Matt
> 
> On Thu, Apr 18, 2024 at 6:33 PM Ron Economos  > wrote:
>> Matt,
>> 
>> Take a look at ...
>> https://github.com/drmpeg/gr-dvbs2
>> 
>> It implements exactly what you're talking about to achieve VCM (Variable 
>> Coding and Modulation).
>> ...

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

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

[Matt Clemons]

Thank you Ron! This does look like exactly what I need. I almost reached
out to you directly, seeing all the DrMpeg commits related to gnuradio DTV
blocks.

Thanks for your help and all the contributions you've made to the community.

Matt

On Thu, Apr 18, 2024 at 6:33 PM Ron Economos  wrote:

> 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

[Ron Economos]

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

[Federico 'Larroca' La Rocca]

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 ()
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!
>