Re: Python OOT module not showing up in GRC

[Ron Economos]

GNU Radio 3.8 uses YAML instead of XML for the files in the grc 
directory. You can convert your .xml files to .yaml files with the command:


gr_modtool update --complete

Ron

On 7/17/20 15:33, Roman A Sandler wrote:

Hi,

I have followed Section 3.2 in the tutorial 
https://wiki.gnuradio.org/index.php/Guided_Tutorial_GNU_Radio_in_Python to 
setup an OOT python block in GRC.


I followed the instructions on a Linux machine running GNURadio 3.7 
and it worked exactly as described.


I then ran the tutorial on an NVIDIA Xavier Linux machine w/ GNURadio 
3.8 and all the steps seemed to work. The QA test worked in python, 
and `cmake; make; sudo make install; sudo ldconfig` all ran without 
any errors. However, when I open GRC, I cannot see the block.


I am wondering if this tutorial is not up-to-date w/ GNURadio 3.8 or 
if maybe there is something weird about the Xavier that is causing the 
bug.


Let me know,
Thanks!

Python OOT module not showing up in GRC

[Roman A Sandler]

Hi,

I have followed Section 3.2 in the tutorial
https://wiki.gnuradio.org/index.php/Guided_Tutorial_GNU_Radio_in_Python to
setup an OOT python block in GRC.

I followed the instructions on a Linux machine running GNURadio 3.7 and it
worked exactly as described.

I then ran the tutorial on an NVIDIA Xavier Linux machine w/ GNURadio 3.8
and all the steps seemed to work. The QA test worked in python, and `cmake;
make; sudo make install; sudo ldconfig` all ran without any errors.
However, when I open GRC, I cannot see the block.

I am wondering if this tutorial is not up-to-date w/ GNURadio 3.8 or if
maybe there is something weird about the Xavier that is causing the bug.

Let me know,
Thanks!

Re: Discuss-gnuradio Digest, Vol 213, Issue 17

[Anselm Karl]

gt; https://github.com/conda-forge/gnuradio-feedstock.
> >
> > If anyone is interested in seeing more packages for other related
> software or OOT modules, I'm also happy to assist in writing the recipe and
> getting it onto conda-forge. The nice thing is that anyone can contribute
> new conda-forge packages or improvements in the form of pull requests, so
> you also don't need me at all if you're so inclined!
> >
> > I'm planning on keeping at least all of the current packages up to date
> with new releases as my time allows, but I would certainly welcome
> co-maintainers or any bits of extra help. Just let me know or get involved
> on github!
> >
> > Cheers,
> > Ryan
> >
>
>
>
>
> --
>
> Message: 8
> Date: Fri, 17 Jul 2020 11:50:45 +0200
> From: Marcin Wachowiak 
> To: discuss-gnuradio@gnu.org
> Subject: Creating synchronized USRP source block
> Message-ID:
>  qpvbkhqc+bo7d...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hello,
> I am trying to create a synchronized usrp source block in gnu radio
> consisting of multiple B210 USRP devices. Lang: C++.
>
> >From what I have found I need to:
>
>- Instantiate multiple multi_usrp_sptr as each B210 requires one and
>multiple B210 devices cannot be addressed by using single sptr
>- Use external frequency and PPS sources - an option that can be
>selected from block or set programmatically
>- Synchronize re/tuning to achieve repeatable phase offset between nodes
>- this can be achieved using timed commands API
>
> https://kb.ettus.com/Synchronizing_USRP_Events_Using_Timed_Commands_in_UHD
>- Synchronize sample streams using time_spec property issue_stream cmd
>
> *The problem is how should I insert these timed commands and set time_spec
> of stream in GNU radio block or gr-uhd libs?*
>
> I looked into the gr-uhd folder where the sink/source code resided and
> found functions that could be altered.
> Unfortunately I don't know how to copy or export this library to do these
> modifications and later compile to  insert my custom blocks to GNU Radio,
> because gr-uhd seems to be built in and compiled at GR installation.
> I attempted coping and then making the lib but that's not the way - it
> didn't succeed. Should I add my own source block via gr_modtool and insert
> only the commands I need?
> Compatibility with uhd and its functions apart from just adding a few lines
> would be advantageous not to write the source from scratch.
>
> Please advise,
> Kind Regards,
> Marcin Wachowiak
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> https://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20200717/cb1ceda3/attachment.html
> >
>
> --
>
> Message: 9
> Date: Fri, 17 Jul 2020 09:44:33 +
> From: Yasser Attarizi 
> To: "discuss-gnuradio@gnu.org" 
> Subject: problem in making a project
> Message-ID:
> <
> lo2p265mb06696afb4cc0fa74e7398191d4...@lo2p265mb0669.gbrp265.prod.outlook.com
> >
>
> Content-Type: text/plain; charset="windows-1252"
>
> Hi
> I am making a project in which there are some a module with some blocks.
> it is lora_sdr and in my computer when I want to make it I see some errors
> like this:
>
> /home/yasser/workarea/LoRa/gr-lora_sdr/build/swig/lora_sdr_swigPYTHON_wrap.cxx:
> In function ‘PyObject* _wrap_add_crc_sptr_relative_rate_i(PyObject*,
> PyObject*)’:
> /home/yasser/workarea/LoRa/gr-lora_sdr/build/swig/lora_sdr_swigPYTHON_wrap.cxx:5862:35:
> error: ‘class gr::lora_sdr::add_crc’ has no member named ‘relative_rate_i’;
> did you mean ‘relative_rate’?
>result = (uint64_t)(*arg1)->relative_rate_i();
>
> I am using python2.7 and gnuradio3.7 and I installed gnuradio with pybomb
> I didn't copay and paste all error lines because they are alot and are the
> same shape. I can bring all of them if necessary
> Best Regards,
> Yasser
>
> [University of Buckingham logo]<
> https://www.buckingham.ac.uk/?utm_source=outlook-signature&utm_medium=email&utm_content=university-logo&utm_campaign=email-signature-generic>
> [TEF Gold - QAA Quality Mark thumbnail - NSS Top for Student Satisfaction
> in England 2018] <
> https://www.buckingham.ac.uk/about/rankings?utm_source=outlook-signature&utm_medium=email&utm_content=rankings-badges&utm_campaign=email-signature-generic
> >
>
> Connect with us: Facebook<http://facebook.com/unibuckingham> - Twitter<
> http://twitter.com/uniofbuckingham> - Instagram<
> https:

