Hi Ralf, Good news!
Regarding your question, In order to be sure that what the block was measuring was right, I've used a complete software transceiver together with a Channel Model block. You may take a look at https://github.com/git-artes/gr-isdbt/blob/master/examples/full_transceiver.grc. This example is easily reproduced in DVB-T by combining the TX and RX example flowgraphs. best Federico El lun, 13 dic 2021 a las 8:02, Ralf Gorholt (<ralf.gorh...@gmx.de>) escribió: > 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 > > 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 >> > > > >
