GNU Radio, One Step at a Time: July 2022

Sunday, July 31, 2022

Re: "L" error code when using Ettus N310

On 2022-07-31 14:22, Christopher Flood wrote:
> Hi all,
>
> I am using an Ettus N310 to transmit and receive signals. My goal is
> to receive four signals and transmit two - however, in this
> configuration my GNU Radio script throws "LLLLL" errors in the
> console. I have had success using the N310 in other configurations
> with no issue, such as receiving four signals or receiving two signals
> and transmitting two signals.
>
> The only documentation I have seen on the "L" code is here, but it
> doesn't really clear anything up.
> https://github.com/gnuradio/gnuradio/issues/3830
> Tx: "Late data (arrived after indicated time)". Rx (RFNoC only?):
> "Late command (stream command arrived after indicated time)".
>
> According to the documentation, I believe receiving four signals and
> transmitting two signals should be possible. Can anyone provide input
> as to what might be going on?
>
> Thanks,
>
> Chris
Does this appear at all sample rates or just low/high sample rates?

Can you share the flow-graph that you're using?

"L" error code when using Ettus N310

Hi all,

I am using an Ettus N310 to transmit and receive signals. My goal is to receive four signals and transmit two - however, in this configuration my GNU Radio script throws "LLLLL" errors in the console. I have had success using the N310 in other configurations with no issue, such as receiving four signals or receiving two signals and transmitting two signals.

The only documentation I have seen on the "L" code is here, but it doesn't really clear anything up.

https://github.com/gnuradio/gnuradio/issues/3830

Tx: "Late data (arrived after indicated time)". Rx (RFNoC only?): "Late command (stream command arrived after indicated time)".

According to the documentation, I believe receiving four signals and transmitting two signals should be possible. Can anyone provide input as to what might be going on?

Thanks,

Chris

Saturday, July 30, 2022

Re: UHD device not found

On 2022-07-30 03:22, Sumit Agrawal (P19EE207) wrote:

Hi,
I am having a USRP N320 and installed gnuradio+uhd (4.0 version) on ubuntu 20.04 LTS. Earlier, device is working fine with following command-

Ping 192.168.10.2

uhd_find_devices

uhd_usrp_probe

But, now I am using it after some time, and the device is pinging properly. However, when I am running the command uhd_find_device, it shows no device found. So help me regarding this issue.

Try:

uhd_usrp_probe --args "addr=192.168.10.2,type=n3xx,product=n320"

UHD device not found

Hi,

I am having a USRP N320 and installed gnuradio+uhd (4.0 version) on ubuntu 20.04 LTS. Earlier, device is working fine with following command-

Ping 192.168.10.2

uhd_find_devices

uhd_usrp_probe

But, now I am using it after some time, and the device is pinging properly. However, when I am running the command uhd_find_device, it shows no device found. So help me regarding this issue.

Thanks & Regards,
Sumit Kumar Agrawal
Ph.D. (Electrical Engineering)
Indian Institute of Technology
Jodhpur, Rajasthan-342037

Mob. No.- 8410957412

Friday, July 29, 2022

UHD 4.2.0.1 released!

UHD 4.2.0.1 is now available [1]! This a minor release that includes:

Support for ZBX rev D daughterboard. Hardware change only. No product feature or spec changes.
Bug fixes and improvements for USRP devices. See the changelog. [1]

We'd like to thank all the USRP users that have filed issues or directly contributed to

UHD and meta-ettus. You contributions have helped the continued improvement of UHD.

As always, please file issues to our GitHub repo [2], by posting in the USRP-users mailing list, or

contacting support@ettus.com.

Thanks!

Steven

[1] https://github.com/EttusResearch/uhd/releases/tag/v4.2.0.1

[2] https://github.com/EttusResearch/uhd/issues/

INTERNAL - NI CONFIDENTIAL

Re: Problem extracting individual elements from pmt list and pmt dictionary messages

k = pmt.intern('spam')

nil = pmt.get_PMT_NIL()

v = pmt.dict_ref(d, k, nil)

The last argument to dict_ref is what gets returned if the key is not found.

On Fri, Jul 29, 2022 at 11:13 AM George Edwards <gedwards.eng@gmail.com> wrote:

Hello GNURadio Community,

I am creating a Python OOT block to send/receive pmt list and pmt dictionary messages. In both cases, I am having problems extracting the elements in the message. Let's assume (some trivial values):
P_list = pmt.to_pmt([1, 2, 3.45, 'eggs'])
P_dict = pmt.to_pmt({'spam': 20, 'eggs': 40})

How do I extract individual elements from P_list and P_dict? Nothing I tried worked.

I appreciate any help.

Regards,
George

Re: Problem extracting individual elements from pmt list and pmt dictionary messages

Hi Jeff,

Thank you very much!

Please make references directly to my pmt objects P_list and P_dict, so I can learn how to get elements from them?

Thank you!

Regards,

George

On Fri, Jul 29, 2022 at 2:58 PM Jeff Long <willcode4@gmail.com> wrote:

k = pmt.intern('spam')
nil = pmt.get_PMT_NIL()
v = pmt.dict_ref(d, k, nil)

The last argument to dict_ref is what gets returned if the key is not found.

On Fri, Jul 29, 2022 at 11:13 AM George Edwards <gedwards.eng@gmail.com> wrote:
Hello GNURadio Community,

I am creating a Python OOT block to send/receive pmt list and pmt dictionary messages. In both cases, I am having problems extracting the elements in the message. Let's assume (some trivial values):
P_list = pmt.to_pmt([1, 2, 3.45, 'eggs'])
P_dict = pmt.to_pmt({'spam': 20, 'eggs': 40})

How do I extract individual elements from P_list and P_dict? Nothing I tried worked.

I appreciate any help.

Regards,
George

