Re: Adaptation of Federico La Roccas ISDB-T blocks for DVB-T
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 () 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
Re: Adaptation of Federico La Roccas ISDB-T blocks for DVB-T
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 () 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 valgr
Re: Adaptation of Federico La Roccas ISDB-T blocks for DVB-T
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 () 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 exec
Re: Adaptation of Federico La Roccas ISDB-T blocks for DVB-T
Hi Vasil, thanks for the information. I am using Linux Mint 20.2 Uma and GNU Radio 3.8.3.1. I don't know yet how to install the debug symbols but perhaps this is not necessary. As I have found out, the downstream blocks expect tags that I don't send and that is the reason why my flowgraph fails (see Federicos post earlier today, he gave me a hint). I have already added one missing tag and there is no more -11 :-) Kind regards, Ralf Am 10.12.2021 um 17:59 schrieb Vasil Velichkov: Hi Ralf, Thread 27 "dvbt_symbol_inn" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffc5ffb700 (LWP 1924)] 0x7fffe61a2e0d in ?? () from /lib/x86_64-linux-gnu/libgnuradio-dtv.so.3.8.3 (gdb) bt #0 0x7fffe61a2e0d in () at /lib/x86_64-linux-gnu/libgnuradio-dtv.so.3.8.3 #1 0x70f40d13 in gr::block_executor::run_one_iteration() () at /lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.8.3 #2 0x70f95eaa in gr::tpb_thread_body::tpb_thread_body(boost::shared_ptr, boost::shared_ptr, int) () at /lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.8.3 #3 0x70f84928 in () at /lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.8.3 It seems you are using Debian/Ubuntu (or some derivative) and you are missing the debug info symbols for libgnuradio-runtime.so and libgnuradio-dtv.so libraries. I'm not a Debian/Ubuntu user and I'm not very familiar how to install the missing symbols. Read the following pages, install the debug symbols and then repeat the same procedure and you will get some more meaningful information like .cpp/.h file names and line numbers. https://wiki.ubuntu.com/Debug%20Symbol%20Packages https://wiki.ubuntu.com/DebuggingProgramCrash https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols Also tell us which Linux distribution do you use and which version? How did you install gnuradio and the exact version? Regards, Vasil On 10/12/2021 14.51, Ralf Gorholt wrote: 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
Re: Adaptation of Federico La Roccas ISDB-T blocks for DVB-T
Hi Ralf, > Thread 27 "dvbt_symbol_inn" received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x7fffc5ffb700 (LWP 1924)] > 0x7fffe61a2e0d in ?? () from > /lib/x86_64-linux-gnu/libgnuradio-dtv.so.3.8.3 > (gdb) bt > #0 0x7fffe61a2e0d in () at > /lib/x86_64-linux-gnu/libgnuradio-dtv.so.3.8.3 > #1 0x70f40d13 in gr::block_executor::run_one_iteration() () at > /lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.8.3 > #2 0x70f95eaa in > gr::tpb_thread_body::tpb_thread_body(boost::shared_ptr, > boost::shared_ptr, int) () at > /lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.8.3 > #3 0x70f84928 in () at > /lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.8.3 It seems you are using Debian/Ubuntu (or some derivative) and you are missing the debug info symbols for libgnuradio-runtime.so and libgnuradio-dtv.so libraries. I'm not a Debian/Ubuntu user and I'm not very familiar how to install the missing symbols. Read the following pages, install the debug symbols and then repeat the same procedure and you will get some more meaningful information like .cpp/.h file names and line numbers. https://wiki.ubuntu.com/Debug%20Symbol%20Packages https://wiki.ubuntu.com/DebuggingProgramCrash https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols Also tell us which Linux distribution do you use and which version? How did you install gnuradio and the exact version? Regards, Vasil On 10/12/2021 14.51, Ralf Gorholt wrote: > 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
Re: Adaptation of Federico La Roccas ISDB-T blocks for DVB-T
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 () 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
Re: Adaptation of Federico La Roccas ISDB-T blocks for DVB-T
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 () 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 >
Re: Adaptation of Federico La Roccas ISDB-T blocks for DVB-T
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
