Monday, May 31, 2021

SPAWC21: ML for Multi-Domain Localization and Signal Recognition Data Competition Call for Participation!

Call for IEEE SPAWC Data Competition Paper Submissions & Competitors!

 

=======================================

 

IEEE Workshop on Signal Processing Advances in Wireless Communications (SPAWC) 2021

September 27 – 30, 2021  --   Lucca, Italy (And Online Hybrid Event)

 

=======================================

 

SPAWC is hosting two exciting data competition this year at the intersection of wireless communications and machine learning and soliciting competitors both through paper submissions on approaches to these problems and through direct participation in the competitions through submission of scored results.

 

We will accept the submission of full papers with proposed approaches and solutions to the data competition problem statements and datasets through July 5th and will accept competition solution entries through the beginning of the conference on September 27th through the data competition sites hosted on Kaggle and eval.ai.

 

Full details for the data competition event may be found at the official conference website at https://www.spawc2021.com/data-competition/

Challenge #1 (Industrial Multi-Domain Localization) focuses on Industry 4.0 centric robust and versatile positioning of robotic devices using a combination of Camera-based, IMU-Based and ultra-wideband (UWB) based data observations requiring the fusion of multiple domains of observation to maximize precision.  As robust and precise radio emitter localization is a key component in future industry and factory applications, we are excited to launch this data-driven challenge as part of SPAWC 21.

https://www.kaggle.com/c/ieeespawc21localization/data

 

Challenge #2 (Wideband Signal Recognition) focuses on rapid spectrum awareness and signal recognition to enable radio spectrum access coordination, anomaly detection, spectrum sharing, spectrum analytics and spectrum monitoring applications.  As real-time spectrum awareness and spectrum aware decision making may be key components to beyond-5G and 6G communications systems, we are excited to launch this data-driven signal recognition competition as part of SPAWC this year to compare and contrast new promising approaches to the problem.

https://eval.ai/web/challenges/challenge-page/1057/overview

 

Both address key challenge areas where machine learning has demonstrated extremely promising initial results in related areas, but where we believe these datasets provide an exciting new step in expanding these results to multi-domain and to broad recognition challenges beyond what has been the principal focus in research publications thus far.   Thus, we hope by posing these two challenges we can excite new researchers to propose, compare and publish new approaches to these problems which can help accelerate and mature these domains at the intersection of communications systems and machine learning.

 

We're soliciting full workshop papers via EDAS (https://edas.info/newPaper.php?c=28267) from competitors wishing to publish their approaches and ideas as well as competition submissions via Kaggle and eval.ai which may be submitted directly via the competition websites above until the beginning of the Conference event.

 

Best Regards,

Tim O'Shea

Data Competition Chair, SPAWC21

 

Re: USRP N200

On 05/31/2021 06:23 AM, Skyvalakis Konstantinos wrote:

Hi,


I have 2 USRP N200 devices equipped with an SBX daughterboard each.


I want to build a 1 Tx, 2 Rx system, where everything is synchronized.


​I have an external generator to provide 10MHz ref clock and PPS input for both USRP devices with equal length cables.


The 1st USRP, with the SBX daughterboard, is both Tx and Rx.


The 2nd USRP, with the SBX daughterboard, is just Rx.


Phase synchronization is crucial to my application and thus I really need to know if I am doing it right or not.


Therefore, I am attaching the following code in Python, that I use to synchronize the devices and I would like to know if it's correct or not.


  def usrp_init(self):
    self.source = [None, None]
    self.source[0] = uhd.usrp_source(
    device_addr=self.usrp_address_source[0],
    stream_args=uhd.stream_args(
    cpu_format="fc32",
    channels=range(1),
    ),
    )

    self.source[1] = uhd.usrp_source(
    device_addr=self.usrp_address_source[1],
    stream_args=uhd.stream_args(
    cpu_format="fc32",
    channels=range(1),
    ),
    )

    self.sink = uhd.usrp_sink(
    device_addr=self.usrp_address_sink,
    stream_args=uhd.stream_args(
    cpu_format="fc32",
    channels=range(1),
    ),
    )

    self.source[0].set_clock_source('external', 0);
    self.source[0].set_time_source('external', 0);
    self.source[0].set_time_unknown_pps(uhd.time_spec())
    self.source[0].set_samp_rate(self.adc_rate)
    self.source[0].set_gain(self.rx_gain0, 0)
    self.source[0].set_antenna("RX2", 0)

    self.source[1].set_clock_source('external', 0)
    self.source[1].set_time_source('external', 0)
    self.source[1].set_time_unknown_pps(uhd.time_spec())
    self.source[1].set_samp_rate(self.adc_rate)
    self.source[1].set_gain(self.rx_gain1, 0)
    self.source[1].set_antenna("RX2", 0)

    self.sink.set_clock_source('external', 0);
    self.sink.set_time_source('external', 0);
    self.sink.set_time_unknown_pps(uhd.time_spec())
    self.sink.set_samp_rate(self.dac_rate)
    self.sink.set_gain(self.tx_gain, 0)
    self.sink.set_antenna("TX/RX", 0)

    time.sleep(1)

    cmd_time0 = self.source[0].get_time_last_pps()
    cmd_time1 = self.source[1].get_time_last_pps()
    cmd_time2 = self.sink.get_time_last_pps()
    real_seconds0 = uhd.time_spec_t.get_real_secs(cmd_time0)
    real_seconds1 = uhd.time_spec_t.get_real_secs(cmd_time1)
    real_seconds2 = uhd.time_spec_t.get_real_secs(cmd_time2)
    future_real_seconds0 = real_seconds0 + 1
    future_real_seconds1 = real_seconds1 + 1
    future_real_seconds2 = real_seconds2 + 1
    future_cmd_time0 = uhd.time_spec_t(future_real_seconds0)
    future_cmd_time1 = uhd.time_spec_t(future_real_seconds1)
    future_cmd_time2 = uhd.time_spec_t(future_real_seconds2)
    self.source[0].set_command_time(future_cmd_time0)
    self.source[1].set_command_time(future_cmd_time1)
    self.sink.set_command_time(future_cmd_time2)
    self.source[0].set_center_freq(uhd.tune_request(self.freq,0), 0)
    self.source[1].set_center_freq(uhd.tune_request(self.freq,0), 0)
    self.sink.set_center_freq(uhd.tune_request(self.freq,0), 0)
    self.source[0].clear_command_time()
    self.source[1].clear_command_time()
    self.sink.clear_command_time()

Thanks in advance.

Konstantinos


Your RX streams need to be coming from a SINGLE multi_usrp object, not separate objects.

Please see the rx_multi_samples example code.

Also there's a good knowledge-base article about synchronization:

https://kb.ettus.com/Synchronization_and_MIMO_Capability_with_USRP_Devices


USRP N200

Hi,


I have 2 USRP N200 devices equipped with an SBX daughterboard each.


I want to build a 1 Tx, 2 Rx system, where everything is synchronized.


​I have an external generator to provide 10MHz ref clock and PPS input for both USRP devices with equal length cables.


The 1st USRP, with the SBX daughterboard, is both Tx and Rx.


The 2nd USRP, with the SBX daughterboard, is just Rx.


Phase synchronization is crucial to my application and thus I really need to know if I am doing it right or not.


Therefore, I am attaching the following code in Python, that I use to synchronize the devices and I would like to know if it's correct or not.


  def usrp_init(self):
    self.source = [None, None]
    self.source[0] = uhd.usrp_source(
    device_addr=self.usrp_address_source[0],
    stream_args=uhd.stream_args(
    cpu_format="fc32",
    channels=range(1),
    ),
    )

    self.source[1] = uhd.usrp_source(
    device_addr=self.usrp_address_source[1],
    stream_args=uhd.stream_args(
    cpu_format="fc32",
    channels=range(1),
    ),
    )

    self.sink = uhd.usrp_sink(
    device_addr=self.usrp_address_sink,
    stream_args=uhd.stream_args(
    cpu_format="fc32",
    channels=range(1),
    ),
    )

    self.source[0].set_clock_source('external', 0);
    self.source[0].set_time_source('external', 0);
    self.source[0].set_time_unknown_pps(uhd.time_spec())
    self.source[0].set_samp_rate(self.adc_rate)
    self.source[0].set_gain(self.rx_gain0, 0)
    self.source[0].set_antenna("RX2", 0)

    self.source[1].set_clock_source('external', 0)
    self.source[1].set_time_source('external', 0)
    self.source[1].set_time_unknown_pps(uhd.time_spec())
    self.source[1].set_samp_rate(self.adc_rate)
    self.source[1].set_gain(self.rx_gain1, 0)
    self.source[1].set_antenna("RX2", 0)

    self.sink.set_clock_source('external', 0);
    self.sink.set_time_source('external', 0);
    self.sink.set_time_unknown_pps(uhd.time_spec())
    self.sink.set_samp_rate(self.dac_rate)
    self.sink.set_gain(self.tx_gain, 0)
    self.sink.set_antenna("TX/RX", 0)

    time.sleep(1)

    cmd_time0 = self.source[0].get_time_last_pps()
    cmd_time1 = self.source[1].get_time_last_pps()
    cmd_time2 = self.sink.get_time_last_pps()
    real_seconds0 = uhd.time_spec_t.get_real_secs(cmd_time0)
    real_seconds1 = uhd.time_spec_t.get_real_secs(cmd_time1)
    real_seconds2 = uhd.time_spec_t.get_real_secs(cmd_time2)
    future_real_seconds0 = real_seconds0 + 1
    future_real_seconds1 = real_seconds1 + 1
    future_real_seconds2 = real_seconds2 + 1
    future_cmd_time0 = uhd.time_spec_t(future_real_seconds0)
    future_cmd_time1 = uhd.time_spec_t(future_real_seconds1)
    future_cmd_time2 = uhd.time_spec_t(future_real_seconds2)
    self.source[0].set_command_time(future_cmd_time0)
    self.source[1].set_command_time(future_cmd_time1)
    self.sink.set_command_time(future_cmd_time2)
    self.source[0].set_center_freq(uhd.tune_request(self.freq,0), 0)
    self.source[1].set_center_freq(uhd.tune_request(self.freq,0), 0)
    self.sink.set_center_freq(uhd.tune_request(self.freq,0), 0)
    self.source[0].clear_command_time()
    self.source[1].clear_command_time()
    self.sink.clear_command_time()

