Hackfest at ESA ESTEC (Noordwejk, NL)
Hello folks, the hackfest at ESA, kindly organized by Andrej Rode, is well underway and we're seeing very interesting progress so far: * a workgroup (packaging) is looking into getting the OOT ecosystem into shape: Infrastructure to build binary packages (.deb for now) to go with our GNU Radio release and nightly PPAs * We've met Micky, the space cat[1] * A second workgroup's focus is laying the foundations for a new GNU Radio runtime environment. This is the continuation of work done at previous conferences – we're finally getting around to writing C++. For now, it's a very MVP / PoC oriented work, not overly concerned with keeping backwards compatibility – instead, focused on translating the requirements gathered up to now into implementable goals that we can start working on and get some coordinatable effort going. More on that *very* soon. Cheers, Marcus [1] https://imgur.com/a/qZuKtHZ
gr version hell gets bigger and bigger...
Hi out there, only a common remark :) I am using gnuradio for around six or seven years now, and such issues were always present, but I never experienced them in the extent like nowadays. More and more I am trapped in version conflicts. Only one simple example, for being able to use gnuradio with my gr-limesdr I need to use gr 3.7, however a LoRaWAN project I wanted to use requires gr 3.8. In other cases projects I wanted to use combined required even three different gr versions. As I am not a coder, no, I can't contribute and update the projects - I am only a user. And also I was not yet motivated enough modifying the cmake file to fool the procedure, in the hope, it may work somehow if I simply extend the accepted version range. I know, this is mainly a matter of the people who maintain such projects...and I have no idea how the awareness for this could be sharpened. As a matter of fact, the most stuff I want to play with still loves 3.7, even going to 3.8 breaks way too much. Ralph. -- Ralph A. Schmid, dk5ras Mondstr. 10 90762 Fürth +49-171-3631223 +49-911-21650056 ra...@schmid.xxx http://www.bclog.de/
Re: gr version hell gets bigger and bigger...
Hi, > As I am not a coder, no, I can't contribute and update the projects - I am > only a user. And also I was not yet motivated enough modifying the cmake > file to fool the procedure, in the hope, it may work somehow if I simply > extend the accepted version range. > > I know, this is mainly a matter of the people who maintain such > projects...and I have no idea how the awareness for this could be sharpened. Paying the maintainer usually helps. Cheers, Sylvain
Re: BER OF OFDM
Hi Madhan, On Wed, 2020-01-29 at 06:13 -0800, Madhan TJ wrote: > DEAR SIR, several ladies on this mailing list, too! > I am doing project on ofdm,so i need to calculate BER for different > modulation techniques Awesome, doing that sounds fine, because an OFDM system typically makes it easy to find frames and thus achieve in- and output bitstream synchronization so you can compare them > While doing this i got Random values of BER for Modulation Techniques > which is not relatable with theory so, you've got a problem with your BER calculation > PLS help me to figure out the error > The screenshot and grc file is attached with this mail. So, you're using blocks from the "deprecated" category: the OFDM Mod and OFDM Demod. Those are broken. Use the modern OFDM infrastructure. Examples of that are found in /usr/share/gnuradio/examples/digital/rx_ofdm.grc, tx_ofdm.grc, ofdm_loopback.grc (or wherever these are installed to on your machine). NO, there's no way around this. Also, don't use WX GUI, it's not maintained anymore, use Qt. You might also want to upgrade to a non-legacy GNU Radio: https://launchpad.net/~gnuradio/+archive/ubuntu/gnuradio-releases Best regards, Marcus
Ubuntu 18.04 LTS QtGUI issues
I have a user of my spectro_radiometer app who is having problems installing it on Ubuntu 18.04 LTS. He installed gnuradio from the repos, then when using grcc -d on the .grc file, gets: Block key "variable_qtgui_label" not found Block key "variable_qtgui_range" not found Block key "variable_qtgui_entry" not found Block key "variable_qtgui_push_button" not found Block key "variable_qtgui_check_box" not found Block key "variable_qtgui_chooser" not found Block key "variable_qtgui_chooser" not found Block key "variable_qtgui_label" not found Block key "variable_qtgui_check_box" not found Block key "variable_qtgui_entry" not found Block key "variable_qtgui_entry" not found Block key "variable_qtgui_entry" not found Block key "variable_qtgui_label" not found Block key "variable_qtgui_push_button" not found Block key "variable_qtgui_entry" not found Block key "variable_qtgui_label" not found Block key "variable_qtgui_chooser" not found Block key "qtgui_tab_widget" not found Block key "osmosdr_source" not found Block key "qtgui_vector_sink_f" not found Block key "qtgui_vector_sink_f" not found Block key "qtgui_vector_sink_f" not found Block key "qtgui_waterfall_sink_x" not found Block key "qtgui_tab_widget" not found This looks to me like the QtGUI components of GR weren't installed correctly by the installer, yet, on my systems here that I've tried, everything works.
Re: Ubuntu 18.04 LTS QtGUI issues
Looks like gr-qtgui wasn't installed. How did the user install GR? On Wed, Jan 29, 2020 at 1:22 PM Marcus D. Leech wrote: > I have a user of my spectro_radiometer app who is having problems > installing it on Ubuntu 18.04 LTS. > > He installed gnuradio from the repos, then when using grcc -d on the > .grc file, gets: > > Block key "variable_qtgui_label" not found > Block key "variable_qtgui_range" not found > Block key "variable_qtgui_entry" not found > Block key "variable_qtgui_push_button" not found > Block key "variable_qtgui_check_box" not found > Block key "variable_qtgui_chooser" not found > Block key "variable_qtgui_chooser" not found > Block key "variable_qtgui_label" not found > Block key "variable_qtgui_check_box" not found > Block key "variable_qtgui_entry" not found > Block key "variable_qtgui_entry" not found > Block key "variable_qtgui_entry" not found > Block key "variable_qtgui_label" not found > Block key "variable_qtgui_push_button" not found > Block key "variable_qtgui_entry" not found > Block key "variable_qtgui_label" not found > Block key "variable_qtgui_chooser" not found > Block key "qtgui_tab_widget" not found > Block key "osmosdr_source" not found > Block key "qtgui_vector_sink_f" not found > Block key "qtgui_vector_sink_f" not found > Block key "qtgui_vector_sink_f" not found > Block key "qtgui_waterfall_sink_x" not found > Block key "qtgui_tab_widget" not found > > > This looks to me like the QtGUI components of GR weren't installed > correctly by the installer, yet, on my systems here that I've tried, >everything works. > > > > > > -- Michael Dickens Ettus Research Technical Support Email: supp...@ettus.com Web: https://ettus.com/
Re: Ubuntu 18.04 LTS QtGUI issues
Using apt-get install Gnuradio. That package includes everything. Sent from my iPhone > On Jan 29, 2020, at 1:23 PM, Michael Dickens > wrote: > > > Looks like gr-qtgui wasn't installed. How did the user install GR? > >> On Wed, Jan 29, 2020 at 1:22 PM Marcus D. Leech >> wrote: >> I have a user of my spectro_radiometer app who is having problems >> installing it on Ubuntu 18.04 LTS. >> >> He installed gnuradio from the repos, then when using grcc -d on the >> .grc file, gets: >> >> Block key "variable_qtgui_label" not found >> Block key "variable_qtgui_range" not found >> Block key "variable_qtgui_entry" not found >> Block key "variable_qtgui_push_button" not found >> Block key "variable_qtgui_check_box" not found >> Block key "variable_qtgui_chooser" not found >> Block key "variable_qtgui_chooser" not found >> Block key "variable_qtgui_label" not found >> Block key "variable_qtgui_check_box" not found >> Block key "variable_qtgui_entry" not found >> Block key "variable_qtgui_entry" not found >> Block key "variable_qtgui_entry" not found >> Block key "variable_qtgui_label" not found >> Block key "variable_qtgui_push_button" not found >> Block key "variable_qtgui_entry" not found >> Block key "variable_qtgui_label" not found >> Block key "variable_qtgui_chooser" not found >> Block key "qtgui_tab_widget" not found >> Block key "osmosdr_source" not found >> Block key "qtgui_vector_sink_f" not found >> Block key "qtgui_vector_sink_f" not found >> Block key "qtgui_vector_sink_f" not found >> Block key "qtgui_waterfall_sink_x" not found >> Block key "qtgui_tab_widget" not found >> >> >> This looks to me like the QtGUI components of GR weren't installed >> correctly by the installer, yet, on my systems here that I've tried, >>everything works. >> >> >> >> >> > > > -- > Michael Dickens > Ettus Research Technical Support > Email: supp...@ettus.com > Web: https://ettus.com/
Re: Ubuntu 18.04 LTS QtGUI issues
Interesting. I really have no idea what's going on there. Using a package install should just work. Are there maybe multiple GR installs & somehow they are being mixed-between -- maybe by some odd shell environment settings? - MLD On Wed, Jan 29, 2020 at 1:35 PM Marcus D Leech wrote: > Using apt-get install Gnuradio. > > That package includes everything. > > Sent from my iPhone > > On Jan 29, 2020, at 1:23 PM, Michael Dickens > wrote: > > > Looks like gr-qtgui wasn't installed. How did the user install GR? > > On Wed, Jan 29, 2020 at 1:22 PM Marcus D. Leech > wrote: > >> I have a user of my spectro_radiometer app who is having problems >> installing it on Ubuntu 18.04 LTS. >> >> He installed gnuradio from the repos, then when using grcc -d on the >> .grc file, gets: >> >> Block key "variable_qtgui_label" not found >> Block key "variable_qtgui_range" not found >> Block key "variable_qtgui_entry" not found >> Block key "variable_qtgui_push_button" not found >> Block key "variable_qtgui_check_box" not found >> Block key "variable_qtgui_chooser" not found >> Block key "variable_qtgui_chooser" not found >> Block key "variable_qtgui_label" not found >> Block key "variable_qtgui_check_box" not found >> Block key "variable_qtgui_entry" not found >> Block key "variable_qtgui_entry" not found >> Block key "variable_qtgui_entry" not found >> Block key "variable_qtgui_label" not found >> Block key "variable_qtgui_push_button" not found >> Block key "variable_qtgui_entry" not found >> Block key "variable_qtgui_label" not found >> Block key "variable_qtgui_chooser" not found >> Block key "qtgui_tab_widget" not found >> Block key "osmosdr_source" not found >> Block key "qtgui_vector_sink_f" not found >> Block key "qtgui_vector_sink_f" not found >> Block key "qtgui_vector_sink_f" not found >> Block key "qtgui_waterfall_sink_x" not found >> Block key "qtgui_tab_widget" not found >> >> >> This looks to me like the QtGUI components of GR weren't installed >> correctly by the installer, yet, on my systems here that I've tried, >>everything works. >> >> >> >> >> >> > > -- > Michael Dickens > Ettus Research Technical Support > Email: supp...@ettus.com > Web: https://ettus.com/ > > -- Michael Dickens Ettus Research Technical Support Email: supp...@ettus.com Web: https://ettus.com/
Re: Ubuntu 18.04 LTS QtGUI issues
Yup. If I were sitting in front of his machine, I could figure it out probably. But he’s in Guatemala. Sent from my iPhone > On Jan 29, 2020, at 1:50 PM, Michael Dickens > wrote: > > > Interesting. I really have no idea what's going on there. Using a package > install should just work. Are there maybe multiple GR installs & somehow they > are being mixed-between -- maybe by some odd shell environment settings? - MLD > >> On Wed, Jan 29, 2020 at 1:35 PM Marcus D Leech >> wrote: >> Using apt-get install Gnuradio. >> >> That package includes everything. >> >> Sent from my iPhone >> On Jan 29, 2020, at 1:23 PM, Michael Dickens wrote: >>> >>> Looks like gr-qtgui wasn't installed. How did the user install GR? >>> On Wed, Jan 29, 2020 at 1:22 PM Marcus D. Leech wrote: I have a user of my spectro_radiometer app who is having problems installing it on Ubuntu 18.04 LTS. He installed gnuradio from the repos, then when using grcc -d on the .grc file, gets: Block key "variable_qtgui_label" not found Block key "variable_qtgui_range" not found Block key "variable_qtgui_entry" not found Block key "variable_qtgui_push_button" not found Block key "variable_qtgui_check_box" not found Block key "variable_qtgui_chooser" not found Block key "variable_qtgui_chooser" not found Block key "variable_qtgui_label" not found Block key "variable_qtgui_check_box" not found Block key "variable_qtgui_entry" not found Block key "variable_qtgui_entry" not found Block key "variable_qtgui_entry" not found Block key "variable_qtgui_label" not found Block key "variable_qtgui_push_button" not found Block key "variable_qtgui_entry" not found Block key "variable_qtgui_label" not found Block key "variable_qtgui_chooser" not found Block key "qtgui_tab_widget" not found Block key "osmosdr_source" not found Block key "qtgui_vector_sink_f" not found Block key "qtgui_vector_sink_f" not found Block key "qtgui_vector_sink_f" not found Block key "qtgui_waterfall_sink_x" not found Block key "qtgui_tab_widget" not found This looks to me like the QtGUI components of GR weren't installed correctly by the installer, yet, on my systems here that I've tried, everything works. >>> >>> >>> -- >>> Michael Dickens >>> Ettus Research Technical Support >>> Email: supp...@ettus.com >>> Web: https://ettus.com/ > > > -- > Michael Dickens > Ettus Research Technical Support > Email: supp...@ettus.com > Web: https://ettus.com/
Re: LimeSDR USB parameter help
hi, Christophe Seguinot i have downloaded your .grc file. i ran it on my laptop with changing audio sink to 44.1, 32, 24. Of course, freq is a fm radio in my area. But i still saw aUaUaU. i heard noise only. my info is: hardware: Limesdr USB OS: ubuntu18.04 gnuradio: 3.8.0.0 gr-limesdr: gr-3.8 LimeSuite: v19.04.1-ga5b3a10f and i also do as gracid said: https://github.com/myriadrf/gr-limesdr/issues/55 1. I see that I've left the default value of "ok to block" in the audio sink, set it to "No" and leave it like that. 2. Try different audio sink rates, for that you would need to change rational resampler and quadrature values (44.1k example: Decimation=2000, Interpolation 441, Quadrature rate: 441e3). 3. Try adding a couple seconds of delay by inserting "Delay" block just before audio sink. I really didnt know why it did not work. i saw @Christophe Seguinot said :In the meantime, I used LimeSuiteGui to calibrate the LimeSDR Mini receiver. Don't know if that step was requested, but it now works! how to calibrate the LimeSDR USB? Is there anybody who can give other recommendations for my case? I am not sure if gnuradio3.7 is ok. But i have no confidence with it.
Re: Recommendation for high sample rate receiver?
Hi A high sample rate for such ns times of arrival resolution is impractical. Same holds for high SNR and longer times of measurement. GPS and most other high resolution positioning systems stitch the information together from the signal time of arrival with the carrier phase of arrival. Since carrier frequencies are incredibly high, their phase can provide such ns accuracy because the phase information is preserved across the downconversion stages with sufficient linearity. For this purpose, the algorithms also need to determine the integer number of arriving wavelengths. Cheers, Qasim
Re: Recommendation for high sample rate receiver?
To whom it may concern: It is already well-discussed, but I would like to add a few points: -If you absolutely want to have a such receiver (it's pretty meaningless, as discussed already, but if you still want to), then you can grab a digital oscilloscope or a similar hardware and attach a RF frontend to it. You will end up losing some (actually, most of) samples, but you cannot run non-trivial data processing chains at 500MS/s in real-time with a generic desktop CPU anyway. -Regarding on why this is pretty meaningless (not using the Nyquist criterion or maths, but using intuitions): consider two consecutive samples, sampled by your receiver. Since the sampling rate is way higher than the bandwidth of the signal, these values are going to be nearly identical. There could be a bit of differences in the amplitude and the phase, but the differences will be pretty small and will be easily washed out by the noise. You cannot expect to get reliable TDOA results from that. You will have to use more samples to get more reliable results.. or just use a slower receiver, anything that satisfies the Nyquist criterion. -If you know the structure of the transmitted signal (like PRNs in GPS), and if you are dealing with CDMA-like signals, then maybe you want to review the GPS receiver design principles and apply that to your design. Not sure if that's the case, though.. -Please consider power difference of arrival or phase interferometry as alternative methods. Regards, Kyeong Su Shin 보낸 사람: Qasim Chaudhari 대신 Discuss-gnuradio 보낸 날짜: 2020년 1월 30일 목요일 오전 11:05 받는 사람: discuss-gnuradio@gnu.org ; mike.nel...@rdss.com 제목: Re: Recommendation for high sample rate receiver? Hi A high sample rate for such ns times of arrival resolution is impractical. Same holds for high SNR and longer times of measurement. GPS and most other high resolution positioning systems stitch the information together from the signal time of arrival with the carrier phase of arrival. Since carrier frequencies are incredibly high, their phase can provide such ns accuracy because the phase information is preserved across the downconversion stages with sufficient linearity. For this purpose, the algorithms also need to determine the integer number of arriving wavelengths. Cheers, Qasim
Re: Recommendation for high sample rate receiver?
To whom it may concern: Forgot to mention: There is a Wikipedia article, listing SDR receivers with various capabilities ( https://en.wikipedia.org/wiki/List_of_software-defined_radios ). There's also something called OneRadio ( http://www.oneradiocorp.com/ ). I saw an actual build of OneRadio, and it was pretty impressive (but expensive, of course). Do not expect these receivers to be well-supported by GNU Radio, however. However (I think it is not necessary, but), if you still want to get a fast receiver and do not want to roll out your own receiver using oscilloscopes or FPGAs, then I guess these are possible alternatives. Regards, Kyeong Su Shin 보낸 사람: Kyeong Su Shin 대신 Discuss-gnuradio 보낸 날짜: 2020년 1월 30일 목요일 오후 12:10 받는 사람: discuss-gnuradio@gnu.org ; mike.nel...@rdss.com 제목: Re: Recommendation for high sample rate receiver? To whom it may concern: It is already well-discussed, but I would like to add a few points: -If you absolutely want to have a such receiver (it's pretty meaningless, as discussed already, but if you still want to), then you can grab a digital oscilloscope or a similar hardware and attach a RF frontend to it. You will end up losing some (actually, most of) samples, but you cannot run non-trivial data processing chains at 500MS/s in real-time with a generic desktop CPU anyway. -Regarding on why this is pretty meaningless (not using the Nyquist criterion or maths, but using intuitions): consider two consecutive samples, sampled by your receiver. Since the sampling rate is way higher than the bandwidth of the signal, these values are going to be nearly identical. There could be a bit of differences in the amplitude and the phase, but the differences will be pretty small and will be easily washed out by the noise. You cannot expect to get reliable TDOA results from that. You will have to use more samples to get more reliable results.. or just use a slower receiver, anything that satisfies the Nyquist criterion. -If you know the structure of the transmitted signal (like PRNs in GPS), and if you are dealing with CDMA-like signals, then maybe you want to review the GPS receiver design principles and apply that to your design. Not sure if that's the case, though.. -Please consider power difference of arrival or phase interferometry as alternative methods. Regards, Kyeong Su Shin 보낸 사람: Qasim Chaudhari 대신 Discuss-gnuradio 보낸 날짜: 2020년 1월 30일 목요일 오전 11:05 받는 사람: discuss-gnuradio@gnu.org ; mike.nel...@rdss.com 제목: Re: Recommendation for high sample rate receiver? Hi A high sample rate for such ns times of arrival resolution is impractical. Same holds for high SNR and longer times of measurement. GPS and most other high resolution positioning systems stitch the information together from the signal time of arrival with the carrier phase of arrival. Since carrier frequencies are incredibly high, their phase can provide such ns accuracy because the phase information is preserved across the downconversion stages with sufficient linearity. For this purpose, the algorithms also need to determine the integer number of arriving wavelengths. Cheers, Qasim
Capture Finite Samples
Hello everyone, I'm trying to capture a user specified number of samples from 3 USRP X300's. To do this I found the finite_acquisition_v function. The problem is it behaves very irregularly, so much so that I can't figure out the right way to use it. It seems that I have to call it once with a big number as a prerequisite. It always returns an empty type this first call. After that first call I have to call it with a sample number request larger than ~1000 to get a none empty tuple. However, the number of samples is less than 1000, for some reason it is 728 If I call it again a third time, I am getting an empty tuple again. I'm wondering if someone can explain the proper way to use this for me. In theory it does exactly what I need to do in one simple function call. Example code: junk = uhd_usrp_source_0.finite_acquisition_v(1000) # first call returns nothing data1 = uhd_usrp_source_0.finite_acquisition_v(1000) # returns 728 samples data2 = uhd_usrp_source_0.finite_acquisition_v(1000) # returns nothing Thanks, Rich
