Hi Federico,
indeed, the "symbol_index" tag that is normally sent for each OFDM
symbol is missing. This might cause an unexpected situation for the
following deinterleaver block, "Access not within mapped region"
according to valgrind.
I will see how I can generate the symbol index for each symbol. The
"Demod Reference Signals" block uses the dvbt_pilot_gen object to parse
the input data and to generate symbol and frame indices.
As far as I have understood, in your block OFDM Synchronization you have
combined the symbol acquisition and the FFT. Then you connect a TMCC
decoder that eliminates the TMCC and auxiliary carriers, generates tags
and outputs the data carriers. My idea was to do the same for the TPS
signals in DVB-T.
To my surprise, in principle what I have done seems to work. If not, my
TPS decoder would not be able to correctly decode the TPS information
that changes accordingly when I change settings in the transmitter, for
instance the modulation scheme.
I will focus on the tags and see what is missing.
Regards,
Ralf
Am 10.12.2021 um 14:25 schrieb Federico 'Larroca' La Rocca:
Hi,
I'd be more than happy to help. A couple of things that come into my
mind.
The OFDM Synchronization block is a combination of our "old" OFDM
Symbol acquisition (for a while now it's been part of GNU Radio) and
Sync and Channel estimation blocks (which performed equalization and
integer frequency correction) . The most important difference is that
OFDM Synchronization includes a loop with the estimated channel gains,
which in turn is used to estimate the sampling error (plus fine
frequency errors). It also indicates some events downstream via tags,
just like the older blocks. This new "DVB-T OFDM Synchronization"
block should then be a combination, if I'm not mistaken, of OFDM
Symbol Acquisition plus Demod Reference Signals (I'm sure Ron will
know more on this).
Anyhow, my point is that you should take a look at the OFDM Symbol
Acquisition and Demod Reference Signals blocks in GNU Radio, and check
which tags are used and when. Maybe this lack of tags is generating an
unforeseen situation on the downstream blocks which generate the
segfault? Furthermore, if I'm not mistaken, the pilots in DVB-T (in
particular continuous pilots) are not exactly the same as in ISDB-T.
Another possibility is that the Demod Reference Signals block is not
equivalent to our Sync and Channel estimation block, and further
processing is needed for it to be ready for the DVB-T Demap...
best
Federico
El vie, 10 dic 2021 a las 9:55, Ralf Gorholt (<ralf.gorh...@gmx.de>)
escribió:
Hi Vasil,
thank you for your message. As I have no experience with GNU Radio and
command line debugging, your hints may be really helpful. I have
attached the gdb and valgrind output to this email.
In the gdb output thread 27 that receives the SIGSEGV is the DVB-T
"Symbol Inner Interleaver" that comes with GNU Radio, not one of
my blocks.
As far as valgrind is concerned, it tells me for my block OFDM
Synchronization: "Conditional jump or move depends on uninitialised
value(s)". I will see if I can find out which variable is
uninitialized
and how I can get rid of this problem.
Kind regards,
Ralf
Am 10.12.2021 um 12:35 schrieb Vasil Velichkov:
> Hi Ralf,
>
> On 10/12/2021 11.52, Ralf Gorholt wrote:
>> Unfortunately, when I deactivate the original flowgraph, it does no
>> longer work and I get a -11 return code.
> The "-11" value means that you got a segmentation fault and the
process was kill with signal 11 (SIGSEGV)
>
>
https://docs.python.org/3.8/library/subprocess.html#subprocess.CalledProcessError.returncode
> https://www.man7.org/linux/man-pages/man7/signal.7.html
>
> In my opinion the easiest way to debug segfaults is to run the
flowgraph under gdb and valgrind. Open your flowgraph in the
gnuradio-companion and then Generate (F5) but do not Execute (F6).
The open a terminal, go where the flowgraph python (.py) file was
generated and execute
>
> gdb -ex run --args /usr/bin/python3 test.py
>
> and then when it stops execute `bt` command in the gdb's shell
and provide the full output. To run it under valgrind execute
>
> valgrind --tool=memcheck /usr/bin/python3 test.py
>
> Adjust the path to your python interpreter and its version if
needed.
>
> Regards,
> Vasil