Re: GPIO lines on RPi4

[jean-michel.fri...@femto-st.fr]

To complete this demonstration of running a TCP server from within the 
GNU Radio Companion flowchart without modifying the generated Python code,
and correcting a mistake in the post below so that I can also update the Signal
Source frequency, I have uploaded
 
http://jmfriedt.org/2020-07-17-140636_2704x1050_scrot_ann.png 

(and removed the erroneous screenshots cited in the previous messages).

Gwenhael Goavec explained to me the mistake I was doing: when calling tt=t.t()
(since t is the Id of the flowchart) from the thread, I was creating a new 
instance of the whole flowchart, whose frequency variable did not match the 
one defining the frequency source signal that was being displayed.
Instead of creating a new instance of the flowchart in the thread, the argument 
"self"
must be provided when creating the thread. Then, the variables and methods from 
the
calling class can be accessed and indeed, changing the signal source frequency 
does
lead to a change in the displayed spectrum.

JM

--
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
25000 Besancon, France

June 30, 2020 10:10 AM, jean-michel.fri...@femto-st.fr wrote:

> Thanks to this comment, I ended up finding a solution to call a thread
> running a TCP/IP server able to control the variables from the main
> processing flowchart, without modifying manually the generated Python for a Qt
> application.
> A screenshot, which I hope is self-explanatory, illustrating this process is 
> at
> http://jmfriedt.org/2020-06-30-083722_2704x1050_scrot.png
> 
> However I am facing a surprising result.
> I initially (see above) created a signal source, set its frequency to a 
> variable flo, 
> checked with a slider that changing flo did change the output frequency, 
> removed the 
> slider and set the signal source flo from my server. No change in the 
> frequency output.
> 
> So I went back to my initial setup in which I change not only the source 
> signal
> frequency but also the receiver hardware LO frequency of the B210, keeping 
> the TX LO
> fixed. And surely enough both a spectrum analyzer and the coupled output from 
> the
> B210 TX to the RX show the signal shifting.
> 
> Screenshots at
> http://jmfriedt.org/2020-06-30-095336_2704x1050_scrot.png show that the 
> callback function
> for the source frequency or LO frequency are exactly the same and so are the 
> server handling
> functions, while
> http://jmfriedt.org/2020-06-30-095712_2704x1050_scrot.png shows that the B210 
> TX frequency
> only changes when tuning the hardware LO, not the signal source LO.
> 
> Is there some signal that needs to be sent to the signal source beyond
> self.analog_sig_source_x_0.set_frequency(self.flo)
> to tell it to change frequency ?
> 
> Thanks, JM
> 
> --
> JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
> 25000 Besancon, France
> 
> June 22, 2020 1:25 PM, "Marcus Müller"  wrote:
> 
>> It gets even better:
>> 
>> We've launched a feature in 3.8.1.0 (and on master before that, as we do
>> with any feature that ends up in a maintenance release) that we hope
>> doesn't come back to bite us due to enabling unclean design. But, we
>> must build best practices so that it doesn't go unused, either, so:
>> 
>> Assuming you're using GNU Radio 3.8.1.0 (or later, once we release
>> something), you can make use of the "Python Snippets" in GRC.
>> 
>> Cheers,
>> Marcus
>> 
>> On 18/06/2020 23.17, Marcus D. Leech wrote:
>> 
>>> On 06/18/2020 03:54 PM, jean-michel.fri...@femto-st.fr wrote:
>> 
>> My approach:
>> * build your grc chart from GNU Radio Companion and generate the .py file
>> * edit the py file and import pygpio
>> * play with the RPi4 GPIO in your python script.
>> 
>> See attached script, with a python server included in the Python script
>> to control an RF switch from a GNU Octave TCP/IP client talking to the
>> Python
>> TCP/IP server.
>> 
>> I am presenting this approach to hardware control at
>> http://jmfriedt.free.fr/sdra_radar.pdf
>> 
>> JM
>>> If you use "Python Module" block, you can write a lot of
>>> non-GnuRadio-esque python, import anything you want, etc, etc. No editing
>>> of the output python required, necessarily.
>> 
>> --
>> JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
>> 25000 Besancon, France
>> 
>> June 18, 2020 9:40 PM, "Da Fy"  wrote:
>>> Hi All, does anyone have an example of how to control GOIO lines on
>>> the RPi4 from within a GRC
>>> flowgraph. I’m guessing it’s an OOT module.
>>> 
>>> I need to generate a signal of a few 100Hz & control GPIO lines at
>>> various points though the cycle.
>>> 
>>> Alternatively, I could generate the signal & lines with external
>>> hardware & read them with
>>> GnuRadio.
>>> 
>>> Tnx, Dave

