DVB-T reception problems
Dear all, after a pause of two years I have started to work again on my DVB-T RX project for GNU Radio. I have tried to port Federico La Rocca's ISDB-T blocks "OFDM Synchronization" and "TMCC Decoder" to DVB-T and in principle they seem to work. When the received signal is stable, I have a stable reception, i.e. frequency and sampling rate are corrected, the constellation is stable and as far as I can see, the OFDM symbols are correctly recognized (at least it seems to me). I have added a TPS decoder that decodes the TPS pilots and delivers the data to the following blocks. The TPS decoder performs some checks to assure that the forwarded data are correct and prints error messages on the console when a problem is detected. In detail, I check the following things: - frame index sequence - symbol index sequence - superframe start However, it still happens from time to time that reception "freezes", i.e. the video pauses and does not start again automatically, despite the fact that there isn't any error message from the TPS decoder. Therefore I assume that there is still at least one error somewhere that I have not found yet. I have got two questions to the DVB-T experts: 1) How should I handle the following cases: - symbol out of sequence / lost symbols - incorrect decoded or incomplete frames In such cases, should I always wait for the next superframe or is there a possibility for a different (and faster) error recovery? 2) When OFDM reception and TPS decoding is OK, what could cause the reception "freeze"? Any idea? As far as GNU Radio and DSP is concerned, I consider myself still as a beginner, so please don't assume too much knowledge on my part :-) Thank you very much for your help! Kind regards, Ralf, DL5EU
Re: Problem migrating an OOT module that uses FFT from 3.8 to 3.9
Hello Ron, thank you very much. I have walked right into the trap a second time :-( I should attach a Post-It to my monitor screen to remind me that I might need to adapt the CMakeLists.txt files when I change something... Long story short, it works now :-) Regards, Ralf Am 29.01.2022 um 23:54 schrieb Ron Economos: Ralf, Yes, I was thinking about how I had done things in my 3.8 OOT's where I had used this syntax instead: fft::fft_complex *ofdm_fft; and ofdm_fft = new fft::fft_complex(ofdm_fft_size, false, 1); The other thing to check is the linking. Like so. https://github.com/drmpeg/gr-paint/blob/master/CMakeLists.txt#L78 and https://github.com/drmpeg/gr-paint/blob/master/lib/CMakeLists.txt#L25 Ron On 1/29/22 14:24, Ralf Gorholt wrote: Hello Ron, d_fft_calculator is (and was in the 3.8 version) an object and not a pointer. That's why I already use the . and not the -> Regards, Ralf Am 29.01.2022 um 21:35 schrieb Ron Economos: Ralf, I'm not sure if you've done this already, but when you use d_fft_calculator, you need to change from -> to . to access it. Ron On 1/29/22 12:24, Ralf Gorholt wrote: Hello all, I am currently trying to migrate an OOT module that uses an FFT object internally from GNU Radio version 3.8 to 3.9. In my .h file I have got this: //old: gr::fft::fft_complex d_fft_calculator; gr::fft::fft_complex_fwd d_fft_calculator; and in the constructor member initializer list this: //old: d_fft_calculator(gr::fft::fft_complex(pow(2.0, 10 + mode), true, 1)), d_fft_calculator(pow(2.0, 10 + mode), 1), The module compiles without a problem but when I start the flowgraph I get the message "ImportError: /usr/local/lib/libgnuradio-dl5eu.so.1.0.0: undefined symbol: _ZN2gr3fft3fftISt7complexIfELb1EED1Ev". It looks to me that somewhere "fft_complex" is still called behind the scenes but I can't see where. Can anyone tell me how I need to correct this? FYI, I have recreated the module and the blocks with gr_modtool and then copied the relevant code from the old to the new version. Thank you very much and kind regards, Ralf
Problem migrating an OOT module that uses FFT from 3.8 to 3.9
Hello all, I am currently trying to migrate an OOT module that uses an FFT object internally from GNU Radio version 3.8 to 3.9. In my .h file I have got this: //old: gr::fft::fft_complex d_fft_calculator; gr::fft::fft_complex_fwd d_fft_calculator; and in the constructor member initializer list this: //old: d_fft_calculator(gr::fft::fft_complex(pow(2.0, 10 + mode), true, 1)), d_fft_calculator(pow(2.0, 10 + mode), 1), The module compiles without a problem but when I start the flowgraph I get the message "ImportError: /usr/local/lib/libgnuradio-dl5eu.so.1.0.0: undefined symbol: _ZN2gr3fft3fftISt7complexIfELb1EED1Ev". It looks to me that somewhere "fft_complex" is still called behind the scenes but I can't see where. Can anyone tell me how I need to correct this? FYI, I have recreated the module and the blocks with gr_modtool and then copied the relevant code from the old to the new version. Thank you very much and kind regards, Ralf
Still: adaptation of the ISDB-T blocks for DVB-T / python problem
Dear all, I have adapted Federicos blocks OFDM Synchronization and TMCC Decoder (which is a TPS decoder now) to DVB-T. They seem to work correctly but I am still having troubles getting a stable video. I have added debug code to the OFDM Synchronization and TPS Decoder blocks. Whenever I detect a problem (symbol loss, frame loss, wrong symbol index, change in CP position, TPS not ok and so on) I print a message on the console and restart sync. In normal cases, when this happens the video just stops for one or two seconds and then continues. However, it happens that the video stops in the middle of the reception without a visible reason. The only thing I can say is that the transport stream that is generated is no longer recognized by VLC. Does anybody have experienced the same or a similar problem or has an idea what could be wrong here? Are there any DVB-T experts here on the list who could help? I would really be happy if I was able to find out what happens here and why. In order to do this, I have copied the relevant blocks from the GNU radio sources to my own module (gr-dl5eu). Unfortunately this seems to be more difficult than I thought, certainly because I am lacking knowledge. I have started with the DVB-T Demap block. I have adapted the namespace and can compile and install the block without a problem. The error I get comes from python. When I start the flowgraph in GNU Radio Companion, python complains: Traceback (most recent call last): File "/home/ralfg/Schreibtisch/GNU Radio/grc/dvbt_rx_udp_new.py", line 431, in main() File "/home/ralfg/Schreibtisch/GNU Radio/grc/dvbt_rx_udp_new.py", line 407, in main tb = top_block_cls() File "/home/ralfg/Schreibtisch/GNU Radio/grc/dvbt_rx_udp_new.py", line 292, in __init__ self.dl5eu_dvbt_demap_0 = dl5eu.dvbt_demap(1512, dtv.MOD_QPSK, dtv.NH, dtv.T2k, 1) File "/usr/lib/python3/dist-packages/dl5eu/dl5eu_swig.py", line 1046, in make return _dl5eu_swig.dvbt_demap_make(nsize, constellation, hierarchy, transmission, gain) TypeError: in method 'dvbt_demap_make', argument 2 of type 'dvb_constellation_t' Why does this type error happen in the copied block in my module (gr-dl5eu) but not in the original block in the dtv/dvbt module? I have attached my source code to this email. An expert will certainly see immediately where my error is. Perhaps somebody has some time to take a look at it? Thank you very much for your help! Kind regards, Ralf <>
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 &quo
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 w
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 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
Adaptation of Federico La Roccas ISDB-T blocks for DVB-T
Dear all, I forgot to mention in me previous mail that the test flowgraph is not generated by GRC when it terminates with a -11 return code. I have just noticed that the test.py file is missing. My GNU Radio version is 3.8.3.1. Ralf
Adaptation of Federico La Roccas ISDB-T blocks for DVB-T
Dear all, in order to benefit from Federicos ISDB-T block "OFDM Synchronization" that performs a frequency and symbol rate correction I am currently trying to adapt his blocks "OFDM Synchronization" and "TMCC Decoder" in a way that makes them usable for DVB-T. To check if they work correctly I have added some "debug printf()'s" and let them run in parallel to the blocks in a flowgraph that works. I am surprised that both of my blocks seem to work. My "TPS Decoder" decodes the TPS carriers correctly and prints out the correct information. The constellation diagram at the output of the OFDM Synchronization seems to be correct as it shows the expected image plus pilot and/or TPS carriers and at the output of the TPS decoder only the constellation of the data carriers is visible. So far, so good. Unfortunately, when I deactivate the original flowgraph, it does no longer work and I get a -11 return code. Do you have any idea how I can find out what happens here? I have attached my source code and a test flow graph to this email. For information, when I bypass the Symbol Inner Interleaver and connect the null sink directly to the output of the TPS decoder the flowgraph does not crash (no -11). I would be happy if someone (especially Federico :-) ) could take a look at it. Perhaps he or she sees at a glance what I do not see. Please do not forget that I am no experienced GNU radio user :-) Thank you very much for your help! Kind regards, Ralf <>
Re: Out Of Tree module works only partially
Hi Federico and Jeff, thank you very much for your prompt answer. As I thought, it was a "newbie" mistake :-) I have modified my block according to what Federico has written and now it works. Regards, Ralf Am 02.12.2021 um 12:31 schrieb Jeff Long: [I just saw the response from Federico as I was writing this, so it's partly a duplicate] In work(), items are in terms of vectors, so you need to store off blk_size in the constructor. In work(), you would copy blk_size * noutput_items. For an example, take a look at the source for any of the built-in blocks that can take a vector, e.g., https://github.com/gnuradio/gnuradio/blob/master/gr-blocks/include/gnuradio/blocks/abs_blk.h https://github.com/gnuradio/gnuradio/blob/master/gr-blocks/lib/abs_blk_impl.h https://github.com/gnuradio/gnuradio/blob/master/gr-blocks/lib/abs_blk_impl.cc On Thu, Dec 2, 2021 at 5:26 AM Ralf Gorholt wrote: Dear all, I am quite new to GNU Radio and in order to see how GNU Radio blocks work I would like to create my own block that (for the moment) just copies complex data from the input to the output. This works as long as I copy only one number but not when I want to copy packets of numbers that come from the preceeding block. My block takes one parameter: blk_size. I would like to insert it in my DVB-T receiver flowgraph to analyze data (in a later step). I had a look at the square_ff example and other blocks to see how they are built but I still don't see what I am doing wrong. It must be a silly mistake. Perhaps you can help me? Here is the code: myblock_impl::myblock_impl(int blk_size) : gr::block("myblock", gr::io_signature::make(1, 1, blk_size * sizeof(gr_complex)), gr::io_signature::make(1, 1, blk_size * sizeof(gr_complex))) { } void myblock_impl::forecast(int noutput_items, gr_vector_int &ninput_items_required) { ninput_items_required[0] = noutput_items; } int myblock_impl::general_work(int noutput_items, gr_vector_int &ninput_items, gr_vector_const_void_star &input_items, gr_vector_void_star &output_items) { const gr_complex *in = (const gr_complex *) input_items[0]; gr_complex *out = (gr_complex *) output_items[0]; for (int i = 0; i < noutput_items; i++) { out[i] = in[i]; } consume_each(noutput_items); return noutput_items; } And the YML file: id: dl5eu_myblock label: myblock category: '[dl5eu]' templates: imports: import dl5eu make: dl5eu.myblock(${blk_size}) parameters: - id: blk_size label: Block size dtype: int default: '1' inputs: - label: in domain: stream dtype: complex vlen: ${blk_size} optional: '0' outputs: - label: out domain: stream dtype: complex vlen: ${blk_size} optional: '0' file_format: 1 Thank you very much for your help! Kind regards, Ralf
Out Of Tree module works only partially
Dear all, I am quite new to GNU Radio and in order to see how GNU Radio blocks work I would like to create my own block that (for the moment) just copies complex data from the input to the output. This works as long as I copy only one number but not when I want to copy packets of numbers that come from the preceeding block. My block takes one parameter: blk_size. I would like to insert it in my DVB-T receiver flowgraph to analyze data (in a later step). I had a look at the square_ff example and other blocks to see how they are built but I still don't see what I am doing wrong. It must be a silly mistake. Perhaps you can help me? Here is the code: myblock_impl::myblock_impl(int blk_size) : gr::block("myblock", gr::io_signature::make(1, 1, blk_size * sizeof(gr_complex)), gr::io_signature::make(1, 1, blk_size * sizeof(gr_complex))) { } void myblock_impl::forecast(int noutput_items, gr_vector_int &ninput_items_required) { ninput_items_required[0] = noutput_items; } int myblock_impl::general_work(int noutput_items, gr_vector_int &ninput_items, gr_vector_const_void_star &input_items, gr_vector_void_star &output_items) { const gr_complex *in = (const gr_complex *) input_items[0]; gr_complex *out = (gr_complex *) output_items[0]; for (int i = 0; i < noutput_items; i++) { out[i] = in[i]; } consume_each(noutput_items); return noutput_items; } And the YML file: id: dl5eu_myblock label: myblock category: '[dl5eu]' templates: imports: import dl5eu make: dl5eu.myblock(${blk_size}) parameters: - id: blk_size label: Block size dtype: int default: '1' inputs: - label: in domain: stream dtype: complex vlen: ${blk_size} optional: '0' outputs: - label: out domain: stream dtype: complex vlen: ${blk_size} optional: '0' file_format: 1 Thank you very much for your help! Kind regards, Ralf
Re: Block not found in module although it is there
Hello Vasil, thank you very much, this seems to solve the problem and I now know where to look the next time :-) Kind regards, Ralf Am 05.05.2021 um 17:08 schrieb Vasil Velichkov: Hi Ralf, On 05/05/2021 17.38, Ralf Gorholt wrote: AttributeError: module 'dl5eu' has no attribute 'dvbt_ofdm_synchronization' Can anybody give me a hint what is happening here? You most probably need to link the gnuradio's fft component to your OOT block. In your CMakeLists.txt find the line that contains `find_package(gnuradio "3.8" ...` and add fft to the list of components. It should looks like this find_package(Gnuradio "3.8" REQUIRED COMPONENTS blocks filter fft) and then in lib/CMakeLists.txt you need to link the gnuradio-fft. Something similar to target_link_libraries(dl5eu gnuradio::gnuradio-runtime gnuradio::gnuradio-fft) Also open python/__init__.py and except ImportError: to except ModuleNotFoundError: You can find some more info in https://wiki.gnuradio.org/index.php/GNU_Radio_3.8_OOT_Module_Porting_Guide#GNU_Radio_Components Regards, Vasil
Block not found in module although it is there
Dear all, my problem concerns GNU Radio version 3.8 from the maintenance branch but it is probably not limited to this version. I would like to try to adapt the block "ofdm_synchronization" that Federico Larrocca and others have developed for ISDB-T so that it can be used for DVB-T. For this purpose I have created the module "gr-dl5eu" that contains a block called "dvbt_ofdm_synchronization". As long as the block only passes data from the input to the output everything is ok. But when I start to add code to the constructor, the block dvbt_ofdm_synchronization is no longer found in gr-dl5eu when I run the flow graph. My constructor looks like this: dvbt_ofdm_synchronization_impl::dvbt_ofdm_synchronization_impl(int mode, int cp_length, bool interpolate : gr::block("dvbt_ofdm_synchronization", gr::io_signature::make(1, 1, sizeof(gr_complex)), gr::io_signature::make(1, 1, sizeof(gr_complex))) { } Everything is fine, the block copies data from input to output. But when I add the variable "d_fft_calculator" to the private section of the object and the following line just before the opening brace of the constructor: " , d_fft_calculator(gr::fft::fft_complex(pow(2.0, 10+mode), true, 1))", I get an error message when I run the flow graph: "AttributeError: module 'dl5eu' has no attribute 'dvbt_ofdm_synchronization'" The complete messages are below. <<< Welcome to GNU Radio Companion v3.8.2.0-113-g729d5a98 >>> Block paths: /usr/share/gnuradio/grc/blocks Loading: "/home/ralfg/gnuradio/dvbt_rx_udp.grc" >>> Done Generating: '/home/ralfg/gnuradio/dvbt_rx_udp.py' Executing: /usr/bin/python3 -u /home/ralfg/gnuradio/dvbt_rx_udp.py qt5ct: using qt5ct plugin gr-osmosdr 0.2.0.0 (0.2.0) gnuradio v3.8.2.0-113-g729d5a98 built-in source types: file rtl rtl_tcp rfspace redpitaya Using device #0 Realtek RTL2838UHIDIR SN: 0001 Found Rafael Micro R820T tuner Setting rtl clock to 2880 Hz. Setting tuner clock to 2880 Hz. [R82XX] PLL not locked! Exact sample rate is: 1142857,021756 Hz [R82XX] PLL not locked! Traceback (most recent call last): File "/home/ralfg/gnuradio/dvbt_rx_udp.py", line 404, in main() File "/home/ralfg/gnuradio/dvbt_rx_udp.py", line 380, in main tb = top_block_cls() File "/home/ralfg/gnuradio/dvbt_rx_udp.py", line 272, in __init__ self.dl5eu_dvbt_ofdm_synchronization_0 = dl5eu.dvbt_ofdm_synchronization(1, 0.125, True) AttributeError: module 'dl5eu' has no attribute 'dvbt_ofdm_synchronization' >>> Done (return code 1) In the original code the initialization of "d_fft_calculator" the initializatiion is done this way. I have the same problem when I change d_fft_calculator to a pointer type and initialize it with "new" inside of the constructor. Can anybody give me a hint what is happening here? Is there something missing in the .yml file? I have got the impression that C++ and GNU Radio are indeed not made for beginners :-( Thank you very much for your help! Kind regards, Ralf
Re: GNU Radio 3.9 gr_modtool problem
I have installed GNU Radio from the master branch, so I have got version 3.10 now. The install prefix is /usr. I don't have a ~/.gnuradio/config.conf file, only ~/.gnuradio/grc.conf exists after I have started gnuradio-companion. The directory /etc/gnuradio/conf.d exists. The files in there are -rw-r--r-- 1 root root 209 Mai 5 14:09 00-grc-docs.conf -rw-r--r-- 1 root root 1074 Mai 5 14:09 gnuradio-runtime.conf -rw-r--r-- 1 root root 351 Mai 5 14:07 gr-audio-alsa.conf -rw-r--r-- 1 root root 414 Mai 5 14:07 gr-audio.conf -rw-r--r-- 1 root root 270 Mai 5 14:07 gr-audio-oss.conf -rw-r--r-- 1 root root 732 Mai 5 14:09 grc.conf -rw-r--r-- 1 root root 736 Mai 5 14:07 gr_log_default.conf -rw-r--r-- 1 root root 496 Mai 5 14:07 gr-qtgui.conf -rw-r--r-- 1 root root 228 Mai 5 14:09 modtool.conf modtool.conf contains: # You may override any setting on a per-user basis by editing # ~/.gnuradio/config.conf [modtool] newmod_path = /usr/share/gnuradio/modtool/templates/gr-newmod The directory /usr/share/gnuradio/modtool/templates/gr-newmod exists and the content is drwxr-xr-x 2 root root 4096 Mai 5 15:22 apps drwxr-xr-x 3 root root 4096 Mai 5 15:22 cmake -rw-r--r-- 1 root root 6567 Mai 5 14:07 CMakeLists.txt drwxr-xr-x 3 root root 4096 Mai 5 15:22 docs drwxr-xr-x 2 root root 4096 Mai 5 15:22 examples -rw-r--r-- 1 root root 41 Mai 5 14:07 .gitignore drwxr-xr-x 2 root root 4096 Mai 5 15:22 grc drwxr-xr-x 3 root root 4096 Mai 5 15:22 include drwxr-xr-x 2 root root 4096 Mai 5 15:22 lib -rw-r--r-- 1 root root 717 Mai 5 14:07 MANIFEST.md drwxr-xr-x 3 root root 4096 Mai 5 15:22 python Then I have created a file config.conf in ~/.gnuradio that contains [modtool] newmod_path = /usr/share/gnuradio/modtool/templates/gr-newmod The error remains. I can call gr_modtool without parameters. In this case a help text is shown. Only when I want to add a new module the error message is shown. Ralf Am 05.05.2021 um 12:31 schrieb Josh Morman: Check your ~/.gnuradio/config.conf file. In there is a section [modtool] and a "newmod_path=..." Verify that matches the value of your installed path. On mine it says: [modtool] newmod_path = /share/gnuradio/gr39/share/gnuradio/modtool/templates/gr-newmod For 3.9, there was a slight change in the behavior how GR finds the newmod path: https://github.com/gnuradio/gnuradio/pull/3266 <https://github.com/gnuradio/gnuradio/pull/3266> in that it will look wherever the currently installed prefix is, which can be seen with gnuradio-config-info --prefix Make sure your environment variables are sourced correctly - PATH, PYTHONPATH, LD_LIBRARY_PATH, and LIBRARY_PATH On Tue, May 4, 2021 at 5:50 PM Ralf Gorholt mailto:ralf.gorh...@gmx.de>> wrote: Dear all, on my Linux Mint (Ubuntu) box, I have installed and compiled GNU Radio 3.9 from source (master branch) as described here: https://wiki.gnuradio.org/index.php/UbuntuInstall#Focal_Fossa_.2820.04.29 <https://wiki.gnuradio.org/index.php/UbuntuInstall#Focal_Fossa_.2820.04.29> and here: https://wiki.gnuradio.org/index.php/InstallingGR#From_Source <https://wiki.gnuradio.org/index.php/InstallingGR#From_Source> CMAKE_INSTALL_PREFIX is /usr. GNU Radio compiles (without UHD and soapy support) and the tests are ok. gnuradio-companion starts and everything seems ok. However, when I try to create a new module with "gr_modtool newmod dl5eu", I get the error message: ModToolException: Could not find gr-newmod source dir. I have also tried what was necessary for Ubuntu 18: $ cd /usr/share/gnuradio/modtool/templates/gr-newmod $ sudo py3clean . but this did not solve the problem. With version 3.8 compiled from the maint-3.8 branch I don't have this problem. Do you have an idea what I am doing wrong here? Thank you very much. Kind regards, Ralf
GNU Radio 3.9 gr_modtool problem
Dear all, on my Linux Mint (Ubuntu) box, I have installed and compiled GNU Radio 3.9 from source (master branch) as described here: https://wiki.gnuradio.org/index.php/UbuntuInstall#Focal_Fossa_.2820.04.29 and here: https://wiki.gnuradio.org/index.php/InstallingGR#From_Source CMAKE_INSTALL_PREFIX is /usr. GNU Radio compiles (without UHD and soapy support) and the tests are ok. gnuradio-companion starts and everything seems ok. However, when I try to create a new module with "gr_modtool newmod dl5eu", I get the error message: ModToolException: Could not find gr-newmod source dir. I have also tried what was necessary for Ubuntu 18: $ cd /usr/share/gnuradio/modtool/templates/gr-newmod $ sudo py3clean . but this did not solve the problem. With version 3.8 compiled from the maint-3.8 branch I don't have this problem. Do you have an idea what I am doing wrong here? Thank you very much. Kind regards, Ralf
GNU Radio (Companion) bug
Dear all, I have spent several hours before my PC trying to get my new OOT block running, but in vain. Now I have got the impression that one of my problems is due to a bug in GNU Radio (Companion). I have attached a working graph (using Qt GUI) to this email. I am not used to report bugs but in the wiki I have read that I should send an email to this list. The problem is, that in certain cases when I change the value of a parameter in a combo box, GRC displays a message telling me that ports are disconnected although they are not. This behaviour can easily reproduced. In GRC, load the attached flow graph and open the properties window of a block that has a combo box. Then, change a parameter and click the "Apply" button. The value in the block changes. Then change the value back. As soon as you select the item in the combo box, a message is displayed telling you that the ports are not connected and no more changes are accepted, even when you click on "Apply". I have verified this with GNU Radio version 3.8.2.0 on Linux (Python 3.8.5) and 3.8.0.0 on Windows (Python 2.7.10). GNU Radio 3.9 (checked on Windows) does not show this behaviour but if I remember correctly, not everything has been ported to version 3.9 yet and for this reason I would like to keep version 3.8. Would it be possible to fix this bug also in version 3.8? Thank you very much for your help. Kind regards, Ralf options: parameters: author: Laurent F4FDW category: '[GRC Hier Blocks]' cmake_opt: '' comment: '' copyright: '' description: Flow Graph de reception DVB-T 1 MHz de BW sur 70cm avec un stick RTL-SDR gen_cmake: 'On' gen_linking: dynamic generate_options: qt_gui hier_block_src_path: '.:' id: dvbt_rx_udp max_nouts: '0' output_language: python placement: (0,0) qt_qss_theme: '' realtime_scheduling: '' run: 'True' run_command: '{python} -u {filename}' run_options: prompt sizing_mode: fixed thread_safe_setters: '' title: RX DVB-T en low BW sur 70cm window_size: '' states: bus_sink: false bus_source: false bus_structure: null coordinate: [16, 16.0] rotation: 0 state: enabled blocks: - name: center_freq id: variable parameters: comment: '' value: ui_center_freq states: bus_sink: false bus_source: false bus_structure: null coordinate: [328, 564.0] rotation: 0 state: enabled - name: freq_corr_ppm id: variable parameters: comment: '' value: ui_freq_corr_ppm states: bus_sink: false bus_source: false bus_structure: null coordinate: [208, 564.0] rotation: 0 state: enabled - name: if_gain_db id: variable parameters: comment: '' value: ui_if_gain_db states: bus_sink: false bus_source: false bus_structure: null coordinate: [528, 564.0] rotation: 0 state: enabled - name: rf_gain_db id: variable parameters: comment: '' value: ui_rf_gain_db states: bus_sink: false bus_source: false bus_structure: null coordinate: [432, 564.0] rotation: 0 state: enabled - name: samp_rate id: variable parameters: comment: '' value: (25 * 8) / 7 states: bus_sink: false bus_source: false bus_structure: null coordinate: [856, 564.0] rotation: 0 state: disabled - name: samp_rate_chooser_0 id: variable_qtgui_chooser parameters: comment: '' gui_hint: 4,0,1,1 label: Bandwidth label0: 200khz label1: 250khz label2: 1Mhz label3: 2MHz label4: '' labels: '[]' num_opts: '4' option0: '228571' option1: '285714' option2: '1142857' option3: '2285714' option4: '' options: '[0, 1, 2]' orient: Qt.QHBoxLayout type: real value: '1142857' widget: radio_buttons states: bus_sink: false bus_source: false bus_structure: null coordinate: [16, 408.0] rotation: 0 state: true - name: ui_center_freq id: variable_qtgui_range parameters: comment: '' gui_hint: 2, 0,1,1 label: center freq. min_len: '0' orient: Qt.Horizontal rangeType: int start: '43000' step: '1000' stop: '44000' value: '43400' widget: counter states: bus_sink: false bus_source: false bus_structure: null coordinate: [352, 20.0] rotation: 0 state: enabled - name: ui_freq_corr_ppm id: variable_qtgui_range parameters: comment: '' gui_hint: 2, 1,1,1 label: Freq. ppm min_len: '0' orient: Qt.Horizontal rangeType:
GNU Radio blocks, GRC and .yml files
Dear all, I am still a GNU Radio beginner and at the moment I try to figure out how to develop an OOT block for GNU Radio. The tutorial explains how to do this and I have managed to create my first block. However, when it comes to the .yml file, I don't find all the information that I need. Is there a document that explains _in detail_ the block descriptions? I have already looked at https://wiki.gnuradio.org/index.php/YAML_GRC but this page does not answer my question. I am looking for a possibility to create an enumeration of float values. Is this possible or are only integer values allowed (as in C/C++)? For example, in my block I need an option called "Guard interval" that has four possible values: 0.25, 0.125, 0.0625 and 0.03125. The corresponding labels would be 1/4, 1/8, 1/16 and 1/32. How can I do this? Thank you very much for your help! Kind regards, Ralf
Re: R: Re: Gnuradio / Ubuntu 20.10
Hi Marcus, to be precise: I use Linux Mint 20.1 which is based on Ubuntu. Effectively, the gr-osmosdr module version 0.2.0-2 works with the version of GNU Radio that is available by default in this Linux Mint version (3.8.1-rc1-2build2) but as far as I remember, it did not work with GNU Radio 3.8.2, the GNU Radio version that I have installed. That's the reason why I have compiled it from source. Kind regards, Ralf Am 11.04.2021 um 17:31 schrieb Marcus Müller: Hi Ralf, glad to hear you've got it to work! When not using the PPA (which I was assuming you'd be doing), you'd get the exact gr-osmosdr that works with Ubuntu's version of GNU Radio (i.e. 3.8.1.0 as I thought you've installed?). Best regards, Marcus On 11.04.21 16:40, Ralf Gorholt wrote: Hello Marcus, I had done this before (installed from PPA) but I didn't get a module that worked with GNU Radio 3.8.2. That's why I have compiled it from source. When the module is compiled, you have to pay attention to the correct prefix for cmake. Ralf Am 11.04.2021 um 14:37 schrieb Marcus Müller: You have to do none of this, sudo apt install gr-osmosdr does everything. And then you're done and can use the OSMOSDR Source or the RTL-Source (which are essentially the same). Cheers, Marcus On 11.04.21 13:26, Ralf Gorholt wrote: Hello Alberto, you may try this: git clone git://github.com/osmocom/gr-osmosdr -b gr3.8 That's how I got the sources for GNU Radio 3.8 one or two weeks ago. Regards, Ralf Am 11.04.2021 um 12:35 schrieb alberto.alle...@alice.it: I follow now this guide: https://lists.gnu.org/archive/html/discuss-gnuradio/2020-09/pdfNp27msymbN.pdf But at point 7 i have a problem. alberto@alberto-Studio-XPS-1340:~/sdr_stuff$ git clone https://git.osmocom.org/gr-osmosdr Clone in 'gr-osmosdr' in corso... error: Failed to connect to git.osmocom.org port 443: Connessione scaduta (curl_result = 7, http_code = 0, sha1 = 3d94e1a5d172fc93da9e9638536ee773f4b5a85a) error: Unable to find 99f14f4991f4154d743fd08b9c49e4eaf8a70001 under https://git.osmocom.org/gr-osmosdr Cannot obtain needed blob 99f14f4991f4154d743fd08b9c49e4eaf8a70001 while processing commit 2d504bde50a0c560a9d31b7b38982bd44cc7fe9d. error: recupero non riuscito. alberto@alberto-Studio-XPS-1340:~/sdr_stuff$ Messaggio originale Da: fab...@opencode.eu Data: 10-apr-2021 22.08 A: Ogg: Re: Gnuradio / Ubuntu 20.10 Hi Alberto, Just open a terminal and run sudo apt install gnuradio And you should be fine. The dependencies for the rtl-sdr are already included. It is probably not the latest&greatest version of gnuradio, but IT should get you started. Fabian Am 10. April 2021 21:38:47 MESZ schrieb Alberto Alletto : Hi! I’m new on ubuntu world. Today i have installed ubuntu 20.10 and i want install Gnuradio to work with RTL-SDR receiver. what is the correct procedure to install gnuradio to work with the rtl-sdr receiver? Tnx Alberto Inviato da iPhone
Re: R: Re: Gnuradio / Ubuntu 20.10
Hello Marcus, I had done this before (installed from PPA) but I didn't get a module that worked with GNU Radio 3.8.2. That's why I have compiled it from source. When the module is compiled, you have to pay attention to the correct prefix for cmake. Ralf Am 11.04.2021 um 14:37 schrieb Marcus Müller: You have to do none of this, sudo apt install gr-osmosdr does everything. And then you're done and can use the OSMOSDR Source or the RTL-Source (which are essentially the same). Cheers, Marcus On 11.04.21 13:26, Ralf Gorholt wrote: Hello Alberto, you may try this: git clone git://github.com/osmocom/gr-osmosdr -b gr3.8 That's how I got the sources for GNU Radio 3.8 one or two weeks ago. Regards, Ralf Am 11.04.2021 um 12:35 schrieb alberto.alle...@alice.it: I follow now this guide: https://lists.gnu.org/archive/html/discuss-gnuradio/2020-09/pdfNp27msymbN.pdf But at point 7 i have a problem. alberto@alberto-Studio-XPS-1340:~/sdr_stuff$ git clone https://git.osmocom.org/gr-osmosdr Clone in 'gr-osmosdr' in corso... error: Failed to connect to git.osmocom.org port 443: Connessione scaduta (curl_result = 7, http_code = 0, sha1 = 3d94e1a5d172fc93da9e9638536ee773f4b5a85a) error: Unable to find 99f14f4991f4154d743fd08b9c49e4eaf8a70001 under https://git.osmocom.org/gr-osmosdr Cannot obtain needed blob 99f14f4991f4154d743fd08b9c49e4eaf8a70001 while processing commit 2d504bde50a0c560a9d31b7b38982bd44cc7fe9d. error: recupero non riuscito. alberto@alberto-Studio-XPS-1340:~/sdr_stuff$ Messaggio originale Da: fab...@opencode.eu Data: 10-apr-2021 22.08 A: Ogg: Re: Gnuradio / Ubuntu 20.10 Hi Alberto, Just open a terminal and run sudo apt install gnuradio And you should be fine. The dependencies for the rtl-sdr are already included. It is probably not the latest&greatest version of gnuradio, but IT should get you started. Fabian Am 10. April 2021 21:38:47 MESZ schrieb Alberto Alletto : Hi! I’m new on ubuntu world. Today i have installed ubuntu 20.10 and i want install Gnuradio to work with RTL-SDR receiver. what is the correct procedure to install gnuradio to work with the rtl-sdr receiver? Tnx Alberto Inviato da iPhone
Re: R: Re: Gnuradio / Ubuntu 20.10
Hello Alberto, you may try this: git clone git://github.com/osmocom/gr-osmosdr -b gr3.8 That's how I got the sources for GNU Radio 3.8 one or two weeks ago. Regards, Ralf Am 11.04.2021 um 12:35 schrieb alberto.alle...@alice.it: I follow now this guide: https://lists.gnu.org/archive/html/discuss-gnuradio/2020-09/pdfNp27msymbN.pdf But at point 7 i have a problem. alberto@alberto-Studio-XPS-1340:~/sdr_stuff$ git clone https://git.osmocom.org/gr-osmosdr Clone in 'gr-osmosdr' in corso... error: Failed to connect to git.osmocom.org port 443: Connessione scaduta (curl_result = 7, http_code = 0, sha1 = 3d94e1a5d172fc93da9e9638536ee773f4b5a85a) error: Unable to find 99f14f4991f4154d743fd08b9c49e4eaf8a70001 under https://git.osmocom.org/gr-osmosdr Cannot obtain needed blob 99f14f4991f4154d743fd08b9c49e4eaf8a70001 while processing commit 2d504bde50a0c560a9d31b7b38982bd44cc7fe9d. error: recupero non riuscito. alberto@alberto-Studio-XPS-1340:~/sdr_stuff$ Messaggio originale Da: fab...@opencode.eu Data: 10-apr-2021 22.08 A: Ogg: Re: Gnuradio / Ubuntu 20.10 Hi Alberto, Just open a terminal and run sudo apt install gnuradio And you should be fine. The dependencies for the rtl-sdr are already included. It is probably not the latest&greatest version of gnuradio, but IT should get you started. Fabian Am 10. April 2021 21:38:47 MESZ schrieb Alberto Alletto : Hi! I’m new on ubuntu world. Today i have installed ubuntu 20.10 and i want install Gnuradio to work with RTL-SDR receiver. what is the correct procedure to install gnuradio to work with the rtl-sdr receiver? Tnx Alberto Inviato da iPhone
Re: Transport stream source
Thank you, this would explain why it did not work out of the box. I had tried multi-cast. Ralf Am 04.04.2021 um 20:22 schrieb Marcus D. Leech: On 04/04/2021 12:22 PM, Ralf Gorholt wrote: Hello Steven, when I look at your flow graph, that is exactly what I have tried to do (use a UDP source and UDP sink) but it did not work. Could it be because I had not put a throttle between source and sink? I will try to reproduce what you have done and see if it works (I don't know 'socat' and have never used it before). Ralf I'll note that any application using multi-cast UDP must do some "special dances" with most OS in order for multi-cast to "work". See, for example, some example code here: https://gist.github.com/hostilefork/f7cae3dc33e7416f2dd25a402857b6c6 It's unlikely that the gr UDP source/sink "know" how to handle multi-cast by themselves.
Re: Transport stream source
Hello Steven, when I look at your flow graph, that is exactly what I have tried to do (use a UDP source and UDP sink) but it did not work. Could it be because I had not put a throttle between source and sink? I will try to reproduce what you have done and see if it works (I don't know 'socat' and have never used it before). Ralf Am 04.04.2021 um 18:09 schrieb Steven Barbo: Hello. If the question is, how can one receive an multicast udp transport stream into udp gr source block? as a test, i've an encoder that encodes a transport stream to udp://239.255.42.42:5004 <http://239.255.42.42:5004> - socat udp4-recv:5004,ip-add-membership=239.255.42.42.0:0.0.0 udp4-sendto:192.168.12.12:5006 <http://192.168.12.12:5006> now send it back out using multicast address 239.255.99.99 <http://239.255.99.99>: 5008 from gr block - mc.png On Sat, Apr 3, 2021 at 2:48 PM Ralf Gorholt mailto:ralf.gorh...@gmx.de>> wrote: Dear all, instead of using a file source, I would like to get data from a video stream into GNU Radio. Is this possible? With VLC, I can connect to the stream using a URL like udp://230.0.0.10:1234 <http://230.0.0.10:1234>. How can I do this in GNU Radio? I have tried to use a UDP source with this address and payload size 1316 (needed for VLC when it connects to a UDP sink in GNU Radio) and to pass the data to a UDP sink at address 230.0.0.20:1 <http://230.0.0.20:1> and payload size 1316 to which I can connect with VLC to see if it works but when I start the flow graph, nothing seems to come out, VLC tries in vain to connect. Thank you very much and happy easter! Kind regards, Ralf -- If something is requisite, how can it possibly be, prerequisite? vanitas vanitatum omnia vanitas later, steve http://umn.edu/~barbo <http://umn.edu/~barbo>
Re: Transport stream source
Hi Marcus, as I have written, I have tried to use a UDP source (and to connect it to a UDP sink with a different IP address and port) but it does not seem to work. As I am quite new to GNU radio, I have certainly made a mistake somewhere. If I only needed a TS source (no matter which one) I could stick with a file. I have already done that and it worked. Could somebody please direct me to the documentation where the basic principle of how GNU Radio works is explained? I know that there are blocks that you can connect together but there must be a "controller" somewhere and I would like to understand how this controller works and how the blocks are called. What I have read until now does not answer my questions :-) Happy Easter, Ralf Am 03.04.2021 um 21:52 schrieb Marcus D Leech: If you want VLC to produce a stream and Gnu Radio to consume it, you need a UDP *source* rather than a *sink*. Sent from my iPhone On Apr 3, 2021, at 3:48 PM, Ralf Gorholt wrote: Dear all, instead of using a file source, I would like to get data from a video stream into GNU Radio. Is this possible? With VLC, I can connect to the stream using a URL like udp://230.0.0.10:1234. How can I do this in GNU Radio? I have tried to use a UDP source with this address and payload size 1316 (needed for VLC when it connects to a UDP sink in GNU Radio) and to pass the data to a UDP sink at address 230.0.0.20:1 and payload size 1316 to which I can connect with VLC to see if it works but when I start the flow graph, nothing seems to come out, VLC tries in vain to connect. Thank you very much and happy easter! Kind regards, Ralf
Transport stream source
Dear all, instead of using a file source, I would like to get data from a video stream into GNU Radio. Is this possible? With VLC, I can connect to the stream using a URL like udp://230.0.0.10:1234. How can I do this in GNU Radio? I have tried to use a UDP source with this address and payload size 1316 (needed for VLC when it connects to a UDP sink in GNU Radio) and to pass the data to a UDP sink at address 230.0.0.20:1 and payload size 1316 to which I can connect with VLC to see if it works but when I start the flow graph, nothing seems to come out, VLC tries in vain to connect. Thank you very much and happy easter! Kind regards, Ralf
Compilation of Ron Economos' gr-dvbtx for GNU Radio 3.8 - help needed
Dear all, I have tried to compile Ron Economs’ block gr-dvbtx from github.com/drmpeg/gr-dvbtx for GNU Radio 3.7.11 and 3.8.2 but I have noticed several problems. 1) In both environments compilation stops because of an error: "gr-dvbtx/lib/dvbtx_ofdm_sym_acquisition_impl.cc:54:68: error: cannot convert ‘uint32_t* {aka unsigned int*}’ to ‘uint16_t* {aka short unsigned int*}’ in argument passing volk_32f_index_max_16u(&peak_index, &datain[0], datain_length);" In order to be able to compile the module, I have declared peak_index as uint16_t but I don’t know if this is the correct way to get rid of this error. For GNU Radio 3.7 everything seems ok now. The module is compiled and appears in the list of modules of GNU Radio Companion. Is this correction ok? 2) CMakeLists.txt expects GNU Radio version 3.7.2: "find_package(Gnuradio "3.7.2" REQUIRED)". In order to compile for version 3.8.2, I had to adapt this line. 3) Now I can compile the module for GNU Radio 3.8, but after "make install" and "ldconfig", GNU Radio Companion does not show the module in the list. Install prefix is /usr. I have noticed that the compiled module for version 3.7 has a version information in the name: "libgnuradio-dvbtx-1.0.0git.so.0.0.0" but the one for version 3.8 has not: "libgnuradio-dvbtx-...so.0.0.0". Could this be the reason for the problem? The version is set in CMakeLists.txt. Why is it empty when compiled for version 3.8? Could somebody please give me a hint what I have to do to get this module compiled and installed for GNU Radio 3.8? I would like to use it on a more recent version of GNU Radio than 3.7. Thank you very much for your help! Kind regards, Ralf
Compile OOT module on Windows
Ok, please forget my question. I have found that I need to specify the Makefile generator which at least in my case is NMake by default but I need MinGW. Now I have to install missing software (e.g. boost). Ralf
Re: Survey regarding GNU radio usage in amateur radio
Hello Adrian, here are my answers to your questions: 1) No. 2) I have tried to use it for DVB-T reception with an RTL-SDR stick in the 70cm band with non standard bandwidths (2 MHz and lower). In principle, this is possible, but there is a problem in the OFDM symbol recognition block due to different clocks used by the receiver and transmitter. This leads sooner or later (seconds to minutes) to reception loss because the receiver has to re-synchronize again. Somebody on the list (I don't remember his name by heart, I would have to search my emails) has made something for ISDB-T but this is not usable for DVB-T. 3) In my opinion, GNU Radio is a very powerful tool. But, it is only a tool and a tool that you have to know how to use. Abolutely nothing for beginners. Mostly nothing is really ready, you have to build what you need yourself. The GUI is very basic. This is only my personal impression, I may be wrong. And I don't know PYTHON and at my age, I don't want to learn yet another programming language. 4) Strong: very powerful and versatile. Weak: different versions of GNU Radio are available, for Linux and Windows, every one with different options (available blocks). Sometimes newer versions do not offer all available blocks. Sometimes you have to compile modules yourself, something that is difficult when you have to or want to stick to Windows. I am partially able to do this but many OMs that I know are not. And lastly, even if Linux was the best system around, people would still prefer Windows. My impression is that without an always up to date Windows version GNU Radio will remain something for "nerds". 5) Yes. Kind regards, Ralf Am 14.11.2020 um 21:43 schrieb Elmore Family: Adrian, Here are my answers to your survey; 1. Yes 2. Attempting to provide a complete transceiver for a Softrock/MOBO 4. It has a very steep learning curve which will keep the majority of hams from utilizing it. However, it's block nature allows RAD which is very attractive for SDR development. 5. No -Original Message- From: Adrian Musceac Sent: Saturday, November 14, 2020 3:11 AM To: discuss-gnuradio@gnu.org Subject: Survey regarding GNU radio usage in amateur radio Hello, I am doing a survey regarding the topic of GNU radio usage in amateur radio activities. This survey is aimed at GNU radio users who are also amateur radio operators. The result of the survey will be published in an article freely available on the Internet and may also be translated to other languages for reading by other amateur radio operators. Your contribution to the survey will remain anonymous unless you express a wish to have author attribution for the answers. You should be comfortable with the license of publication which will be one of Creative Commons Attribution 4.0 license or GNU Free Documentation license. You may reply directly or send me the answers privately. The date limit for answers is 30 December current year. I will ask you to respond to the following questions (you may omit questions where you do not have answers): 1. Are you actively using GNU radio in amateur radio activities? 2. If yes, how are you using GNU radio, please provide some details. 3. Do you think GNU radio and applications using it solve some specific problem for amateur operators which is not solved by other free software DSP libraries, or, on the contrary, do you think it should implement a solution that already exists elsewhere? 4. What would you consider strong and weak points in GNU radio when related to amateur radio usage? 5. Is your local amateur radio community generally aware of the existence of GNU radio? 6. If you have any authored / co-authored published papers, talk slides, seminars etc. related to the topic of this survey, can you provide a short description and a link if available? 7. Are you involved in research projects which use amateur radio crowd-sourced data, and if so, can you provide a short description of the project? 8. Do you have any suggestions for raising general amateur radio public awareness of free software in general and specifically GNU radio? Thanks in advance for answering. Adrian
Re: DVB-T receiver problem (OFDM symbol acquisition)
Hello Ron, do you think it would be possible to use your block that detects the drift to adapt the sample rate of the source block automatically and if yes, how would I have to do that? When the position of the CP increases, the sample rate must be decreased and vice versa. Could it be done by a kind of feedback? This way it would not be necessary to implement the algorithm for DVB-T. Even if I would like to do this, due to my lack of knowledge I don't think that I would be able to. Sample rate correction solves my problem but in order to be useful, it would have to be done automatically. Thank you very much and kind regards, Ralf Am 02.03.2020 um 13:42 schrieb Ron Economos: Did you read the README.md of gr-dvbt? It says: /Late note: As of 2015, I donated the gr-dvbt project to gnuradio. It is now integrated in the mainline of gnuradio/gr-dtv./ The OFDM symbol acquisition block in gr-dtv has been upgraded with the fixes from the ISDBT team. See this commit: https://github.com/gnuradio/gnuradio/commit/761b62d4660a121c78b6a7ad17fd7b08badcbb88#diff-aa5858d955a31c6be8746db56ea13c6a However, there is still an issue with the block. It can't tolerate a sample rate difference between the transmitter and receiver. If the difference is large, the block will fail fairly quickly (minutes). I have a test OFDM acquisition block that prints out the drift. It can be found here: https://github.com/drmpeg/gr-dvbtx You may have to go back one commit to make it compile with the latest version of GNU Radio 3.7. Ron On 3/2/20 03:58, Ralf Gorholt wrote: Dear all, please apologize my long email but I cannot explain my problem and what I have done so far in three words. I am currently working on a DVB-T receiver project to receive transmissions on 434 MHz with 2 MHz bandwidth or less using GNU Radio and an RTL-SDR stick. The flow graph is based on the examples in gr-dvbt. The transmitter is a HiDes model HV320E. Reception works, but the video stops after one minute or so while the constellation diagram is still active (dots are moving). I am no expert and have only few knowledge of DSP and DVB yet, but to me the problem seems to be in the OFDM symbol acquisition block. Conditions: Linux Mint 19.3 in a virtual machine (VMware) GNU Radio 3.7.11 if I am right (I would need to check at home) What I have done so far: I have created a flow graph for a DVB-T receiver based on the examples in gr-dvbt. The signal source is an RTL-SDR stick and the sample rate is 16/7 MHz (= 2.285714 MHz) to get 2 MHz bandwidth. The signal sink is a TCP server sink to which I connect with VLC media player to display the received video transport stream. This works, but after one minute or so the video stops while the constellation diagram is still active (dots are moving). I am currently using QPSK, code rate 3/4 and guard interval 1/8 but I have also tried 16QAM, code rate 1/2 and guard interval 1/8 and have the same problem. To track down the source of the problem, I have created a file outside of GNU Radio that I can use in a file source instead of the RTL-SDR source of my flow graph. This allows me to make tests with an input signal that does not change between different tests. The data of this file are sent to the OFDM symbol acquisition block and the output of this block is stored in a second file. When the input signal, the algorithm and the parameters do not change between different tests I expect the generated file to be always the same. However, this is not the case. The files that are generated with the output of the OFDM symbol acquisition block differ from each other. But when I send the content of one of those generated files to the rest of the receiver and do this several times, I always get the same transport stream at the output. I have verified this by using a file sink and comparing the files. That’s why I suspect the OFDM symbol acquisition block to be the culprit. When I was searching the internet for information concerning my problem, I found an email from 2015 in the archive of this mailing list where someone wrote that the OFDM symbol acquisition block of gr-isdbt should be used because it worked better than the one in gr-dvbt. I have done so and installed gr-isdbt from git and replaced the block. However, there are two such blocks in gr-isdbt and none of them solves my problem. They perform even worse than the original block in gr-dvbt and after some time the program terminates without a message. I hope that my explanations are clear enough. Is there anybody who can tell me what might be wrong here or what I am doing wrong? Why is the output of the OFDM symbol acquisition block not always the same when the start condition of every run is the same? Am I missing something here? Thank you very much for your help. Kind regards, Ralf
Re: DVB-T receiver problem (OFDM symbol acquisition)
Hi Ron, when I adapt the parameters of my flow graph I get exactly the same result with your file as you do. Kind regards, Ralf Am 03.03.2020 um 02:22 schrieb Ron Economos: Yes, changing back to uint16_t is correct. But something is not correct with your file. When you read from a file, sample rate doesn't matter. You shouldn't see any drift at all. I have a test file on my website. It can be downloaded at: http://www.w6rz.net/adv16.cfile It's 934,551,552 bytes It's meant to be run with the default test flow graph, dvbt_rx_8k.grc (8K, 2/3, 16QAM, 1/32 GI). On my setup, I get the following from the debug block every time. OFDM Symbol Acquisition Restarted! Cyclic Prefix position = 12671 Cyclic Prefix position = 12671 Cyclic Prefix position = 12671 Cyclic Prefix position = 12671 Cyclic Prefix position = 12671 Cyclic Prefix position = 12671 Cyclic Prefix position = 12671 Cyclic Prefix position = 12671 Cyclic Prefix position = 12671 Cyclic Prefix position = 12671 Cyclic Prefix position = 12671 Cyclic Prefix position = 12671 >>> Done That file was created by just using the transmitter test flow graph (dvbt_tx_8k.grc) and writing to a file instead of transmitting over the air. Ron On 3/2/20 12:45, Ralf Gorholt wrote: Dear Ron, the fixes seem to be included in the version that I have installed (3.7.11-10). I have tried to build your debug block but I get an error message concerning a type cast: ralfg@vm5:~/GNU Radio/src/gr-dvbtx-master/build$ make [ 5%] Building CXX object lib/CMakeFiles/gnuradio-dvbtx.dir/dvbtx_ofdm_sym_acquisition_impl.cc.o /home/ralfg/GNU Radio/src/gr-dvbtx-master/lib/dvbtx_ofdm_sym_acquisition_impl.cc: In member function ‘int gr::dvbtx::dvbtx_ofdm_sym_acquisition_impl::peak_detect_process(const float*, int, int*, int*)’: /home/ralfg/GNU Radio/src/gr-dvbtx-master/lib/dvbtx_ofdm_sym_acquisition_impl.cc:54:68: error: cannot convert ‘uint32_t* {aka unsigned int*}’ to ‘uint16_t* {aka short unsigned int*}’ in argument passing volk_32f_index_max_16u(&peak_index, &datain[0], datain_length); To be able to compile the module, I have changed the type of peak_index to uint16_t, hoping this is correct. When I run my flow graph on a live video, I can see that the position of the cyclic prefix changes constantly. The same happens when I take the data from the file as input (which I think is normal, because the signal has been sampled with the same sample rate). However, given that the data in the file don't change, I do not understand why two consecutive runs on the same data detect different positions of the cyclic prefix: 1st run: OFDM Symbol Acquisition Restarted! OFDM Symbol Acquisition Restarted! OFDM Symbol Acquisition Restarted! OFDM Symbol Acquisition Restarted! OFDM Symbol Acquisition Restarted! OFDM Symbol Acquisition Restarted! Cyclic Prefix position = 3963 Cyclic Prefix position = 3978 Cyclic Prefix position = 3993 Cyclic Prefix position = 4009 Cyclic Prefix position = 4026 [... deleted ...] Cyclic Prefix position = 4597 Cyclic Prefix position overflow! OFDM Symbol Acquisition Restarted! Cyclic Prefix position = 3460 2nd run: OFDM Symbol Acquisition Restarted! OFDM Symbol Acquisition Restarted! OFDM Symbol Acquisition Restarted! OFDM Symbol Acquisition Restarted! OFDM Symbol Acquisition Restarted! OFDM Symbol Acquisition Restarted! Cyclic Prefix position = 3963 Cyclic Prefix position = 3979 Cyclic Prefix position = 3995 Cyclic Prefix position = 4010 Cyclic Prefix position = 4025 [... deleted ...] Cyclic Prefix position = 4595 Cyclic Prefix position overflow! OFDM Symbol Acquisition Restarted! Cyclic Prefix position = 3458 At the beginning of both runs the position of the cyclic prefix is 3963. This means, that in both cases the first symbol is detected at the same position. How is it possible that the position of the following symbols differ (e.g. 3978 vs. 3979)? All I did was stopping and restarting the flow graph. As everything in the block is pure and well defined mathematics, when the conditions (data, parameters) do not change, to my understanding the result should always be the same. I may be wrong, but in this case I would like to understand why. Do you have an explanation for me? Thank you very much for your help. Kind regards, Ralf, DL5EU Am 02.03.2020 um 13:42 schrieb Ron Economos: Did you read the README.md of gr-dvbt? It says: /Late note: As of 2015, I donated the gr-dvbt project to gnuradio. It is now integrated in the mainline of gnuradio/gr-dtv./ The OFDM symbol acquisition block in gr-dtv has been upgraded with the fixes from the ISDBT team. See this commit: https://github.com/gnuradio/gnuradio/commit/761b62d4660a121c78b6a7ad17fd7b08badcbb88#diff-aa5858d955a31c6be8746db56ea13c6a However, there is still an issue with the block. It can't tolerate a sample rate difference between the transmitter and receiver. If the difference is large, the block will fail fairly quickly (minutes). I hav
Re: DVB-T receiver problem (OFDM symbol acquisition)
Hi Federico, I think I have sent my previous email a bit too fast. After having looked at the code of the OFDM Synchronization block it seems to me that this block is specific to ISDB-T. This would mean that I cannot use it for DVB-T because of incompatibilities between ISDB-T and DVB-T (e.g. carrier positions). Kind regards, Ralf Am 03.03.2020 um 13:05 schrieb Federico 'Larroca' La Rocca: Hi Ralf, It should be right after the channel. It performs symbol acquisition, FFT and channel equalization (as well as sampling corrections and coarse and fine frequency corrections). Please see the examples folder in gr-isdbt (for instance rx_demo.grc which also includes the gr-dtv blocks disabled, which should help you understand where to put the block). best El mar., 3 mar. 2020 a las 4:16, Ralf Gorholt (mailto:ralf.gorh...@gmx.de>>) escribió: Dear Federico, unfortunately I have not been able to figure out how this block has to be used and where it has to be positioned in the flow graph. Although I know more about DVB-T today than three months ago I am still a beginner :-) Perhaps it would help me if you could give me some hints. Thank you very much and kind regards, Ralf, DL5EU *Gesendet:* Montag, 02. März 2020 um 13:47 Uhr *Von:* "Federico 'Larroca' La Rocca" mailto:flarr...@gmail.com>> *An:* "Ron Economos" mailto:w...@comcast.net>> *Cc:* "GNURadio Discussion List" mailto:discuss-gnuradio@gnu.org>> *Betreff:* Re: DVB-T receiver problem (OFDM symbol acquisition) Hi, Although I don't have an answer to Ralf's question, if the sampling rate seems to be a problem, gr-isdbt's OFDM Synchronization block (with "Interpolate" set to "yes") corrects the sampling rate; see https://iie.fing.edu.uy/publicaciones/2016/LFGGB16/ for an explanation of the algorithm (although it expects different tags and parameters, so that's probably why it won't work out of the box with the rest of the gr-dtv blocks or a DVB-T transmission). As Ron wrote, the rest of the block is mostly the same as in gr-dtv. best Federico El lun., 2 mar. 2020 a las 9:44, Ron Economos (mailto:w...@comcast.net>>) escribió: Did you read the README.md of gr-dvbt? It says: /Late note: As of 2015, I donated the gr-dvbt project to gnuradio. It is now integrated in the mainline of gnuradio/gr-dtv./ The OFDM symbol acquisition block in gr-dtv has been upgraded with the fixes from the ISDBT team. See this commit: https://github.com/gnuradio/gnuradio/commit/761b62d4660a121c78b6a7ad17fd7b08badcbb88#diff-aa5858d955a31c6be8746db56ea13c6a However, there is still an issue with the block. It can't tolerate a sample rate difference between the transmitter and receiver. If the difference is large, the block will fail fairly quickly (minutes). I have a test OFDM acquisition block that prints out the drift. It can be found here: https://github.com/drmpeg/gr-dvbtx You may have to go back one commit to make it compile with the latest version of GNU Radio 3.7. Ron On 3/2/20 03:58, Ralf Gorholt wrote: Dear all, please apologize my long email but I cannot explain my problem and what I have done so far in three words. I am currently working on a DVB-T receiver project to receive transmissions on 434 MHz with 2 MHz bandwidth or less using GNU Radio and an RTL-SDR stick. The flow graph is based on the examples in gr-dvbt. The transmitter is a HiDes model HV320E. Reception works, but the video stops after one minute or so while the constellation diagram is still active (dots are moving). I am no expert and have only few knowledge of DSP and DVB yet, but to me the problem seems to be in the OFDM symbol acquisition block. Conditions: Linux Mint 19.3 in a virtual machine (VMware) GNU Radio 3.7.11 if I am right (I would need to check at home) What I have done so far: I have created a flow graph for a DVB-T receiver based on the examples in gr-dvbt. The signal source is an RTL-SDR stick and the sample rate is 16/7 MHz (= 2.285714 MHz) to get 2 MHz bandwidth. The signal sink is a TCP server sink to which I connect with VLC media player to display the received video transport stream. This works, but after one minute or so the video stops while the constellation diagram is still active (dots are moving). I am currently using QPSK, code rate 3/4 and guard interval 1/8 but I have also tried 16QAM, c
Aw: Re: DVB-T receiver problem (OFDM symbol acquisition)
Thank you very much, Federico. If I understand correctly, this block replaces the OFDM symbol acquisition block. I will have a look at the examples and try it. Best regards, Ralf, DL5EU Gesendet: Dienstag, 03. März 2020 um 13:05 Uhr Von: "Federico 'Larroca' La Rocca" An: "Ralf Gorholt" Cc: "GNURadio Discussion List" Betreff: Re: DVB-T receiver problem (OFDM symbol acquisition) Hi Ralf, It should be right after the channel. It performs symbol acquisition, FFT and channel equalization (as well as sampling corrections and coarse and fine frequency corrections). Please see the examples folder in gr-isdbt (for instance rx_demo.grc which also includes the gr-dtv blocks disabled, which should help you understand where to put the block). best El mar., 3 mar. 2020 a las 4:16, Ralf Gorholt (<ralf.gorh...@gmx.de>) escribió: Dear Federico, unfortunately I have not been able to figure out how this block has to be used and where it has to be positioned in the flow graph. Although I know more about DVB-T today than three months ago I am still a beginner :-) Perhaps it would help me if you could give me some hints. Thank you very much and kind regards, Ralf, DL5EU Gesendet: Montag, 02. März 2020 um 13:47 Uhr Von: "Federico 'Larroca' La Rocca" <flarr...@gmail.com> An: "Ron Economos" <w...@comcast.net> Cc: "GNURadio Discussion List" <discuss-gnuradio@gnu.org> Betreff: Re: DVB-T receiver problem (OFDM symbol acquisition) Hi, Although I don't have an answer to Ralf's question, if the sampling rate seems to be a problem, gr-isdbt's OFDM Synchronization block (with "Interpolate" set to "yes") corrects the sampling rate; see https://iie.fing.edu.uy/publicaciones/2016/LFGGB16/ for an explanation of the algorithm (although it expects different tags and parameters, so that's probably why it won't work out of the box with the rest of the gr-dtv blocks or a DVB-T transmission). As Ron wrote, the rest of the block is mostly the same as in gr-dtv. best Federico El lun., 2 mar. 2020 a las 9:44, Ron Economos (<w...@comcast.net>) escribió: Did you read the README.md of gr-dvbt? It says: Late note: As of 2015, I donated the gr-dvbt project to gnuradio. It is now integrated in the mainline of gnuradio/gr-dtv. The OFDM symbol acquisition block in gr-dtv has been upgraded with the fixes from the ISDBT team. See this commit: https://github.com/gnuradio/gnuradio/commit/761b62d4660a121c78b6a7ad17fd7b08badcbb88#diff-aa5858d955a31c6be8746db56ea13c6a However, there is still an issue with the block. It can't tolerate a sample rate difference between the transmitter and receiver. If the difference is large, the block will fail fairly quickly (minutes). I have a test OFDM acquisition block that prints out the drift. It can be found here: https://github.com/drmpeg/gr-dvbtx You may have to go back one commit to make it compile with the latest version of GNU Radio 3.7. Ron On 3/2/20 03:58, Ralf Gorholt wrote: Dear all, please apologize my long email but I cannot explain my problem and what I have done so far in three words. I am currently working on a DVB-T receiver project to receive transmissions on 434 MHz with 2 MHz bandwidth or less using GNU Radio and an RTL-SDR stick. The flow graph is based on the examples in gr-dvbt. The transmitter is a HiDes model HV320E. Reception works, but the video stops after one minute or so while the constellation diagram is still active (dots are moving). I am no expert and have only few knowledge of DSP and DVB yet, but to me the problem seems to be in the OFDM symbol acquisition block. Conditions: Linux Mint 19.3 in a virtual machine (VMware) GNU Radio 3.7.11 if I am right (I would need to check at home) What I have done so far: I have created a flow graph for a DVB-T receiver based on the examples in gr-dvbt. The signal source is an RTL-SDR stick and the sample rate is 16/7 MHz (= 2.285714 MHz) to get 2 MHz bandwidth. The signal sink is a TCP server sink to which I connect with VLC media player to display the received video transport stream. This works, but after one minute or so the video stops while the constellation diagram is still active (dots are moving). I am currently using QPSK, code rate 3/4 and guard interval 1/8 but I have also tried 16QAM, code rate 1/2 and guard interval 1/8 and have the same problem. To track down the source of the problem, I have created a file outside of GNU Radio that I can use in a file source instead of the RTL-SDR source of my flow graph. This allows me to make tests with an input signal that does not change between different tests. The data of this file are sent to the OFDM symbol acquisition block and the output of this block is stored in a second file. When the input signal, the algorithm and the parameters do not change be
Re: DVB-T receiver problem (OFDM symbol acquisition)
Dear Federico, unfortunately I have not been able to figure out how this block has to be used and where it has to be positioned in the flow graph. Although I know more about DVB-T today than three months ago I am still a beginner :-) Perhaps it would help me if you could give me some hints. Thank you very much and kind regards, Ralf, DL5EU Gesendet: Montag, 02. März 2020 um 13:47 Uhr Von: "Federico 'Larroca' La Rocca" An: "Ron Economos" Cc: "GNURadio Discussion List" Betreff: Re: DVB-T receiver problem (OFDM symbol acquisition) Hi, Although I don't have an answer to Ralf's question, if the sampling rate seems to be a problem, gr-isdbt's OFDM Synchronization block (with "Interpolate" set to "yes") corrects the sampling rate; see https://iie.fing.edu.uy/publicaciones/2016/LFGGB16/ for an explanation of the algorithm (although it expects different tags and parameters, so that's probably why it won't work out of the box with the rest of the gr-dtv blocks or a DVB-T transmission). As Ron wrote, the rest of the block is mostly the same as in gr-dtv. best Federico El lun., 2 mar. 2020 a las 9:44, Ron Economos (<w...@comcast.net>) escribió: Did you read the README.md of gr-dvbt? It says: Late note: As of 2015, I donated the gr-dvbt project to gnuradio. It is now integrated in the mainline of gnuradio/gr-dtv. The OFDM symbol acquisition block in gr-dtv has been upgraded with the fixes from the ISDBT team. See this commit: https://github.com/gnuradio/gnuradio/commit/761b62d4660a121c78b6a7ad17fd7b08badcbb88#diff-aa5858d955a31c6be8746db56ea13c6a However, there is still an issue with the block. It can't tolerate a sample rate difference between the transmitter and receiver. If the difference is large, the block will fail fairly quickly (minutes). I have a test OFDM acquisition block that prints out the drift. It can be found here: https://github.com/drmpeg/gr-dvbtx You may have to go back one commit to make it compile with the latest version of GNU Radio 3.7. Ron On 3/2/20 03:58, Ralf Gorholt wrote: Dear all, please apologize my long email but I cannot explain my problem and what I have done so far in three words. I am currently working on a DVB-T receiver project to receive transmissions on 434 MHz with 2 MHz bandwidth or less using GNU Radio and an RTL-SDR stick. The flow graph is based on the examples in gr-dvbt. The transmitter is a HiDes model HV320E. Reception works, but the video stops after one minute or so while the constellation diagram is still active (dots are moving). I am no expert and have only few knowledge of DSP and DVB yet, but to me the problem seems to be in the OFDM symbol acquisition block. Conditions: Linux Mint 19.3 in a virtual machine (VMware) GNU Radio 3.7.11 if I am right (I would need to check at home) What I have done so far: I have created a flow graph for a DVB-T receiver based on the examples in gr-dvbt. The signal source is an RTL-SDR stick and the sample rate is 16/7 MHz (= 2.285714 MHz) to get 2 MHz bandwidth. The signal sink is a TCP server sink to which I connect with VLC media player to display the received video transport stream. This works, but after one minute or so the video stops while the constellation diagram is still active (dots are moving). I am currently using QPSK, code rate 3/4 and guard interval 1/8 but I have also tried 16QAM, code rate 1/2 and guard interval 1/8 and have the same problem. To track down the source of the problem, I have created a file outside of GNU Radio that I can use in a file source instead of the RTL-SDR source of my flow graph. This allows me to make tests with an input signal that does not change between different tests. The data of this file are sent to the OFDM symbol acquisition block and the output of this block is stored in a second file. When the input signal, the algorithm and the parameters do not change between different tests I expect the generated file to be always the same. However, this is not the case. The files that are generated with the output of the OFDM symbol acquisition block differ from each other. But when I send the content of one of those generated files to the rest of the receiver and do this several times, I always get the same transport stream at the output. I have verified this by using a file sink and comparing the files. That’s why I suspect the OFDM symbol acquisition block to be the culprit. When I was searching the internet for information concerning my problem, I found an email from 2015 in the archive of this mailing list where someone wrote that the OFDM symbol acquisition block of gr-isdbt should be used because it worked better than the one in gr-dvbt. I have done so and installed gr-isdbt from git and replaced the block. However, there are two such blocks in gr-isdbt and none of them solves my problem. They perform even worse than the origina
Re: DVB-T receiver problem (OFDM symbol acquisition)
Dear Ron, the fixes seem to be included in the version that I have installed (3.7.11-10). I have tried to build your debug block but I get an error message concerning a type cast: ralfg@vm5:~/GNU Radio/src/gr-dvbtx-master/build$ make [ 5%] Building CXX object lib/CMakeFiles/gnuradio-dvbtx.dir/dvbtx_ofdm_sym_acquisition_impl.cc.o /home/ralfg/GNU Radio/src/gr-dvbtx-master/lib/dvbtx_ofdm_sym_acquisition_impl.cc: In member function ‘int gr::dvbtx::dvbtx_ofdm_sym_acquisition_impl::peak_detect_process(const float*, int, int*, int*)’: /home/ralfg/GNU Radio/src/gr-dvbtx-master/lib/dvbtx_ofdm_sym_acquisition_impl.cc:54:68: error: cannot convert ‘uint32_t* {aka unsigned int*}’ to ‘uint16_t* {aka short unsigned int*}’ in argument passing volk_32f_index_max_16u(&peak_index, &datain[0], datain_length); To be able to compile the module, I have changed the type of peak_index to uint16_t, hoping this is correct. When I run my flow graph on a live video, I can see that the position of the cyclic prefix changes constantly. The same happens when I take the data from the file as input (which I think is normal, because the signal has been sampled with the same sample rate). However, given that the data in the file don't change, I do not understand why two consecutive runs on the same data detect different positions of the cyclic prefix: 1st run: OFDM Symbol Acquisition Restarted! OFDM Symbol Acquisition Restarted! OFDM Symbol Acquisition Restarted! OFDM Symbol Acquisition Restarted! OFDM Symbol Acquisition Restarted! OFDM Symbol Acquisition Restarted! Cyclic Prefix position = 3963 Cyclic Prefix position = 3978 Cyclic Prefix position = 3993 Cyclic Prefix position = 4009 Cyclic Prefix position = 4026 [... deleted ...] Cyclic Prefix position = 4597 Cyclic Prefix position overflow! OFDM Symbol Acquisition Restarted! Cyclic Prefix position = 3460 2nd run: OFDM Symbol Acquisition Restarted! OFDM Symbol Acquisition Restarted! OFDM Symbol Acquisition Restarted! OFDM Symbol Acquisition Restarted! OFDM Symbol Acquisition Restarted! OFDM Symbol Acquisition Restarted! Cyclic Prefix position = 3963 Cyclic Prefix position = 3979 Cyclic Prefix position = 3995 Cyclic Prefix position = 4010 Cyclic Prefix position = 4025 [... deleted ...] Cyclic Prefix position = 4595 Cyclic Prefix position overflow! OFDM Symbol Acquisition Restarted! Cyclic Prefix position = 3458 At the beginning of both runs the position of the cyclic prefix is 3963. This means, that in both cases the first symbol is detected at the same position. How is it possible that the position of the following symbols differ (e.g. 3978 vs. 3979)? All I did was stopping and restarting the flow graph. As everything in the block is pure and well defined mathematics, when the conditions (data, parameters) do not change, to my understanding the result should always be the same. I may be wrong, but in this case I would like to understand why. Do you have an explanation for me? Thank you very much for your help. Kind regards, Ralf, DL5EU Am 02.03.2020 um 13:42 schrieb Ron Economos: Did you read the README.md of gr-dvbt? It says: /Late note: As of 2015, I donated the gr-dvbt project to gnuradio. It is now integrated in the mainline of gnuradio/gr-dtv./ The OFDM symbol acquisition block in gr-dtv has been upgraded with the fixes from the ISDBT team. See this commit: https://github.com/gnuradio/gnuradio/commit/761b62d4660a121c78b6a7ad17fd7b08badcbb88#diff-aa5858d955a31c6be8746db56ea13c6a However, there is still an issue with the block. It can't tolerate a sample rate difference between the transmitter and receiver. If the difference is large, the block will fail fairly quickly (minutes). I have a test OFDM acquisition block that prints out the drift. It can be found here: https://github.com/drmpeg/gr-dvbtx You may have to go back one commit to make it compile with the latest version of GNU Radio 3.7. Ron On 3/2/20 03:58, Ralf Gorholt wrote: Dear all, please apologize my long email but I cannot explain my problem and what I have done so far in three words. I am currently working on a DVB-T receiver project to receive transmissions on 434 MHz with 2 MHz bandwidth or less using GNU Radio and an RTL-SDR stick. The flow graph is based on the examples in gr-dvbt. The transmitter is a HiDes model HV320E. Reception works, but the video stops after one minute or so while the constellation diagram is still active (dots are moving). I am no expert and have only few knowledge of DSP and DVB yet, but to me the problem seems to be in the OFDM symbol acquisition block. Conditions: Linux Mint 19.3 in a virtual machine (VMware) GNU Radio 3.7.11 if I am right (I would need to check at home) What I have done so far: I have created a flow graph for a DVB-T receiver based on the examples in gr-dvbt. The signal source is an RTL-SDR stick and the sample rate is 16/7 MHz (= 2.285714 MHz) to get 2 MHz bandwidth. The signal sink is a TCP server sink to which
Aw: Re: DVB-T receiver problem (OFDM symbol acquisition)
Dear Ron, my input signal comes from a file and is the same for every test. I also do not change any parameter between tests. If a difference in the sample rate was the cause of the problem, shouldn't the program always fail at exactly the same point (or time)? This is definitely not the case. However, I have some new things to test now. Thank you all very much. Ralf Gesendet: Montag, 02. März 2020 um 14:54 Uhr Von: "Ron Economos" An: discuss-gnuradio@gnu.org Betreff: Re: DVB-T receiver problem (OFDM symbol acquisition) Okay, just making sure since you mentioned gr-dvbt. I'll take a look at the gr-isdbt acquisition block and see if the interpolation method can be ported to GNU Radio. It doesn't take much difference in sample rate to cause the problem. In my setup, I'm using two different Ettus B210's (without GPS locking), and it fails pretty quickly. I can make it run longer by using the test block and manually adjusting the sample rate of one B210. Ron On 3/2/20 05:35, Ralf Gorholt wrote: Dear Ron, thank you very much for your quick answer. I know that Bogdan donated gr-dvbt to GNU radio and I did not install it seperately. It has been installed with GNU Radio using the package manager. The commit you mention seems to be from december 2015, so I suppose it is already in the package but I will check the source code of the installed GNU Radio version when I am back at home. As far as the drift is concerned, I will try your block and see what it prints out. There might be a slight difference because some source blocks accept only integer values as sample rates (if i remember correctly the ADALM PLUTO does), but in my case a sample rate of 16/7 MHz is needed, which is not an integer value. I suppose there is no way to correct a sample rate difference automatically and for small differences resampling won't help either... Kind regards, Ralf (DL5EU) Gesendet: Montag, 02. März 2020 um 13:42 Uhr Von: "Ron Economos" An: discuss-gnuradio@gnu.org Betreff: Re: DVB-T receiver problem (OFDM symbol acquisition) Did you read the README.md of gr-dvbt? It says: Late note: As of 2015, I donated the gr-dvbt project to gnuradio. It is now integrated in the mainline of gnuradio/gr-dtv. The OFDM symbol acquisition block in gr-dtv has been upgraded with the fixes from the ISDBT team. See this commit: https://github.com/gnuradio/gnuradio/commit/761b62d4660a121c78b6a7ad17fd7b08badcbb88#diff-aa5858d955a31c6be8746db56ea13c6a However, there is still an issue with the block. It can't tolerate a sample rate difference between the transmitter and receiver. If the difference is large, the block will fail fairly quickly (minutes). I have a test OFDM acquisition block that prints out the drift. It can be found here: https://github.com/drmpeg/gr-dvbtx You may have to go back one commit to make it compile with the latest version of GNU Radio 3.7. Ron On 3/2/20 03:58, Ralf Gorholt wrote: Dear all, please apologize my long email but I cannot explain my problem and what I have done so far in three words. I am currently working on a DVB-T receiver project to receive transmissions on 434 MHz with 2 MHz bandwidth or less using GNU Radio and an RTL-SDR stick. The flow graph is based on the examples in gr-dvbt. The transmitter is a HiDes model HV320E. Reception works, but the video stops after one minute or so while the constellation diagram is still active (dots are moving). I am no expert and have only few knowledge of DSP and DVB yet, but to me the problem seems to be in the OFDM symbol acquisition block. Conditions: Linux Mint 19.3 in a virtual machine (VMware) GNU Radio 3.7.11 if I am right (I would need to check at home) What I have done so far: I have created a flow graph for a DVB-T receiver based on the examples in gr-dvbt. The signal source is an RTL-SDR stick and the sample rate is 16/7 MHz (= 2.285714 MHz) to get 2 MHz bandwidth. The signal sink is a TCP server sink to which I connect with VLC media player to display the received video transport stream. This works, but after one minute or so the video stops while the constellation diagram is still active (dots are moving). I am currently using QPSK, code rate 3/4 and guard interval 1/8 but I have also tried 16QAM, code rate 1/2 and guard interval 1/8 and have the same problem. To track down the source of the problem, I have created a file outside of GNU Radio that I can use in a file source instead of the RTL-SDR source of my flow graph. This allows me to make tests with an input signal that does not change between different tests. The data of this file are sent to the OFDM symbol acquisition block and the output of this block is stored in a second file. When the input signal, the algorithm and the parameters do not change between different tests I expect the generated file to be always the same. However, this is not the case. The files that are g
Re: DVB-T receiver problem (OFDM symbol acquisition)
Dear Marcus, Thank you too for your quick answer. I am struggling with GNU Radio since the end of last year but it's getting better :-) The reason why I still use version 3.7 is that it is included in LinuxMint 19.3 and offers source blocks for RTL-SDR sticks and the ADALM PLUTO (I have both devices). I am not familiar with building and installing software on Linux from the sources. I had installed GNU Radio 3.8.1 for testing but some source blocks were missing so I went back to 3.7. However, since yesterday I know how I can build blocks myself (I did it with gr-isdbt), so I will try version 3.8 again. I am looking for a simple and reproductible solution that other people are able to use without too much effort, because not every HAM is a software or Linux guru and most of the people I know prefer Windows, but that is another point. It is difficult to change habits. First I need something that works reliably. To come back to Rons mail, if a difference in the sample rates of TX and RX caused the problem, shouldn't the program always fail at exactly the same point (time) because the input data and start conditions do not change? This is not the case. To mention something that just comes back to my mind: as far as I can see, the first difference in the files is always at a 16k boundary (0x8000, 0xc000, 0x14000, ...) but this might be a coincidence. Kind regards, Ralf (DL5EU) Gesendet: Montag, 02. März 2020 um 13:57 Uhr Von: "Müller, Marcus (CEL)" An: "ralf.gorh...@gmx.de" , "discuss-gnuradio@gnu.org" Betreff: Re: DVB-T receiver problem (OFDM symbol acquisition) Hi Ralf, wow, thanks for the extensive mail! Can't process it right now (at work), but a few quick notes: * 3.7.11 is rather oldish, and upgrading to GNU Radio 3.8 would definitely be a good idea. In fact, on the current development version of GNU Radio, we even have enabled a few optimizations that make things /much much faster/. * Your debugging based on a file is on-point, excellent work * I also expect the output of the OFDM symbol acquisition to be constant. That might be a bug we fixed when we moved to GNU Radio 3.8 * All in all, if you're really still running GNU Radio 3.7, it'd be worth just trying with Debian Testing, which comes with our latest release, or at least debian stable / buster, which comes with 3.8.0.0 Best regards, Marcus On Mon, 2020-03-02 at 12:58 +0100, Ralf Gorholt wrote: > Dear all, > > please apologize my long email but I cannot explain my problem and what I have done so far in three words. > > I am currently working on a DVB-T receiver project to receive transmissions on 434 MHz with 2 MHz bandwidth or less using GNU Radio and an RTL-SDR stick. The flow graph is based on the examples in gr-dvbt. The transmitter is a HiDes model HV320E. Reception works, but the video stops after one minute or so while the constellation diagram is still active (dots are moving). I am no expert and have only few knowledge of DSP and DVB yet, but to me the problem seems to be in the OFDM symbol acquisition block. > > Conditions: > Linux Mint 19.3 in a virtual machine (VMware) > GNU Radio 3.7.11 if I am right (I would need to check at home) > > What I have done so far: > > I have created a flow graph for a DVB-T receiver based on the examples in gr-dvbt. The signal source is an RTL-SDR stick and the sample rate is 16/7 MHz (= 2.285714 MHz) to get 2 MHz bandwidth. The signal sink is a TCP server sink to which I connect with VLC media player to display the received video transport stream. This works, but after one minute or so the video stops while the constellation diagram is still active (dots are moving). I am currently using QPSK, code rate 3/4 and guard interval 1/8 but I have also tried 16QAM, code rate 1/2 and guard interval 1/8 and have the same problem. > > To track down the source of the problem, I have created a file outside of GNU Radio that I can use in a file source instead of the RTL-SDR source of my flow graph. This allows me to make tests with an input signal that does not change between different tests. > > The data of this file are sent to the OFDM symbol acquisition block and the output of this block is stored in a second file. When the input signal, the algorithm and the parameters do not change between different tests I expect the generated file to be always the same. However, this is not the case. The files that are generated with the output of the OFDM symbol acquisition block differ from each other. But when I send the content of one of those generated files to the rest of the receiver and do this several times, I always get the same transport stream at the output. I have verified this by using a file sink and comparing the files. That’s why I suspect the OFDM symbol acquisition block to be the culprit. > > When I was searching the internet for information concerning my
Re: DVB-T receiver problem (OFDM symbol acquisition)
Dear Ron, thank you very much for your quick answer. I know that Bogdan donated gr-dvbt to GNU radio and I did not install it seperately. It has been installed with GNU Radio using the package manager. The commit you mention seems to be from december 2015, so I suppose it is already in the package but I will check the source code of the installed GNU Radio version when I am back at home. As far as the drift is concerned, I will try your block and see what it prints out. There might be a slight difference because some source blocks accept only integer values as sample rates (if i remember correctly the ADALM PLUTO does), but in my case a sample rate of 16/7 MHz is needed, which is not an integer value. I suppose there is no way to correct a sample rate difference automatically and for small differences resampling won't help either... Kind regards, Ralf (DL5EU) Gesendet: Montag, 02. März 2020 um 13:42 Uhr Von: "Ron Economos" An: discuss-gnuradio@gnu.org Betreff: Re: DVB-T receiver problem (OFDM symbol acquisition) Did you read the README.md of gr-dvbt? It says: Late note: As of 2015, I donated the gr-dvbt project to gnuradio. It is now integrated in the mainline of gnuradio/gr-dtv. The OFDM symbol acquisition block in gr-dtv has been upgraded with the fixes from the ISDBT team. See this commit: https://github.com/gnuradio/gnuradio/commit/761b62d4660a121c78b6a7ad17fd7b08badcbb88#diff-aa5858d955a31c6be8746db56ea13c6a However, there is still an issue with the block. It can't tolerate a sample rate difference between the transmitter and receiver. If the difference is large, the block will fail fairly quickly (minutes). I have a test OFDM acquisition block that prints out the drift. It can be found here: https://github.com/drmpeg/gr-dvbtx You may have to go back one commit to make it compile with the latest version of GNU Radio 3.7. Ron On 3/2/20 03:58, Ralf Gorholt wrote: Dear all, please apologize my long email but I cannot explain my problem and what I have done so far in three words. I am currently working on a DVB-T receiver project to receive transmissions on 434 MHz with 2 MHz bandwidth or less using GNU Radio and an RTL-SDR stick. The flow graph is based on the examples in gr-dvbt. The transmitter is a HiDes model HV320E. Reception works, but the video stops after one minute or so while the constellation diagram is still active (dots are moving). I am no expert and have only few knowledge of DSP and DVB yet, but to me the problem seems to be in the OFDM symbol acquisition block. Conditions: Linux Mint 19.3 in a virtual machine (VMware) GNU Radio 3.7.11 if I am right (I would need to check at home) What I have done so far: I have created a flow graph for a DVB-T receiver based on the examples in gr-dvbt. The signal source is an RTL-SDR stick and the sample rate is 16/7 MHz (= 2.285714 MHz) to get 2 MHz bandwidth. The signal sink is a TCP server sink to which I connect with VLC media player to display the received video transport stream. This works, but after one minute or so the video stops while the constellation diagram is still active (dots are moving). I am currently using QPSK, code rate 3/4 and guard interval 1/8 but I have also tried 16QAM, code rate 1/2 and guard interval 1/8 and have the same problem. To track down the source of the problem, I have created a file outside of GNU Radio that I can use in a file source instead of the RTL-SDR source of my flow graph. This allows me to make tests with an input signal that does not change between different tests. The data of this file are sent to the OFDM symbol acquisition block and the output of this block is stored in a second file. When the input signal, the algorithm and the parameters do not change between different tests I expect the generated file to be always the same. However, this is not the case. The files that are generated with the output of the OFDM symbol acquisition block differ from each other. But when I send the content of one of those generated files to the rest of the receiver and do this several times, I always get the same transport stream at the output. I have verified this by using a file sink and comparing the files. That’s why I suspect the OFDM symbol acquisition block to be the culprit. When I was searching the internet for information concerning my problem, I found an email from 2015 in the archive of this mailing list where someone wrote that the OFDM symbol acquisition block of gr-isdbt should be used because it worked better than the one in gr-dvbt. I have done so and installed gr-isdbt from git and replaced the block. However, there are two such blocks in gr-isdbt and none of them solves my problem. They perform even worse than the original block in gr-dvbt and after some time the program terminates without a message. I hope that my explanations are clear enough. Is there anybody who can tell me what might be wrong here or what I am doing wron
DVB-T receiver problem (OFDM symbol acquisition)
Dear all, please apologize my long email but I cannot explain my problem and what I have done so far in three words. I am currently working on a DVB-T receiver project to receive transmissions on 434 MHz with 2 MHz bandwidth or less using GNU Radio and an RTL-SDR stick. The flow graph is based on the examples in gr-dvbt. The transmitter is a HiDes model HV320E. Reception works, but the video stops after one minute or so while the constellation diagram is still active (dots are moving). I am no expert and have only few knowledge of DSP and DVB yet, but to me the problem seems to be in the OFDM symbol acquisition block. Conditions: Linux Mint 19.3 in a virtual machine (VMware) GNU Radio 3.7.11 if I am right (I would need to check at home) What I have done so far: I have created a flow graph for a DVB-T receiver based on the examples in gr-dvbt. The signal source is an RTL-SDR stick and the sample rate is 16/7 MHz (= 2.285714 MHz) to get 2 MHz bandwidth. The signal sink is a TCP server sink to which I connect with VLC media player to display the received video transport stream. This works, but after one minute or so the video stops while the constellation diagram is still active (dots are moving). I am currently using QPSK, code rate 3/4 and guard interval 1/8 but I have also tried 16QAM, code rate 1/2 and guard interval 1/8 and have the same problem. To track down the source of the problem, I have created a file outside of GNU Radio that I can use in a file source instead of the RTL-SDR source of my flow graph. This allows me to make tests with an input signal that does not change between different tests. The data of this file are sent to the OFDM symbol acquisition block and the output of this block is stored in a second file. When the input signal, the algorithm and the parameters do not change between different tests I expect the generated file to be always the same. However, this is not the case. The files that are generated with the output of the OFDM symbol acquisition block differ from each other. But when I send the content of one of those generated files to the rest of the receiver and do this several times, I always get the same transport stream at the output. I have verified this by using a file sink and comparing the files. That’s why I suspect the OFDM symbol acquisition block to be the culprit. When I was searching the internet for information concerning my problem, I found an email from 2015 in the archive of this mailing list where someone wrote that the OFDM symbol acquisition block of gr-isdbt should be used because it worked better than the one in gr-dvbt. I have done so and installed gr-isdbt from git and replaced the block. However, there are two such blocks in gr-isdbt and none of them solves my problem. They perform even worse than the original block in gr-dvbt and after some time the program terminates without a message. I hope that my explanations are clear enough. Is there anybody who can tell me what might be wrong here or what I am doing wrong? Why is the output of the OFDM symbol acquisition block not always the same when the start condition of every run is the same? Am I missing something here? Thank you very much for your help. Kind regards, Ralf
[Discuss-gnuradio] E100 and HDMI
Hi, so far we used our E100s via LAN from Remote. Now we connected HDMI locally by using an HDMI-to-DVI apapter and a DELL DVI display. Nothing is displayed, no boot text, no X output. X server seems to run on the E100 utilizing OMAPFB... Should it work by default? Any hints for us? Thanks! Ralf ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] E100 Performance
Am 29.06.2011 16:34, schrieb Marcus D. Leech: On 29/06/2011 9:11 AM, Ralf wrote: Hi, the simple GRC in the attachment creates lots of underflows on our E100 ("U" on console) and dropouts when looking at the spectrum. Is this as expected or how can this overload of the embedded Linux be avoided? Thanks, Ralf Well, for one, 60Khz isn't a proper divisor of the 128MHz sample rate of the DAC, which means it can't be properly interpolated. The minimum sample rate that you can deliver to the USRP-E100 is 128MHz/512 = 250kHz, so you'll have to interpolate your data stream up to 250kHz prior to "presentation" to the UHD sink block. Hi Marcus, thanks for your reply. That is very important for us to understand. How is the divider 512 determined? It is in the FPGA I suppose. Where can read more about the FPGA besides this small text? http://www.gnu.org/software/gnuradio/doc/exploring-gnuradio.html#fpga Can we only put proper divisors of 128MHz in terms of datarate into the UHD sink even above 250kHz? Actually we need to put ~10kbit/s of data onto a ~400kHz carrier. Is the GRC repeater the right functionality to interpolate the small datarate as shown in the attached setup? Regards, Ralf Thu Jun 30 11:09:05 2011 options id tx _enabled True title author description window_size 1280, 1024 generate_options qt_gui category Custom run_options prompt run True realtime_scheduling _coordinate (10, 10) _rotation 0 blks2_dxpsk_mod id blks2_dxpsk_mod_0 _enabled True type dqpsk samples_per_symbol 4 excess_bw 0.35 gray_code True verbose False log False _coordinate (313, 259) _rotation 0 random_source_x id random_source_x_0 _enabled True type byte min 0 max 255 num_samps 10 repeat True _coordinate (73, 259) _rotation 0 uhd_usrp_source id uhd_usrp_source_0 _enabled True type complex dev_addr ref_clk sync clock_rate 0.0 num_mboards 1 sd_spec0 sd_spec1 sd_spec2 sd_spec3 nchan 1 samp_rate 100 center_freq0 0 gain0 0 ant0 bw0 0 center_freq1 0 gain1 0 ant1 bw1 0 center_freq2 0 gain2 0 ant2 bw2 0 center_freq3 0 gain3 0 ant3 bw3 0 center_freq4 0 gain4 0 ant4 bw4 0 center_freq5 0 gain5 0 ant5 bw5 0 center_freq6 0 gain6 0 ant6 bw6 0 center_freq7 0 gain7 0 ant7 bw7 0 center_freq8 0 gain8 0 ant8 bw8 0 center_freq9 0 gain9 0 ant9 bw9 0 center_freq10 0 gain10 0 ant10 bw10 0 center_freq11 0 gain11 0 ant11 bw11 0 center_freq12 0 gain12 0 ant12 bw12 0 center_freq13 0 gain13 0 ant13 bw13 0 center_freq14 0 gain14 0 ant14 bw14 0 center_freq15 0 gain15 0 ant15
[Discuss-gnuradio] DPSK2 Demodulator
Hi, we are trying to use DPSK2 modulator and demodulator during our first trials. As far as we can see there is hardly any documentation available on this. We would appreciate a few explaining words from somebody who knows how to configure the demodulator so that data is correctly received. What synchronization method(s) is/are included? Raised-cosine-filter for matched filtering seems to be included? We tried like this with no success: Modulator: Type: DQPSK Sample/Symbol: 2 Excess BW: 0.35 GrayCode: YES Verbose: OFF Logging: OFF Demodulator: Sample/Symbol: 2 Excess BW: 0.35 FLL Alpha: 0.01 Phase Alpha: 0.1 Timing Max Dev: 1.5 Omega Relative Limit: 0.005 GrayCode: YES Verbose: OFF Logging: OFF Sync Out: ON Thanks in advance! Ralf ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] E100 Performance
Hi, the simple GRC in the attachment creates lots of underflows on our E100 ("U" on console) and dropouts when looking at the spectrum. Is this as expected or how can this overload of the embedded Linux be avoided? Thanks, Ralf Wed Jun 29 14:59:09 2011 uhd_usrp_sink id uhd_usrp_sink_0 _enabled True type complex dev_addr ref_clk sync clock_rate 0.0 num_mboards 1 sd_spec0 :A sd_spec1 sd_spec2 sd_spec3 nchan 1 samp_rate samp_rate center_freq0 40 gain0 3 ant0 bw0 0 center_freq1 0 gain1 0 ant1 bw1 0 center_freq2 0 gain2 0 ant2 bw2 0 center_freq3 0 gain3 0 ant3 bw3 0 center_freq4 0 gain4 0 ant4 bw4 0 center_freq5 0 gain5 0 ant5 bw5 0 center_freq6 0 gain6 0 ant6 bw6 0 center_freq7 0 gain7 0 ant7 bw7 0 center_freq8 0 gain8 0 ant8 bw8 0 center_freq9 0 gain9 0 ant9 bw9 0 center_freq10 0 gain10 0 ant10 bw10 0 center_freq11 0 gain11 0 ant11 bw11 0 center_freq12 0 gain12 0 ant12 bw12 0 center_freq13 0 gain13 0 ant13 bw13 0 center_freq14 0 gain14 0 ant14 bw14 0 center_freq15 0 gain15 0 ant15 bw15 0 _coordinate (828, 246) _rotation 0 gr_multiply_const_vxx id gr_multiply_const_vxx_0 _enabled True type complex const 0.1 vlen 1 _coordinate (635, 263) _rotation 0 options id tx _enabled True title author description window_size 1280, 1024 generate_options qt_gui category Custom run_options prompt run True realtime_scheduling _coordinate (10, 10) _rotation 0 blks2_dxpsk_mod id blks2_dxpsk_mod_0 _enabled True type dqpsk samples_per_symbol 4 excess_bw 0.35 gray_code True verbose False log False _coordinate (425, 238) _rotation 0 random_source_x id random_source_x_0 _enabled True type byte min 0 max 255 num_samps 10 repeat True _coordinate (183, 239) _rotation 0 variable id samp_rate _enabled True value 6 _coordinate (10, 170) _rotation 0 random_source_x_0 blks2_dxpsk_mod_0 0 0 gr_multiply_const_vxx_0 uhd_usrp_sink_0 0 0 blks2_dxpsk_mod_0 gr_multiply_const_vxx_0 0 0 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] E100 - No devices found for ----->
Hi Josh, today we managed to make UHD sink and source work in parallel on E100 using FPGA5.bin by building UHD like this: git clone git://code.ettus.com/ettus/uhd.git cd uhd git pull git://code.ettus.com/ettus/uhd.git next cd host/ $ mkdir build $ cd build $ cmake -DCMAKE_CXX_FLAGS:STRING="-mcpu=cortex-a8 -mfpu=neon -mfloat-abi=softfp -g" -DENABLE_USRP_E100=TRUE -DENABLE_USRP_E_UTILS=TRUE -i ../ $ make $ make test $ make install $ ldconfig Please bear in mind that we are absolute beginners to Gnuradio and E100. We started one week ago. Some more precise information really helps!! However, your help is appreciated! Thanks, Ralf Am 27.06.2011 18:50, schrieb Josh Blum: we don't manage wih the E100 FPGA5 bitstream. It is placed in the images directory and we use a new branch but we don't really think the FPGA5 is used. What do you mean? And we still have the same problem with parallel UHD devices (sink/source). Another guy confirmed it was working for him just fine. In any case, I think it will also work if you patch this onto the master branch (very small change): http://pastebin.com/JinMRTTD Which branch shall we use? Can you pinpoint exactly? Shall we use the Josh branch from http://gnuradio.org/cgit ? For gnuradio? The master branch on gnuradio.org is fine. Do you have images available? We still don't have a cross-compile env. yet. Hence compilation takes very long time... Yes :-) http://code.ettus.com/redmine/ettus/projects/usrpe1xx/wiki/Experimental_Images Another topic we recognized on E100 is that we suspect incomplete datastreams when the Gumstix is overloaded performancewise. I will come back with details on our transmitter setup which might cause overloads. But - is it possible to overload the 720MHz Gumstix easily? What happens in this case - samples are discarded? On receive, the host backpressures the FPGA. See http://www.ettus.com/uhd_docs/manual/html/general.html#overflow-underflow-notes -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] E100 - No devices found for ----->
> -Original Message- > From: discuss-gnuradio-bounces+r.wierse=brunel...@gnu.org > [mailto:discuss-gnuradio-bounces+r.wierse=brunel...@gnu.org] > On Behalf Of Josh Blum > Sent: Thursday, June 23, 2011 5:35 PM > To: discuss-gnuradio@gnu.org > Subject: Re: [Discuss-gnuradio] E100 - No devices found for -> > > > > > On 06/23/2011 03:16 AM, Ralf Wierse wrote: > > OK, first simple reason discovered. > > UHD can only be used for one device - either UHD_usrp_sink > or source. > > > > How can UHD be used for both devices in parallel? > > > > Sorry, Its a known bug related to opening twice. Its fixed on the next > branch. Solution w/ instructions: > http://comments.gmane.org/gmane.comp.hardware.usrp.e100/754 > > -Josh Hi Josh, we don't manage wih the E100 FPGA5 bitstream. It is placed in the images directory and we use a new branch but we don't really think the FPGA5 is used. And we still have the same problem with parallel UHD devices (sink/source). Which branch shall we use? Can you pinpoint exactly? Shall we use the Josh branch from http://gnuradio.org/cgit ? Do you have images available? We still don't have a cross-compile env. yet. Hence compilation takes very long time... Another topic we recognized on E100 is that we suspect incomplete datastreams when the Gumstix is overloaded performancewise. I will come back with details on our transmitter setup which might cause overloads. But - is it possible to overload the 720MHz Gumstix easily? What happens in this case - samples are discarded? Regards, Ralf ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] E100 - No devices found for ----->
> -Original Message- > From: Jason Abele [mailto:ja...@ettus.com] > Sent: Thursday, June 23, 2011 5:29 PM > To: Ralf Wierse > Cc: discuss-gnuradio@gnu.org > Subject: Re: [Discuss-gnuradio] E100 - No devices found for -> > > > On Thu, Jun 23, 2011 at 5:32 AM, Ralf Wierse > wrote: > >> -Original Message- > >> From: Jason Abele [mailto:ja...@ettus.com] > >> Sent: Thursday, June 23, 2011 1:04 PM > >> To: Ralf Wierse > >> Cc: discuss-gnuradio Discussion Group > >> Subject: Re: [Discuss-gnuradio] E100 - No devices found for -> > >> > >> > >> On Thu, Jun 23, 2011 at 3:16 AM, Ralf Wierse > >> wrote: > >> > OK, first simple reason discovered. > >> > UHD can only be used for one device - either UHD_usrp_sink > >> or source. > >> > > >> > How can UHD be used for both devices in parallel? > >> > >> You have to access both source and sink from the same process, but > >> then it is possible to use both at the same time. > >> > >> Jason > > > > > > Hi Jason, > > thanks but I am a little confused. > > I would say it is in the same process since I have sink and > source in the same > > GRC setup. The failure shows up when the generated python > script instantiates an > > UHD devices the second time as far as I understand. > > Is there any combined UHD_usrp_sink/source block for GRC or > how is this to > > be done practically? > > Can you send the simplest .grc file which causes this issue? > > Jason Hi Jason, Josh wrote to use the latest branch. This one is still building since we don't have any cross compile environment yet... However, attached is a GRC setup which fails due to parallel use of two UHD devices. Well, this is very simple. Hope the parallel issue is fixed using the latest branch. If not, we appreciate more support. Regards, Ralf parallel.py Description: Binary data parallel.grc Description: Binary data <<< Welcome to GNU Radio Companion >>> Loading: "/home/root/spec_analyzer.grc" >>> Done Showing: "/home/root/spec_analyzer.grc" Loading: "/home/root/audio_test.grc" >>> Done Loading: "/home/root/simple.grc" >>> Done Loading: "/home/root/examples/grc/usrp/usrp_rx_dpsk.grc" >>> Done Loading: "/home/root/test.grc" >>> Done Loading: "/home/root/test2.grc" >>> Done Loading: "/home/root/sender2.grc" >>> Done Showing: "/home/root/sender2.grc" Showing: "" Showing: "/home/root/simple.grc" Showing: "/home/root/test.grc" Showing: "/home/root/sender2.grc" Showing: "" Generating: "/mnt/UHD-Mirror/host/parallel.py" Executing: "/mnt/UHD-Mirror/host/parallel.py" >>> Done Generating: "/mnt/UHD-Mirror/host/parallel.py" Executing: "/mnt/UHD-Mirror/host/parallel.py" linux; GNU C++ version 4.5.3 20110311 (prerelease); Boost_104500; UHD_003.000.001- QIconvCodec::convertFromUnicode: using Latin-1 for conversion, iconv failed for BOM: Bad file descriptor QIconvCodec::convertFromUnicode: using Latin-1 for conversion, iconv_open failed QIconvCodec::convertToUnicode: using Latin-1 for conversion, iconv_open failed Opening USRP-E on /dev/usrp_e0 USRP-E100 clock control: 6 r_counter: 1 a_counter: 0 b_counter: 12 prescaler: 8 vco_divider: 2 chan_divider: 15 vco_rate: 1920.00MHz chan_rate: 960.00MHz out_rate: 64.00MHz Warning: Ignoring discovered device EnvironmentError: IOError: Failed to open /dev/usrp_e0 Traceback (most recent call last): File "/mnt/UHD-Mirror/host/parallel.py", line 89, in tb = parallel() File "/mnt/UHD-Mirror/host/parallel.py", line 49, in __init__ num_channels=1, File "/usr/local/lib/python2.6/site-packages/gnuradio/uhd/__init__.py", line 74, in constructor_interceptor return old_constructor(*args, **kwargs) File "/usr/local/lib/python2.6/site-packages/gnuradio/uhd/uhd_swig.py", line 1854, in usrp_sink return _uhd_swig.usrp_sink(*args, **kwargs) RuntimeError: LookupError: KeyError: No devices found for -> Empty Device Address >>> Done ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] E100 - No devices found for ----->
> -Original Message- > From: Jason Abele [mailto:ja...@ettus.com] > Sent: Thursday, June 23, 2011 1:04 PM > To: Ralf Wierse > Cc: discuss-gnuradio Discussion Group > Subject: Re: [Discuss-gnuradio] E100 - No devices found for -> > > > On Thu, Jun 23, 2011 at 3:16 AM, Ralf Wierse > wrote: > > OK, first simple reason discovered. > > UHD can only be used for one device - either UHD_usrp_sink > or source. > > > > How can UHD be used for both devices in parallel? > > You have to access both source and sink from the same process, but > then it is possible to use both at the same time. > > Jason Hi Jason, thanks but I am a little confused. I would say it is in the same process since I have sink and source in the same GRC setup. The failure shows up when the generated python script instantiates an UHD devices the second time as far as I understand. Is there any combined UHD_usrp_sink/source block for GRC or how is this to be done practically? Thanks Ralf ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] E100 - No devices found for ----->
> -Original Message- > From: Jason Abele [mailto:ja...@ettus.com] > Sent: Thursday, June 23, 2011 1:04 PM > To: Ralf Wierse > Cc: discuss-gnuradio Discussion Group > Subject: Re: [Discuss-gnuradio] E100 - No devices found for -> > > > On Thu, Jun 23, 2011 at 3:16 AM, Ralf Wierse > wrote: > > OK, first simple reason discovered. > > UHD can only be used for one device - either UHD_usrp_sink > or source. > > > > How can UHD be used for both devices in parallel? > > You have to access both source and sink from the same process, but > then it is possible to use both at the same time. > > Jason Hi Jason, thanks but I am a little confused. I would say it is in the same process since I have sink and source in the same GRC setup. The failure shows up when the generated python script instantiates an UHD devices the second time as far as I understand. Is there any combined UHD_usrp_sink/source block for GRC or how is this to be done practically? Thanks Ralf ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] E100 - No devices found for ----->
OK, first simple reason discovered. UHD can only be used for one device - either UHD_usrp_sink or source. How can UHD be used for both devices in parallel? Thanks, Ralf > -Original Message- > From: discuss-gnuradio-bounces+r.wierse=brunel...@gnu.org > [mailto:discuss-gnuradio-bounces+r.wierse=brunel...@gnu.org] > On Behalf Of Ralf Wierse > Sent: Thursday, June 23, 2011 10:29 AM > To: 'discuss-gnuradio Discussion Group' > Subject: [Discuss-gnuradio] E100 - No devices found for -> > > > Hi all, > > we are new with E100. > > we managed to use UHD:USRP_Source without further > configuration and display > it on QT_GUI_SINK. > > we don't manage with UHD:USRP_Sink without further configuration: > > File > "/usr/local/lib/python2.6/site-packages/gnuradio/uhd/uhd_swig. > py", line 1854, in usrp_sink > return _uhd_swig.usrp_sink(*args, **kwargs) > RuntimeError: LookupError: KeyError: No devices found for -> > Empty Device Address > > How to configure the sink address? > > Any help appreciated! > thanks! > Ralf > > uhd_usrp_probe output: > > linux; GNU C++ version 4.5.3 20110311 (prerelease); > Boost_104500; UHD_003.000.001- > > Opening USRP-E on /dev/usrp_e0 > Loading FPGA image: > /usr/share/uhd/images/usrp_e100_fpga.bin... done = 1 > Configuration complete. > re-Opening USRP-E on /dev/usrp_e0 > USRP-E100 clock control: 6 > r_counter: 1 > a_counter: 0 > b_counter: 12 > prescaler: 8 > vco_divider: 2 > chan_divider: 15 > vco_rate: 1920.00MHz > chan_rate: 960.00MHz > out_rate: 64.00MHz > > _ > / > | Device: usrp-e device > | _ > |/ > | | Mboard: usrp-e mboard > | | vendor: 3 > | | device: 1 > | | revision: 3 > | | content: 0 > | | model: E100 > | | serial: EAR10ZFE1 > | | _ > | |/ > | | | RX DSP: usrp-e ddc0 > | | | Codec Rate: 64.00 Msps > | | _ > | |/ > | | | TX DSP: usrp-e duc0 > | | | Codec Rate: 64.00 Msps > | | _ > | |/ > | | | RX Dboard: usrp-e dboard (rx unit) > | | | _ > | | |/ > | | | | RX Subdev: LF RX (0x000f) - AB > | | | | Antennas: > | | | | Freq range: -32.000 to 32.000 Mhz > | | | | Gain Elements: None > | | | | Connection Type: C > | | | | Uses LO offset: No > | | | _ > | | |/ > | | | | RX Subdev: LF RX (0x000f) - BA > | | | | Antennas: > | | | | Freq range: -32.000 to 32.000 Mhz > | | | | Gain Elements: None > | | | | Connection Type: c > | | | | Uses LO offset: No > | | | _ > | | |/ > | | | | RX Subdev: LF RX (0x000f) - A > | | | | Antennas: > | | | | Freq range: -32.000 to 32.000 Mhz > | | | | Gain Elements: None > | | | | Connection Type: R > | | | | Uses LO offset: No > | | | _ > | | |/ > | | | | RX Subdev: LF RX (0x000f) - B > | | | | Antennas: > | | | | Freq range: -32.000 to 32.000 Mhz > | | | | Gain Elements: None > | | | | Connection Type: r > | | | | Uses LO offset: No > | | | _ > | | |/ > | | | | RX Codec: usrp-e adc - ad9522 > | | | | Gain range ad9862 pga: 0.0 to 20.0 step 1.0 dB > | | _ > | |/ > | | | TX Dboard: usrp-e dboard (tx unit) > | | | _ > | | |/ > | | | | TX Subdev: LF TX (0x000e) - AB > | | | | Antennas: > | | | | Freq range: -32.000 to 32.000 Mhz > | | | | Gain Elements: None > | | | | Connection Type: C > | | | | Uses LO offset: No > | | | _ > | | |/ > | | | | TX Subdev: LF TX (0x000e) - BA > | | | | Antennas: > | | | | Freq range: -32.000 to 32
[Discuss-gnuradio] E100 - No devices found for ----->
Hi all, we are new with E100. we managed to use UHD:USRP_Source without further configuration and display it on QT_GUI_SINK. we don't manage with UHD:USRP_Sink without further configuration: File "/usr/local/lib/python2.6/site-packages/gnuradio/uhd/uhd_swig.py", line 1854, in usrp_sink return _uhd_swig.usrp_sink(*args, **kwargs) RuntimeError: LookupError: KeyError: No devices found for -> Empty Device Address How to configure the sink address? Any help appreciated! thanks! Ralf uhd_usrp_probe output: linux; GNU C++ version 4.5.3 20110311 (prerelease); Boost_104500; UHD_003.000.001- Opening USRP-E on /dev/usrp_e0 Loading FPGA image: /usr/share/uhd/images/usrp_e100_fpga.bin... done = 1 Configuration complete. re-Opening USRP-E on /dev/usrp_e0 USRP-E100 clock control: 6 r_counter: 1 a_counter: 0 b_counter: 12 prescaler: 8 vco_divider: 2 chan_divider: 15 vco_rate: 1920.00MHz chan_rate: 960.00MHz out_rate: 64.00MHz _ / | Device: usrp-e device | _ |/ | | Mboard: usrp-e mboard | | vendor: 3 | | device: 1 | | revision: 3 | | content: 0 | | model: E100 | | serial: EAR10ZFE1 | | _ | |/ | | | RX DSP: usrp-e ddc0 | | | Codec Rate: 64.00 Msps | | _ | |/ | | | TX DSP: usrp-e duc0 | | | Codec Rate: 64.00 Msps | | _ | |/ | | | RX Dboard: usrp-e dboard (rx unit) | | | _ | | |/ | | | | RX Subdev: LF RX (0x000f) - AB | | | | Antennas: | | | | Freq range: -32.000 to 32.000 Mhz | | | | Gain Elements: None | | | | Connection Type: C | | | | Uses LO offset: No | | | _ | | |/ | | | | RX Subdev: LF RX (0x000f) - BA | | | | Antennas: | | | | Freq range: -32.000 to 32.000 Mhz | | | | Gain Elements: None | | | | Connection Type: c | | | | Uses LO offset: No | | | _ | | |/ | | | | RX Subdev: LF RX (0x000f) - A | | | | Antennas: | | | | Freq range: -32.000 to 32.000 Mhz | | | | Gain Elements: None | | | | Connection Type: R | | | | Uses LO offset: No | | | _ | | |/ | | | | RX Subdev: LF RX (0x000f) - B | | | | Antennas: | | | | Freq range: -32.000 to 32.000 Mhz | | | | Gain Elements: None | | | | Connection Type: r | | | | Uses LO offset: No | | | _ | | |/ | | | | RX Codec: usrp-e adc - ad9522 | | | | Gain range ad9862 pga: 0.0 to 20.0 step 1.0 dB | | _ | |/ | | | TX Dboard: usrp-e dboard (tx unit) | | | _ | | |/ | | | | TX Subdev: LF TX (0x000e) - AB | | | | Antennas: | | | | Freq range: -32.000 to 32.000 Mhz | | | | Gain Elements: None | | | | Connection Type: C | | | | Uses LO offset: No | | | _ | | |/ | | | | TX Subdev: LF TX (0x000e) - BA | | | | Antennas: | | | | Freq range: -32.000 to 32.000 Mhz | | | | Gain Elements: None | | | | Connection Type: c | | | | Uses LO offset: No | | | _ | | |/ | | | | TX Subdev: LF TX (0x000e) - A | | | | Antennas: | | | | Freq range: -32.000 to 32.000 Mhz | | | | Gain Elements: None | | | | Connection Type: R | | | | Uses LO offset: No | | | _ | | |/ | | | | TX Subdev: LF TX (0x000e) - B | | | | Antennas: | | | | Freq range: -32.000 to 32.000 Mhz | | | | Gain Elements: None | | | | Connection Type: r | | | | Uses LO offset: No | | | _ | | |/ | | | | TX Codec: usrp-e dac - ad9522 | | | | Gain range ad9862 pga: -20.0 to 0.0 step 0.1 dB ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Freelancer wanted - LF Transmission with Gnuradio/USRP
Dear all, I got three times positive feedback on my beginners questions below. Hence, I am pretty positive myself that my plan is feasible. Today I started to use GRC... This time I would like to ask if there is a freelancer out there intersted in helping us out. This year we have so many projects that we don't really manage to design another prototype as described below even if it is based on ready hardware. I am asking for help in these topics: 1) setting up a basic GnuRadio structure (RX and TX) to enable us trying around with different simple modulation schemes at different frequencies. 2) Designing simple analogue front ends for RX and TX with some possibility to vary the transmit power to be used up to 1MHz or some MHz to be connected to Ettus equipment. Should be fun I suppose! It would simplify things if YOU were resident in Europe or better Germany but I appreciate answers from the US or elsewhere as well. For number 2) above it is not absotuley necessary to create the hardware. Design and component selection would help as well. If you are interested please contact me directly and we can talk about details. Best regards, Ralf I don't really dare to type any email adress here to avoid spam and address crawlers... http://tinyurl.com/5ths4yq +49 5121 1760 707 > -Original Message- > From: discuss-gnuradio-bounces+wierse=gmx...@gnu.org > [mailto:discuss-gnuradio-bounces+wierse=gmx...@gnu.org] On > Behalf Of wie...@gmx.de > Sent: Monday, May 30, 2011 2:13 PM > To: discuss-gnuradio@gnu.org > Subject: [Discuss-gnuradio] LF Transmission with Gnuradio/USRP > > > Dear GNU Radio gurus, > > I have sent this before but it might have not reached you guys. > Excuse me some basic questions. Point me to another forum or > information > site if this is not the right place... > > we are supposed to pre-develop an inductive coupling radio > transmission > system somewhere between 100khz and 1Mhz with low data rate. > Nothing decided yet (modulation scheme, frequency, transnmit > power, ...) > > I am thinking of Gnuradio on USRP with LFRX/TX as a kind of generic > development platform for transmitter and receiver. > > We are experienced in linux and python and others but we haven't > digged very much into GNU Radio yet. > > Can we do simple modulations like FSK, ASK and OOK easily? > I expect we will get a simple spectrum analyzer capability with the > USRP receiver, right? > > I am not sure I fully understand what is implemented on LFRX/TC from > Ettus Research? Only ADC and DAC or also ome amplifiers and LP filter? > Where can we find specifications? > > Any recommendations to my project intention very much appreciated! > > thanks in advance! > Regards, > Ralf > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio