Re: [Discuss-gnuradio] GRC newbie questions

[Kevin Lee]

Hello,

I believe you'd set the number of outputs to 1, for the array itself, and
when you set the data type of the output, you'd use sizeof(float) or
sizeof(gr_complex) * array_size, so in this case array_size is 58. You'd do
this for both input and output signatures.

Good luck!

Kevin

On Thu, Jun 27, 2019, 5:14 PM Barry Duggan  wrote:

> This is a restatement of my second question:
>
> If the input to a block is an array of X bytes, and I produce an output
> array of Y bytes, is that still considered a sync_block, i.e. one array
> in, one array out? For example, if the input array has a length of 64
> bytes, and I produce an output array with 68 bytes, do I set the number
> of outputs to 1 (for the array) or 68 for the length of the array?
>
> Thanks
> --
> Barry Duggan
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GRC newbie questions

[Barry Duggan]

This is a restatement of my second question:

If the input to a block is an array of X bytes, and I produce an output 
array of Y bytes, is that still considered a sync_block, i.e. one array 
in, one array out? For example, if the input array has a length of 64 
bytes, and I produce an output array with 68 bytes, do I set the number 
of outputs to 1 (for the array) or 68 for the length of the array?


Thanks
--
Barry Duggan

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GRCon19 Updates & Reminders

[Ben Hilburn]

Hi all!

This year's keynotes have been announced! This year, our keynote speakers
will be:

   - Travis Goodspeed
   - Mark Shuttleworth, Canonical
   - Robert Suggs, Marshall Space Flight Center
   - Mark Spencer, Digium

You can see more details about the conference program on the website, located
here
.
Note that talks & submitted tutorials have not yet been added to the
program!

Next up, the first deadline for submissions to GRCon is next Monday 1 July!
Please get your talk, poster, and paper submissions in as soon as you can.
The submission website is here:

https://openconf.org/GRCon19/openconf.php

Remember that GRCon maintains a policy that you do not have to present at
the conference to publish in the technical proceedings. If you're
submitting a presentation or poster, we encourage you to also submit a
paper to the proceedings. If you're unable to make the event but would like
to publish and share your work, you can submit a paper alone, which if
accepted will be posted with this year's TP at pubs.gnuradio.org.

Lastly, per my annual call to register earlier, please register as soon as
you can! Conference registration can be found here:

https://tickets.gnuradio.org/grcon19/

Please note that
*prices will go up on August 1st.*

If you haven't booked your hotel, yet, you can book in our discounted room
block at the conference hotel using this link:

https://www.marriott.com/events/start.mi?id=1553879040993&key=GRP

As usual, if you have any questions, please don't hesitate to reach out!
You can reach the organizing team at gr...@gnuradio.org

Cheers,
Ben
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-ieee-80211: UDP Warning and another error

[sumit kumar]

Thats true, thanks. meanwhile the UDP problem is solved. I had to run the
command as root :D not sudo.

On Thu, 27 Jun 2019 at 20:07, Michael Dickens 
wrote:

> I guess for your need so long as it works that's what matters, yes?
>
> We'll work on fixing the issue you found anyway ... seems like it's legit
> & undesirable LOL.
>
> Good luck with your demo! - MLD
>
> On Thu, Jun 27, 2019, at 2:01 PM, sumit kumar wrote:
>
> Well it worked after compiling old checkouts (but not giving me the usual
> satisfaction of a fresh install... but anyways)
>
> On Thu, 27 Jun 2019 at 19:45, sumit kumar  wrote:
>
> Its overwhelming :D, I have a demo on Monday and I was 100% assured
> gr-ieee-80211 will work as usual.
>
> Before I saw your mail, I already checked out GR to 3.7.12, UHD to 003 009
> 006 and compiling now.
> Yes I used pybombs for installation.
>
> I have a USB with gnuradio installed into it. It works good and it has GR
> 3.7.11, uhd 003 009 006 and gr-ieee-80211 version I dint check.
>
>
>

-- 
Sumit Kumar
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-ieee-80211: UDP Warning and another error

[Michael Dickens]

I guess for your need so long as it works that's what matters, yes?

We'll work on fixing the issue you found anyway ... seems like it's legit & 
undesirable LOL.

Good luck with your demo! - MLD

On Thu, Jun 27, 2019, at 2:01 PM, sumit kumar wrote:
> Well it worked after compiling old checkouts (but not giving me the usual 
> satisfaction of a fresh install... but anyways)
> 
> On Thu, 27 Jun 2019 at 19:45, sumit kumar  wrote:
>> Its overwhelming :D, I have a demo on Monday and I was 100% assured 
>> gr-ieee-80211 will work as usual. 
>> 
>> Before I saw your mail, I already checked out GR to 3.7.12, UHD to 003 009 
>> 006 and compiling now. 
>> Yes I used pybombs for installation. 
>> 
>> I have a USB with gnuradio installed into it. It works good and it has GR 
>> 3.7.11, uhd 003 009 006 and gr-ieee-80211 version I dint check. 
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-ieee-80211: UDP Warning and another error

[sumit kumar]

Well it worked after compiling old checkouts (but not giving me the usual
satisfaction of a fresh install... but anyways)

On Thu, 27 Jun 2019 at 19:45, sumit kumar  wrote:

> Its overwhelming :D, I have a demo on Monday and I was 100% assured
> gr-ieee-80211 will work as usual.
>
> Before I saw your mail, I already checked out GR to 3.7.12, UHD to 003 009
> 006 and compiling now.
> Yes I used pybombs for installation.
>
> I have a USB with gnuradio installed into it. It works good and it has GR
> 3.7.11, uhd 003 009 006 and gr-ieee-80211 version I dint check.
>
>
>
> On Thu, 27 Jun 2019 at 19:31, Michael Dickens 
> wrote:
>
>> Hmmm ... well the current UHD API for "set_auto_dc_offset" is
>> "(bool, size_t)". Looks like the generated Python from gr-ieee-80211 is
>> "set_auto_dc_offset("", 0)", which isn't compatible with the current UHD
>> API for this method.
>>
>> Hmmm ... here's my best bet: gr-ieee802-11 uses the GR-provided GRC
>> blocks (whether XML or YML). Guessing you're using some reasonably recently
>> (e.g., 2019) GR 3.8-tech-preview commit. If that's the case, then here's
>> what seems to be the issue ... In this commit <
>> https://github.com/gnuradio/gnuradio/commit/4804d1fdb6950d2b2ec5707cd8a362f01ed2cf90
>>  >,
>> then file "gr-uhd/grc/gen_uhd_usrp_blocks.py" was dramatically changed to
>> generate the YML required by the 3.8 GRC. The API for
>> "set_auto_dc_offset" was removed entirely ... not sure why ... but somehow
>> GRC when "compiling" the flowgraph from YML into Python generates that
>> command improperly.
>>
>> You said you used PyBOMBS to install everything ... yes? The UHD is the
>> current GIT master, so bleeding edge LOL.
>>
>> Any way you can figure out which commit of GNU Radio and gr-ieee-80211
>> were used? The latter was recently updated such that the GIT master
>> corresponds to GR 3.8, while "main-3.7" is for the current GR "maint-3.7"
>> branch ... - MLD
>>
>> On Thu, Jun 27, 2019, at 12:59 PM, sumit kumar wrote:
>>
>> Sure I will try that, meanwhile any tip on the other issue, i.e.,
>>
>> *TypeError: in method 'usrp_source_sptr_set_auto_dc_offset', argument 2
>> of type 'bool'*
>>
>> Regards
>> Sumit
>>
>>
>>
>
> --
> Sumit Kumar
>
>
>

-- 
Sumit Kumar
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-ieee-80211: UDP Warning and another error

[sumit kumar]

Its overwhelming :D, I have a demo on Monday and I was 100% assured
gr-ieee-80211 will work as usual.

Before I saw your mail, I already checked out GR to 3.7.12, UHD to 003 009
006 and compiling now.
Yes I used pybombs for installation.

I have a USB with gnuradio installed into it. It works good and it has GR
3.7.11, uhd 003 009 006 and gr-ieee-80211 version I dint check.



On Thu, 27 Jun 2019 at 19:31, Michael Dickens 
wrote:

> Hmmm ... well the current UHD API for "set_auto_dc_offset" is
> "(bool, size_t)". Looks like the generated Python from gr-ieee-80211 is
> "set_auto_dc_offset("", 0)", which isn't compatible with the current UHD
> API for this method.
>
> Hmmm ... here's my best bet: gr-ieee802-11 uses the GR-provided GRC blocks
> (whether XML or YML). Guessing you're using some reasonably recently (e.g.,
> 2019) GR 3.8-tech-preview commit. If that's the case, then here's what
> seems to be the issue ... In this commit <
> https://github.com/gnuradio/gnuradio/commit/4804d1fdb6950d2b2ec5707cd8a362f01ed2cf90
>  >,
> then file "gr-uhd/grc/gen_uhd_usrp_blocks.py" was dramatically changed to
> generate the YML required by the 3.8 GRC. The API for
> "set_auto_dc_offset" was removed entirely ... not sure why ... but somehow
> GRC when "compiling" the flowgraph from YML into Python generates that
> command improperly.
>
> You said you used PyBOMBS to install everything ... yes? The UHD is the
> current GIT master, so bleeding edge LOL.
>
> Any way you can figure out which commit of GNU Radio and gr-ieee-80211
> were used? The latter was recently updated such that the GIT master
> corresponds to GR 3.8, while "main-3.7" is for the current GR "maint-3.7"
> branch ... - MLD
>
> On Thu, Jun 27, 2019, at 12:59 PM, sumit kumar wrote:
>
> Sure I will try that, meanwhile any tip on the other issue, i.e.,
>
> *TypeError: in method 'usrp_source_sptr_set_auto_dc_offset', argument 2 of
> type 'bool'*
>
> Regards
> Sumit
>
>
>

-- 
Sumit Kumar
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-ieee-80211: UDP Warning and another error

[Michael Dickens]

Hmmm ... well the current UHD API for "set_auto_dc_offset" is "(bool, size_t)". 
Looks like the generated Python from gr-ieee-80211 is "set_auto_dc_offset("", 
0)", which isn't compatible with the current UHD API for this method.

Hmmm ... here's my best bet: gr-ieee802-11 uses the GR-provided GRC blocks 
(whether XML or YML). Guessing you're using some reasonably recently (e.g., 
2019) GR 3.8-tech-preview commit. If that's the case, then here's what seems to 
be the issue ... In this commit < 
https://github.com/gnuradio/gnuradio/commit/4804d1fdb6950d2b2ec5707cd8a362f01ed2cf90
 >, then file "gr-uhd/grc/gen_uhd_usrp_blocks.py" was dramatically changed to 
generate the YML required by the 3.8 GRC. The API for "set_auto_dc_offset" was 
removed entirely ... not sure why ... but somehow GRC when "compiling" the 
flowgraph from YML into Python generates that command improperly.

You said you used PyBOMBS to install everything ... yes? The UHD is the current 
GIT master, so bleeding edge LOL.

Any way you can figure out which commit of GNU Radio and gr-ieee-80211 were 
used? The latter was recently updated such that the GIT master corresponds to 
GR 3.8, while "main-3.7" is for the current GR "maint-3.7" branch ... - MLD

On Thu, Jun 27, 2019, at 12:59 PM, sumit kumar wrote:
> Sure I will try that, meanwhile any tip on the other issue, i.e., 
> 
> *TypeError: in method 'usrp_source_sptr_set_auto_dc_offset', argument 2 of 
> type 'bool'*
> **
> Regards
> Sumit 
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-ieee-80211: UDP Warning and another error

[sumit kumar]

Sure I will try that, meanwhile any tip on the other issue, i.e.,

*TypeError: in method 'usrp_source_sptr_set_auto_dc_offset', argument 2 of
type 'bool'*

Regards
Sumit



On Thu, 27 Jun 2019 at 18:54, Michael Dickens 
wrote:

> I'm no expert on what to change here, but I'd guess there's another
> setting that's the correct one for your specific OS & version, and that
> "net.core.rmem_max" is the correct one for some other OS and/or version.
> Maybe do a quick internet search for how to change the UDP buffer size on
> your OS and version? Maybe someone else in GR-land has seen this issue &
> knows what to do? - MLD
>
> On Thu, Jun 27, 2019, at 12:43 PM, sumit kumar wrote:
>
> This happens after running *sudo sysctl -w net.core.rmem_max=5000*
>
> [INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501;
> UHD_3.15.0.git-1-gf83faf28
> [INFO] [USRP2] Opening a USRP2/N-Series device...
> [INFO] [USRP2] Current recv frame size: 1472 bytes
> [INFO] [USRP2] Current send frame size: 1472 bytes
> [WARNING] [UDP] The recv buffer could not be resized sufficiently.
> Target sock buff size: 5000 bytes.
> Actual sock buff size: 212992 bytes.
> See the transport application notes on buffer resizing.
> Please run: sudo sysctl -w net.core.rmem_max=5000
> [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 recv buffer could not be resized sufficiently.
> Target sock buff size: 5000 bytes.
> Actual sock buff size: 212992 bytes.
> See the transport application notes on buffer resizing.
> Please run: sudo sysctl -w net.core.rmem_max=5000
> [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 recv buffer could not be resized sufficiently.
> Target sock buff size: 250 bytes.
> Actual sock buff size: 212992 bytes.
> See the transport application notes on buffer resizing.
> Please run: sudo sysctl -w net.core.rmem_max=250
> [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 recv buffer could not be resized sufficiently.
> Target sock buff size: 250 bytes.
> Actual sock buff size: 212992 bytes.
> See the transport application notes on buffer resizing.
> Please run: sudo sysctl -w net.core.rmem_max=250
> [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] [UHD] Unable to set the thread priority. Performance may be
> negatively affected.
> Please see the general application notes in the manual for instructions.
> EnvironmentError: OSError: error in pthread_setschedparam
> Traceback (most recent call last):
>   File "/home/sumit/gradio/src/gr-ieee-80211/examples/wifi_rx.py", line
> 374, in 
> main()
>   File "/home/sumit/gradio/src/gr-ieee-80211/examples/wifi_rx.py", line
> 362, in main
> tb = top_block_cls()
>   File "/home/sumit/gradio/src/gr-ieee-80211/examples/wifi_rx.py", line
> 151, in __init__
> self.uhd_usrp_source_0.set_auto_dc_offset("", 0)
>   File
> "/home/sumit/gradio/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
> line 3499, in set_auto_dc_offset
> return _uhd_swig.usrp_source_sptr_set_auto_dc_offset(self, enb, chan)
> TypeError: in method 'usrp_source_sptr_set_auto_dc_offset', argument 2 of
> type 'bool'
>
>
>

-- 
Sumit Kumar
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] ADRV9008-2, Zynq FPGA boards, and gnuradio

[Travis Collins]

Erik,

You can use the generic IIO Device blocks to talk to the ADRV9008/9. The
PHY Device is "adrv9009-phy", Device is "axi-adrv9009-rx-obs-hpc" to get
the observation path, and the channels are voltage0_i and voltage0_q.

In regards to processing data, even on the FPGA fabric 450 MHz is
challenging. I would recommend looking at captured buffers in isolation and
prove that your signal processing is working. Then migrate things to the
FPGA fabric.

If you have more questions please post them on the ADI support forums here:
https://ez.analog.com/

-Travis


On Thu, Jun 27, 2019 at 10:36 AM Müller, Marcus (CEL) 
wrote:

> Hi Erik,
>
> On Thu, 2019-06-27 at 09:19 +, Erik Heinz wrote:
> > Hi Marcus,
> >
> > thank you for clarifying. I already guessed that signal processing in
> the FPGA is required, but I had the hope that we can start with a CPU-only
> setup with limited performance and improve it by FPGA implementations later
> on.
> >
> > Do you have a rough guess what bandwidth a Cortex-A53 ARM on an ZCU102
> board would be able to handle, considered some basic data processing within
> gnuradio?
>
> Puh, that really depends on the kind of processing your basic
> processing is!
> Also, you'd be surprised how much CPU you can spend on getting data
> from devices to userland, so how you'd go about that can have a heavy
> influence.
>
> But: Really no big deal: Simply prototype your whole signal processing
> on a capable PC, identify the bottlenecks, port and test them on the
> FPGA, and test whether what you consider "lightweight" stuff works in
> isolation on a comparable ARM at sufficient rates.
> >
> > This approach, however, would only work if there were some support and
> some hooks within the Linux IIO kernel driver and/or libiio for including
> customer FPGA designs.
>
> I'll go ahead and admit that I don't know IIO well enough to comment on
> this. But: there's certainly folks at analog devices that know! Travis
> would be my go-to person here.
>
> Best regards,
> Marcus
>
> > So far I have not found any hint that such support exists. In this case
> running  gnuradio on the Zync board would be a dead end solution that
> cannot be accelerated easily, and no appropriate approach for the given
> task.
> >
> > Best regards,
> > Erik
> >
> > 
> > Von: Müller, Marcus (CEL) 
> > Gesendet: Dienstag, 25. Juni 2019 13:05
> > An: discuss-gnuradio@gnu.org; Erik Heinz
> > Betreff: Re: [Discuss-gnuradio] ADRV9008-2, Zynq FPGA boards, and
> gnuradio
> >
> > Hi Erik,
> >
> > so, GNU Radio *itself* is purely host-based software; in other words,
> > you'd be processing 100s of MHz on the poor Zynq's ARM (will not even
> > remotely happen).
> >
> > What you'd need is to do the signal processing in the FPGA, for the
> > most significant part. After you've selected your channel and reduced
> > your sampling rate to that, yes, GNU Radio could very well deal with
> > that data (if the ARM CPU is up for that).
> >
> > There's an accelerator framework, that Ettus developed for their Zynq-
> > based products, called RFNoC. That works relatively nicely with GNU
> > Radio. Pretty sure Analog Devices themselves also have libiio-
> > compatible ways of signal (pre)processing on Zynqs, but I'm not
> > knowledgeable about that at all.
> >
> > Which FPGA would fit your bill depends on the kind of signal processing
> > you'd need to do. I'd assume the 7000 series Zynq would be a bit on the
> > limits of its bandwidths dealing with 450 MS/s.
> >
> > Best regards,
> > Marcus
> >
> > On Tue, 2019-06-25 at 10:04 +, Erik Heinz wrote:
> > > Hello everyone,
> > >
> > > we are developing an application where a large bandwidth (some 100 MHz
> at  5–6 GHz mid frequency) needs to be processed to extract a small
> bandwidth
> > > payload signal.
> > >
> > > For rapid prototyping and testing algorithms I am thinking about using
> an ADRV9008-2 evaluation board, a Xilinx Zynq FPGA board, and gnuradio.
> > >
> > > I understand that there do exist ready-made Linux distributions that
> run on boards like the ZC702 (Zynq-7000 based) or ZCU102 (Ultrascale+
> based) and it is possible to run gnuradio on top of it.
> > > I also found some hint that there does exist software to access an
> EVAL-ADRV9008 board connected to the Zync board from within gnuradio.
> > > So I assume in principle it should be possible to process the 450 MHz
> bandwidth from the ADRV9008-2 directly on the Zync board using gnuradio in
> real time.
> > >
> > > Can anyone confirm that this assumption is correct and that such a
> setup could work? Has this be done before?
> > > Would both the ZC702 and the ZCU102 be suitable?
> > > Where should I start reading?
> > >
> > > Lots of questions. Thank you for some answers.
> > > Erik
> > >
> > > ___
> > > Discuss-gnuradio mailing list
> > > Discuss-gnuradio@gnu.org
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
_

Re: [Discuss-gnuradio] gr-ieee-80211: UDP Warning and another error

[Michael Dickens]

I'm no expert on what to change here, but I'd guess there's another setting 
that's the correct one for your specific OS & version, and that 
"net.core.rmem_max" is the correct one for some other OS and/or version. Maybe 
do a quick internet search for how to change the UDP buffer size on your OS and 
version? Maybe someone else in GR-land has seen this issue & knows what to do? 
- MLD

On Thu, Jun 27, 2019, at 12:43 PM, sumit kumar wrote:
> This happens after running *sudo sysctl -w net.core.rmem_max=5000*
> 
> [INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501; 
> UHD_3.15.0.git-1-gf83faf28
> [INFO] [USRP2] Opening a USRP2/N-Series device...
> [INFO] [USRP2] Current recv frame size: 1472 bytes
> [INFO] [USRP2] Current send frame size: 1472 bytes
> [WARNING] [UDP] The recv buffer could not be resized sufficiently.
> Target sock buff size: 5000 bytes.
> Actual sock buff size: 212992 bytes.
> See the transport application notes on buffer resizing.
> Please run: sudo sysctl -w net.core.rmem_max=5000
> [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 recv buffer could not be resized sufficiently.
> Target sock buff size: 5000 bytes.
> Actual sock buff size: 212992 bytes.
> See the transport application notes on buffer resizing.
> Please run: sudo sysctl -w net.core.rmem_max=5000
> [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 recv buffer could not be resized sufficiently.
> Target sock buff size: 250 bytes.
> Actual sock buff size: 212992 bytes.
> See the transport application notes on buffer resizing.
> Please run: sudo sysctl -w net.core.rmem_max=250
> [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 recv buffer could not be resized sufficiently.
> Target sock buff size: 250 bytes.
> Actual sock buff size: 212992 bytes.
> See the transport application notes on buffer resizing.
> Please run: sudo sysctl -w net.core.rmem_max=250
> [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] [UHD] Unable to set the thread priority. Performance may be 
> negatively affected.
> Please see the general application notes in the manual for instructions.
> EnvironmentError: OSError: error in pthread_setschedparam
> Traceback (most recent call last):
>  File "/home/sumit/gradio/src/gr-ieee-80211/examples/wifi_rx.py", line 374, 
> in 
>  main()
>  File "/home/sumit/gradio/src/gr-ieee-80211/examples/wifi_rx.py", line 362, 
> in main
>  tb = top_block_cls()
>  File "/home/sumit/gradio/src/gr-ieee-80211/examples/wifi_rx.py", line 151, 
> in __init__
>  self.uhd_usrp_source_0.set_auto_dc_offset("", 0)
>  File 
> "/home/sumit/gradio/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py", 
> line 3499, in set_auto_dc_offset
>  return _uhd_swig.usrp_source_sptr_set_auto_dc_offset(self, enb, chan)
> TypeError: in method 'usrp_source_sptr_set_auto_dc_offset', argument 2 of 
> type 'bool'
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-ieee-80211: UDP Warning and another error

[sumit kumar]

This happens after running *sudo sysctl -w net.core.rmem_max=5000*

[INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501;
UHD_3.15.0.git-1-gf83faf28
[INFO] [USRP2] Opening a USRP2/N-Series device...
[INFO] [USRP2] Current recv frame size: 1472 bytes
[INFO] [USRP2] Current send frame size: 1472 bytes
[WARNING] [UDP] The recv buffer could not be resized sufficiently.
Target sock buff size: 5000 bytes.
Actual sock buff size: 212992 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.rmem_max=5000
[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 recv buffer could not be resized sufficiently.
Target sock buff size: 5000 bytes.
Actual sock buff size: 212992 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.rmem_max=5000
[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 recv buffer could not be resized sufficiently.
Target sock buff size: 250 bytes.
Actual sock buff size: 212992 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.rmem_max=250
[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 recv buffer could not be resized sufficiently.
Target sock buff size: 250 bytes.
Actual sock buff size: 212992 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.rmem_max=250
[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] [UHD] Unable to set the thread priority. Performance may be
negatively affected.
Please see the general application notes in the manual for instructions.
EnvironmentError: OSError: error in pthread_setschedparam
Traceback (most recent call last):
  File "/home/sumit/gradio/src/gr-ieee-80211/examples/wifi_rx.py", line
374, in 
main()
  File "/home/sumit/gradio/src/gr-ieee-80211/examples/wifi_rx.py", line
362, in main
tb = top_block_cls()
  File "/home/sumit/gradio/src/gr-ieee-80211/examples/wifi_rx.py", line
151, in __init__
self.uhd_usrp_source_0.set_auto_dc_offset("", 0)
  File
"/home/sumit/gradio/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
line 3499, in set_auto_dc_offset
return _uhd_swig.usrp_source_sptr_set_auto_dc_offset(self, enb, chan)
TypeError: in method 'usrp_source_sptr_set_auto_dc_offset', argument 2 of
type 'bool'

On Thu, 27 Jun 2019 at 18:34, sumit kumar  wrote:

> Hi Michael, Yes indeed, tried till  500, still no luck.
>
> Regards
> Sumit
>
> On Thu, 27 Jun 2019 at 18:30, Michael Dickens 
> wrote:
>
>> Hi Sumit - Just out of curiosity, have you tried the command the warning
>> asks you to execute?
>> {{{
>> sudo sysctl -w net.core.wmem_max=250
>> }}}
>> If not then please try it & see if that helps. - MLD
>>
>> On Thu, Jun 27, 2019, at 12:27 PM, sumit kumar wrote:
>>
>> OS: Ubuntu 18.04
>> Laptop: Dell Latitude 5490
>> GNU Radio : 3.7.13.5
>> UHD : UHD_3.15.0.git-1-gf83faf28
>> SDR: Ettus N200
>>
>> I did a fresh install today using pybombs.
>>
>> Then tried running wifi_rx.grc from gr-ieee-80211 package and flooded
>> with errors. Never seen them before. Bold marked part is coming with all
>> the programs where I am connected to USRP such as uhd_fft while the rest
>> happens with wifi_rx.grc (this is what I have observed so far).
>>
>> However, all the programs are working flawlessly with older version.
>>
>> Any tips to solve it.
>>
>> Regards
>> Sumit
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *[INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501;
>> UHD_3.15.0.git-1-gf83faf28[INFO] [USRP2] Opening a USRP2/N-Series
>> device...[INFO] [USRP2] Current recv frame size: 1472 bytes[INFO] [USRP2]
>> Current send frame size: 1472 bytes[WARNING] [UDP] The send buffer could
>> not be resized sufficiently.Target sock buff size: 250 bytes.Actual
>> sock buff size: 212992 bytes.See the transport application notes on buffer
>> resizing.Please run: sudo sysctl -w net.core.wmem_max=250[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 send buffer could not be resized
>> sufficiently.Target sock buff size: 250 bytes.Actual sock buff size:
>> 212992 bytes.See the transport application notes on buffer resizing.Please
>> run: sudo sysctl -w net.core.wmem_max=250[WARNING] [UDP] The current
>> send_buff_size of 212992 is less than the minimum recommended size of
>> 307200 and may 

Re: [Discuss-gnuradio] gr-ieee-80211: UDP Warning and another error

[sumit kumar]

Hi Michael, Yes indeed, tried till  500, still no luck.

Regards
Sumit

On Thu, 27 Jun 2019 at 18:30, Michael Dickens 
wrote:

> Hi Sumit - Just out of curiosity, have you tried the command the warning
> asks you to execute?
> {{{
> sudo sysctl -w net.core.wmem_max=250
> }}}
> If not then please try it & see if that helps. - MLD
>
> On Thu, Jun 27, 2019, at 12:27 PM, sumit kumar wrote:
>
> OS: Ubuntu 18.04
> Laptop: Dell Latitude 5490
> GNU Radio : 3.7.13.5
> UHD : UHD_3.15.0.git-1-gf83faf28
> SDR: Ettus N200
>
> I did a fresh install today using pybombs.
>
> Then tried running wifi_rx.grc from gr-ieee-80211 package and flooded with
> errors. Never seen them before. Bold marked part is coming with all the
> programs where I am connected to USRP such as uhd_fft while the rest
> happens with wifi_rx.grc (this is what I have observed so far).
>
> However, all the programs are working flawlessly with older version.
>
> Any tips to solve it.
>
> Regards
> Sumit
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *[INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501;
> UHD_3.15.0.git-1-gf83faf28[INFO] [USRP2] Opening a USRP2/N-Series
> device...[INFO] [USRP2] Current recv frame size: 1472 bytes[INFO] [USRP2]
> Current send frame size: 1472 bytes[WARNING] [UDP] The send buffer could
> not be resized sufficiently.Target sock buff size: 250 bytes.Actual
> sock buff size: 212992 bytes.See the transport application notes on buffer
> resizing.Please run: sudo sysctl -w net.core.wmem_max=250[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 send buffer could not be resized
> sufficiently.Target sock buff size: 250 bytes.Actual sock buff size:
> 212992 bytes.See the transport application notes on buffer resizing.Please
> run: sudo sysctl -w net.core.wmem_max=250[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
> send buffer could not be resized sufficiently.Target sock buff size:
> 1048576 bytes.Actual sock buff size: 212992 bytes.See the transport
> application notes on buffer resizing.Please run: sudo sysctl -w
> net.core.wmem_max=1048576[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 send buffer could not be
> resized sufficiently.Target sock buff size: 250 bytes.Actual sock buff
> size: 212992 bytes.See the transport application notes on buffer
> resizing.Please run: sudo sysctl -w net.core.wmem_max=250[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] [UHD] Unable to set the thread priority. Performance may be
> negatively affected.Please see the general application notes in the manual
> for instructions.EnvironmentError: OSError: error in pthread_setschedparam*
>
> Traceback (most recent call last):
>   File "/home/sumit/gradio/src/gr-ieee-80211/examples/wifi_rx.py", line
> 374, in 
> main()
>   File "/home/sumit/gradio/src/gr-ieee-80211/examples/wifi_rx.py", line
> 362, in main
> tb = top_block_cls()
>   File "/home/sumit/gradio/src/gr-ieee-80211/examples/wifi_rx.py", line
> 151, in __init__
> self.uhd_usrp_source_0.set_auto_dc_offset("false", 0)
>   File
> "/home/sumit/gradio/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
> line 3499, in set_auto_dc_offset
> return _uhd_swig.usrp_source_sptr_set_auto_dc_offset(self, enb, chan)
> TypeError: in method 'usrp_source_sptr_set_auto_dc_offset', argument 2 of
> type 'bool'
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>

-- 
Sumit Kumar
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-ieee-80211: UDP Warning and another error

[Michael Dickens]

Hi Sumit - Just out of curiosity, have you tried the command the warning asks 
you to execute?
{{{
sudo sysctl -w net.core.wmem_max=250
}}}
If not then please try it & see if that helps. - MLD

On Thu, Jun 27, 2019, at 12:27 PM, sumit kumar wrote:
> OS: Ubuntu 18.04
> Laptop: Dell Latitude 5490
> GNU Radio : 3.7.13.5
> UHD : UHD_3.15.0.git-1-gf83faf28
> SDR: Ettus N200
> 
> I did a fresh install today using pybombs. 
> 
> Then tried running wifi_rx.grc from gr-ieee-80211 package and flooded with 
> errors. Never seen them before. Bold marked part is coming with all the 
> programs where I am connected to USRP such as uhd_fft while the rest happens 
> with wifi_rx.grc (this is what I have observed so far).
> 
> However, all the programs are working flawlessly with older version.
> 
> Any tips to solve it.
> 
> Regards
> Sumit 
> 
> *[INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501; 
> UHD_3.15.0.git-1-gf83faf28
> [INFO] [USRP2] Opening a USRP2/N-Series device...
> [INFO] [USRP2] Current recv frame size: 1472 bytes
> [INFO] [USRP2] Current send frame size: 1472 bytes
> [WARNING] [UDP] The send buffer could not be resized sufficiently.
> Target sock buff size: 250 bytes.
> Actual sock buff size: 212992 bytes.
> See the transport application notes on buffer resizing.
> Please run: sudo sysctl -w net.core.wmem_max=250
> [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 send buffer could not be resized sufficiently.
> Target sock buff size: 250 bytes.
> Actual sock buff size: 212992 bytes.
> See the transport application notes on buffer resizing.
> Please run: sudo sysctl -w net.core.wmem_max=250
> [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 send buffer could not be resized sufficiently.
> Target sock buff size: 1048576 bytes.
> Actual sock buff size: 212992 bytes.
> See the transport application notes on buffer resizing.
> Please run: sudo sysctl -w net.core.wmem_max=1048576
> [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 send buffer could not be resized sufficiently.
> Target sock buff size: 250 bytes.
> Actual sock buff size: 212992 bytes.
> See the transport application notes on buffer resizing.
> Please run: sudo sysctl -w net.core.wmem_max=250
> [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] [UHD] Unable to set the thread priority. Performance may be 
> negatively affected.
> Please see the general application notes in the manual for instructions.
> EnvironmentError: OSError: error in pthread_setschedparam*
> *
*Traceback (most recent call last):
>  File "/home/sumit/gradio/src/gr-ieee-80211/examples/wifi_rx.py", line 374, 
> in 
>  main()
>  File "/home/sumit/gradio/src/gr-ieee-80211/examples/wifi_rx.py", line 362, 
> in main
>  tb = top_block_cls()
>  File "/home/sumit/gradio/src/gr-ieee-80211/examples/wifi_rx.py", line 151, 
> in __init__
>  self.uhd_usrp_source_0.set_auto_dc_offset("false", 0)
>  File 
> "/home/sumit/gradio/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py", 
> line 3499, in set_auto_dc_offset
>  return _uhd_swig.usrp_source_sptr_set_auto_dc_offset(self, enb, chan)
> TypeError: in method 'usrp_source_sptr_set_auto_dc_offset', argument 2 of 
> type 'bool'
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] gr-ieee-80211: UDP Warning and another error

[sumit kumar]

OS: Ubuntu 18.04
Laptop: Dell Latitude 5490
GNU Radio : 3.7.13.5
UHD : UHD_3.15.0.git-1-gf83faf28
SDR: Ettus N200

I did a fresh install today using pybombs.

Then tried running wifi_rx.grc from gr-ieee-80211 package and flooded with
errors. Never seen them before. Bold marked part is coming with all the
programs where I am connected to USRP such as uhd_fft while the rest
happens with wifi_rx.grc (this is what I have observed so far).

However, all the programs are working flawlessly with older version.

Any tips to solve it.

Regards
Sumit































*[INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501;
UHD_3.15.0.git-1-gf83faf28[INFO] [USRP2] Opening a USRP2/N-Series
device...[INFO] [USRP2] Current recv frame size: 1472 bytes[INFO] [USRP2]
Current send frame size: 1472 bytes[WARNING] [UDP] The send buffer could
not be resized sufficiently.Target sock buff size: 250 bytes.Actual
sock buff size: 212992 bytes.See the transport application notes on buffer
resizing.Please run: sudo sysctl -w net.core.wmem_max=250[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 send buffer could not be resized
sufficiently.Target sock buff size: 250 bytes.Actual sock buff size:
212992 bytes.See the transport application notes on buffer resizing.Please
run: sudo sysctl -w net.core.wmem_max=250[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
send buffer could not be resized sufficiently.Target sock buff size:
1048576 bytes.Actual sock buff size: 212992 bytes.See the transport
application notes on buffer resizing.Please run: sudo sysctl -w
net.core.wmem_max=1048576[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 send buffer could not be
resized sufficiently.Target sock buff size: 250 bytes.Actual sock buff
size: 212992 bytes.See the transport application notes on buffer
resizing.Please run: sudo sysctl -w net.core.wmem_max=250[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] [UHD] Unable to set the thread priority. Performance may be
negatively affected.Please see the general application notes in the manual
for instructions.EnvironmentError: OSError: error in pthread_setschedparam*

Traceback (most recent call last):
  File "/home/sumit/gradio/src/gr-ieee-80211/examples/wifi_rx.py", line
374, in 
main()
  File "/home/sumit/gradio/src/gr-ieee-80211/examples/wifi_rx.py", line
362, in main
tb = top_block_cls()
  File "/home/sumit/gradio/src/gr-ieee-80211/examples/wifi_rx.py", line
151, in __init__
self.uhd_usrp_source_0.set_auto_dc_offset("false", 0)
  File
"/home/sumit/gradio/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
line 3499, in set_auto_dc_offset
return _uhd_swig.usrp_source_sptr_set_auto_dc_offset(self, enb, chan)
TypeError: in method 'usrp_source_sptr_set_auto_dc_offset', argument 2 of
type 'bool'
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Inexpensive Digital RF Signal Generator

[Kyeong Su Shin]

Hello Cliff:


If you really want to keep the price low, you can get a Raspberry Pi 
(https://github.com/F5OEO/rpitx ) or a  FL2k ( 
https://osmocom.org/projects/osmo-fl2k/wiki ) which Marcus suggested. The 
problem is that these devices generate a _lot_ of harmonics (that is why you 
can use them as RF transmitters, even without adding additional LOs and mixers 
to the frontend), so you will have to add your own filters or prevent the 
signals from getting out from your house (or you will end up annoying FCC). 
Maybe you can put them inside of a microwave (I haven't thought about it much, 
so please do not believe me re. this).



Regards,

Kyeong Su Shin





보낸 사람: cliff palmer  대신 Discuss-gnuradio 

보낸 날짜: 2019년 6월 27일 목요일 오후 6:32:25
받는 사람: discuss-gnuradio@gnu.org
제목: Re: [Discuss-gnuradio] Inexpensive Digital RF Signal Generator

Thanks for both suggestions.  Both recommended solutions are great hardware, 
but at those prices I may as well buy another HackRF One.

On Thu, Jun 27, 2019 at 4:41 AM Jonas Manthey 
mailto:jonas.mant...@u-blox.com>> wrote:

Hi Cliff,



You don’t specify your bandwidth requirements but you might want to have a look 
at the ADALM-PLUTO SDR: 
https://www.analog.com/en/design-center/evaluation-hardware-and-software/evaluation-boards-kits/adalm-pluto.html

It does not fully match your requirements, however I am not aware of an SDR 
that can transmit and costs less than 50$. If you strip away the transmit 
requirements, the rtl-sdr is perfect for your needs: 
https://www.rtl-sdr.com/buy-rtl-sdr-dvb-t-dongles/

Maybe you can use this and an inexpensive arbitrary waveform generator?



Cheers,

Jonas



From: Discuss-gnuradio 
[mailto:discuss-gnuradio-bounces+jonas.manthey=u-blox@gnu.org]
 On Behalf Of cliff palmer
Sent: Mittwoch, 26. Juni 2019 15:15
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] Inexpensive Digital RF Signal Generator



I'd like to buy/build an inexpensive digital RF signal generator for testing RF 
scan/capture projects.  I want something that

- generates a digital pattern I specify (512 - 32k bits)

- on a frequency I select (somewhere in the 100M - 500M range but the range of 
frequencies can be much narrower)

- is entirely legal to operate in the US (I don't mind registering it with the 
FCC)

- is simple enough that a newcomer to RF signal processing/SDR can make it work 
without pestering this fine list with dozens of questions

- is controllable using software running on a linux or windows workstation 
connected via USB (JTAG is fine)

- is inexpensive (read US$50 or less, or $100 or less if it makes coffee and 
performs light housekeeping)

- is safe to operate (no breadboard layouts, and something you would let your 
grandchildren touch)

- is powered by USB connection to a monitor, workstation or power adapter and 
the power connection on the Signal Generator can be USB, barrel connector, or 
any other standard connection

And with all that, I am indifferent on color, form factor, brand name and such.

Thanks in advance

Cliff
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Inexpensive Digital RF Signal Generator

[CEL]

You **Really** have steep pricing ideas :) Anyway, 
https://osmocom.org/projects/osmo-fl2k/wiki

On Thu, 2019-06-27 at 05:32 -0400, cliff palmer wrote:
> Thanks for both suggestions.  Both recommended solutions are great hardware, 
> but at those prices I may as well buy another HackRF One.
> 
> On Thu, Jun 27, 2019 at 4:41 AM Jonas Manthey  
> wrote:
> > Hi Cliff,
> >  
> > You don’t specify your bandwidth requirements but you might want to have a 
> > look at the ADALM-PLUTO SDR: 
> > https://www.analog.com/en/design-center/evaluation-hardware-and-software/evaluation-boards-kits/adalm-pluto.html
> > It does not fully match your requirements, however I am not aware of an SDR 
> > that can transmit and costs less than 50$. If you strip away the transmit 
> > requirements, the rtl-sdr is perfect for your needs: 
> > https://www.rtl-sdr.com/buy-rtl-sdr-dvb-t-dongles/
> > Maybe you can use this and an inexpensive arbitrary waveform generator?
> >  
> > Cheers,
> > Jonas
> >  
> > From: Discuss-gnuradio 
> > [mailto:discuss-gnuradio-bounces+jonas.manthey=u-blox@gnu.org] On 
> > Behalf Of cliff palmer
> > Sent: Mittwoch, 26. Juni 2019 15:15
> > To: discuss-gnuradio@gnu.org
> > Subject: [Discuss-gnuradio] Inexpensive Digital RF Signal Generator
> >  
> > I'd like to buy/build an inexpensive digital RF signal generator for 
> > testing RF scan/capture projects.  I want something that 
> > - generates a digital pattern I specify (512 - 32k bits)
> > - on a frequency I select (somewhere in the 100M - 500M range but the range 
> > of frequencies can be much narrower)
> > - is entirely legal to operate in the US (I don't mind registering it with 
> > the FCC)
> > - is simple enough that a newcomer to RF signal processing/SDR can make it 
> > work without pestering this fine list with dozens of questions
> > - is controllable using software running on a linux or windows workstation 
> > connected via USB (JTAG is fine)
> > - is inexpensive (read US$50 or less, or $100 or less if it makes coffee 
> > and performs light housekeeping)
> > - is safe to operate (no breadboard layouts, and something you would let 
> > your grandchildren touch)
> > - is powered by USB connection to a monitor, workstation or power adapter 
> > and the power connection on the Signal Generator can be USB, barrel 
> > connector, or any other standard connection
> > And with all that, I am indifferent on color, form factor, brand name and 
> > such.
> > Thanks in advance
> > Cliff
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] ADRV9008-2, Zynq FPGA boards, and gnuradio

[CEL]

Hi Erik,

On Thu, 2019-06-27 at 09:19 +, Erik Heinz wrote:
> Hi Marcus,
> 
> thank you for clarifying. I already guessed that signal processing in the 
> FPGA is required, but I had the hope that we can start with a CPU-only setup 
> with limited performance and improve it by FPGA implementations later on.
> 
> Do you have a rough guess what bandwidth a Cortex-A53 ARM on an ZCU102 board 
> would be able to handle, considered some basic data processing within 
> gnuradio?

Puh, that really depends on the kind of processing your basic
processing is!
Also, you'd be surprised how much CPU you can spend on getting data
from devices to userland, so how you'd go about that can have a heavy
influence.

But: Really no big deal: Simply prototype your whole signal processing
on a capable PC, identify the bottlenecks, port and test them on the
FPGA, and test whether what you consider "lightweight" stuff works in
isolation on a comparable ARM at sufficient rates.
> 
> This approach, however, would only work if there were some support and some 
> hooks within the Linux IIO kernel driver and/or libiio for including customer 
> FPGA designs.

I'll go ahead and admit that I don't know IIO well enough to comment on
this. But: there's certainly folks at analog devices that know! Travis
would be my go-to person here.

Best regards,
Marcus

> So far I have not found any hint that such support exists. In this case 
> running  gnuradio on the Zync board would be a dead end solution that cannot 
> be accelerated easily, and no appropriate approach for the given task.
> 
> Best regards,
> Erik
> 
> 
> Von: Müller, Marcus (CEL) 
> Gesendet: Dienstag, 25. Juni 2019 13:05
> An: discuss-gnuradio@gnu.org; Erik Heinz
> Betreff: Re: [Discuss-gnuradio] ADRV9008-2, Zynq FPGA boards, and gnuradio
> 
> Hi Erik,
> 
> so, GNU Radio *itself* is purely host-based software; in other words,
> you'd be processing 100s of MHz on the poor Zynq's ARM (will not even
> remotely happen).
> 
> What you'd need is to do the signal processing in the FPGA, for the
> most significant part. After you've selected your channel and reduced
> your sampling rate to that, yes, GNU Radio could very well deal with
> that data (if the ARM CPU is up for that).
> 
> There's an accelerator framework, that Ettus developed for their Zynq-
> based products, called RFNoC. That works relatively nicely with GNU
> Radio. Pretty sure Analog Devices themselves also have libiio-
> compatible ways of signal (pre)processing on Zynqs, but I'm not
> knowledgeable about that at all.
> 
> Which FPGA would fit your bill depends on the kind of signal processing
> you'd need to do. I'd assume the 7000 series Zynq would be a bit on the
> limits of its bandwidths dealing with 450 MS/s.
> 
> Best regards,
> Marcus
> 
> On Tue, 2019-06-25 at 10:04 +, Erik Heinz wrote:
> > Hello everyone,
> > 
> > we are developing an application where a large bandwidth (some 100 MHz at  
> > 5–6 GHz mid frequency) needs to be processed to extract a small bandwidth
> > payload signal.
> > 
> > For rapid prototyping and testing algorithms I am thinking about using an 
> > ADRV9008-2 evaluation board, a Xilinx Zynq FPGA board, and gnuradio.
> > 
> > I understand that there do exist ready-made Linux distributions that run on 
> > boards like the ZC702 (Zynq-7000 based) or ZCU102 (Ultrascale+ based) and 
> > it is possible to run gnuradio on top of it.
> > I also found some hint that there does exist software to access an 
> > EVAL-ADRV9008 board connected to the Zync board from within gnuradio.
> > So I assume in principle it should be possible to process the 450 MHz 
> > bandwidth from the ADRV9008-2 directly on the Zync board using gnuradio in 
> > real time.
> > 
> > Can anyone confirm that this assumption is correct and that such a setup 
> > could work? Has this be done before?
> > Would both the ZC702 and the ZCU102 be suitable?
> > Where should I start reading?
> > 
> > Lots of questions. Thank you for some answers.
> > Erik
> > 
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] UDP to burst transmitter

[krono86]

  Hi guys!
I want to realize a gr flowgraph that transmit a burst of
samples whenever an UDP packet arrives.
I the last few days I created an
out-of-tree block that generates the burst, starting from an input
string.
An external process produces the input string asynchronuously
(very low frequency, about 2 Hz), but my custom gr block output
continuously!
How could I realize this type of burst transmission?
Thank
you.

Ivan

--

by krono86 ...e vada come vuole, un uomo non puo che
morire una sola volta http://www.krono86.netsons.org  



Con OpenStar hai Giga, SMS e i minuti che vuoi da 4,99€ al mese, per sempre. 
Cambi gratis quando e come vuoi e in più hai 6 mesi di INFINTY! 
http://tisca.li/myopen

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Inexpensive Digital RF Signal Generator

[cliff palmer]

Thanks for both suggestions.  Both recommended solutions are great
hardware, but at those prices I may as well buy another HackRF One.

On Thu, Jun 27, 2019 at 4:41 AM Jonas Manthey 
wrote:

> Hi Cliff,
>
>
>
> You don’t specify your bandwidth requirements but you might want to have a
> look at the ADALM-PLUTO SDR:
> https://www.analog.com/en/design-center/evaluation-hardware-and-software/evaluation-boards-kits/adalm-pluto.html
>
> It does not fully match your requirements, however I am not aware of an
> SDR that can transmit and costs less than 50$. If you strip away the
> transmit requirements, the rtl-sdr is perfect for your needs:
> https://www.rtl-sdr.com/buy-rtl-sdr-dvb-t-dongles/
>
> Maybe you can use this and an inexpensive arbitrary waveform generator?
>
>
>
> Cheers,
>
> Jonas
>
>
>
> *From:* Discuss-gnuradio [mailto:discuss-gnuradio-bounces+jonas.manthey=
> u-blox@gnu.org] *On Behalf Of *cliff palmer
> *Sent:* Mittwoch, 26. Juni 2019 15:15
> *To:* discuss-gnuradio@gnu.org
> *Subject:* [Discuss-gnuradio] Inexpensive Digital RF Signal Generator
>
>
>
> I'd like to buy/build an inexpensive digital RF signal generator for
> testing RF scan/capture projects.  I want something that
>
> - generates a digital pattern I specify (512 - 32k bits)
>
> - on a frequency I select (somewhere in the 100M - 500M range but the
> range of frequencies can be much narrower)
>
> - is entirely legal to operate in the US (I don't mind registering it with
> the FCC)
>
> - is simple enough that a newcomer to RF signal processing/SDR can make it
> work without pestering this fine list with dozens of questions
>
> - is controllable using software running on a linux or windows workstation
> connected via USB (JTAG is fine)
>
> - is inexpensive (read US$50 or less, or $100 or less if it makes coffee
> and performs light housekeeping)
>
> - is safe to operate (no breadboard layouts, and something you would let
> your grandchildren touch)
>
> - is powered by USB connection to a monitor, workstation or power adapter
> and the power connection on the Signal Generator can be USB, barrel
> connector, or any other standard connection
>
> And with all that, I am indifferent on color, form factor, brand name and
> such.
>
> Thanks in advance
>
> Cliff
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] ADRV9008-2, Zynq FPGA boards, and gnuradio

[Erik Heinz]

Hi Marcus,

thank you for clarifying. I already guessed that signal processing in the FPGA 
is required, but I had the hope that we can start with a CPU-only setup with 
limited performance and improve it by FPGA implementations later on.

Do you have a rough guess what bandwidth a Cortex-A53 ARM on an ZCU102 board 
would be able to handle, considered some basic data processing within gnuradio?

This approach, however, would only work if there were some support and some 
hooks within the Linux IIO kernel driver and/or libiio for including customer 
FPGA designs. So far I have not found any hint that such support exists. In 
this case running  gnuradio on the Zync board would be a dead end solution that 
cannot be accelerated easily, and no appropriate approach for the given task.

Best regards,
Erik


Von: Müller, Marcus (CEL) 
Gesendet: Dienstag, 25. Juni 2019 13:05
An: discuss-gnuradio@gnu.org; Erik Heinz
Betreff: Re: [Discuss-gnuradio] ADRV9008-2, Zynq FPGA boards, and gnuradio

Hi Erik,

so, GNU Radio *itself* is purely host-based software; in other words,
you'd be processing 100s of MHz on the poor Zynq's ARM (will not even
remotely happen).

What you'd need is to do the signal processing in the FPGA, for the
most significant part. After you've selected your channel and reduced
your sampling rate to that, yes, GNU Radio could very well deal with
that data (if the ARM CPU is up for that).

There's an accelerator framework, that Ettus developed for their Zynq-
based products, called RFNoC. That works relatively nicely with GNU
Radio. Pretty sure Analog Devices themselves also have libiio-
compatible ways of signal (pre)processing on Zynqs, but I'm not
knowledgeable about that at all.

Which FPGA would fit your bill depends on the kind of signal processing
you'd need to do. I'd assume the 7000 series Zynq would be a bit on the
limits of its bandwidths dealing with 450 MS/s.

Best regards,
Marcus

On Tue, 2019-06-25 at 10:04 +, Erik Heinz wrote:
> Hello everyone,
>
> we are developing an application where a large bandwidth (some 100 MHz at  
> 5–6 GHz mid frequency) needs to be processed to extract a small bandwidth
> payload signal.
>
> For rapid prototyping and testing algorithms I am thinking about using an 
> ADRV9008-2 evaluation board, a Xilinx Zynq FPGA board, and gnuradio.
>
> I understand that there do exist ready-made Linux distributions that run on 
> boards like the ZC702 (Zynq-7000 based) or ZCU102 (Ultrascale+ based) and it 
> is possible to run gnuradio on top of it.
> I also found some hint that there does exist software to access an 
> EVAL-ADRV9008 board connected to the Zync board from within gnuradio.
> So I assume in principle it should be possible to process the 450 MHz 
> bandwidth from the ADRV9008-2 directly on the Zync board using gnuradio in 
> real time.
>
> Can anyone confirm that this assumption is correct and that such a setup 
> could work? Has this be done before?
> Would both the ZC702 and the ZCU102 be suitable?
> Where should I start reading?
>
> Lots of questions. Thank you for some answers.
> Erik
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Inexpensive Digital RF Signal Generator

[Jonas Manthey]

Hi Cliff,

You don’t specify your bandwidth requirements but you might want to have a look 
at the ADALM-PLUTO SDR: 
https://www.analog.com/en/design-center/evaluation-hardware-and-software/evaluation-boards-kits/adalm-pluto.html
It does not fully match your requirements, however I am not aware of an SDR 
that can transmit and costs less than 50$. If you strip away the transmit 
requirements, the rtl-sdr is perfect for your needs: 
https://www.rtl-sdr.com/buy-rtl-sdr-dvb-t-dongles/
Maybe you can use this and an inexpensive arbitrary waveform generator?

Cheers,
Jonas

From: Discuss-gnuradio 
[mailto:discuss-gnuradio-bounces+jonas.manthey=u-blox@gnu.org] On Behalf Of 
cliff palmer
Sent: Mittwoch, 26. Juni 2019 15:15
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] Inexpensive Digital RF Signal Generator

I'd like to buy/build an inexpensive digital RF signal generator for testing RF 
scan/capture projects.  I want something that
- generates a digital pattern I specify (512 - 32k bits)
- on a frequency I select (somewhere in the 100M - 500M range but the range of 
frequencies can be much narrower)
- is entirely legal to operate in the US (I don't mind registering it with the 
FCC)
- is simple enough that a newcomer to RF signal processing/SDR can make it work 
without pestering this fine list with dozens of questions
- is controllable using software running on a linux or windows workstation 
connected via USB (JTAG is fine)
- is inexpensive (read US$50 or less, or $100 or less if it makes coffee and 
performs light housekeeping)
- is safe to operate (no breadboard layouts, and something you would let your 
grandchildren touch)
- is powered by USB connection to a monitor, workstation or power adapter and 
the power connection on the Signal Generator can be USB, barrel connector, or 
any other standard connection
And with all that, I am indifferent on color, form factor, brand name and such.
Thanks in advance
Cliff
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio