NEWSDR 2022 -- Save the Date!! -- Friday June 3
Save-the-Date!! NEWSDR 2022 will be held on Friday June 3. The event is free and will be fully virtual, and within an interactive virtual environment. Please visit our website for updates on the agenda. More information and registration instructions will be posted at the end of this week. https://newsdr.org/workshops/newsdr2022/
Re: Improving GRC usability: How do you deal with changes in .grc file behaviour caused by opening it on newer/older GRC version?
Hi there, I'd like to make one final request for anyone interested in giving taking part in this very short survey to do so. I'll be closing the survey this Sunday (17th April). Has this scenario ever happened to you: You open a .grc file with an older (or newer) version of GRC than the file was created with. When you try to open it the .grc file behaves differently, due to differences in GRC version. --- How did you deal with this scenario? How did you get the .grc to execute as you expected? All GRC users input is very welcome: https://saneuxdesign.survey.fm/dealing-with-changes-in-how-grc-file-behaves-caused-by-opening-it-in-newer-or-older-grc-version Thanks to all the 13 people who took part so far. Thanks in advance, Bernard On 07/03/2022 16:35, Bernard Tyers - EI8FDB wrote: Subject: Re: Improving GRC usability: How do you deal with changes in .grc file behaviour caused by opening it on newer/older GRC version? From: Bernard Tyers - EI8FDB Date: 07/03/2022, 16:35 To: GNU Radio Discuss List Hi there, I'd like to say thanks to the community members who've contributed to this issue so far, and make another request for anyone interested in giving their input. Has this scenario ever happened to you - You open a .grc file with an older (or newer) version of GRC than the file was created with. When you try to open it the .grc file behaves differently, due to differences in GRC version. -- How did you deal with this scenario? How did you get the .grc to execute as you expected? All GRC users input is very welcome: https://saneuxdesign.survey.fm/dealing-with-changes-in-how-grc-file-behaves-caused-by-opening-it-in-newer-or-older-grc-version Thanks, Bernard On 22/02/2022 11:55, Bernard Tyers - EI8FDB wrote: Hi there, I contribute to usability improvements to GNU Radio, and I'm looking for input from the community. Has this scenario ever happened to you - You open a .grc file with an older (or newer) version of GRC than the file was created with. When you try to open it the .grc file behaves differently, due to differences in GRC version. -- How did you deal with this scenario? How did you get the .grc to execute as you expected? Give your input by completing this short 3 question form: https://saneuxdesign.survey.fm/dealing-with-changes-in-how-grc-file-behaves-caused-by-opening-it-in-newer-or-older-grc-version You don't need to be a GNU Radio expert to give your input. If you've not experienced this scenario, but you have ideas on how you would go about it, your input is welcome. Any questions, please let me know. Thanks in advance, Bernard
Options - QT GUI window size and placement
I recently built a laptop with Ubuntu 20.04 and then built gnuradio 3.10.2 from source. I noticed that the Hackrf is now supported through the SoapySDR source/sink blocks (rather than the Osmocom blocks), so I made some examples & tests of hackrf rx and tx. Works fine, but I have a question. Previously the window that starts when the flowgraph is executed (i.e. the popup window with the QT GUI widgets and instrumentation), would remember the window size and placement; but now it doesn't. In 3.10.2 how do I control the window size and placement? Thanks, Jake
Some thoughts regarding GSoC
Hi! Just want to share a few thoughts I had reading through the page about GSoC. "GNU Radio NCurses Support": Albeit this sounds awesome, I also come to think about doing this over http. Have a look at how Node-Red (https://nodered.org/) works and looks. Instead of trying to implement something in the console, I think there is great success to be found doing this in a browser instead. Using SSH to connect to your remote and setup a TCP-tunnel over it, and then access your GRC in your browser. Or for the savy, set it up using https over nginx or proxy of choice. Maybe a lot of code from the Node-Red project can be re-used. Using WebSockets and other new tech's in browser-dev could really do a difference here. "Implement optimized, standardized channel codes": There was a discussion a while ago regarding how polynomials are used in the different blocks of GRC and GR. At least for GRC, my opinion is that it should be friendly towards new users who might not be programmers. Today, polynomials are entered as an integer, and the size of the polynomial must be entered in another field, even though it could be determined from the polynomial. Example: Mask: 0x8003 K:14 => [15,1,0] My suggestion is that, at least in GRC, maybe as parallel blocks to the existing, that polynomials are entered in the [15,1,0] fashion, as a Python-list of exponents, and that mask and K are derived from that input, instead of the other way around. This goes for the blocks Scrambler, Descrambler, LFSR-generators, Reed-Solomon FEC, and probably more. Hope my toughts inspire some discussion and improves gnuradio, my favorite open-source project, thank you for reading.
Re: Some thoughts regarding GSoC
El 13/4/22 a las 19:37, Elof Wecksell escribió: There was a discussion a while ago regarding how polynomials are used in the different blocks of GRC and GR. At least for GRC, my opinion is that it should be friendly towards new users who might not be programmers. Today, polynomials are entered as an integer, and the size of the polynomial must be entered in another field, even though it could be determined from the polynomial. Example: Mask: 0x8003 K:14 => [15,1,0] My suggestion is that, at least in GRC, maybe as parallel blocks to the existing, that polynomials are entered in the [15,1,0] fashion, as a Python-list of exponents, and that mask and K are derived from that input, instead of the other way around. This goes for the blocks Scrambler, Descrambler, LFSR-generators, Reed-Solomon FEC, and probably more. Hi Elof, I think that's a good idea about making polynomials easier to use. However, there is another tricky fact about polynomials, and it is that some authors will list p(x), while others will list the "reverse" polynomial p(1/x)x^d (here d is the degree of p). I don't know how to solve this notation inconsistency, other than with good documentation about what notation we use. In some cases there might be a choice which is more natural (the polynomial of a multiplicative scrambler, for instance, since it's its transfer function in the usual Z-tranform sense). Additionally, when listing the polynomials in hex (as a mask), some authors will omit the leading term (since it's always 1), and some authors will omit the independent term (since in most non-degenerate cases it's also 1). In any case, I think that the approach we take should be retro-compatible, and not break people's flowgraphs and documentation. An approach could be to provide the two kinds of input as alternatives in the same block. Best, Daniel. OpenPGP_signature Description: OpenPGP digital signature
How to get information on number of input data samples in C++ OOT
Hello GNURadio Community, I am writing a Gnuradio C++ OOT block and need to get the number of complex input data samples fed into my block by the scheduler on each iteration of data delivery. I need to know this information because the relationship between my input and output stream is not as simple as say a one to one I/O as the "sync" block. In Python, it is easy, I can find the value by doing: numInputs = len(input_items[0]). In the C++ general_work method which I paste below, I have not been able to extract the number of input samples from any of the parameters. [image: image.png] I will appreciate any help provided. Thank you! George
Re: How to get information on number of input data samples in C++ OOT
The C++ API gives you ninput_items explicitly, so ninput_items[0] is the number of items in input_items[0]. On Wed, Apr 13, 2022 at 7:18 PM George Edwards wrote: > Hello GNURadio Community, > > I am writing a Gnuradio C++ OOT block and need to get the number of > complex input data samples fed into my block by the scheduler on each > iteration of data delivery. I need to know this information because the > relationship between my input and output stream is not as simple as say a > one to one I/O as the "sync" block. > > In Python, it is easy, I can find the value by doing: numInputs = > len(input_items[0]). In the C++ general_work method which I paste below, > I have not been able to extract the number of input samples from any of the > parameters. > [image: image.png] > > I will appreciate any help provided. > Thank you! > George > >
Trouble With gr-osmosdr Install
Hello, I will preface this by saying I am a linux novice. I have been trying to set up GNURadio to use with a HackRF. To do this, I have installed gr-osmosdr following instructions from the install guide ( https://osmocom.org/projects/gr-osmosdr/wiki/GrOsmoSDR). I have GNURadio Companion version 3.7.13.4. I am on a Raspberry Pi 4 running the most recent Raspbian. My problem is that I cannot get the osmocom source and sink blocks to show up in GRC, and I cannot find the osmocom_source and osmocom_sink .XML files anywhere either. I tried copying the hackrf_source and hackrf_sink .XML files directly to the folder in my GRC block path, but when starting GRC it would throw an error message that the .XML files were unrecognized. Not sure what else to do. Would greatly appreciate your help. Best, Ambroise - KN6NOR
