Re: Change Variable value from an python block or module?
Yes, but no! So, GRC Variables are really a GRC concept, and you'd need to break multiple layers of encapsulation from within a Python block just to alter them. Really, that's possible with a simple callback function, but please don't. Instead, the appropriate way of dealing with this would be giving the signal source a message port, on which it accepts new values via message. Then, from your Python or C++ block, just send a message. Best regards, Marcus On Wed, 2020-03-25 at 14:57 +, Steffen Kiel wrote: > Hello! > > I have a signal source whose frequency input is referenced to a variable. > Is it possible to access this variables value and set it from a python block > or python module? > > BR, > Steffen smime.p7s Description: S/MIME cryptographic signature
Re: GSoC Introduction
Hi Charlie, I was writing a much longer email, but let's first get the formal blocker out of the way: You need to upload a proof of enrollment before you can even upload your proposal to the GSoC website. The latter needs to happen by March 31, no exceptions. Will that work out for you? A 19 day timeframe from "I anticipate I will be eligible" to "I'm definitely eligible, here's my proof of enrollment (not: acceptance)" sounds ambitious. **Will** that work out? If it won't, it might be smarter to prepare this for the coming year. Best regards, Marcus On Thu, 2020-03-12 at 07:38 -0400, Charlie Phillips wrote: > Hi, > > I'm Charlie Phillips, a High School Senior at Florida's Suncoast Community > High School. Although I am not currently enrolled in an undergraduate > program, I am in the process of selecting the University that I will pursue > my computer science undergraduate degree and I anticipate that I will be > eligible for participating to Google's Summer School of Code for 2020. > > During the past two years, I have been working with GNU Radio software for > programming software-defined radio platforms (such as PlutoSDR and LimeSDR) > in I-SENSE and the Department of Computer and Electrical Engineering and > Computer Science at Florida Atlantic University under the supervision of Dr. > George Sklivanitis. I have experience on testing basic digital signal > processing concepts by implementing Out-Of-Tree modules in GNU Radio, and I > am proficient in C++ and Python. > > Part of my work at Florida Atlantic University included experimentation with > gr-lora for command and control of unmanned sea-surface vehicles and > simulation of a binary FSK transceiver for underwater acoustic > communications. I was wondering if the development of a a new module > "gr-underwater" for simulation and emulation of underwater acoustic links > would be of interest to the GNU Radio community. > > I look forward to your feedback. > > Thanks, > Charlie Phillips smime.p7s Description: S/MIME cryptographic signature
Re: Gstreamer webcam usage error
Hi Ahmet, pretty clearly, this isn't the right forum for webcam / gstreamer trouble :) Best regards, Marcus On Wed, 2020-03-11 at 17:30 +0300, Ahmet DEMIR wrote: > Hi, > I want to use the webcam of my laptop in gstreamer to stream a real time > video. I have a problem given in below figure. Is there anybody to help me to > remove this error? > Note: I am using gstreamer 1.0 and linux ubuntu 18.04 OS. > Thanks in advance for the help. > Regards. > smime.p7s Description: S/MIME cryptographic signature
Re: Failed to XInitThreads()
Why? That warning is a legitimate one, but it's also just a warning. As software architect, I'd like to understand the reason for wanting to remove this. Best regards, Marcus On Tue, 2020-03-10 at 08:04 +, Comm Sp wrote: > Yes. Here it is. Regardless of its effects, I am very interested in removing > this warning. > > https://a.uguu.se/rgc6Iiu3v37w_test.py > > > > > On Tuesday, March 10, 2020, 12:00:54 PM GMT+5, Sylvain Munaut > <246...@gmail.com> wrote: > > > > Generating: '/home/mgusr/Flowgraphs/Test.py' > > > > Executing: /usr/bin/python3 -u /home/mgusr/Flowgraphs/Test.py > > > > Warning: failed to XInitThreads() > > > Could you put up the .py file generated somewhere ? > > Cheers, > > Sylvain Munaut > smime.p7s Description: S/MIME cryptographic signature
Re: GnuRadio Help
Hello Vincenzo, Kyeong Su Shin is absolutely right! I'd also like to add that in any case, you'd really want at least Ubuntu 18.04LTS; anything older than that becomes a dependency hell, anyway, so even PyBOMBS wouldn't help much. Best regards, Marcus On Mon, 2020-03-09 at 17:43 +, Kyeong Su Shin wrote: > Hello Vincenzo: > > For an AMD64 system with Ubuntu 18.04 or above, you may try using the GNU > Radio PPA. See: > https://wiki.gnuradio.org/index.php/InstallingGR#Ubuntu_PPA_Installation . > > If that does not work (if your system is not a typical AMD64 box with Ubuntu > 18.04 or higher), you may try PyBOMBs or try building it from manually (from > source). These are described in other sections of the wiki page linked above. > > Regards, > Kyeong Su Shin > 보낸 사람: Vincenzo Mone 대신 Discuss-gnuradio > > 보낸 날짜: 2020년 3월 10일 화요일 오전 2:18 > 받는 사람: discuss-gnuradio@gnu.org > 제목: GnuRadio Help > > Hi Folks, > This is my first post on this group. > Anybody can tell me the right procedure and where to get the Gnuradio v. 3.8 > or above > For Ubuntu? I have tried in Terminal to digit sudo apt gnuradio but I get > installed > The 3.7 version. > Please any help? > Thanks in advance > > 73 de Enzo IK8OZV > EasyLog 5 BetaTester > EasyLog PDA BetaTester > WinBollet BetaTester > D.C.I. CheckPoint Regione Campania > Skype: ik8ozv8520 > > > > > * > ** GSM +39 328 7110193 ** > * SMS +39 328 7110193* > * > smime.p7s Description: S/MIME cryptographic signature
Re: Pi GNURadion challenge.
Hi Robert, On Sun, 2020-03-08 at 20:24 +0100, Robert Heerekop wrote: > > 2. I try to get GNURadio Companion 3.8 running as a GUI because I read that > that was more stable. I'm happy though if I can get any version working in > the first place... > The provided sugegstion to simply perform "sudo apt install gnuradio" does > not install 3.8 but 3.7.13.4. The good news however is that GNU Radio > Companion can be started from the GUI and after installing the osmocom, > RTL-SDR from the RPi-menu and fixing a lxterminal issue, I am able to proces > a WBFM receiver grc-example, but seems facing an audio sink issue resulting > in silence I will continue to look to search for a solution but failed so > far. > As I wrote, you should first upgrade to Testing. That should be easy: https://www.raspberrypi.org/forums/viewtopic.php?t=212223 says: edit your /etc/apt/sources.list, and replace what's in there (stretch, buster, stable, ...) with "testing", then run "sudo apt update", "sudo apt full-upgrade", "sudo apt install gnuradio". Best regards, Marcus smime.p7s Description: S/MIME cryptographic signature
Re: Measure bit error rate.
On Fri, 2020-03-06 at 12:00 +0100, Md. Atiqur Rahman wrote: > I read some documents and it is mostly saying need a file sink, but what > would be the file formate of the sink? > https://wiki.gnuradio.org/index.php/FAQ#What_is_the_file_format_of_a_file_sink.3F_How_can_I_read_files_produced_by_a_file_sink.3F smime.p7s Description: S/MIME cryptographic signature
Re: BladeRF 2 in GRC3.8
Haven't tried it, but I don't see why not. Make sure you've got the right bladerf library development headers installed before building gr- osmosdr. Best regards, Marcus On Fri, 2020-03-06 at 11:37 +, Jerom Maas - LR wrote: > Hello everyone, > > at the moment, I'm trying to connect a BladeRF2 to GNU Radio Companion, using > the Osmocom block (in Ubuntu). > This appears to be more difficult than I thought: I could do it in GRC3.7, > but for some reason I can't pull it off in GRC3.8. > > After a bit of Googling, I get the impression that others have struggled with > this before, but I couldn't really find a solution. > Does anyone know if it is still possible to connect a BladeRF2 via Osmocom to > GRC3.8? Or do I have to find another solution? > > Thanks for your help! > > Jerom Maas smime.p7s Description: S/MIME cryptographic signature
Re: Help with uhd_packet_tx
You'll need to open the packet_tx example from the same folder, and hit "generate" on that, and then reload the block library. On Thu, 2020-03-05 at 13:56 +0300, Ahmet DEMIR wrote: > Thanks a lot for the help. I am using linux ubuntu 18.04 operating system. > When I want to use the uhd_packet_tx.grc example given in > Gnuradio/examples/digital/packet folder, I see that a block is missing as can > be seen at below figure(Example is taken from Gnuradio3.8 version). What is > this block for? Do I have an uninstalled package? I am beginner in this area. > If you help me, I am very pleased to you. smime.p7s Description: S/MIME cryptographic signature
Re: Installing an old version of gnuradio
Depends on the operating system you're running on. However, if the blocks have been removed in GNU Radio 3.8, they've been removed because they didn't work anymore, so you'll need to replace them either way. Best regards, Marcus PS: If you include as much info as possible in your original emails, it's easier to help you right away. On Wed, 2020-03-04 at 16:26 +0300, Ahmet DEMIR wrote: > Hello, > Thank you in advance for the help... > I am trying to transmit a video wirelessly by using Gnuradio. However, some > of the blocks that I want to use in my study are undefined. But, these blocks > can be reached at older versions of Gnuradio. I followed the instructions > given below web-site. But, I get some errors. I also give the error > screenshot in below figure. Can you help me how to install gnuradio 3.7 > version instead of 3.8 version? > Thank you. > Web-site: > https://wiki.gnuradio.org/index.php/InstallingGR#To_install_system_wide > smime.p7s Description: S/MIME cryptographic signature
Re: Channel estimation OFDM saving taps
Hi Vinicius, you can directly feed the output of the OFDM channel estimation block into a simple general block that you write yourself[1] – even in Python – and make that block * either save the contents of the relevant tags to a file or * output a vector of (inverse) channel coefficients taken from the `ofdm_sync_eq_taps` tag. Generally, however, never forget that OFDM channel estimations are *not* a property of the _channel_, but of the _receiver_: If you recall the effects of having a cyclic prefix in OFDM, you'll remember that it's not critical that your receiver is in perfect time synchronity with the beginning of the actual payload part of the symbol (after the CP). Instead, as long as your FFT starts *somewhere* in the cyclic prefix, you're fine synchronization-wise, since a (simulatedly) circular time shift (due to starting the FFT in the CP instead of exactly at the start of symbol after the CP) is just a point-wise multiplication with a complex sinusoid after the FFT – and that means your timing offset will just manifest as rotation of the channel coefficients. And you're correcting these, anyway. So, as long as a CP-OFDM receiver is consistent in the amount of time it starts doing the FFT before the end of CP, the rotation each subcarrier coefficient experiences is always the same and will thus be corrected (e.g. through pilot estimation). But: That means that your channel estimate is not the same you'd get when you're even a fraction of a sample off in timing compared to someone else. It's still the same, ignoring complex rotation, so the power delay profile will be right, and when you agree on e.g. an average phase of symbols, you can compare different channel estimates, but don't directly compare the channel estimates from different receivers, or the same receiver over more than a frame, or after tuning. Best regards, Marcus [1] https://tutorials.gnuradio.org PS: long-term observers will know that I fought very hard to not embed loads of LaTeX in this reply. On Tue, 2020-03-03 at 16:39 +0100, Vinicius Mesquita wrote: > Hello. > Thank you in advance for the help... > > I already searched the mailing list and could not find it how to properly > see/save the channel taps from the OFDM Channel Estimation block. I saw that > is in a tag, but how can I save it? > > What I'd love to find is a way to see the channel estimation with the 52 taps > in a QT GUI plot. Is that possible? If it's not, saving it it's already > awesome. > > Thank you!! smime.p7s Description: S/MIME cryptographic signature
Re: DVB-T receiver problem (OFDM symbol acquisition)
Never too late, just put it on the Ideas List wiki page On Mon, 2020-03-02 at 10:38 -0300, Federico 'Larroca' La Rocca wrote: > Ron, > Let me know if I can be of any help. I've been wanting to port the whole > project and integrate it to GNU Radio for a some years by now, but I just > can't find the time. Maybe it would make a GSoC project? Or it's too late by > now? > best > Federico > > El lun., 2 mar. 2020 a las 10:56, Ron Economos () escribió: > > 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 fi
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 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 smime.p7s Description: S/MIME cryptographic signature
Re: Packet encoder-decoder cannot be found
Dear Ahmet, they were buggy (randomly dropped data), i.e. they never fully worked, couldn't be fixed, were explicitly in the "deprecated" category for multiple years on GNU Radio 3.7 and then finally removed in GNU Radio 3.8. So, you need to replace them with something else. GNU Radio comes with examples (typically, installed to /usr/share/gnuradio/examples), and in the digital/packet directory you'll find some approaches. Best regards, Marcus On Mon, 2020-03-02 at 14:16 +0300, Ahmet DEMIR wrote: > Hi, > I want to simulate a video transmitter-receiver and want to use packet > encoder and decoder. I set up the last version of gnuradio which is gnuradio > 3.8.1.0. But I cannot find these blocks. Can you help me please? smime.p7s Description: S/MIME cryptographic signature
Re: Need advice regarding GRC
That's a bit broad, what's your scientific interest/research topic/general interest? On Sun, 2020-02-23 at 11:49 +0530, aakash jaiswal wrote: > I am a postgraduate student and just got introduced to gnu radio. Could any > please tell me some good but basic level projects i can make with gnu radio > and usrp b200 or b210? smime.p7s Description: S/MIME cryptographic signature
Re: GRC 3.8 Output language Py2 or Py3 (Windows)
Hi Geof, this is just to let you know how much I appreciate your work: Thank you! Best regards, Marcus On Thu, 2020-02-20 at 17:14 -0500, Geof Nieboer wrote: > Jerom, > > Confirming what Marus and the others have said, the current installers use > py2.7 and only py2.7. > > It is indeed a major effort to move to py3 (because compilers), and once it's > done, it'll be done forever, I can't maintain 2 versions. So since py2.7 was > the legacy standard, I'm planning on one more GR 3.8 build before converting > the installers to py3. > > Py3 once the old code is ripped out will actually be much easier to maintain, > but for now, you are stuck. However, at some point in the > future-at-a-date-I-won't-commit-to-because-life, GR3.8+py3 will be available > on Windows in a handy-dandy installer. > > Geof > > On Thu, Feb 20, 2020 at 11:55 AM Michael Dickens > wrote: > > If you install from an EXE, then you'll get whatever it was built for (Py27 > > or Py3). If there's any way to build from source then you can select the > > Python version directly. I don't run Windows, nor do I build for it; > > hopefully someone is providing different Windows installer for GR38 with > > variants for Py27 and Py3 ... - MLD > > > > On Thu, Feb 20, 2020 at 10:08 AM Jerom Maas - LR > > wrote: > > > Hello Michael, thanks for the quick response! > > > > > > I've just reinstalled GRC, but I've not seen a single option about Py2 or > > > Py3. Maybe it's because I use the .exe installer, that it automatically > > > chooses Py2 then? As said before, I don't even have Py2 installed on my > > > pc. Should I give it a go using Powershell, or try another method? > > > > > > > > > > > > Jerom > > > > > > Van: Michael Dickens > > > Verzonden: donderdag 20 februari 2020 15:50:43 > > > Aan: Jerom Maas - LR > > > CC: discuss-gnuradio@gnu.org > > > Onderwerp: Re: GRC 3.8 Output language Py2 or Py3 (Windows) > > > > > > Hi Jerom - I believe GRC outputs Py script based on how GR is installed. > > > Since GR38 can be installed using Py27 or Py3, if it's installed using > > > Py27 then GRC will output for Py27. If installed for Py3 then it'll > > > output for Py3. Pretty sure this is correct. Hence, I'd advise you to > > > check how GR is installed in the first place & if for Py27 then see about > > > getting it installed for Py3. Hope this is useful! - MLD > > > > > > On Thu, Feb 20, 2020 at 9:06 AM Jerom Maas - LR > > > wrote: > > > > Hello all, > > > > > > > > > > > > > > > > after installing GRC 3.8, I find that the .py files that are created > > > > from grc are python 2, instead of python 3. > > > > > > > > I use Py3 and not Py2, so that's a problem. > > > > > > > > How do I change the output language of GRC? If I use the 'option block' > > > > I can only choose 'Python' or ' C++' , but I can't specify the > > > > version of Python. I am using Windows. > > > > > > > > > > > > > > > > Thanks for your help, > > > > > > > > > > > > > > > > Jerom Maas > > > > > > > > > > > > > > > > PS I am not so familiar with C, so if the solution is to alter a bit in > > > > Cmake or something, can you specifically name the file that needs to be > > > > changed? That would be very helpful! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Michael Dickens > > > Ettus Research Technical Support > > > Email: supp...@ettus.com > > > Web: https://ettus.com/ > > > > smime.p7s Description: S/MIME cryptographic signature
Re: [GNU Radio 3.8] Error loading modules on E310
On Fri, 2020-02-21 at 19:44 +0100, Ivan Iudice wrote: > > An other question, why the same version of gnuradio (3.8.0.0) I compiled and > installed on my host machine uses python 3, and on the E310 uses python 2? > Because those are built in different environments. smime.p7s Description: S/MIME cryptographic signature
Re: Python module: object as a reference (just as "Block ID" in "Function Probe" block)
Hi Lukas,
On Fri, 2020-02-21 at 16:17 +0100, Lukas Haase wrote:
>
> Example 2: How do select integer-n mode?
>
> tune_req_rx.args=uhd.device_addr(','.join(["mode_n=integer",
> "int_n_step=1000e3",]))
> tune_req_tx.args=uhd.device_addr(','.join(["mode_n=integer",
> "int_n_step=1000e3",]))
>
> If this message interface should be useful at all, it needs to support all
> the functions that the API provides. Otherwise I start writing a nice
> architecture using messages and shortly after I realize I need to through
> everything away because the interface just doesn't expose the functions
> needed.
Well, It's really not that I disagree! But: you do realize this is a
FOSS project mainly at the mercy of volunteers?
Sure, there's a company with interest in gr-uhd, but even they are
resource-limited and can't guess your use case. So, you're doing the
right thing here, discussing your use case and proposing change.
> > So, really, if this is about setting the gain as a timed command, then
> > follow [1] and use a "time" field.
>
> No, see above. Either I don't see it or this interface has not been made for
> any more advanced application.
Good thing that you can modify the source code of GNU Radio :)
> I am not sure if I understand exactly. So GPIO should only be used with
> messages or NOT with messages?
Only through message handlers.
> If with messages, why is there no way to send GPIO messages to the USRP
> blocks?
Because nobody implemented it! That's why I recommended you do that :)
> Let me briefly tell why these GPIOs are important: In order for them to make
> sense, I need to synchronize them precisely to my signal flow. For example, I
> want to switch something exactly at sample n=1.
Ah, that sounds even less like you'd want to call a function on the
block: That'd be totally unrelated to the signal flow, and might come
too early, or too late.
For the USRP sink, the right way to work here would be using a stream
tag (but again, you'd want to add a stream tag handler to the
usrp_sink's work() then); for the USRP source, yeah, send a message
with a timed command, and start the stream with a start time, so that
you know when, relative to the first received sample, things will
happen.
> > Honestly: At this point, I'd recommend just patching the
> > uhd_block_impl.cc, probably. Look for `REGISTER_CMD_HANLDER` and
> > imitate that line.
>
> If this is really the only way, I teeth-gnashingly proceed with that.
Sorry!
> This unfortunately results in an unmaintable code base that I wanted to avoid
> at all costs.
?!
I don't see why – upstream that change, it's universally helpful, and
it appears in our releases pretty quickly.
> I am wondering if I am the first person in the world needing to
access more than just basic functionality.
Maybe!
> And this is my first project in gnuradio, so I am a beginner.
I can see how this is a bit bad :(
Let me think about this: Maybe we can circumvent the need for you to
modify GNU Radio.
I have never done so, but in principle, you can register message
handlers not only for yourself (if you're a GNU Radio block), but on
other blocks just as well.
So, we could try to:
1. Write a function that takes the arguments you need to properly call
things on the USRP block from a PMT and a USRP block
(say, gpio_at_time(block_handle, PMT))
2. add a new message port "special", i.e.
block_id->message_port_register_in(pmt::mp("special"));
3. register a new message handler on the USRP block, i.e.
block_handle->set_msg_handler(
pmt::mp("special"),
[block_handle](pmt::pmt_t msg)
{
gpio_at_time(block_handle, msg);
}
);
To explain:
3. generates a lambda that calls your setter function, but GNU Radio
makes sure that the function is only ever called when no other
functions in the GNU Radio block execution is trying to use the USRP.
Now, obviously, that doesn't get rid of the need to pass a block
handle, but it'd solve the threading issue here.
To solve the handle issue:
* Write a hier_block that *contains* the USRP block you want to use –
now you know what the block handle is in your hier block's constructor
* do 1.-3. in there
* use that hier block in your overall flow graph instead of the USRP
block itself.
I hope that sounds less crazy than trying to change the UHD blocks
themselves.
Personally, I'd of course prefer a good upstreamed solution, but I can
see how that might not be feasible at this point.
Best regards,
Marcus
smime.p7s
Description: S/MIME cryptographic signature
Re: Python module: object as a reference (just as "Block ID" in "Function Probe" block)
Hi Lukas, On Fri, 2020-02-21 at 00:24 +0100, Lukas Haase wrote: > These blocks support a message interface but unfortunately this is pretty > useless except for the simplest applications (I need to control advanced > tuning with timed commands, GPIO ports etc). That's very much supported, far as I know: you send PMT dictionaries containing a time spec and the setting you want to do. That is, if your USRP supports that, you can do it with GNU Radio. > Hence I need to call the methods of these objects directly but I need a > reference to them inside my custom block. From a software architecture point of view: no, you don't :) > Within my python block I cannot reference the parent blocks, hence I need to > pass a reference to these two objects via the constructor (and parameters). > Basically I want to do the same as parameter "Block ID" from the block > "Function Probe" does. > > What is the best way to implement this? Not implementing this at all, since the resulting flow graph makes assumptions on the order of initialization, and other things that you really shouldn't depend on, since they can't be assumed. > Param - Usrp Source Block(usrp_source_block): > Value "uhd_usrp_sink_0" cannot be evaluated: > name 'uhd_usrp_sink_0' is not defined Exactly this! So, really, if this is about setting the gain as a timed command, then follow [1] and use a "time" field. For GPIO, you're right, there's no message handler for that. But as far as I'm concerned, you *really* don't want to set GPIO things without a message handler, as this could lead to undefined device states if another thread (here, the one running the work() of your uhd_usrp_source block, or a message handler) is manipulating device state. Generally, on classic gen<=3 USRPs, the command queue is head- blocked – and thus, you'll need to send in all commands in order. Therefore, a call to get something (e.g. the state of GPIOs) after a timed command call might then block, and things get logically complicated pretty quickly. Now, how to solve your issue? Honestly: At this point, I'd recommend just patching the uhd_block_impl.cc, probably. Look for `REGISTER_CMD_HANLDER` and imitate that line. Best regards, Marcus [1] http://marcus.hostalia.de/gnuradio-3.8.1.0-rc1/page_uhd.html smime.p7s Description: S/MIME cryptographic signature
[call] We're live ! (was: [call] GNU Radio Project Call 2020-02: Today, postponed to 20:00 UTC)
https://www.twitch.tv/gnuradio ... and the recording will be uploaded to Youtube, too. On Thu, 2020-02-20 at 17:46 +, Müller, Marcus (CEL) wrote: > Dear GNU Radio community, > > due to unplanned events, we have to postpone the project call by two > hours to 20:00 UTC. > > Best regards, > Marcus smime.p7s Description: S/MIME cryptographic signature
Re: [GNU Radio 3.8] Error loading modules on E310
Hi Ivan, GNU Radio 3.7: Python2 GNU Radio 3.8: Py2 XOR Py3 GNU Radio >3.8: Py3 On Thu, 2020-02-20 at 19:35 +0100, Ivan Iudice wrote: > Your help is very welcome! > I’m sorry for the stupid question, however, how can I know which version of > python is used by gnuradio? > > Ivan > > > Il giorno 20 feb 2020, alle ore 19:22, Philip Balister > > ha scritto: > > > > On 2/20/20 11:25 AM, Ivan Iudice wrote: > > > Hi Philip! > > > I only have site-package folder in both python2.7 and python3.5 lib > > > folders, no dist-package. > > > The problem is that in python3.5/site-package there is not numpy, it’s > > > only in python2.7/site-package. > > > Is it not installed for python3? How can I install it in both the sdk > > > sysroot and in the target? > > > > hmm, is gnuradio on the e310 using python 2 or 3? Maybe mixed python > > versions. > > > > Sorry for the short answer, trying to help, but I don't use the Ettus > > builds for gnuradio. > > > > Philip > > > > > Thanks so much. > > > > > > Ivan > > > > > > > > Il giorno 20 feb 2020, alle ore 17:05, Philip Balister > > > > > ha scritto: > > > > > > > > I had some dist-packages versus site-packages with some versions of > > > > gnuradio. See if both exist. I'm betting numpy is in site-packages. > > > > > > > > Philip > > > > > > > > > On 2/19/20 4:46 PM, Ivan Iudice wrote: > > > > > I’m curious to know if there is somebody in the list developing for > > > > > E310 using current SDK. > > > > > This is a problem that, obviously, everybody wants execute custom > > > > > module could incur. > > > > > Any ideas? > > > > > > > > > > Ivan > > > > > > > > > > > > Il giorno 17 feb 2020, alle ore 17:31, kron...@tiscali.it ha > > > > > > > scritto: > > > > > > > > > > > > > > > > > > Dear all, > > > > > > finally I cross-compiled my OOT module for running on USRP E310. > > > > > > Based on the instructions at > > > > > > "https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source";, > > > > > > I set the environment variable PYTHONPATH a little bit different, > > > > > > to point the path of the installed OOT module: > > > > > > > > > > > > export > > > > > > PYTHONPATH=$LOCALPREFIX/lib/python3.5/dist-packages:$PYTHONPATH > > > > > > > > > > > > Such a way, on the target I can load my custom module in python. > > > > > > root@ni-e31x-316AFEA:~# python3 -c "import custom_mod" > > > > > > I created a flowgraph that use my OOT module, and I discovered in > > > > > > the newer file system for E310 python3 has not all of the needed > > > > > > libraries. > > > > > > root@ni-e31x-316AFEA:~# ./top_block.py > > > > > > Traceback (most recent call last): > > > > > > File "./top_block.py", line 12, in > > > > > > from gnuradio import blocks > > > > > > File > > > > > > "/home/root/localinstall/usr/lib/python3.5/dist-packages/gnuradio/blocks/__init__.py", > > > > > > line 38, in > > > > > > from .stream_to_vector_decimator import * > > > > > > File > > > > > > "/home/root/localinstall/usr/lib/python3.5/dist-packages/gnuradio/blocks/stream_to_vector_decimator.py", > > > > > > line 23, in > > > > > > from gnuradio import gr > > > > > > File > > > > > > "/home/root/localinstall/usr/lib/python3.5/dist-packages/gnuradio/gr/__init__.py", > > > > > > line 46, in > > > > > > from .top_block import * > > > > > > File > > > > > > "/home/root/localinstall/usr/lib/python3.5/dist-packages/gnuradio/gr/top_block.py", > > > > > > line 32, in > > > > > > from .hier_block2 import hier_block2 > > > > > > File > > > > > > "/home/root/localinstall/usr/lib/python3.5/dist-packages/gnuradio/gr/hier_block2.py", > > > > > > line 26, in > > > > > > import pmt > > > > > > File > > > > > > "/home/root/localinstall/usr/lib/python3.5/dist-packages/pmt/__init__.py", > > > > > > line 61, in > > > > > > from .pmt_to_python import pmt_to_python as to_python > > > > > > File > > > > > > "/home/root/localinstall/usr/lib/python3.5/dist-packages/pmt/pmt_to_python.py", > > > > > > line 23, in > > > > > > import numpy > > > > > > ImportError: No module named 'numpy' > > > > > > How could I solve the problem? > > > > > > I'm so close to run my OOT modules on the target... > > > > > > Thanks so much. > > > > > > Ivan > > > > > > > > > > > > > > > > > > > > > > > > Con Tiscali Mobile Smart 30 4G hai minuti illimitati, 100 SMS e 30 > > > > > > Giga in 4G a soli 8,99€ al mese. http://tisca.li/smart30 > > > > > > > > smime.p7s Description: S/MIME cryptographic signature
Re: GRC 3.8 Output language Py2 or Py3 (Windows)
Hi Paul, indeed, it is a chicken & egg situation, which is why I embrace Jerom working on windows. But the honest truth is: while there **really** is a lot of time spent on making GNU Radio work as smoothly as on most Linux systems, as of now, your choices are limited. And this is one of the cases where the available choices simply won't work for the user. > We’re generally not students/academics or industry developers, and can’t (or don’t want to) mess with Heinz 59 Varieties of Linux J. Let me assure you that reliable, uniform Windows development seems to be way, way, WAY harder than on Linux, at least to me, where there's canonical paths, and your Distro takes care of installing dependencies. Every single time, and I mean that, that I had to develop or even just build something on Windows, it was a mess, unless someone spent time specifically writing a recipe for the version of dependencies you wanted to use and your specific compiler and all the other things that might vary on Windows installations. I hope projects like Chocolately and Conan improve that situation, but really, the times where Software on Linux was worse to piece together than on windows are over. Best Regards, Marcus On Thu, 2020-02-20 at 18:04 +, Paul White wrote: > Hi, Marcus > “H you're one of the few windows users” > Isn’t this a chicken & egg situation? > My bet is, if Windows binaries were available then *many* more Windows users > (like me) would be falling over themselves in the rush to use Gnu Radio. > We’re generally not students/academics or industry developers, and can’t (or > don’t want to) mess with Heinz 59 Varieties of Linux J. > Regards > Paul > smime.p7s Description: S/MIME cryptographic signature
[call] GNU Radio Project Call 2020-02: Today, postponed to 20:00 UTC
Dear GNU Radio community, due to unplanned events, we have to postpone the project call by two hours to 20:00 UTC. Best regards, Marcus smime.p7s Description: S/MIME cryptographic signature
Re: GRC 3.8 Output language Py2 or Py3 (Windows)
Hi Jerom, cool! You can, by the way, run Linux in a VM under windows, so that you don't have any risk or permanent investment to use Linux: https://www.virtualbox.org/wiki/Downloads Best regards, Marcus On Thu, 2020-02-20 at 15:38 +, Jerom Maas - LR wrote: > hi Marcus, > Thanks again for the quick reply. > It's good to know that I won't get py3 out of windows GRC. > I'll switch to linux for now. I've not worked with it before, but I'm not > afraid either 😉. > Most important for me is to avoid Py2 if possible. > I'll keep an eye out for possible windows updates in the future. Should you > need a guinea-pc, feel free to contact me. > Thanks for the info, > > Jerom > Van: Müller, Marcus (CEL) > Verzonden: donderdag 20 februari 2020 16:24:49 > Aan: michael.dick...@ettus.com; Jerom Maas - LR > CC: discuss-gnuradio@gnu.org > Onderwerp: Re: GRC 3.8 Output language Py2 or Py3 (Windows) > > Ha! Don't get me wrong, it's awesome you're using Windows. > > Now, I don't think Geof came around to building a Python3 GNU Radio, so > you're out of luck for now. You could try your hands on doing that > yourself – follow the link to the Github repo with the source building > scripts – but I'd doubt it's easy :( > > Alternatively: > > Use WSL to run GNU Radio 3.8 on Ubuntu 19.04 or 19.10[1] under windows, > then install GNU Radio 3.8 [2]. Install an X server for windows. > I've had a student that did that and used VS Code on windows to target > his WSL installation, it worked well. > > Or, really, just install a modern Linux (eg. Ubuntu 19.10, Debian) > natively or in a VM for now :) > > As of now, there IS concentrated efforts to improve the windows > situation, but to be honest, it's a strange and confusing and > frustrating world for a lot of us, and I don't even have a single > Windows machine... > > Best regards, > Marcus > > [1] > https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.ubuntu.com_WSL-23Ubuntu-5Fon-5FWSL&d=DwIFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=FxwOwDihISw27IZqIUL77cVHQ03qpclxjfkd7WoRAZ8&m=va4bD3iSeVyxTS3NnAN1oTx0C5TfsrYkCr2kFmx24v0&s=2tDf7lNzveWEyNKZWPEZap9kode2wzF1J4qdX4rF6nk&e= > > [2] > https://urldefense.proofpoint.com/v2/url?u=https-3A__launchpad.net_-7Egnuradio_-2Barchive_ubuntu_gnuradio-2Dreleases&d=DwIFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=FxwOwDihISw27IZqIUL77cVHQ03qpclxjfkd7WoRAZ8&m=va4bD3iSeVyxTS3NnAN1oTx0C5TfsrYkCr2kFmx24v0&s=LSEvfOORFeBb413MJ14w5snDGugZmuVASEwW9QHMa-A&e= > > On Thu, 2020-02-20 at 15:17 +, Jerom Maas - LR wrote: > > Hello Marcus, > > > > that is correct! Sometimes, looking at the help on these forums, I also > > have the feeling that I'm one of the few windows users. > > First of all, a correction: I did not use any .exe, but the file: > > gnuradio_3.8.0.0_win64.msi > > > > I got it from > > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.gcndevelopment.com_gnuradio_downloads.htm&d=DwIFaQ&c=XYzUhXBD2cD-CornpT4QE19xOJBbRy-TBPLK0X9U2o8&r=FxwOwDihISw27IZqIUL77cVHQ03qpclxjfkd7WoRAZ8&m=va4bD3iSeVyxTS3NnAN1oTx0C5TfsrYkCr2kFmx24v0&s=Ia-uzBv1tMkVhBYI2Nrd_k3qtGMkNRaOlveZ79q0yz0&e= > > , downloaded yesterday (feb 19th). > > The file can be found under the 64-Bit Any CPU Windows installer, top link > > - v3.8.0.0/v1.7 BETA > > > > Thank you very much for the help. It's frustrating to be using windows and > > to differ from the linux standards, but looking at the bright side: > > I'm glad to help fixing the last problems for windows users :). > > > > Jerom > > Van: Müller, Marcus (CEL) > > Verzonden: donderdag 20 februari 2020 16:11:15 > > Aan: michael.dick...@ettus.com; Jerom Maas - LR > > CC: discuss-gnuradio@gnu.org > > Onderwerp: Re: GRC 3.8 Output language Py2 or Py3 (Windows) > > > > H you're one of the few windows users; we'll need you to tell us > > *exactly* what you've downloaded! > > > > Best regards, > > Marcus > > > > On Thu, 2020-02-20 at 15:08 +, Jerom Maas - LR wrote: > > > Hello Michael, thanks for the quick response! > > > I've just reinstalled GRC, but I've not seen a single option about Py2 or > > > Py3. Maybe it's because I use the .exe installer, that it automatically > > > chooses Py2 then? As said before, I don't even have Py2 installed on my > > > pc. Should I give it a go using Powershell, or try another method? > > > > > > Jerom > > > Van: Michael Dickens &g
Re: GRC 3.8 Output language Py2 or Py3 (Windows)
Ha! Don't get me wrong, it's awesome you're using Windows. Now, I don't think Geof came around to building a Python3 GNU Radio, so you're out of luck for now. You could try your hands on doing that yourself – follow the link to the Github repo with the source building scripts – but I'd doubt it's easy :( Alternatively: Use WSL to run GNU Radio 3.8 on Ubuntu 19.04 or 19.10[1] under windows, then install GNU Radio 3.8 [2]. Install an X server for windows. I've had a student that did that and used VS Code on windows to target his WSL installation, it worked well. Or, really, just install a modern Linux (eg. Ubuntu 19.10, Debian) natively or in a VM for now :) As of now, there IS concentrated efforts to improve the windows situation, but to be honest, it's a strange and confusing and frustrating world for a lot of us, and I don't even have a single Windows machine... Best regards, Marcus [1] https://wiki.ubuntu.com/WSL#Ubuntu_on_WSL [2] https://launchpad.net/~gnuradio/+archive/ubuntu/gnuradio-releases On Thu, 2020-02-20 at 15:17 +, Jerom Maas - LR wrote: > Hello Marcus, > > that is correct! Sometimes, looking at the help on these forums, I also have > the feeling that I'm one of the few windows users. > First of all, a correction: I did not use any .exe, but the file: > gnuradio_3.8.0.0_win64.msi > > I got it from http://www.gcndevelopment.com/gnuradio/downloads.htm, > downloaded yesterday (feb 19th). > The file can be found under the 64-Bit Any CPU Windows installer, top link - > v3.8.0.0/v1.7 BETA > > Thank you very much for the help. It's frustrating to be using windows and to > differ from the linux standards, but looking at the bright side: > I'm glad to help fixing the last problems for windows users :). > > Jerom > Van: Müller, Marcus (CEL) > Verzonden: donderdag 20 februari 2020 16:11:15 > Aan: michael.dick...@ettus.com; Jerom Maas - LR > CC: discuss-gnuradio@gnu.org > Onderwerp: Re: GRC 3.8 Output language Py2 or Py3 (Windows) > > H you're one of the few windows users; we'll need you to tell us > *exactly* what you've downloaded! > > Best regards, > Marcus > > On Thu, 2020-02-20 at 15:08 +, Jerom Maas - LR wrote: > > Hello Michael, thanks for the quick response! > > I've just reinstalled GRC, but I've not seen a single option about Py2 or > > Py3. Maybe it's because I use the .exe installer, that it automatically > > chooses Py2 then? As said before, I don't even have Py2 installed on my pc. > > Should I give it a go using Powershell, or try another method? > > > > Jerom > > Van: Michael Dickens > > Verzonden: donderdag 20 februari 2020 15:50:43 > > Aan: Jerom Maas - LR > > CC: discuss-gnuradio@gnu.org > > Onderwerp: Re: GRC 3.8 Output language Py2 or Py3 (Windows) > > > > Hi Jerom - I believe GRC outputs Py script based on how GR is installed. > > Since GR38 can be installed using Py27 or Py3, if it's installed using Py27 > > then GRC will output for Py27. If installed for Py3 then it'll output for > > Py3. Pretty sure this is correct. Hence, I'd advise you to check how GR is > > installed in the first place & if for Py27 then see about getting it > > installed for Py3. Hope this is useful! - MLD > > > > On Thu, Feb 20, 2020 at 9:06 AM Jerom Maas - LR wrote: > > > Hello all, > > > > > > after installing GRC 3.8, I find that the .py files that are created from > > > grc are python 2, instead of python 3. > > > I use Py3 and not Py2, so that's a problem. > > > How do I change the output language of GRC? If I use the 'option block' > > > I can only choose 'Python' or ' C++' , but I can't specify the version > > > of Python. I am using Windows. > > > > > > Thanks for your help, > > > > > > Jerom Maas > > > > > > PS I am not so familiar with C, so if the solution is to alter a bit in > > > Cmake or something, can you specifically name the file that needs to be > > > changed? That would be very helpful! > > > > > > > > > > > > > smime.p7s Description: S/MIME cryptographic signature
Re: QT4 GUI runtime error
There's no such thing as "the Qt4 runtime error". Please send us the exactly what you're getting. This mailing list sees a couple of thousand emails in 3 years, so really, we'll need you to tell us what you're reading as error *in verbatim*, and a link to the mailing list archive post (or at least the exact date and subject line) to figure out what you're talking about. Best regards, Marcus On Thu, 2020-02-20 at 14:54 +, Carlos Velazquez wrote: > I was referring to the QT4 runtime error. I was hoping 3 years may have > provided a solution since those QT blocks are so basic (frequency sink, > waterfall). > > I’m hesitant to switch to 3.8 since I don’t know if my OOT items will work, > took me forever to get working, and my project is due in one week. But I’ll > try on a VM tonight and see. > > Thanks for your help! > > > On Feb 20, 2020, at 8:32 AM, Müller, Marcus (CEL) wrote: > > > > Hi Carlos, > > > > > I saw mention to this error > > > > not quite sure what you're referring to. What error? > > > > WX not working on every platform and us not having adequate knowledge > > to repair it was the reason to remove it from GNU Radio, so my > > recommendation really is using Qt instead. > > > > Also, instead of the ld GNU Radio 3.7.11, I'd recommend you get our > > release builds: > > > > uninstall your old GNU Radio, and then run > > sudo add-apt-repository ppa:gnuradio/gnuradio-releases > > sudo apt-get update > > to get GNU Radio 3.8. > > > > Best regards, > > Marcus > > > > > > > On Thu, 2020-02-20 at 00:17 -0500, Carlos wrote: > > > I saw mention to this error in 2017 in the archives and the fix was a > > > delete and install. This is running Ubuntu 18.04 with GR3.7.11-10. The > > > weird part is that WX FFT does not work and none of the frequency related > > > QTs either. The others do. > > > > > > Any idea how to fix that besides remove and re-install? > > > > > > v/r, > > > > > > Carlos smime.p7s Description: S/MIME cryptographic signature
Re: GRC 3.8 Output language Py2 or Py3 (Windows)
H you're one of the few windows users; we'll need you to tell us *exactly* what you've downloaded! Best regards, Marcus On Thu, 2020-02-20 at 15:08 +, Jerom Maas - LR wrote: > Hello Michael, thanks for the quick response! > I've just reinstalled GRC, but I've not seen a single option about Py2 or > Py3. Maybe it's because I use the .exe installer, that it automatically > chooses Py2 then? As said before, I don't even have Py2 installed on my pc. > Should I give it a go using Powershell, or try another method? > > Jerom > Van: Michael Dickens > Verzonden: donderdag 20 februari 2020 15:50:43 > Aan: Jerom Maas - LR > CC: discuss-gnuradio@gnu.org > Onderwerp: Re: GRC 3.8 Output language Py2 or Py3 (Windows) > > Hi Jerom - I believe GRC outputs Py script based on how GR is installed. > Since GR38 can be installed using Py27 or Py3, if it's installed using Py27 > then GRC will output for Py27. If installed for Py3 then it'll output for > Py3. Pretty sure this is correct. Hence, I'd advise you to check how GR is > installed in the first place & if for Py27 then see about getting it > installed for Py3. Hope this is useful! - MLD > > On Thu, Feb 20, 2020 at 9:06 AM Jerom Maas - LR wrote: > > Hello all, > > > > after installing GRC 3.8, I find that the .py files that are created from > > grc are python 2, instead of python 3. > > I use Py3 and not Py2, so that's a problem. > > How do I change the output language of GRC? If I use the 'option block' I > > can only choose 'Python' or ' C++' , but I can't specify the version of > > Python. I am using Windows. > > > > Thanks for your help, > > > > Jerom Maas > > > > PS I am not so familiar with C, so if the solution is to alter a bit in > > Cmake or something, can you specifically name the file that needs to be > > changed? That would be very helpful! > > > > > > > > smime.p7s Description: S/MIME cryptographic signature
Re: QT4 GUI runtime error
Hi Carlos, > I saw mention to this error not quite sure what you're referring to. What error? WX not working on every platform and us not having adequate knowledge to repair it was the reason to remove it from GNU Radio, so my recommendation really is using Qt instead. Also, instead of the ld GNU Radio 3.7.11, I'd recommend you get our release builds: uninstall your old GNU Radio, and then run sudo add-apt-repository ppa:gnuradio/gnuradio-releases sudo apt-get update to get GNU Radio 3.8. Best regards, Marcus On Thu, 2020-02-20 at 00:17 -0500, Carlos wrote: > I saw mention to this error in 2017 in the archives and the fix was a delete > and install. This is running Ubuntu 18.04 with GR3.7.11-10. The weird part is > that WX FFT does not work and none of the frequency related QTs either. The > others do. > > Any idea how to fix that besides remove and re-install? > > v/r, > > Carlos smime.p7s Description: S/MIME cryptographic signature
Re: About the transceiver and sending packets to / from a hardware
It's great that you posted here! I was thanking you for that! Welcome to the community! On Fri, 2020-02-14 at 16:37 -0600, sampath ranga wrote: > Hello Mr.Marcus Muller , > >I totally understand and i apologize for not asking my question in public > . I am new to this forum . I have been working on gnu radio for some time and > just came to know about this platform that does discussion . So I just got an > idea of how to subscribe and how to post the questions. I am totally sorry if > something is wrong . Yes i will see through the reply you sent and try to > work on it and will get you back soon > > Thanks and regards , > Ranganathan Sampathkumar > > On Fri, Feb 14, 2020 at 4:31 PM Müller, Marcus (CEL) wrote: > > Hi! > > > > On Fri, 2020-02-14 at 14:57 -0600, sampath ranga wrote: > > > How are you? I am Ranganathan Sampathkumar, one of the research students > > > who gave request to you through Linkedin a few days ago. > > > > I'd respectfully like to point out that as an author and maintainer of > > open source software, it's often a very time-consuming task to read the > > private messages asking for advice about one's projects. Knowing the > > less-than-amusing messages that show up on the issues on Basti's > > software projects, I think it what reaches him in private actually be a > > really bad burden for him. > > > > It's really much better that you wrote here to the mailing list; in > > general, unless it's really something that *must* be done in privacy, > > it's polite to use the public platforms of open source projects and > > communities. Thanks for reaching out in this public way! > > > > > 1. Is the implementation verification can only be done with TelosB mote > > > with contiki firmware? > > > > Haven't played with in a while, but gr-ieee802-15-4 is at least as far > > as I know a standards-compliant implementation: If you configure it in > > a standards-compliant way, it simply "speaks" zigbee. > > > > > Can we use other Zigbee hardware to sniff the message? > > > > Yes? > > > > > When i tried to do that i can transceive the message successfully in > > > Wireshark > > > > with what did you try? Notice that the Wireshark dissector might not > > like the packet format of all capture devices. > > > > > 2. Or if i do in reverse, say for example if i try to send a message > > > from other Zigbee device to the GNU Radio that has transceiver code > > > with .pcap file, I am seeing the "packets that has been sent from the > > > transceiver in .pcap file at Wireshark but the .pcap file doesnot > > > have the message from the other hardware device". > > > > There's different 802.15.4 PHYs, make sure you're using the same, and > > appropriately configured, for your other device. There's more that can > > go wrong here than can go right – employ your signal processing > > knowledge and the Qt GUI sinks to inspect what you're receiving while > > you are receiving it. > > > > Best regards, > > Marcus smime.p7s Description: S/MIME cryptographic signature
Re: About the transceiver and sending packets to / from a hardware
Hi! On Fri, 2020-02-14 at 14:57 -0600, sampath ranga wrote: > How are you? I am Ranganathan Sampathkumar, one of the research students who > gave request to you through Linkedin a few days ago. I'd respectfully like to point out that as an author and maintainer of open source software, it's often a very time-consuming task to read the private messages asking for advice about one's projects. Knowing the less-than-amusing messages that show up on the issues on Basti's software projects, I think it what reaches him in private actually be a really bad burden for him. It's really much better that you wrote here to the mailing list; in general, unless it's really something that *must* be done in privacy, it's polite to use the public platforms of open source projects and communities. Thanks for reaching out in this public way! > 1. Is the implementation verification can only be done with TelosB mote with > contiki firmware? Haven't played with in a while, but gr-ieee802-15-4 is at least as far as I know a standards-compliant implementation: If you configure it in a standards-compliant way, it simply "speaks" zigbee. > Can we use other Zigbee hardware to sniff the message? Yes? > When i tried to do that i can transceive the message successfully in > Wireshark with what did you try? Notice that the Wireshark dissector might not like the packet format of all capture devices. > 2. Or if i do in reverse, say for example if i try to send a message > from other Zigbee device to the GNU Radio that has transceiver code > with .pcap file, I am seeing the "packets that has been sent from the > transceiver in .pcap file at Wireshark but the .pcap file doesnot > have the message from the other hardware device". There's different 802.15.4 PHYs, make sure you're using the same, and appropriately configured, for your other device. There's more that can go wrong here than can go right – employ your signal processing knowledge and the Qt GUI sinks to inspect what you're receiving while you are receiving it. Best regards, Marcus smime.p7s Description: S/MIME cryptographic signature
Re: Baseband signals frequency,amplitude,data rate determination.
Hello, > I need the basic baseband signal (low frequency) but it would be a 0Hz frequency? Yes, as said, it would be a band-limited signal around 0 Hz. That's the definition of baseband signal. I'm not sure what you mean with > timing diagram is showing the signal has some certain frequency A timing diagram (not _quite_ sure what that is) shows no frequency. Are you perhaps mixing up bandwidth and frequency? Or maybe symbol rate? (But you already have some calculations of symbol rate, so I'm really not sure what you mean.) Regarding bandwidth: Bandwidth of a linear modulation (without Bias) is always fully defined by the pulse shaping filter. You have one of these in your system! Best regards, Marcus PS: https://www.analog.com/media/en/training-seminars/design-handbooks/Software-Defined-Radio-for-Engineers-2018/SDR4Engineers.pdf might be a good place to start; you have gaps in understanding of chapters 2.1–2.3, 2.7, and 4.1–4.2, it seems. It'll be very hard for you to understand what your equalizer and synchronizers do. On Fri, 2020-02-14 at 21:24 +0100, Md. Atiqur Rahman wrote: > Thank you for the clarification. I will update it to 3.8 soon. > However, baseband is the main signal which will be converted to RF signal by > means of upconverter. I have a SDR device(red-pitaya), in which two digitally > modulated baseband signals(I-Q) will come out separately and later on with RF > front end it will be mixed with high frequency. That is the main idea. Hence, > first, I need the basic baseband signal (low frequency) but it would be a 0Hz > frequency? That I have no idea of. The timing diagram is showing the signal > has some certain frequency, then it would be 0? > Would you please give me some details. Thank you so much. > > ps: WX block insertion was a mistake. I didn't realize it until you mentioned > it. As I am going to write a report on my work as well, it is great to know > that now the graph can be export. Is there any updates also for extracting > GRC flow graph from file>screen capture as well? > > On Fri, Feb 14, 2020 at 9:01 PM Müller, Marcus (CEL) wrote: > > Hi Md. Atiqur, > > > > On Fri, 2020-02-14 at 20:43 +0100, Md. Atiqur Rahman wrote: > > > For a QPSK modulation technique, I choose to set constellation point 1 to > > > -1, hence 1.4142 would be amplitude > > > > Ah, you're confusing the magnitude of the complex number with the > > amplitude of the I and Q component. > > > > So, yes, the magnitude of (1 + 1j), (1 - 1j), (-1 + 1j) and (-1 -1j) > > are 1.41, but the real and imaginary parts are still +-1. > > > > > but in the timing diagram, it looks less than that. > > > > So, that's correct :) > > > > > Another point is, as my sampling rate is 2Mhz, and samples per symbol are > > > 32, hence 62.5K is the symbol rate, what will be my baseband signal > > > frequency? > > > > 0 Hz. That's what "baseband" means. > > > > > > Best regards, > > Marcus > > > > PS: As someone occasionallly advising students, I'd recommend > > you clean up your flow graph; there's blocks in there you've commented > > out that you can never use (WX can't coexist with QT GUI). Also, try to > > make it as linear as possible, so to make it really easy to follow the > > "sample flow" optically. This is the Nr. 1 debugging hint for GRC > > beginners, and it really helps a lot when talking about a flow graph. > > > > Also, by the way, you're using a legacy GNU Radio. We've released GR > > 3.8, and you're still on 3.7.; the new GNU Radio has fewer bugs, and > > vector export for GRC figures, which is important to anyone writing a > > thesis with GRC flow graph pictures ;) > > smime.p7s Description: S/MIME cryptographic signature
Re: Baseband signals frequency,amplitude,data rate determination.
Hi Md. Atiqur, On Fri, 2020-02-14 at 20:43 +0100, Md. Atiqur Rahman wrote: > For a QPSK modulation technique, I choose to set constellation point 1 to -1, > hence 1.4142 would be amplitude Ah, you're confusing the magnitude of the complex number with the amplitude of the I and Q component. So, yes, the magnitude of (1 + 1j), (1 - 1j), (-1 + 1j) and (-1 -1j) are 1.41, but the real and imaginary parts are still +-1. > but in the timing diagram, it looks less than that. So, that's correct :) > Another point is, as my sampling rate is 2Mhz, and samples per symbol are 32, > hence 62.5K is the symbol rate, what will be my baseband signal frequency? 0 Hz. That's what "baseband" means. Best regards, Marcus PS: As someone occasionallly advising students, I'd recommend you clean up your flow graph; there's blocks in there you've commented out that you can never use (WX can't coexist with QT GUI). Also, try to make it as linear as possible, so to make it really easy to follow the "sample flow" optically. This is the Nr. 1 debugging hint for GRC beginners, and it really helps a lot when talking about a flow graph. Also, by the way, you're using a legacy GNU Radio. We've released GR 3.8, and you're still on 3.7.; the new GNU Radio has fewer bugs, and vector export for GRC figures, which is important to anyone writing a thesis with GRC flow graph pictures ;) smime.p7s Description: S/MIME cryptographic signature
Re: make error with gr3.8
Hi Martin, 1. you're using a guide meant for Ubuntu 19.10, but you are running a Ubuntu 18.04. So, yeah, that probably works, but really, not what you'd normally do. 2. UNLESS you really need the Ettus version of UHD, and can't work with the one supplied with your Ubuntu installation, building anything from source is a bad idea. **Do you REALLY need UHD 3.15 on Ubuntu 18.04**? It'd be usually easier to just upgrade to Ubuntu 19.10. That has UHD 3.15 in its default installation sources, so no need to build UHD from source, and you can install GNU Radio linking to that version of UHD for that without having to compile anything from source. Please do not compile software from source unless you really need to; that's just complications without benefits. We're supplying current GNU Radio packages for Ubuntu [1] that are way easier to install. But, as said, you can only work with a *really* old UHD if you stay on Ubuntu 18.04. Updating your Ubuntu is my recommendation. (Please uninstall all things you've built from source before updating your Ubuntu: cd uhd/build; sudo make uninstall) If you can live with the old version of UHD that Ubuntu 18.04 ships (e.g. if you have no USRP, or a USRP N210, or so), it's better to not install UHD from source (i.e. uninstall what you've built from source), and just follow [1], even on Ubuntu 18.04. Regarding your problem: the fact that building breaks when linking gr- blocks points to insufficient RAM. Back when I started with GNU Radio about 10 years ago, that was a very common sight. Today, it's rare to find a PC that has insufficient RAM and not enough Swap, but you seem to be in the unlucky situation that you're running out of it. This again stresses the unnecessary amount of complications building from source brings. Best regards, Marcus [1] sudo add-apt-repository ppa:gnuradio/gnuradio-releases sudo apt-get update sudo apt-get install gnuradio This automatically installs the version of UHD your Ubuntu brings (old UHD 3.10 on Ubuntu 18.04, new Ubuntu 3.15 on Ubuntu 19.10), and installs GNU Radio. Should take less than 3 Minutes. Below, a bit of commentary: On Fri, 2020-02-14 at 18:50 +, Martin Spears wrote: > following this doc ---> > https://docs.google.com/document/d/17gbDc_l32wbNIrXopUWIr1pOpu_Ty8tTeC4t12Ah_XE/edit#heading=h.ocyosag08tha > !!! > Ubuntu 19.04 != Ubuntu 18.04 > > GNU Radio 3.8, Ettus UHD and Ubuntu 19.10 <--- > ~/source/gnuradio/build$ cmake -DCMAKE_INSTALL_PREFIX=/usr ../ Dangerous, you're installing into directories usually managed by your Linux distro (i.e. Ubuntu). I do not recommend that. > […] > after make -j4 > > […] > [ 47%] Building CXX object > gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/ctrlport_probe2_c_impl.cc.o > [ 47%] Building CXX object > gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/ctrlport_probe2_f_impl.cc.o > [ 47%] Building CXX object > gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/ctrlport_probe2_s_impl.cc.o > [ 47%] Building CXX object > gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/ctrlport_probe2_i_impl.cc.o > [ 48%] Building CXX object > gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/ctrlport_probe2_b_impl.cc.o > [ 48%] Linking CXX shared library libgnuradio-blocks.so This is the most RAM-intense step in the whole GNU Radio build. > [ 48%] Built target gnuradio-blocks ... Hence my suspicion that you run out of RAM. It might be something else. The fact that there's no compiler error printed, however, suggests my suspicion is right. You can usually check using `dmesg`, whether there's a OOM (out-of-memory) kill log entry somewhere. > Makefile:140: recipe for target 'all' failed > make: *** [all] Error 2 :( smime.p7s Description: S/MIME cryptographic signature
Re: example pfb_sync_test
Hi Sarandis, all but the last three lines shouldn't be necessary at all (why did you install all this?), but they don't hurt, either. Thrift is a RPC backend, i.e. it allows a program to call functions in other processes that don't even necessarily have to run on the same computer. GNU Radio *can* use thrift internally, but it doesn't have to. Could you try sudo apt install thrift-compiler python3-thrift and see whether that helps the symptom? Best regards, Marcus On Fri, 2020-02-14 at 14:48 +0200, sarandis. Doulgeris wrote: > bioic beaver and gnuradio 3.8. installed it : > sudo apt install git cmake g++ libboost-all-dev libgmp-dev swig python3-numpy > \ > python3-mako python3-sphinx python3-lxml doxygen libfftw3-dev \ > libsdl1.2-dev libgsl-dev libqwt-qt5-dev libqt5opengl5-dev python3-pyqt5 \ > liblog4cpp5-dev libzmq3-dev python3-yaml python3-click python3-click-plugins \ > python3-zmq python3-scipy > > sudo add-apt-repository ppa:gnuradio/gnuradio-releases > sudo apt-get update > sudo apt-get install gnuradio > > i dont know what thrift is > > Στις Πέμ, 13 Φεβ 2020 στις 4:21 μ.μ., ο/η Michael Dickens > έγραψε: > > Can you provide us with a little more info here, and that we can try to > > replicate your issue: > > > > * Is the OS "Ubuntu 18.04.3 LTS (Bionic Beaver)" ... or something else? > > > > * Are you trying to use the GNU Radio 3.8.0.0 release? > > > > * How did you install GR? > > > > * what version of Thrift is installed, and how did you install it? > > > > > > On Thu, Feb 13, 2020 at 9:04 AM sarandis. Doulgeris > > wrote: > > > Hi when i try to run the example i get this error > > > > > > ControlPort Monitor running. > > > python3: > > > /build/gnuradio-6i8Hb6/gnuradio-3.8.0.0~gnuradio~bionic/gnuradio-runtime/lib/controlport/rpcmanager.cc:38: > > > static rpcserver_booter_base* rpcmanager::get(): Assertion > > > `booter_registered || aggregator_registered' failed. > > > > smime.p7s Description: S/MIME cryptographic signature
Re: GNURadio Leaking memory during repeated simulations
Hi, huh. That looks hard to debug; also, the slow down is suspicious (as long as there's memory available, it shouldn't take significantly longer to get some – usually, memory fragmentation isn't *that* bad, and this shouldn't be doing *that* much memory allocation). Could you put all your code in one .py file (or a set of these) that one can simply execute right away? That would allow us to reproduce. Also, could you tell us your specific GNU Radio version (all four digits of it?). Best regards, Marcus On Tue, 2020-02-11 at 16:34 -0800, Roman A Sandler wrote: > Hi, > > I am using GNURadio to decode a large amount of 1024-sample complex > vectors of different modulation schemes. Thus, I have a for loop > which runs gr.top_block.run() at each iteration and uses a vector > sink to collect the results. The issue is that as the simulation > keeps going, each itertion takes longer (e.g. starts of at 120it/sec, > and then after 5000 iterations slows down to 10it/sec). I can see in > task manager (I am on windows) that memory is increasing so clearly > there is a memory leak where somehow the results of the iterations > arent being deleted. > > Is there an explicit way to delete runs or is this a bug? > > CODE: > > calling code: > ``` > for _ in range(1): > decode(sig) > ``` > > decode func: > ``` > def decode(channel_sigs): > tb = gr.top_block() > > ## > # Variables > ## > nfilts = 32 > sps = 4 > timing_loop_bw = 3 * 6.28 / 100.0 # NOTE: this controls > convergence speed! > constellation_scheme, bps = get_constellation_scheme(scheme) > rrc_taps = firdes.root_raised_cosine(nfilts, nfilts, 1.0 / > float(sps), 0.35, 11 * sps * nfilts) > phase_bw = 6.28 / 100.0 > eq_gain = 0.01 > arity = 4 > > Actual blocks > channel_src = blocks.vector_source_c(channel_sigs, False) > digital_pfb_clock_sync = digital.pfb_clock_sync_ccf(sps, > timing_loop_bw, rrc_taps, nfilts, > nfilts / 2, > 1.5, 1) > constellation_soft_decoder = > digital.constellation_soft_decoder_cf(constellation_scheme) > binary_slicer = digital.binary_slicer_fb() > blocks_char_to_float = blocks.char_to_float(1, 1) > recovered_bits_dst = blocks.vector_sink_f() > > ## > # Connections > ## > tb.connect((channel_src, 0), (digital_pfb_clock_sync, 0)) > tb.connect((digital_pfb_clock_sync, 0), > (constellation_soft_decoder, 0)) > tb.connect((constellation_soft_decoder, 0), (binary_slicer, 0)) > tb.connect((binary_slicer, 0), (blocks_char_to_float, 0)) > tb.connect((blocks_char_to_float, 0), (recovered_bits_dst, 0)) > > tb.run() > > recovered_bits = np.array(recovered_bits_dst.data()) > return recovered_bits > ``` smime.p7s Description: S/MIME cryptographic signature
Re: Version compatibility problem
Hi Luke, though I like that guide, I'd **really** recommend not building GNU Radio from source on Ubuntu 19.10, unless you really need to (for example, and that's why Ettus has such a guide, because you're using a different UHD than what is available from Ubuntu). On Ubuntu 19.10, it's really really really simple to get running GNU Radio 3.8: sudo add-apt-repository ppa:gnuradio/gnuradio-releases sudo apt-get update sudo apt install gnuradio Done. Hi Laura, that's a manual installation outside your prefix; I think you really might have had multiple GNU Radio 3.8 installations. Yeah, so honestly, re-installing Ubuntu and using the method I described above instead of trying to fix this (which definitely is possible, but not much fun) is the faster way. Best regards, Marcus On Wed, 2020-02-12 at 23:53 +, Luke Stutters wrote: > Dear Laura, > > If you need to build and run GNU Radio 3.8 on a recent Linux kernel > and not just install it from packages, you may find the following > notes useful: > https://docs.google.com/document/d/17gbDc_l32wbNIrXopUWIr1pOpu_Ty8tTeC4t12Ah_XE/edit?usp=sharing > > This is just a simplified version of the guide on the Ettus wiki, but > for Ubuntu 19.10: > https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux > > I was going to add it to the GNU Radio wiki but it does some things > that are unsuitable for a lot of systems, like installing self- > compiled software in /usr instead of /usr/local and patching numpy > in-place to work round Python 3.7 changes. > > However, the simpler approach avoided Python and C++ environment- > related issues for me, and I just needed to test something quickly. > > Best wishes, > > On Wed, 12 Feb 2020 at 23:07, Laura Arjona wrote: > > sorry, typed it wrong > > ~$ which gnradio-config-info > > /usr/local/bin/gnuradio-config-info > > > > On Wed, Feb 12, 2020 at 3:03 PM Laura Arjona > > wrote: > > > Thank you Marcus. > > > > > > I think I am going to install ubuntu again, since I really need > > > to have gnuradio working asap. > > > > > > It says nothing > > > ~$ which gnradio-config-info > > > > > > :~$ gnuradio-config-info --version > > > 3.8.0.0 > > > > > > On Wed, Feb 12, 2020 at 2:42 PM Müller, Marcus (CEL) < > > > muel...@kit.edu> wrote: > > > > huh. Seems to be more than one installation in the prefix?! > > > > what does `which gnuradio-config-info` say? > > > > > > > > > > > > On Wed, 2020-02-12 at 13:52 -0800, Laura Arjona wrote: > > > > > Thank you, > > > > > > > > > > I got rid of all the folders named gnuradio, and it seems to > > > > be > > > > > uninstalled, because when I run uninstall I get Package > > > > 'gnuradio' > > > > > is not installed, so not removed > > > > > > > > > > But I still get > > > > > # gnuradio-config-info --version > > > > > 3.8.0.0 > > > > > > > > > > > > > > > > > > > > On Wed, Feb 12, 2020 at 12:47 PM Müller, Marcus (CEL) < > > > > > muel...@kit.edu> wrote: > > > > > > Hi Laura, > > > > > > > > > > > > first of all, unless you really want to work *on* GNU > > > > Radio, > > > > > > there's > > > > > > little reason to install it using PyBOMBS. At the very > > > > least, on > > > > > > Debian > > > > > > testing, there's native GNU Radio 3.8 packages, and for > > > > Fedora and > > > > > > Ubuntu, GNU Radio has binary packages that you can just > > > > install and > > > > > > use > > > > > > to develop your out-of-tree modules and GNU Radio > > > > applications. > > > > > > > > > > > > However, PyBOMBS will have installed GNU Radio 3.8 into the > > > > prefix > > > > > > ~/gnuradio. So, if you just move that out of the way, or > > > > delete it, > > > > > > then you should have no access to GNU Radio 3.8.0.0 > > > > anymore. > > > > > > > > > > > > Best regards, > > > > > > Marcus > > > > > > > > > > > > On Wed, 2020-02-12 at 12:12 -0800, Laura Arjona wrote: > > > > > > > Good morning, > > > > &g
Re: Version compatibility problem
huh. Seems to be more than one installation in the prefix?! what does `which gnuradio-config-info` say? On Wed, 2020-02-12 at 13:52 -0800, Laura Arjona wrote: > Thank you, > > I got rid of all the folders named gnuradio, and it seems to be > uninstalled, because when I run uninstall I get Package 'gnuradio' > is not installed, so not removed > > But I still get > # gnuradio-config-info --version > 3.8.0.0 > > > > On Wed, Feb 12, 2020 at 12:47 PM Müller, Marcus (CEL) < > muel...@kit.edu> wrote: > > Hi Laura, > > > > first of all, unless you really want to work *on* GNU Radio, > > there's > > little reason to install it using PyBOMBS. At the very least, on > > Debian > > testing, there's native GNU Radio 3.8 packages, and for Fedora and > > Ubuntu, GNU Radio has binary packages that you can just install and > > use > > to develop your out-of-tree modules and GNU Radio applications. > > > > However, PyBOMBS will have installed GNU Radio 3.8 into the prefix > > ~/gnuradio. So, if you just move that out of the way, or delete it, > > then you should have no access to GNU Radio 3.8.0.0 anymore. > > > > Best regards, > > Marcus > > > > On Wed, 2020-02-12 at 12:12 -0800, Laura Arjona wrote: > > > Good morning, > > > > > > In short, I installed gnuradio 3.8 following the tutorial in the > > github site > > > sudo -H pip3 install PyBOMBS > > > pybombs auto-config > > > pybombs recipes add-defaults > > > pybombs prefix init ~/gnuradio -R gnuradio-default > > > > > > but I got problems with the python path, then removed gnuradio, > > and re-installed the version 3.7. > > > > > > But when I check the version with gnuradio-config-info --version > > > I still get version 3.8.0. > > > > > > Because of the version I have other eros when building my oot- > > modules. > > > > > > > > > Any advice there? > > > > > > Thanks! > > > > > > > > smime.p7s Description: S/MIME cryptographic signature
Re: Version compatibility problem
Hi Laura, first of all, unless you really want to work *on* GNU Radio, there's little reason to install it using PyBOMBS. At the very least, on Debian testing, there's native GNU Radio 3.8 packages, and for Fedora and Ubuntu, GNU Radio has binary packages that you can just install and use to develop your out-of-tree modules and GNU Radio applications. However, PyBOMBS will have installed GNU Radio 3.8 into the prefix ~/gnuradio. So, if you just move that out of the way, or delete it, then you should have no access to GNU Radio 3.8.0.0 anymore. Best regards, Marcus On Wed, 2020-02-12 at 12:12 -0800, Laura Arjona wrote: > Good morning, > > In short, I installed gnuradio 3.8 following the tutorial in the github site > sudo -H pip3 install PyBOMBS > pybombs auto-config > pybombs recipes add-defaults > pybombs prefix init ~/gnuradio -R gnuradio-default > > but I got problems with the python path, then removed gnuradio, and > re-installed the version 3.7. > > But when I check the version with gnuradio-config-info --version > I still get version 3.8.0. > > Because of the version I have other eros when building my oot-modules. > > > Any advice there? > > Thanks! > > smime.p7s Description: S/MIME cryptographic signature
Re: clear buffers of stuck chain
You can't send more message than what your bandwidth/radio allows you to send. So, either throw away as many messages as necessary to bring the short- term average message rate to something your hardware can send, or implement a buffering block that puts incoming messages in a queue and slowly emits them. It might be beneficial if you modified gr-ieee802-15-4's PHY blocks in a way that they themselves emit "I've done sending a packet" messages, which you can use to know to when you can send more data. Best regards, Marcus On Tue, 2020-02-11 at 09:44 +0200, Eitan Hetzroni wrote: > Exactly, how can i solve this if i do want to spam? > > > On Mon, Feb 10, 2020 at 6:56 PM Sylvain Munaut <246...@gmail.com> wrote: > > My best guess at this point is you're spamming it with as much message > > as possible (way too many for the actual radio part to send) and then > > at some point the buffers are filled up and it's only accepting new > > messages at the rate it's actually sending them. > > > > Cheers, > > > >Sylvain > > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential and/or privileged > material. Any review, retransmission, dissemination or other use of, or > taking of any action in reliance upon, this information by persons or > entities other than the intended recipient is prohibited. If you received > this in error, please contact the sender and delete all copies of the message. smime.p7s Description: S/MIME cryptographic signature
Re: Kurtosis estimator
Maybe you can abuse the mpsk_snr_est for your purposes? On Sun, 2020-02-09 at 22:16 -0500, Marcus D. Leech wrote: > Has anyone implemented a Kurtosis estimator in GR? Maybe a convenient OOT? > > > smime.p7s Description: S/MIME cryptographic signature
Re: clear buffers of stuck chain
Hi Eitan, sorry, nobody will be able to help you based on the lack of information on what exactly you're doing. "A zigbee chain" really doesn't help any of us debug your issue! Best regards, Marcus On Sun, 2020-02-09 at 09:33 +0200, Eitan Hetzroni wrote: > anyone? > > On Wed, Feb 5, 2020 at 5:47 PM Eitan Hetzroni > wrote: > > hi, > > i am using a gnuradio zigbee chain , and sending alot of packets. > > after a certain point, it stops sending packets(or does very > > slowly). > > can i somehow increase the buffer(message loop) or force it to > > clear the message loop? > > > > thanks > > > > The information transmitted is intended only for the person or entity > to which it is addressed and may contain confidential and/or > privileged material. Any review, retransmission, dissemination or > other use of, or taking of any action in reliance upon, this > information by persons or entities other than the intended recipient > is prohibited. If you received this in error, please contact the > sender and delete all copies of the message. smime.p7s Description: S/MIME cryptographic signature
Re: Finding GNU Radio 3.8 Compatible Versions Of OOT Modules
Generally, the place to start looking for GNU Radio module is cgran.org. Our fantastic volunteers (hey, Nicolas and Marc and others!) have just last week added a new column: supported GNU Radio versions. Sadly that column isn't overly well-populated so far – we expect that to change soon; it's a rather easy field in the Manifest of such OOTs. Best regards, Marcus On Thu, 2020-02-06 at 01:39 +, Luke Stutters wrote: > Dear GNURadioers, > > I was at FOSDEM 2020 and enjoyed the talks. > > I am new to GNU Radio and I have ported a couple of OOT modules to > GNU Radio 3.8. I found the porting tool very helpful but there are > usually some additional Python 3 and cmake changes that are needed > too. > > What is the best way to share this work? I could see some 3.8-related > pull requests for projects on Github - is there an official system to > find 3.8-compatible versions of OOT modules? > > Many thanks, smime.p7s Description: S/MIME cryptographic signature
Re: Link not found for USRP FPGA manual
Hi Laura, I believe such questions are better suited for the usrp-users mailing list, because working on the USRP2 FPGA has little to do with GNU Radio itself! You're right, that link is dead in the UHD 4.0.0.0 documentation, but you're probably not using UHD 4 anyway: Your installation method for UHD probably came with the same documentation, but for specifically the version you're using (maybe in a separate package, it depends), and that would contain the FPGA manual. Generally, I honestly wouldn't dive into programming FPGAs unless there is a very very good reason you *must* use the FPGA – that's digital hardware design, and that's a whole league of complexity and new paradigms that can take months to basically come to terms with. Best regards, Marcus On Wed, 2020-02-05 at 11:15 -0800, Laura Arjona wrote: > Hi community, > > I want to learn about programming the USRP2 FPGA. > > The link about the FPGA manual doesn't work > http://files.ettus.com/manual/md_fpga.html > > Any help of where to find such manual? > > THanks! > > Laura. > -- > Laura Arjona > Washington Research Foundation Innovation Postdoctoral Fellow in > Neuroengineering > > Paul G. Allen School of Computer Science & Engineering > 185 E Stevens Way NE > University of Washington > Seattle, WA 98195-2350 smime.p7s Description: S/MIME cryptographic signature
Re: Slack alternatives
Hi Everyone, we're on this already :) But we do take your emails as "this needs to be bumped up in priority". Thanks! Marcus On Tue, 2020-02-04 at 17:32 +0100, Albin Stigö wrote: > +1 > > On Tue, Feb 4, 2020, 17:26 Sylvain Munaut <246...@gmail.com> wrote: > > Hi > > > > > as you might know, Slack has become a very frequently used tool for > > > communication in the project. > > > Tbh, I never understood the hype around Slack (not the form of > > > communication but the specific software). It deletes our old messages and > > > takes up a ridiculous amount of RAM. > > > > +1 > > > > > Are there any people interested on switching to an alternative, like > > > Mattermost [1]? I’m not deep in the topic, but from what I’ve heard it’s > > > like Slack, but self-hosted, open-source and free. > > > > I think Andre was working on an alternative. > > > > Cheers, > > > >Sylvain > > smime.p7s Description: S/MIME cryptographic signature
Re: [EXT] Re: Recommendation for high sample rate receiver?
Oh you're of course right :) My rule of thumb was "7 to 9 times the fundamental frequency in bandwidth for reliable edges". Cheers, Marcus On Mon, 2020-02-03 at 14:05 +, Chesir, Aaron M. wrote: > Your statement " A signal with 0.1 microsecond rise time definitely > has definitely more than 6 MHz bandwidth" is not necessarily true. > > Simple proof: > > The first 3 components of a 1 Mcycle/sec square wave are: > sin(2*pi*1e6*t) + (1/3) sin(2*pi*3*1e6*t) + (1/5) sin(2*pi*5*1e6*t). > > If you add just the above 3 components, the highest component of the > resultant signal is obviously 5 MHz. > > Its rise time is 0.1 microseconds. > > Aaron > > -Original Message- > From: Discuss-gnuradio < > discuss-gnuradio-bounces+achesir=mitre@gnu.org> On Behalf Of > Müller, Marcus (CEL) > Sent: Monday, February 3, 2020 6:18 AM > To: mike.nel...@rdss.com; discuss-gnuradio@gnu.org > Subject: [EXT] Re: Recommendation for high sample rate receiver? > > Hi Mike, > thanks for following up on this: > A signal with 0.1 microsecond rise time definitely has definitely > more than 6 MHz bandwidth :) so that's where my confusion stems from. > > It will have something upwards of 20 MHz, rule of thumb should be > around 100 MHz bandwidths, and that fits nicely with the bare > necessary > 40 MHz bandwidth for do anything at a 25ns timescale. > As said, if you can capture that amount of bandwidth, you can infer > the timing – you really do not need 500 MS/s, as far as I can tell > from your description of the signal. > Then again, there might be complicating factors – extreme dynamic > range, for example. > > Could you tell us more details about your signal? And also, "as > accurately as possible" is not a spec; could you say "I need a timing > accuracy of X ns, given an SNR of Y dB", so that we could help you > there? > > Best regards, > Marcus > > On Sat, 2020-02-01 at 02:58 -0500, Mike wrote: > > Thank you to all who commented. > > > > The target signal of interest uses pulse modulation where each > > pulse > > is 1 microsecond in duration, with a rise time of less than 0.1 > > microsecond and a decay time of less than 0.2 microseconds. The > > goal > > is to identify the start (arrival) of a transmission at each > > receiver > > site as accurately as possible (better than 25 ns). > > > > Interpolation adds no useful information regarding start time, of > > course. Lower sampling rates lose arrival time resolution. > > > > No affordable SDR supports 500 MS/sec; I'm looking at A/D > > evaluation > > boards with an RF front end. > > > > > > Thanks! > > > > > > > > On 1/29/2020 10:34 PM, Kyeong Su Shin wrote: > > > 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 > > > < > > > discuss-gnuradio-bounces+ksshin=postech.ac...@gnu.org> > > > 보낸 날짜: 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
Re: Recommendation for high sample rate receiver?
Hi Mike, thanks for following up on this: A signal with 0.1 microsecond rise time definitely has definitely more than 6 MHz bandwidth :) so that's where my confusion stems from. It will have something upwards of 20 MHz, rule of thumb should be around 100 MHz bandwidths, and that fits nicely with the bare necessary 40 MHz bandwidth for do anything at a 25ns timescale. As said, if you can capture that amount of bandwidth, you can infer the timing – you really do not need 500 MS/s, as far as I can tell from your description of the signal. Then again, there might be complicating factors – extreme dynamic range, for example. Could you tell us more details about your signal? And also, "as accurately as possible" is not a spec; could you say "I need a timing accuracy of X ns, given an SNR of Y dB", so that we could help you there? Best regards, Marcus On Sat, 2020-02-01 at 02:58 -0500, Mike wrote: > Thank you to all who commented. > > The target signal of interest uses pulse modulation where each pulse > is 1 microsecond in duration, with a rise time of less than 0.1 > microsecond and a decay time of less than 0.2 microseconds. The goal > is to identify the start (arrival) of a transmission at each receiver > site as accurately as possible (better than 25 ns). > > Interpolation adds no useful information regarding start time, of > course. Lower sampling rates lose arrival time resolution. > > No affordable SDR supports 500 MS/sec; I'm looking at A/D evaluation > boards with an RF front end. > > > Thanks! > > > > On 1/29/2020 10:34 PM, Kyeong Su Shin wrote: > > 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 < > > discuss-gnuradio-bounces+ksshin=postech.ac...@gnu.org> > > 보낸 날짜: 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 purpos
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
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
Re: Constellation script
Hi Michel, welcome to the mailing list. I must admit that I don't really know what you want to do. Can you explain it, so that doesn't know what a DMR-C4FM relay is, understands? I think you're referring to some GRC flow graphs, but sadly we don't know which ones you have been looking at. So, specific links would be very appreciated. Best regards, Marcus On Mon, 2020-01-20 at 17:41 +0100, michel slepoukha wrote: > Hello all! > I designed in 2018 the DMR-C4FM relay from Albi (Tarn), F5ZLH > it works… > Well, not that good, because we noticed a poor signal quality: > > > with the constellation, on a portable equipment such as the Rpi 4. we will > beable to adjust the relay settings > And there only GNURadio is installed correctly and worked perfectly with an > RTL-SDR key. > But most of the flow chart examples use logical signal sources and if some of > them have an RTL-SDR key as input, they are either incomplete or with errors > (wonder if this is not done expressly?) . And above all, no script linked to > the flow chart concerned. > So, I can only turn to the competence of your team to finally have this > script validated. > Configuration is simple: SDR-RTL → constellation > With thanks for help > Mike > smime.p7s Description: S/MIME cryptographic signature
Guidance on channel separation (was: Discuss-gnuradio Digest, Vol 207, Issue 21)
Dear Faisal, first piece of guidance: write good emails; the email you answered to literally says: On Mon, 2020-01-20 at 22:38 +0500, Faisal Khan wrote: > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of Discuss-gnuradio digest..." So, I've changed your subject line. Anyway, your question is > I want guidance about that while receiving two channels how can i separate those channels and records their audio in their respective files simultaneously.. So, not quite sure what you mean here: with what are you recording? Best regards, Marcus smime.p7s Description: S/MIME cryptographic signature
Re: GNU Radio ABI guarantees
Ah, you're right: of course you *could* use a symbol introduced in A.B.1.0 and then couldn't compile with A.B.0.0, but what I meant is "recompiling (when a new release comes out)". On Tue, 2020-01-21 at 15:36 +0100, Sylvain Munaut wrote: > > we guarantee API > > compatibility (i.e. recompiling will never fail) for all releases that > > have the same A.B. > > Huh really ? > > I thought it was more like within the same A.B, if it builds with C0, > it will build for any C1 >= C0. > > Cheers, > > Sylvain smime.p7s Description: S/MIME cryptographic signature
Re: GNU Radio ABI guarantees
Hi Thomas, as Nate wrote: we guarantee ABI compatibility between Releases A.B.C.D that only differ in D (i.e. no relinking necessary), we guarantee API compatibility (i.e. recompiling will never fail) for all releases that have the same A.B. Best regards, Marcus On Mon, 2020-01-20 at 23:00 +, Thomas Habets wrote: > What are the ABI guarantees between GNU Radio releases? > > I'm drafting a GREP on modernizing the C++ code[1], so started wondering > about this. > > If a minor release, once released, only gets backported fixes from master, > then this should not be an issue. > > [1] https://github.com/gnuradio/greps/pull/19 > smime.p7s Description: S/MIME cryptographic signature
Re: New QTGUI Eye Sink proposal
Hi Christophe, That's awesome! I'm looking forward to reviewing that PR! On Fri, 2020-01-17 at 11:13 +0100, Christophe Seguinot wrote: > I really want to congratulate developers for their good quality code of > GNURadio. Without that I wouldn't have been able to develop this eye_sink. I think you're making more than one developer blush here :) > Il must be noticed that a real eye diagram would be triggered with a > (recovered) symbol clock. For these reasons, triggering of noisy and/or > unsynchronized (receiver) signals is tricky and may lead to incorrect eye > pattern Ah, that's not a bad limitation: that's what trigger-on-tag is for; you can write a synchronizer for your specific waveform (and synchronizers are different for different systems...) and just tag the correct point in time. Best regards, Marcus smime.p7s Description: S/MIME cryptographic signature
Re: Library for matrix operations? (eigenvalues, pseudoinverse)
True, Eigen is pretty popular for people needing to do Matrix operations – I wasn't aware they even have Matrix decompositions[1]! (in hindsight... considering the library name...) I like Eigen, but there's two caveats, I find: 1. indexing is done with () instead of [] (I guess it's made for people who come from Matlab) 2. It's very much mathematician's software – I found (but that's about a decade in the past, at the very least, so older compilers, older processors, older Eigen) that things like Matrix·Matrix products were relatively slow I do recommend it to students that simply need some Matrix functionality, as performance usually is of secondary concern and can be optimized as soon as the software works. Best regards, Marcus [1] http://eigen.tuxfamily.org/dox/group__TopicLinearAlgebraDecompositions.html On Fri, 2020-01-17 at 11:16 +1300, Jeremy Reeve wrote: > Hi Laura, > > Just to add to the suggestions, I've seen Eigen [1] used in the past. > It's a template library (headers only) and has no external > dependencies other than the standard library and that might be > something to consider given your use-case. > > [1] http://eigen.tuxfamily.org/index.php?title=Main_Page > > Jeremy > > On Fri, 17 Jan 2020 at 10:02, Laura Arjona wrote: > > Hi all, > > > > Is there any library to use in gnuradio for algebra operations, such as > > matrix eigenvalues, and pseudoinverse? Or I'd need to code them myself in > > C++? > > > > I need to integrate those operations into my OOT C++ blocks. > > > > Thanks for your time > > > > Best > > > > -- > > Laura Arjona > > Washington Research Foundation Innovation Postdoctoral Fellow in > > Neuroengineering > > > > Paul G. Allen School of Computer Science & Engineering > > 185 E Stevens Way NE > > University of Washington > > Seattle, WA 98195-2350 smime.p7s Description: S/MIME cryptographic signature
Re: Library for matrix operations? (eigenvalues, pseudoinverse)
Oh not to forget: if you really just want to use LAPACK in isolation and not require other dependencies at runtime... there's of course also the option of writing Fortran [1] and then just directly using it from C++... but beware, FORTRAN matrices are column-major, whereas C/C++ tends to be row-major. Best regards, Marcus [1] https://github.com/kit-cel/gr-specest/search?q=filename%3A.f90&unscoped_q=filename%3A.f90 On Thu, 2020-01-16 at 21:31 +, Müller, Marcus (CEL) wrote: > So, that depends a bit on what you want to do: > > These operations are classically implemented in a library called > LAPACK, which is really mature (and, it's written in Fortran90). You > use it through C++ wrappers like "IT++" or "Armadillo". > > Be a bit careful though. The usual way of defining the pseudoinverse of > a martrix with lin. indep. columns is > > A⁺ = (A* A)⁻¹ A* > > (with * being hermitian transposition). > > One of the relatively eternal laws of numerical math seems to be > > "you DON'T want to calculate that matrix inverse; it's way more work > than finding the solution to a system of linear equations directly (and > potentially much worse in terms of accuracy[2, (1.2) on p.2])" > > even for relatively small (A'A). Therefore, other methods exist, which > tend to be faster, and can, under some assumptions, be more stable[1]; > one is based on the singular value decomposition > >A = U𝛴V* > > TL;DR: LAPACK wrapped for your language of choice, e.g. IT++ has > eigenvalue, and singular value decompositions. You should find the > Pseudoinverse through the singular value decomposition. > > Best regards, > Marcus > > [1]https://www.johndcook.com/blog/2018/05/05/svd/ > [2] S. Rump: "Inversion of Extremely Ill-Conditioned Matrices > in Floating-Point" http://www.ti3.tuhh.de/paper/rump/Ru08a.pdf > > On Thu, 2020-01-16 at 20:57 -0800, Laura Arjona wrote: > > Hi all, > > > > Is there any library to use in gnuradio for algebra operations, such as > > matrix eigenvalues, and pseudoinverse? Or I'd need to code them myself in > > C++? > > > > I need to integrate those operations into my OOT C++ blocks. > > > > Thanks for your time > > > > Best > > smime.p7s Description: S/MIME cryptographic signature
Re: Library for matrix operations? (eigenvalues, pseudoinverse)
So, that depends a bit on what you want to do: These operations are classically implemented in a library called LAPACK, which is really mature (and, it's written in Fortran90). You use it through C++ wrappers like "IT++" or "Armadillo". Be a bit careful though. The usual way of defining the pseudoinverse of a martrix with lin. indep. columns is A⁺ = (A* A)⁻¹ A* (with * being hermitian transposition). One of the relatively eternal laws of numerical math seems to be "you DON'T want to calculate that matrix inverse; it's way more work than finding the solution to a system of linear equations directly (and potentially much worse in terms of accuracy[2, (1.2) on p.2])" even for relatively small (A'A). Therefore, other methods exist, which tend to be faster, and can, under some assumptions, be more stable[1]; one is based on the singular value decomposition A = U𝛴V* TL;DR: LAPACK wrapped for your language of choice, e.g. IT++ has eigenvalue, and singular value decompositions. You should find the Pseudoinverse through the singular value decomposition. Best regards, Marcus [1]https://www.johndcook.com/blog/2018/05/05/svd/ [2] S. Rump: "Inversion of Extremely Ill-Conditioned Matrices in Floating-Point" http://www.ti3.tuhh.de/paper/rump/Ru08a.pdf On Thu, 2020-01-16 at 20:57 -0800, Laura Arjona wrote: > Hi all, > > Is there any library to use in gnuradio for algebra operations, such as > matrix eigenvalues, and pseudoinverse? Or I'd need to code them myself in C++? > > I need to integrate those operations into my OOT C++ blocks. > > Thanks for your time > > Best > smime.p7s Description: S/MIME cryptographic signature
Re: pybombs install gr-osmosdr ........ bunch of errors
Hi Fernando, the bug report you linked to was closed because it's a) inaccurate and b) posted to the wrong github repo. So, Sylvain actually tried to make gr-osmosdr 3.8 compatible, and it's sad that doesn't work for you. I don't think you should actually need MPIR – MPIR is kind of the fall back when GMP cannot be found (which, for example, always happens on Windows, because there's no Windows version of GMP). So, could you try installing GMP (simply through apt-get, i.e. `sudo apt install libgmp`. Also, can you please uninstall your manually installed CMake? The CMake in Ubuntu 19.04 should be 3.13.4. It was 3.10.2 in 18.04, so, maybe you have a half-upgraded Ubuntu installation? That's all a bit strange. After uninstalling your manual CMake installation, try using `sudo apt update && sudo apt install --reinstall cmake`. Best regards, Marcus On Wed, 2020-01-15 at 17:57 +0100, Fernando wrote: > I have tried: > > sudo apt install git > > sudo apt install cmake > > git clone git://git.osmocom.org/gr-osmosdr > > cd gr-osmosdr/ > > git checkout gr3.8 > > mkdir build > > cd build/ > > cmake ../ > > Error: CMake 3.13 or higher is required. You are running version 3.10.2 > > Then I installed last cmake (and mpir3.0.0) and > > bin/cmake ../ > > and then > > grc@gnuradio:~/gr-osmosdr/build$ bin/cmake ../ > -- Build type not specified: defaulting to release. > -- Checking for module 'gmp' > -- No package 'gmp' found > -- Could NOT find GMP (missing: GMPXX_LIBRARY GMP_LIBRARY GMP_INCLUDE_DIR) > -- Checking for module 'mpir >= 3.0' > -- No package 'mpir' found > -- Could NOT find MPIR (missing: MPIRXX_LIBRARY MPIR_INCLUDE_DIR) > CMake Error at > build/share/cmake-3.15/Modules/FindPackageHandleStandardArgs.cmake:137 > (message): > Could NOT find MPLIB (missing: MPLIBXX_LIBRARY MPLIB_INCLUDE_DIR) > Call Stack (most recent call first): > build/share/cmake-3.15/Modules/FindPackageHandleStandardArgs.cmake:378 > (_FPHSA_FAILURE_MESSAGE) > /usr/lib/x86_64-linux-gnu/cmake/gnuradio/FindMPLIB.cmake:26 > (find_package_handle_standard_args) > build/share/cmake-3.15/Modules/CMakeFindDependencyMacro.cmake:47 > (find_package) > /usr/lib/x86_64-linux-gnu/cmake/gnuradio/GnuradioConfig.cmake:26 > (find_dependency) > CMakeLists.txt:45 (find_package) > > > -- Configuring incomplete, errors occurred! > See also "/home/grc/gr-osmosdr/build/CMakeFiles/CMakeOutput.log". > > > > > And I have read this wich says that gr-osmosdr does not work with gnuradio 3.8 > > https://github.com/gnuradio/gnuradio/issues/2838 > > > > > > On 14/1/20 11:42, Müller, Marcus (CEL) wrote: > > Ah little correction: > > On Tue, 2020-01-14 at 10:10 +, Müller, Marcus (CEL) wrote: > > > Hi Fernando, > > > > > > GNU Radio itself doesn't interface with the bladeRF directly, at all – > > > things like gr-osmosdr do. > > > Hence, there's absolutely no need to build GNU Radio from source. > > > > > > Instead: > > > > > > 1. Get a modern GNU Radio (3.8.0.0 as of writing) as a binary package > > > via our PPA [1]: > > > sudo add-apt-repository ppa:gnuradio/gnuradio-releases > > > sudo apt update > > > sudo apt install gnuradio > > > > also > > > > sudo apt install gnuradio-dev > > > 2. build the libbladerf from source that can talk to your BladeRF. > > > Install it. > > > 3. build gr-osmosdr from source so that you get GNU Radio blocks to use > > > that libbladerf > > > > > > Best regards, > > > Marcus > > > > > > > > > [1] https://launchpad.net/~gnuradio/+archive/ubuntu/gnuradio-releases > > > On Mon, 2020-01-13 at 21:53 +0100, Fernando wrote: > > > > As I reported before I'm trying to use a new bladeRF 2.0 in gnuradio > > > > but it does not work with the bladeRF in the ubuntu repos, so I'm > > > > trying to install gnuradio and gr-osmosdr with pybombs > > > > > > > > I'm using ubuntu 19.04. The precess i have followed is the following: > > > > > > > > sudo apt install git > > > > sudo apt install python3 > > > > sudo apt install python3-pip > > > > sudo pip3 install --upgrade git+https://github.com/gnuradio/pybombs.git > > > > pybombs auto-config > > > > pybombs recipes add-defaults > > > > sudo apt install git cmake g++ libboost-all-dev libgmp-dev swig > > > > pytho
Re: Regarding File Source Block Funtionality
Dear Shivam, the mailing list archive shows no record of you ever contacting this list under the subject "Regarding File source Block Funtionality"[1] or from someone named Shivam at all[2]. This, together with the fact that we're basically participating on this list in mostly unpaid time might explain why you've never heard from us. First of all: it makes no sense calling an output file *.txt. It's not text, see our FAQ [3]. It's not clear what you'd want to do here: The slider is not a display element. Your requirement doesn't make much sense. What's the *purpose* of all this? Best regards, Marcus [1] https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=funtionality&submit=Search%21&idxname=discuss-gnuradio&max=20&result=normal&sort=score [2] https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=shivam&submit=Search%21&idxname=discuss-gnuradio&max=20&result=normal&sort=score [3] https://wiki.gnuradio.org/index.php/FAQ#What_is_the_file_format_of_a_file_sink.3F_How_can_I_read_files_produced_by_a_file_sink.3F On Wed, 2020-01-15 at 14:17 +0100, Shivam Shrivastava wrote: > Hi All, > > Just a gentle reminder, I didn't receive anything from your side, I assume > my problem definition was quite vague and I didn't explain the exact > scenario. So I'm trying again to give you guys a more clearer picture. > >I'm currently > using GNU Radio Companion tool to develop a flow graph which looks like this > (please find the below screenshot) > As you can see here, I'm using File Source Block which takes IQ file as > source(this file contains all the IQ data. approximately of 3GB) and in the > the File Sink I'm just storing all the IQ data in a output.txt file. As per > my requirement, I need to implement a functionality which controls the > content of file source through the sliding bar or progress bar i.e. if IQ > file is read only 50% then slider should move to 50%. I have tried different > approach and searched on the internet but couldn't find any workaround > through which I can manipulate the File Source Block. Just a quick update > I'm doing my project in python and would like to implement this feature in > the same source code. > It seems like the Seek() function in the API is not behaving > as expected. Could anyone please suggest me a way to achieve this > functionality if it is possible. Looking forward to the positive response and > thanks in advance. > > > Thanks & Regards > Shivam Shrivastava. > > On Fri, Jan 3, 2020 at 1:45 PM Shivam Shrivastava > wrote: > > Hi All, > > > > I need small help, I'm using Gnu Radio companion with File Source Block in > > my application. Currently stuck to achieve a functionality where I want to > > seek input file according to the seek bar. In simple term, is there any way > > to know how much input file has been read in File Source Block. Any lead > > would be really helpful. Let me know if you need further clarification. > > > > Looking forward to hearing from you. > > > > -- > > Thanks & Regards > > Shivam Shrivastava > > smime.p7s Description: S/MIME cryptographic signature
Re: pybombs install gr-osmosdr ........ bunch of errors
Ah little correction: On Tue, 2020-01-14 at 10:10 +, Müller, Marcus (CEL) wrote: > Hi Fernando, > > GNU Radio itself doesn't interface with the bladeRF directly, at all – > things like gr-osmosdr do. > Hence, there's absolutely no need to build GNU Radio from source. > > Instead: > > 1. Get a modern GNU Radio (3.8.0.0 as of writing) as a binary package > via our PPA [1]: > sudo add-apt-repository ppa:gnuradio/gnuradio-releases > sudo apt update > sudo apt install gnuradio also sudo apt install gnuradio-dev > 2. build the libbladerf from source that can talk to your BladeRF. > Install it. > 3. build gr-osmosdr from source so that you get GNU Radio blocks to use > that libbladerf > > Best regards, > Marcus > > > [1] https://launchpad.net/~gnuradio/+archive/ubuntu/gnuradio-releases > On Mon, 2020-01-13 at 21:53 +0100, Fernando wrote: > > As I reported before I'm trying to use a new bladeRF 2.0 in gnuradio but it > > does not work with the bladeRF in the ubuntu repos, so I'm trying to > > install gnuradio and gr-osmosdr with pybombs > > > > I'm using ubuntu 19.04. The precess i have followed is the following: > > > > sudo apt install git > > sudo apt install python3 > > sudo apt install python3-pip > > sudo pip3 install --upgrade git+https://github.com/gnuradio/pybombs.git > > pybombs auto-config > > pybombs recipes add-defaults > > sudo apt install git cmake g++ libboost-all-dev libgmp-dev swig > > python3-numpy \ > > python3-mako python3-sphinx python3-lxml doxygen libfftw3-dev libcomedi-dev > > \ > > libsdl1.2-dev libgsl-dev libqwt-qt5-dev libqt5opengl5-dev python3-pyqt5 \ > > liblog4cpp5-dev libzmq3-dev python3-yaml python3-click > > python3-click-plugins \ > > python3-zmq > > pybombs prefix init ~/gnuradio -R gnuradio-default > > > > pybombs install gr-osmosdr > > there comes the error: mpir not found, then I have installed mpir > > > > sudo apt install yasm > > I have installed mpir3.0.0 from > > http://mpir.org/downloads.html > > > > > > and then > > > > > > > > grc@gnuradio:~$ pybombs install gr-osmosdr > > [INFO] Prefix Python version is: 3.7.3 > > [INFO] PyBOMBS Version 2.3.4a0 > > [INFO] Phase 1: Creating install tree and installing binary packages: > > Install tree: > > \- gr-osmosdr > > [INFO] Phase 1 complete: All binary dependencies installed. > > [INFO] Phase 2: Recursively installing source packages to prefix: > > [INFO] Installing package: gr-osmosdr > > [WARNING] Build dir already exists: /home/grc/gnuradio/src/gr-osmosdr/build > > Configuring: (100%) > > [==] > > [WARNING] Configuration failed. Re-trying with higher verbosity. > > -- Extracting version information from git describe... > > -- Configuring Boost C++ Libraries... > > -- Boost version: 1.67.0 > > -- Found the following Boost libraries: > > -- thread > > -- system > > -- chrono > > -- date_time > > -- atomic > > -- Checking for module 'gmp' > > -- No package 'gmp' found > > -- Checking for module 'mpir >= 3.0' > > -- No package 'mpir' found > > -- Could NOT find MPIR (missing: MPIRXX_LIBRARY MPIR_INCLUDE_DIR) > > > > > > -- Checking for module 'gnuradio-iqbalance' > > > > > > -- No package 'gnuradio-iqbalance' found > > > > > > -- Found gnuradio-uhd: /home/grc/gnuradio/include, > > /home/grc/gnuradio/lib/libgnuradio-uhd.so > > > > -- Checking for module 'gnuradio-fcd' > > > > > > -- No package 'gnuradio-fcd' found > > > > > > -- gnuradio-fcd not found. > >
Re: pybombs install gr-osmosdr ........ bunch of errors
Hi Fernando, GNU Radio itself doesn't interface with the bladeRF directly, at all – things like gr-osmosdr do. Hence, there's absolutely no need to build GNU Radio from source. Instead: 1. Get a modern GNU Radio (3.8.0.0 as of writing) as a binary package via our PPA [1]: sudo add-apt-repository ppa:gnuradio/gnuradio-releases sudo apt update sudo apt install gnuradio 2. build the libbladerf from source that can talk to your BladeRF. Install it. 3. build gr-osmosdr from source so that you get GNU Radio blocks to use that libbladerf Best regards, Marcus [1] https://launchpad.net/~gnuradio/+archive/ubuntu/gnuradio-releases On Mon, 2020-01-13 at 21:53 +0100, Fernando wrote: > As I reported before I'm trying to use a new bladeRF 2.0 in gnuradio but it > does not work with the bladeRF in the ubuntu repos, so I'm trying to install > gnuradio and gr-osmosdr with pybombs > > I'm using ubuntu 19.04. The precess i have followed is the following: > > sudo apt install git > sudo apt install python3 > sudo apt install python3-pip > sudo pip3 install --upgrade git+https://github.com/gnuradio/pybombs.git > pybombs auto-config > pybombs recipes add-defaults > sudo apt install git cmake g++ libboost-all-dev libgmp-dev swig python3-numpy > \ > python3-mako python3-sphinx python3-lxml doxygen libfftw3-dev libcomedi-dev \ > libsdl1.2-dev libgsl-dev libqwt-qt5-dev libqt5opengl5-dev python3-pyqt5 \ > liblog4cpp5-dev libzmq3-dev python3-yaml python3-click python3-click-plugins \ > python3-zmq > pybombs prefix init ~/gnuradio -R gnuradio-default > > pybombs install gr-osmosdr > there comes the error: mpir not found, then I have installed mpir > > sudo apt install yasm > I have installed mpir3.0.0 from > http://mpir.org/downloads.html > > > and then > > > > grc@gnuradio:~$ pybombs install gr-osmosdr > [INFO] Prefix Python version is: 3.7.3 > [INFO] PyBOMBS Version 2.3.4a0 > [INFO] Phase 1: Creating install tree and installing binary packages: > Install tree: > | > \- gr-osmosdr > [INFO] Phase 1 complete: All binary dependencies installed. > [INFO] Phase 2: Recursively installing source packages to prefix: > [INFO] Installing package: gr-osmosdr > [WARNING] Build dir already exists: /home/grc/gnuradio/src/gr-osmosdr/build > Configuring: (100%) > [==] > [WARNING] Configuration failed. Re-trying with higher verbosity. > -- Extracting version information from git describe... > -- Configuring Boost C++ Libraries... > -- Boost version: 1.67.0 > -- Found the following Boost libraries: > -- thread > -- system > -- chrono > -- date_time > -- atomic > -- Checking for module 'gmp' > -- No package 'gmp' found > -- Checking for module 'mpir >= 3.0' > -- No package 'mpir' found > -- Could NOT find MPIR (missing: MPIRXX_LIBRARY MPIR_INCLUDE_DIR) > > > -- Checking for module 'gnuradio-iqbalance' > > > -- No package 'gnuradio-iqbalance' found > > > -- Found gnuradio-uhd: /home/grc/gnuradio/include, > /home/grc/gnuradio/lib/libgnuradio-uhd.so > > -- Checking for module 'gnuradio-fcd' > > > -- No package 'gnuradio-fcd' found > > > -- gnuradio-fcd not found. > > > -- Could NOT find GNURADIO_FCD (missing: GNURADIO_FCD_LIBRARIES > GNURADIO_FCD_INCLUDE_DIRS) > > -- Checking for module 'gnuradio-fcdproplus' > > > -- No package 'gnuradio-fcdproplus' found > > > -- gnuradio-fcdproplus not found. > > > -- Could NOT find GNURADIO_FCDPP (missing: GNURADIO_FCDPP_LIBRARIES > GNURADIO_FCDPP_INCLUDE_DIRS) > > -- Checking for module 'libmirisdr'
Re: FT8 with GNU radio and the PlutoSDR on the 2 meters band
Hey Adrian, that's nice! Generally: you said you couldn't implement an ALC: what's an ALC? Best regards, Marcus Mon, 2020-01-13 at 16:40 +, Adrian Musceac wrote: > Hi, > > I wrote a report about combining WSJTX and GNU radio with a PlutoSDR > transceiver to achieve FT8 contacts on the 144 MHz amateur radio band. The > short summary is that I achieved contacts at over 800 km and heard stations > as far as 1000 km last month in excellent tropo propagation conditions with > 20 Watts of output power. > I thought you might be interested in reading this, but it's too long to paste > here. > > The report can be read here: > http://qradiolink.org/ft8-plutosdr-2meters.html > > Adrian YO8RZZ smime.p7s Description: S/MIME cryptographic signature
Re: gr-iqbal, gr-fosphor, gr-osmosdr updated to Gnuradio 3.8
Jep; that's why I also upload all GNU Radio release tarballs to github. Cheers Marcus On Wed, 2020-01-08 at 17:59 +0100, Andrej Rode wrote: > Hi Phil, > > > > > You either need to make and host your own, or download from the > > > github mirror ( https://github.com/osmocom/gr-iqbal/releases ) > > > > Standard warning, github is known to regenerate tarballs with > > different contents that lead to sha has mismatches with time making > > it hard to validate the downloaded tarball. Don't depend on githb > > downloaded tarballs if you care about supply chain integrity. > > This is a bit imprecise: The contents of the tarball are not > different, but rather are timestamps might differ for _automatic_ > generated tarballs. This is due to GitHub sometimes regenerating > tarballs on the fly. > > If a release tarball is created manually and > uploaded as asset for a release tag there is no problem. > > Cheers > A > smime.p7s Description: S/MIME cryptographic signature
Re: GRC General Comment & Question
Dear John, you mean an external device that can interact with GNU Radio's sample streams? Well, I'd say it's not very hard per se – all you need is to write a driver for that device. That driver needs to have an interface that you can use to transmit samples from your PC to the device, or get samples from that device into your PC. Then, you'd call that from within a GNU Radio block. It's pretty much exactly what the USRP sink and source, or the audio sink and source do. The question of "how hard is it" is, however, tends to be dominated by boundary conditions: How fast do you need things to be? How experienced are you at building devices, and how experienced at writing drivers? Or do driver and device already exist, and you only need to write that GNU Radio block? Then it's mostly a question of programming proficiency. Best regards, Marcus On Wed, 2020-01-08 at 06:41 -0500, John Wood via GNU Radio, the Free & Open-Source Toolkit for Software Radio wrote: > Good morning Marcus, and to the other erudite, frequent contributors to this > e-mail list. I'm far from a subject matter expert on the GNU Radio Companion > (GRC) but consider it to be one of the best examples of a user-friendly, > mouse-driven, object-oriented programming environment. My hat's off to its > original creator(s). Oh yeah, and the price is right ;-) The number of > devices/tools available right out of the box is quite impressive IMO and the > fact that GRC generates executable Python source code is a bonus. My > question is how relatively difficult is it to create a new device (USRP, > filters, modulators etc) that can be dragged to the GRC work area? Thanks > for your time and comment. VTY, > > > J.B. Wood smime.p7s Description: S/MIME cryptographic signature
Re: wimax chain
Hi Eitan, > specifically - mimo-ofdm over wimax As I said, it's unlikely someone else wrote exactly what you're supposed to build before. I'm currently not taking development projects, but: it's a pretty normal thing to pay for contract GNU Radio development, so I'm sure we can help you find someone to work for you! Of course, the mailing list is always open to your questions, so if you have any questions to what I (or others) have written here before, do not hesitate to ask about specifics! Best regards, Marcus On Sun, 2019-12-22 at 14:17 +0200, Eitan Hetzroni wrote: > specifically - mimo-ofdm over wimax > > On Sun, Dec 22, 2019 at 1:13 PM Eitan Hetzroni > wrote: > > anyone with any progress on the wimax?will to even pay for a > > working chain - cant figure out where to find a grc chain. > > > > On Wed, Nov 20, 2019 at 3:29 PM Müller, Marcus (CEL) < > > muel...@kit.edu> wrote: > > > Hi, > > > ah! OK, yeah, that's unfortunate. > > > > > > So, the easy thing about OFDM: as soon as you know where your > > > symbol > > > starts, all you need to do is apply an FFT – and you're done. > > > (you will > > > still have to "equalize" your reception, but that is a point-wise > > > multiplication at the output of the FFT.) > > > > > > So, if I was to recommend a methodology for solving this: Start > > > with > > > building a fixed-lag correlator to find the beginning of > > > symbols. > > > You're not the first person to have to do that: > > > The gr-dab module [1] contains one such, that you'd only have to > > > parameterize to use the length and sizes of OFDM symbols in WiMaX > > > instead of these in DAB+. (I actually recommend looking at gr- > > > dab's > > > receiver; it's a nice display of how to demodulate OFDM > > > downlinks.) > > > You'll be getting output that you can threshold to get the > > > beginnings > > > of symbols, then you just start taking FFTs at these positions, > > > and in > > > those, you look for the preamble symbols to get the equalizer > > > taps. > > > > > > Best regards, > > > Marcus > > > > > > [1] https://github.com/kit-cel/gr-dab > > > On Wed, 2019-11-20 at 15:19 +0200, Eitan Hetzroni wrote: > > > > hello, > > > > it is an ofdm system, but i could not get to tweak the ofdm_Rx > > > example to find the preamble in the transmission i was looking to > > > capture. > > > > > > > > On Wed, Nov 20, 2019 at 3:16 PM Müller, Marcus (CEL) < > > > muel...@kit.edu> wrote: > > > > > Hi Eitan, > > > > > > > > > > please keep replies on the list! > > > > > I don't think there's a readymade solution for you. > > > > > > > > > > I'm not quite sure what you mean with "resemble OFDM": could > > > you > > > > > elaborate? I really thought that IEEE802.16 is a pure OFDM > > > system, so > > > > > this comes as a surprise. In which way is it not? > > > > > > > > > > Best regards, > > > > > Marcus > > > > > > > > > > On Wed, 2019-11-20 at 15:13 +0200, Eitan Hetzroni wrote: > > > > > > thanks for the rapid reply, > > > > > > it does resemble ofdm, however as a beginner in the field i > > > was hoping to find a readymade chain to tweak with? > > > > > > > > > > > > > > > > > > On Wed, Nov 20, 2019 at 3:11 PM Müller, Marcus (CEL) < > > > muel...@kit.edu> wrote: > > > > > > > Hi Eitan, > > > > > > > > > > > > > > it's been a while since I've looked into IEEE802.16, but > > > that's a very > > > > > > > regular OFDM system, isn't it, with a fixed OFDM symbol > > > as short > > > > > > > preamble (for the downlink bursts), and a 2-symbol > > > preamble for the > > > > > > > start of frame? > > > > > > > > > > > > > > A simple correlation detector might do in that case; a > > > bit nicer on the > > > > > > > acquisition speed per computational effort might be a > > > fixed-length > > > > > > > correlator that detects the position of cyclic prefixes > > > and could b
Re: Xlating FIR filter delay
Hi Angilberto, On Thu, 2019-12-19 at 15:13 +, Angilberto Muniz Sb wrote: > In the docs it says the xlating fir filter is a symmetric one, certainly not in general. The FIR filter can whatever filter you put in there. You're thinking of an example somewhere! So, what docs *specifically* say that? > has linear phase shift and causes no phase distortion. I'd agree with "if it's symmetric, it's got a linear phase shift". I wouldn't fully agree with "no phase distortion", because it's still a frequency-dependent shift. > Lets say I have the following setup: > > x(t) = cos(wt), > s1(t) = x(t) upshiffted to w1, s2(t) = x(t) upshiffted to w2 > > s(t) = s1(t) + s2(t). > > Now, I apply two xlating filters to s(t): > > r1(t) = s(t) filtered and downconverted to w > r2(t) = s(t) filtered and downconverted to w > > I see a phase shift (or time delay) between x(t) and r1(t) or r2(t). Yes, that's *group delay*. Best regards, Marcus smime.p7s Description: S/MIME cryptographic signature
Re: Xlating FIR filter delay
Ah, no! So, what you're seeing is no processing delay caused by our implementation of the xlating FIR filter, but simply *group delay*, which every linear system has. I don't know your background, so it's a bit hard to recommend some literature, but group delay would be covered in a "signals and systems" text book. > Guess I've found the answer: > (len(filter_taps) - 1) / 2 That is true ONLY if your filter has linear phase. It has linear phase iff it's symmetric to the center tap. Best regards, Marcus On Thu, 2019-12-19 at 14:08 +, Angilberto Muniz Sb wrote: > Yes Marcus, I'm interested in the "excess" delay, thats why I need to cancel > the group delay. > > Guess I've found the answer: > > (len(filter_taps) - 1) / 2 > > Will try it.. > > > Angilberto. > > > Em quinta-feira, dezembro 19, 2019, 9:16 AM, Müller, Marcus (CEL) > escreveu: > > > Hi Angilberto, > > > > am I right to assume that you already are considering the group delay > > of the filter that you specified and there's "excess" delay beyond > > that? > > > > Best regards, > > Marcus > > > > On Wed, 2019-12-18 at 19:59 +, Angilberto Muniz Sb wrote: > > > Hi all, > > > > > > I have a dual tone signal that I down convert and split into two common > > > frequency signals with the Xlating-fir filter. So far so good. > > > > > > However I noticed there is a phase shift between the signals generated (I > > > assume this is due the filter delay). I have to compensate for that. > > > > > > The question: How to determine or estimate that delay? > > > > > > Thank you, > > > > > > > > > Angilberto. smime.p7s Description: S/MIME cryptographic signature
Re: Xlating FIR filter delay
Hi Angilberto, am I right to assume that you already are considering the group delay of the filter that you specified and there's "excess" delay beyond that? Best regards, Marcus On Wed, 2019-12-18 at 19:59 +, Angilberto Muniz Sb wrote: > Hi all, > > I have a dual tone signal that I down convert and split into two common > frequency signals with the Xlating-fir filter. So far so good. > > However I noticed there is a phase shift between the signals generated (I > assume this is due the filter delay). I have to compensate for that. > > The question: How to determine or estimate that delay? > > Thank you, > > > Angilberto. smime.p7s Description: S/MIME cryptographic signature
[GSoC] GSoC 2020 is coming // new org admin
Hi all! Google's Summer of Code 2019 has definitely been a success for GNU Radio and we're already looking towards 2020! Organization applications open in about 4 weeks, so it's again time to think about new project ideas! If you have something in mind that is feasible to do within 3 months, please share your ideas here on the list or on Slack/IRC, so we can add it to the wiki. Next year's GSoC will, however, no longer be organized by me. I'm very happy to announce that Sebastian Koslowski has agreed to take over as org admin and will therefore coordinate GNU Radio's GSoC participation from now on! So please make him for him as easy as it was for me and start thinking about student projects (and mentoring them ;) )! Cheers, Felix
Re: gr-iqbal, gr-fosphor, gr-osmosdr updated to Gnuradio 3.8
Wow, Sylvain, this is awesome! Especially: thank you for handling the "obscure" special 3.7+qt5 case. Cheers, Marcus On Sun, 2019-12-08 at 21:31 +0100, Sylvain Munaut wrote: > Hi, > > I have just pushed updates to various osmocom repositories, updating > them to run on gnuradio 3.8. > > Here's the status per project : > > * gr-iqbal : >- Old gnuradio 3.7 version been forked into a 'gr3.7' branch and > will remain there. It won't be maintained and will most likely never > receive any further updates. >- 'master' now contains the gnuradio 3.8 compatible code and the > latest version has also been tagged. > > * gr-fopshor : >- The gnuradio 3.7 version actually got updated a bit with some new > functionality, then moved over to also a 'gr3.7'. Again, I won't > backport future features to it so I don't really expect any further > updates. >- Because I know some distribution still maintain a gnuradio 3.7 > package but removed Qt4 (and so ported gnuradio to Qt5), I also > created a 'gr3.7-qt5' branch that's designed to work with gnuradio 3.7 > but using Qt5 instead of Qt4. >- Finally, 'master' contains the gnuradio 3.8 compatible code. ATM > there is no functional (as in 'fosphor features') differences with the > two others, it's just Qt5 support and Makefile changes. >- A couple of the interesting new features that have been added : > . Fixes the long standing bug of NVidia CL/GL sharing not working > (thanks Aaron Giles for figuring out root cause) > . Memory leak fix (thanks Emil Berg for reporting) > . Improved CL device compatibility check before trying to use > them (thanks to Ethan Trewhitt) > . Allow explicit selection of the CL device via FOSPHOR_CL_DEV > env var if you have several CL platform/devices. > > * gr-osmosdr : > - 'master' is still 3.7 version, same code as before but has been > tagged and a 'gr3.7' branch has been created in anticipation that > master will become 3.8 > - An experimental 'gr3.8' branch has been added that contains an > upgrade to Gnuradio 3.8 (based off the work from Mickey Vänskä and > Maitland Bottoms). > . I tested it with UHD / Blade RF / Hack RF which are all the > devices I have available. > . It also adds support for the Airspy HF courtesy of Alexandru Csete > . Still feel free to use it as base for packaging and report any > additional patch you have to apply for the build. > . Once I have enough success report, this will land in master. > . Currently the utilities in apps _have_not_ been ported to 3.8 > (especially GUI changed to Qt5) ... if anyone wants to do that and > send me a diff, that would be _very_ welcome and I'll include that in > this branch. > > > Cheers, > > Sylvain Munaut > > PS: bcc'd package maintainer I thought of. > smime.p7s Description: S/MIME cryptographic signature
Re: Is there anything about USRP blocks that breaks them within hier blocks?
Glad to help! NB: the null source-to-sink trick might consume up to two CPU cores completely and thus contribute to global warming as much as about 1.5 ppb of the total bitcoin infrastructure ;) Cheers, Marcus On Fri, 2019-12-06 at 05:21 +0100, Lukas Haase wrote: > Dear Marcus, Dear Kevin, > > On 2019-12-05 22:21, Kevin Reid wrote: > > On Thu, Dec 5, 2019 at 1:04 AM Müller, Marcus (CEL) > <mailto:muel...@kit.edu>> wrote: > > > > > However, with your zero in- and output hier block, > > > top_block.connect(something) was *never* called with the hier block, > > > and hence, the hier block didn't become part of a flow graph that is > > > to be executed. It's just a graph that *exists*, not one that *does* > > > something. > > > > > > TL;DR: can't use a hier block without outside connections, since > > > that's not becoming part of the top_block that'll be executed. > Wow, that was exactly the answer I was looking for. > I would have never guessed that. > I added a "Null Source" outside and a "Null Sink" inside and indeed, it works > not as expected. > > In addition to the usual connect() that takes two blocks, there is also > > a connect() method overload that takes only one block, specifically to > > enable adding a block with no connections to a parent hier block or top > > block. > > https://www.gnuradio.org/doc/doxygen/classgr_1_1hier__block2.html#ab21892550c8fea3867628400bb8ed0be > > Thank you. > > > I just tested this case — GRC fails to generate an appropriate connect() > > call in the top block, but if I add one, then the blocks within the hier > > block execute as expected. I have filed > > issue https://github.com/gnuradio/gnuradio/issues/2950 about this. > > Wonderful, thank you. > > Luke > > smime.p7s Description: S/MIME cryptographic signature
Re: Is there anything about USRP blocks that breaks them within hier blocks?
Hi Lukas, hi Marcus the prime, the UHD blocks *can't* know they're in a hier block. That information is not available to them, at all. "Hier Block" is just a flow-graph construction-time concept: It doesn't exist when the UHD block is constructed, and it doesn't exist when the flow graph starts executing. _BUT_: When you run a GNU Radio flowgraph, you call the start() method of a top_block, which is essentially a hier block containing the whole flow graph. It was told which blocks and connections (vertices and edges) make up the flow graph, by being told to top_block.connect(start,end) blocks. In the case of hier blocks, the connect() thing basically leads to a recursive addition of the subgraph contained in the hier block. However, with your zero in- and output hier block, top_block.connect(something) was *never* called with the hier block, and hence, the hier block didn't become part of a flow graph that is to be executed. It's just a graph that *exists*, not one that *does* something. TL;DR: can't use a hier block without outside connections, since that's not becoming part of the top_block that'll be executed. Best regards, Marcus the second On Wed, 2019-12-04 at 16:44 -0500, Marcus D. Leech wrote: > On 12/04/2019 04:08 PM, Lukas Haase wrote: > > Hi Marcus, > > > > > > > > No, unofrtunately. > > > > 0 gain is still something like -10dBm. Huge and clearly visible on a > > spectrum analyzer. > > Where the exact tone is doesn't matter because my span is 10Mhz (I actually > > meant 915MHz) and I used full span to look at the entire frequency range. > > > > The point is: I filled all numbers in numerically and everything works if > > the URSP Source is in my main block. Then I *copy and paste* everything (to > > avoid any doubts) into a hier-block, put in the hier block and it stops > > working. I showed the exact screenshots. > > Even the leakage from the USRP itself is gone which means that the USRP > > just turns off, crashed badly or similar. > > > > This is either a weird bug or we are not supposed to use the USRP block > > within a hier block. > > > > Thanks, > > Luke > > > > > The USRP source wouldn't really have any "idea" that it's inside a hier > block. This may be a weird Gnu Radio limitation--hier blocks normally >have at least an input, and usually an input and an output. But a GR > expert might want to chime in about whether this case "works". > > > > smime.p7s Description: S/MIME cryptographic signature
Re: Stream args on UHD USRP Sink
As said, I'm almost certain you can absorb that multiplication in anything else you're doing already. On Tue, 2019-12-03 at 21:00 -0300, Wheberth Damascena Dias wrote: > Yeah, You are right, > > My initial thougth was, UHD already needs to scale whatever comes in to the > DAC range. If it could take in account this extra scaling I could save the > constant multiplier block. > > Best Regards. > > Em ter, 3 de dez de 2019 15:24, Müller, Marcus (CEL) > escreveu: > > I'd recommend not overestimating the workload of scaling outside of UHD > > – UHD still has to do that multiplication! So, scaling e.g. your > > constellation or your pulse-shaping filter would make at least as much > > sense. > > > > On Tue, 2019-12-03 at 14:11 -0300, Wheberth Damascena Dias wrote: > > > Hi Marcus, I > > > > > > I am planning to give a try to the GnuRadio 3.8 PPA. We are developing > > > some OOT blocks and some rework may be needed to do so. > > > > > > I will take a look at the code, but I am inclined to change my > > > application to eliminate the need of scaling in real time (scalling the > > > QAM symbols for example) > > > > > > Regarding the USRP I am using a pair of X310. > > > > > > Thank you very much. > > > Wheberth > > > > > > > > > Em ter, 3 de dez de 2019 13:26, Müller, Marcus (CEL) > > > escreveu: > > > > U that's an ancient version of GNU Radio. Do you use any other UHD- > > > > linking software, or can you try our new PPA that would give you a > > > > modern GNU Radio 3.8.0.0? > > > > > > > > https://launchpad.net/~gnuradio/+archive/ubuntu/gnuradio-releases > > > > > > > > Anyway, for most USRPs "fullscale" actually should do some scaling (if > > > > you're so inclined, look for "_host_extra_scaling" in the UHD source > > > > code). > > > > > > > > What is the USRP you're using? > > > > > > > > Best regards, > > > > Marcus > > > > > > > > On Tue, 2019-12-03 at 08:41 -0300, Wheberth Damascena Dias wrote: > > > > > Hi all, not sure if I should send this here or at USRP list. > > > > > > > > > > I am trying to set the "fullscale" as a stream parameter of the USRP > > > > > Sink block, but it have no effect. The idea is to avoid the use aof > > > > > one block to scale the samples to [-1.0, +1.0] range May I be missing > > > > > something? > > > > > > > > > > For reference I am using GnuRadio 3.7.11 with libuhd 3.10.3 (All > > > > > stock from Ubuntu 18.04). > > > > > Thank you very > > > > > > > > > > > > > > > > > > > > -- > > > > > Wheberth Damascena Dias > > > > > ___ _ _ __ ___ __ _ _ _ _ > > > > > http://www.linkedin.com/in/wheberth > > > > > e-mail:whebe...@gmail.com > > > > > smime.p7s Description: S/MIME cryptographic signature
Re: gr_modtool crash
Yeah, packaging mishaps happen, and especially with Ubuntu/Canonical mostly grazing uninvolvedly on Mait's effort in the debian space, they sometimes slip by. I'm super thankful Mait is so agile when it comes to fixing the debian packages! On Tue, 2019-12-03 at 17:55 +, César MR wrote: > It worked! > > Oddly, newmod didn’t work in a fresh Ubuntu minimal installation. Thank you! > > > > De: Maitland Bottoms > Enviado: martes, 3 de diciembre de 2019 17:16 > Para: César MR; discuss-gnuradio@gnu.org > Asunto: Re: gr_modtool crash > > César MR writes: > > > Hi! I'm trying to follow the tutorial about working with gnuradio in c++, > > which can be found in the wiki, but i when i try to run gr_modtool, it > > crash. At first i thought that it was because of my language, so i changed > > my linux mint language to UK english, but it didn't work. > > > > In addition i had to run gr_modtool with admin privileges in order to get > > a crash report in /var/crash directory. > > > > You can download the whole crash log here: https://mega.nz/#!yLxRGaRI > > > > What do you think is the root of my problem? thank you > > That is a Debian packaging of gnuradio bug that mint inherited. > This is also found in Debian 10 "Buster" gnuradio 3.7.13.4-4. > > The problem comes from Python byte-compiled files used as templates. > > The solution is to remove all .pyc files found under > /usr/share/gnuradio/modtool/gr-newmod > especially: > /usr/share/gnuradio/modtool/gr-newmod/python/build_utils_codes.pyc > /usr/share/gnuradio/modtool/gr-newmod/python/build_utils.pyc > /usr/share/gnuradio/modtool/gr-newmod/python/__init__.pyc > > I missed these becasue they are not present in the .deb, but are > generated when the package is installed. > > Recent (gnuradio 3.8) Debian packages no longer byte-compile any Python > under /usr/share/gnuradio/ - solving this problem. > > Easiest fix is just > `sudo rm /usr/share/gnuradio/modtool/gr-newmod/python/*pyc` > > Good luck, > -Maitland > smime.p7s Description: S/MIME cryptographic signature
Re: Stream args on UHD USRP Sink
I'd recommend not overestimating the workload of scaling outside of UHD – UHD still has to do that multiplication! So, scaling e.g. your constellation or your pulse-shaping filter would make at least as much sense. On Tue, 2019-12-03 at 14:11 -0300, Wheberth Damascena Dias wrote: > Hi Marcus, I > > I am planning to give a try to the GnuRadio 3.8 PPA. We are developing some > OOT blocks and some rework may be needed to do so. > > I will take a look at the code, but I am inclined to change my application to > eliminate the need of scaling in real time (scalling the QAM symbols for > example) > > Regarding the USRP I am using a pair of X310. > > Thank you very much. > Wheberth > > > Em ter, 3 de dez de 2019 13:26, Müller, Marcus (CEL) > escreveu: > > U that's an ancient version of GNU Radio. Do you use any other UHD- > > linking software, or can you try our new PPA that would give you a > > modern GNU Radio 3.8.0.0? > > > > https://launchpad.net/~gnuradio/+archive/ubuntu/gnuradio-releases > > > > Anyway, for most USRPs "fullscale" actually should do some scaling (if > > you're so inclined, look for "_host_extra_scaling" in the UHD source > > code). > > > > What is the USRP you're using? > > > > Best regards, > > Marcus > > > > On Tue, 2019-12-03 at 08:41 -0300, Wheberth Damascena Dias wrote: > > > Hi all, not sure if I should send this here or at USRP list. > > > > > > I am trying to set the "fullscale" as a stream parameter of the USRP Sink > > > block, but it have no effect. The idea is to avoid the use aof one block > > > to scale the samples to [-1.0, +1.0] range May I be missing something? > > > > > > For reference I am using GnuRadio 3.7.11 with libuhd 3.10.3 (All stock > > > from Ubuntu 18.04). > > > Thank you very > > > > > > > > > > > > -- > > > Wheberth Damascena Dias > > > ___ _ _ __ ___ __ _ _ _ _ > > > http://www.linkedin.com/in/wheberth > > > e-mail:whebe...@gmail.com > > > smime.p7s Description: S/MIME cryptographic signature
upgrading to 3.8 (was: Re: Stream args on UHD USRP Sink)
Hi Glen, On Tue, 2019-12-03 at 12:20 -0500, Glen Langston wrote: > Hi > > This is a general question about upgrade to python 3 and gnu radio 3.8. > > We’ve got some custom C++ and Python code that will need to be installed. > The python ran in version 2.7. This is working with gnuradio companion > 3.7.13.4 > > How difficult a task is upgrading? A day/week/month? Pretty much impossible to say, but if you say "some", I'd assume it's in the range of single-digits hours. See: https://wiki.gnuradio.org/index.php/GNU_Radio_3.8_OOT_Module_Porting_Guide Best regards, Marcus smime.p7s Description: S/MIME cryptographic signature
Re: Stream args on UHD USRP Sink
U that's an ancient version of GNU Radio. Do you use any other UHD- linking software, or can you try our new PPA that would give you a modern GNU Radio 3.8.0.0? https://launchpad.net/~gnuradio/+archive/ubuntu/gnuradio-releases Anyway, for most USRPs "fullscale" actually should do some scaling (if you're so inclined, look for "_host_extra_scaling" in the UHD source code). What is the USRP you're using? Best regards, Marcus On Tue, 2019-12-03 at 08:41 -0300, Wheberth Damascena Dias wrote: > Hi all, not sure if I should send this here or at USRP list. > > I am trying to set the "fullscale" as a stream parameter of the USRP Sink > block, but it have no effect. The idea is to avoid the use aof one block to > scale the samples to [-1.0, +1.0] range May I be missing something? > > For reference I am using GnuRadio 3.7.11 with libuhd 3.10.3 (All stock from > Ubuntu 18.04). > Thank you very > > > > -- > Wheberth Damascena Dias > ___ _ _ __ ___ __ _ _ _ _ > http://www.linkedin.com/in/wheberth > e-mail:whebe...@gmail.com > smime.p7s Description: S/MIME cryptographic signature
Re: Re: Gnuradio 3.8 on Windows generates negative return codes
Correct me, as I'm really not a Visual Studio expert but: VS2008 predates C++11 support; you shouldn't be able to sensibly use it for GNU Radio 3.8's C++11 codebase. If I remember correctly, that's why we set the minimum MSVC version to 1800 (which corresponds to Visual Studio 2012, I think). Best regards, Marcus On Sat, 2019-11-30 at 10:57 -0500, Geof Nieboer wrote: > > I have Visual Studio 2008 installed for C++ development. However, > I do not understand how this works with python. > > I'm not sure if VS 2008 supports python debugging, but I know that > 2015 does, just have to be sure that the python features are > installed. Then you can create a python-based project, then add the > existing .py file to it, and "Step Into" Run like a C++ file. The > only tricky part is setting up the python environment correctly, but > the variables you need are all in the run_gr.bat file. > > A simpler but cruder option is the old "add print 'made to here' > lines everywhere" and let us know where it's dying. Unfortunately I > suspect it will be on "tb.start()" which won't provide much of a > smoking gun. > > Geof > > On Fri, Nov 29, 2019 at 7:00 PM Lukas Haase > wrote: > > Hi Geof, > > > > Thank you very much for your help. > > > > On 2019-11-29 17:37, Geof Nieboer wrote: > > > Lukas, > > > > > > [...] > > > > > > So obviously something is failing early in the python script > > before it > > > really gets the flowgraph going. That error code is fairly > > vague, > > > google tells me it's a generic system error. > > > > > > Please try this, open the GR command prompt, and attempt to run > > the > > > generated python file manually, and see if it produces any more > > useful > > > detail. > > > > Nope, nothing: > > > > O:\local>python test_qt.py > > > > O:\local> > > > > > The next step after that would be to try to run the python > > > script in Visual Studio (or your preferred debugger) in debug > > mode and > > > figure out what line is causing the failure. > > > > Could you elaborate on this briefly? > > > > I have Visual Studio 2008 installed for C++ development. However, I > > do not understand how this works with python. > > > > > Another thing to try to would be to run it as admin and see if > > anything > > > different occurs. Also try setting to "No Gui" just for kicks. > > > > As admin: exactly the same output. > > > > No Gui: exactly the same. > > > > > The fact that the second flowgraph does show the radio > > initializing is a > > > good sign, it shows that block is starting up as expected. > > > > I should have mentioned that this one is from another workstation > > (same version/configuration). > > > > Additionally: Resizing the companion window makes it crash: > > > > Assertion failed: CAIRO_REFERENCE_COUNT_HAS_REFERENCE (&surface- > > >ref_count), file cairo-surface.c, line 955 > > > > (for this one I will file a bug report). > > > > > > Thanks, > > Luke > > > > smime.p7s Description: S/MIME cryptographic signature
Re: Signal Tracking
Hi Sarandis, you can change the center frequency of the osmocom source by calling the appropriate setter function. In GRC, that is automatically done when you change the variable that you used there, for example with a slider. Now, you seem to want to do that automatically: just write a bit of python code with a for loop, and use it to modify your variable. This is not a sample-accurate thing: the clock of your PC has not much to do with the clock of your SDR device (whatever that is), so you need to account very much for that. "Video bandwidth" is a term that only applies to old-school mixer/filter-based spectrum analyzers, not quite sure what you mean with that here. There's no video. Best regards, Marcus On Tue, 2019-11-26 at 18:38 +0200, sarandis. Doulgeris wrote: > Hi. Is there a way to change the center frequency of osmocom source, having > the video bandwidth steady, automatically at a given rate istead of a range > variable? smime.p7s Description: S/MIME cryptographic signature
Re: UHD: USRP source issue when using 2 channels
I'm s close to shouting out "ha-ha! Integer signedness error!", but I think chances are this was fixed on master in 8eb1a354c0b5126b6c0b7d55b68963a155088b3a. On Thu, 2019-11-21 at 01:57 -0800, Ron Economos wrote: > I have the same issue, but the error message is different. > > Traceback (most recent call last): >File "/home/re/xfer/uhdrx.py", line 213, in > main() >File "/home/re/xfer/uhdrx.py", line 191, in main > tb = top_block_cls() >File "/home/re/xfer/uhdrx.py", line 97, in __init__ > self.uhd_usrp_source_0.set_center_freq(center_freq, 1) >File > "/opt/gnuradio-3.7.12git/lib/python3.6/dist-packages/gnuradio/uhd/uhd_swig.py", > > line 3600, in set_center_freq > return _uhd_swig.usrp_source_sptr_set_center_freq(self, *args) > RuntimeError: LookupError: IndexError: multi_usrp: RX channel > 140641462873248 out of range for configured RX frontends > > >>> Done (return code 1) > > Ron > > On 11/21/19 00:43, jean-michel.fri...@femto-st.fr wrote: > > Am I the only one facing an issue with fetching data from 2 channels of a > > B210 receiver ? > > When addressing a single channels (USRP Source -> file sink) all goes well, > > but > > whenever I activate a second channel (Num Mboards=1, Num Channels=2) I get > > an error message > > > > tb = top_block_cls() > > File "/tmp/GPS.py", line 103, in __init__ > > self.connect((self.uhd_usrp_source_1, 1), (self.blocks_null_sink_0, 0)) > > File > > ".../gnuradio3.8/lib/python3.7/dist-packages/gnuradio/gr/hier_block2.py", > > line 48, in wrapped > > func(self, src, src_port, dst, dst_port) > > File > > ".../gnuradio3.8/lib/python3.7/dist-packages/gnuradio/gr/hier_block2.py", > > line 111, in connect > > self.primitive_connect(*args) > > File > > ".../gnuradio3.8/lib/python3.7/dist-packages/gnuradio/gr/runtime_swig.py", > > line 5461, in > > primitive_connect > > return _runtime_swig.top_block_sptr_primitive_connect(self, *args) > > RuntimeError: port number 1 exceeds max of 0 > > > > whatever sink (file, null) is attached to the UHD output. I am facing the > > issue > > with custom 3.8.0.0-rc2 (Python 3.7.5) or the current Debian/sid 3.8.0.0 > > (Python 3.7.5) versions of GNU Radio Companion. > > > > The flowchart with the issue is at http://jmfriedt.org/GPS.pdf > > > > Thanks, JM > > > > smime.p7s Description: S/MIME cryptographic signature
Re: wimax chain
Hi, ah! OK, yeah, that's unfortunate. So, the easy thing about OFDM: as soon as you know where your symbol starts, all you need to do is apply an FFT – and you're done. (you will still have to "equalize" your reception, but that is a point-wise multiplication at the output of the FFT.) So, if I was to recommend a methodology for solving this: Start with building a fixed-lag correlator to find the beginning of symbols. You're not the first person to have to do that: The gr-dab module [1] contains one such, that you'd only have to parameterize to use the length and sizes of OFDM symbols in WiMaX instead of these in DAB+. (I actually recommend looking at gr-dab's receiver; it's a nice display of how to demodulate OFDM downlinks.) You'll be getting output that you can threshold to get the beginnings of symbols, then you just start taking FFTs at these positions, and in those, you look for the preamble symbols to get the equalizer taps. Best regards, Marcus [1] https://github.com/kit-cel/gr-dab On Wed, 2019-11-20 at 15:19 +0200, Eitan Hetzroni wrote: > hello, > it is an ofdm system, but i could not get to tweak the ofdm_Rx example to > find the preamble in the transmission i was looking to capture. > > On Wed, Nov 20, 2019 at 3:16 PM Müller, Marcus (CEL) wrote: > > Hi Eitan, > > > > please keep replies on the list! > > I don't think there's a readymade solution for you. > > > > I'm not quite sure what you mean with "resemble OFDM": could you > > elaborate? I really thought that IEEE802.16 is a pure OFDM system, so > > this comes as a surprise. In which way is it not? > > > > Best regards, > > Marcus > > > > On Wed, 2019-11-20 at 15:13 +0200, Eitan Hetzroni wrote: > > > thanks for the rapid reply, > > > it does resemble ofdm, however as a beginner in the field i was hoping to > > > find a readymade chain to tweak with? > > > > > > > > > On Wed, Nov 20, 2019 at 3:11 PM Müller, Marcus (CEL) > > > wrote: > > > > Hi Eitan, > > > > > > > > it's been a while since I've looked into IEEE802.16, but that's a very > > > > regular OFDM system, isn't it, with a fixed OFDM symbol as short > > > > preamble (for the downlink bursts), and a 2-symbol preamble for the > > > > start of frame? > > > > > > > > A simple correlation detector might do in that case; a bit nicer on the > > > > acquisition speed per computational effort might be a fixed-length > > > > correlator that detects the position of cyclic prefixes and could be > > > > applied to a whole burst or even frame to get a good timing estimate > > > > before you start decoding OFDM symbols. > > > > > > > > Best regards, > > > > Marcus > > > > > > > > PS: Your email signature is kinda funny on a publicly archived mailing > > > > list :D > > > > > > > > > > > > On Wed, 2019-11-20 at 14:43 +0200, Eitan Hetzroni wrote: > > > > > Hi, > > > > > any solution to the reception (rx) or tx of wimax using gnuradio? > > > > > could not find any proper chain that finds the preamble. > > > > > > > > > > The information transmitted is intended only for the person or entity > > > > > to which it is addressed and may contain confidential and/or > > > > > privileged material. Any review, retransmission, dissemination or > > > > > other use of, or taking of any action in reliance upon, this > > > > > information by persons or entities other than the intended recipient > > > > > is prohibited. If you received this in error, please contact the > > > > > sender and delete all copies of the message. > > > > > > The information transmitted is intended only for the person or entity to > > > which it is addressed and may contain confidential and/or privileged > > > material. Any review, retransmission, dissemination or other use of, or > > > taking of any action in reliance upon, this information by persons or > > > entities other than the intended recipient is prohibited. If you received > > > this in error, please contact the sender and delete all copies of the > > > message. > > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential and/or privileged > material. Any review, retransmission, dissemination or other use of, or > taking of any action in reliance upon, this information by persons or > entities other than the intended recipient is prohibited. If you received > this in error, please contact the sender and delete all copies of the message. smime.p7s Description: S/MIME cryptographic signature
Re: wimax chain
Hi Eitan, please keep replies on the list! I don't think there's a readymade solution for you. I'm not quite sure what you mean with "resemble OFDM": could you elaborate? I really thought that IEEE802.16 is a pure OFDM system, so this comes as a surprise. In which way is it not? Best regards, Marcus On Wed, 2019-11-20 at 15:13 +0200, Eitan Hetzroni wrote: > thanks for the rapid reply, > it does resemble ofdm, however as a beginner in the field i was hoping to > find a readymade chain to tweak with? > > > On Wed, Nov 20, 2019 at 3:11 PM Müller, Marcus (CEL) wrote: > > Hi Eitan, > > > > it's been a while since I've looked into IEEE802.16, but that's a very > > regular OFDM system, isn't it, with a fixed OFDM symbol as short > > preamble (for the downlink bursts), and a 2-symbol preamble for the > > start of frame? > > > > A simple correlation detector might do in that case; a bit nicer on the > > acquisition speed per computational effort might be a fixed-length > > correlator that detects the position of cyclic prefixes and could be > > applied to a whole burst or even frame to get a good timing estimate > > before you start decoding OFDM symbols. > > > > Best regards, > > Marcus > > > > PS: Your email signature is kinda funny on a publicly archived mailing > > list :D > > > > > > On Wed, 2019-11-20 at 14:43 +0200, Eitan Hetzroni wrote: > > > Hi, > > > any solution to the reception (rx) or tx of wimax using gnuradio? > > > could not find any proper chain that finds the preamble. > > > > > > The information transmitted is intended only for the person or entity to > > > which it is addressed and may contain confidential and/or privileged > > > material. Any review, retransmission, dissemination or other use of, or > > > taking of any action in reliance upon, this information by persons or > > > entities other than the intended recipient is prohibited. If you received > > > this in error, please contact the sender and delete all copies of the > > > message. > > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential and/or privileged > material. Any review, retransmission, dissemination or other use of, or > taking of any action in reliance upon, this information by persons or > entities other than the intended recipient is prohibited. If you received > this in error, please contact the sender and delete all copies of the message. smime.p7s Description: S/MIME cryptographic signature
Re: wimax chain
Hi Eitan, it's been a while since I've looked into IEEE802.16, but that's a very regular OFDM system, isn't it, with a fixed OFDM symbol as short preamble (for the downlink bursts), and a 2-symbol preamble for the start of frame? A simple correlation detector might do in that case; a bit nicer on the acquisition speed per computational effort might be a fixed-length correlator that detects the position of cyclic prefixes and could be applied to a whole burst or even frame to get a good timing estimate before you start decoding OFDM symbols. Best regards, Marcus PS: Your email signature is kinda funny on a publicly archived mailing list :D On Wed, 2019-11-20 at 14:43 +0200, Eitan Hetzroni wrote: > Hi, > any solution to the reception (rx) or tx of wimax using gnuradio? > could not find any proper chain that finds the preamble. > > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential and/or privileged > material. Any review, retransmission, dissemination or other use of, or > taking of any action in reliance upon, this information by persons or > entities other than the intended recipient is prohibited. If you received > this in error, please contact the sender and delete all copies of the message. smime.p7s Description: S/MIME cryptographic signature
Re: gr-gsm make issue with osmosdr module
That won't work. The gr-osmosdr you install via apt will be for GNU Radio 3.7 (which you, by the way, then probably installed as dependency), and that conflicts with the GNU Radio 3.8 you're using! On Tue, 2019-11-19 at 16:23 +, Martin Spears wrote: > Kyeong Su Shin > > purged and re-installed gr-osmosdr from ubuntu package > > http://archive.ubuntu.mirror.rafal.ca/ubuntu bionic/universe amd64 gr-osmosdr > amd64 0.1.4-14build1 > > [ 71%] Linking CXX shared module _grgsm_swig.so > [ 71%] Built target grgsm_swig > [ 73%] Generating grgsm_livemon > <<< Welcome to GNU Radio Companion Compiler 3.8.0.0 >>> > > Block paths: > /home/martin/.grc_gnuradio > /home/martin/src/gr-gsm/grc > /usr/share/gnuradio/grc/blocks > /usr/local/share/gnuradio/grc/blocks > > >>> Loading: /home/martin/src/gr-gsm/apps/grgsm_livemon.grc > Traceback (most recent call last): > File "/home/martin/src/gr-gsm/python/grgsm/__init__.py", line 64, in > > from .device import * > File "/home/martin/src/gr-gsm/python/grgsm/misc_utils/device.py", line 24, > in > import osmosdr > ModuleNotFoundError: No module named 'osmosdr' > Traceback (most recent call last): > File "/home/martin/src/gr-gsm/python/grgsm/__init__.py", line 64, in > > from .device import * > File "/home/martin/src/gr-gsm/python/grgsm/misc_utils/device.py", line 24, > in > import osmosdr > ModuleNotFoundError: No module named 'osmosdr' > Traceback (most recent call last): > File "/home/martin/src/gr-gsm/python/grgsm/__init__.py", line 64, in > > from .device import * > File "/home/martin/src/gr-gsm/python/grgsm/misc_utils/device.py", line 24, > in > import osmosdr > ModuleNotFoundError: No module named 'osmosdr' > Traceback (most recent call last): > File "/home/martin/src/gr-gsm/python/grgsm/__init__.py", line 64, in > > from .device import * > File "/home/martin/src/gr-gsm/python/grgsm/misc_utils/device.py", line 24, > in > import osmosdr > ModuleNotFoundError: No module named 'osmosdr' > Traceback (most recent call last): > File "/home/martin/src/gr-gsm/python/grgsm/__init__.py", line 64, in > > from .device import * > File "/home/martin/src/gr-gsm/python/grgsm/misc_utils/device.py", line 24, > in > import osmosdr > ModuleNotFoundError: No module named 'osmosdr' > Traceback (most recent call last): > File "/home/martin/src/gr-gsm/python/grgsm/__init__.py", line 64, in > > from .device import * > File "/home/martin/src/gr-gsm/python/grgsm/misc_utils/device.py", line 24, > in > import osmosdr > ModuleNotFoundError: No module named 'osmosdr' > Traceback (most recent call last): > File "/home/martin/src/gr-gsm/python/grgsm/__init__.py", line 64, in > > from .device import * > File "/home/martin/src/gr-gsm/python/grgsm/misc_utils/device.py", line 24, > in > import osmosdr > ModuleNotFoundError: No module named 'osmosdr' > Traceback (most recent call last): > File "/home/martin/src/gr-gsm/python/grgsm/__init__.py", line 64, in > > from .device import * > File "/home/martin/src/gr-gsm/python/grgsm/misc_utils/device.py", line 24, > in > import osmosdr > ModuleNotFoundError: No module named 'osmosdr' > Traceback (most recent call last): > File "/home/martin/src/gr-gsm/python/grgsm/__init__.py", line 64, in > > from .device import * > File "/home/martin/src/gr-gsm/python/grgsm/misc_utils/device.py", line 24, > in > import osmosdr > ModuleNotFoundError: No module named 'osmosdr' > Traceback (most recent call last): > File "/home/martin/src/gr-gsm/python/grgsm/__init__.py", line 64, in > > from .device import * > File "/home/martin/src/gr-gsm/python/grgsm/misc_utils/device.py", line 24, > in > import osmosdr > ModuleNotFoundError: No module named 'osmosdr' > Traceback (most recent call last): > File "/home/martin/src/gr-gsm/python/grgsm/__init__.py", line 64, in > > from .device import * > File "/home/martin/src/gr-gsm/python/grgsm/misc_utils/device.py", line 24, > in > import osmosdr > ModuleNotFoundError: No module named 'osmosdr' > Traceback (most recent call last): > File "/home/martin/src/gr-gsm/python/grgsm/__init__.py", line 64, in > > from .device import * > File "/home/martin/src/gr-gsm/python/grgsm/misc_utils/device.py", line 24, > in > import osmosdr > ModuleNotFoundError: No module named 'osmosdr' > Traceback (most recent call last): > File "/home/martin/src/gr-gsm/python/grgsm/__init__.py", line 64, in > > from .device import * > File "/home/martin/src/gr-gsm/python/grgsm/misc_utils/device.py", line 24, > in > import osmosdr > ModuleNotFoundError: No module named 'osmosdr' > Traceback (most recent call last): > File "/home/martin/src/gr-gsm/python/grgsm/__init__.py", line 64, in > > from .device import * > File "/home/martin/src/gr-gsm/python/grgsm/misc_utils/device.py", line 24, > in > import osmosdr > ModuleNotFoundError: No module named 'osmosd
Re: discuss-gnuradio Subject prefix (Was: Contribute to GNU radio)
I frankly don't fully follow – instead of writing a filter that sorts away your emails in folders, you could also write a filter that prefixes them with [tags]? I don't know yahoo's mail interface very well, but I'd be surprised if that functionality didn't exist. Also, it's completely up to your mail client to show all unread emails in an inbox; my K9 for android does that beautifully. On Tue, 2019-11-19 at 08:15 +, Bogdan Diaconescu wrote: > I understand the technical motivation behind this. Frankly if the e-mails are > filtered into a folder they will stay there unread forever. I like to pick > e-mails based on their subject and list for reading. If this change remains > without [gnuradio-] preamble I need to find a way to easily identify the > list. This seems a let's bring in technology to make life even more complex. > > Bogdan > > > > On Monday, November 18, 2019, 1:27:47 PM GMT+2, Adrian Musceac > wrote: > > > You're probably right, but I have to use the canine mailer with a flat view > on my phone due to screen limitations, and I suppose some other people do as > well. > For normal desktop view it's not such a big deal. > > Adrian > > On November 18, 2019 10:59:00 AM UTC, "N. Benes" wrote: > > Hi everyone, > > > > FYI, here is the general announcement of and motivation for the changes: > > > > > https://lists.gnu.org/archive/html/savannah-hackers-public/2019-06/msg00018.html > > > https://lists.gnu.org/archive/html/savannah-hackers-public/2019-09/msg00016.html > > > > Adrian Musceac: > > > I have to agree with Bogdan, it is standards complying but really > > > annoying. > > > I receive email from 10 - 15 lists and this one is the only one not > > > altering the subject. > > > > The recommended way is to use List-Id, To, and Cc. > > > > In Thunderbird, for instance, this is very easy to get via > > > > Tools --> Message Filters > > > > Then match "List-Id contains discuss-gnuradio.gnu.org" and move emails > > to a separate directory. > > > > Your 10-15 other mailing lists will likely already provide a proper > > List-Id for many years. Consider that they have the same problem with > > DKIP and, maybe, switch to (the standard complying) use of List-Id in > > the future, too. > > > > Cheers, > > nicolas > > smime.p7s Description: S/MIME cryptographic signature
Re: qt-gui problems with GNU 3.8
> generated. > #38 2180. [ 81%] Building CXX object > gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/__/include/gnuradio/qtgui/moc_spectrumdisplayform.cpp.o > #38 2180. c++: error: > /opt/truearrow/6.3/src/gnuradio/build/gr-qtgui/lib/__/include/gnuradio/qtgui/moc_spectrumdisplayform.cpp: > No such file or directory > #38 2180. c++: fatal error: no input files > #38 2180. compilation terminated. > #38 2180. make[2]: *** > [gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/build.make:714: > gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/__/include/gnuradio/qtgui/moc_spectrumdisplayform.cpp.o] > Error 1 > #38 2180. make[1]: *** [CMakeFiles/Makefile2:9430: > gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/all] Error 2 > #38 2180. make: *** [Makefile:141: all] Error 2 > #38 DONE 2180.6s > > > > > On 11/15/19, 3:50 PM, "Müller, Marcus (CEL)" wrote: > > Ah, it's the same old blues; need to have qt(4)-devel packaged for qwt. > > (What I've tried is: Run Fedora as host, and have a podman (or docker, > as if I care, replace "podman" by "docker" below) container > > marcus@workstation> podman run -it --rm centos:8) > > This is a very rough rundown of what I just did in a fresh CentOS 8 > container: > > [root@hash /]# dnf check-update; dnf install -y epel-release > [root@hash /]# dnf update -y > [root@hash /]# dnf install -y make rpm-build qt5-qt*-devel rpmdevtools > ccache > [root@hash /]# adduser mockbuild > [root@hash /]# cd > [root@hash ~]# curl -o qwt-6.1.3-11.fc31.src.rpm > > https://ftp-stud.hs-esslingen.de/pub/fedora/linux/releases/31/Everything/source/tree/Packages/q/qwt-6.1.3-11.fc31.src.rpm > [root@hash ~]# rpm -i qwt-6.1.3-11.fc31.src.rpm > > I had to hunt down a lot of qt4 lines in the qwt.spec and remove them > before this builds on CentOS 8. I have just attached a diff for a > successfully building Qwt6 on the Bug that Vasil mentioned [2], so we > can try that one; continue with > > [root@hash ~]# cd rpmbuild/SPECS > [root@hash SPECS]# rm qwt.spec > [root@hash SPECS]# curl -o qwt.spec > https://bugzilla.redhat.com/attachment.cgi?id=1636615 > [root@hash SPECS]# rpmbuild -bs qwt.spec > [root@hash SPECS]# cd ../SRPMS > [root@hash SRPMS]# rpmbuild -rb *.src.rpm > … wit … > > This should, if the build succeeds (mine is still running), give you > qwt6-qt5 packages. Install these! > > [root@hash SRPMS]# cd ../RPMS/ > [root@hash RPMS]# ls */* > noarch/qwt-doc-6.1.3-11.el8.noarch.rpm > x86_64/qwt-qt5-6.1.3-11.el8.x86_64.rpm > x86_64/qwt-qt5-devel-6.1.3-11.el8.x86_64.rpm > x86_64/qwt-debugsource-6.1.3-11.el8.x86_64.rpm > x86_64/qwt-qt5-debuginfo-6.1.3-11.el8.x86_64.rpm > [root@hash RPMS]# cd x86_64 > [root@hash x86_64]# dnf install -y * > > Try to build GNU Radio now! > > > Best regards, > Marcus > > On Fri, 2019-11-15 at 21:46 +0200, Vasil Velichkov wrote: > > Hi Mark, > > > > On 15/11/2019 21.19, Mark Koenig wrote: > > > I am trying to build gnuradio branch maint-3.8 and I am having > trouble getting qt-gui to enabled. I am currently using the new distro > CentOS 8, and I cannot find any ‘qwt’ packages. Has anyone got gnuradio to > build on CentOS 8 yet? I am very close to having all the modules I desire to > be built and enabled. > > > > > > Any help would be greatly appreciated. > > > > The qwt package is usually available from the EPEL repositories[1] but > there are still no package for epel8, see [2] > > > > [1] https://fedoraproject.org/wiki/EPEL > > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1751172 > > > > Regards, > > Vasil > > > > smime.p7s Description: S/MIME cryptographic signature
Re: GUI issues on GRC on macOS
Not the OS X expert here, but this sounds like you're having problems in your installation and did not put the icons in the right place. How did you install GNU Radio? On Mon, 2019-11-18 at 17:09 +0100, Mehdi Asgari wrote: > Hello everyone. > I have been trying to compile 3.8 on the latest version of macOS. Finally I > managed to fix all the compile-time and runtime issues. > I can confirm that the runtime and GRC are working to some extent (for > example by connecting a source to a waterfall sink and running the flow-graph > flawlessly) > But now on “gnuradio-companion”, all the sub-menu items have a single icon: a > grey display shaped icon. This is not a big issue to me, as I still can read > the tooltips and find the buttons/items, but there are some other UI related > problems as well. > > For example when I try to open the filter design tool by going to the “Tools > -> Filter Design Tool” menu, nothing happens. I just get this error in the > command line: > > ``` > /usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/subprocess.py:883: > ResourceWarning: subprocess 36222 is still running > ResourceWarning, source=self) > ResourceWarning: Enable tracemalloc to get the object allocation traceback > ``` > > But there’s no such sub-process running (in this case PID 36222) > > Here’s my build info if it helps: > GNURadio 3.8.0 built from the release zip file > QWT 6.1.4 > QT 5.12.6 > Python 3.7.5 > > Any ideas? > Thanks in advance > Mehdi smime.p7s Description: S/MIME cryptographic signature
Re: Contribute to GNU radio
Hi Bogdan, I'm afraid that's a bit out of the realm of what César can do – that's gnu.org infrastructure, and we're still (still) trying to figure out whether (and if so, how) it's possible to repair. Cheers, Marcus On Sun, 2019-11-17 at 17:53 +0200, Bogdan Diaconescu wrote: > You may start fixing the e-mail system so that it will add a prefix > to the e-mails like [gnuradio-*] Your subject. > Like it used to do before month or so ago when it was not confusing > many of us. > > Cheers, > Bogdan > > > On 15 Nov 2019, at 22:57, César fumfum > > wrote: > > > > > > Hi, > > > > I’m an engineering student of third year who have been using this > > tool for 1 year and i love GNU radio. Now i feel that i can > > contribute to this project and help the free software, but i don’t > > know if i got the needed skills. > > > > I would like to help developing tools because i know a few > > programming languages (java, c++ and Python) at a basic / > > intermediate level, and i know the basics of signal processing > > which is learnt in college. > > > > Do you got any recommendation for me? Are my skills good enough to > > start contributing to this project? > > Thanks in advance. smime.p7s Description: S/MIME cryptographic signature
Re: float-to-short conversion
You are _NOT_ an idiot. There were serious bugs in the generic implementation of several of the type conversion kernels. Best regards, Marcus On Sun, 2019-11-17 at 12:20 -0500, Marcus D Leech wrote: > Thanks Ron. > > I did some more testing, and it appears to indicate that I’m an > idiot. I won’t go into the sordid details. > > > > Sent from my iPhone > > > On Nov 17, 2019, at 6:17 AM, Ron Economos wrote: > > > > It's pretty easy to test for Volk issues. Just edit the > > ~/.volk/volk_config file and change the volk_32f_s32f_convert_16i > > line to generic for both alignments. > > > > On my older box, volk_config has u_avx for both alignments (and > > that works correctly). > > > > Ron > > > > > On 11/16/19 17:55, Marcus D. Leech wrote: > > > Is it possible that at some point the GR3.7 float-to-short > > > convert (which uses Volk, it seems) got busted? > > > > > > I'm seeing values that look like they have been inappropriately > > > byte-swapped. > > > > > > The attached flow-graph produces an output file with the correct > > > value of "7" interpreted as a Short, but when the same is run on > > > a different (still X86) machine (The Atom X5 z8350), as on the > > > Atomic PI SBC, the values are byte-swapped. > > > > > > I've been pulling my hair out for *weeks* on this, and only this > > > evening came to realize that somewhere, those "shorts" are > > > getting > > > byte-swapped, and it looks like *one* of the Volk kernels may > > > be to blame. > > > > > > I would fully-expect there to be "surprises" when exchanging data > > > twixt ARM SBCs and any randomly-chosen X86, because some (not > > > ALL) > > > ARMs use a different byte-ordering, but this is between X86 > > > systems. > > > > > > And on my lappy, which is a core i7 m640, the attached flow-graph > > > produces the correct results in the output file. > > > > > > My lappy is running GR 3.7.13.4 while the packaged GR for Ubuntu > > > 18.04 (on the Atomic PI) is 3.7.11-10. > > > > > > > > > smime.p7s Description: S/MIME cryptographic signature
Re: Contribute to GNU radio
Hi Martin, César, > If you're asking for something specific, how about you do the guided > tutorials (you can find them on the wiki), and see if they are still up to > date? Oh, yes! I totally forgot about these. Yes, going through these with an as-modern-as-possible GNU Radio installation would be super helpful. It's really hard for us "old" users to assess whether these tutorials are actually still working well enough for users that haven't developed GNU Radio themselves. Also, I'm pretty sure GRC looks pretty different from when most of the screenshots therein were taken, so if you just follow along these instructions with a GNU Radio 3.8 or newer installation, and re-take the screenshots, that would be immensely helpful. Like, that would definitely make my day. Best regards, Marcus smime.p7s Description: S/MIME cryptographic signature
Re: Contribute to GNU radio
Hi César! It's awesome that you want to help! If you've used GNU Radio before, then: YOU DEFINITELY HAVE THE SKILLS! Generally, we always need people to 1. Write documentation, 2. Test our current development version, 3. Report and reproduce bugs, 4. Review pull requests, 5. Fix bugs and 6. implement new features. So, pick any one of these six problems! We have a tag "good first issue" on the GNU Radio bug tracker[1]. Try these; I hope these are actually good first issues in that they are easy enough for a beginner to both pick up how to work with the project as community as much as as code base whilst still teaching you a bit about everyday problems of GNU Radio. I especially like #1971 [2], where we're still missing a few illustrating flow graphs in gr-qtgui/examples for every single Qt GUI visualization, and a screenshot in the Block Documentation of the Qt Blocks [3]. That would actually combine 1., 2., probably 3. and potentially 5., and maybe even 6. in one task! You might want to install the current "master" branch of GNU Radio. If you're on Ubuntu, that's pretty easy (thanks to Josh's new Ubuntu PPA), if not, you'll need to build from source. Best regards, Marcus [1] https://github.com/gnuradio/gnuradio/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22 [2] https://github.com/gnuradio/gnuradio/issues/1971 [3] https://wiki.gnuradio.org/index.php?title=Category:Block_Docs&pagefrom=Q#mw-pages On Fri, 2019-11-15 at 20:56 +, César fumfum wrote: > Hi, > > I’m an engineering student of third year who have been using this tool for 1 > year and i love GNU radio. Now i feel that i can contribute to this project > and help the free software, but i don’t know if i got the needed skills. > > I would like to help developing tools because i know a few programming > languages (java, c++ and Python) at a basic / intermediate level, and i know > the basics of signal processing which is learnt in college. > > Do you got any recommendation for me? Are my skills good enough to start > contributing to this project? > Thanks in advance. smime.p7s Description: S/MIME cryptographic signature
Re: qt-gui problems with GNU 3.8
Ah, it's the same old blues; need to have qt(4)-devel packaged for qwt. (What I've tried is: Run Fedora as host, and have a podman (or docker, as if I care, replace "podman" by "docker" below) container marcus@workstation> podman run -it --rm centos:8) This is a very rough rundown of what I just did in a fresh CentOS 8 container: [root@hash /]# dnf check-update; dnf install -y epel-release [root@hash /]# dnf update -y [root@hash /]# dnf install -y make rpm-build qt5-qt*-devel rpmdevtools ccache [root@hash /]# adduser mockbuild [root@hash /]# cd [root@hash ~]# curl -o qwt-6.1.3-11.fc31.src.rpm https://ftp-stud.hs-esslingen.de/pub/fedora/linux/releases/31/Everything/source/tree/Packages/q/qwt-6.1.3-11.fc31.src.rpm [root@hash ~]# rpm -i qwt-6.1.3-11.fc31.src.rpm I had to hunt down a lot of qt4 lines in the qwt.spec and remove them before this builds on CentOS 8. I have just attached a diff for a successfully building Qwt6 on the Bug that Vasil mentioned [2], so we can try that one; continue with [root@hash ~]# cd rpmbuild/SPECS [root@hash SPECS]# rm qwt.spec [root@hash SPECS]# curl -o qwt.spec https://bugzilla.redhat.com/attachment.cgi?id=1636615 [root@hash SPECS]# rpmbuild -bs qwt.spec [root@hash SPECS]# cd ../SRPMS [root@hash SRPMS]# rpmbuild -rb *.src.rpm … wit … This should, if the build succeeds (mine is still running), give you qwt6-qt5 packages. Install these! [root@hash SRPMS]# cd ../RPMS/ [root@hash RPMS]# ls */* noarch/qwt-doc-6.1.3-11.el8.noarch.rpm x86_64/qwt-qt5-6.1.3-11.el8.x86_64.rpm x86_64/qwt-qt5-devel-6.1.3-11.el8.x86_64.rpm x86_64/qwt-debugsource-6.1.3-11.el8.x86_64.rpm x86_64/qwt-qt5-debuginfo-6.1.3-11.el8.x86_64.rpm [root@hash RPMS]# cd x86_64 [root@hash x86_64]# dnf install -y * Try to build GNU Radio now! Best regards, Marcus On Fri, 2019-11-15 at 21:46 +0200, Vasil Velichkov wrote: > Hi Mark, > > On 15/11/2019 21.19, Mark Koenig wrote: > > I am trying to build gnuradio branch maint-3.8 and I am having trouble > > getting qt-gui to enabled. I am currently using the new distro CentOS 8, > > and I cannot find any ‘qwt’ packages. Has anyone got gnuradio to build on > > CentOS 8 yet? I am very close to having all the modules I desire to be > > built and enabled. > > > > Any help would be greatly appreciated. > > The qwt package is usually available from the EPEL repositories[1] but there > are still no package for epel8, see [2] > > [1] https://fedoraproject.org/wiki/EPEL > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1751172 > > Regards, > Vasil > smime.p7s Description: S/MIME cryptographic signature
Re: qt-gui problems with GNU 3.8
Oh, CentOS 8 is out! Nice, I was waiting for that. Let me check whether I can reproduce. Best regards, Marcus On Fri, 2019-11-15 at 19:19 +, Mark Koenig wrote: > I am trying to build gnuradio branch maint-3.8 and I am having trouble > getting qt-gui to enabled. I am currently using the new distro CentOS 8, and > I cannot find any ‘qwt’ packages. Has anyone got gnuradio to build on CentOS > 8 yet? I am very close to having all the modules I desire to be built and > enabled. > > Any help would be greatly appreciated. > > Mark > > Here is the cmake error output for qt-gui. > > -- Python checking for PyQt5 - found > -- Checking for module 'Qt5Qwt6' > -- Package 'Qt5Qwt6', required by 'virtual:world', not found > -- > -- Configuring gr-qtgui support... > -- Dependency Boost_FOUND = 1 > -- Dependency QT_FOUND = 1 > -- Dependency QWT_FOUND = FALSE > -- Dependency ENABLE_VOLK = TRUE > -- Dependency ENABLE_GNURADIO_RUNTIME = ON > -- Dependency ENABLE_GR_FFT = ON > -- Dependency ENABLE_GR_FILTER = ON > -- Dependency PYTHONLIBS_FOUND = TRUE > -- Dependency PYQT5_FOUND = TRUE > -- Disabling gr-qtgui support. > -- Override with -DENABLE_GR_QTGUI=ON/OFF > > Here are my final modules enabled ad disabled. > > -- # Gnuradio enabled components > -- ## > -- * python-support > -- * testing-support > -- * doxygen > -- * gnuradio-runtime > -- * gr-ctrlport > -- * * thrift > -- * gnuradio-companion > -- * gr-blocks > -- * gr-fec > -- * gr-fft > -- * gr-filter > -- * gr-analog > -- * gr-digital > -- * gr-dtv > -- * gr-audio > -- * * oss > -- * gr-channels > -- * gr-trellis > -- * gr-uhd > -- * gr-utils > -- * gr_modtool > -- * gr-vocoder > -- * gr-wavelet > -- > -- ## > -- # Gnuradio disabled components > -- ## > -- * sphinx > -- * gr-qtgui > -- * gr-video-sdl > -- * gr-zeromq > -- > > > > smime.p7s Description: S/MIME cryptographic signature
Re: How to tell whether gnuradio is using NEON or not?
... which either means that's fine, or we need more (or sometimes, better) NEON implementations. If this is critical to you, let us get you onboard with VOLK development – and get your NEON code upstreamed! :D Best regards, Marcus On Fri, 2019-11-15 at 21:34 +0300, Amr Bekhit wrote: > Hi Marcus, > > Thanks for the clarification. I guess in this case, seeing as volk > correctly detected the presence of neon during the compilation process > but found the generic machine to be faster, then I can assume, as you > said, that GCC 9 is indeed doing a better job than the hand optimized > assembly! > > On Fri, 15 Nov 2019 at 14:57, Müller, Marcus (CEL) wrote: > > Hi Amr, > > > > that just either means that the kernel has no NEON implementation so > > far, so generic is the only choice, or, and that's *good* news, the > > compiler has gotten so smart that it outranks hand-written code. > > > > Best regards, > > Marcus > > > > On Fri, 2019-11-15 at 14:01 +0300, Amr Bekhit wrote: > > > Going back to this problem, I recently set up a fresh Raspberry Pi 4 > > > system using Ubuntu Server 19.10 and compiled GNU Radio v3.7.13.5 from > > > source, which also compiled the built in Volk. I then ran volk_profile > > > and was surprised to find that the generic machine was very often > > > faster than NEON, and that most of the entries in volk_config > > > preferred the generic machine. This seems incorrect - what could the > > > mistake be? > > > > > > == > > > Here are the build settings: > > > > > > ubuntu@ubuntu:~$ uname -a > > > Linux ubuntu 5.3.0-1012-raspi2 #14-Ubuntu SMP Mon Nov 11 10:06:55 UTC > > > 2019 aarch64 aarch64 aarch64 GNU/Linux > > > > > > ubuntu@ubuntu:~$ volk-config-info --version > > > 2.0 > > > > > > ubuntu@ubuntu:~$ volk-config-info --cc > > > cc (Ubuntu 9.2.1-9ubuntu2) 9.2.1 20191008 > > > > > > ubuntu@ubuntu:~$ volk-config-info --cflags > > > /usr/bin/cc:::-O3 -DNDEBUG -std=gnu99 -fvisibility=hidden > > > -Wsign-compare -Wall -Wno-uninitialized -Wall > > > /usr/bin/c++:::-O3 -DNDEBUG -fvisibility=hidden -Wsign-compare -Wall > > > -Wno-uninitialized -Wall > > > generic_orc:::GNU:::-O3 -DNDEBUG -std=gnu99 -fvisibility=hidden > > > -Wsign-compare -Wall -Wno-uninitialized -Wall > > > neon_orc:::GNU:::-O3 -DNDEBUG -std=gnu99 -fvisibility=hidden > > > -Wsign-compare -Wall -Wno-uninitialized -Wall > > > -funsafe-math-optimizations > > > neonv8:::GNU:::-O3 -DNDEBUG -std=gnu99 -fvisibility=hidden > > > -Wsign-compare -Wall -Wno-uninitialized -Wall > > > -funsafe-math-optimizations -funsafe-math-optimizations > > > > > > ubuntu@ubuntu:~$ volk-config-info --avail-machines > > > generic_orc;neon_orc;neonv8; > > > > > > volk-config-info --machine > > > neon_orc > > > > > > == > > > Here's the output of volk_profile: > > > > > > ubuntu@ubuntu:~$ volk_profile > > > RUN_VOLK_TESTS: volk_64u_popcntpuppet_64u(131071,1987) > > > generic completed in 1312.04 ms > > > neon completed in 1378.97 ms > > > Best aligned arch: generic > > > Best unaligned arch: generic > > > RUN_VOLK_TESTS: volk_64u_popcntpuppet_64u(131071,1987) > > > generic completed in 1292.81 ms > > > neon completed in 1390.73 ms > > > Best aligned arch: generic > > > Best unaligned arch: generic > > > RUN_VOLK_TESTS: volk_64u_popcntpuppet_64u(131071,1987) > > > generic completed in 1311.04 ms > > > neon completed in 1397.88 ms > > > Best aligned arch: generic > > > Best unaligned arch: generic > > > RUN_VOLK_TESTS: volk_16u_byteswappuppet_16u(131071,1987) > > > generic completed in 224.223 ms > > > neon completed in 278.588 ms > > > neon_table completed in 359.529 ms > > > Best aligned arch: generic > > > Best unaligned arch: generic > > > RUN_VOLK_TESTS: volk_32u_byteswappuppet_32u(131071,1987) > > > generic completed in 425.049 ms > > > neon completed in 752.16 ms > > > Best aligned arch: generic > > > Best unaligned arch: generic > > > RUN_VOLK_TESTS: volk_32u_popcntpuppet_32u(131071,1987) > > > no architectures to test > > > RUN_VOLK_TESTS: volk_64u_byteswappuppet_64u(131071,1987) > > > no architectures to test > > > RUN_VOLK_TESTS: volk_32fc_s32fc_rotatorpuppet_3
Re: Baseband signal generating.
The 3.7-era constellation encoders, if I remember correctly, are average-power-normalizing. So, as I said, simply multiply by a factor 0.5. You already have that in your flow graph and bypassed it. So, you already know what to do. Go wild! (Also, you usually do *not* want a fixed peak-to-peak amplitude but actually a fixed average power when you want to compare things. Anything else would be unfair!) Best regards, Marcus On Fri, 2019-11-15 at 16:35 +0100, Md. Atiqur Rahman wrote: > Hello, > I did change the constellations point to -0.5,+0.5 but still, the output > signal amplitude is the same as before. > This is for BPSK, what should I do for other schemes if I want to change its > amplitude 1v peak to peak? > Thank you. > smime.p7s Description: S/MIME cryptographic signature
Re: Baseband signal generating.
… and the easiest way to adjust that is by simply multiplying the result with the appropriate factor Best regards, Marcus On Fri, 2019-11-15 at 13:06 +0100, Christophe Seguinot wrote: > Hi > > Your amplitude is set in constellation object, in the constellation points > list. > > At present yours is +-1 for BPSK, and +-1+-j for QPSK > > So amplitude is 1 (+-1) for BPSK and 1.414 for QPSK > > This must be adjusted to your requirements (-0.5,0.5) for BPSK > > Regards > > > > On 15/11/2019 11:03, Md. Atiqur Rahman wrote: > > Hello there, I am working on generating a baseband signal by using > > GNU-Radio. I have chosen a random signal along with the constellation > > modulator and constellation object. However, I go through all settings for > > these blocks but don't find the setting option for signal 'Amplitude'. How > > can I be sure that my generating amplitude (let say peak to peak)? > > > > I can see the signal amplitude in QT GUI Time Sink but I am not sure how > > its amplitude define here in this scheme. It seems like signal amplitude is > > 2v peak to peak. Is it right? But I want to generate a baseband signal > > which will have 1v peak to peak. Thank you. > > > > -- > > Sincerely, > > Hasan > > smime.p7s Description: S/MIME cryptographic signature
Re: How to tell whether gnuradio is using NEON or not?
Hi Amr, that just either means that the kernel has no NEON implementation so far, so generic is the only choice, or, and that's *good* news, the compiler has gotten so smart that it outranks hand-written code. Best regards, Marcus On Fri, 2019-11-15 at 14:01 +0300, Amr Bekhit wrote: > Going back to this problem, I recently set up a fresh Raspberry Pi 4 > system using Ubuntu Server 19.10 and compiled GNU Radio v3.7.13.5 from > source, which also compiled the built in Volk. I then ran volk_profile > and was surprised to find that the generic machine was very often > faster than NEON, and that most of the entries in volk_config > preferred the generic machine. This seems incorrect - what could the > mistake be? > > == > Here are the build settings: > > ubuntu@ubuntu:~$ uname -a > Linux ubuntu 5.3.0-1012-raspi2 #14-Ubuntu SMP Mon Nov 11 10:06:55 UTC > 2019 aarch64 aarch64 aarch64 GNU/Linux > > ubuntu@ubuntu:~$ volk-config-info --version > 2.0 > > ubuntu@ubuntu:~$ volk-config-info --cc > cc (Ubuntu 9.2.1-9ubuntu2) 9.2.1 20191008 > > ubuntu@ubuntu:~$ volk-config-info --cflags > /usr/bin/cc:::-O3 -DNDEBUG -std=gnu99 -fvisibility=hidden > -Wsign-compare -Wall -Wno-uninitialized -Wall > /usr/bin/c++:::-O3 -DNDEBUG -fvisibility=hidden -Wsign-compare -Wall > -Wno-uninitialized -Wall > generic_orc:::GNU:::-O3 -DNDEBUG -std=gnu99 -fvisibility=hidden > -Wsign-compare -Wall -Wno-uninitialized -Wall > neon_orc:::GNU:::-O3 -DNDEBUG -std=gnu99 -fvisibility=hidden > -Wsign-compare -Wall -Wno-uninitialized -Wall > -funsafe-math-optimizations > neonv8:::GNU:::-O3 -DNDEBUG -std=gnu99 -fvisibility=hidden > -Wsign-compare -Wall -Wno-uninitialized -Wall > -funsafe-math-optimizations -funsafe-math-optimizations > > ubuntu@ubuntu:~$ volk-config-info --avail-machines > generic_orc;neon_orc;neonv8; > > volk-config-info --machine > neon_orc > > == > Here's the output of volk_profile: > > ubuntu@ubuntu:~$ volk_profile > RUN_VOLK_TESTS: volk_64u_popcntpuppet_64u(131071,1987) > generic completed in 1312.04 ms > neon completed in 1378.97 ms > Best aligned arch: generic > Best unaligned arch: generic > RUN_VOLK_TESTS: volk_64u_popcntpuppet_64u(131071,1987) > generic completed in 1292.81 ms > neon completed in 1390.73 ms > Best aligned arch: generic > Best unaligned arch: generic > RUN_VOLK_TESTS: volk_64u_popcntpuppet_64u(131071,1987) > generic completed in 1311.04 ms > neon completed in 1397.88 ms > Best aligned arch: generic > Best unaligned arch: generic > RUN_VOLK_TESTS: volk_16u_byteswappuppet_16u(131071,1987) > generic completed in 224.223 ms > neon completed in 278.588 ms > neon_table completed in 359.529 ms > Best aligned arch: generic > Best unaligned arch: generic > RUN_VOLK_TESTS: volk_32u_byteswappuppet_32u(131071,1987) > generic completed in 425.049 ms > neon completed in 752.16 ms > Best aligned arch: generic > Best unaligned arch: generic > RUN_VOLK_TESTS: volk_32u_popcntpuppet_32u(131071,1987) > no architectures to test > RUN_VOLK_TESTS: volk_64u_byteswappuppet_64u(131071,1987) > no architectures to test > RUN_VOLK_TESTS: volk_32fc_s32fc_rotatorpuppet_32fc(131071,1987) > generic completed in 2390.53 ms > neon completed in 927.447 ms > Best aligned arch: neon > Best unaligned arch: neon > RUN_VOLK_TESTS: volk_8u_conv_k7_r2puppet_8u(131071,1987) > no architectures to test > RUN_VOLK_TESTS: volk_32f_x2_fm_detectpuppet_32f(131071,1987) > no architectures to test > RUN_VOLK_TESTS: volk_16ic_s32f_deinterleave_real_32f(131071,1987) > no architectures to test > RUN_VOLK_TESTS: volk_16ic_deinterleave_real_8i(131071,1987) > generic completed in 118.046 ms > neon completed in 108.788 ms > u_orc completed in 133.196 ms > Best aligned arch: neon > Best unaligned arch: neon > RUN_VOLK_TESTS: volk_16ic_deinterleave_16i_x2(131071,1987) > generic completed in 279.341 ms > u_orc completed in 625.402 ms > Best aligned arch: generic > Best unaligned arch: generic > RUN_VOLK_TESTS: volk_16ic_s32f_deinterleave_32f_x2(131071,1987) > generic completed in 602.508 ms > neon completed in 611.587 ms > u_orc completed in 5000.92 ms > Best aligned arch: generic > Best unaligned arch: generic > RUN_VOLK_TESTS: volk_16ic_deinterleave_real_16i(131071,1987) > no architectures to test > RUN_VOLK_TESTS: volk_16ic_magnitude_16i(131071,1987) > no architectures to test > RUN_VOLK_TESTS: volk_16ic_s32f_magnitude_32f(131071,1987) > no architectures to test > RUN_VOLK_TESTS: volk_16ic_convert_32fc(131071,1987) > generic completed in 599.708 ms > neon completed in 604.177 ms > Best aligned arch: generic > Best unaligned arch: generic > RUN_VOLK_TESTS: volk_16ic_x2_multiply_16ic(131071,1987) > generic completed in 498.56 ms > neon completed in 679.4 ms > Best aligned arch: generic > Best unaligned arch: generic > RUN_VOLK_TESTS: volk_16ic_x2_dot_prod_16ic(131071,1987) > generic completed in 1834.92 ms > neon completed in 501 ms > neon_vma completed in 493.5
Re: Going from GUI to non-GUI operation.
Hi Glen, On Thu, 2019-11-14 at 11:52 -0500, Glen I Langston wrote: > Hi Amr, > > Thanks for your suggestion. > > However when I select no-gui, then all the QT blocks go RED in my designs in > gnuradio-companion. > > I was hoping that they would instead just go quiet and use the default values. That would be relatively hard to do in the general case, since QT blocks also include sliders, variable entry boxes etc. > > I can, of course, just delete all the QT blocks, but then when going back > to debugging/improving I’d have to put them back in. You'll be delighted to find the "disable" function: rightclick -> disable, or just selecting a block and pressing "D". Best regards, Marcus smime.p7s Description: S/MIME cryptographic signature
Re: Gnuradio for Raspberry PI 4 and SDRPLay works well, but need documentation
Hi Glen, On Thu, 2019-11-14 at 09:22 -0500, Glen I Langston wrote: > Thanks Marcus, > > Concerning your points, I thought I’d edited the Subject line to > start a new thread. I’ll be more careful in the future. > no worries – just the danger of hiding your own threads! > Also thanks for your clarification of the source code origin. I’ve also > directly contacted the folks at SDRPlay. > > I do think the SDRPlay folks do want to be more closely integrated > with the Gnuradio folks, as they are partially integrated into > the OsmoSdr releases. We'd love to, but the licensing is pretty clear on that: can't distribute compiled code that links against GNU Radio if you're closed source. > I’m a little vague on the relationship > between OsmoSdr.org and Gnuradio. You mean the osmocom project; they are cool folks that do way more than just gr-osmosdr; from experimentation hardware over software implementations of fully standards-compliant base stations to cellular backbone infrastructure. BBS / modem servers and much more! Check out their projects! https://osmocom.org/projects/ I think you specifically might enjoy their work on Thuraja http://media.ccc.de/browse/congress/2011/28c3-4688-en-introducing_osmo_gmr.html I'd say, osmocom is in the business of making as much as possible of the modern communication stack free to use and inspect. > Maybe the relationship is > “parallel play”. There's a personal overlap between GNU Radio contributors and osmocom contributors! Also, I respect hell out of them and enjoy hanging around with 'em, so there's that. Best regards, Marcus smime.p7s Description: S/MIME cryptographic signature
Re: Gnuradio for Raspberry PI 4 and SDRPLay works well, but need documentation
Hi Glen, first of all: This email nearly eluded my attention – you replied to a completely different topic, and that means email clients will sort your mail under the "Simulated Time?" thread. Simply don't reply to emails if you don't mean to actually reply. Then: The SDRPlay block isn't part of GNU Radio itself – it comes from somewhere else, and I must admit I don't know from where. You'll probably have to download the SDRPlay driver package and look inside. Problem with the SDRPlay driver is: It's closed source, and as such, they can't link software against GNU Radio (which is GPL), and then distribute it. If someone could reverse engineer that and write a GPL- compatible driver (and integrate it with soapy or with gr-osmosdr), that'd be very cool. Best regards, Marcus On Wed, 2019-11-13 at 20:19 -0500, Glen Langston wrote: > Hello all, > > This email is a request for documentation on SDRPlay Source block in > Gnuradio companion. > > I have been testing our Radio Astronomy Spectrometer and Event > detection with the SDRPlay RSP1A. It seems to be working pretty > well, using the downloaded OS for Pi from SDRPlay. They seem to have > put a pretty complete version of 3.7.13.4. > > Swig and boost are installed and it was fairly easy to build the C++ code in > git clone http://www.github.com/WVURAIL/gr-radio_astro > > I did update a few items, including VNC and SSH configuration, but > mostly it worked out of the box. I started with a Pi 3B+ but did > have some trouble running out of memory, so switched to a PI 4B (4 GB) > and the complied > code ran well. > > Attached is a screen capture of the design, the inputs to the > SDRSource and the operating design. I seem many lines in the > frequency range 1416.5 to 1423.5 MHz and I'm wondering if I have the > wrong band pass filter selected. But I the SDRPlay source block > inputs don't well match the hardware layout (so far as I can figure > out). (The capture has the wrong frequency label, it should be GHz > not MHz). > > I've goggled everywhere but have had no luck finding any document on > the sdrplay source block in gnuradio companion. Any suggestions? > > Thanks > Glen smime.p7s Description: S/MIME cryptographic signature
Re: problems about Installing multiple versions of gnuradio
You probably have conflicting configuration about paths in ~/.gnuradio; hard to say, actually. Generally, when installing in separate prefixes, it's no good idea to have both prefixes in LD_LIBRARY_PATH etc at the same time - for any given process, only one should be in there. That's no technical challenge, though, since environment variables are always just inherented from the spawning parent process. Best regards, Marcus On Thu, 2019-11-14 at 17:16 +0800, mangrove_forest wrote: > I want to install two versions of gnuradio on one machine. I first installed > gnuradio 3.7 in default directory /usr/local/（and it works normally）, and > then installed the gnuradio 3.9 in the directory /opt/gnuradio. But the > gnuradio 3.7 can't run again,as follows: > $ gnuradio-companion > Traceback (most recent call last): > File "/usr/local/bin/gnuradio-companion", line 99, in > run_main() > File "/usr/local/bin/gnuradio-companion", line 92, in run_main > exit(main()) > File "/usr/local/lib/python2.7/dist-packages/gnuradio/grc/main.py", line 51, > in main > install_prefix=gr.prefix() > File "/usr/local/lib/python2.7/dist-packages/gnuradio/grc/gui/Platform.py", > line 38, in init > _Platform.init(self, *args, **kwargs) > File "/usr/local/lib/python2.7/dist-packages/gnuradio/grc/core/Platform.py", > line 75, in init > self.build_block_library() > File "/usr/local/lib/python2.7/dist-packages/gnuradio/grc/core/Platform.py", > line 175, in build_block_library > hide_bokeh_gui_options_if_not_installed(self.blocks['options']) > File > "/usr/local/lib/python2.7/dist-packages/gnuradio/grc/core/utils/odict.py", > line 35, in getitem > return self._data[key] > KeyError: 'options' > what can i do?? > > > when i run gnuradio 3.9 in the directory /opt/gnuradio/bin as follows, it > runs: > $export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/gnuradio/lib > $export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/opt/gnuradio/lib/pkgconfig > $export PYTHONPATH=$PYTHONPATH:/opt/gnuradio/lib/python3.6/dist-packages > $cd /opt/gnuradio/bin > $ ./gnuradio-companion > <<< Welcome to GNU Radio Companion 3.9.0.0-git >>> > Block paths: > /opt/gnuradio/share/gnuradio/grc/blocks smime.p7s Description: S/MIME cryptographic signature