problem in making a project

[Yasser Attarizi]

Hi
I am making a project in which there are some a module with some blocks. it is 
lora_sdr and in my computer when I want to make it I see some errors like this:

/home/yasser/workarea/LoRa/gr-lora_sdr/build/swig/lora_sdr_swigPYTHON_wrap.cxx: 
In function ‘PyObject* _wrap_add_crc_sptr_relative_rate_i(PyObject*, 
PyObject*)’:
/home/yasser/workarea/LoRa/gr-lora_sdr/build/swig/lora_sdr_swigPYTHON_wrap.cxx:5862:35:
 error: ‘class gr::lora_sdr::add_crc’ has no member named ‘relative_rate_i’; 
did you mean ‘relative_rate’?
   result = (uint64_t)(*arg1)->relative_rate_i();

I am using python2.7 and gnuradio3.7 and I installed gnuradio with pybomb
I didn't copay and paste all error lines because they are alot and are the same 
shape. I can bring all of them if necessary
Best Regards,
Yasser

[University of Buckingham 
logo]
 [TEF Gold - QAA Quality Mark thumbnail - NSS Top for Student Satisfaction in 
England 2018] 


Connect with us: Facebook - 
Twitter - 
Instagram - 
LinkedIn

The University of Buckingham respects your rights with regards to data privacy 
and data protection. Please review our privacy 
notice,
 which informs you how we collect, store, use, share, process and protect your 
personal information.

It also tells you how you can access and update your personal information and 
make certain choices about how your personal information is used. By 
communicating with the University, using its websites, making applications or 
by otherwise giving us your personal information you are accepting the 
practices described in this Privacy Notice. If you do not agree to this Privacy 
Notice, please do not give us any of your personal information.

Creating synchronized USRP source block

[Marcin Wachowiak]

Hello,
I am trying to create a synchronized usrp source block in gnu radio
consisting of multiple B210 USRP devices. Lang: C++.

>From what I have found I need to:

   - Instantiate multiple multi_usrp_sptr as each B210 requires one and
   multiple B210 devices cannot be addressed by using single sptr
   - Use external frequency and PPS sources - an option that can be
   selected from block or set programmatically
   - Synchronize re/tuning to achieve repeatable phase offset between nodes
   - this can be achieved using timed commands API
   https://kb.ettus.com/Synchronizing_USRP_Events_Using_Timed_Commands_in_UHD
   - Synchronize sample streams using time_spec property issue_stream cmd

*The problem is how should I insert these timed commands and set time_spec
of stream in GNU radio block or gr-uhd libs?*

I looked into the gr-uhd folder where the sink/source code resided and
found functions that could be altered.
Unfortunately I don't know how to copy or export this library to do these
modifications and later compile to  insert my custom blocks to GNU Radio,
because gr-uhd seems to be built in and compiled at GR installation.
I attempted coping and then making the lib but that's not the way - it
didn't succeed. Should I add my own source block via gr_modtool and insert
only the commands I need?
Compatibility with uhd and its functions apart from just adding a few lines
would be advantageous not to write the source from scratch.

Please advise,
Kind Regards,
Marcin Wachowiak