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/GP
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_us
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
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 (mos
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-ieee8
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 ha
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!
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ü
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 a
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
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 US
11 matches
Mail list logo