Re: Problem seeing HackRF hardware on Mac via a Docker Container

Hi,

Maybe a workaround is running something like SoapyRemote in Mac OS and
then accessing the device from Docker through the network.

Best,
Daniel.

On 28/07/2022 19:30, Marcus Müller wrote:
> Hi George,
>
> Docker on Mac OS cannot pass through USB devices:
>
> https://docs.docker.com/desktop/faqs/general/#can-i-pass-through-a-usb-device-to-a-container
>
>
> So, this is sadly impossible.
>
> Best regards,
> Marcus
>
> On 7/28/22 17:03, George Edwards wrote:
>> Hello GNURadio Community!
>>
>> I am working with Gnuradio 3.9 on a Mac. Gnuradio runs inside a Docker
>> Container. I build a Gnuradio flow graph with a soapy HackRF source
>> block to interface with the HackRF hardware. When I run the flow
>> graph, it says there is no matching HackRF.
>>
>> Will appreciate any suggestions, thank you.
>> George
>

Problem extracting individual elements from pmt list and pmt dictionary messages

Hello GNURadio Community,

I am creating a Python OOT block to send/receive pmt list and pmt dictionary messages. In both cases, I am having problems extracting the elements in the message. Let's assume (some trivial values):

P_list = pmt.to_pmt([1, 2, 3.45, 'eggs'])

P_dict = pmt.to_pmt({'spam': 20, 'eggs': 40})

How do I extract individual elements from P_list and P_dict? Nothing I tried worked.

I appreciate any help.

Regards,

George

Re: Problem seeing HackRF hardware on Mac via a Docker Container

Hi Derek and Daniel,

Thank you very much! Will use your suggestions.

George

On Fri, Jul 29, 2022 at 7:51 AM Derek Kozel <derek@bitstovolts.com> wrote:

Docker on a Mac can be setup with the networking passthrough to let the X310 and N310 work. The limitation is specifically on USB device passthrough.

Not relevant to your issue specifically, but the Analog Devices ADALM-PLUTO educational SDR uses USB but identifies as a network card so interestingly it is possible to work around the limitation. The same limitation on USB devices existed until recently with the Windows Subsystem for Linux but that is improving over time.

Regards,
Derek

On 7/28/2022 8:06 PM, George Edwards wrote:

Hi Marcus, do you know if a Docker Container on Mac talk to either the X310 or N310 radio? George

On Thu, Jul 28, 2022, 11:32 AM Marcus Müller <mmueller@gnuradio.org> wrote:

Hi George,

Docker on Mac OS cannot pass through USB devices:

https://docs.docker.com/desktop/faqs/general/#can-i-pass-through-a-usb-device-to-a-container

So, this is sadly impossible.

Best regards,
Marcus

On 7/28/22 17:03, George Edwards wrote:
> Hello GNURadio Community!
>
> I am working with Gnuradio 3.9 on a Mac. Gnuradio runs inside a Docker
> Container. I build a Gnuradio flow graph with a soapy HackRF source
> block to interface with the HackRF hardware. When I run the flow
> graph, it says there is no matching HackRF.
>
> Will appreciate any suggestions, thank you.
> George

Re: Problem seeing HackRF hardware on Mac via a Docker Container

Docker on a Mac can be setup with the networking passthrough to let the X310 and N310 work. The limitation is specifically on USB device passthrough.

Not relevant to your issue specifically, but the Analog Devices ADALM-PLUTO educational SDR uses USB but identifies as a network card so interestingly it is possible to work around the limitation. The same limitation on USB devices existed until recently with the Windows Subsystem for Linux but that is improving over time.

Regards,
Derek

On 7/28/2022 8:06 PM, George Edwards wrote:

Hi Marcus, do you know if a Docker Container on Mac talk to either the X310 or N310 radio? George

On Thu, Jul 28, 2022, 11:32 AM Marcus Müller <mmueller@gnuradio.org> wrote:

Hi George,

Docker on Mac OS cannot pass through USB devices:

https://docs.docker.com/desktop/faqs/general/#can-i-pass-through-a-usb-device-to-a-container

So, this is sadly impossible.

Best regards,
Marcus

On 7/28/22 17:03, George Edwards wrote:
> Hello GNURadio Community!
>
> I am working with Gnuradio 3.9 on a Mac. Gnuradio runs inside a Docker
> Container. I build a Gnuradio flow graph with a soapy HackRF source
> block to interface with the HackRF hardware. When I run the flow
> graph, it says there is no matching HackRF.
>
> Will appreciate any suggestions, thank you.
> George

Mysterious on Block QT GNU Level Gauge

Hello,

I have installed GnuRadio 3.10.1.1 and Python 3.10.4 on Ubuntu 22_04

There is a mysterious with the block QT GUI Level Gauge:

If I set “Show Values” of True, the graph steps in 1 inclement.

If I set “Show Values” of False” the graph steps in 10 increments!

Has everybody an idea?

Thanks

Karl-Heinz Kemna

how to auto frequency sweep in GRC?

I want to transmit a signal in a certain bandwidth such that it automatically sweeps through the spectrum....any suggestions.?

Like, sweeping a signal through 400MHz - 500MHz range.

