Hello Federico,
after a lot of thinking I have finally managed to adapt your OFDM
Synchronization and TMCC Decoder blocks for DVB-T :-) The problem
was that the frame and symbol indexes in the tags sent by the TPS
decoder were not correct.
Although I can see the video now, I am not sure that I have really
done everything right, because I have still some problems of
understanding. Perhaps you can bring some light into the dark?
I have connected GUI number sinks to the freq. error and samp. error
outputs of the OFDM Synchronization block to display the values and
I have noticed the following:
1) With interpolation in the OFDM Synchronization block turned on,
when I adjust the frequency of the source block (frequency
correction ppm) so that the freq. error output value is near to
zero, this value drifts very slowly in one direction, from higher to
lower values, crossing zero (i.e. from positive to negative values).
2) The value at the samp. error output is zero and constant (at
least I have seen no change during about 30 minutes).
Is this the correct behaviour? If not, how should it be?
Thank you very much for your help and kind regards,
Ralf
Am 11.12.2021 um 16:11 schrieb Ralf
Gorholt:
Hello Federico,
I have a lot of difficulties to generate the output and the tags
for the blocks that follow my TPS Decoder in the flowgraph. That's
why I had the idea to take a different approach.
The OFDM Synchronization block outputs the payload carriers (1705
in 2K mode) whereas the Demod Reference Symbols block that
normally follows the FFT expects 2048 carriers. My question sounds
certainly silly but would it be possible to fill in the missing
carriers with zero carriers (amplitude and phase == 0) to get 2048
carriers again and thus be able to use the original DVB-T blocks?
As far as I know, in DVB-T the carriers at the borders are all set
to zero (and perhaps the one in the middle too). Perhaps this
would be too simple to be true :-)
Regards,
Ralf
Am 10.12.2021 um 14:41 schrieb Ralf
Gorholt:
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
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