Re: 2 SDRs – Parallel Programming

[Marcus Müller]

Hello Oğuzhan,

so, what radios are these?

Generally, this *very* much sounds like you need to use timed commands, which trigger the 
tuning at a specific sample time, instead of "yeah, whenever the connection between PC and 
the USRP has delivered the command".


You can send these commands to the "command" message port on the USRP Sink[1]; the set of 
things you can set (depending on the actual hardware model) are documented in [2]. Note 
that you'll want to sent in a PMT dictionary. Such a dictionary can nicely be created 
using the pmt.pmt_to_python.python_to_pmt function, e.g.


command_dictionary = pmt.pmt_to_python.python_to_pmt(
 { "time": (full_seconds, fractional_seconds),
   "tune": (target_frequency, dsp_offset) })

Also note that especially if you're doing this tuning within a range smaller than your 
USRP's master clock rate, you can use DSP-only tuning, and achieve "instant" tuning at the 
specified time stamp.


Note that the time the USRP gets initialized is "0" from the device's perspective. You can 
see the current time of the device in the rx_time tags on the USRP Source's stream.


Best regards,
Marcus

[1] https://wiki.gnuradio.org/index.php?title=USRP_Sink
[2] https://www.gnuradio.org/doc/doxygen/page_uhd.html#uhd_command_syntax_cmds
On 04.01.24 15:43, Oğuzhan Gedikli wrote:

Hello,

I have a system I set up with 2 different SDRs. One of the SDRs works as a transmitter and 
the other works as a receiver. When I want to change the center frequency of both of them, 
I use the code below.


usrp_sink.set_center_freq(uhd.tune_request(freq, rf_freq=freq - lo_offset, 
rf_freq_policy=uhd.tune_request.POLICY_MANUAL), 0)
usrp_source.set_center_freq(uhd.tune_request(freq, rf_freq=freq - lo_offset, 
rf_freq_policy=uhd.tune_request.POLICY_MANUAL), 0)


I measured how long each one took. One of them (of course, I know it changes depending on 
the hopping frequency. I applied all the tests I mentioned at the same frequencies) takes 
180ms, and the other one takes 50ms.


50ms is of great importance to me because it repeats this process thousands of times 
during a measurement. For this reason, I wanted to run the 2 lines of code you see in 
parallel and I noticed that there was no change in the time. I tested the code I wrote to 
parallelize it; the code works. It starts both functions at the same time. Later, when I 
debugged the parts containing 'set_center_freq', I saw that the 'wait' command took up 
most of the time spent. I have not examined the contents of your library. I'm saying what 
I see on the debug screen. I did not write any 'wait' command myself. But I don't 
understand why one SDR keeps threading and prevents applying commands to the other.



footnote: There is no situation due to GIL. I tested this too.

Re: Python Bindings Out of Sync: Which files are out of sync?

[Josh Morman]

Hi Glen,

The file that is out of sync is
vsum_python.cc

This can be updated using
gr_modtool bind vsum

This ensures that changes in vsum.h are reflected in the python bindings.

Josh

On Thu, Jan 4, 2024 at 2:05 PM Glen Langston 
wrote:

> Hello
>
> I’m running gnuradio 3.9.x and am writing a couple simple C++ blocks.
>
> in ~/test/lib
>
> I have vsum_impl.cc  and vsum_impl.h
>
> In ~/test/python/radio_astro/bindings
>
> I have vsum.h
>
> I get these messages in the build “make ..” step:
>
> ...
> -- PYTHON and GRC components are enabled
> -- Python checking for pygccxml - not found
> -- Found PythonLibs: /usr/lib/aarch64-linux-gnu/libpython3.9.so
> -- Performing Test HAS_FLTO
> -- Performing Test HAS_FLTO - Success
> -- Found pybind11: /usr/include (found version "2.6.2" )
> CMake Error at /usr/local/lib/cmake/gnuradio/GrPybind.cmake:221 (message):
>   Python bindings for vsum.h are out of sync
> Call Stack (most recent call first):
>   python/radio_astro/bindings/CMakeLists.txt:39 (GR_PYBIND_MAKE_OOT)
>
>
> -- Configuring incomplete, errors occurred!
> See also
> "/home/radioastro/Research/gr-radio_astro/build/CMakeFiles/CMakeOutput.log".
> See also
> "/home/radioastro/Research/gr-radio_astro/build/CMakeFiles/CMakeError.log".
>
> Could someone remind me exactly which files are “out of sync”?
>
> vsum.h must be one, but which is the other?   I think that vsum_impl.h and
> vsum.h are consistent
> (but not, of course, identical).
>
> Thanks!
>
> Glen
>
>
>
> > On Dec 30, 2023, at 8:16 AM, Marcus Müller 
> wrote:
> >
> > Heyo Kimmo,
> > sorry for the delayed response:
> > On 29.12.23 01:00, Kimmo Lehtinen wrote:
> >> I would like to make modifications to the following two GNURadio blocks:
> >> 1) QT GUI number sink---
> >> I would like to modify it so that it can also display integers and
> strings. Currently it can display floats, shorts and bytes.
> >> I raised an issue about this at the Github page of GNURadio, and I got
> the following reply:"A number of GR blocks infer type from item size, and
> that's what this block does (in its constructor). Unfortunately, float and
> int32 are the same size, so int32 is not usable.It would be possible to add
> another constructor that uses an explicit type instead of item size."
> > Warning: this is probably more involved than you hoped for. If you've
> worked with C++ before: No problem, you can at any point always ask for
> help. It's also super helpful to use "Draft PR" on github to share your
> current state of affairs!
> > If you haven't: I think this might be a bit too hard.
> > Yep, you would need to copy the make function as declared in
> number_sink.h in [0]:
> > static sptr make(size_t itemsize,
> >  float average = 0,
> >  graph_t graph_type = NUM_GRAPH_HORIZ,
> >  int nconnections = 1,
> >  QWidget* parent = NULL);
> >
> > to a second make function that has a different signature, for example
> > static sptr make(item_type_t itemtype,
> >  float average = 0,
> >  graph_t graph_type = NUM_GRAPH_HORIZ,
> >  int nconnections = 1,
> >  QWidget* parent = NULL);
> > where item_type_t is a "Scoped enum"/class enum [1]; something like,
> within number_sink class,
> > enum class item_type_t { FLOAT, INT32 , INT16, INT8 }; // or whatever
> types you want to support
> > Then you would actually need to implement that in number_sink_impl.cc
> like [2]. But for that you need to modify the actual constructor to not
> take size_t itemsize as argument [3], but item_type_t itemtype!
> > You would add a field const item_type_t d_itemtype and remove d_itemsize
> in number_sink_impl.h [4] and add it to the initializer list [5]; you'd
> want a switch()/case construct to set the alignment_multiple [6].
> > Then, you replace the switch (d_itemsize) in get_item [7] with an
> appropriate switch(d_itemtype).
> > Test it successfully compiles!
> > Now you only need to do two things to
> gr-qtgui/python/qtgui/bindings/number_sink_python.cc
> > • add the new class enum item_type_t to bind_number_sink [8],
> > • add the new make function:
> > • modify the existing definition and
> > • copy it to replace size_t itemsize with
> number_sink::item_type_t itemtype
> > In detail: following [9], you need to change
> > py::class_ >gr::sync_block,
> >gr::block,
> >gr::basic_block,
> >std::shared_ptr>(m, "number_sink",
> D(number_sink))
> >
> > .def(py::init(&number_sink::make),
> > ………
> >
> > into
> > py::class_ >gr::sync_block,
> >gr::block,
> >gr::basic_block,
> >std::shared_ptr>
> > number_sink_wrapper(m, "number_sink", D(number_sink));
> >
> > py::enum_(number_sink_wrapper,
> "item_ty

Python Bindings Out of Sync: Which files are out of sync?

[Glen Langston]

Hello

I’m running gnuradio 3.9.x and am writing a couple simple C++ blocks.

in ~/test/lib 

I have vsum_impl.cc  and vsum_impl.h

In ~/test/python/radio_astro/bindings

I have vsum.h

I get these messages in the build “make ..” step:

...
-- PYTHON and GRC components are enabled
-- Python checking for pygccxml - not found
-- Found PythonLibs: /usr/lib/aarch64-linux-gnu/libpython3.9.so
-- Performing Test HAS_FLTO
-- Performing Test HAS_FLTO - Success
-- Found pybind11: /usr/include (found version "2.6.2" )
CMake Error at /usr/local/lib/cmake/gnuradio/GrPybind.cmake:221 (message):
  Python bindings for vsum.h are out of sync
Call Stack (most recent call first):
  python/radio_astro/bindings/CMakeLists.txt:39 (GR_PYBIND_MAKE_OOT)


-- Configuring incomplete, errors occurred!
See also 
"/home/radioastro/Research/gr-radio_astro/build/CMakeFiles/CMakeOutput.log".
See also 
"/home/radioastro/Research/gr-radio_astro/build/CMakeFiles/CMakeError.log".

Could someone remind me exactly which files are “out of sync”?

vsum.h must be one, but which is the other?   I think that vsum_impl.h and 
vsum.h are consistent
(but not, of course, identical).

Thanks!

Glen



> On Dec 30, 2023, at 8:16 AM, Marcus Müller  wrote:
> 
> Heyo Kimmo,
> sorry for the delayed response:
> On 29.12.23 01:00, Kimmo Lehtinen wrote:
>> I would like to make modifications to the following two GNURadio blocks:
>> 1) QT GUI number sink---
>> I would like to modify it so that it can also display integers and strings. 
>> Currently it can display floats, shorts and bytes.
>> I raised an issue about this at the Github page of GNURadio, and I got the 
>> following reply:"A number of GR blocks infer type from item size, and that's 
>> what this block does (in its constructor). Unfortunately, float and int32 
>> are the same size, so int32 is not usable.It would be possible to add 
>> another constructor that uses an explicit type instead of item size."
> Warning: this is probably more involved than you hoped for. If you've worked 
> with C++ before: No problem, you can at any point always ask for help. It's 
> also super helpful to use "Draft PR" on github to share your current state of 
> affairs!
> If you haven't: I think this might be a bit too hard.
> Yep, you would need to copy the make function as declared in number_sink.h in 
> [0]:
> static sptr make(size_t itemsize,
>  float average = 0,
>  graph_t graph_type = NUM_GRAPH_HORIZ,
>  int nconnections = 1,
>  QWidget* parent = NULL);
> 
> to a second make function that has a different signature, for example
> static sptr make(item_type_t itemtype,
>  float average = 0,
>  graph_t graph_type = NUM_GRAPH_HORIZ,
>  int nconnections = 1,
>  QWidget* parent = NULL);
> where item_type_t is a "Scoped enum"/class enum [1]; something like, within 
> number_sink class,
> enum class item_type_t { FLOAT, INT32 , INT16, INT8 }; // or whatever types 
> you want to support
> Then you would actually need to implement that in number_sink_impl.cc like 
> [2]. But for that you need to modify the actual constructor to not take 
> size_t itemsize as argument [3], but item_type_t itemtype!
> You would add a field const item_type_t d_itemtype and remove d_itemsize in 
> number_sink_impl.h [4] and add it to the initializer list [5]; you'd want a 
> switch()/case construct to set the alignment_multiple [6].
> Then, you replace the switch (d_itemsize) in get_item [7] with an appropriate 
> switch(d_itemtype). 
> Test it successfully compiles!
> Now you only need to do two things to 
> gr-qtgui/python/qtgui/bindings/number_sink_python.cc 
> • add the new class enum item_type_t to bind_number_sink [8],
> • add the new make function:
> • modify the existing definition and
> • copy it to replace size_t itemsize with number_sink::item_type_t 
> itemtype
> In detail: following [9], you need to change
> py::class_gr::sync_block,
>gr::block,
>gr::basic_block,
>std::shared_ptr>(m, "number_sink", D(number_sink))
> 
> .def(py::init(&number_sink::make), 
> ………
> 
> into
> py::class_gr::sync_block,
>gr::block,
>gr::basic_block,
>std::shared_ptr>
> number_sink_wrapper(m, "number_sink", D(number_sink));
> 
> py::enum_(number_sink_wrapper, "item_type_t");
> 
> number_sink_wrapper
> .def(py::init(&number_sink::make),
> 
> Please compile the result (make sure to make clean before, we've changed 
> bindings), and test it works, from python!
> Now, we need to tell GRC that there's a new way to create a Qt GUI number 
> sink! So, modify qtgui_humber_sink.block.yml [10] to use the new make 
> function instead of 

2 SDRs – Parallel Programming

[Oğuzhan Gedikli]

Hello,

I have a system I set up with 2 different SDRs. One of the SDRs works as a 
transmitter and the other works as a receiver. When I want to change the center 
frequency of both of them, I use the code below.

usrp_sink.set_center_freq(uhd.tune_request(freq, rf_freq=freq - lo_offset, 
rf_freq_policy=uhd.tune_request.POLICY_MANUAL), 0)
usrp_source.set_center_freq(uhd.tune_request(freq, rf_freq=freq - lo_offset, 
rf_freq_policy=uhd.tune_request.POLICY_MANUAL), 0)

I measured how long each one took. One of them (of course, I know it changes 
depending on the hopping frequency. I applied all the tests I mentioned at the 
same frequencies) takes 180ms, and the other one takes 50ms.


50ms is of great importance to me because it repeats this process thousands of 
times during a measurement. For this reason, I wanted to run the 2 lines of 
code you see in parallel and I noticed that there was no change in the time. I 
tested the code I wrote to parallelize it; the code works. It starts both 
functions at the same time. Later, when I debugged the parts containing 
'set_center_freq', I saw that the 'wait' command took up most of the time 
spent. I have not examined the contents of your library. I'm saying what I see 
on the debug screen. I did not write any 'wait' command myself. But I don't 
understand why one SDR keeps threading and prevents applying commands to the 
other.


footnote: There is no situation due to GIL. I tested this too.