Thanks in advance.

Konstantinos


Saturday, May 29, 2021

Re: Error with dynamically changing block parameter

Hi all,

Just replying to my previous message for the benefit of everyone else
whos also trying to do make a OOT that responds dynamically to changes
in a parameter (e.g. through QT GUI Range).

The key is to add your setter function (which sets your parameter) to
`callback` in your block's YAML file. See
https://wiki.gnuradio.org/index.php/YAML_GRC#Templates for more
information.

In my preceding email, I had problems because I tried to use
gr_controlport. I barked up the wrong tree.

Thanks to Derek Kozel for sharing this information with me.

Cheers,
Sol

On 13/5/21 12:03 am, Solomon Tan wrote:
> Hi all,
>
> I am trying to make my OOT block respond to changes in its parameter the
> same way the Add Const block behaves. I want my block to update its
> value as and when the user slides the qtgui range. I notice this is not
> done by default. I added the same `add_rpc_variable` function defined in
> `gr-blocks/lib/add_const_ff_impl.cc`. I replaced the appropriate
> variable/function names with my own. However, I get the following error.
>
> ```
> error: no matching function for call to
> 'rpcbasic_register_set<gr::my_OOT::reactionFunction_impl,
> float>::rpcbasic_register_set(std::string, const char [9], void
> (gr::my_OOT::reactionFunction_impl::*)(int), pmt::pmt_t, pmt::pmt_t,
> pmt::pmt_t, const char [1], const char [16], priv_lvl_t, const uint32_t&)'
> 225 |
> DISPNULL)));
> ```
>
> I imported the same header files that `add_const_ff_impl.h` and
> `add_const.h` import. What does the error mean. What have I done
> incorrectly? I couldnt find a thread describing the same problem in the
> archives.
>
> Does someone have an easier way to do what I wanna do?
>
> Thanks.
> Cheers,
> Sol
>

European GNU Radio Days contest for winning a B205mini

Dear GNU Radio enthusiasts,
as part of the virtual event European GNU Radio Days to be held June
24--26, 2021 as a joint meeting with the Software Defined Radio Academy
for the Saturday session, our generous sponsor NI is donating two
B205mini. A challenge has been set to select the winners amongst the
participants, as provided at
https://gnuradio-eu-21.sciencesconf.org/resource/page/id/3

The first two best entries will be offered the B205mini units selected
on the provided answers.

Best wishes and good luck,
for the European GNU Radio Days organizing committee, JM

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

Re: RRC filter understanding

Yes there will be a difference, the RRC filter block is just a wrapper for a call to firdes to design an RRC with the specified sampling rate/symbol rate/excess bandwidth/ntap. The designed taps are then used in a fir filter block whose decimation or interpolation is determined by the field you provide. So If you put in the parameters you mentioned, you'd have designed a 4 Sample/symbol RRC and stuck it into a FIR filter doing 128x interpolation (128x zero insertion followed by filtering using your RRC) - this is probably not what you wanted. In most cases I'd agree you want the interp to match your SPS. I can imagine some usecases where you'd want to filter received data without downsampling it which this block allows you to do but I'm blanking on other uses for this functionality.

On Sat, May 29, 2021 at 9:33 AM Ivan Penchev Ivanov <ivan.pe.ivanov@gmail.com> wrote:
Having a background with Matlab, now I am working on QPSK transceiver in Gnuradio.
I have a question for understanding RRC filter parameters in Gnuradio.
Let's take an RRC interpolation filter in the transmitter. There are parameters for sample rate and for symbol rate. Suppose my sample rate is 32 kHz (typical default  value) and for the symbol rate I put 8 kHz. Isn't it obvious that interpolation is 4, so I have 4 samples per symbol. My question is why is there a dedicated parameter for interpolation? What function will it have? What would be the difference if instead of 4 in the field interpolation, I put 128?

Best regards.

RRC filter understanding

Having a background with Matlab, now I am working on QPSK transceiver in Gnuradio.
I have a question for understanding RRC filter parameters in Gnuradio.
Let's take an RRC interpolation filter in the transmitter. There are parameters for sample rate and for symbol rate. Suppose my sample rate is 32 kHz (typical default  value) and for the symbol rate I put 8 kHz. Isn't it obvious that interpolation is 4, so I have 4 samples per symbol. My question is why is there a dedicated parameter for interpolation? What function will it have? What would be the difference if instead of 4 in the field interpolation, I put 128?

Best regards.

Friday, May 28, 2021

Re: Phase Synchronize 2 USRP N200 w/ SBX cards

So you are presumably using timed commands for tuning, and making sure both devices are set to exactly the same time on the PPS pulse?

What is the magnitude of the phase difference that you're seeing!

Sent from my iPhone

On May 28, 2021, at 6:30 AM, Skyvalakis Konstantinos <kskyvalakis@isc.tuc.gr> wrote:



Hi,


I have 2 USRP N200 devices equipped with an SBX daughterboard each.


I also have a function generator to provide PPS and 10MHz reference signals, to both USRP devices with equal length cables.


The problem is that I want to synchronize the 2 SBX daughterboards, so that I get a consistent phase measurement everytime I run my code.


 What I mean by consistent phase measurement, is that I want to be getting more or less the exact same phase measurement in the static environment where I perform my experiments.


And I want to be getting that same phase measurement even if I power-cycle the devices (i.e. turn them off and back on again ). I need to have reproducibility.


I have tried various instructions found in the knowledge base of Ettus and around the internet like in the mailing-lists or on stackexchange but unfortunately nothing has worked for me so far.


I managed to kill the CFO between the devices, but I still haven't managed to kill the phase difference between them.


Feel free to ask me any questions that might help solve my problem.


Thanks in advance.


Konstantinos

Phase synchronize 2 USRP N200 w/ SBX cards

Hi,


I have 2 USRP N200 devices equipped with an SBX daughterboard each.


I also have a function generator to provide PPS and 10MHz reference signals, to both USRP devices with equal length cables.


The problem is that I want to synchronize the 2 SBX daughterboards, so that I get a consistent phase measurement everytime I run my code.


 What I mean by consistent phase measurement, is that I want to be getting more or less the exact same phase measurement in the static environment where I perform my experiments.


And I want to be getting that same phase measurement even if I power-cycle the devices (i.e. turn them off and back on again ). I need to have reproducibility.


I have tried various instructions found in the knowledge base of Ettus and around the internet like in the mailing-lists or on stackexchange but unfortunately nothing has worked for me so far.


I managed to kill the CFO between the devices, but I still haven't managed to kill the phase difference between them.


Feel free to ask me any questions that might help solve my problem.


Thanks in advance.


Konstantinos​


Phase Synchronize 2 USRP N200 w/ SBX cards

Hi,


I have 2 USRP N200 devices equipped with an SBX daughterboard each.


I also have a function generator to provide PPS and 10MHz reference signals, to both USRP devices with equal length cables.


The problem is that I want to synchronize the 2 SBX daughterboards, so that I get a consistent phase measurement everytime I run my code.


 What I mean by consistent phase measurement, is that I want to be getting more or less the exact same phase measurement in the static environment where I perform my experiments.


And I want to be getting that same phase measurement even if I power-cycle the devices (i.e. turn them off and back on again ). I need to have reproducibility.


I have tried various instructions found in the knowledge base of Ettus and around the internet like in the mailing-lists or on stackexchange but unfortunately nothing has worked for me so far.


I managed to kill the CFO between the devices, but I still haven't managed to kill the phase difference between them.


Feel free to ask me any questions that might help solve my problem.


Thanks in advance.


Konstantinos

Thursday, May 27, 2021

