UHD: USRP source issue when using 2 channels
Am I the only one facing an issue with fetching data from 2 channels of a B210 receiver ? When addressing a single channels (USRP Source -> file sink) all goes well, but whenever I activate a second channel (Num Mboards=1, Num Channels=2) I get an error message tb = top_block_cls() File "/tmp/GPS.py", line 103, in __init__ self.connect((self.uhd_usrp_source_1, 1), (self.blocks_null_sink_0, 0)) File ".../gnuradio3.8/lib/python3.7/dist-packages/gnuradio/gr/hier_block2.py", line 48, in wrapped func(self, src, src_port, dst, dst_port) File ".../gnuradio3.8/lib/python3.7/dist-packages/gnuradio/gr/hier_block2.py", line 111, in connect self.primitive_connect(*args) File ".../gnuradio3.8/lib/python3.7/dist-packages/gnuradio/gr/runtime_swig.py", line 5461, in primitive_connect return _runtime_swig.top_block_sptr_primitive_connect(self, *args) RuntimeError: port number 1 exceeds max of 0 whatever sink (file, null) is attached to the UHD output. I am facing the issue with custom 3.8.0.0-rc2 (Python 3.7.5) or the current Debian/sid 3.8.0.0 (Python 3.7.5) versions of GNU Radio Companion. The flowchart with the issue is at http://jmfriedt.org/GPS.pdf Thanks, JM
Re: UHD: USRP source issue when using 2 channels
I have the same issue, but the error message is different. Traceback (most recent call last): File "/home/re/xfer/uhdrx.py", line 213, in main() File "/home/re/xfer/uhdrx.py", line 191, in main tb = top_block_cls() File "/home/re/xfer/uhdrx.py", line 97, in __init__ self.uhd_usrp_source_0.set_center_freq(center_freq, 1) File "/opt/gnuradio-3.7.12git/lib/python3.6/dist-packages/gnuradio/uhd/uhd_swig.py", line 3600, in set_center_freq return _uhd_swig.usrp_source_sptr_set_center_freq(self, *args) RuntimeError: LookupError: IndexError: multi_usrp: RX channel 140641462873248 out of range for configured RX frontends >>> Done (return code 1) Ron On 11/21/19 00:43, jean-michel.fri...@femto-st.fr wrote: Am I the only one facing an issue with fetching data from 2 channels of a B210 receiver ? When addressing a single channels (USRP Source -> file sink) all goes well, but whenever I activate a second channel (Num Mboards=1, Num Channels=2) I get an error message tb = top_block_cls() File "/tmp/GPS.py", line 103, in __init__ self.connect((self.uhd_usrp_source_1, 1), (self.blocks_null_sink_0, 0)) File ".../gnuradio3.8/lib/python3.7/dist-packages/gnuradio/gr/hier_block2.py", line 48, in wrapped func(self, src, src_port, dst, dst_port) File ".../gnuradio3.8/lib/python3.7/dist-packages/gnuradio/gr/hier_block2.py", line 111, in connect self.primitive_connect(*args) File ".../gnuradio3.8/lib/python3.7/dist-packages/gnuradio/gr/runtime_swig.py", line 5461, in primitive_connect return _runtime_swig.top_block_sptr_primitive_connect(self, *args) RuntimeError: port number 1 exceeds max of 0 whatever sink (file, null) is attached to the UHD output. I am facing the issue with custom 3.8.0.0-rc2 (Python 3.7.5) or the current Debian/sid 3.8.0.0 (Python 3.7.5) versions of GNU Radio Companion. The flowchart with the issue is at http://jmfriedt.org/GPS.pdf Thanks, JM
[Discuss-gnuradio] buffer allocation failing with RuntimeError: bad_alloc
I'm running the sample wifi_tx.grc flowchart from gr-ieee802.11, substituting a null sink for the USRP sink to test it. When I try to run it, it fails with the following error message: " >set_min_output_buffer on block 7 to 207744 >set_min_output_buffer on block 9 to 2077440 >set_min_output_buffer on block 11 to 2077440 >set_min_output_buffer on block 12 to 207744 >set_min_output_buffer on block 13 to 415488 >set_min_output_buffer on block 14 to 207744 >set_min_output_buffer on block 26 to 262144 >set_min_output_buffer on block 27 to 96000 >set_min_output_buffer on block 31 to 10 >gr::vmcircbuf_mmap_shm_open: mmap (1): Cannot allocate memory >gr::buffer::allocate_buffer: failed to allocate buffer of size 1038720 KB >gr::vmcircbuf_mmap_shm_open: mmap (1): Cannot allocate memory >gr::buffer::allocate_buffer: failed to allocate buffer of size 1038720 KB >Traceback (most recent call last): > File "/home/vtti/working/wifi_tx.py", line 297, in >main() > File "/home/vtti/working/wifi_tx.py", line 276, in main >tb.start() > File "/usr/local/lib/python3.6/dist-packages/gnuradio/gr/top_block.py", line 111, >in start >top_block_start_unlocked(self._impl, max_noutput_items) > File "/usr/local/lib/python3.6/dist-packages/gnuradio/gr/runtime_swig.py", line >5828, in top_block_start_unlocked >return _runtime_swig.top_block_start_unlocked(r, max_noutput_items) >RuntimeError: std::bad_alloc " Here's a picture of my flowchart: [image: gnuradio-runtimeError-bad_alloc.png] Tested this on a different machine, and it works fine, so the problem isn't with the flowchart itself. I'm working off the maint-3.8 branch, installed from source. Any idea why I'm getting this error, or how I could resolve it? Thanks! -- Eamon Heaney *Fleet Commander* *President, Model UN at Virginia Tech*
Re: UHD: USRP source issue when using 2 channels
I'm s close to shouting out "ha-ha! Integer signedness error!", but I think chances are this was fixed on master in 8eb1a354c0b5126b6c0b7d55b68963a155088b3a. On Thu, 2019-11-21 at 01:57 -0800, Ron Economos wrote: > I have the same issue, but the error message is different. > > Traceback (most recent call last): >File "/home/re/xfer/uhdrx.py", line 213, in > main() >File "/home/re/xfer/uhdrx.py", line 191, in main > tb = top_block_cls() >File "/home/re/xfer/uhdrx.py", line 97, in __init__ > self.uhd_usrp_source_0.set_center_freq(center_freq, 1) >File > "/opt/gnuradio-3.7.12git/lib/python3.6/dist-packages/gnuradio/uhd/uhd_swig.py", > > line 3600, in set_center_freq > return _uhd_swig.usrp_source_sptr_set_center_freq(self, *args) > RuntimeError: LookupError: IndexError: multi_usrp: RX channel > 140641462873248 out of range for configured RX frontends > > >>> Done (return code 1) > > Ron > > On 11/21/19 00:43, jean-michel.fri...@femto-st.fr wrote: > > Am I the only one facing an issue with fetching data from 2 channels of a > > B210 receiver ? > > When addressing a single channels (USRP Source -> file sink) all goes well, > > but > > whenever I activate a second channel (Num Mboards=1, Num Channels=2) I get > > an error message > > > > tb = top_block_cls() > > File "/tmp/GPS.py", line 103, in __init__ > > self.connect((self.uhd_usrp_source_1, 1), (self.blocks_null_sink_0, 0)) > > File > > ".../gnuradio3.8/lib/python3.7/dist-packages/gnuradio/gr/hier_block2.py", > > line 48, in wrapped > > func(self, src, src_port, dst, dst_port) > > File > > ".../gnuradio3.8/lib/python3.7/dist-packages/gnuradio/gr/hier_block2.py", > > line 111, in connect > > self.primitive_connect(*args) > > File > > ".../gnuradio3.8/lib/python3.7/dist-packages/gnuradio/gr/runtime_swig.py", > > line 5461, in > > primitive_connect > > return _runtime_swig.top_block_sptr_primitive_connect(self, *args) > > RuntimeError: port number 1 exceeds max of 0 > > > > whatever sink (file, null) is attached to the UHD output. I am facing the > > issue > > with custom 3.8.0.0-rc2 (Python 3.7.5) or the current Debian/sid 3.8.0.0 > > (Python 3.7.5) versions of GNU Radio Companion. > > > > The flowchart with the issue is at http://jmfriedt.org/GPS.pdf > > > > Thanks, JM > > > > smime.p7s Description: S/MIME cryptographic signature
Re: [Discuss-gnuradio] buffer allocation failing with RuntimeError: bad_alloc
You must be running an older kernel that doesn't set kernel.shmmax to some large value. To check the current setting: sysctl kernel.shmmax To set it higher: sudo -w kernel.shmmax=2147483648 Ron On 11/21/19 01:59, Eamon Heaney wrote: I'm running the sample wifi_tx.grc flowchart from gr-ieee802.11, substituting a null sink for the USRP sink to test it. When I try to run it, it fails with the following error message: " >set_min_output_buffer on block 7 to 207744 >set_min_output_buffer on block 9 to 2077440 >set_min_output_buffer on block 11 to 2077440 >set_min_output_buffer on block 12 to 207744 >set_min_output_buffer on block 13 to 415488 >set_min_output_buffer on block 14 to 207744 >set_min_output_buffer on block 26 to 262144 >set_min_output_buffer on block 27 to 96000 >set_min_output_buffer on block 31 to 10 >gr::vmcircbuf_mmap_shm_open: mmap (1): Cannot allocate memory >gr::buffer::allocate_buffer: failed to allocate buffer of size 1038720 KB >gr::vmcircbuf_mmap_shm_open: mmap (1): Cannot allocate memory >gr::buffer::allocate_buffer: failed to allocate buffer of size 1038720 KB >Traceback (most recent call last): > File "/home/vtti/working/wifi_tx.py", line 297, in > main() > File "/home/vtti/working/wifi_tx.py", line 276, in main > tb.start() > File "/usr/local/lib/python3.6/dist-packages/gnuradio/gr/top_block.py", line 111, >in start > top_block_start_unlocked(self._impl, max_noutput_items) > File "/usr/local/lib/python3.6/dist-packages/gnuradio/gr/runtime_swig.py", line >5828, in top_block_start_unlocked > return _runtime_swig.top_block_start_unlocked(r, max_noutput_items) >RuntimeError: std::bad_alloc " Here's a picture of my flowchart: gnuradio-runtimeError-bad_alloc.png Tested this on a different machine, and it works fine, so the problem isn't with the flowchart itself. I'm working off the maint-3.8 branch, installed from source. Any idea why I'm getting this error, or how I could resolve it? Thanks! -- Eamon Heaney / /Fleet Commander/ // /President, Model UN at Virginia Tech/ /
Re: UHD: USRP source issue when using 2 channels
I'll give it a try. Ron On 11/21/19 02:13, Müller, Marcus (CEL) wrote: I'm s close to shouting out "ha-ha! Integer signedness error!", but I think chances are this was fixed on master in 8eb1a354c0b5126b6c0b7d55b68963a155088b3a. On Thu, 2019-11-21 at 01:57 -0800, Ron Economos wrote: I have the same issue, but the error message is different. Traceback (most recent call last): File "/home/re/xfer/uhdrx.py", line 213, in main() File "/home/re/xfer/uhdrx.py", line 191, in main tb = top_block_cls() File "/home/re/xfer/uhdrx.py", line 97, in __init__ self.uhd_usrp_source_0.set_center_freq(center_freq, 1) File "/opt/gnuradio-3.7.12git/lib/python3.6/dist-packages/gnuradio/uhd/uhd_swig.py", line 3600, in set_center_freq return _uhd_swig.usrp_source_sptr_set_center_freq(self, *args) RuntimeError: LookupError: IndexError: multi_usrp: RX channel 140641462873248 out of range for configured RX frontends >>> Done (return code 1) Ron On 11/21/19 00:43, jean-michel.fri...@femto-st.fr wrote: Am I the only one facing an issue with fetching data from 2 channels of a B210 receiver ? When addressing a single channels (USRP Source -> file sink) all goes well, but whenever I activate a second channel (Num Mboards=1, Num Channels=2) I get an error message tb = top_block_cls() File "/tmp/GPS.py", line 103, in __init__ self.connect((self.uhd_usrp_source_1, 1), (self.blocks_null_sink_0, 0)) File ".../gnuradio3.8/lib/python3.7/dist-packages/gnuradio/gr/hier_block2.py", line 48, in wrapped func(self, src, src_port, dst, dst_port) File ".../gnuradio3.8/lib/python3.7/dist-packages/gnuradio/gr/hier_block2.py", line 111, in connect self.primitive_connect(*args) File ".../gnuradio3.8/lib/python3.7/dist-packages/gnuradio/gr/runtime_swig.py", line 5461, in primitive_connect return _runtime_swig.top_block_sptr_primitive_connect(self, *args) RuntimeError: port number 1 exceeds max of 0 whatever sink (file, null) is attached to the UHD output. I am facing the issue with custom 3.8.0.0-rc2 (Python 3.7.5) or the current Debian/sid 3.8.0.0 (Python 3.7.5) versions of GNU Radio Companion. The flowchart with the issue is at http://jmfriedt.org/GPS.pdf Thanks, JM
Re: UHD: USRP source issue when using 2 channels
I confirm that with the current git (GNU Radio 3.9.0) the issue seems solved. JM -- JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe, 25000 Besancon, France November 21, 2019 11:14 AM, "Müller, Marcus" wrote: > I'm s close to shouting out "ha-ha! Integer signedness error!", but > I think chances are this was fixed on master in > 8eb1a354c0b5126b6c0b7d55b68963a155088b3a. > > On Thu, 2019-11-21 at 01:57 -0800, Ron Economos wrote: > >> I have the same issue, but the error message is different. >> >> Traceback (most recent call last): >> File "/home/re/xfer/uhdrx.py", line 213, in >> main() >> File "/home/re/xfer/uhdrx.py", line 191, in main >> tb = top_block_cls() >> File "/home/re/xfer/uhdrx.py", line 97, in __init__ >> self.uhd_usrp_source_0.set_center_freq(center_freq, 1) >> File >> "/opt/gnuradio-3.7.12git/lib/python3.6/dist-packages/gnuradio/uhd/uhd_swig.py", >> line 3600, in set_center_freq >> return _uhd_swig.usrp_source_sptr_set_center_freq(self, *args) >> RuntimeError: LookupError: IndexError: multi_usrp: RX channel >> 140641462873248 out of range for configured RX frontends >> > Done (return code 1) >> >> Ron >> >> On 11/21/19 00:43, jean-michel.fri...@femto-st.fr wrote: >> Am I the only one facing an issue with fetching data from 2 channels of a >> B210 receiver ? >> When addressing a single channels (USRP Source -> file sink) all goes well, >> but >> whenever I activate a second channel (Num Mboards=1, Num Channels=2) I get >> an error message >> >> tb = top_block_cls() >> File "/tmp/GPS.py", line 103, in __init__ >> self.connect((self.uhd_usrp_source_1, 1), (self.blocks_null_sink_0, 0)) >> File >> ".../gnuradio3.8/lib/python3.7/dist-packages/gnuradio/gr/hier_block2.py", >> line 48, in wrapped >> func(self, src, src_port, dst, dst_port) >> File >> ".../gnuradio3.8/lib/python3.7/dist-packages/gnuradio/gr/hier_block2.py", >> line 111, in connect >> self.primitive_connect(*args) >> File >> ".../gnuradio3.8/lib/python3.7/dist-packages/gnuradio/gr/runtime_swig.py", >> line 5461, in >> primitive_connect >> return _runtime_swig.top_block_sptr_primitive_connect(self, *args) >> RuntimeError: port number 1 exceeds max of 0 >> >> whatever sink (file, null) is attached to the UHD output. I am facing the >> issue >> with custom 3.8.0.0-rc2 (Python 3.7.5) or the current Debian/sid 3.8.0.0 >> (Python 3.7.5) versions of GNU Radio Companion. >> >> The flowchart with the issue is at http://jmfriedt.org/GPS.pdf >> >> Thanks, JM
Re: UHD: USRP source issue when using 2 channels
Also confirm it's fixed. Ron On 11/21/19 02:25, jean-michel.fri...@femto-st.fr wrote: I confirm that with the current git (GNU Radio 3.9.0) the issue seems solved. JM -- JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe, 25000 Besancon, France November 21, 2019 11:14 AM, "Müller, Marcus" wrote: I'm s close to shouting out "ha-ha! Integer signedness error!", but I think chances are this was fixed on master in 8eb1a354c0b5126b6c0b7d55b68963a155088b3a. On Thu, 2019-11-21 at 01:57 -0800, Ron Economos wrote: I have the same issue, but the error message is different. Traceback (most recent call last): File "/home/re/xfer/uhdrx.py", line 213, in main() File "/home/re/xfer/uhdrx.py", line 191, in main tb = top_block_cls() File "/home/re/xfer/uhdrx.py", line 97, in __init__ self.uhd_usrp_source_0.set_center_freq(center_freq, 1) File "/opt/gnuradio-3.7.12git/lib/python3.6/dist-packages/gnuradio/uhd/uhd_swig.py", line 3600, in set_center_freq return _uhd_swig.usrp_source_sptr_set_center_freq(self, *args) RuntimeError: LookupError: IndexError: multi_usrp: RX channel 140641462873248 out of range for configured RX frontends Done (return code 1) Ron On 11/21/19 00:43, jean-michel.fri...@femto-st.fr wrote: Am I the only one facing an issue with fetching data from 2 channels of a B210 receiver ? When addressing a single channels (USRP Source -> file sink) all goes well, but whenever I activate a second channel (Num Mboards=1, Num Channels=2) I get an error message tb = top_block_cls() File "/tmp/GPS.py", line 103, in __init__ self.connect((self.uhd_usrp_source_1, 1), (self.blocks_null_sink_0, 0)) File ".../gnuradio3.8/lib/python3.7/dist-packages/gnuradio/gr/hier_block2.py", line 48, in wrapped func(self, src, src_port, dst, dst_port) File ".../gnuradio3.8/lib/python3.7/dist-packages/gnuradio/gr/hier_block2.py", line 111, in connect self.primitive_connect(*args) File ".../gnuradio3.8/lib/python3.7/dist-packages/gnuradio/gr/runtime_swig.py", line 5461, in primitive_connect return _runtime_swig.top_block_sptr_primitive_connect(self, *args) RuntimeError: port number 1 exceeds max of 0 whatever sink (file, null) is attached to the UHD output. I am facing the issue with custom 3.8.0.0-rc2 (Python 3.7.5) or the current Debian/sid 3.8.0.0 (Python 3.7.5) versions of GNU Radio Companion. The flowchart with the issue is at http://jmfriedt.org/GPS.pdf Thanks, JM
Re: [Discuss-gnuradio] buffer allocation failing with RuntimeError: bad_alloc
Yeah, I tried changing the maximum shared memory, but that didn't work. I mean, it didn't resolve the problem; I gave it 2147483648 but the error persists. I tried adding a zero to that, but that's an "Invalid Argument." On Thu, Nov 21, 2019 at 5:17 AM Ron Economos wrote: > You must be running an older kernel that doesn't set kernel.shmmax to some > large value. > > To check the current setting: > > sysctl kernel.shmmax > > To set it higher: > > sudo -w kernel.shmmax=2147483648 > > Ron > On 11/21/19 01:59, Eamon Heaney wrote: > > I'm running the sample wifi_tx.grc flowchart from gr-ieee802.11, > substituting a null sink for the USRP sink to test it. > > When I try to run it, it fails with the following error message: > " > >set_min_output_buffer on block 7 to 207744 > >set_min_output_buffer on block 9 to 2077440 > >set_min_output_buffer on block 11 to 2077440 > >set_min_output_buffer on block 12 to 207744 > >set_min_output_buffer on block 13 to 415488 > >set_min_output_buffer on block 14 to 207744 > >set_min_output_buffer on block 26 to 262144 > >set_min_output_buffer on block 27 to 96000 > >set_min_output_buffer on block 31 to 10 > >gr::vmcircbuf_mmap_shm_open: mmap (1): Cannot allocate memory > >gr::buffer::allocate_buffer: failed to allocate buffer of size 1038720 KB > >gr::vmcircbuf_mmap_shm_open: mmap (1): Cannot allocate memory > >gr::buffer::allocate_buffer: failed to allocate buffer of size 1038720 KB > >Traceback (most recent call last): > > File "/home/vtti/working/wifi_tx.py", line 297, in > >main() > > File "/home/vtti/working/wifi_tx.py", line 276, in main > >tb.start() > > File "/usr/local/lib/python3.6/dist-packages/gnuradio/gr/top_block.py", > line 111, >in start > >top_block_start_unlocked(self._impl, max_noutput_items) > > File > "/usr/local/lib/python3.6/dist-packages/gnuradio/gr/runtime_swig.py", line > >5828, in top_block_start_unlocked > >return _runtime_swig.top_block_start_unlocked(r, max_noutput_items) > >RuntimeError: std::bad_alloc > " > Here's a picture of my flowchart: > [image: gnuradio-runtimeError-bad_alloc.png] > > Tested this on a different machine, and it works fine, so the problem > isn't with the flowchart itself. I'm working off the maint-3.8 branch, > installed from source. > > Any idea why I'm getting this error, or how I could resolve it? Thanks! > -- > Eamon Heaney > * Fleet Commander * > * President, Model UN at Virginia Tech * > > -- Eamon Heaney *Fleet Commander* *President, Model UN at Virginia Tech*
Project Call Today! 10 AM Pacific, 19:00 CET
Hi all, we have another project call today, in 18 minutes (sorry for the late announcement). Join us on IRC or Slack for the meeting link. I'll post the YT link here, too. Cheers! --M
Re: [Discuss-gnuradio] buffer allocation failing with RuntimeError: bad_alloc
Look in
${HOME}/.gnuradio/prefs/vmcircbuf_default_factory
and see what is there and maybe change to this:
gr::vmcircbuf_mmap_tmpfile_factory
Philip
On 11/21/19 4:59 AM, Eamon Heaney wrote:
> I'm running the sample wifi_tx.grc flowchart from gr-ieee802.11,
> substituting a null sink for the USRP sink to test it.
>
> When I try to run it, it fails with the following error message:
> "
>> set_min_output_buffer on block 7 to 207744
>> set_min_output_buffer on block 9 to 2077440
>> set_min_output_buffer on block 11 to 2077440
>> set_min_output_buffer on block 12 to 207744
>> set_min_output_buffer on block 13 to 415488
>> set_min_output_buffer on block 14 to 207744
>> set_min_output_buffer on block 26 to 262144
>> set_min_output_buffer on block 27 to 96000
>> set_min_output_buffer on block 31 to 10
>> gr::vmcircbuf_mmap_shm_open: mmap (1): Cannot allocate memory
>> gr::buffer::allocate_buffer: failed to allocate buffer of size 1038720 KB
>> gr::vmcircbuf_mmap_shm_open: mmap (1): Cannot allocate memory
>> gr::buffer::allocate_buffer: failed to allocate buffer of size 1038720 KB
>> Traceback (most recent call last):
>> File "/home/vtti/working/wifi_tx.py", line 297, in
>>main()
>> File "/home/vtti/working/wifi_tx.py", line 276, in main
>>tb.start()
>> File "/usr/local/lib/python3.6/dist-packages/gnuradio/gr/top_block.py",
> line 111, >in start
>>top_block_start_unlocked(self._impl, max_noutput_items)
>> File
> "/usr/local/lib/python3.6/dist-packages/gnuradio/gr/runtime_swig.py", line
>> 5828, in top_block_start_unlocked
>>return _runtime_swig.top_block_start_unlocked(r, max_noutput_items)
>> RuntimeError: std::bad_alloc
> "
> Here's a picture of my flowchart:
> [image: gnuradio-runtimeError-bad_alloc.png]
>
> Tested this on a different machine, and it works fine, so the problem isn't
> with the flowchart itself. I'm working off the maint-3.8 branch, installed
> from source.
>
> Any idea why I'm getting this error, or how I could resolve it? Thanks!
>