Hardware used; HackRF ONE (https://greatscottgadgets.com/hackrf/)

Antenna :ANT 500

Thursday, July 28, 2022

Re: Receiving on two channels with E310/E312

On 2022-07-28 11:22, Lipski, Michael Victor wrote:

I tried running rx_multi_samples, but I wasn't sure exactly what arguments to use:

my@comp:/usr/local/lib/uhd/examples$ ./rx_multi_samples --args="addr=192.168.10.43" --rate=1000000 --channels="0,1"

Creating the usrp device with: addr=192.168.10.43...

[INFO] [UHD] linux; GNU C++ version 9.4.0; Boost_107100; UHD_4.1.0.HEAD-0-g6bd0be9c

[INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=192.168.10.43,type=e3xx,product=e310_sg3,serial=31F3C12,fpga=n/a,claimed=False,addr=192.168.10.43

[INFO] [MPM.PeriphManager] Found 1 daughterboard(s).

[INFO] [MPM.PeriphManager] init() called with device args `fpga=n/a,mgmt_addr=192.168.10.43,product=e310_sg3'.

[WARNING] [UDP] The recv buffer could not be resized sufficiently.

Target sock buff size: 2500000 bytes.

Actual sock buff size: 212992 bytes.

See the transport application notes on buffer resizing.

Please run: sudo sysctl -w net.core.rmem_max=2500000

[WARNING] [UDP] The send buffer could not be resized sufficiently.

Target sock buff size: 2500000 bytes.

Actual sock buff size: 212992 bytes.

See the transport application notes on buffer resizing.

Please run: sudo sysctl -w net.core.wmem_max=2500000

[WARNING] [UDP] The current recv_buff_size of 212992 is less than the minimum recommended size of 816000 and may result in dropped packets on some NICs

[WARNING] [UDP] The current send_buff_size of 212992 is less than the minimum recommended size of 307200 and may result in dropped packets on some NICs

[INFO] [0/Radio#0] Performing CODEC loopback test on channel 0 ...

[INFO] [0/Radio#0] CODEC loopback test passed

[INFO] [0/Radio#0] Performing CODEC loopback test on channel 1 ...

[INFO] [0/Radio#0] CODEC loopback test passed

Using Device: Single USRP:

Device: E300-Series Device

Mboard 0: e310_sg3

RX Channel: 0

RX DSP: n/a

RX Dboard: A

RX Subdev: E3xx

RX Channel: 1

RX DSP: n/a

RX Dboard: A

RX Subdev: E3xx

TX Channel: 0

TX DSP: n/a

TX Dboard: A

TX Subdev: E3xx

TX Channel: 1

TX DSP: n/a

TX Dboard: A

TX Subdev: E3xx

Setting RX Rate: 1.000000 Msps...

Actual RX Rate: 1.000000 Msps...

Setting device timestamp to 0...

[WARNING] [UDP] The recv buffer could not be resized sufficiently.

Target sock buff size: 2500000 bytes.

Actual sock buff size: 212992 bytes.

See the transport application notes on buffer resizing.

Please run: sudo sysctl -w net.core.rmem_max=2500000

[WARNING] [UDP] The send buffer could not be resized sufficiently.

Target sock buff size: 2500000 bytes.

Actual sock buff size: 212992 bytes.

See the transport application notes on buffer resizing.

Please run: sudo sysctl -w net.core.wmem_max=2500000

[WARNING] [UDP] The current recv_buff_size of 212992 is less than the minimum recommended size of 307200 and may result in dropped packets on some NICs

[WARNING] [UDP] The current send_buff_size of 212992 is less than the minimum recommended size of 307200 and may result in dropped packets on some NICs

[WARNING] [UDP] The recv buffer could not be resized sufficiently.

Target sock buff size: 2500000 bytes.

Actual sock buff size: 212992 bytes.

See the transport application notes on buffer resizing.

Please run: sudo sysctl -w net.core.rmem_max=2500000

[WARNING] [UDP] The send buffer could not be resized sufficiently.

Target sock buff size: 2500000 bytes.

Actual sock buff size: 212992 bytes.

See the transport application notes on buffer resizing.

Please run: sudo sysctl -w net.core.wmem_max=2500000

[WARNING] [UDP] The current recv_buff_size of 212992 is less than the minimum recommended size of 307200 and may result in dropped packets on some NICs

[WARNING] [UDP] The current send_buff_size of 212992 is less than the minimum recommended size of 307200 and may result in dropped packets on some NICs

Begin streaming 10000 samples, 1.500000 seconds in the future...

Received packet: 364 samples, 1 full secs, 0.500000 frac secs

Received packet: 364 samples, 1 full secs, 0.500364 frac secs

Received packet: 364 samples, 1 full secs, 0.500728 frac secs

Received packet: 364 samples, 1 full secs, 0.501092 frac secs

Received packet: 364 samples, 1 full secs, 0.501456 frac secs

Received packet: 364 samples, 1 full secs, 0.501820 frac secs

Received packet: 364 samples, 1 full secs, 0.502184 frac secs

Received packet: 364 samples, 1 full secs, 0.502548 frac secs

Received packet: 364 samples, 1 full secs, 0.502912 frac secs

Received packet: 364 samples, 1 full secs, 0.503276 frac secs

Received packet: 364 samples, 1 full secs, 0.503640 frac secs

Received packet: 364 samples, 1 full secs, 0.504004 frac secs

Received packet: 364 samples, 1 full secs, 0.504368 frac secs

Received packet: 364 samples, 1 full secs, 0.504732 frac secs

Received packet: 364 samples, 1 full secs, 0.505096 frac secs

Received packet: 364 samples, 1 full secs, 0.505460 frac secs

Received packet: 364 samples, 1 full secs, 0.505824 frac secs

Received packet: 364 samples, 1 full secs, 0.506188 frac secs

Received packet: 364 samples, 1 full secs, 0.506552 frac secs

Received packet: 364 samples, 1 full secs, 0.506916 frac secs

Received packet: 364 samples, 1 full secs, 0.507280 frac secs

Received packet: 364 samples, 1 full secs, 0.507644 frac secs

Received packet: 364 samples, 1 full secs, 0.508008 frac secs

Received packet: 364 samples, 1 full secs, 0.508372 frac secs

Received packet: 364 samples, 1 full secs, 0.508736 frac secs

Received packet: 364 samples, 1 full secs, 0.509100 frac secs

Received packet: 364 samples, 1 full secs, 0.509464 frac secs

Received packet: 172 samples, 1 full secs, 0.509828 frac secs

Done!

my@comp:/usr/local/lib/uhd/examples$

Yeah, so this looks like it may be a bug in gr-uhd in the version of Gnu Radio you're using.

Re: Problem seeing HackRF hardware on Mac via a Docker Container

Hi Marcus, do you know if a Docker Container on Mac talk to either the X310 or N310 radio? George

On Thu, Jul 28, 2022, 11:32 AM Marcus Müller <mmueller@gnuradio.org> wrote:

Hi George,

Docker on Mac OS cannot pass through USB devices:

https://docs.docker.com/desktop/faqs/general/#can-i-pass-through-a-usb-device-to-a-container

So, this is sadly impossible.

Best regards,
Marcus

On 7/28/22 17:03, George Edwards wrote:
> Hello GNURadio Community!
>
> I am working with Gnuradio 3.9 on a Mac. Gnuradio runs inside a Docker
> Container. I build a Gnuradio flow graph with a soapy HackRF source
> block to interface with the HackRF hardware. When I run the flow
> graph, it says there is no matching HackRF.
>
> Will appreciate any suggestions, thank you.
> George

Re: Problem seeing HackRF hardware on Mac via a Docker Container

Thanks Marcus!

George

On Thu, Jul 28, 2022, 11:32 AM Marcus Müller <mmueller@gnuradio.org> wrote:

Hi George,

Docker on Mac OS cannot pass through USB devices:

https://docs.docker.com/desktop/faqs/general/#can-i-pass-through-a-usb-device-to-a-container

So, this is sadly impossible.

Best regards,
Marcus

On 7/28/22 17:03, George Edwards wrote:
> Hello GNURadio Community!
>
> I am working with Gnuradio 3.9 on a Mac. Gnuradio runs inside a Docker
> Container. I build a Gnuradio flow graph with a soapy HackRF source
> block to interface with the HackRF hardware. When I run the flow
> graph, it says there is no matching HackRF.
>
> Will appreciate any suggestions, thank you.
> George

Re: Problem seeing HackRF hardware on Mac via a Docker Container

Hi George,

Docker on Mac OS cannot pass through USB devices:

https://docs.docker.com/desktop/faqs/general/#can-i-pass-through-a-usb-device-to-a-container

So, this is sadly impossible.

Best regards,
Marcus

On 7/28/22 17:03, George Edwards wrote:
> Hello GNURadio Community!
>
> I am working with Gnuradio 3.9 on a Mac. Gnuradio runs inside a Docker
> Container. I build a Gnuradio flow graph with a soapy HackRF source
> block to interface with the HackRF hardware. When I run the flow
> graph, it says there is no matching HackRF.
>
> Will appreciate any suggestions, thank you.
> George

Re: Receiving on two channels with E310/E312

I tried running rx_multi_samples, but I wasn't sure exactly what arguments to use:

my@comp:/usr/local/lib/uhd/examples$ ./rx_multi_samples --args="addr=192.168.10.43" --rate=1000000 --channels="0,1"

Creating the usrp device with: addr=192.168.10.43...

[INFO] [UHD] linux; GNU C++ version 9.4.0; Boost_107100; UHD_4.1.0.HEAD-0-g6bd0be9c

[INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=192.168.10.43,type=e3xx,product=e310_sg3,serial=31F3C12,fpga=n/a,claimed=False,addr=192.168.10.43

[INFO] [MPM.PeriphManager] Found 1 daughterboard(s).

[INFO] [MPM.PeriphManager] init() called with device args `fpga=n/a,mgmt_addr=192.168.10.43,product=e310_sg3'.

[WARNING] [UDP] The recv buffer could not be resized sufficiently.

Target sock buff size: 2500000 bytes.

Actual sock buff size: 212992 bytes.

See the transport application notes on buffer resizing.

Please run: sudo sysctl -w net.core.rmem_max=2500000

[WARNING] [UDP] The send buffer could not be resized sufficiently.

Target sock buff size: 2500000 bytes.

Actual sock buff size: 212992 bytes.

See the transport application notes on buffer resizing.

Please run: sudo sysctl -w net.core.wmem_max=2500000

[WARNING] [UDP] The current recv_buff_size of 212992 is less than the minimum recommended size of 816000 and may result in dropped packets on some NICs

[WARNING] [UDP] The current send_buff_size of 212992 is less than the minimum recommended size of 307200 and may result in dropped packets on some NICs

[INFO] [0/Radio#0] Performing CODEC loopback test on channel 0 ...

[INFO] [0/Radio#0] CODEC loopback test passed

[INFO] [0/Radio#0] Performing CODEC loopback test on channel 1 ...

[INFO] [0/Radio#0] CODEC loopback test passed

Using Device: Single USRP:

Device: E300-Series Device

Mboard 0: e310_sg3

RX Channel: 0

RX DSP: n/a

RX Dboard: A

RX Subdev: E3xx

RX Channel: 1

RX DSP: n/a

RX Dboard: A

RX Subdev: E3xx

TX Channel: 0

TX DSP: n/a

TX Dboard: A

TX Subdev: E3xx

TX Channel: 1

TX DSP: n/a

TX Dboard: A

TX Subdev: E3xx

Setting RX Rate: 1.000000 Msps...

Actual RX Rate: 1.000000 Msps...

Setting device timestamp to 0...

[WARNING] [UDP] The recv buffer could not be resized sufficiently.

Target sock buff size: 2500000 bytes.

Actual sock buff size: 212992 bytes.

See the transport application notes on buffer resizing.

Please run: sudo sysctl -w net.core.rmem_max=2500000

[WARNING] [UDP] The send buffer could not be resized sufficiently.

Target sock buff size: 2500000 bytes.

Actual sock buff size: 212992 bytes.

See the transport application notes on buffer resizing.

Please run: sudo sysctl -w net.core.wmem_max=2500000

[WARNING] [UDP] The current recv_buff_size of 212992 is less than the minimum recommended size of 307200 and may result in dropped packets on some NICs

[WARNING] [UDP] The current send_buff_size of 212992 is less than the minimum recommended size of 307200 and may result in dropped packets on some NICs

[WARNING] [UDP] The recv buffer could not be resized sufficiently.

Target sock buff size: 2500000 bytes.

Actual sock buff size: 212992 bytes.

See the transport application notes on buffer resizing.

Please run: sudo sysctl -w net.core.rmem_max=2500000

[WARNING] [UDP] The send buffer could not be resized sufficiently.

Target sock buff size: 2500000 bytes.

Actual sock buff size: 212992 bytes.

See the transport application notes on buffer resizing.

Please run: sudo sysctl -w net.core.wmem_max=2500000

[WARNING] [UDP] The current recv_buff_size of 212992 is less than the minimum recommended size of 307200 and may result in dropped packets on some NICs

[WARNING] [UDP] The current send_buff_size of 212992 is less than the minimum recommended size of 307200 and may result in dropped packets on some NICs

Begin streaming 10000 samples, 1.500000 seconds in the future...

Received packet: 364 samples, 1 full secs, 0.500000 frac secs

Received packet: 364 samples, 1 full secs, 0.500364 frac secs

Received packet: 364 samples, 1 full secs, 0.500728 frac secs

Received packet: 364 samples, 1 full secs, 0.501092 frac secs

Received packet: 364 samples, 1 full secs, 0.501456 frac secs

Received packet: 364 samples, 1 full secs, 0.501820 frac secs

Received packet: 364 samples, 1 full secs, 0.502184 frac secs

Received packet: 364 samples, 1 full secs, 0.502548 frac secs

Received packet: 364 samples, 1 full secs, 0.502912 frac secs

Received packet: 364 samples, 1 full secs, 0.503276 frac secs

Received packet: 364 samples, 1 full secs, 0.503640 frac secs

Received packet: 364 samples, 1 full secs, 0.504004 frac secs

Received packet: 364 samples, 1 full secs, 0.504368 frac secs

Received packet: 364 samples, 1 full secs, 0.504732 frac secs

Received packet: 364 samples, 1 full secs, 0.505096 frac secs

Received packet: 364 samples, 1 full secs, 0.505460 frac secs

Received packet: 364 samples, 1 full secs, 0.505824 frac secs

Received packet: 364 samples, 1 full secs, 0.506188 frac secs

Received packet: 364 samples, 1 full secs, 0.506552 frac secs

Received packet: 364 samples, 1 full secs, 0.506916 frac secs

Received packet: 364 samples, 1 full secs, 0.507280 frac secs

Received packet: 364 samples, 1 full secs, 0.507644 frac secs

Received packet: 364 samples, 1 full secs, 0.508008 frac secs

Received packet: 364 samples, 1 full secs, 0.508372 frac secs

Received packet: 364 samples, 1 full secs, 0.508736 frac secs

Received packet: 364 samples, 1 full secs, 0.509100 frac secs

Received packet: 364 samples, 1 full secs, 0.509464 frac secs

Received packet: 172 samples, 1 full secs, 0.509828 frac secs

Done!

my@comp:/usr/local/lib/uhd/examples$

From: Discuss-gnuradio <discuss-gnuradio-bounces+mvl5023=psu.edu@gnu.org> on behalf of Marcus D. Leech <patchvonbraun@gmail.com>
Sent: Wednesday, July 27, 2022 5:06 PM
To: discuss-gnuradio@gnu.org <discuss-gnuradio@gnu.org>
Subject: Re: Receiving on two channels with E310/E312

On 2022-07-27 14:22, Lipski, Michael Victor wrote:

Sure, screenshot of flowgraph is included. GRC version is 3.8, UHD is 4.1.0.

The E310 is being used in networking mode for some very basic testing. I have an E312 set up as to transmit a sine wave output (USRP Sink), which is connected over SMA to the E310 Rx ports (USRP Source). This works fine with a single Rx channel, and I can split the output of the transmitter and feed it to two different E310s, which works just fine as well. However, if I try to receive them both on the same E310, I get an error.

From: Discuss-gnuradio <discuss-gnuradio-bounces+mvl5023=psu.edu@gnu.org> on behalf of Marcus D. Leech <patchvonbraun@gmail.com>
Sent: Wednesday, July 27, 2022 1:58 PM
To: discuss-gnuradio@gnu.org <discuss-gnuradio@gnu.org>
Subject: Re: Receiving on two channels with E310/E312

On 2022-07-27 13:40, Lipski, Michael Victor wrote:

I tried both options; "A:A A:B" was invalid; it seems to accept "A:0 A:1", except that it gives me the same error message: "Runtime Error: port number 1 exceeds max of 0."

Everything works fine with a single receive channel. I have also tried streaming a single receive channel from two different E310s, which works just fine as well. As soon as I try to add a second Rx channel, the flowgraph stops working.

Could you perhaps share the flow-graph with the list, and which version of UHD, Gnu Radio you're using? Are you running on the E310 itself, or using
"network mode" ?

This may be a bug in gr-uhd, not sure.

What happens if you use one of the UHD-only example apps, like "rx_multi_samples" ? ?

Problem seeing HackRF hardware on Mac via a Docker Container

Hello GNURadio Community!

I am working with Gnuradio 3.9 on a Mac. Gnuradio runs inside a Docker Container. I build a Gnuradio flow graph with a soapy HackRF source block to interface with the HackRF hardware. When I run the flow graph, it says there is no matching HackRF.

Will appreciate any suggestions, thank you.

George

Wednesday, July 27, 2022

Re: Receiving on two channels with E310/E312

On 2022-07-27 14:22, Lipski, Michael Victor wrote:

Sure, screenshot of flowgraph is included. GRC version is 3.8, UHD is 4.1.0.

The E310 is being used in networking mode for some very basic testing. I have an E312 set up as to transmit a sine wave output (USRP Sink), which is connected over SMA to the E310 Rx ports (USRP Source). This works fine with a single Rx channel, and I can split the output of the transmitter and feed it to two different E310s, which works just fine as well. However, if I try to receive them both on the same E310, I get an error.

From: Discuss-gnuradio <discuss-gnuradio-bounces+mvl5023=psu.edu@gnu.org> on behalf of Marcus D. Leech <patchvonbraun@gmail.com>
Sent: Wednesday, July 27, 2022 1:58 PM
To: discuss-gnuradio@gnu.org <discuss-gnuradio@gnu.org>
Subject: Re: Receiving on two channels with E310/E312

On 2022-07-27 13:40, Lipski, Michael Victor wrote:

I tried both options; "A:A A:B" was invalid; it seems to accept "A:0 A:1", except that it gives me the same error message: "Runtime Error: port number 1 exceeds max of 0."

Everything works fine with a single receive channel. I have also tried streaming a single receive channel from two different E310s, which works just fine as well. As soon as I try to add a second Rx channel, the flowgraph stops working.

Could you perhaps share the flow-graph with the list, and which version of UHD, Gnu Radio you're using? Are you running on the E310 itself, or using
"network mode" ?

This may be a bug in gr-uhd, not sure.

What happens if you use one of the UHD-only example apps, like "rx_multi_samples" ? ?

Re: gr_modtool in conda failing

Hi Jameson,

I just tried this in a fresh environment with gnuradio 3.8.2 and python
3.8.13, and I was unable to reproduce the error. Maybe some of my
packages were newer than what you have. Can you try upgrading packages
to their latest versions? In other words, maybe you have an older build
of gnuradio 3.8.2 that was fixed in a subsequent build of that same
version number.

Or maybe this has a similar cause to
https://github.com/gnuradio/gnuradio/issues/5068?

Cheers,
Ryan

On 7/26/22 1:20 PM, Jameson Collins wrote:
> miniforge conda environment, gnuradio 3.8.2.0
>
> (gnuradio) user@user-VirtualBox-20$ gr_modtool newmod
> Name of the new module: asdf
> Creating out-of-tree module in ./gr-asdf...
> Traceback (most recent call last):
> File
> "/home/user/build/conda/miniforge3/envs/gnuradio/bin/gr_modtool", line
> 30, in <module>
> cli()
> File
> "/home/user/build/conda/miniforge3/envs/gnuradio/lib/python3.8/site-packages/click/core.py",
> line 1130, in __call__
> return self.main(*args, **kwargs)
> File
> "/home/user/build/conda/miniforge3/envs/gnuradio/lib/python3.8/site-packages/click/core.py",
> line 1055, in main
> rv = self.invoke(ctx)
> File
> "/home/user/build/conda/miniforge3/envs/gnuradio/lib/python3.8/site-packages/click/core.py",
> line 1657, in invoke
> return _process_result(sub_ctx.command.invoke(sub_ctx))
> File
> "/home/user/build/conda/miniforge3/envs/gnuradio/lib/python3.8/site-packages/click/core.py",
> line 1404, in invoke
> return ctx.invoke(self.callback, **ctx.params)
> File
> "/home/user/build/conda/miniforge3/envs/gnuradio/lib/python3.8/site-packages/click/core.py",
> line 760, in invoke
> return __callback(*args, **kwargs)
> File
> "/home/user/build/conda/miniforge3/envs/gnuradio/lib/python3.8/site-packages/gnuradio/modtool/cli/base.py",
> line 153, in wrapper
> return func(*args, **kwargs)
> File
> "/home/user/build/conda/miniforge3/envs/gnuradio/lib/python3.8/site-packages/gnuradio/modtool/cli/newmod.py",
> line 64, in cli
> run(self)
> File
> "/home/user/build/conda/miniforge3/envs/gnuradio/lib/python3.8/site-packages/gnuradio/modtool/cli/base.py",
> line 172, in run
> module.run()
> File
> "/home/user/build/conda/miniforge3/envs/gnuradio/lib/python3.8/site-packages/gnuradio/modtool/core/newmod.py",
> line 91, in run
> s = filetext.read()
> File
> "/home/user/build/conda/miniforge3/envs/gnuradio/lib/python3.8/codecs.py",
> line 322, in decode
> (result, consumed) = self._buffer_decode(data, self.errors, final)
> UnicodeDecodeError: 'utf-8' codec can't decode byte 0x8d in position 12:
> invalid start byte

Re: Receiving on two channels with E310/E312

Yes, there is a 30 dB attenuator before the splitter.

From: Discuss-gnuradio <discuss-gnuradio-bounces+mvl5023=psu.edu@gnu.org> on behalf of Marcus D. Leech <patchvonbraun@gmail.com>
Sent: Wednesday, July 27, 2022 2:36 PM
To: discuss-gnuradio@gnu.org <discuss-gnuradio@gnu.org>
Subject: Re: Receiving on two channels with E310/E312

On 2022-07-27 14:22, Lipski, Michael Victor wrote:

Sure, screenshot of flowgraph is included. GRC version is 3.8, UHD is 4.1.0.

The E310 is being used in networking mode for some very basic testing. I have an E312 set up as to transmit a sine wave output (USRP Sink), which is connected over SMA to the E310 Rx ports (USRP Source). This works fine with a single Rx channel, and I can split the output of the transmitter and feed it to two different E310s, which works just fine as well. However, if I try to receive them both on the same E310, I get an error.

On a separate note, I assume you have 30-50dB of attenuation inserted into the lines between the TX and RX?

From: Discuss-gnuradio <discuss-gnuradio-bounces+mvl5023=psu.edu@gnu.org> on behalf of Marcus D. Leech <patchvonbraun@gmail.com>
Sent: Wednesday, July 27, 2022 1:58 PM
To: discuss-gnuradio@gnu.org <discuss-gnuradio@gnu.org>
Subject: Re: Receiving on two channels with E310/E312

On 2022-07-27 13:40, Lipski, Michael Victor wrote:

I tried both options; "A:A A:B" was invalid; it seems to accept "A:0 A:1", except that it gives me the same error message: "Runtime Error: port number 1 exceeds max of 0."

Everything works fine with a single receive channel. I have also tried streaming a single receive channel from two different E310s, which works just fine as well. As soon as I try to add a second Rx channel, the flowgraph stops working.

Could you perhaps share the flow-graph with the list, and which version of UHD, Gnu Radio you're using? Are you running on the E310 itself, or using
"network mode" ?

Re: Receiving on two channels with E310/E312

On 2022-07-27 14:22, Lipski, Michael Victor wrote:

Sure, screenshot of flowgraph is included. GRC version is 3.8, UHD is 4.1.0.

The E310 is being used in networking mode for some very basic testing. I have an E312 set up as to transmit a sine wave output (USRP Sink), which is connected over SMA to the E310 Rx ports (USRP Source). This works fine with a single Rx channel, and I can split the output of the transmitter and feed it to two different E310s, which works just fine as well. However, if I try to receive them both on the same E310, I get an error.

On a separate note, I assume you have 30-50dB of attenuation inserted into the lines between the TX and RX?

From: Discuss-gnuradio <discuss-gnuradio-bounces+mvl5023=psu.edu@gnu.org> on behalf of Marcus D. Leech <patchvonbraun@gmail.com>
Sent: Wednesday, July 27, 2022 1:58 PM
To: discuss-gnuradio@gnu.org <discuss-gnuradio@gnu.org>
Subject: Re: Receiving on two channels with E310/E312

On 2022-07-27 13:40, Lipski, Michael Victor wrote:

I tried both options; "A:A A:B" was invalid; it seems to accept "A:0 A:1", except that it gives me the same error message: "Runtime Error: port number 1 exceeds max of 0."

Everything works fine with a single receive channel. I have also tried streaming a single receive channel from two different E310s, which works just fine as well. As soon as I try to add a second Rx channel, the flowgraph stops working.

Could you perhaps share the flow-graph with the list, and which version of UHD, Gnu Radio you're using? Are you running on the E310 itself, or using
"network mode" ?

Re: Receiving on two channels with E310/E312

Sure, screenshot of flowgraph is included. GRC version is 3.8, UHD is 4.1.0.

The E310 is being used in networking mode for some very basic testing. I have an E312 set up as to transmit a sine wave output (USRP Sink), which is connected over SMA to the E310 Rx ports (USRP Source). This works fine with a single Rx channel, and I can split the output of the transmitter and feed it to two different E310s, which works just fine as well. However, if I try to receive them both on the same E310, I get an error.

From: Discuss-gnuradio <discuss-gnuradio-bounces+mvl5023=psu.edu@gnu.org> on behalf of Marcus D. Leech <patchvonbraun@gmail.com>
Sent: Wednesday, July 27, 2022 1:58 PM
To: discuss-gnuradio@gnu.org <discuss-gnuradio@gnu.org>
Subject: Re: Receiving on two channels with E310/E312

On 2022-07-27 13:40, Lipski, Michael Victor wrote:

I tried both options; "A:A A:B" was invalid; it seems to accept "A:0 A:1", except that it gives me the same error message: "Runtime Error: port number 1 exceeds max of 0."

Everything works fine with a single receive channel. I have also tried streaming a single receive channel from two different E310s, which works just fine as well. As soon as I try to add a second Rx channel, the flowgraph stops working.

Could you perhaps share the flow-graph with the list, and which version of UHD, Gnu Radio you're using? Are you running on the E310 itself, or using
"network mode" ?

Re: Receiving on two channels with E310/E312

On 2022-07-27 13:40, Lipski, Michael Victor wrote:

I tried both options; "A:A A:B" was invalid; it seems to accept "A:0 A:1", except that it gives me the same error message: "Runtime Error: port number 1 exceeds max of 0."

Everything works fine with a single receive channel. I have also tried streaming a single receive channel from two different E310s, which works just fine as well. As soon as I try to add a second Rx channel, the flowgraph stops working.

Could you perhaps share the flow-graph with the list, and which version of UHD, Gnu Radio you're using? Are you running on the E310 itself, or using
"network mode" ?

Re: Receiving on two channels with E310/E312

I tried both options; "A:A A:B" was invalid; it seems to accept "A:0 A:1", except that it gives me the same error message: "Runtime Error: port number 1 exceeds max of 0."

Everything works fine with a single receive channel. I have also tried streaming a single receive channel from two different E310s, which works just fine as well. As soon as I try to add a second Rx channel, the flowgraph stops working.

From: Discuss-gnuradio <discuss-gnuradio-bounces+mvl5023=psu.edu@gnu.org> on behalf of Lipski, Michael Victor <mvl5023@psu.edu>
Sent: Wednesday, July 27, 2022 12:04 PM
To: GNU Radio Mailing List <discuss-gnuradio@gnu.org>
Subject: Receiving on two channels with E310/E312

Hello all,

I am running some simple tests with some E310/E312 radios and would like to set one up to receive on two channels simultaneously. How would I go about doing this using the UHD:USRP Source block? I have no problem receiving on a single channel, but when I try to set up the block to have two channels, I get a, "Runtime Error: port number 1 exceeds max of 0."

I am rather new to the E310/E312, and I'm testing them out over networked mode rather than embedded. I have the device set up with a static IP address, which is configured in the Device Address box. What would be the basic parameters needed to set up an E310 to receive on two channels? I know the two RX channels would share the same LO, so I have the center frequency set to the same value for Ch0 and Ch1. I'm using GRC 3.8 and UHD 4.1.0.

I appreciate any help with this. Thanks!

Re: Receiving on two channels with E310/E312

On 2022-07-27 12:04, Lipski, Michael Victor wrote:

Hello all,

I am running some simple tests with some E310/E312 radios and would like to set one up to receive on two channels simultaneously. How would I go about doing this using the UHD:USRP Source block? I have no problem receiving on a single channel, but when I try to set up the block to have two channels, I get a, "Runtime Error: port number 1 exceeds max of 0."

I am rather new to the E310/E312, and I'm testing them out over networked mode rather than embedded. I have the device set up with a static IP address, which is configured in the Device Address box. What would be the basic parameters needed to set up an E310 to receive on two channels? I know the two RX channels would share the same LO, so I have the center frequency set to the same value for Ch0 and Ch1. I'm using GRC 3.8 and UHD 4.1.0.

I appreciate any help with this. Thanks!

Make sure your SUBDEV spec is:

A:A A:B

or

A:0 A:1

Depending on which version of UHD you're running on your E310.

Receiving on two channels with E310/E312

Hello all,

I appreciate any help with this. Thanks!

Tuesday, July 26, 2022

gr_modtool in conda failing

miniforge conda environment, gnuradio 3.8.2.0

(gnuradio) user@user-VirtualBox-20$ gr_modtool newmod
Name of the new module: asdf
Creating out-of-tree module in ./gr-asdf...
Traceback (most recent call last):
File "/home/user/build/conda/miniforge3/envs/gnuradio/bin/gr_modtool", line 30, in <module>
cli()
File "/home/user/build/conda/miniforge3/envs/gnuradio/lib/python3.8/site-packages/click/core.py", line 1130, in __call__
return self.main(*args, **kwargs)
File "/home/user/build/conda/miniforge3/envs/gnuradio/lib/python3.8/site-packages/click/core.py", line 1055, in main
rv = self.invoke(ctx)
File "/home/user/build/conda/miniforge3/envs/gnuradio/lib/python3.8/site-packages/click/core.py", line 1657, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "/home/user/build/conda/miniforge3/envs/gnuradio/lib/python3.8/site-packages/click/core.py", line 1404, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "/home/user/build/conda/miniforge3/envs/gnuradio/lib/python3.8/site-packages/click/core.py", line 760, in invoke
return __callback(*args, **kwargs)
File "/home/user/build/conda/miniforge3/envs/gnuradio/lib/python3.8/site-packages/gnuradio/modtool/cli/base.py", line 153, in wrapper
return func(*args, **kwargs)
File "/home/user/build/conda/miniforge3/envs/gnuradio/lib/python3.8/site-packages/gnuradio/modtool/cli/newmod.py", line 64, in cli
run(self)
File "/home/user/build/conda/miniforge3/envs/gnuradio/lib/python3.8/site-packages/gnuradio/modtool/cli/base.py", line 172, in run
module.run()
File "/home/user/build/conda/miniforge3/envs/gnuradio/lib/python3.8/site-packages/gnuradio/modtool/core/newmod.py", line 91, in run
s = filetext.read()
File "/home/user/build/conda/miniforge3/envs/gnuradio/lib/python3.8/codecs.py", line 322, in decode
(result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x8d in position 12: invalid start byte

Monday, July 25, 2022

回复: [GSoC porting SIMD to gr-web] weekly update

Hi, all!

I will post weekly this project update in this thread, following is last week:

Short version report:( unfortunaly I need to rebuild gr-web)

Has Done: 1. using latest gr commit to build gr-web. 2. Fix commit missing issue.

TODO: 1. fix the running fail issue. 2. And push the modification to marc's repo.

Full version report: blog here

Yours,

Yao

发件人: 史皓航
发送时间: 2022年7月18日 22:39
收件人: discuss-gnuradio@gnu.org
主题: re: [GSoC porting SIMD to gr-web] weekly update

Hey, all!

I will post weekly this project update in this thread, following is last week:

Short version report:(due to covid-19 the progress slows down a little)

Has Done: post a blog to introduce the dev tool usage(part 1)

TODO: post another blog and measure the different implemented volk performance(time cost first)

Full version report: blog here

Yours,

Yao.

发件人: 史皓航 <shyhot@outlook.com>
发送时间: 2022年7月12日 0:10
收件人: discuss-gnuradio@gnu.org <discuss-gnuradio@gnu.org>
主题: [GSoC porting SIMD to gr-web] weekly update

Hey, all!

This is a weekly update email about the GSoC project.

Following is last week progress and next week plan:

Short:

l Has Done: building gr-web wholly and play grc.

l Need to be Done: Intend to run a benchmark to measure different implement to `volk`

Full blog:

Week2 | eat4toast.github.io

Yours,

Yao

发件人: 史皓航
发送时间: 2022年7月5日 00:06
收件人: discuss-gnuradio@gnu.org
主题: [GSoC porting SIMD to gr-web] weekly update

Hi, everyone!

I've been accepted to work with GnuRadio for this year's Google Summer of Code.

The task I intend to implement is porting SIMD code to gr-web through wasm,

which enables gnuradio more extensible and popular through the browser.

I am really sorry, this post seems a bit late due to some unexpected problems with the building gr-web from the source.

Last week's blog:

https://eat4toast.github.io/2022/07/04/week1.html

I will post a weekly update on the mailing list, well the blog will record more latest progress.

Yours,

Yao.