Re: launching gnuradio generated python file core dumps

Looks like a double-free in the destructor for the number sink. Please add an issue. Shouldn't slow you down though since it only happens on exit.

On Thu, May 27, 2021 at 8:04 PM Chris Gorman <chrisjohgorman@gmail.com> wrote:
Hello All,

I'm generating a python file that attempts to replicate Victor Cai's
MFCW radar.  I don't know for sure if I've implemented it correctly,
but it causes a core dump when run.  I'm using the feature/gr-iio
branch, v3.10.0.0git-341-g131f32c7.  I don't have to run the program,
just launch and close the window and I get the following...

[chris@descartes radar]$ ./mfcw.py
free(): invalid pointer
Aborted (core dumped)

When I run the program using gdb, I get...

(gdb) run mfcw.py
Starting program: /usr/bin/python mfcw.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x7fffe6b80640 (LWP 50441)]
[New Thread 0x7fffe635d640 (LWP 50442)]
[New Thread 0x7fffe5910640 (LWP 50443)]
[Thread 0x7fffe5910640 (LWP 50443) exited]
[New Thread 0x7fffe5910640 (LWP 50444)]
[New Thread 0x7fffe510f640 (LWP 50445)]
---snip---
[New Thread 0x7fff75d9f640 (LWP 50473)]
[New Thread 0x7fff7559e640 (LWP 50476)]
[Thread 0x7fff927fc640 (LWP 50464) exited]
[Thread 0x7fff92ffd640 (LWP 50463) exited]
---snip---
[Thread 0x7fffd7e67640 (LWP 50447) exited]
[Thread 0x7fffb3fff640 (LWP 50454) exited]
[Thread 0x7fff7559e640 (LWP 50476) exited]
[Thread 0x7fff765a0640 (LWP 50472) exited]
[Thread 0x7fff75d9f640 (LWP 50473) exited]
[Thread 0x7fff80ff9640 (LWP 50471) exited]
[Thread 0x7fff817fa640 (LWP 50470) exited]
[Thread 0x7fffe6b80640 (LWP 50441) exited]
[Thread 0x7fff81ffb640 (LWP 50469) exited]
[Thread 0x7fff827fc640 (LWP 50468) exited]
[Thread 0x7fff82ffd640 (LWP 50467) exited]
[Thread 0x7fff837fe640 (LWP 50466) exited]
[Thread 0x7fff83fff640 (LWP 50465) exited]
free(): invalid pointer
Thread 1 "python" received signal SIGABRT, Aborted.
0x00007ffff7a58d22 in raise () from /usr/lib/libc.so.6
(gdb) bt
#0  0x00007ffff7a58d22 in raise () at /usr/lib/libc.so.6
#1  0x00007ffff7a42862 in abort () at /usr/lib/libc.so.6
#2  0x00007ffff7a9ad28 in __libc_message () at /usr/lib/libc.so.6
#3  0x00007ffff7aa292a in  () at /usr/lib/libc.so.6
#4  0x00007ffff7aa3cfc in _int_free () at /usr/lib/libc.so.6
#5  0x00007ffff7aa79e8 in free () at /usr/lib/libc.so.6
#6  0x00007fffeb1dfd6f in gr::qtgui::number_sink_impl::~number_sink_impl() ()
    at /usr/local/lib/libgnuradio-qtgui.so.3.10.0git
#7  0x00007fffeb1e0123 in virtual thunk to
gr::qtgui::number_sink_impl::~number_sink_impl() () at
/usr/local/lib/libgnuradio-qtgui.so.3.10.0git
#8  0x00007fffeb356e0a in  ()
    at /usr/local/lib/python3.9/site-packages/gnuradio/qtgui/qtgui_python.cpython-39-x86_64-linux-gnu.so
#9  0x00007fffeb37bce6 in  ()
    at /usr/local/lib/python3.9/site-packages/gnuradio/qtgui/qtgui_python.cpython-39-x86_64-linux-gnu.so
#10 0x00007fffeb34f9c4 in  ()
    at /usr/local/lib/python3.9/site-packages/gnuradio/qtgui/qtgui_python.cpython-39-x86_64-linux-gnu.so
#11 0x00007ffff7d09cb6 in  () at /usr/lib/libpython3.9.so.1.0
#12 0x00007ffff6d98f26 in  ()
    at /usr/lib/python3.9/site-packages/PyQt5/sip.cpython-39-x86_64-linux-gnu.so
#13 0x00007ffff6d9a194 in  ()
    at /usr/lib/python3.9/site-packages/PyQt5/sip.cpython-39-x86_64-linux-gnu.so
#14 0x00007ffff7d029ac in  () at /usr/lib/libpython3.9.so.1.0
#15 0x00007ffff7dc17de in  () at /usr/lib/libpython3.9.so.1.0
#16 0x00007ffff7df09ba in PyGC_Collect () at /usr/lib/libpython3.9.so.1.0
#17 0x00007ffff7dee8a9 in Py_FinalizeEx () at /usr/lib/libpython3.9.so.1.0
#18 0x00007ffff7de643c in Py_RunMain () at /usr/lib/libpython3.9.so.1.0
#19 0x00007ffff7db7349 in Py_BytesMain () at /usr/lib/libpython3.9.so.1.0
#20 0x00007ffff7a43b25 in __libc_start_main () at /usr/lib/libc.so.6
#21 0x000055555555504e in _start ()

Since my last post was a known bug, I searched the issue tracker at
github for gnuradio, but I couldn't find anything about this one.
Should I move this there?

Thanks in advance,

Chris

launching gnuradio generated python file core dumps

Hello All,

I'm generating a python file that attempts to replicate Victor Cai's
MFCW radar. I don't know for sure if I've implemented it correctly,
but it causes a core dump when run. I'm using the feature/gr-iio
branch, v3.10.0.0git-341-g131f32c7. I don't have to run the program,
just launch and close the window and I get the following...

[chris@descartes radar]$ ./mfcw.py
free(): invalid pointer
Aborted (core dumped)

When I run the program using gdb, I get...

(gdb) run mfcw.py
Starting program: /usr/bin/python mfcw.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x7fffe6b80640 (LWP 50441)]
[New Thread 0x7fffe635d640 (LWP 50442)]
[New Thread 0x7fffe5910640 (LWP 50443)]
[Thread 0x7fffe5910640 (LWP 50443) exited]
[New Thread 0x7fffe5910640 (LWP 50444)]
[New Thread 0x7fffe510f640 (LWP 50445)]
---snip---
[New Thread 0x7fff75d9f640 (LWP 50473)]
[New Thread 0x7fff7559e640 (LWP 50476)]
[Thread 0x7fff927fc640 (LWP 50464) exited]
[Thread 0x7fff92ffd640 (LWP 50463) exited]
---snip---
[Thread 0x7fffd7e67640 (LWP 50447) exited]
[Thread 0x7fffb3fff640 (LWP 50454) exited]
[Thread 0x7fff7559e640 (LWP 50476) exited]
[Thread 0x7fff765a0640 (LWP 50472) exited]
[Thread 0x7fff75d9f640 (LWP 50473) exited]
[Thread 0x7fff80ff9640 (LWP 50471) exited]
[Thread 0x7fff817fa640 (LWP 50470) exited]
[Thread 0x7fffe6b80640 (LWP 50441) exited]
[Thread 0x7fff81ffb640 (LWP 50469) exited]
[Thread 0x7fff827fc640 (LWP 50468) exited]
[Thread 0x7fff82ffd640 (LWP 50467) exited]
[Thread 0x7fff837fe640 (LWP 50466) exited]
[Thread 0x7fff83fff640 (LWP 50465) exited]
free(): invalid pointer
Thread 1 "python" received signal SIGABRT, Aborted.
0x00007ffff7a58d22 in raise () from /usr/lib/libc.so.6
(gdb) bt
#0 0x00007ffff7a58d22 in raise () at /usr/lib/libc.so.6
#1 0x00007ffff7a42862 in abort () at /usr/lib/libc.so.6
#2 0x00007ffff7a9ad28 in __libc_message () at /usr/lib/libc.so.6
#3 0x00007ffff7aa292a in () at /usr/lib/libc.so.6
#4 0x00007ffff7aa3cfc in _int_free () at /usr/lib/libc.so.6
#5 0x00007ffff7aa79e8 in free () at /usr/lib/libc.so.6
#6 0x00007fffeb1dfd6f in gr::qtgui::number_sink_impl::~number_sink_impl() ()
at /usr/local/lib/libgnuradio-qtgui.so.3.10.0git
#7 0x00007fffeb1e0123 in virtual thunk to
gr::qtgui::number_sink_impl::~number_sink_impl() () at
/usr/local/lib/libgnuradio-qtgui.so.3.10.0git
#8 0x00007fffeb356e0a in ()
at /usr/local/lib/python3.9/site-packages/gnuradio/qtgui/qtgui_python.cpython-39-x86_64-linux-gnu.so
#9 0x00007fffeb37bce6 in ()
at /usr/local/lib/python3.9/site-packages/gnuradio/qtgui/qtgui_python.cpython-39-x86_64-linux-gnu.so
#10 0x00007fffeb34f9c4 in ()
at /usr/local/lib/python3.9/site-packages/gnuradio/qtgui/qtgui_python.cpython-39-x86_64-linux-gnu.so
#11 0x00007ffff7d09cb6 in () at /usr/lib/libpython3.9.so.1.0
#12 0x00007ffff6d98f26 in ()
at /usr/lib/python3.9/site-packages/PyQt5/sip.cpython-39-x86_64-linux-gnu.so
#13 0x00007ffff6d9a194 in ()
at /usr/lib/python3.9/site-packages/PyQt5/sip.cpython-39-x86_64-linux-gnu.so
#14 0x00007ffff7d029ac in () at /usr/lib/libpython3.9.so.1.0
#15 0x00007ffff7dc17de in () at /usr/lib/libpython3.9.so.1.0
#16 0x00007ffff7df09ba in PyGC_Collect () at /usr/lib/libpython3.9.so.1.0
#17 0x00007ffff7dee8a9 in Py_FinalizeEx () at /usr/lib/libpython3.9.so.1.0
#18 0x00007ffff7de643c in Py_RunMain () at /usr/lib/libpython3.9.so.1.0
#19 0x00007ffff7db7349 in Py_BytesMain () at /usr/lib/libpython3.9.so.1.0
#20 0x00007ffff7a43b25 in __libc_start_main () at /usr/lib/libc.so.6
#21 0x000055555555504e in _start ()

Since my last post was a known bug, I searched the issue tracker at
github for gnuradio, but I couldn't find anything about this one.
Should I move this there?

Thanks in advance,

Chris

Recommendation for PCI-based SDR frontends

Hi everyone,
I'm looking for stable and affordable SDRs that can be connected and slotted into the computer through the standard  PCI bus. So far I have only found XTRX. I was wondering if there were other tested solutions out there. 

Regards,

Moses. 

Re: Problem changing LO with qt-gui range on Pluto SDR

Hi Chris,

apparently you just discovered a bug, that just by chance, has already
been fixed. Simply update to the latest feature/gr-iio and you'll be
good to go.

If you're interested in what went wrong, the set_params call erroneously
included the buffer_size, see [0] vs [1].

David

[0]
https://github.com/gnuradio/gnuradio/blob/da099c070c2d61607e40dbcaedeb0474e974c9a2/gr-iio/grc/iio_pluto_source.block.yml#L114
[1]
https://github.com/gnuradio/gnuradio/blob/da099c070c2d61607e40dbcaedeb0474e974c9a2/gr-iio/python/iio/bindings/pluto_source_python.cc#L58-L72

On 5/27/21 10:10 PM, Chris Gorman wrote:
> Invoked with: <gnuradio.iio.iio_python.pluto_source object at
> 0x7f7c4a0095b0>, 102400000, 1536000, 20000000, 32768, True, True,
> True, 'slow_attack', 64, 'Design', '', 384000.0, 512000.0

Problem changing LO with qt-gui range on Pluto SDR

Hello All,

I am having difficulty using a qt-gui range with my plutosdr to change
the LO frequency. I am using the feature/gr-iio branch,
v3.10.0.0git-297-gb13303bd. When I run my python file and try to
change the LO frequency with a qt-gui range, I get the following
error.

[chris@descartes gnuradio]$ ./pluto_radio.py
Traceback (most recent call last):
File "/usr/local/lib/python3.9/site-packages/gnuradio/qtgui/range.py",
line 186, in changed
self.notifyChanged(self.rangeType(val))
File "/usr/local/lib/python3.9/site-packages/gnuradio/qtgui/range.py",
line 285, in sliderChanged
self.notifyChanged(self.rangeType(value))
File "/home/chris/src/gnuradio/./pluto_radio.py", line 233, in set_f
self.iio_pluto_source_0.set_params(int(self.f*1e6), self.samp_rate,
20000000, 32768, True, True, True, 'slow_attack', 64, 'Design', '',
self.samp_rate/4, self.samp_rate/3)
TypeError: set_params(): incompatible function arguments. The
following argument types are supported:
1. (self: gnuradio.iio.iio_python.pluto_source, longfrequency:
int, samplerate: int, bandwidth: int, quadrature: bool, rfdc: bool,
bbdc: bool, gain: str, gain_value: float, filter_source: str = '',
filter_filename: str = '', Fpass: float = 0.0, Fstop: float = 0.0) ->
None

Invoked with: <gnuradio.iio.iio_python.pluto_source object at
0x7f7c4a0095b0>, 102400000, 1536000, 20000000, 32768, True, True,
True, 'slow_attack', 64, 'Design', '', 384000.0, 512000.0
Aborted (core dumped)

The python file is generated from the attached pluto_radio.grc file.

Should I create a ticket for this?

Thanks in advance,

Chris

Re: libosmo-dsp build hangs (required for gr-osmosdr)

I'd commented out fcd in the deps for gr-osmosdr. Here's what I currently have for diffs to gr-recipes:

$ git diff | cat
diff --git a/gr-osmosdr.lwr b/gr-osmosdr.lwr
index f40f1f9..5d2b084 100644
--- a/gr-osmosdr.lwr
+++ b/gr-osmosdr.lwr
@@ -29,11 +29,12 @@ depends:
 - airspy
 - airspyhf
 - soapysdr
-- gr-fcdproplus
+#- gr-fcdproplus
 description: Interface API independent of the underlying radio hardware
 gitbranch: master
 inherit: cmake
 # Let's always build this from source, not binaries
 source: git+https://git.osmocom.org/gr-osmosdr
+mirror: git+https://github.com/osmocom/gr-osmosdr
 vars:
   config_opt: ' -DENABLE_NONFREE=TRUE '
diff --git a/libhidapi.lwr b/libhidapi.lwr
index b0c817b..23c7e89 100644
--- a/libhidapi.lwr
+++ b/libhidapi.lwr
@@ -23,5 +23,6 @@ depends:
 inherit: autoconf
 satisfy:
   deb: libhidapi-dev
+  rpm: hidapi-devel
   pacman: hidapi
 source: git+https://github.com/signal11/hidapi.git
diff --git a/libiio.lwr b/libiio.lwr
index 633072d..30b1325 100644
--- a/libiio.lwr
+++ b/libiio.lwr
@@ -22,7 +22,7 @@ depends:
 - libxml
 - libusb
 description: Library for interfacing with IIO devices
-gitrev: tags/v0.18
+gitrev: tags/v0.21
 inherit: cmake
 satisfy:
   deb: libiio0 >= 0.9 && libiio-dev >= 0.9
diff --git a/libosmo-dsp.lwr b/libosmo-dsp.lwr
index e8e3595..375faa2 100644
--- a/libosmo-dsp.lwr
+++ b/libosmo-dsp.lwr
@@ -30,4 +30,5 @@ inherit: autoconf
 satisfy:
   port: libosmo-dsp
 source: git+https://git.osmocom.org/libosmo-dsp
+mirror: git+https://github.com/osmocom/libosmo-dsp
 installdir: .
diff --git a/libosmocore.lwr b/libosmocore.lwr
index 3818d6a..29aafff 100644
--- a/libosmocore.lwr
+++ b/libosmocore.lwr
@@ -33,5 +33,6 @@ description: A library with generic ulitity functions developed by Osmocom proje
 gitbranch: master
 inherit: autoconf
 source: git+https://git.osmocom.org/libosmocore
+mirror: git+https://github.com/osmocom/libosmocore
 vars:
   config_opt: ' --disable-libsctp '
diff --git a/rtl-sdr.lwr b/rtl-sdr.lwr
index 27301cc..fb073c4 100644
--- a/rtl-sdr.lwr
+++ b/rtl-sdr.lwr
@@ -30,5 +30,6 @@ satisfy:
   pacman: rtl-sdr
   rpm: rtl-sdr
 source: git+https://git.osmocom.org/rtl-sdr
+mirror: git+https://github.com/osmocom/rtl-sdr
 vars:
   config_opt: ' -DDETACH_KERNEL_DRIVER=ON '

On Thu, May 27, 2021 at 10:59 AM Johannes Demel <demel@ant.uni-bremen.de> wrote:
Hi Jeff,

thanks for your help. I decided to be a bit more pragmatic and just
install the missing piece.
On Ubuntu 20.04 the required package is `texlive-latex-extra` and
requires 182 MB of disk space.

All of this is part of my effort to install gr-osmosdr on GR 3.9.
Besides this hiccup, the pybombs recipe tries to install gr-fcdproplus
which seems to be stuck with 3.8. This project's CMake output is really
useful. Anyways, I decided to set gr-fcdproplus to `forceinstalled:
'True'` in my prefix config.yml. gr-osmosdr is kind enough to just skip
this dependency in that case.

Cheers
Johannes

On 27.05.21 11:32, Jeff Long wrote:
> Or could just install the missing LaTeX module. On Fedora, it's
> texlive-newunicodechar. For reference, no problems building libosmo-dsp
> here.
>
> On Thu, May 27, 2021 at 4:21 AM Johannes Demel <demel@ant.uni-bremen.de
> <mailto:demel@ant.uni-bremen.de>> wrote:
>
>     Thanks Jeff!
>
>     Unfortunately, these settings are already present in that config.yml. I
>     double checked the config.yml in my prefix as well. There are no
>     overwrites.
>
>     This is from `gr-recipes/libosmo-dsp.lwr`:
>     ```
>     configure: autoreconf -i -I /usr/share/aclocal && ./configure
>     --prefix=$prefix $config_opt
>     ```
>     I'd really like to learn about `$config_opt`. What value(s) are in
>     there?
>     I removed libosmo-dsp (also from the inventory.yml).
>
>     This is the output of `pybombs -v install libosmo-dsp`:
>     ```
>     [DEBUG] Requirements met.
>     [DEBUG] Using build directory:
>     /home/johannes/prefix/gnuradio/src/libosmo-dsp
>     [DEBUG] Configuring recipe libosmo-dsp
>     [DEBUG] Using vars - ordereddict([('config_opt', ''), ('builddir',
>     '/home/johannes/prefix/gnuradio/src/libosmo-dsp')])
>     [DEBUG] In cwd - /home/johannes/prefix/gnuradio/src/libosmo-dsp
>     [DEBUG] Executing command `$ autoreconf -i -I /usr/share/aclocal &&
>     ./configure --prefix=/home/johannes/prefix/gnuradio'
>     Configuring: (100%)
>     [DEBUG] Thread signaled termination or returned
>     [DEBUG] Return value: 0
>     [DEBUG] Configure successful.
>     [DEBUG] Setting state to `configured'
>     [DEBUG] Saving inventory to file
>     /home/johannes/prefix/gnuradio/.pybombs/inventory.yml...
>     [DEBUG] Building recipe libosmo-dsp
>     [DEBUG] In cwd - /home/johannes/prefix/gnuradio/src/libosmo-dsp
>     [DEBUG] Executing command `$ make -j64'
>     Building:    [
>     ```
>     This is where it hangs.
>
>     I just tried to run it on a host with a full LaTeX installation. There
>     it goes through without any issue.
>
>     My guess would be that I'd have to do a full LaTeX install. That's
>     something I'd like to avoid.
>
>     I'd like to skip the whole Doxygen part and hope the issue goes away. A
>     more narrow solution would be nice as well though.
>
>     Cheers
>     Johannes
>
>     On 26.05.21 19:17, Jeff Long wrote:
>      > In ~/.pybombs/config.yml
>      >
>      > - config:
>      >      makewidth: 4
>      >      builddocs: OFF
>      >      cmakebuildtype: Release
>      >
>      > On Wed, May 26, 2021 at 12:41 PM Johannes Demel
>     <demel@ant.uni-bremen.de <mailto:demel@ant.uni-bremen.de>
>      > <mailto:demel@ant.uni-bremen.de
>     <mailto:demel@ant.uni-bremen.de>>> wrote:
>      >
>      >     Hi all,
>      >
>      >     I'm trying to install gr-osmosdr with GR 3.9. Currently
>     pybombs hangs
>      >     during libosmo-dsp build. Unfortunately it just hangs forever
>     without
>      >     any output, but if I try it manually, I see:
>      >
>      >     ```
>      >     ! LaTeX Error: File `newunicodechar.sty' not found.
>      >
>      >     Type X to quit or <RETURN> to proceed,
>      >     or enter new name. (Default extension: sty)
>      >
>      >     Enter file name:
>      >     ```
>      >     Thus, I'd like to disable generating docs. All of this
>     happens while
>      >     docs are generated. There's a minimal latex install but I
>     don't want
>      >     any
>      >     more TeX on that machine.
>      >
>      >     I can't find the switch to disable docs. How do I do that? Or
>     disable
>      >     doxygen.
>      >
>      >     Cheers
>      >     Johannes
>      >
>      >     --
>      >     Johannes Demel M.Sc.
>      >     Research Engineer
>      >
>      >     University of Bremen
>      >     Department of Communications Engineering
>      >     Faculty 1 - Physics / Electrical Engineering
>      >     NW1, N2400
>      >     Otto-Hahn-Allee NW1
>      >     28359 Bremen
>      >
>      >     Phone +49 421 218-62393
>      > demel@ant.uni-bremen.de <mailto:demel@ant.uni-bremen.de>
>     <mailto:demel@ant.uni-bremen.de <mailto:demel@ant.uni-bremen.de>>
>      >
>      >     Secretariat
>      >     Tel. +49 421 218-62390
>      > preuss@ant.uni-bremen.de <mailto:preuss@ant.uni-bremen.de>
>     <mailto:preuss@ant.uni-bremen.de <mailto:preuss@ant.uni-bremen.de>>
>      >
>      > www.uni-bremen.de/en <http://www.uni-bremen.de/en>
>     <http://www.uni-bremen.de/en <http://www.uni-bremen.de/en>>
>      >
>      >     University of Bremen - Established 1971
>      >
>

Re: libosmo-dsp build hangs (required for gr-osmosdr)

Hi Jeff,

thanks for your help. I decided to be a bit more pragmatic and just
install the missing piece.
On Ubuntu 20.04 the required package is `texlive-latex-extra` and
requires 182 MB of disk space.

All of this is part of my effort to install gr-osmosdr on GR 3.9.
Besides this hiccup, the pybombs recipe tries to install gr-fcdproplus
which seems to be stuck with 3.8. This project's CMake output is really
useful. Anyways, I decided to set gr-fcdproplus to `forceinstalled:
'True'` in my prefix config.yml. gr-osmosdr is kind enough to just skip
this dependency in that case.

Cheers
Johannes

On 27.05.21 11:32, Jeff Long wrote:
> Or could just install the missing LaTeX module. On Fedora, it's
> texlive-newunicodechar. For reference, no problems building libosmo-dsp
> here.
>
> On Thu, May 27, 2021 at 4:21 AM Johannes Demel <demel@ant.uni-bremen.de
> <mailto:demel@ant.uni-bremen.de>> wrote:
>
> Thanks Jeff!
>
> Unfortunately, these settings are already present in that config.yml. I
> double checked the config.yml in my prefix as well. There are no
> overwrites.
>
> This is from `gr-recipes/libosmo-dsp.lwr`:
> ```
> configure: autoreconf -i -I /usr/share/aclocal && ./configure
> --prefix=$prefix $config_opt
> ```
> I'd really like to learn about `$config_opt`. What value(s) are in
> there?
> I removed libosmo-dsp (also from the inventory.yml).
>
> This is the output of `pybombs -v install libosmo-dsp`:
> ```
> [DEBUG] Requirements met.
> [DEBUG] Using build directory:
> /home/johannes/prefix/gnuradio/src/libosmo-dsp
> [DEBUG] Configuring recipe libosmo-dsp
> [DEBUG] Using vars - ordereddict([('config_opt', ''), ('builddir',
> '/home/johannes/prefix/gnuradio/src/libosmo-dsp')])
> [DEBUG] In cwd - /home/johannes/prefix/gnuradio/src/libosmo-dsp
> [DEBUG] Executing command `$ autoreconf -i -I /usr/share/aclocal &&
> ./configure --prefix=/home/johannes/prefix/gnuradio'
> Configuring: (100%)
> [DEBUG] Thread signaled termination or returned
> [DEBUG] Return value: 0
> [DEBUG] Configure successful.
> [DEBUG] Setting state to `configured'
> [DEBUG] Saving inventory to file
> /home/johannes/prefix/gnuradio/.pybombs/inventory.yml...
> [DEBUG] Building recipe libosmo-dsp
> [DEBUG] In cwd - /home/johannes/prefix/gnuradio/src/libosmo-dsp
> [DEBUG] Executing command `$ make -j64'
> Building:    [
> ```
> This is where it hangs.
>
> I just tried to run it on a host with a full LaTeX installation. There
> it goes through without any issue.
>
> My guess would be that I'd have to do a full LaTeX install. That's
> something I'd like to avoid.
>
> I'd like to skip the whole Doxygen part and hope the issue goes away. A
> more narrow solution would be nice as well though.
>
> Cheers
> Johannes
>
> On 26.05.21 19:17, Jeff Long wrote:
> > In ~/.pybombs/config.yml
> >
> > - config:
> >      makewidth: 4
> >      builddocs: OFF
> >      cmakebuildtype: Release
> >
> > On Wed, May 26, 2021 at 12:41 PM Johannes Demel
> <demel@ant.uni-bremen.de <mailto:demel@ant.uni-bremen.de>
> > <mailto:demel@ant.uni-bremen.de
> <mailto:demel@ant.uni-bremen.de>>> wrote:
> >
> >     Hi all,
> >
> >     I'm trying to install gr-osmosdr with GR 3.9. Currently
> pybombs hangs
> >     during libosmo-dsp build. Unfortunately it just hangs forever
> without
> >     any output, but if I try it manually, I see:
> >
> >     ```
> >     ! LaTeX Error: File `newunicodechar.sty' not found.
> >
> >     Type X to quit or <RETURN> to proceed,
> >     or enter new name. (Default extension: sty)
> >
> >     Enter file name:
> >     ```
> >     Thus, I'd like to disable generating docs. All of this
> happens while
> >     docs are generated. There's a minimal latex install but I
> don't want
> >     any
> >     more TeX on that machine.
> >
> >     I can't find the switch to disable docs. How do I do that? Or
> disable
> >     doxygen.
> >
> >     Cheers
> >     Johannes
> >
> >     --
> >     Johannes Demel M.Sc.
> >     Research Engineer
> >
> >     University of Bremen
> >     Department of Communications Engineering
> >     Faculty 1 - Physics / Electrical Engineering
> >     NW1, N2400
> >     Otto-Hahn-Allee NW1
> >     28359 Bremen
> >
> >     Phone +49 421 218-62393
> > demel@ant.uni-bremen.de <mailto:demel@ant.uni-bremen.de>
> <mailto:demel@ant.uni-bremen.de <mailto:demel@ant.uni-bremen.de>>
> >
> >     Secretariat
> >     Tel. +49 421 218-62390
> > preuss@ant.uni-bremen.de <mailto:preuss@ant.uni-bremen.de>
> <mailto:preuss@ant.uni-bremen.de <mailto:preuss@ant.uni-bremen.de>>
> >
> > www.uni-bremen.de/en <http://www.uni-bremen.de/en>
> <http://www.uni-bremen.de/en <http://www.uni-bremen.de/en>>
> >
> >     University of Bremen - Established 1971
> >
>

Re: libosmo-dsp build hangs (required for gr-osmosdr)

Or could just install the missing LaTeX module. On Fedora, it's texlive-newunicodechar. For reference, no problems building libosmo-dsp here.

On Thu, May 27, 2021 at 4:21 AM Johannes Demel <demel@ant.uni-bremen.de> wrote:
Thanks Jeff!

Unfortunately, these settings are already present in that config.yml. I
double checked the config.yml in my prefix as well. There are no overwrites.

This is from `gr-recipes/libosmo-dsp.lwr`:
```
configure: autoreconf -i -I /usr/share/aclocal && ./configure
--prefix=$prefix $config_opt
```
I'd really like to learn about `$config_opt`. What value(s) are in there?
I removed libosmo-dsp (also from the inventory.yml).

This is the output of `pybombs -v install libosmo-dsp`:
```
[DEBUG] Requirements met.
[DEBUG] Using build directory:
/home/johannes/prefix/gnuradio/src/libosmo-dsp
[DEBUG] Configuring recipe libosmo-dsp
[DEBUG] Using vars - ordereddict([('config_opt', ''), ('builddir',
'/home/johannes/prefix/gnuradio/src/libosmo-dsp')])
[DEBUG] In cwd - /home/johannes/prefix/gnuradio/src/libosmo-dsp
[DEBUG] Executing command `$ autoreconf -i -I /usr/share/aclocal &&
./configure --prefix=/home/johannes/prefix/gnuradio'
Configuring: (100%)
[DEBUG] Thread signaled termination or returned
[DEBUG] Return value: 0
[DEBUG] Configure successful.
[DEBUG] Setting state to `configured'
[DEBUG] Saving inventory to file
/home/johannes/prefix/gnuradio/.pybombs/inventory.yml...
[DEBUG] Building recipe libosmo-dsp
[DEBUG] In cwd - /home/johannes/prefix/gnuradio/src/libosmo-dsp
[DEBUG] Executing command `$ make -j64'
Building:    [
```
This is where it hangs.

I just tried to run it on a host with a full LaTeX installation. There
it goes through without any issue.

My guess would be that I'd have to do a full LaTeX install. That's
something I'd like to avoid.

I'd like to skip the whole Doxygen part and hope the issue goes away. A
more narrow solution would be nice as well though.

Cheers
Johannes

On 26.05.21 19:17, Jeff Long wrote:
> In ~/.pybombs/config.yml
>
> - config:
>      makewidth: 4
>      builddocs: OFF
>      cmakebuildtype: Release
>
> On Wed, May 26, 2021 at 12:41 PM Johannes Demel <demel@ant.uni-bremen.de
> <mailto:demel@ant.uni-bremen.de>> wrote:
>
>     Hi all,
>
>     I'm trying to install gr-osmosdr with GR 3.9. Currently pybombs hangs
>     during libosmo-dsp build. Unfortunately it just hangs forever without
>     any output, but if I try it manually, I see:
>
>     ```
>     ! LaTeX Error: File `newunicodechar.sty' not found.
>
>     Type X to quit or <RETURN> to proceed,
>     or enter new name. (Default extension: sty)
>
>     Enter file name:
>     ```
>     Thus, I'd like to disable generating docs. All of this happens while
>     docs are generated. There's a minimal latex install but I don't want
>     any
>     more TeX on that machine.
>
>     I can't find the switch to disable docs. How do I do that? Or disable
>     doxygen.
>
>     Cheers
>     Johannes
>
>     --
>     Johannes Demel M.Sc.
>     Research Engineer
>
>     University of Bremen
>     Department of Communications Engineering
>     Faculty 1 - Physics / Electrical Engineering
>     NW1, N2400
>     Otto-Hahn-Allee NW1
>     28359 Bremen
>
>     Phone +49 421 218-62393
>     demel@ant.uni-bremen.de <mailto:demel@ant.uni-bremen.de>
>
>     Secretariat
>     Tel. +49 421 218-62390
>     preuss@ant.uni-bremen.de <mailto:preuss@ant.uni-bremen.de>
>
>     www.uni-bremen.de/en <http://www.uni-bremen.de/en>
>
>     University of Bremen - Established 1971
>

Re: libosmo-dsp build hangs (required for gr-osmosdr)

Thanks Jeff!

Unfortunately, these settings are already present in that config.yml. I
double checked the config.yml in my prefix as well. There are no overwrites.

This is from `gr-recipes/libosmo-dsp.lwr`:
```
configure: autoreconf -i -I /usr/share/aclocal && ./configure
--prefix=$prefix $config_opt
```
I'd really like to learn about `$config_opt`. What value(s) are in there?
I removed libosmo-dsp (also from the inventory.yml).

This is the output of `pybombs -v install libosmo-dsp`:
```
[DEBUG] Requirements met.
[DEBUG] Using build directory:
/home/johannes/prefix/gnuradio/src/libosmo-dsp
[DEBUG] Configuring recipe libosmo-dsp
[DEBUG] Using vars - ordereddict([('config_opt', ''), ('builddir',
'/home/johannes/prefix/gnuradio/src/libosmo-dsp')])
[DEBUG] In cwd - /home/johannes/prefix/gnuradio/src/libosmo-dsp
[DEBUG] Executing command `$ autoreconf -i -I /usr/share/aclocal &&
./configure --prefix=/home/johannes/prefix/gnuradio'
Configuring: (100%)
[DEBUG] Thread signaled termination or returned
[DEBUG] Return value: 0
[DEBUG] Configure successful.
[DEBUG] Setting state to `configured'
[DEBUG] Saving inventory to file
/home/johannes/prefix/gnuradio/.pybombs/inventory.yml...
[DEBUG] Building recipe libosmo-dsp
[DEBUG] In cwd - /home/johannes/prefix/gnuradio/src/libosmo-dsp
[DEBUG] Executing command `$ make -j64'
Building: [
```
This is where it hangs.

I just tried to run it on a host with a full LaTeX installation. There
it goes through without any issue.

My guess would be that I'd have to do a full LaTeX install. That's
something I'd like to avoid.

I'd like to skip the whole Doxygen part and hope the issue goes away. A
more narrow solution would be nice as well though.

Cheers
Johannes

On 26.05.21 19:17, Jeff Long wrote:
> In ~/.pybombs/config.yml
>
> - config:
>     makewidth: 4
>     builddocs: OFF
>     cmakebuildtype: Release
>
> On Wed, May 26, 2021 at 12:41 PM Johannes Demel <demel@ant.uni-bremen.de
> <mailto:demel@ant.uni-bremen.de>> wrote:
>
> Hi all,
>
> I'm trying to install gr-osmosdr with GR 3.9. Currently pybombs hangs
> during libosmo-dsp build. Unfortunately it just hangs forever without
> any output, but if I try it manually, I see:
>
> ```
> ! LaTeX Error: File `newunicodechar.sty' not found.
>
> Type X to quit or <RETURN> to proceed,
> or enter new name. (Default extension: sty)
>
> Enter file name:
> ```
> Thus, I'd like to disable generating docs. All of this happens while
> docs are generated. There's a minimal latex install but I don't want
> any
> more TeX on that machine.
>
> I can't find the switch to disable docs. How do I do that? Or disable
> doxygen.
>
> Cheers
> Johannes
>
> --
> Johannes Demel M.Sc.
> Research Engineer
>
> University of Bremen
> Department of Communications Engineering
> Faculty 1 - Physics / Electrical Engineering
> NW1, N2400
> Otto-Hahn-Allee NW1
> 28359 Bremen
>
> Phone +49 421 218-62393
> demel@ant.uni-bremen.de <mailto:demel@ant.uni-bremen.de>
>
> Secretariat
> Tel. +49 421 218-62390
> preuss@ant.uni-bremen.de <mailto:preuss@ant.uni-bremen.de>
>
> www.uni-bremen.de/en <http://www.uni-bremen.de/en>
>
> University of Bremen - Established 1971
>

Re: query about GRC

Dear Professor,
It'll be great if you give us some more information like the version of GRC that you are using and just as heads us Prof, click on the block go to advanced tab and enter your comment there, it'll show up like the image I have attached.



Sender notified by
Mailtrack 05/27/21, 01:13:56 PM

On Thu, May 27, 2021 at 12:57 PM Prof. M.B. Patil <mbpatil@ee.iitb.ac.in> wrote:

Dear All,

I was not able to figure out how
this works in GRC:

view -> Show block comments

I toggled it, but it did not seem to
make any difference. Any pointers would
be greatly appreciated.

M.Patil






--
S. Aditya Arun Kumar
+919123517465

query about GRC

Dear All,

I was not able to figure out how
this works in GRC:

view -> Show block comments

I toggled it, but it did not seem to
make any difference. Any pointers would
be greatly appreciated.

M.Patil

Wednesday, May 26, 2021

Re: OOT Module with shape error

The "additional checks" would be to find the min of input and output lengths, and to copy only that number of items. Something like:

nitems = min(len(input_items[0]), len(output_items[0]))
out[:nitems] = in[:nitems]

As your block gets more complex, the checks/limits may get more complex.

On Wed, May 26, 2021 at 7:56 PM Elmore Family <wa4ywm@comcast.net> wrote:
Jeff,
 
This didn't work – same error.
 
Jim
 
From: Jeff Long
Sent: Tuesday, May 25, 2021 5:22 PM
Subject: Re: OOT Module with shape error
 
The framework can give you different size input and output buffers. In this case, you would:
 
nitems = len(input_items[0])
out[:nitems] = input_items[0]
 
You may have to do more checks, of course, because input could be larger than output.
 
On Tue, May 25, 2021 at 5:03 PM Elmore's <wa4ywm@comcast.net> wrote:
I am attempting to add an OOT module to my flowgraph. I have generated a General block which I want to place between an Audio Source and a Multiply Constant.
 
The Audio Source is set at a 48K sample rate. Input and Output are float.
 
As a test (I have never tried using an OOT module before) I said:
    out[:] = input_items[0]
in an attempt to simply feed the input to the output unmodified.
 
I get a run time error:
    ValueError: Could not broadcast input array from shape(4800) into shape(256)
 
Obviously I don't know how to perform the simplest possible operation. What is wrong here?
 
I have tried looking on forums and reading some of the GNU docs but no joy.
 
Thanks for any help.
 
Jim
 
 

Virus-free. www.avg.com

Re: OOT Module with shape error

Jeff,
 
This didn't work – same error.
 
Jim
 
From: Jeff Long
Sent: Tuesday, May 25, 2021 5:22 PM
Subject: Re: OOT Module with shape error
 
The framework can give you different size input and output buffers. In this case, you would:
 
nitems = len(input_items[0])
out[:nitems] = input_items[0]
 
You may have to do more checks, of course, because input could be larger than output.
 
On Tue, May 25, 2021 at 5:03 PM Elmore's <wa4ywm@comcast.net> wrote:
I am attempting to add an OOT module to my flowgraph. I have generated a General block which I want to place between an Audio Source and a Multiply Constant.
 
The Audio Source is set at a 48K sample rate. Input and Output are float.
 
As a test (I have never tried using an OOT module before) I said:
    out[:] = input_items[0]
in an attempt to simply feed the input to the output unmodified.
 
I get a run time error:
    ValueError: Could not broadcast input array from shape(4800) into shape(256)
 
Obviously I don't know how to perform the simplest possible operation. What is wrong here?
 
I have tried looking on forums and reading some of the GNU docs but no joy.
 
Thanks for any help.
 
Jim
 
 

Virus-free. www.avg.com

Re: libosmo-dsp build hangs (required for gr-osmosdr)

In ~/.pybombs/config.yml

- config:
    makewidth: 4
    builddocs: OFF
    cmakebuildtype: Release

On Wed, May 26, 2021 at 12:41 PM Johannes Demel <demel@ant.uni-bremen.de> wrote:
Hi all,

I'm trying to install gr-osmosdr with GR 3.9. Currently pybombs hangs
during libosmo-dsp build. Unfortunately it just hangs forever without
any output, but if I try it manually, I see:

```
! LaTeX Error: File `newunicodechar.sty' not found.

Type X to quit or <RETURN> to proceed,
or enter new name. (Default extension: sty)

Enter file name:
```
Thus, I'd like to disable generating docs. All of this happens while
docs are generated. There's a minimal latex install but I don't want any
more TeX on that machine.

I can't find the switch to disable docs. How do I do that? Or disable
doxygen.

Cheers
Johannes

--
Johannes Demel M.Sc.
Research Engineer

University of Bremen
Department of Communications Engineering
Faculty 1 - Physics / Electrical Engineering
NW1, N2400
Otto-Hahn-Allee NW1
28359 Bremen

Phone +49 421 218-62393
demel@ant.uni-bremen.de

Secretariat
Tel. +49 421 218-62390
preuss@ant.uni-bremen.de

www.uni-bremen.de/en

University of Bremen - Established 1971

Re: Gnuradio: SineWave generator python block choppy audio out

although later testing shows that yours doesn't flicker like Markuc does when changing frequency or sample rate on the fly

V V sre., 26. maj 2021 ob 19:08 je oseba Mitja kocjančič <veso266@gmail.com> napisala:
both yours and Maruc solutions work very well, didn't spot any visual difference between them, so thank you both

V V sre., 26. maj 2021 ob 18:50 je oseba Achilleas Anastasopoulos <anastas@umich.edu> napisala:
Hi all,

I do not think that the proposed algorithm by Marcus is the correct way to implement this block, 
because it assumes that the frequency has remained the same throughout the life of the block!
The correct way is to keep a state variable (say, "self.phase") that is initialized to 0 and  records the accumulated state (modulo 2 pi) up to the last call of work.
Then in one call of work you should just generate the sin wave as suggested:

f_rel = 2 * np.pi * self.frequency / self.sample_rate
number = len(output_items[0])
phases = (f_rel * np.arange(0,number)+self.phase ) % (2*np.pi)
output_items[0][:] = self.amplitude*np.sin(phases)
self.phase=phases[-1]+ f_rel

best
Achilleas

Re: Gnuradio: SineWave generator python block choppy audio out

both yours and Maruc solutions work very well, didn't spot any visual difference between them, so thank you both

V V sre., 26. maj 2021 ob 18:50 je oseba Achilleas Anastasopoulos <anastas@umich.edu> napisala:
Hi all,

I do not think that the proposed algorithm by Marcus is the correct way to implement this block, 
because it assumes that the frequency has remained the same throughout the life of the block!
The correct way is to keep a state variable (say, "self.phase") that is initialized to 0 and  records the accumulated state (modulo 2 pi) up to the last call of work.
Then in one call of work you should just generate the sin wave as suggested:

f_rel = 2 * np.pi * self.frequency / self.sample_rate
number = len(output_items[0])
phases = (f_rel * np.arange(0,number)+self.phase ) % (2*np.pi)
output_items[0][:] = self.amplitude*np.sin(phases)
self.phase=phases[-1]+ f_rel

best
Achilleas

Re: Gnuradio: SineWave generator python block choppy audio out

Hi all,

I do not think that the proposed algorithm by Marcus is the correct way to implement this block, 
because it assumes that the frequency has remained the same throughout the life of the block!
The correct way is to keep a state variable (say, "self.phase") that is initialized to 0 and  records the accumulated state (modulo 2 pi) up to the last call of work.
Then in one call of work you should just generate the sin wave as suggested:

f_rel = 2 * np.pi * self.frequency / self.sample_rate
number = len(output_items[0])
phases = (f_rel * np.arange(0,number)+self.phase ) % (2*np.pi)
output_items[0][:] = self.amplitude*np.sin(phases)
self.phase=phases[-1]+ f_rel

best
Achilleas

libosmo-dsp build hangs (required for gr-osmosdr)

Hi all,

I'm trying to install gr-osmosdr with GR 3.9. Currently pybombs hangs
during libosmo-dsp build. Unfortunately it just hangs forever without
any output, but if I try it manually, I see:

```
! LaTeX Error: File `newunicodechar.sty' not found.

Type X to quit or <RETURN> to proceed,
or enter new name. (Default extension: sty)

Enter file name:
```
Thus, I'd like to disable generating docs. All of this happens while
docs are generated. There's a minimal latex install but I don't want any
more TeX on that machine.

I can't find the switch to disable docs. How do I do that? Or disable
doxygen.

Cheers
Johannes

--
Johannes Demel M.Sc.
Research Engineer

University of Bremen
Department of Communications Engineering
Faculty 1 - Physics / Electrical Engineering
NW1, N2400
Otto-Hahn-Allee NW1
28359 Bremen

Phone +49 421 218-62393
demel@ant.uni-bremen.de

Secretariat
Tel. +49 421 218-62390
preuss@ant.uni-bremen.de

www.uni-bremen.de/en

University of Bremen - Established 1971

Re: rational resampler fractional bandwidth error

That did the trick, thanks Jeff.

Re: rational resampler fractional bandwidth error

Try leaving the field blank to get the previous behavior.

On Wed, May 26, 2021 at 10:02 AM Jason Matusiak <jason@gardettoengineering.com> wrote:
It has been a while since I have worked with GNUradio, but I am poking around with it again and having some issues.  I am currently using v3.8 on an Ubuntu machine.

I was trying to get a custom flowgraph to work and ran up against an error for the rational resampler.  I then pulled out the  fm_rds_alternate.grc example from gr-rds and found the exact same issue.  Basically, if I use the stock flowgraph, when I try to run it, I get the following error:

Traceback (most recent call last):
  File "/opt/gnuradio/v3.8/src/gr-rds/examples/fm_rds_alternate.py", line 784, in <module>
    main()
  File "/opt/gnuradio/v3.8/src/gr-rds/examples/fm_rds_alternate.py", line 760, in main
    tb = top_block_cls()
  File "/opt/gnuradio/v3.8/src/gr-rds/examples/fm_rds_alternate.py", line 548, in __init__
    fractional_bw=0)
  File "/opt/gnuradio/v3.8/lib/python3/dist-packages/gnuradio/filter/rational_resampler.py", line 150, in __init__
    interpolation, decimation, taps, fractional_bw)
  File "/opt/gnuradio/v3.8/lib/python3/dist-packages/gnuradio/filter/rational_resampler.py", line 113, in __init__
    taps = design_filter(interpolation, decimation, fractional_bw)
  File "/opt/gnuradio/v3.8/lib/python3/dist-packages/gnuradio/filter/rational_resampler.py", line 46, in design_filter
    raise ValueError("Invalid fractional_bandwidth, must be in (0, 0.5)")
ValueError: Invalid fractional_bandwidth, must be in (0, 0.5)

>>> Done (return code 1)

Did something maybe change with the rational resampler and I need to update older flowgraphs?  Using a value of 0.4 allows it to run, but I am not sure if that is an acceptable value when it was previously set to zero (it would appear).

rational resampler fractional bandwidth error

It has been a while since I have worked with GNUradio, but I am poking around with it again and having some issues.  I am currently using v3.8 on an Ubuntu machine.

I was trying to get a custom flowgraph to work and ran up against an error for the rational resampler.  I then pulled out the  fm_rds_alternate.grc example from gr-rds and found the exact same issue.  Basically, if I use the stock flowgraph, when I try to run it, I get the following error:

Traceback (most recent call last):
  File "/opt/gnuradio/v3.8/src/gr-rds/examples/fm_rds_alternate.py", line 784, in <module>
    main()
  File "/opt/gnuradio/v3.8/src/gr-rds/examples/fm_rds_alternate.py", line 760, in main
    tb = top_block_cls()
  File "/opt/gnuradio/v3.8/src/gr-rds/examples/fm_rds_alternate.py", line 548, in __init__
    fractional_bw=0)
  File "/opt/gnuradio/v3.8/lib/python3/dist-packages/gnuradio/filter/rational_resampler.py", line 150, in __init__
    interpolation, decimation, taps, fractional_bw)
  File "/opt/gnuradio/v3.8/lib/python3/dist-packages/gnuradio/filter/rational_resampler.py", line 113, in __init__
    taps = design_filter(interpolation, decimation, fractional_bw)
  File "/opt/gnuradio/v3.8/lib/python3/dist-packages/gnuradio/filter/rational_resampler.py", line 46, in design_filter
    raise ValueError("Invalid fractional_bandwidth, must be in (0, 0.5)")
ValueError: Invalid fractional_bandwidth, must be in (0, 0.5)

>>> Done (return code 1)

Did something maybe change with the rational resampler and I need to update older flowgraphs?  Using a value of 0.4 allows it to run, but I am not sure if that is an acceptable value when it was previously set to zero (it would appear).

Re: Gnuradio: SineWave generator python block choppy audio out

err Oh! I shouldn't have answered in a hurry, sorry!
The method self.nitems_written(0) gives you the items your block has already produced, so
that at each call to work() the sine continues exactly where it left off.
My apologies for the confusion this caused,
Marcus

On 26.05.21 13:06, Mitja kocjančič wrote:
> OK, I tried it even on GNURadio 3.9 and self.noutputs_written(0) is still not defined
> https://imgur.com/ylW1uGy <https://imgur.com/ylW1uGy>
>
> so is there any other way to set startnrto the right value so my audio won't be choppy
>
> BTW: side question, is it possible to somehow tell gnuradio to always use notepad++ as its
> editor (config option or something)?
>
>
> V V sre., 26. maj 2021 ob 11:59 je oseba Marcus Müller <mmueller@gnuradio.org
> <mailto:mmueller@gnuradio.org>> napisala:
>
> Sorry, the function is called self.noutputs_written() of course.
>
> https://github.com/rftap/gr-rftap <https://github.com/rftap/gr-rftap> shouldn't be
> necessary, usually; I think gr-ieee802-11
> even contains exactly this functionality!
>
> gr-rds has definitely been ported to 3.8 (it's even the default branch), and 3.9 (the
> maint-3.9 branch).
>
> Best regards,
> Marcus
>
> On 26.05.21 10:37, Mitja kocjančič wrote:
> > Thanks you very much
> > the reason I use gnuradio 3.7 is because some OOT modules
> >
> > gr-rftap https://github.com/rftap/gr-rftap <https://github.com/rftap/gr-rftap>
> <https://github.com/rftap/gr-rftap <https://github.com/rftap/gr-rftap>>
> > gr-rds (don't know about this one but probably would work on 3.9):
> > https://github.com/bastibl/gr-rds <https://github.com/bastibl/gr-rds>
> <https://github.com/bastibl/gr-rds <https://github.com/bastibl/gr-rds>>
> >
> > do not work on gnuradio 3.9 (rftap doesn't even work on 3.8) and I am waiting for
> them to
> > port over
> >
> > am not sure where you got
> > ninputs_written(0) from as its not defined and even looked in gnuradio 3.9 source
> code and
> > couldn't find it mentioned anywhere
> >
> >
> >
> > V V sre., 26. maj 2021 ob 00:18 je oseba Marcus Müller <mmueller@gnuradio.org
> <mailto:mmueller@gnuradio.org>
> > <mailto:mmueller@gnuradio.org <mailto:mmueller@gnuradio.org>>> napisala:
> >
> >     Hi Mitja!
> >
> >     Great to have you here :)
> >
> >
> >     Couple of things up front:
> >
> >     1. This is GNU Radio 3.7. Especially if you want to implement things in Python
> blocks, 3.8
> >     or later is a *must*. GNU Radio 3.7 is really just in legacy keepalive mode, not
> actively
> >     developed. Please update to GNU Radio 3.8 or 3.9. You really should not start
> developing
> >     for GNU Radio 3.7 in 2021!
> >     2. WX GUI is dead. We stopped being able to support it a long time ago. Please
> use Qt GUI
> >     instead.
> >
> >     All in all, please update your version of GNU Radio. In case any bugs occur, we
> won't be
> >     able to help you with GNU Radio 3.7. GNU Radio 3.8 can be natively installed on
> almost all
> >     modern Linux distros directly from their package managers, and on Windows, and
> OS X using
> >     conda and other tools, without any complications.
> >
> >     With that out of the way, let's look at your code:
> >
> >             for i in range(0, len(output_items[0])): #8192
> >                 output_items[0][i] = np.sin(2 * np.pi * self.frequency * (i /
> >     self.sample_rate)) * self.amplitude
> >
> >     No surprise the sound is choppy! You reset your i to 0 for every new call to work();
> >     however, GNU Radio doesn't guarantee that work is called with number of items
> equal to a
> >     multiple of your sine period.
> >     So, this is a bug in your design. What you'd want is really something like
> >
> >     def work(self, input_items, output_items):
> >        # get rid of the for loop!
> >        startnr = self.ninputs_written(0)
> >        f_rel = 2 * np.pi * self.frequency / self.sample_rate
> >        number = len(output_items[0])
> >        output_items[0][:] = self.amplitude*np.sin(f_rel * np.arange(startnr,
> startnr+number))
> >        return number
> >
> >     Best regards
> >     Marcus
> >
>