Re: Conda installation on Windows broken, both minconda & radioconda installer (Was: Please help out a new guy)

[Dave Borch]

Ryan,
You nailed it!  I uninstalled the Pothos SDR environment and when I
reinstalled radioconda I noticed that the installation reset the
Pothos registry settings.  That fixed it.
I really appreciate your help.
Best regards,
Dave

On Thu, Feb 29, 2024 at 12:06 PM Ryan Volz  wrote:
>
> Hi Dave,
>
> I see you've found the relevant GitHub issue for this:
> https://github.com/ryanvolz/radioconda/issues/78
>
> It's still unclear to me exactly what is going wrong here, but it is
> certainly some form of having multiple versions of a library on your
> system (probably Qt, probably installed with other software) and those
> conflicting with each other. Conda environments try to isolate these
> things, but clearly it doesn't always work. Windows, in particular, is
> harder with how it handles DLLs.
>
> The best advice I can give is to try uninstalling other software that
> might make use of Qt.
>
> I won't have a lot of time over the next month to look into this
> further, so sorry ahead of time. It's a high priority issue though that
> I plan on tackling further at some point. Maybe someone else who can
> reproduce can step in and help out until then.
>
> Cheers,
> Ryan
>
> On 2/29/24 9:53 AM, Dave Borch wrote:
> > Marcus,
> > Many thanks for giving it a shot.
> > Best regards,
> > Dave
> >
> > On Thu, Feb 29, 2024 at 9:25 AM Marcus Müller  
> > wrote:
> >>
> >> Good Morning!
> >>
> >> I'm looping the mailing list back in, so that more people can look at it!
> >>
> >> So, this looks generally pretty good; you have exactly one environment. 
> >> But: that might
> >> mean when you said you were using miniforge, you might have installed 
> >> things into the same
> >> environment, so that problems stemming from that might persist.
> >>
> >> Hm; aside from trying to make a new environment, activating it and 
> >> installing GNU Radio in
> >> there, my honest assessment is that I'm out of my conda depth!
> >>
> >> I hope someone else on the list has a clever idea.
> >>
> >> Best regards,
> >> Marcus
> >>
> >> On 29.02.24 14:54, Dave Borch wrote:
> >>> Good morning, Marcus.
> >>> Here is the result of my query:
> >>>
> >>> (base) C:\Users\Dave>conda info --envs
> >>> # conda environments:
> >>> #
> >>> base  *  C:\Users\Dave\radioconda
> >>>
> >>> Does this shed any light on the problem?
> >>> Thanks,
> >>> Dave
> >>>
> >>>
> >>> On Wed, Feb 28, 2024 at 6:24 PM Marcus Müller  
> >>> wrote:
> >>>> Hi Dave,
> >>>>
> >>>> welcome to the GNU Radio community! We certainly try to make it 
> >>>> entry-friendly; and the
> >>>> good news is that the errors you're seeing don't seem to be UNIX-related 
> >>>> :)
> >>>>
> >>>> So, I'd have to guess a lot here, but the error you're describing could 
> >>>> mean there's a
> >>>> wrong version of a library being found – which is supporting, usually 
> >>>> *conda installations
> >>>> are quite self-contained!
> >>>>
> >>>> This is but a stab in the dark, but: Is it possible you set up 
> >>>> radioconda, and used the
> >>>> same conda prefix as you used for miniforge? Don't really understand how 
> >>>> that would break,
> >>>> but it's my best guess for now.
> >>>>
> >>>> Maybe there's multiple conda environments? Does `conda info --envs` say 
> >>>> something to that end?
> >>>>
> >>>> Best regards,
> >>>> Marcus
> >>>>
> >>>> On 27.02.24 22:22, Dave Borch wrote:
> >>>>> Friends,
> >>>>> I'm brand new to Gnu Radio and haven't really used Unix for years. So
> >>>>> please be patient with me here. I loaded Gnu Radio Companion onto my
> >>>>> Windows 10 system and whenever I try to execute a flow graph involving
> >>>>> any of the QT tools I get the following message:
> >>>>>
> >>>>> DLL load failed while importing qtgui_python: The specified procedure
> >>>>> could not be found.
> >>>>>
> >>>>> Listed below are the packages that didn't load properly:
> >>>>>
> >>>>> Failed \Device\HarddiskVolume3\Users\
> >>>>> Dave\radioconda\Library\bin\volk.dll
> >>>>> Failed 
> >>>>> \Device\HarddiskVolume3\Users\Dave\radioconda\Library\bin\Qt5Gui_conda.dll
> >>>>> Failed 
> >>>>> \Device\HarddiskVolume3\Users\Dave\radioconda\Library\bin\Qt5Gui_conda.dll
> >>>>> Failed 
> >>>>> \Device\HarddiskVolume3\Users\Dave\radioconda\Library\bin\icuuc73.dll
> >>>>> Failed 
> >>>>> \Device\HarddiskVolume3\Users\Dave\radioconda\Library\bin\icudt73.dll
> >>>>> Failed 
> >>>>> \Device\HarddiskVolume3\Users\Dave\radioconda\Library\bin\libomp.dll
> >>>>>
> >>>>> I get the same error whether I load radioconda using the radioconda
> >>>>> installer from github or by using miniforge.
> >>>>>
> >>>>> Running Gnu Radio Companion on a laptop, also running Windows 10, I
> >>>>> don't experience this problem. I don't experience the problem on my
> >>>>> Raspberry Pi either.
> >>>>>
> >>>>> I'd be grateful for any help, and please direct me to the appropriate
> >>>>> forum if I'm here in error.
> >>>>>
> >>>>> Thanks,
> >>>>> Dave
> >>>>>
> >

Re: Conda installation on Windows broken, both minconda & radioconda installer (Was: Please help out a new guy)

[Dave Borch]

Marcus,
Many thanks for giving it a shot.
Best regards,
Dave

On Thu, Feb 29, 2024 at 9:25 AM Marcus Müller  wrote:
>
> Good Morning!
>
> I'm looping the mailing list back in, so that more people can look at it!
>
> So, this looks generally pretty good; you have exactly one environment. But: 
> that might
> mean when you said you were using miniforge, you might have installed things 
> into the same
> environment, so that problems stemming from that might persist.
>
> Hm; aside from trying to make a new environment, activating it and installing 
> GNU Radio in
> there, my honest assessment is that I'm out of my conda depth!
>
> I hope someone else on the list has a clever idea.
>
> Best regards,
> Marcus
>
> On 29.02.24 14:54, Dave Borch wrote:
> > Good morning, Marcus.
> > Here is the result of my query:
> >
> > (base) C:\Users\Dave>conda info --envs
> > # conda environments:
> > #
> > base  *  C:\Users\Dave\radioconda
> >
> > Does this shed any light on the problem?
> > Thanks,
> > Dave
> >
> >
> > On Wed, Feb 28, 2024 at 6:24 PM Marcus Müller  
> > wrote:
> >> Hi Dave,
> >>
> >> welcome to the GNU Radio community! We certainly try to make it 
> >> entry-friendly; and the
> >> good news is that the errors you're seeing don't seem to be UNIX-related :)
> >>
> >> So, I'd have to guess a lot here, but the error you're describing could 
> >> mean there's a
> >> wrong version of a library being found – which is supporting, usually 
> >> *conda installations
> >> are quite self-contained!
> >>
> >> This is but a stab in the dark, but: Is it possible you set up radioconda, 
> >> and used the
> >> same conda prefix as you used for miniforge? Don't really understand how 
> >> that would break,
> >> but it's my best guess for now.
> >>
> >> Maybe there's multiple conda environments? Does `conda info --envs` say 
> >> something to that end?
> >>
> >> Best regards,
> >> Marcus
> >>
> >> On 27.02.24 22:22, Dave Borch wrote:
> >>> Friends,
> >>> I'm brand new to Gnu Radio and haven't really used Unix for years. So
> >>> please be patient with me here. I loaded Gnu Radio Companion onto my
> >>> Windows 10 system and whenever I try to execute a flow graph involving
> >>> any of the QT tools I get the following message:
> >>>
> >>> DLL load failed while importing qtgui_python: The specified procedure
> >>> could not be found.
> >>>
> >>> Listed below are the packages that didn't load properly:
> >>>
> >>> Failed \Device\HarddiskVolume3\Users\
> >>> Dave\radioconda\Library\bin\volk.dll
> >>> Failed 
> >>> \Device\HarddiskVolume3\Users\Dave\radioconda\Library\bin\Qt5Gui_conda.dll
> >>> Failed 
> >>> \Device\HarddiskVolume3\Users\Dave\radioconda\Library\bin\Qt5Gui_conda.dll
> >>> Failed 
> >>> \Device\HarddiskVolume3\Users\Dave\radioconda\Library\bin\icuuc73.dll
> >>> Failed 
> >>> \Device\HarddiskVolume3\Users\Dave\radioconda\Library\bin\icudt73.dll
> >>> Failed 
> >>> \Device\HarddiskVolume3\Users\Dave\radioconda\Library\bin\libomp.dll
> >>>
> >>> I get the same error whether I load radioconda using the radioconda
> >>> installer from github or by using miniforge.
> >>>
> >>> Running Gnu Radio Companion on a laptop, also running Windows 10, I
> >>> don't experience this problem. I don't experience the problem on my
> >>> Raspberry Pi either.
> >>>
> >>> I'd be grateful for any help, and please direct me to the appropriate
> >>> forum if I'm here in error.
> >>>
> >>> Thanks,
> >>> Dave
> >>>

Please help out a new guy

[Dave Borch]

Friends,
I'm brand new to Gnu Radio and haven't really used Unix for years. So
please be patient with me here. I loaded Gnu Radio Companion onto my
Windows 10 system and whenever I try to execute a flow graph involving
any of the QT tools I get the following message:

DLL load failed while importing qtgui_python: The specified procedure
could not be found.

Listed below are the packages that didn't load properly:

Failed \Device\HarddiskVolume3\Users\
Dave\radioconda\Library\bin\volk.dll
Failed 
\Device\HarddiskVolume3\Users\Dave\radioconda\Library\bin\Qt5Gui_conda.dll
Failed 
\Device\HarddiskVolume3\Users\Dave\radioconda\Library\bin\Qt5Gui_conda.dll
Failed \Device\HarddiskVolume3\Users\Dave\radioconda\Library\bin\icuuc73.dll
Failed \Device\HarddiskVolume3\Users\Dave\radioconda\Library\bin\icudt73.dll
Failed \Device\HarddiskVolume3\Users\Dave\radioconda\Library\bin\libomp.dll

I get the same error whether I load radioconda using the radioconda
installer from github or by using miniforge.

Running Gnu Radio Companion on a laptop, also running Windows 10, I
don't experience this problem. I don't experience the problem on my
Raspberry Pi either.

I'd be grateful for any help, and please direct me to the appropriate
forum if I'm here in error.

Thanks,
Dave

removing module fails

[Dave Helm]

Hello,

I created a new c++ block called telemetry using gr_modtool.

Now I want to remove it but keep the other blocks I previously created.

So I did gr_modtool rm telemetry.

It did the following based upon git status:

> modified:
> examples/telemetry/__pycache__/python_telemetry_epy_block_0.cpython-38.pyc
> deleted:lib/telemetry_impl.cc
> modified:   python/sidekiq/CMakeLists.txt
> modified:   python/sidekiq/bindings/CMakeLists.txt
> deleted:python/sidekiq/bindings/docstrings/telemetry_pydoc_template.h
> modified:   python/sidekiq/bindings/python_bindings.cc
> deleted:python/sidekiq/bindings/telemetry_python.cc
> deleted:python/sidekiq/qa_telemetry.py
>

Now when I attempt to bind the other two blocks, I get an error.
It seems it still thinks the telemetry block exists and it's trying to bind
it.

>  GNU Radio module name identified: sidekiq

/usr/lib/python3/dist-packages/apport/report.py:13: DeprecationWarning: the
imp module is deprecated in favour of importlib; see the module's
documentation for alternative uses
  import fnmatch, glob, traceback, errno, sys, atexit, locale, imp, stat
Traceback (most recent call last):
  File "/usr/local/bin/gr_modtool", line 18, in 
cli()
  File "/usr/lib/python3/dist-packages/click/core.py", line 764, in __call__
return self.main(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/click/core.py", line 717, in main
rv = self.invoke(ctx)
  File "/usr/lib/python3/dist-packages/click/core.py", line 1137, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/lib/python3/dist-packages/click/core.py", line 956, in invoke
return ctx.invoke(self.callback, **ctx.params)
  File "/usr/lib/python3/dist-packages/click/core.py", line 555, in invoke
return callback(*args, **kwargs)
  File
"/usr/local/lib/python3.8/dist-packages/gnuradio/modtool/cli/base.py", line
135, in wrapper
return func(*args, **kwargs)
  File
"/usr/local/lib/python3.8/dist-packages/gnuradio/modtool/cli/bind.py", line
49, in cli
run(self)
  File
"/usr/local/lib/python3.8/dist-packages/gnuradio/modtool/cli/base.py", line
155, in run
module.run()
  File
"/usr/local/lib/python3.8/dist-packages/gnuradio/modtool/core/bind.py",
line 88, in run
bg.gen_file_binding(file_to_process)
  File
"/usr/local/lib/python3.8/dist-packages/gnuradio/bindtool/core/generator.py",
line 195, in gen_file_binding
parser = GenericHeaderParser(
  File
"/usr/local/lib/python3.8/dist-packages/gnuradio/blocktool/core/parseheader_generic.py",
line 57, in __init__
raise BlockToolException('file', file_path, 'does not exist')
gnuradio.blocktool.core.base.BlockToolException: ('file',
'./include/gnuradio/sidekiq/telemetry.h', 'does not exist')

What can I modify to make sure I can build and run the other blocks?

Thanks,

Dave

Getting undefined symbol

[Dave Helm]

Hello,

I am attempting to create an OOT module called telemetry that receives
messages and does printf() when the message is received.  For now.

I am modeling it after your message_debug block found in gnuradio/blocks

It was working fine till I actually created the message functions.

It compiles and installs fine.  When I run gnuradio_companion no errors.

But when I execute my blocks I get this error:

> Traceback (most recent call last):
>   File "/home/dhelm/gr-sidekiq/examples/telemetry.py", line 34, in 
> from gnuradio import sidekiq
>   File
> "/usr/local/lib/python3.8/dist-packages/gnuradio/sidekiq/__init__.py", line
> 18, in 
> from .sidekiq_python import *
> ImportError: /usr/local/lib/libgnuradio-sidekiq.so.1.0.0: undefined
> symbol: _ZTVN2gr7sidekiq14telemetry_implE
>
> I understand that there is some undefined symbol called, but I can't tell
what it is from the name.  Is there a way to find out?

I ran into this issue when adding my message functions:

The message_debug has functions like:

*void message_debug_impl::print(const pmt::pmt_t& msg)*
*void message_debug_impl::store(const pmt::pmt_t& msg)*

These are defined in the *message_debug_impl.h* file.
But not in the *include/gnuradio/blocks/message_debug.h* file.

When I do that with my functions I get a compile time error that the
functions are not defined.  So I needed to add them to my
*include/gnuradio/sidekiq/telemetry.h* file.
Then I did bind and cmake, make, sudo make install

I compiled and installed it.  But when I actually run the block I get the
error listed above.

Any ideas?

Thanks,

Dave

Re: LDPC Decoder block API change

[Dave Miller]

Thanks Herve for the below clarification on the MIT license and also
clarification on the folks who created AFF3CT,

I just made the needed corrections to the readme files on both
gr-aff3ct_codes and gr-HighDataRate_Modem.

Regards,
Dave

On Wed, Aug 2, 2023 at 2:52 AM  Dear Dave,
>
> Thank you for your work on AFF3CT. I know that Americans like to think
> that what is clever has been invented by them :-) but in this case, AFF3CT
> is not originating from MIT. It is delivered with an MIT open source
> license but has nothing to do with the MIT (as stated on your github). To
> render unto Caesar the things that are Caesar's: it is a library created by
> French collegues and in particular Adrien Cassagne the main architect (see
> https://aff3ct.github.io/contributors.html).
>
> Best regards
>
> Hervé
>
> --
> *De: *"Dave Miller" 
> *À: *Discuss-gnuradio@gnu.org
> *Envoyé: *Mercredi 2 Août 2023 04:54:49
> *Objet: *RE: LDPC Decoder block API change
>
> All,
>
> Since last week below (CCSDS LDPC Rate 1/2 OOT Decoder), I have just also
> added a DVB-S2 Rate 1/2 LDPC decoder and associated Encoder/Decoder
> flowgraph to my gr-aff3ct_codes repository:
>
> 1. For the DVB-S2 Rate 1/2 LDPC Decoder (64800,32400), I again used the
> AFF3CT C++ Library
> 2. For the DVB-S2 Encoder, I used the GNU Radio In-Tree DVB-S2 LDPC
> Encoder block
>
> https://github.com/DavidToddMiller/gr-aff3ct_codes
>
> Regards,
> Dave
>
> --
> *From*: Dave Miller
> *Subject*: RE: LDPC Decoder block API change
> *Date*: Tue, 25 Jul 2023 21:58:50 -0400
> --
> Jeff,
>
> I have implemented a GNU Radio OOT block for a CCSDS rate 1/2 LDPC
> Decoder. I did not even try to use the current GNU Radio In-Tree LDPC
> decoder block because others have noted that the In-Tree LDPC decoder has
> issues:
>
>   1. I used the MIT AFF3CT C++ library as noted on my OOT site for the
> decoder on github: gr-aff3ct_codes
>  - An AFF3CT library approach for a LDPC decoder was also
> noted by Daniel Estevez (gr-satellites) in his Orion/Moon Link
> analyses/articles in late CY2022.
>   2. The AFF3CT C++ library may open up many other decoder options also
> for GNU Radio decoders.
>   3. However, I did use the GNU Radio In-Tree LDPC Encoder Block for my
> CCSDS Rate 1/2 LDPC Encoder.
>
> Regards,
> Dave Miller
>
> 
> --
> *From*: Jeff Long
> *Subject*: LDPC Decoder block API change
> *Date*: Tue, 25 Jul 2023 18:32:26 -0400
> --
> Does anyone use the LDPC Decoder block? PR
> https://github.com/gnuradio/gnuradio/pull/6748 will remove a param,
> changing the API. Normally we wouldn't do this, but best we can tell, the
> block is currently broken and unused.
>
>

RE: LDPC Decoder block API change

[Dave Miller]

All,

Since last week below (CCSDS LDPC Rate 1/2 OOT Decoder), I have just also
added a DVB-S2 Rate 1/2 LDPC decoder and associated Encoder/Decoder
flowgraph to my gr-aff3ct_codes repository:

1. For the DVB-S2 Rate 1/2 LDPC Decoder (64800,32400), I again used the
AFF3CT C++ Library
2. For the DVB-S2 Encoder, I used the GNU Radio In-Tree DVB-S2 LDPC Encoder
block

https://github.com/DavidToddMiller/gr-aff3ct_codes

Regards,
Dave

--
*From*: Dave Miller
*Subject*: RE: LDPC Decoder block API change
*Date*: Tue, 25 Jul 2023 21:58:50 -0400
--
Jeff,

I have implemented a GNU Radio OOT block for a CCSDS rate 1/2 LDPC Decoder.
I did not even try to use the current GNU Radio In-Tree LDPC decoder block
because others have noted that the In-Tree LDPC decoder has issues:

  1. I used the MIT AFF3CT C++ library as noted on my OOT site for the
decoder on github: gr-aff3ct_codes
 - An AFF3CT library approach for a LDPC decoder was also noted
by Daniel Estevez (gr-satellites) in his Orion/Moon Link analyses/articles
in late CY2022.
  2. The AFF3CT C++ library may open up many other decoder options also for
GNU Radio decoders.
  3. However, I did use the GNU Radio In-Tree LDPC Encoder Block for my
CCSDS Rate 1/2 LDPC Encoder.

Regards,
Dave Miller

--
*From*: Jeff Long
*Subject*: LDPC Decoder block API change
*Date*: Tue, 25 Jul 2023 18:32:26 -0400
--
Does anyone use the LDPC Decoder block? PR
https://github.com/gnuradio/gnuradio/pull/6748 will remove a param,
changing the API. Normally we wouldn't do this, but best we can tell, the
block is currently broken and unused.

RE: Using Fractional or Rational resampler to simulate Doppler

[Dave Miller]

Jose,

During my talk at the last GNU Radio Conference (September 2022), I was
asked by an audience member about how to handle Doppler for spacecraft
links so I later developed Transmit/Receive Flowgraphs with Doppler that
are located at:

https://github.com/DavidToddMiller/gr-HighDataRate_Modem

You can find the flowgraphs that include Doppler in the following folder on
the repository site:

“examples/Doppler_And_CCSDS_TTC_Flowgraphs_LowRate”

When running one of the flowgraphs, you will see the Transmit carrier (PM
modulation with a subcarrier) slowly drifting across the Frequency Sink
display in the GUI (about 200-300 Hz per second to simulate typical S-band
link Doppler in Low Earth Orbit). On the receive end of the flowgraph, a
continuous FFT is used to acquire and track the carrier. Generating the
Doppler portion of the flowgraph is done with just standard In-Tree GNU
Radio blocks.

Since the GNU Radio Conference, I have added a lot more to this repository
including Doppler and a lot of codes: CCSDS Reed Solomon, CCSDS
Convolutional, and CCSDS DVB-S2 to test them at high data rates with CPU
multicores. However, the Doppler flowgraphs to which I am pointing you is
low data rate.

Support for a CCSDS rate ½ LDPC Encoder/Decoder is at my other repository,
but it does not include Doppler yet in the flowgraphs (maybe later this
year):

https://github.com/DavidToddMiller/gr-aff3ct_codes


Regards,

Dave Miller




On Thu, Jul 27, 2023 at 4:19 PM Jose Ruvalcaba wrote:

> Hello,
>
> I am trying to simulate an accurate representation of Doppler Shift in a
> channel and I was told that to do this I would have to multiply a complex
> signal with a cosine and implement a resampler block to simulate the signal
> samples that are coming closer or farther away from each other.
>
> My question is this, can I use either the rational resampler or fractional
> resampler block in GNU Radio to dynamically simulate samples moving closer
> or farther than each other?  Or would I need to make my own OOT block to do
> this?
>
> I tried using a QT GUI Range block to change the resampling ratio of a
> fractional resampler but my flowgraph froze.
>
> Any suggestions?
>
> Thanks,
> Jose
>

RE: LDPC Decoder block API change

[Dave Miller]

Jeff,

I have implemented a GNU Radio OOT block for a CCSDS rate 1/2 LDPC Decoder.
I did not even try to use the current GNU Radio In-Tree LDPC decoder block
because others have noted that the In-Tree LDPC decoder has issues:

  1. I used the MIT AFF3CT C++ library as noted on my OOT site for the
decoder on github: gr-aff3ct_codes
 - An AFF3CT library approach for a LDPC decoder was also noted
by Daniel Estevez (gr-satellites) in his Orion/Moon Link analyses/articles
in late CY2022.
  2. The AFF3CT C++ library may open up many other decoder options also for
GNU Radio decoders.
  3. However, I did use the GNU Radio In-Tree LDPC Encoder Block for my
CCSDS Rate 1/2 LDPC Encoder.

Regards,
Dave Miller

--
*From*: Jeff Long
*Subject*: LDPC Decoder block API change
*Date*: Tue, 25 Jul 2023 18:32:26 -0400
--
Does anyone use the LDPC Decoder block? PR
https://github.com/gnuradio/gnuradio/pull/6748 will remove a param,
changing the API. Normally we wouldn't do this, but best we can tell, the
block is currently broken and unused.

Fwd: MIMO with LimeSDR

[Dave Miller]

Hi Evgeny,

A few months ago, I had I believe a similar situation with the LimeSDR-mini
you describe below and show in your attached spectrum plots. Although not a
MIMO configuration.

For me the solution was to not use the gnu radio in-tree modulation blocks
in gnuradio version 3.8 with the LimeSDR sink block.  I used my own
modulator blocks for BPSK and later QPSK with the LimeSDR block.  I sent a
square wave pulse shape baseband signal to the input of the LimeSDR-mini.

The full discussion and solution for this work-around with flowgraphs and
spectrum plots is on a Lime Myriad RF site thread in August that I
established to get some input from the Lime Microsystems folks:
"LimeSDR-Mini GR-3.8 Block Transmit Distortion"

Regards,
Dave




-- Forwarded message -
From: Evgeny Hahamovich
Date: Thu, Oct 28, 2021 at 11:57 AM
Subject: MIMO with LimeSDR
To: 


Hi all,

I am interested in checking the MIMO (well, actually it's SIMO for now)
work mode for my LimeSDR with GNURadio (v.3.8.3.1). Getting into the MIMO
mode was simple by setting RxChannel = A+B, but I got stuck just after
this...

In the attached screenshots you can see the spectrum and constellations I
got for QPSK. As you can see, one of the channels offers terrible
performance :( Have you encountered something similar? This is strange to
me, I didn't expect such a major difference between the 2 channels
performance. Maybe I'm doing something wrong...

Also, can you advise on some blocks I can use for 2 antenas detection to
improve performance or point me to some documentation or examples for using
this mode?

Thank you,
Evgeny

Re: Questions on Polyphase Clock Sync block

[Dave Miller]

George,

No deep reason for the gain block between the Polyphase Clock Sync and the
Costas Loop.  I just used the gain block for my convenience when testing
the flowgraph with an external modulator and different settings to see what
worked best.

Regards,
Dave

On Wed, Mar 10, 2021 at 12:12 PM George Edwards 
wrote:

> Hi Dave,
>
> Thanks again for the help!
>
> I followed your example to set the firdes filter parameters and my GRC
> flowgraph is now working,...Thank you! I must mention an observation, the
> I/Q constellation points after timing synchronization are around +/-0.8 on
> the real and imaginary axes and not +/-1. I know the filter gain scaling
> you use is correct. The gain must be equal to the number of arms in the
> polyphase timing synchronizer and I am using 32 arms like you so I set it
> to 32 (Fred Harris' work makes that clear). At any rate, I am not worried
> about this because I increase filter gain to a value greater than 32 to
> get +/-1 on the I/Q constellation axes.
>
> I have a question for you: Is there a reason why you scaled the values
> leaving the Polyphase Clock Sync before they entered the Costas Loop?
>
> Thanks for the great help!
>
> Regards,
> George
>
> On Tue, Mar 9, 2021 at 4:11 PM Dave Miller 
> wrote:
>
>> George,
>>
>> I would recommend that you start with the below referenced example symbol
>> sync flowgraphs and parameter settings and tutorials first, get them up and
>> running well, and then tweak the symbol sync block settings to your desired
>> parameters/settings for your scenario:
>>
>>- .grc examples: You can find some symbol sync example flowgraphs
>>with gnuradio version 3.8.2 installed on
>>usr/share/gnuradio/examples/digital/demod
>>- GRCon 2019 Slide Presentation: I developed the tutorial
>>presentation at the following link in order to help get others up and
>>running quickly with the Polyphase Clock Sync block including the RRC
>>filter taps. See slides #8 and #10 for the exact parameter settings that
>>may answer your question. It was done in gnu radio version 3.7.11, but the
>>flowgraph and all its parameter settings still work in version 3.8.2.
>>
>>
>> https://www.gnuradio.org/grcon/grcon19/presentations/NASA_Space_Communications_Network_Modem/
>>
>>- GRCon 2020 Presentation Video: Daniel Estevez’s video tutorial uses
>>the other symbol sync block in gnu radio with the Gardner TED selection.
>>You can pause his video at about 1:01:24 with the symbol sync “properties”
>>box open and see all the exact settings.
>>
>> https://www.youtube.com/watch?v=RDbs6l4rMhs
>>
>> You may also want to check your symbol rate frequency offset setting
>> between your modulator and the symbol sync block and verify that the
>> frequency offset is not too large for the loop bandwidth of the symbol sync.
>>
>> Hope the above is useful,
>>
>> Dave
>>
>> _
>>
>> *From*: George Edwards
>> *Subject*: Questions on Polyphase Clock Sync block
>> *Date*: Mon, 8 Mar 2021 16:21:22 -0600
>> --
>> Hello,
>>
>> My goal is symbol timing using the Polyphase Clock Sync block. I
>> generated a QPSK waveform which I input to the Channel Model block with
>> epsilon set to 1.0005 (small signal timing offset) and pass the signal to
>> the  Polyphase Clock Sync. The Polyphase filter is designed to run with 32
>> arms and receive the tap coeff's from the RRC Filter Taps. The parameters
>> for RRC Filter Taps block are are set with defined variables as follows:
>> Gain =1
>> Sample_rate (Hz): sample_rate
>> Symbol_rate (Hz): sample_rate/sps(where sps is samples/symbol and
>>  defined)
>> Excess_BW: excess_bw
>> Num Taps: 32*(sps*6*2)   (designing for overlap of +/-6 symbols
>> with "sps"
>> samples/symbol)
>> 1) When I run the GRC and look at the constellation plot at the output of
>> the Polyphase Clock Sync, all I see is a dot at the origin of the I/Q plot.
>>
>> 2) So I tried changing the number of taps to see if things change and
>> only when I try the number of taps equal to 32*11 do I get something that
>> makes some sense. I get data over the 4 quadrants between +/-.04 +/-0.4j,
>> spread out. Of course, it keeps smearing into one.
>>
>> Will appreciate any suggestions on how to use the Polyphase Clock Sync
>> block in conjunction with the RRC Filter Taps for symbol timing.
>>
>> Thank you!
>>
>> Regards,
>> George
>>
>

RE: Questions on Polyphase Clock Sync block

[Dave Miller]

George,

I would recommend that you start with the below referenced example symbol
sync flowgraphs and parameter settings and tutorials first, get them up and
running well, and then tweak the symbol sync block settings to your desired
parameters/settings for your scenario:

   - .grc examples: You can find some symbol sync example flowgraphs with
   gnuradio version 3.8.2 installed on
   usr/share/gnuradio/examples/digital/demod
   - GRCon 2019 Slide Presentation: I developed the tutorial presentation
   at the following link in order to help get others up and running quickly
   with the Polyphase Clock Sync block including the RRC filter taps. See
   slides #8 and #10 for the exact parameter settings that may answer your
   question. It was done in gnu radio version 3.7.11, but the flowgraph and
   all its parameter settings still work in version 3.8.2.


https://www.gnuradio.org/grcon/grcon19/presentations/NASA_Space_Communications_Network_Modem/

   - GRCon 2020 Presentation Video: Daniel Estevez’s video tutorial uses
   the other symbol sync block in gnu radio with the Gardner TED selection.
   You can pause his video at about 1:01:24 with the symbol sync “properties”
   box open and see all the exact settings.

https://www.youtube.com/watch?v=RDbs6l4rMhs

You may also want to check your symbol rate frequency offset setting
between your modulator and the symbol sync block and verify that the
frequency offset is not too large for the loop bandwidth of the symbol sync.

Hope the above is useful,

Dave

_

*From*: George Edwards
*Subject*: Questions on Polyphase Clock Sync block
*Date*: Mon, 8 Mar 2021 16:21:22 -0600
--
Hello,

My goal is symbol timing using the Polyphase Clock Sync block. I generated
a QPSK waveform which I input to the Channel Model block with epsilon set
to 1.0005 (small signal timing offset) and pass the signal to the
Polyphase Clock Sync. The Polyphase filter is designed to run with 32 arms
and receive the tap coeff's from the RRC Filter Taps. The parameters for
RRC Filter Taps block are are set with defined variables as follows:
Gain =1
Sample_rate (Hz): sample_rate
Symbol_rate (Hz): sample_rate/sps(where sps is samples/symbol and
 defined)
Excess_BW: excess_bw
Num Taps: 32*(sps*6*2)   (designing for overlap of +/-6 symbols
with "sps"
samples/symbol)
1) When I run the GRC and look at the constellation plot at the output of
the Polyphase Clock Sync, all I see is a dot at the origin of the I/Q plot.

2) So I tried changing the number of taps to see if things change and only
when I try the number of taps equal to 32*11 do I get something that makes
some sense. I get data over the 4 quadrants between +/-.04 +/-0.4j, spread
out. Of course, it keeps smearing into one.

Will appreciate any suggestions on how to use the Polyphase Clock Sync
block in conjunction with the RRC Filter Taps for symbol timing.

Thank you!

Regards,
George

Re: [Discuss-gnuradio] 'module' object has no attribute

[Dave NotTelling]

Guy,

 I assume that error is coming from Python.  If that's the case, then
it might be that your Swig build messed up somewhere or the lib and Swig
are not agreeing.  When I get those kinds of errors I will edit the
__init__.py file for the Python module (likely in
/usr/local/lib/python2.7/dist-packages/your_module_name/) and remove the
`pass` for the ImportError and replace with `import traceback;
traceback.print_exc()` to see what's wrong.  It might be that your .so file
isn't being imported properly to Python.  Making that __init__ change and
then running `python -c 'import your_module_name'` should result in seeing
a better error.  If no error happens, then you can also try running `python
-c 'import my_module_name; print dir(your_module_name)` to see if your
module actually has any contents at all.

 Hope that helps!

-Dave

On Mon, Dec 17, 2018 at 5:16 AM Guy Durrieu  wrote:

> Hi,
>
> I am developing some kind of MAC layer within a GNUradio model. Until
> now, my C++ mac module works.
>
> Now I need to add time functionnalities to my module. I include the
> following declarations:
>
> ---
> boost::chrono::system_clock::time_point now =
> boost::chrono::system_clock::now() ;
> boost::chrono::system_clock::time_point nextperiod = now +
> boost::chrono::milliseconds{d_period} ;
> ---
>
> The "make" runs successfully (no compile time errors) but after
> launching gnuradio-companion, when trying to execute the model, I get
> the error
>
> ---
> AttributeError: 'module' object has no attribute 'mac'
> ---
>
> Did somebody experience this kind of error with boost/chrono ? I read in
> the list that it could result from a library access problem, but
> libboost-chrono.so is present in the standard directory
> /usr/lib/x86_64-linux-gnu, so I really don't understand what happens in
> my model...
>
> Thanks in advance for your help !
>
> -- GD.
>
> Guy Durrieu
> ONERA - Département Traitement de l'Information et Systèmes
> CEntRe de Toulouse, 2, avenue Edouard Belin BP 74025 31055 TOULOUSE CEDEX 4
> Tél. +33 5 62 25 26 59
> avertissement http://www.onera.fr/onera-en/emails-terms
>
>
>
>
>
> ___
> 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] Correct GRC version for UHD 3.13.0.1

[Dave NotTelling]

John,

 The issue you are having is that the version of the firmware on your
radio does not match the version of the UHD libraries that you have on your
system.  You need to either update your radios (uhd_image_loader) or change
your version of UHD to match what the radio has.  The former is the better
choice in my opinion.

 I think that you need to add `--init-only` to the uhd_usrp_probe
command to tell if the versions line up.  I seem to recall not getting the
version error without it.

 For the instructions on how to compile UHD from source:
https://files.ettus.com/manual/page_build_guide.html

 Also, for GNU Radio: https://wiki.gnuradio.org/index.php/UbuntuInstall

 You likely don't need to install from source.  As far as I know gr-uhd
just makes use of the system UHD install.  Perhaps you have two different
locations that UHD is installed to?  You could double check that you don't
have libuhd.so in /usr/local/lib and /usr/lib at the same time.  I'd
suggest updating the radios to the current firmware with uhd_image_loader,
power cycling them, and then trying again.

Good luck!

-Dave

On Thu, Sep 20, 2018 at 5:36 PM John_w_g  wrote:

> I am using Ubuntu 18.04 and the only listed GRC version in the ppa is
> version 3.13.0.1
>
> I have an Ettus x310 and have downloaded the correct FPGA image and
> verified correct operation with uhd_usrp_probe.
>
> I have GRC 3.7.11 installed and when I attempt to access the x310, I get
> an incompatible FPGA version.
>
> First question is what is the correct GRC version to work with this UHD
> version?
>
> Second question as a relatively new Linux user, I really don't want to
> compile source code. If that is necessary, where should I look for a
> detailed description of the correct process.
>
> John G
>
>
> Sent from ProtonMail mobile
>
>
> ___
> 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] New to Gnu Radio - Save signal to data for an analysis

[Dave NotTelling]

You should be able to read the output of that command with [1].  Make sure
that you use the --file option before your output file name.  I tried the
command you ran and didn't get any output because I didn't have --file
before the output name.  Maybe a version difference?

By default it seems that the rx_samples_to_file saves samples as SC16
(short complex 16 bit).  I had assumed it would be FC32 which would require
the use of [2] to read.  You can change the output format (CPU format) with
the --type option.  Check the output of --help to see the type options.


[1]
https://github.com/gnuradio/gnuradio/blob/master/gr-utils/octave/read_cshort_binary.m
[2]
https://github.com/gnuradio/gnuradio/blob/master/gr-utils/octave/read_complex_binary.m

On Mon, Jul 9, 2018 at 6:25 AM Wass Mailing  wrote:

> Hello everyone,
>
> I am new on Gnu Radio, and I saw that it was possible to save images of a
> signal, however I would like to recover this signal in the form of data in
> order to carry out a statistical analysis and to see the evolution on a
> frequency wifi on which I circulate traffic and can make comparisons. So
> I wanted to know if it was possible to recover my signal in the form of
> non-binary data file as I do this command below and can analyze them on
> Octave (Matlab). Finally if is it possible to know the architecture of
> the file generated by this command:
>
> ./rx_samples_to_file --freq 2457e6 --rate 1e6 --gain 38.0 --duration 20
> usrp_samples2.dat
>
> Cordially,
>
> --Wassim BERRICHE
> ___
> 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] Remote Control of a Flowgraph

[Dave NotTelling]

If it's just variables that you need to change then you can use the XMLRPC
block.  I've used it in several graphs where I needed up update variables
on the fly.  I'm not sure if the XMLRPC block exposes all variables and
functions in the top block.  I think it's just functions.  The server block
works really easily with Python which is a big win.  Maybe control port
works for the same task?  Haven't really played with it though.

On Wed, Jul 4, 2018 at 3:57 PM mehtap özkan  wrote:

> Dear All,
>  I want to control a Flowgraph remotely from another computer. We have
> found an OOT module called gr-bokeh which is fine for controlling the
> flowgraph from a webpage.
>  Is there another way to control a flowgraph remotely using a stand-alone
> application?
> ___
> 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] GNU Radio not installing: Build Failed

[Dave NotTelling]

Check out the thread titled: install issues with c++11.  I think you two
are having the same issue with PyBombs and C++11

On Thu, Jun 7, 2018 at 10:16 AM Mir Muhammad Lodro 
wrote:

> Hi All
> i am installing GNU Radio on Linux 16.04, but it's not installing by
> saying this file requires compiler and library support for ISO 2011
> standard. This can be done by issuing -std=c++11 or -std=gnu++11  when one
> has to run single file. But here the build process is automated. I would be
> grateful if you can look into the following prompt response and guide what
> could be the possible solution. I have already installed GNU Radio on
> different machine running 16.04, but I am surprise to see the error when
> installing on another machine  and despite repeating the very same steps.
>
> The as it as prompt response is:
>
> root@pezp63763:/home/eexmmlo# pybombs prefix init -a default
> prefix/default/ -R gnuradio-default
> PyBOMBS - INFO - PyBOMBS Version 2.3.2
> PyBOMBS.prefix - WARNING - There already is a prefix in
> `/home/eexmmlo/prefix/default'.
> Continue using this path Y/[N]? y
> Alias `default' already exists, overwrite Y/[N]? y
> PyBOMBS.prefix - INFO - Installing default packages for prefix...
> PyBOMBS.prefix - INFO -
>   - gnuradio
> PyBOMBS.install_manager - INFO - Phase 1: Creating install tree and
> installing binary packages:
> Install tree:
> |
> \- gnuradio
> PyBOMBS.install_manager - INFO - Phase 2: Recursively installing source
> packages to prefix:
> PyBOMBS.install_manager - INFO - Installing package: gnuradio
> PyBOMBS.Packager.source - WARNING - Build dir already exists:
> /home/eexmmlo/prefix/default/src/gnuradio/build
> Building:(100%)
> [=]
> [  4%] Built target volk_obj
> [  4%] Built target volk
> [  4%] Built target volk_test_all
> [  4%] Built target volk_profile
> [  5%] Built target volk-config-info
> [  6%] Built target pygen_volk_python_volk_modtool_34493
> [  6%] Built target pygen_volk_python_volk_modtool_04eb6
> [  7%] Built target pmt_generated
> [  7%] Built target gnuradio-pmt
> [ 10%] Built target gnuradio-runtime
> [ 11%] Built target test-gnuradio-runtime
> [ 11%] Built target gr_runtime_test
> [ 11%] Built target test-gnuradio-pmt
> [ 11%] Built target gr_pmt_test
> [ 11%] Built target gnuradio-config-info
> [ 11%] Built target pmt_swig_swig_doc
> [ 11%] Built target _pmt_swig_swig_tag
> [ 11%] Built target pmt_swig_gnuradio_runtime_swig_7dd5e
> [ 11%] Built target _pmt_swig
> [ 11%] Built target runtime_swig_swig_doc
> [ 11%] Built target pmt_swig
> [ 11%] Built target _runtime_swig_swig_tag
> [ 11%] Built target runtime_swig_gnuradio_runtime_swig_7dd5e
> [ 11%] Built target _runtime_swig
> [ 11%] Built target pygen_gnuradio_runtime_swig_bc893
> [ 12%] Built target pygen_gnuradio_runtime_swig_c7096
> [ 13%] Built target pygen_gnuradio_runtime_python_gnuradio_0cff0
> [ 13%] Built target pygen_gnuradio_runtime_python_gnuradio_gr_c39fa
> [ 13%] Built target pygen_gnuradio_runtime_python_gnuradio_gru_e77e9
> [ 13%] Built target pygen_gnuradio_runtime_python_gnuradio_ctrlport_20832
> [ 13%] Built target pygen_gnuradio_runtime_python_gnuradio_ctrlport_c0e39
> [ 13%] Built target pygen_gnuradio_runtime_python_gnuradio_ctrlport_2dcdd
> [ 13%] Built target pygen_gnuradio_runtime_python_gnuradio_ctrlport_a87ad
> [ 13%] Built target pygen_gnuradio_runtime_python_pmt_5fb7b
> [ 13%] Built target pygen_gnuradio_runtime_examples_mp_sched_be1cd
> [ 13%] Built target pygen_gnuradio_runtime_examples_network_14cb6
> [ 13%] Built target pygen_gnuradio_runtime_examples_volk_benchmark_0f7b0
> [ 14%] Built target blocks_generated_includes
> [ 14%] Building CXX object
> gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/float_array_to_int.cc.o
> In file included from /usr/include/c++/5/cstdint:35:0,
>  from
> /home/eexmmlo/prefix/default/src/gnuradio/gr-blocks/lib/float_array_to_int.cc:30:
> /usr/include/c++/5/bits/c++0x_warning.h:32:2: error: #error This file
> requires compiler and library support for the ISO C++ 2011 standard. This
> support must be enabled with the -std=c++11 or -std=gnu++11 compiler
> options.
>  #error This file requires compiler and library support \
>   ^
> /home/eexmmlo/prefix/default/src/gnuradio/gr-blocks/lib/float_array_to_int.cc:32:14:
> error: ‘int64_t’ does not name a type
>  static const int64_t MAX_INT =  INT32_MAX;
>   ^
> /home/eexmmlo/prefix/default/src/gnuradio/gr-blocks/lib/float_array_to_int.cc:33:14:
> error: ‘int64_t’ does not name a type
>  static const int64_t MIN_INT =  INT32_MIN;
>   ^
> /home/eexmmlo/prefix/default/src/gnuradio/gr-blocks/lib/float_array_to_int.cc:
> In function ‘void float_array_to_int(const float*, int*, float, int)’:
> /home/eexmmlo/prefix/default/src/gnuradio/gr-blocks/lib/float_array_to_int.cc:39:5:
> error: ‘int64_t’ was not declared in this scope
>  int64_t r = llrintf(

Re: [Discuss-gnuradio] Issue installing GNU Radio with PyBombs

[Dave NotTelling]

I forced the CMAKE_CXX_COMPILER variable to be c++ and the CMAKE_C_COMPILER
to be cc.  You could likely use the older compiler for UHD by passing in
the compiler, a dash, and the version number.  You should be able to see
all available options by opening a terminal, typing `gcc-` and then hitting
tab twice quickly.  Should autocomplete with all available options.  If
that doesn't work then you can try `dpkg -l | grep gcc`.  If you wanted to
use gcc 4.7, then you could set CMAKE_CXX_COMPILER to g++-4.7.  Should be
able to do something similar with the C compiler and gcc-4.7.  I also found
that installing another more recent version of Boost fixed issues for me.
But, that comes with the issue of keeping two diff versions of Boost on the
same system which can mean lots of odd path variables needing to be set :(

On Tue, Jun 5, 2018 at 7:22 PM, Jose Ruvalcaba  wrote:

> Hi Dave,
>
> I have Ubuntu 16.04. I actually had a similar issue as Jason Matusiak had
> with C++11, as discussed in a recent thread, but I updated my gcc compiler
> from 5.3.2 to 6.4 which seemed to fix the c++11 problem but created this
> new issue. How did you build UHD using gcc, if you don't mind me asking?
>
>
>
> On Tue, Jun 5, 2018 at 2:13 PM, Dave NotTelling 
> wrote:
>
>> I ran into this issue when using clang to build UHD on Ubuntu 16.04.  Had
>> to fall back to using gcc to build UHD due to an issue with 16.04's boost
>> not playing nice with clang.  Not sure if that's what's happening here
>> though.  What OS are you using?  Not sure how PyBombs does things under the
>> covers :(
>>
>> On Tue, Jun 5, 2018 at 2:34 PM Jose Ruvalcaba  wrote:
>>
>>> Hello,
>>>
>>> I am trying to install Gnuradio with PyBombs and I am encountering the
>>> following issue when I reach to the UHD part:
>>>
>>> Cloning into 'uhd'...
>>> remote: Counting objects: 123, done.
>>> remote: Total 123 (delta 23), reused 23 (delta 23), pack-reused 100
>>> Receiving objects: 100% (123/123), 39.75 KiB | 0 bytes/s, done.
>>> Resolving deltas: 100% (79/79), completed with 14 local objects.
>>> Checking connectivity... done.
>>> Configuring: (100%) [=
>>> 
>>> ==]
>>> Building:(100%) [=
>>> 
>>> ==]
>>> [  2%] Built target uhd_rpclib
>>> [ 62%] Built target uhd
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *[ 62%] Linking CXX executable twinrx_freq_hopping../lib/libuhd.so.3.12:
>>> undefined reference to
>>> `boost::re_detail::cpp_regex_traits_implementation::transform_primary[abi:cxx11](char
>>> const*, char const*) const'../lib/libuhd.so.3.12: undefined reference to
>>> `boost::re_detail::cpp_regex_traits_implementation::transform[abi:cxx11](char
>>> const*, char const*) const'collect2: error: ld returned 1 exit
>>> statusexamples/CMakeFiles/twinrx_freq_hopping.dir/build.make:109: recipe
>>> for target 'examples/twinrx_freq_hopping' failedmake[2]: ***
>>> [examples/twinrx_freq_hopping] Error 1CMakeFiles/Makefile2:493: recipe for
>>> target 'examples/CMakeFiles/twinrx_freq_hopping.dir/all' failedmake[1]: ***
>>> [examples/CMakeFiles/twinrx_freq_hopping.dir/all] Error 2Makefile:160:
>>> recipe for target 'all' failedmake: *** [all] Error
>>> 2PyBOMBS.Packager.source - ERROR - Build failed. See output above for error
>>> messages.PyBOMBS.Packager.source - ERROR - Problem occurred while building
>>> package uhd:Build failed.PyBOMBS.install_manager - ERROR - Error installing
>>> package uhd. Aborting.*
>>>
>>>
>>> Can anyone shine some light on what the error may be? Has anyone seen
>>> this issue?
>>>
>>> Thanks,
>>> Jose
>>> ___
>>> 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] Issue installing GNU Radio with PyBombs

[Dave NotTelling]

I ran into this issue when using clang to build UHD on Ubuntu 16.04.  Had
to fall back to using gcc to build UHD due to an issue with 16.04's boost
not playing nice with clang.  Not sure if that's what's happening here
though.  What OS are you using?  Not sure how PyBombs does things under the
covers :(

On Tue, Jun 5, 2018 at 2:34 PM Jose Ruvalcaba  wrote:

> Hello,
>
> I am trying to install Gnuradio with PyBombs and I am encountering the
> following issue when I reach to the UHD part:
>
> Cloning into 'uhd'...
> remote: Counting objects: 123, done.
> remote: Total 123 (delta 23), reused 23 (delta 23), pack-reused 100
> Receiving objects: 100% (123/123), 39.75 KiB | 0 bytes/s, done.
> Resolving deltas: 100% (79/79), completed with 14 local objects.
> Checking connectivity... done.
> Configuring: (100%)
> [===]
> Building:(100%)
> [===]
> [  2%] Built target uhd_rpclib
> [ 62%] Built target uhd
>
>
>
>
>
>
>
>
>
>
>
>
>
> *[ 62%] Linking CXX executable twinrx_freq_hopping../lib/libuhd.so.3.12:
> undefined reference to
> `boost::re_detail::cpp_regex_traits_implementation::transform_primary[abi:cxx11](char
> const*, char const*) const'../lib/libuhd.so.3.12: undefined reference to
> `boost::re_detail::cpp_regex_traits_implementation::transform[abi:cxx11](char
> const*, char const*) const'collect2: error: ld returned 1 exit
> statusexamples/CMakeFiles/twinrx_freq_hopping.dir/build.make:109: recipe
> for target 'examples/twinrx_freq_hopping' failedmake[2]: ***
> [examples/twinrx_freq_hopping] Error 1CMakeFiles/Makefile2:493: recipe for
> target 'examples/CMakeFiles/twinrx_freq_hopping.dir/all' failedmake[1]: ***
> [examples/CMakeFiles/twinrx_freq_hopping.dir/all] Error 2Makefile:160:
> recipe for target 'all' failedmake: *** [all] Error
> 2PyBOMBS.Packager.source - ERROR - Build failed. See output above for error
> messages.PyBOMBS.Packager.source - ERROR - Problem occurred while building
> package uhd:Build failed.PyBOMBS.install_manager - ERROR - Error installing
> package uhd. Aborting.*
>
>
> Can anyone shine some light on what the error may be? Has anyone seen this
> issue?
>
> Thanks,
> Jose
> ___
> 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] functions to generate random signals

[Dave NotTelling]

If you have C++11 or higher you can use
http://en.cppreference.com/w/cpp/numeric/random/uniform_real_distribution.
I think that solves the first problem.  Check out
https://stackoverflow.com/questions/32889309/adding-gaussian-noise for an
example of using it for Gaussian noise.

On Tue, Jun 5, 2018 at 1:19 PM Linda20071  wrote:

> I understand the uniform random generator and Gaussian generator have
> already been implemented in gnuradio. However, For some reason, I need to
> implement some customized blocks to generate my own random sequences.
>
> Could an expert here explain:
> 1. Is there a function in C++ that can generate a uniform noise? Is it the
> function rand() in math.h?
> 2. Is there a function in C++ that can generate a Gaussian noise?
>
> If yes, are there any documents on how to use these two functions?
>
> Thank you.
>
>
>
> ___
> 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] install issue with c++11

[Dave NotTelling]

Check out
https://github.com/gnuradio/pybombs#configuring-a-prefix-environment-eg-for-cross-compiling.
You might be able to set CXXFLAGS with the `--env` flag

On Tue, Jun 5, 2018 at 10:36 AM Dave NotTelling  wrote:

> I would suspect that PyBombs doesn't care about your env variables.  That
> or it overwrites the CMAKE_CXX_FLAGS at some point.  I have no idea how
> PyBombs builds the CMake projects.  If it's not calling the `cmake` command
> directly, then it likely will not pick up the env variable.
>
> On Tue, Jun 5, 2018 at 10:33 AM Philip Balister 
> wrote:
>
>> On 06/05/2018 10:06 AM, Marcus D. Leech wrote:
>> > On 06/05/2018 09:07 AM, Jason Matusiak wrote:
>> >> Thanks Dave, but that did not seem to work for me.  Here were the
>> >> commands I ran (slightly different than recommended, but that was for
>> >> some different recipe mods that have nothing to do with this issue):
>> >>
>> >> $ export CXXFLAGS="-std=c++11"
>> >> $ PREFIX=/opt/gnuradio/v3.7.12.0
>> >> $ yes | pybombs prefix init $PREFIX
>> >> $ yes | pybombs -p $PREFIX recipes add gr-recipes
>> >> git+https://github.com/gnuradio/gr-recipes.git
>> >> $ source /opt/gnuradio/v3.7.12.0/setup_env.sh
>> >> $ pybombs -vvv -p $PREFIX install gnuradio
>> >>
>> >> And currently things keep erroring out at the same place while
>> >> installing UHD:
>> >>
>> >> [ 43%] Building CXX object
>> >>
>> lib/CMakeFiles/uhd.dir/usrp/dboard/magnesium/magnesium_radio_ctrl_impl.cpp.o
>> >>
>> >> [ 43%] Building CXX object
>> >>
>> lib/CMakeFiles/uhd.dir/usrp/dboard/magnesium/magnesium_radio_ctrl_init.cpp.o
>> >>
>> >> c++: internal compiler error: Killed (program cc1plus)
>> >> Please submit a full bug report,
>> >> with preprocessed source if appropriate.
>> >> See <http://bugzilla.redhat.com/bugzilla> for instructions.
>> >> make[2]: ***
>> >>
>> [lib/CMakeFiles/uhd.dir/usrp/dboard/magnesium/magnesium_radio_ctrl_init.cpp.o]
>> >> Error 4
>> >> make[2]: *** Waiting for unfinished jobs
>> >>
>> >> I've also tried env CXXFLAGS=-std=c++11, but it had the same issues.
>> >>
>> > That error is internal to the compiler, it is failing to perform its job
>> > correctly.  This has nothing to do with Gnu Radio, per se, or PyBombs
>> >   or any of that.  This ordinarily means you compiler is broken in some
>> > way.
>> >
>> > HOWEVER.  How much memory do you have on the system?
>>
>>
>> Run dmesg and look for messages from the OOM killer (Out of Memory)
>>
>> Philip
>>
>> >
>> > This issue used to happen on systems with small physical memory, because
>> > compiling certain things requires a lot of virtual memory
>> >   on the part of the compiler.
>> >
>> >
>> >>
>> >> Jason,
>> >>  You can set the CXXFLAGS env variable to "-std=c++11" and any
>> >> CMake builds you run (assuming the same shell) will check the
>> >> CXXFLAGS var first.  This assumes that you don't overwrite the
>> >> value of CMAKE_CXX_FLAGS.  I just tried it in a terminal with
>> >> `export CXXFLAGS="-std=c++11"`, then `cmake ..`, and finally
>> >> `VERBOSE=1 make -j 1`.  The verbose make command will show you if
>> >> your flags are taking or not.
>> >> -Dave
>> >>
>> >> On Tue, Jun 5, 2018 at 8:00 AM Jason Matusiak
>> >> > >> <mailto:ja...@gardettoengineering.com>> wrote:
>> >>
>> >> I am trying to install gnuradio onto a Centos 7 box and am
>> >> having more and more issues with packages that use c++11
>> >> commands.  For some of the packages, I add the line:
>> >> CMAKE_CXX_FLAGS "-std=c++11"
>> >> to the module's CMakeLists.txt file.
>> >> The issue is that that requires a fetch, the mod, and then a
>> >> rebuild.  This worked OK with it was just gqrx I was doing it
>> >> for, but now I need it for other modules it appears, and so I
>> >> am trying to find a more elegant solution that covers
>> >> everything that is built via a pybombs install gnuradio
>> >> command (like gr-blocks, which I can&

Re: [Discuss-gnuradio] install issue with c++11

[Dave NotTelling]

I would suspect that PyBombs doesn't care about your env variables.  That
or it overwrites the CMAKE_CXX_FLAGS at some point.  I have no idea how
PyBombs builds the CMake projects.  If it's not calling the `cmake` command
directly, then it likely will not pick up the env variable.

On Tue, Jun 5, 2018 at 10:33 AM Philip Balister  wrote:

> On 06/05/2018 10:06 AM, Marcus D. Leech wrote:
> > On 06/05/2018 09:07 AM, Jason Matusiak wrote:
> >> Thanks Dave, but that did not seem to work for me.  Here were the
> >> commands I ran (slightly different than recommended, but that was for
> >> some different recipe mods that have nothing to do with this issue):
> >>
> >> $ export CXXFLAGS="-std=c++11"
> >> $ PREFIX=/opt/gnuradio/v3.7.12.0
> >> $ yes | pybombs prefix init $PREFIX
> >> $ yes | pybombs -p $PREFIX recipes add gr-recipes
> >> git+https://github.com/gnuradio/gr-recipes.git
> >> $ source /opt/gnuradio/v3.7.12.0/setup_env.sh
> >> $ pybombs -vvv -p $PREFIX install gnuradio
> >>
> >> And currently things keep erroring out at the same place while
> >> installing UHD:
> >>
> >> [ 43%] Building CXX object
> >>
> lib/CMakeFiles/uhd.dir/usrp/dboard/magnesium/magnesium_radio_ctrl_impl.cpp.o
> >>
> >> [ 43%] Building CXX object
> >>
> lib/CMakeFiles/uhd.dir/usrp/dboard/magnesium/magnesium_radio_ctrl_init.cpp.o
> >>
> >> c++: internal compiler error: Killed (program cc1plus)
> >> Please submit a full bug report,
> >> with preprocessed source if appropriate.
> >> See <http://bugzilla.redhat.com/bugzilla> for instructions.
> >> make[2]: ***
> >>
> [lib/CMakeFiles/uhd.dir/usrp/dboard/magnesium/magnesium_radio_ctrl_init.cpp.o]
> >> Error 4
> >> make[2]: *** Waiting for unfinished jobs
> >>
> >> I've also tried env CXXFLAGS=-std=c++11, but it had the same issues.
> >>
> > That error is internal to the compiler, it is failing to perform its job
> > correctly.  This has nothing to do with Gnu Radio, per se, or PyBombs
> >   or any of that.  This ordinarily means you compiler is broken in some
> > way.
> >
> > HOWEVER.  How much memory do you have on the system?
>
>
> Run dmesg and look for messages from the OOM killer (Out of Memory)
>
> Philip
>
> >
> > This issue used to happen on systems with small physical memory, because
> > compiling certain things requires a lot of virtual memory
> >   on the part of the compiler.
> >
> >
> >>
> >> Jason,
> >>  You can set the CXXFLAGS env variable to "-std=c++11" and any
> >> CMake builds you run (assuming the same shell) will check the
> >> CXXFLAGS var first.  This assumes that you don't overwrite the
> >> value of CMAKE_CXX_FLAGS.  I just tried it in a terminal with
> >> `export CXXFLAGS="-std=c++11"`, then `cmake ..`, and finally
> >> `VERBOSE=1 make -j 1`.  The verbose make command will show you if
> >> your flags are taking or not.
> >> -Dave
> >>
> >> On Tue, Jun 5, 2018 at 8:00 AM Jason Matusiak
> >>  >> <mailto:ja...@gardettoengineering.com>> wrote:
> >>
> >> I am trying to install gnuradio onto a Centos 7 box and am
> >> having more and more issues with packages that use c++11
> >> commands.  For some of the packages, I add the line:
> >> CMAKE_CXX_FLAGS "-std=c++11"
> >> to the module's CMakeLists.txt file.
> >> The issue is that that requires a fetch, the mod, and then a
> >> rebuild.  This worked OK with it was just gqrx I was doing it
> >> for, but now I need it for other modules it appears, and so I
> >> am trying to find a more elegant solution that covers
> >> everything that is built via a pybombs install gnuradio
> >> command (like gr-blocks, which I can't use this trick for).
> >> If I understand the problem correctly, Ubuntu uses new enough
> >> tools to realize that it needs to use the c++11 version (or
> >> newer I assume) to build since it is needed.  It seems like
> >> even though Centos 7 has the c++11 capability, it does not
> >> smartly trying to use it, and must be directed to for the
> >> installs to work.
> >> Is there something I can do at an upper level to make things
> >&g

Re: [Discuss-gnuradio] install issue with c++11

[Dave NotTelling]

Jason,

 You can set the CXXFLAGS env variable to "-std=c++11" and any CMake
builds you run (assuming the same shell) will check the CXXFLAGS var
first.  This assumes that you don't overwrite the value of
CMAKE_CXX_FLAGS.  I just tried it in a terminal with `export
CXXFLAGS="-std=c++11"`, then `cmake ..`, and finally `VERBOSE=1 make -j
1`.  The verbose make command will show you if your flags are taking or not.

-Dave

On Tue, Jun 5, 2018 at 8:00 AM Jason Matusiak 
wrote:

> I am trying to install gnuradio onto a Centos 7 box and am having more and
> more issues with packages that use c++11 commands.  For some of the
> packages, I add the line:
> CMAKE_CXX_FLAGS "-std=c++11"
> to the module's CMakeLists.txt file.
>
> The issue is that that requires a fetch, the mod, and then a rebuild.
> This worked OK with it was just gqrx I was doing it for, but now I need it
> for other modules it appears, and so I am trying to find a more elegant
> solution that covers everything that is built via a pybombs install
> gnuradio command (like gr-blocks, which I can't use this trick for).
>
> If I understand the problem correctly, Ubuntu uses new enough tools to
> realize that it needs to use the c++11 version (or newer I assume) to build
> since it is needed.  It seems like even though Centos 7 has the c++11
> capability, it does not smartly trying to use it, and must be directed to
> for the installs to work.
>
> Is there something I can do at an upper level to make things happy on an
> install?
> ___
> 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] Connecting two USRPs in one laptop in gnuradio companion

[Dave NotTelling]

Inkyu,

 At least in 3.9.4 that could be a sequence number error (
https://github.com/EttusResearch/uhd/blob/release_003_009_004/host/lib/usrp/common/async_packet_handler.hpp#L62).
Odd that you're seeing that with USB.  Not really sure how to help you with
that part.

-Dave

On Tue, Apr 24, 2018 at 6:09 AM, Inkyu Bang  wrote:

> Hi,
>
> I am trying to use two USRP (B210) in one laptop.
> I plan to send signals using two USRPs from the same source.
>
> When I tried to separately run ".grc" file in each terminal, it works
> correctly.
> However, when I tried to add one more "UHD: USRP sink" block in GRC.
>
> It shows an exception message "S" and only one USRP works.
>
> Could anyone help me to solve this problem?
>
> (1) What is the meaning of "S"?
> O: overflow, U: underflow, but I don't know what this is.
>
> (2) Is there any way to use multiple "UHD: USRP sink" blocks in one
> machine?
>
> Thank you,
> Regards,
>
> Inkyu Bang
>
> ___
> 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] Callback Function in Blocks for C++

[Dave NotTelling]

Take a look at
https://github.com/gnuradio/gnuradio/blob/master/gr-blocks/include/gnuradio/blocks/throttle.h#L57
,
https://github.com/gnuradio/gnuradio/blob/master/gr-blocks/lib/throttle_impl.h#L49,
and
https://github.com/gnuradio/gnuradio/blob/master/gr-blocks/lib/throttle_impl.cc#L70
as an example.  The XML is at
https://github.com/gnuradio/gnuradio/blob/master/gr-blocks/grc/blocks_throttle.xml#L13

On Tue, Mar 20, 2018 at 12:40 PM, Luis Felipe Albarracin Sanchez <
lfasanc...@gmail.com> wrote:

> Hello Everyone,
>
> I am trying to build a new block from scratch, that allows me to change
> parameter values while the flowgraph is running.
>
> I have found that for the .XML code i must use:
>
> "Function"($XXX)
>
> My question is, in the c++ code , besides creating the function and
> applying values to the parameter, do i need to do something else so the
> callback work?
>
> Thanks for the response.
>
>
> ___
> 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] return value of gr::block::general_work

[Dave NotTelling]

Well, that settles the question :)

On Sun, Jan 21, 2018 at 1:55 PM, Jeff Long  wrote:

> I sent a PR with a doc fix for this. Interleaver uses this (since it does
> round-robin on the input). Also ofdm_chanest and header_payload_demux.
>
> On Sun, Jan 21, 2018 at 1:54 PM, Jeff Long  wrote:
>
>> I sent a PR with a doc fix for this. Interleaver uses this (since it does
>> round-robin on the input). Also ofdm_chanest and header_payload_demux.
>>
>> On Sun, Jan 21, 2018 at 1:34 PM, Michael Dickens <
>> michael.dick...@ettus.com> wrote:
>>
>>> In theory, yes, you can call "produce()" for each output stream with a
>>> different number of items (or, the same), then return
>>> gr::block::WORK_CALLED_PRODUCE to tell the scheduler that produce was
>>> handled inside "general_work()". I know of no blocks that actually do this,
>>> but I don't know everything. That said, the GR runtime internals support my
>>> statement & hence this is worth trying. If you do try & succeed, please do
>>> let the list know. Cheers! - MLD
>>>
>>> On Sun, Jan 21, 2018, at 1:19 PM, Dave NotTelling wrote:
>>> > I found in the docs that general_work only supports outputting the
>>> same number of samples to each output port (
>>> https://github.com/gnuradio/gnuradio/blob/master/gnuradio-r
>>> untime/include/gnuradio/block.h#L47-L49) but the produce method seems
>>> to tell otherwise (https://github.com/gnuradio/g
>>> nuradio/blob/master/gnuradio-runtime/include/gnuradio/block.h#L241-L248)
>>> and even has its own return flag for general_work.  So, question is: can
>>> general_work output different numbers of samples to each output port by use
>>> of the produce() function and returning -2 in general_work?
>>>
>>> ___
>>> 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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] return value of gr::block::general_work

[Dave NotTelling]

Thanks!

On Sun, Jan 21, 2018 at 1:34 PM, Michael Dickens 
wrote:

> In theory, yes, you can call "produce()" for each output stream with a
> different number of items (or, the same), then return
> gr::block::WORK_CALLED_PRODUCE to tell the scheduler that produce was
> handled inside "general_work()". I know of no blocks that actually do this,
> but I don't know everything. That said, the GR runtime internals support my
> statement & hence this is worth trying. If you do try & succeed, please do
> let the list know. Cheers! - MLD
>
> On Sun, Jan 21, 2018, at 1:19 PM, Dave NotTelling wrote:
> > I found in the docs that general_work only supports outputting the same
> number of samples to each output port (https://github.com/gnuradio/
> gnuradio/blob/master/gnuradio-runtime/include/gnuradio/block.h#L47-L49)
> but the produce method seems to tell otherwise (
> https://github.com/gnuradio/gnuradio/blob/master/gnuradio-
> runtime/include/gnuradio/block.h#L241-L248) and even has its own return
> flag for general_work.  So, question is: can general_work output different
> numbers of samples to each output port by use of the produce() function and
> returning -2 in general_work?
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] return value of gr::block::general_work

[Dave NotTelling]

I found in the docs that general_work only supports outputting the same
number of samples to each output port (
https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/include/gnuradio/block.h#L47-L49)
but the produce method seems to tell otherwise (
https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/include/gnuradio/block.h#L241-L248)
and even has its own return flag for general_work.  So, question is: can
general_work output different numbers of samples to each output port by use
of the produce() function and returning -2 in general_work?

On Wed, Jan 17, 2018 at 6:40 PM, Weihan Chen  wrote:

> I got it. Thank you for your response.
>
> Best,
> Weihan
>
> On Wed, Jan 17, 2018 at 5:30 PM, Sakthivel Velumani 
> wrote:
>
>> Hi Weihan,
>>
>> For any block, the noutput_items is just a scalar - meaning "number of
>> items actually written to each output stream" is same for all the output
>> ports. The buffer size of all output ports are the same.
>>
>> Best,
>> Sakthivel
>>
>> On Wed, Jan 17, 2018 at 4:23 PM, Weihan Chen  wrote:
>>
>>> Hi,
>>>
>>> From the manual it says this number is "number of items actually
>>> written to each output stream". But I'm a bit confused that if we have
>>> a block with multiple output ports, then what does the return value mean?
>>> Please help, thanks.
>>>
>>> Regards,
>>> Weihan
>>>
>>>
>>>
>>> ___
>>> 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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Stream to PDU - Guaranteed to not lump tags?

[Dave NotTelling]

That does help!  Thanks Michael :)

On Wed, Jan 10, 2018 at 9:10 PM, Michael Dickens 
wrote:

> Hi Dave - The tagged stream -> PDU block will generate exactly 1 PDU per
> call to work. In your example, it is possible that all 3 of the PDUs will
> end up being in the stream, but, because of the way "tagged_stream_block"
> works, work() will be called with "ninput_items[0]" being just the value
> entered for the tag representing any given PDU length, no more or less.
>
> This stated, it is possible to end up with multiple same-named tag offset
> values in the stream on the same item; I've seen this recently. There are
> also sometimes other tags within range on the stream. All of the tags that
> aren't removed as the provided length key will be added to the PDU as
> meta-data. This might be the source of your "multiple offset values"
> comment.
>
> Hope this helps! - MLD
>
> On Wed, Jan 10, 2018, at 8:32 PM, Dave NotTelling wrote:
>
>  Thanks for the response!  Apologies for the unclear question.  Here's
> another shot:
>
> Can one call to the work function yield multiple offsets from the
> `get_tags_in_range(0, nitems_read(0), nitems_read(0) + noutput_items)`
> call?  With multiple offsets then that means there are multiple sets of
> PDUs (assuming that the stream was created from pdu_to_tagged_stream).
> Let's say for fun that there are 3 PDUs like the following (CAR, CDR):
>
>
>- ( {'pdu_len': 10, 'offset': 0, 'frame' : 1}, (0x00 0x00 0x00 0x00
>0x00 0x00 0x00 0x00 0x00 0x00) )
>- ( {'pdu_len': 10, 'offset': 10, 'frame' : 2}, (0x00 0x00 0x00 0x00
>0x00 0x00 0x00 0x00 0x00 0x00) )
>- ( {'pdu_len': 10, 'offset': 11, 'frame' : 3}, (0x00 0x00 0x00 0x00
>0x00 0x00 0x00 0x00 0x00 0x00) )
>
> What I'm curious about is whether or not a single call to work() will end
> up with tags for more than one of the PDUs above.  For instance, if the
> buffer for the block is large enough, would 20 samples get lumped in to a
> single call to work() resulting in say offset 0 and offset 10 both showing
> up in 'get_tags_in_range(0, nitems_read(0), nitems_read(0) +
> noutput_items)'?  This of course assumes that pdu_to_tagged_stream and
> tagged_stream_to_pdu both are set to use 'pdu_len' as the length tag.
>
>  I seem to remember having that very issue once.  I got multiple
> offset values in a work() function in the past.  Pretty sure I did at least
> O.o  Really, just curious if there is a guarantee somewhere deeper in the
> block code that ensures that can't happen.
>
>  As I write this I realize that this is a pretty easy thing to test
> out.  If it's still unclear, then I'll just do that and post results :)
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Stream to PDU - Guaranteed to not lump tags?

[Dave NotTelling]

Michael,

 Thanks for the response!  Apologies for the unclear question.  Here's
another shot:

Can one call to the work function yield multiple offsets from the
`get_tags_in_range(0, nitems_read(0), nitems_read(0) + noutput_items)`
call?  With multiple offsets then that means there are multiple sets of
PDUs (assuming that the stream was created from pdu_to_tagged_stream).
Let's say for fun that there are 3 PDUs like the following (CAR, CDR):


   - ( {'pdu_len': 10, 'offset': 0, 'frame' : 1}, (0x00 0x00 0x00 0x00
   0x00 0x00 0x00 0x00 0x00 0x00) )
   - ( {'pdu_len': 10, 'offset': 10, 'frame' : 2}, (0x00 0x00 0x00 0x00
   0x00 0x00 0x00 0x00 0x00 0x00) )
   - ( {'pdu_len': 10, 'offset': 11, 'frame' : 3}, (0x00 0x00 0x00 0x00
   0x00 0x00 0x00 0x00 0x00 0x00) )

What I'm curious about is whether or not a single call to work() will end
up with tags for more than one of the PDUs above.  For instance, if the
buffer for the block is large enough, would 20 samples get lumped in to a
single call to work() resulting in say offset 0 and offset 10 both showing
up in 'get_tags_in_range(0, nitems_read(0), nitems_read(0) +
noutput_items)'?  This of course assumes that pdu_to_tagged_stream and
tagged_stream_to_pdu both are set to use 'pdu_len' as the length tag.


 I seem to remember having that very issue once.  I got multiple offset
values in a work() function in the past.  Pretty sure I did at least O.o
Really, just curious if there is a guarantee somewhere deeper in the block
code that ensures that can't happen.

 As I write this I realize that this is a pretty easy thing to test
out.  If it's still unclear, then I'll just do that and post results :)

Thanks!

On Wed, Jan 10, 2018 at 3:32 PM, Michael Dickens 
wrote:

> Hi Dave - The tagged stream -> PDU block will look at for the provided tag
> string at the current 0 offset & if found then that's what the PDU data
> size (in items) will be [this is actually handled in the
> "tagged_stream_block" parent class]. If there are interim tags (within the
> output PDU size in items), then they are just added as meta-data to the
> PDU. Each PDU is created independent of the other PDUs, and just 1 created
> per call to "work". Not sure if this is what you were looking to have
> answered; if not, please clarity. Cheers! - MLD
>
> On Wed, Jan 10, 2018, at 11:30 AM, Dave NotTelling wrote:
> > The wording of the title likely needs work, but the basic idea is this:
> >
> >  * Suppose that I have a ZMQ message source that has arbitrarily sized
> vectors of some consistent type
> >  * I convert that over to a tagged stream, do some operations on it,
> then convert it back to a PDU
> >  * Assume for a second that several of the offsets in the tagged stream
> are very small (only say 10 samples each) and back to back
> >  * Is there a guarantee that each of the 10 sample offsets will result
> in a single PDU?
> >
> >Looking at the source of tagged_stream_to_pdu it seems that there is no
> check that multiple tag offsets arrived in a single call to work.  Or is
> that something that cannot happen?  Having a contract that no more than one
> offset can arrive at a single call to work would be really nice, but I
> imagine that doing so could cause some pretty serious performance issues.
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Stream to PDU - Guaranteed to not lump tags?

[Dave NotTelling]

The wording of the title likely needs work, but the basic idea is this:


   - Suppose that I have a ZMQ message source that has arbitrarily sized
   vectors of some consistent type
   - I convert that over to a tagged stream, do some operations on it, then
   convert it back to a PDU
   - Assume for a second that several of the offsets in the tagged stream
   are very small (only say 10 samples each) and back to back
   - Is there a guarantee that each of the 10 sample offsets will result in
   a single PDU?

Looking at the source of tagged_stream_to_pdu it seems that there is no
check that multiple tag offsets arrived in a single call to work.  Or is
that something that cannot happen?  Having a contract that no more than one
offset can arrive at a single call to work would be really nice, but I
imagine that doing so could cause some pretty serious performance issues O.o
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] package 'gnuradio-fft' not found

[Dave NotTelling]

You are missing quite a few libs.  The one that's causing your specific
issue:

-- Configuring gr-fec support...
--   Dependency ENABLE_VOLK = ON
--   Dependency Boost_FOUND = 1
--   Dependency ENABLE_GNURADIO_RUNTIME = ON
--   Dependency ENABLE_GR_BLOCKS = ON
--   Enabling gr-fec support.
--   Override with -DENABLE_GR_FEC=ON/OFF
-- checking for module 'fftw3f >= 3.0'
--   package 'fftw3f >= 3.0' not found
-- Could NOT find FFTW3F (missing:  FFTW3F_LIBRARIES FFTW3F_INCLUDE_DIRS)
-- 
-- Configuring gr-fft support...
--   Dependency ENABLE_VOLK = ON
--   Dependency Boost_FOUND = 1
--   Dependency ENABLE_GNURADIO_RUNTIME = ON
--   Dependency ENABLE_GR_BLOCKS = ON
--   Dependency FFTW3F_FOUND = FALSE
--   Disabling gr-fft support.
--   Override with -DENABLE_GR_FFT=ON/OFF

Notice that fftwf3 is missing which means you don't have libfftw which
means no FFT support.  Since you're running Ubuntu you should look at
https://wiki.gnuradio.org/index.php/UbuntuInstall and run the canned
apt-get commands for your version.

On Tue, Jan 9, 2018 at 11:48 PM, Koyel Das  wrote:

> Hi,
>
> yes cmake of gnuradio has gr-fft and many other components disables.
> Following is the outcome of cmake
>
> -- Build type not specified: defaulting to release.
> -- Build type set to Release.
> -- Extracting version information from git describe...
> -- Compiler Version: cc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4
> Copyright (C) 2013 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> -- Compiler Flags: /usr/bin/cc:::-O3 -DNDEBUG  -std=gnu99
> -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized
> /usr/bin/c++:::-O3 -DNDEBUG  -std=c++98 -fvisibility=hidden -Wsign-compare
> -Wall -Wno-uninitialized
> -- ADDING PERF COUNTERS
> -- Building Static Libraries: OFF
> -- Boost version: 1.54.0
> -- Found the following Boost libraries:
> --   date_time
> --   program_options
> --   filesystem
> --   system
> --   regex
> --   thread
> -- Enabling use of known bad versions of Boost.
> -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found
> suitable version "2.7.6", minimum required is "2.7")
> --
> -- Checking for module SWIG
> -- Found SWIG version 2.0.11.
> -- Requested SWIG version is at least .
> -- Disabling SWIG because version check failed.
> --
> -- The build system will automatically enable all components.
> -- Use -DENABLE_DEFAULT=OFF to disable components by default.
> --
> -- Configuring python-support support...
> --   Dependency PYTHONLIBS_FOUND = TRUE
> --   Dependency SWIG_FOUND = FALSE
> --   Dependency SWIG_VERSION_CHECK = FALSE
> --   Disabling python-support support.
> --   Override with -DENABLE_PYTHON=ON/OFF
> --
> -- Configuring testing-support support...
> --   Dependency CPPUNIT_FOUND = TRUE
> --   Enabling testing-support support.
> --   Override with -DENABLE_TESTING=ON/OFF
> --
> -- Configuring VOLK support...
> -- Build type set to Release.
> -- Extracting version information from git describe...
> --
> -- Python checking for python >= 2.5
> -- Python checking for python >= 2.5 - found
> --
> -- Python checking for Cheetah >= 2.0.0
> -- Python checking for Cheetah >= 2.0.0 - found
> -- Boost version: 1.54.0
> -- Found the following Boost libraries:
> --   filesystem
> --   system
> --   unit_test_framework
> --   program_options
> -- Enabling use of known bad versions of Boost.
> -- checking for module 'orc-0.4 > 0.4.11'
> --   package 'orc-0.4 > 0.4.11' not found
> -- orc files (missing:  ORC_LIBRARY ORC_INCLUDE_DIR ORCC_EXECUTABLE)
> -- QA Testing is enabled.
> --   Modify using: -DENABLE_TESTING=ON/OFF
> -- System profiling is disabled.
> --   Modify using: -DENABLE_PROFILING=ON/OFF
> -- Compiler name: GNU
> -- x86* CPU detected
> -- ORC support not found, Overruled arch orc
> -- CPU width is 64 bits, Overruled arch 32
> -- Available architectures: generic;64;3dnow;abm;popcount;
> mmx;fma;sse;sse2;norc;sse3;ssse3;sse4_a;sse4_1;sse4_2;avx;avx2
> -- Available machines: generic;sse2_64_mmx;sse3_64_
> mmx;ssse3_64_mmx;sse4_a_64_mmx;sse4_1_64_mmx;sse4_2_64_
> mmx;avx_64_mmx;avx2_64_mmx
> -- BUILD TYPE = RELEASE
> -- Base cflags = -O3 -DNDEBUG  -std=gnu99 -fvisibility=hidden
> -Wsign-compare -Wall -Wno-uninitialized -Wall
> -- BUILD INFO ::: generic ::: GNU ::: -O3 -DNDEBUG  -std=gnu99
> -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wall
> -- BUILD INFO ::: sse2_64_mmx ::: GNU ::: -O3 -DNDEBUG  -std=gnu99
> -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wall -m64
> -mmmx -msse -msse2
> -- BUILD INFO ::: sse3_64_mmx ::: GNU ::: -O3 -DNDEBUG  -std=gnu99
> -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wall -m64
> -mmmx -msse -msse2 -msse3
> -- BUILD INFO ::: ssse3_64_mmx ::: GNU ::: -O3 -DNDEBUG  -std=gnu99
> -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -Wall -m64
> -mmmx -msse -msse2 -msse3 -mssse3
> -- BUILD INF

Re: [Discuss-gnuradio] GRCON2017

[Dave NotTelling]

Any updates on the videos getting posted to YouTube?

On Wed, Sep 20, 2017 at 10:03 AM, Ben Hilburn  wrote:

> Hey all -
>
> Ron is exactly right. I meant to post the link to the slidedecks, which
> are now live.
>
> We are still waiting on the videos, which will get posted to YouTube once
> we receive them - I'll make another announcement, then. Sorry about the
> copy / paste mixup on the URLs.
>
> Cheers,
> Ben
>
> On Tue, Sep 19, 2017 at 5:29 PM, Ron Economos  wrote:
>
>> I think Ben meant to post this link, which are the presentation slides.
>>
>> https://www.gnuradio.org/grcon-2017/program/grcon17-presentations/
>>
>> I expect the presentation videos will take a little while to edit and
>> publish.
>>
>> Ron
>> On 09/19/2017 09:50 AM, Kevin Reid wrote:
>>
>> On Mon, Sep 18, 2017 at 7:01 PM, Ben Hilburn 
>> wrote:
>>
>>> Presentations are now live: https://www.youtube.com/
>>> channel/UCceoapZVEDCQ4s8y16M7Fng
>>>
>>> There are some missing, but we'll get them up as soon as we get them.
>>> Same with the talk recordings, which will get posted to our YouTube channel.
>>>
>>
>> There doesn't seem to be anything newer than 9 months other than the
>> project calls. Are you sure the videos are public?
>>
>>
>>
>> ___
>> 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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Performance monitoring within Gnuradio

[Dave NotTelling]

There is also the Linux tool `perf`.  I use that instead of the GNU Radio
tools due to library compatibility issues (also thrift is a pita to get
working with GNU Radio in my experience).  An example is: `perf top -p
 --call-graph=fp` (use sudo if needed).  If you want to see everything
you can use the PID of the flowgraph itself.  If you want to see individual
modules then you'll need to use `top -H` or whatever htop flags are needed
to see thread names.  From there you can get the PID of a specific block
and use that PID in the call to `perf`.  You can get an idea of where your
module is spending a lot of it's time.  Not sure if you need debugging
symbols installed or not.  I just use the habit of always building
debugging symbols while doing dev work.  An example of usage in the real
world: https://jvns.ca/blog/2016/02/24/perf-top-my-new-best-friend/


On Mon, Oct 30, 2017 at 10:41 AM, Vipin Sharma 
wrote:

> Thanks for the tip!
>
> I will try htop first and then rebuild if necessary.
>
> On Mon, Oct 30, 2017 at 5:29 AM Michael Dickens 
> wrote:
>
>> Hi Vipin - To get performance counters, you have to rebuild GNU Radio
>> and enable them specifically via the cmake command addition
>> "-DENABLE_PERFORMANCE_COUNTERS=ON". Make sure to review the output of
>> the cmake command to verify that they have been enabled, then once
>> you're satisfied do the usual build and install. You'll have to figure
>> out how to make use of PCs; I think TomR did a presentation on them,
>> once upon a time, that would be useful.
>>
>> An alternative is to use "htop" and turn on thread names since GR
>> internally names all threads based on the block running in the thread.
>> "htop" won't give you the high level of detail of PCs, but it also
>> doesn't require you to install Thrift nor rebuild GR; it can be used
>> with your current GR install & will give you an idea of which blocks are
>> using the most CPU cycles.
>>
>> Hope this helps! - MLD
>>
>> On Sun, Oct 29, 2017, at 10:21 AM, Vipin Sharma wrote:
>> > I am trying to monitor performance for my custom blocks using
>> GnuRadio's perf monitoring tools. After researching a bit, I found out that
>> I need to install Apache Thrift.
>> >
>> > Do I need to re-build GnuRadio to leverage Thrift?
>> >
>> > If yes, what options should I give to build script so that it
>> recognizes and builds with Thrift?
>> >
>> > I really just want to measure how much time the work function of my
>> custom block is taking. This way of measuring performance sounds very
>> invasive. May be I should just add code to the work function to measure CPU
>> cycles?
>> >
>> > What is the simplest way to do this?
>>
>
> ___
> 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] Doxygen documentation in GRC

[Dave NotTelling]

Thanks for the reply!  I am running a very old version of GNU Radio, so
that explains why it's still a problem for me.

On Tue, Oct 10, 2017 at 11:15 PM, Sebastian Müller  wrote:

> I think this has been fixed in https://github.com/
> gnuradio/gnuradio/commit/ac925c426dd8dc75b6ee0bd82506e0f59cc5f207, so
> 3.7.10.2 or later should have this fixed IIRC. Do you maybe have an older
> installation?
>
> Sebastian Müller
> gse...@gmail.com
> PGP ID DC2AA3EE
> <http://pgp.mit.edu/pks/lookup?op=vindex&search=0x9FFBD55DDC2AA3EE>
>
> Am 10. Oktober 2017 um 07:40:23, Dave NotTelling (dmp250...@gmail.com)
> schrieb:
>
> Anyone have input on this?  I'm trying to make my blocks more user
> friendly, but all I've been able to get to show up is the description.  The
> information about each parameter is lost in GRC.  Shows up fine in the HTML
> report.
>
> On Wed, Aug 10, 2016 at 6:01 AM, Sebastian Müller 
> wrote:
>
>> Hi all,
>>
>> I've been trying now for some days to include the doxygen documentation
>> for my OOT in the GRC blocks (in the tab Documentation). While actually
>> *something* is displayed there, it is not all that I want. For instance the
>> complete \details section is missing as well as a tabular constructor
>> parameter description. Both seem to work in other blocks
>> (tv_dvbt2_framemapper_cc or digital_ofdm_carrier_allocator_cvc as
>> reference).
>>
>> The HTML doxygen documentation is generated perfectly. Can you point me
>> to what I might be missing? I suppose it could be a SWIG issue since GRC is
>> only displaying the swigged block's __doc__ property.
>>
>> Cheers,
>> Sebastian
>>
>> ___
>> 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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Doxygen documentation in GRC

[Dave NotTelling]

Anyone have input on this?  I'm trying to make my blocks more user
friendly, but all I've been able to get to show up is the description.  The
information about each parameter is lost in GRC.  Shows up fine in the HTML
report.

On Wed, Aug 10, 2016 at 6:01 AM, Sebastian Müller  wrote:

> Hi all,
>
> I've been trying now for some days to include the doxygen documentation
> for my OOT in the GRC blocks (in the tab Documentation). While actually
> *something* is displayed there, it is not all that I want. For instance the
> complete \details section is missing as well as a tabular constructor
> parameter description. Both seem to work in other blocks
> (tv_dvbt2_framemapper_cc or digital_ofdm_carrier_allocator_cvc as
> reference).
>
> The HTML doxygen documentation is generated perfectly. Can you point me to
> what I might be missing? I suppose it could be a SWIG issue since GRC is
> only displaying the swigged block's __doc__ property.
>
> Cheers,
> Sebastian
>
> ___
> 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] Multiple Vectors in PMT

[Dave NotTelling]

The second part is what I was asking about.  For some reason my brain was
stuck on the PDU CAR/CDR and having multiple vectors in the CDR.  I could
completely do that since it's all generic anyway.  Could just make the CDR
a tuple and stuff as many different types of uniform vectors as I want into
the same PDU.

On Wed, Sep 6, 2017 at 10:57 AM, Marcus Müller  wrote:

> Yes, why not? you can register as many output message ports as you want,
> and you can also send as many Messages in the same step as you want, if
> that's what you want.
>
> Best regards,
>
> Marcus
>
> On 09/06/2017 02:58 PM, Dave NotTelling wrote:
>
> Is there a way to have multiple vectors output from a PMT block?
> Something akin to having more than one streaming output?
>
> Thanks!
>
> -Dave
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Multiple Vectors in PMT

[Dave NotTelling]

I just realized that I asked a dumb question.  I can put whatever wherever
so long as the downstream blocks understand it.  Please disregard.

On Wed, Sep 6, 2017 at 8:58 AM, Dave NotTelling  wrote:

> Is there a way to have multiple vectors output from a PMT block?
> Something akin to having more than one streaming output?
>
> Thanks!
>
> -Dave
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Multiple Vectors in PMT

[Dave NotTelling]

Is there a way to have multiple vectors output from a PMT block?  Something
akin to having more than one streaming output?

Thanks!

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

Re: [Discuss-gnuradio] High Water Mark - ZMQ Message Blocks

[Dave NotTelling]

Thanks!

On Mon, Jun 5, 2017 at 3:13 PM, Marcus Müller 
wrote:

> Hi Dave,
>
> yep, GR messages are back-pressure-free, so that's by design.
>
> Best regards,
>
> Marcus
>
> On 05.06.2017 15:35, Dave NotTelling wrote:
>
> I noticed that the message base ZMQ blocks don't support high water marks
> (HWM) but the streaming ones do.  Is there a specific reason for that, or
> is it just the way those blocks were developed?
>
> Thanks!
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] High Water Mark - ZMQ Message Blocks

[Dave NotTelling]

I noticed that the message base ZMQ blocks don't support high water marks
(HWM) but the streaming ones do.  Is there a specific reason for that, or
is it just the way those blocks were developed?

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

Re: [Discuss-gnuradio] Valve Module

[Dave NotTelling]

If you run `grep -r 'valve' *` in the gnuradio source directory you'll find
that it lives in grc/grc_gnuradio/blks2/selector.py.  No .cc file for this
one.

On Fri, May 5, 2017 at 5:30 AM, Ayan Chatterjee  wrote:

> Hi all,
>
> I want to create a new port for "Open" in the existing Valve module. Where
> can I get the .cc file for the valve module in GNU Radio 3.7.4 ?
>
> Thanks.
>
> Regards,
> Ayan
>
> ___
> 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] Process Naming

[Dave NotTelling]

I can see that the threads are showing up with meaningful names using `top
-H`.  Names like `zmq_pub_sink_c1`.  The `ps` command doesn't usually show
me anything special :(  But, `top -H` does which is nice.

On Thu, May 4, 2017 at 9:46 PM, Marcus D. Leech  wrote:

> On 05/04/2017 09:23 PM, Dave NotTelling wrote:
>
> How are processes named in GNU Radio?  I assumed they took on the ID of
> the block.  But testing has showed that not to be the case.  I was hoping
> to be able to see CPU usage of my blocks by running `top -H` and looking at
> the process names.  I also tried setting the block alias but that did
> nothing to the process name (not even sure what it's for honestly).  Is
> this doable?
>
> Thanks!
>
> -Dave
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
> Gnu Radio calls set_pthread_name(), but this isn't necessarily reflected
> in the data that any given implementation of "ps" pulls out of /proc and/or
> the kernel.
>
>
>
> ___
> 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] Process Naming

[Dave NotTelling]

How are processes named in GNU Radio?  I assumed they took on the ID of the
block.  But testing has showed that not to be the case.  I was hoping to be
able to see CPU usage of my blocks by running `top -H` and looking at the
process names.  I also tried setting the block alias but that did nothing
to the process name (not even sure what it's for honestly).  Is this doable?

Thanks!

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

Re: [Discuss-gnuradio] GRC sheet size

[Dave NotTelling]

If you want to change the default size you can look in
/usr/local/etc/gnuradio/conf.d/grc.conf and change the line
`canvas_default_size = 1280, 1024`.  The path might be different on your
system.  You can run `find / -name grc.conf 2>/dev/null` to hunt it down.

On Fri, Apr 28, 2017 at 5:05 AM, Sebastian Müller  wrote:

> In the „Options“ Block, there is a parameter named „Canvas Size“. Enter
> there WIDTH, HEIGHT, e.g. "1280, 1024“.
>
> Regards,
>
> Sebastian Müller
> gse...@gmail.com
>
> Am 28. April 2017 um 08:56:42, Fernando (ferna...@samara.com.es) schrieb:
>
> Is it possible to change the "sheet size" in GRC?
>
> I'm working on a big diagram and it does not fit well.
>
>
> regards
>
>
>
> ___
> 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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OS X Fuzzy Text in GRC

[Dave NotTelling]

Michael helped me out yesterday, but the fuzziness didn't go away by
changing the Python info.plist file per
https://trac.macports.org/ticket/36410.  I'm just going to accept it as a
slightly annoying 'feature' since it's not something that kills
functionality.  If anyone has success in making the text inside the blocks
as clean as the text in the menus then I'd love to hear how.  I also tried
changing the gr-qtgui conf file to raster, opengl, and native with no
change between them.

On Sun, Apr 2, 2017 at 2:10 PM, Michael Dickens 
wrote:

> Can you send me (off list) a screen snapshot or the like so that I can see
> what you mean by "fuzzy"? I see nothing out of the ordinary in GRC when
> running, but then maybe I'm not looking at the correct text... Cheers! - MLD
>
> On Sun, Apr 2, 2017, at 10:12 AM, Dave NotTelling wrote:
>
> I just installed GNU Radio via macports and the text in the blocks is
> really fuzzy.  I ran across https://trac.macports.org/ticket/36410 but I
> don't quite understand how to make it work for my issue.  Is there
> something in /Applications/MacPorts/Qt4 that I should be changing? I'm
> running OS X 10.11.6.
>
>
> ___
> 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] OS X Fuzzy Text in GRC

[Dave NotTelling]

I just installed GNU Radio via macports and the text in the blocks is
really fuzzy.  I ran across https://trac.macports.org/ticket/36410 but I
don't quite understand how to make it work for my issue.  Is there
something in /Applications/MacPorts/Qt4 that I should be changing?

I'm running OS X 10.11.6

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

Re: [Discuss-gnuradio] Fwd: Newbie: usage of PDU to Tagged Stream block

[Dave NotTelling]

Derp, I didn't English well, but you get the idea :)

On Sun, Mar 5, 2017 at 12:26 PM, Dave NotTelling 
wrote:

> Here is your graph with a slight modification of your graph to show what
> happens if you have the CAR populated.
>
>
>
> On Sun, Mar 5, 2017 at 12:20 PM, Dave NotTelling 
> wrote:
>
>> You don't see any output from the Tag Debug block because it only shows
>> the tags, not the data.  You actually don't have any tags in your data.
>> You just have a PMT object with a NIL CAR and a populated CDR.  Since there
>> are no elements in the CAR, you get no tags.  I personally got confused
>> because I thought that if I passed in a valid CAR/CDR combo to the pmt
>> generator then it would just overwrite the CDR portion.  Not so, it
>> actually ignores whatever data comes in.  Check out
>> http://gnuradio.org/doc/doxygen/page_pmt.html for more info about PMT
>> objects.
>>
>> On Sun, Mar 5, 2017 at 8:33 AM, Jorge Carpio  wrote:
>>
>>> Hi all,
>>>
>>> I'm pretty new to GNU Radio, I followed the tutorials and made some
>>> simple flowgraphs to use with an USRP. Recently took a look at the
>>> gr-digital packet communication examples.
>>>
>>> I'm having trouble figuring out the right way to use the PDU to Tagged
>>> Stream block. I connected a Random PDU Generator to the input of the block,
>>> expecting a tagged stream to be produced at the output. But I must have
>>> misunderstood something, because there is no way I can see the samples
>>> being produced in the tagged stream of bytes. I can only see the length
>>> tags in the output stream, but no trace of the PDU data. Not even when I
>>> try to write the stream to a file or to stdout.
>>>
>>>
>>> Attached is the flowgraph I'm using.
>>>
>>> Cheers,
>>> Jorge
>>>
>>>
>>>
>>>
>>> ___
>>> 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] Fwd: Newbie: usage of PDU to Tagged Stream block

[Dave NotTelling]

Here is your graph with a slight modification of your graph to show what
happens if you have the CAR populated.



On Sun, Mar 5, 2017 at 12:20 PM, Dave NotTelling 
wrote:

> You don't see any output from the Tag Debug block because it only shows
> the tags, not the data.  You actually don't have any tags in your data.
> You just have a PMT object with a NIL CAR and a populated CDR.  Since there
> are no elements in the CAR, you get no tags.  I personally got confused
> because I thought that if I passed in a valid CAR/CDR combo to the pmt
> generator then it would just overwrite the CDR portion.  Not so, it
> actually ignores whatever data comes in.  Check out
> http://gnuradio.org/doc/doxygen/page_pmt.html for more info about PMT
> objects.
>
> On Sun, Mar 5, 2017 at 8:33 AM, Jorge Carpio  wrote:
>
>> Hi all,
>>
>> I'm pretty new to GNU Radio, I followed the tutorials and made some
>> simple flowgraphs to use with an USRP. Recently took a look at the
>> gr-digital packet communication examples.
>>
>> I'm having trouble figuring out the right way to use the PDU to Tagged
>> Stream block. I connected a Random PDU Generator to the input of the block,
>> expecting a tagged stream to be produced at the output. But I must have
>> misunderstood something, because there is no way I can see the samples
>> being produced in the tagged stream of bytes. I can only see the length
>> tags in the output stream, but no trace of the PDU data. Not even when I
>> try to write the stream to a file or to stdout.
>>
>>
>> Attached is the flowgraph I'm using.
>>
>> Cheers,
>> Jorge
>>
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>


pdu2tagstream_modified.grc
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Fwd: Newbie: usage of PDU to Tagged Stream block

[Dave NotTelling]

You don't see any output from the Tag Debug block because it only shows the
tags, not the data.  You actually don't have any tags in your data.  You
just have a PMT object with a NIL CAR and a populated CDR.  Since there are
no elements in the CAR, you get no tags.  I personally got confused because
I thought that if I passed in a valid CAR/CDR combo to the pmt generator
then it would just overwrite the CDR portion.  Not so, it actually ignores
whatever data comes in.  Check out
http://gnuradio.org/doc/doxygen/page_pmt.html for more info about PMT
objects.

On Sun, Mar 5, 2017 at 8:33 AM, Jorge Carpio  wrote:

> Hi all,
>
> I'm pretty new to GNU Radio, I followed the tutorials and made some simple
> flowgraphs to use with an USRP. Recently took a look at the gr-digital
> packet communication examples.
>
> I'm having trouble figuring out the right way to use the PDU to Tagged
> Stream block. I connected a Random PDU Generator to the input of the block,
> expecting a tagged stream to be produced at the output. But I must have
> misunderstood something, because there is no way I can see the samples
> being produced in the tagged stream of bytes. I can only see the length
> tags in the output stream, but no trace of the PDU data. Not even when I
> try to write the stream to a file or to stdout.
>
>
> Attached is the flowgraph I'm using.
>
> Cheers,
> Jorge
>
>
>
>
> ___
> 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] Newbie trying to follow OOT module tutorial

[Dave NotTelling]

Check out
http://gnuradio.org/redmine/projects/gnuradio/wiki/BlocksCodingGuide.
You'll see that the <+MAX_IN+>, <+MAX_OUT+>, <+MIN_IN+>, <+MIN_OUT+>,
<+ITYPE+>, and <+OTYPE+> have all been replaced with actual values.  Unless
you have multiple inputs and/or outputs you'll replace all of the
<+MAX_IN+>, <+MAX_OUT+>, <+MIN_IN+>, <+MIN_OUT+> parts with the number 1.
  <+ITYPE+>, and <+OTYPE+> are dependent on what your input and output
types are for the block.  Suppose your block reads in complex values and
output floats.  In that case you would replace all instances of <+ITYPE+>
with gr_complex and all instances of <+OTYPE+> with float.  Also make sure
that your XML file for the block matches the number of inputs, and outputs
as well as the types for each.

On Sun, Mar 5, 2017 at 11:38 AM, Honcho41  wrote:

> Hi, I'm a complete novice to GNURadio but I'm trying to follow the gnu
> tutorial for creating a OOT block.  When I get to the CMake part I keep
> getting these error codes.  I'm sure I'm just missing a dependancy or
> something simple but I'm also pretty new to RPi too.  I'm trying to create
> a
> project for a university degree and I'm getting a bit stumped.  Any help is
> appreciated.
>
> pi@raspberrypi:~/gr-howto/build $ cmake
> -DCMAKE_INSTALL_PREFIX=/usr/share/gnuradio ../
> -- Build type not specified: defaulting to release.
> -- Boost version: 1.55.0
> -- Found the following Boost libraries:
> --   filesystem
> --   system
> -- Found Doxygen: /usr/bin/doxygen (found version "1.8.8")
> Checking for GNU Radio Module: RUNTIME
>  * INCLUDES=/usr/include
>  *
> LIBS=/usr/lib/arm-linux-gnueabihf/libgnuradio-runtime.
> so;/usr/lib/arm-linux-gnueabihf/libgnuradio-pmt.so
> GNURADIO_RUNTIME_FOUND = TRUE
> CMake Warning (dev) at
> /usr/lib/arm-linux-gnueabihf/cmake/gnuradio/GrTest.cmake:45
> (get_target_property):
>   Policy CMP0026 is not set: Disallow use of the LOCATION target property.
>   Run "cmake --help-policy CMP0026" for policy details.  Use the
> cmake_policy
>   command to set the policy and suppress this warning.
>
>   The LOCATION property should not be read from target "test-howto".  Use
> the
>   target name directly with add_custom_command, or use the generator
>   expression $, as appropriate.
>
> Call Stack (most recent call first):
>   lib/CMakeLists.txt:79 (GR_ADD_TEST)
> This warning is for project developers.  Use -Wno-dev to suppress it.
>
> CMake Warning (dev) at
> /usr/lib/arm-linux-gnueabihf/cmake/gnuradio/GrTest.cmake:45
> (get_target_property):
>   Policy CMP0026 is not set: Disallow use of the LOCATION target property.
>   Run "cmake --help-policy CMP0026" for policy details.  Use the
> cmake_policy
>   command to set the policy and suppress this warning.
>
>   The LOCATION property should not be read from target "gnuradio-howto".
> Use
>   the target name directly with add_custom_command, or use the generator
>   expression $, as appropriate.
>
> Call Stack (most recent call first):
>   python/CMakeLists.txt:44 (GR_ADD_TEST)
> This warning is for project developers.  Use -Wno-dev to suppress it.
>
> CMake Warning (dev) at
> /usr/lib/arm-linux-gnueabihf/cmake/gnuradio/GrTest.cmake:45
> (get_target_property):
>   Policy CMP0045 is not set: Error on non-existent target in
>   get_target_property.  Run "cmake --help-policy CMP0045" for policy
> details.
>   Use the cmake_policy command to set the policy and suppress this warning.
>
>   get_target_property() called with non-existent target "/usr/bin/python2".
> Call Stack (most recent call first):
>   python/CMakeLists.txt:44 (GR_ADD_TEST)
> This warning is for project developers.  Use -Wno-dev to suppress it.
>
> CMake Warning (dev) at
> /usr/lib/arm-linux-gnueabihf/cmake/gnuradio/GrTest.cmake:45
> (get_target_property):
>   Policy CMP0045 is not set: Error on non-existent target in
>   get_target_property.  Run "cmake --help-policy CMP0045" for policy
> details.
>   Use the cmake_policy command to set the policy and suppress this warning.
>
>   get_target_property() called with non-existent target
>   "/home/pi/gr-howto/python/qa_square_ff.py".
> Call Stack (most recent call first):
>   python/CMakeLists.txt:44 (GR_ADD_TEST)
> This warning is for project developers.  Use -Wno-dev to suppress it.
>
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /home/pi/gr-howto/build
> pi@raspberrypi:~/gr-howto/build $ make
> [  6%] Building CXX object
> lib/CMakeFiles/gnuradio-howto.dir/square_ff_impl.cc.o
> /home/pi/gr-howto/lib/square_ff_impl.cc: In constructor
> ‘gr::howto::square_ff_impl::square_ff_impl()’:
> /home/pi/gr-howto/lib/square_ff_impl.cc:43:38: error: expected
> primary-expression before ‘<’ token
>gr::io_signature::make(<+MIN_IN+>, <+MAX_IN+>,
> sizeof(<+ITYPE+>)),
>   ^
> /home/pi/gr-howto/lib/square_ff_impl.cc:43:40: error: ‘MIN_IN’ was not
> declared in this scope
>gr::io_signature::make(<+MIN_IN+>, <+MAX_IN+>,
> sizeof(<+IT

Re: [Discuss-gnuradio] Newbie trying to follow OOT module tutorial

[Dave NotTelling]

Oh, here's a better link:
http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorial_GNU_Radio_in_C++#424-Step-3-Fleshing-out-the-code

On Sun, Mar 5, 2017 at 12:09 PM, Dave NotTelling 
wrote:

> Check out http://gnuradio.org/redmine/projects/gnuradio/
> wiki/BlocksCodingGuide.  You'll see that the <+MAX_IN+>, <+MAX_OUT+>,
> <+MIN_IN+>, <+MIN_OUT+>, <+ITYPE+>, and <+OTYPE+> have all been replaced
> with actual values.  Unless you have multiple inputs and/or outputs you'll
> replace all of the <+MAX_IN+>, <+MAX_OUT+>, <+MIN_IN+>, <+MIN_OUT+> parts
> with the number 1.   <+ITYPE+>, and <+OTYPE+> are dependent on what your
> input and output types are for the block.  Suppose your block reads in
> complex values and output floats.  In that case you would replace all
> instances of <+ITYPE+> with gr_complex and all instances of <+OTYPE+> with
> float.  Also make sure that your XML file for the block matches the number
> of inputs, and outputs as well as the types for each.
>
> On Sun, Mar 5, 2017 at 11:38 AM, Honcho41  wrote:
>
>> Hi, I'm a complete novice to GNURadio but I'm trying to follow the gnu
>> tutorial for creating a OOT block.  When I get to the CMake part I keep
>> getting these error codes.  I'm sure I'm just missing a dependancy or
>> something simple but I'm also pretty new to RPi too.  I'm trying to
>> create a
>> project for a university degree and I'm getting a bit stumped.  Any help
>> is
>> appreciated.
>>
>> pi@raspberrypi:~/gr-howto/build $ cmake
>> -DCMAKE_INSTALL_PREFIX=/usr/share/gnuradio ../
>> -- Build type not specified: defaulting to release.
>> -- Boost version: 1.55.0
>> -- Found the following Boost libraries:
>> --   filesystem
>> --   system
>> -- Found Doxygen: /usr/bin/doxygen (found version "1.8.8")
>> Checking for GNU Radio Module: RUNTIME
>>  * INCLUDES=/usr/include
>>  *
>> LIBS=/usr/lib/arm-linux-gnueabihf/libgnuradio-runtime.so;/
>> usr/lib/arm-linux-gnueabihf/libgnuradio-pmt.so
>> GNURADIO_RUNTIME_FOUND = TRUE
>> CMake Warning (dev) at
>> /usr/lib/arm-linux-gnueabihf/cmake/gnuradio/GrTest.cmake:45
>> (get_target_property):
>>   Policy CMP0026 is not set: Disallow use of the LOCATION target property.
>>   Run "cmake --help-policy CMP0026" for policy details.  Use the
>> cmake_policy
>>   command to set the policy and suppress this warning.
>>
>>   The LOCATION property should not be read from target "test-howto".  Use
>> the
>>   target name directly with add_custom_command, or use the generator
>>   expression $, as appropriate.
>>
>> Call Stack (most recent call first):
>>   lib/CMakeLists.txt:79 (GR_ADD_TEST)
>> This warning is for project developers.  Use -Wno-dev to suppress it.
>>
>> CMake Warning (dev) at
>> /usr/lib/arm-linux-gnueabihf/cmake/gnuradio/GrTest.cmake:45
>> (get_target_property):
>>   Policy CMP0026 is not set: Disallow use of the LOCATION target property.
>>   Run "cmake --help-policy CMP0026" for policy details.  Use the
>> cmake_policy
>>   command to set the policy and suppress this warning.
>>
>>   The LOCATION property should not be read from target "gnuradio-howto".
>> Use
>>   the target name directly with add_custom_command, or use the generator
>>   expression $, as appropriate.
>>
>> Call Stack (most recent call first):
>>   python/CMakeLists.txt:44 (GR_ADD_TEST)
>> This warning is for project developers.  Use -Wno-dev to suppress it.
>>
>> CMake Warning (dev) at
>> /usr/lib/arm-linux-gnueabihf/cmake/gnuradio/GrTest.cmake:45
>> (get_target_property):
>>   Policy CMP0045 is not set: Error on non-existent target in
>>   get_target_property.  Run "cmake --help-policy CMP0045" for policy
>> details.
>>   Use the cmake_policy command to set the policy and suppress this
>> warning.
>>
>>   get_target_property() called with non-existent target
>> "/usr/bin/python2".
>> Call Stack (most recent call first):
>>   python/CMakeLists.txt:44 (GR_ADD_TEST)
>> This warning is for project developers.  Use -Wno-dev to suppress it.
>>
>> CMake Warning (dev) at
>> /usr/lib/arm-linux-gnueabihf/cmake/gnuradio/GrTest.cmake:45
>> (get_target_property):
>>   Policy CMP0045 is not set: Error on non-existent target in
>>   get_target_property.  Run "cmake --help-policy CMP0045" for policy
>> details.
>>   Use the cmake_policy command t

Re: [Discuss-gnuradio] Testing Message Based Blocks

[Dave NotTelling]

Ooo, I hadn't even thought about that.  Thank you!!  I'm still
interested in why the Python block doesn't work 'correctly' while the C++
block does, so if you do get some time I'd really be interested in your
findings.

Thanks!!

On Tue, Feb 28, 2017 at 11:38 AM, Marcus Müller 
wrote:

> Hi Dave,
>
> haven't gotten around to looking at your block, but I presume it uses
> message passing to emit PMTs, is that right?
>
> In that case, the "message debug" block has a "store" input.
>
> Best regards,
>
> Marcus
>
> On 02/28/2017 05:15 PM, Dave NotTelling wrote:
>
> Anyone able to help out?  Hoping it's just something dumb that I didn't
> set properly.
>
> On Feb 25, 2017 17:32, "Dave NotTelling"  wrote:
>
>> I am attempting to test a block that takes in complex samples and outputs
>> PMT objects.  In order to properly test it, I need to run a vector through
>> it and verify that the correct number of PMT objects were created.  Thus
>> far I have not run across any blocks that act like a vector sink for PMT
>> objects.  So, I created my own in Python.  When I run with the custom PMT
>> sink the graph never stops.  If I create the same PMT sink in C++ then
>> everything works as expected.  Attached is some example code.  If you build
>> gr-poopie with `cmake .. && make && sudo make install && sudo ldconfig` you
>> can then run the `test.py` script in the base directory.  It should work
>> for the first three tests and then hang on the last one.
>>
>> Thanks!
>>
>> -Dave
>>
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Testing Message Based Blocks

[Dave NotTelling]

Anyone able to help out?  Hoping it's just something dumb that I didn't set
properly.

On Feb 25, 2017 17:32, "Dave NotTelling"  wrote:

> I am attempting to test a block that takes in complex samples and outputs
> PMT objects.  In order to properly test it, I need to run a vector through
> it and verify that the correct number of PMT objects were created.  Thus
> far I have not run across any blocks that act like a vector sink for PMT
> objects.  So, I created my own in Python.  When I run with the custom PMT
> sink the graph never stops.  If I create the same PMT sink in C++ then
> everything works as expected.  Attached is some example code.  If you build
> gr-poopie with `cmake .. && make && sudo make install && sudo ldconfig` you
> can then run the `test.py` script in the base directory.  It should work
> for the first three tests and then hang on the last one.
>
> Thanks!
>
> -Dave
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] fft_filter_ccc Output Buffer Size

[Dave NotTelling]

After some more research it seems that this is an issue of not having an
even multiple of input samples to taps.  For others, here is where I found
the answer: http://www.dspguide.com/ch18/2.htm

On Fri, Feb 10, 2017 at 11:19 AM, Dave NotTelling 
wrote:

> I am trying to use the FFT filter in some c++ code and I'm having issues
> with seg faulting.  The code below will work, but only because the output
> buffer is twice as large as the input buffer.  It doesn't have to be twice
> as large, but it does have to be some number larger than the input buffer.
> Why is that?  Also, how do I know what the output buffer size should be?
>
> Thank you!!
>
>
> [code]
>
> #include 
> #include 
> #include 
> #include 
>
> int main(){
> // Generate a set of zeroed out taps
> std::vector > taps(512, std::complex(0.0f,
> 0.0f));
>
> // Number of random samples to generate
> const int sampleSize = 3;
> // Create a vector of 32fc samples.  Don't initialize it to anything,
> just let it have
> // random data.
> gr_complex * input = (gr_complex *)malloc(sizeof(gr_complex) *
> sampleSize);
>
> // Place to store the output samples from the FFT
> gr_complex * output = (gr_complex *)malloc(sizeof(gr_complex) *
> sampleSize);
>
> // Create a filter to run the input samples through
> gr::filter::kernel::fft_filter_ccc * filter = new
> gr::filter::kernel::fft_filter_ccc(1, taps, 1);
>
> // Filter the input samples
> filter->filter(sampleSize, input, output);
>
> // Free up the malloc'd input and output storage
> free(input);
> free(output);
>
> delete filter;
>
> return 0;
> }
>
> [/code]
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] fft_filter_ccc Output Buffer Size

[Dave NotTelling]

I am trying to use the FFT filter in some c++ code and I'm having issues
with seg faulting.  The code below will work, but only because the output
buffer is twice as large as the input buffer.  It doesn't have to be twice
as large, but it does have to be some number larger than the input buffer.
Why is that?  Also, how do I know what the output buffer size should be?

Thank you!!


[code]

#include 
#include 
#include 
#include 

int main(){
// Generate a set of zeroed out taps
std::vector > taps(512, std::complex(0.0f,
0.0f));

// Number of random samples to generate
const int sampleSize = 3;
// Create a vector of 32fc samples.  Don't initialize it to anything,
just let it have
// random data.
gr_complex * input = (gr_complex *)malloc(sizeof(gr_complex) *
sampleSize);

// Place to store the output samples from the FFT
gr_complex * output = (gr_complex *)malloc(sizeof(gr_complex) *
sampleSize);

// Create a filter to run the input samples through
gr::filter::kernel::fft_filter_ccc * filter = new
gr::filter::kernel::fft_filter_ccc(1, taps, 1);

// Filter the input samples
filter->filter(sampleSize, input, output);

// Free up the malloc'd input and output storage
free(input);
free(output);

delete filter;

return 0;
}

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

Re: [Discuss-gnuradio] PMT Oddities

[Dave NotTelling]

Assuming that is reproducible, does anyone have suggestions on how to get
around it?

On Fri, Dec 9, 2016 at 9:16 PM, Dave NotTelling  wrote:

> Here is a full example:
>
> [code]
>
> #!/usr/bin/python
>
> import pmt
>
> d = pmt.make_dict()
> d = pmt.dict_add(d, pmt.intern('a'), pmt.intern('a'))
> d = pmt.dict_add(d, pmt.intern('b'), pmt.intern('b'))
> d = pmt.dict_add(d, pmt.intern('c'), pmt.intern('c'))
>
> a = pmt.cons(d, pmt.make_u8vector(10, 10))
>
> print 'dict_keys with a populated dictionary'
> print pmt.dict_keys(a)
>
> a = pmt.cons(pmt.make_dict(), pmt.make_u8vector(10, 10))
>
> print 'dict_keys with an empty dictionary'
> print pmt.dict_keys(a)
>
> [/code]
>
> You end up with the following output:
>
> [output]
>
> dict_keys with a populated dictionary
> ((c . c))
> dict_keys with an empty dictionary
> Traceback (most recent call last):
>   File "test.py", line 18, in 
> print pmt.dict_keys(a)
>   File "/usr/local/lib/python2.7/dist-packages/pmt/pmt_swig.py", line
> 3010, in dict_keys
> return _pmt_swig.dict_keys(dict)
> RuntimeError: pmt_car: wrong_type : ()
>
>
> [/output]
>
> The first call to dict_keys(a) returns the last element in the
> dictionary.  The second call errors out.  Both should error out correct?
>
> On Fri, Dec 9, 2016 at 9:11 PM, Dave NotTelling 
> wrote:
>
>> I understand that it should bomb, but it doesn't if there are elements in
>> the dictionary of the pair generated by cons.  that's the problem.  calling
>> dict_keys should die on both tests, but returns just fine on the first
>> test.
>>
>>
>> On Dec 9, 2016 1:35 PM, "Martin Braun"  wrote:
>>
>> On 12/05/2016 01:56 PM, Dave NotTelling wrote:
>> > Marcus & Martin:
>> >
>> >  I tried the dict_keys() method of checking, but even that can
>> > fail.  Here is an example:
>> >
>> > [code]
>> >
>> > import pmt
>> >
>> > d = pmt.make_dict()
>> > d = pmt.dict_add(d, pmt.intern('a'), pmt.intern('a'))
>> > d = pmt.dict_add(d, pmt.intern('b'), pmt.intern('b'))
>> > d = pmt.dict_add(d, pmt.intern('c'), pmt.intern('c'))
>> >
>> > a = pmt.cons(d, pmt.make_u8vector(10, 10))
>> >
>> > print pmt.dict_keys(a)
>> >
>> > [/code]
>> >
>> > You end up with: ((c . c))
>> >
>> > The dict_keys() method will bomb if there are no elements in the
>> dictionary:
>> >
>> > print pmt.dict_keys(pmt.cons(pmt.make_dict(), pmt.make_u8vector(10,
>> 10)))
>>
>> It's supposed to bomb -- pmt.cons() does not return a dict. That's
>> exactly how you can test for dicts.
>>
>> See:
>> https://github.com/gnuradio/gnuradio/blob/1e8562c8d5430667b4
>> 8fced2d2e50ab5771dfb5e/gr-uhd/lib/usrp_block_impl.cc#L486-L494
>>
>> -- M
>>
>> ___
>> 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] PMT Oddities

[Dave NotTelling]

Here is a full example:

[code]

#!/usr/bin/python

import pmt

d = pmt.make_dict()
d = pmt.dict_add(d, pmt.intern('a'), pmt.intern('a'))
d = pmt.dict_add(d, pmt.intern('b'), pmt.intern('b'))
d = pmt.dict_add(d, pmt.intern('c'), pmt.intern('c'))

a = pmt.cons(d, pmt.make_u8vector(10, 10))

print 'dict_keys with a populated dictionary'
print pmt.dict_keys(a)

a = pmt.cons(pmt.make_dict(), pmt.make_u8vector(10, 10))

print 'dict_keys with an empty dictionary'
print pmt.dict_keys(a)

[/code]

You end up with the following output:

[output]

dict_keys with a populated dictionary
((c . c))
dict_keys with an empty dictionary
Traceback (most recent call last):
  File "test.py", line 18, in 
print pmt.dict_keys(a)
  File "/usr/local/lib/python2.7/dist-packages/pmt/pmt_swig.py", line 3010,
in dict_keys
return _pmt_swig.dict_keys(dict)
RuntimeError: pmt_car: wrong_type : ()


[/output]

The first call to dict_keys(a) returns the last element in the dictionary.
The second call errors out.  Both should error out correct?

On Fri, Dec 9, 2016 at 9:11 PM, Dave NotTelling  wrote:

> I understand that it should bomb, but it doesn't if there are elements in
> the dictionary of the pair generated by cons.  that's the problem.  calling
> dict_keys should die on both tests, but returns just fine on the first
> test.
>
>
> On Dec 9, 2016 1:35 PM, "Martin Braun"  wrote:
>
> On 12/05/2016 01:56 PM, Dave NotTelling wrote:
> > Marcus & Martin:
> >
> >  I tried the dict_keys() method of checking, but even that can
> > fail.  Here is an example:
> >
> > [code]
> >
> > import pmt
> >
> > d = pmt.make_dict()
> > d = pmt.dict_add(d, pmt.intern('a'), pmt.intern('a'))
> > d = pmt.dict_add(d, pmt.intern('b'), pmt.intern('b'))
> > d = pmt.dict_add(d, pmt.intern('c'), pmt.intern('c'))
> >
> > a = pmt.cons(d, pmt.make_u8vector(10, 10))
> >
> > print pmt.dict_keys(a)
> >
> > [/code]
> >
> > You end up with: ((c . c))
> >
> > The dict_keys() method will bomb if there are no elements in the
> dictionary:
> >
> > print pmt.dict_keys(pmt.cons(pmt.make_dict(), pmt.make_u8vector(10,
> 10)))
>
> It's supposed to bomb -- pmt.cons() does not return a dict. That's
> exactly how you can test for dicts.
>
> See:
> https://github.com/gnuradio/gnuradio/blob/1e8562c8d5430667b4
> 8fced2d2e50ab5771dfb5e/gr-uhd/lib/usrp_block_impl.cc#L486-L494
>
> -- M
>
> ___
> 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] PMT Oddities

[Dave NotTelling]

I understand that it should bomb, but it doesn't if there are elements in
the dictionary of the pair generated by cons.  that's the problem.  calling
dict_keys should die on both tests, but returns just fine on the first
test.

On Dec 9, 2016 1:35 PM, "Martin Braun"  wrote:

On 12/05/2016 01:56 PM, Dave NotTelling wrote:
> Marcus & Martin:
>
>  I tried the dict_keys() method of checking, but even that can
> fail.  Here is an example:
>
> [code]
>
> import pmt
>
> d = pmt.make_dict()
> d = pmt.dict_add(d, pmt.intern('a'), pmt.intern('a'))
> d = pmt.dict_add(d, pmt.intern('b'), pmt.intern('b'))
> d = pmt.dict_add(d, pmt.intern('c'), pmt.intern('c'))
>
> a = pmt.cons(d, pmt.make_u8vector(10, 10))
>
> print pmt.dict_keys(a)
>
> [/code]
>
> You end up with: ((c . c))
>
> The dict_keys() method will bomb if there are no elements in the
dictionary:
>
> print pmt.dict_keys(pmt.cons(pmt.make_dict(), pmt.make_u8vector(10, 10)))

It's supposed to bomb -- pmt.cons() does not return a dict. That's
exactly how you can test for dicts.

See:
https://github.com/gnuradio/gnuradio/blob/1e8562c8d5430667b48fced2d2e50a
b5771dfb5e/gr-uhd/lib/usrp_block_impl.cc#L486-L494

-- M

___
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] PMT Oddities

[Dave NotTelling]

Thoughts?

On Mon, Dec 5, 2016 at 4:56 PM, Dave NotTelling  wrote:

> Marcus & Martin:
>
>  I tried the dict_keys() method of checking, but even that can fail.
> Here is an example:
>
> [code]
>
> import pmt
>
> d = pmt.make_dict()
> d = pmt.dict_add(d, pmt.intern('a'), pmt.intern('a'))
> d = pmt.dict_add(d, pmt.intern('b'), pmt.intern('b'))
> d = pmt.dict_add(d, pmt.intern('c'), pmt.intern('c'))
>
> a = pmt.cons(d, pmt.make_u8vector(10, 10))
>
> print pmt.dict_keys(a)
>
> [/code]
>
> You end up with: ((c . c))
>
> The dict_keys() method will bomb if there are no elements in the
> dictionary:
>
> print pmt.dict_keys(pmt.cons(pmt.make_dict(), pmt.make_u8vector(10, 10)))
>
>
> On Tue, Nov 22, 2016 at 5:55 PM, Dave NotTelling 
> wrote:
>
>> Thanks for the explanation!
>>
>> On Tue, Nov 22, 2016 at 5:29 PM, Marcus Müller 
>> wrote:
>>
>>> That's a long story. Essentially, a list is a pair of the first element
>>> and a pair of a second element and a pair of the third element and a pair
>>> of …
>>>
>>> Cheers,
>>> Marcus
>>>
>>> On 22.11.2016 23:18, Dave NotTelling wrote:
>>>
>>> I ask because it feels like a bug.  Things like ((a . b), (c . d), (e .
>>> f)) are definitely not pairs (assuming a pair is 2 elements) and (in my
>>> opinion) should not return true for pmt.is_pair().
>>>
>>> On Tue, Nov 22, 2016 at 5:12 PM, Dave NotTelling 
>>> wrote:
>>>
>>>> Martin,
>>>>
>>>>  Was that done on purpose?
>>>>
>>>>  Thank you for the link!  I hadn't thought about checking that way.
>>>>
>>>> Thanks!
>>>>
>>>> -Dave
>>>>
>>>> On Tue, Nov 22, 2016 at 5:08 PM, Martin Braun 
>>>> wrote:
>>>>
>>>>> Dave,
>>>>>
>>>>> pairs pass is_dict(), which is possibly the root cause here. See also:
>>>>> https://github.com/gnuradio/gnuradio/blob/31b28f0cf4694378b2
>>>>> 6617616d08b4082668962f/gr-uhd/lib/usrp_block_impl.cc#L487-L494
>>>>>
>>>>> Cheers,
>>>>> M
>>>>>
>>>>> On 11/22/2016 01:47 PM, Dave NotTelling wrote:
>>>>> > I noticed today that the is_dict and is_pair checks are not
>>>>> appearing to
>>>>> > work properly.  Here is an example that shows the issue:
>>>>> >
>>>>> > [code]
>>>>> >
>>>>> > #!/usr/bin/python
>>>>> >
>>>>> > import pmt
>>>>> >
>>>>> > def print_pmt(dictVar):
>>>>> > print 'isPair:%05s, isDict:%05s, isTuple:%05s  =>  %s' %
>>>>> > (pmt.is_pair(dictVar), pmt.is_dict(dictVar), pmt.is_tuple(dictVar),
>>>>> dictVar)
>>>>> >
>>>>> > print 'DICT'
>>>>> >
>>>>> > d = pmt.make_dict()
>>>>> > print_pmt(d)
>>>>> >
>>>>> > d = pmt.dict_add(d, pmt.intern('a'), pmt.intern('b'))
>>>>> > print_pmt(d)
>>>>> >
>>>>> > d = pmt.dict_add(d, pmt.intern('c'), pmt.intern('d'))
>>>>> > print_pmt(d)
>>>>> >
>>>>> > d = pmt.dict_add(d, pmt.intern('e'), pmt.intern('f'))
>>>>> > print_pmt(d)
>>>>> >
>>>>> > print '\nCONS'
>>>>> >
>>>>> > p = pmt.cons(pmt.make_dict(), pmt.make_u8vector(0,0))
>>>>> > print_pmt(p)
>>>>> >
>>>>> > [/code]
>>>>> >
>>>>> > Run that and you'll see what I consider strange behavior.  The
>>>>> values of
>>>>> > is_pair and is_dict to not match what is expected.  Is that by
>>>>> design?
>>>>> > If so, why?
>>>>> >
>>>>> > ((a . b)) is not a pair...  It's a single element dictionary
>>>>> > ((c . d) (a . b)) i can sorta see this being a pair, but it wasn't
>>>>> > created that way
>>>>> > ((e . f) (c . d) (a . b)) definitely not a pair as it's 3 elements
>>>>> >
>>>>> > (() . #[]) don't dictionaries have to be nested?
>>>>> >
>>>>> >
>>>>> > Thanks!
>>>>> >
>>>>> >
>>>>> > ___
>>>>> > 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 mailing 
>>> listDiscuss-gnuradio@gnu.orghttps://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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Max PMT Size

[Dave NotTelling]

I seem to remember asking this question once before and being told that the
only way to increase the max size of a PMT object is to set a define in a
header file before compilation.  Is this size limit only applicable to the
PDU to Tagged Stream block?  Can a PMT output to another PMT input be
whatever size it wants to be?

Also, is there a way to programmatically get the max possible buffer size?

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

Re: [Discuss-gnuradio] PMT Oddities

[Dave NotTelling]

Marcus & Martin:

 I tried the dict_keys() method of checking, but even that can fail.
Here is an example:

[code]

import pmt

d = pmt.make_dict()
d = pmt.dict_add(d, pmt.intern('a'), pmt.intern('a'))
d = pmt.dict_add(d, pmt.intern('b'), pmt.intern('b'))
d = pmt.dict_add(d, pmt.intern('c'), pmt.intern('c'))

a = pmt.cons(d, pmt.make_u8vector(10, 10))

print pmt.dict_keys(a)

[/code]

You end up with: ((c . c))

The dict_keys() method will bomb if there are no elements in the dictionary:

print pmt.dict_keys(pmt.cons(pmt.make_dict(), pmt.make_u8vector(10, 10)))


On Tue, Nov 22, 2016 at 5:55 PM, Dave NotTelling 
wrote:

> Thanks for the explanation!
>
> On Tue, Nov 22, 2016 at 5:29 PM, Marcus Müller 
> wrote:
>
>> That's a long story. Essentially, a list is a pair of the first element
>> and a pair of a second element and a pair of the third element and a pair
>> of …
>>
>> Cheers,
>> Marcus
>>
>> On 22.11.2016 23:18, Dave NotTelling wrote:
>>
>> I ask because it feels like a bug.  Things like ((a . b), (c . d), (e .
>> f)) are definitely not pairs (assuming a pair is 2 elements) and (in my
>> opinion) should not return true for pmt.is_pair().
>>
>> On Tue, Nov 22, 2016 at 5:12 PM, Dave NotTelling 
>> wrote:
>>
>>> Martin,
>>>
>>>  Was that done on purpose?
>>>
>>>  Thank you for the link!  I hadn't thought about checking that way.
>>>
>>> Thanks!
>>>
>>> -Dave
>>>
>>> On Tue, Nov 22, 2016 at 5:08 PM, Martin Braun 
>>> wrote:
>>>
>>>> Dave,
>>>>
>>>> pairs pass is_dict(), which is possibly the root cause here. See also:
>>>> https://github.com/gnuradio/gnuradio/blob/31b28f0cf4694378b2
>>>> 6617616d08b4082668962f/gr-uhd/lib/usrp_block_impl.cc#L487-L494
>>>>
>>>> Cheers,
>>>> M
>>>>
>>>> On 11/22/2016 01:47 PM, Dave NotTelling wrote:
>>>> > I noticed today that the is_dict and is_pair checks are not appearing
>>>> to
>>>> > work properly.  Here is an example that shows the issue:
>>>> >
>>>> > [code]
>>>> >
>>>> > #!/usr/bin/python
>>>> >
>>>> > import pmt
>>>> >
>>>> > def print_pmt(dictVar):
>>>> > print 'isPair:%05s, isDict:%05s, isTuple:%05s  =>  %s' %
>>>> > (pmt.is_pair(dictVar), pmt.is_dict(dictVar), pmt.is_tuple(dictVar),
>>>> dictVar)
>>>> >
>>>> > print 'DICT'
>>>> >
>>>> > d = pmt.make_dict()
>>>> > print_pmt(d)
>>>> >
>>>> > d = pmt.dict_add(d, pmt.intern('a'), pmt.intern('b'))
>>>> > print_pmt(d)
>>>> >
>>>> > d = pmt.dict_add(d, pmt.intern('c'), pmt.intern('d'))
>>>> > print_pmt(d)
>>>> >
>>>> > d = pmt.dict_add(d, pmt.intern('e'), pmt.intern('f'))
>>>> > print_pmt(d)
>>>> >
>>>> > print '\nCONS'
>>>> >
>>>> > p = pmt.cons(pmt.make_dict(), pmt.make_u8vector(0,0))
>>>> > print_pmt(p)
>>>> >
>>>> > [/code]
>>>> >
>>>> > Run that and you'll see what I consider strange behavior.  The values
>>>> of
>>>> > is_pair and is_dict to not match what is expected.  Is that by design?
>>>> > If so, why?
>>>> >
>>>> > ((a . b)) is not a pair...  It's a single element dictionary
>>>> > ((c . d) (a . b)) i can sorta see this being a pair, but it wasn't
>>>> > created that way
>>>> > ((e . f) (c . d) (a . b)) definitely not a pair as it's 3 elements
>>>> >
>>>> > (() . #[]) don't dictionaries have to be nested?
>>>> >
>>>> >
>>>> > Thanks!
>>>> >
>>>> >
>>>> > ___
>>>> > 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 mailing 
>> listDiscuss-gnuradio@gnu.orghttps://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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] PMT Oddities

[Dave NotTelling]

Thanks for the explanation!

On Tue, Nov 22, 2016 at 5:29 PM, Marcus Müller 
wrote:

> That's a long story. Essentially, a list is a pair of the first element
> and a pair of a second element and a pair of the third element and a pair
> of …
>
> Cheers,
> Marcus
>
> On 22.11.2016 23:18, Dave NotTelling wrote:
>
> I ask because it feels like a bug.  Things like ((a . b), (c . d), (e .
> f)) are definitely not pairs (assuming a pair is 2 elements) and (in my
> opinion) should not return true for pmt.is_pair().
>
> On Tue, Nov 22, 2016 at 5:12 PM, Dave NotTelling 
> wrote:
>
>> Martin,
>>
>>  Was that done on purpose?
>>
>>  Thank you for the link!  I hadn't thought about checking that way.
>>
>> Thanks!
>>
>> -Dave
>>
>> On Tue, Nov 22, 2016 at 5:08 PM, Martin Braun 
>> wrote:
>>
>>> Dave,
>>>
>>> pairs pass is_dict(), which is possibly the root cause here. See also:
>>> https://github.com/gnuradio/gnuradio/blob/31b28f0cf4694378b2
>>> 6617616d08b4082668962f/gr-uhd/lib/usrp_block_impl.cc#L487-L494
>>>
>>> Cheers,
>>> M
>>>
>>> On 11/22/2016 01:47 PM, Dave NotTelling wrote:
>>> > I noticed today that the is_dict and is_pair checks are not appearing
>>> to
>>> > work properly.  Here is an example that shows the issue:
>>> >
>>> > [code]
>>> >
>>> > #!/usr/bin/python
>>> >
>>> > import pmt
>>> >
>>> > def print_pmt(dictVar):
>>> > print 'isPair:%05s, isDict:%05s, isTuple:%05s  =>  %s' %
>>> > (pmt.is_pair(dictVar), pmt.is_dict(dictVar), pmt.is_tuple(dictVar),
>>> dictVar)
>>> >
>>> > print 'DICT'
>>> >
>>> > d = pmt.make_dict()
>>> > print_pmt(d)
>>> >
>>> > d = pmt.dict_add(d, pmt.intern('a'), pmt.intern('b'))
>>> > print_pmt(d)
>>> >
>>> > d = pmt.dict_add(d, pmt.intern('c'), pmt.intern('d'))
>>> > print_pmt(d)
>>> >
>>> > d = pmt.dict_add(d, pmt.intern('e'), pmt.intern('f'))
>>> > print_pmt(d)
>>> >
>>> > print '\nCONS'
>>> >
>>> > p = pmt.cons(pmt.make_dict(), pmt.make_u8vector(0,0))
>>> > print_pmt(p)
>>> >
>>> > [/code]
>>> >
>>> > Run that and you'll see what I consider strange behavior.  The values
>>> of
>>> > is_pair and is_dict to not match what is expected.  Is that by design?
>>> > If so, why?
>>> >
>>> > ((a . b)) is not a pair...  It's a single element dictionary
>>> > ((c . d) (a . b)) i can sorta see this being a pair, but it wasn't
>>> > created that way
>>> > ((e . f) (c . d) (a . b)) definitely not a pair as it's 3 elements
>>> >
>>> > (() . #[]) don't dictionaries have to be nested?
>>> >
>>> >
>>> > Thanks!
>>> >
>>> >
>>> > ___
>>> > 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 mailing 
> listDiscuss-gnuradio@gnu.orghttps://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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] PMT Oddities

[Dave NotTelling]

I ask because it feels like a bug.  Things like ((a . b), (c . d), (e . f))
are definitely not pairs (assuming a pair is 2 elements) and (in my
opinion) should not return true for pmt.is_pair().

On Tue, Nov 22, 2016 at 5:12 PM, Dave NotTelling 
wrote:

> Martin,
>
>  Was that done on purpose?
>
>  Thank you for the link!  I hadn't thought about checking that way.
>
> Thanks!
>
> -Dave
>
> On Tue, Nov 22, 2016 at 5:08 PM, Martin Braun 
> wrote:
>
>> Dave,
>>
>> pairs pass is_dict(), which is possibly the root cause here. See also:
>> https://github.com/gnuradio/gnuradio/blob/31b28f0cf4694378b2
>> 6617616d08b4082668962f/gr-uhd/lib/usrp_block_impl.cc#L487-L494
>>
>> Cheers,
>> M
>>
>> On 11/22/2016 01:47 PM, Dave NotTelling wrote:
>> > I noticed today that the is_dict and is_pair checks are not appearing to
>> > work properly.  Here is an example that shows the issue:
>> >
>> > [code]
>> >
>> > #!/usr/bin/python
>> >
>> > import pmt
>> >
>> > def print_pmt(dictVar):
>> > print 'isPair:%05s, isDict:%05s, isTuple:%05s  =>  %s' %
>> > (pmt.is_pair(dictVar), pmt.is_dict(dictVar), pmt.is_tuple(dictVar),
>> dictVar)
>> >
>> > print 'DICT'
>> >
>> > d = pmt.make_dict()
>> > print_pmt(d)
>> >
>> > d = pmt.dict_add(d, pmt.intern('a'), pmt.intern('b'))
>> > print_pmt(d)
>> >
>> > d = pmt.dict_add(d, pmt.intern('c'), pmt.intern('d'))
>> > print_pmt(d)
>> >
>> > d = pmt.dict_add(d, pmt.intern('e'), pmt.intern('f'))
>> > print_pmt(d)
>> >
>> > print '\nCONS'
>> >
>> > p = pmt.cons(pmt.make_dict(), pmt.make_u8vector(0,0))
>> > print_pmt(p)
>> >
>> > [/code]
>> >
>> > Run that and you'll see what I consider strange behavior.  The values of
>> > is_pair and is_dict to not match what is expected.  Is that by design?
>> > If so, why?
>> >
>> > ((a . b)) is not a pair...  It's a single element dictionary
>> > ((c . d) (a . b)) i can sorta see this being a pair, but it wasn't
>> > created that way
>> > ((e . f) (c . d) (a . b)) definitely not a pair as it's 3 elements
>> >
>> > (() . #[]) don't dictionaries have to be nested?
>> >
>> >
>> > Thanks!
>> >
>> >
>> > ___
>> > 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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] PMT Oddities

[Dave NotTelling]

Martin,

 Was that done on purpose?

 Thank you for the link!  I hadn't thought about checking that way.

Thanks!

-Dave

On Tue, Nov 22, 2016 at 5:08 PM, Martin Braun 
wrote:

> Dave,
>
> pairs pass is_dict(), which is possibly the root cause here. See also:
> https://github.com/gnuradio/gnuradio/blob/31b28f0cf4694378b26617616d08b4
> 082668962f/gr-uhd/lib/usrp_block_impl.cc#L487-L494
>
> Cheers,
> M
>
> On 11/22/2016 01:47 PM, Dave NotTelling wrote:
> > I noticed today that the is_dict and is_pair checks are not appearing to
> > work properly.  Here is an example that shows the issue:
> >
> > [code]
> >
> > #!/usr/bin/python
> >
> > import pmt
> >
> > def print_pmt(dictVar):
> > print 'isPair:%05s, isDict:%05s, isTuple:%05s  =>  %s' %
> > (pmt.is_pair(dictVar), pmt.is_dict(dictVar), pmt.is_tuple(dictVar),
> dictVar)
> >
> > print 'DICT'
> >
> > d = pmt.make_dict()
> > print_pmt(d)
> >
> > d = pmt.dict_add(d, pmt.intern('a'), pmt.intern('b'))
> > print_pmt(d)
> >
> > d = pmt.dict_add(d, pmt.intern('c'), pmt.intern('d'))
> > print_pmt(d)
> >
> > d = pmt.dict_add(d, pmt.intern('e'), pmt.intern('f'))
> > print_pmt(d)
> >
> > print '\nCONS'
> >
> > p = pmt.cons(pmt.make_dict(), pmt.make_u8vector(0,0))
> > print_pmt(p)
> >
> > [/code]
> >
> > Run that and you'll see what I consider strange behavior.  The values of
> > is_pair and is_dict to not match what is expected.  Is that by design?
> > If so, why?
> >
> > ((a . b)) is not a pair...  It's a single element dictionary
> > ((c . d) (a . b)) i can sorta see this being a pair, but it wasn't
> > created that way
> > ((e . f) (c . d) (a . b)) definitely not a pair as it's 3 elements
> >
> > (() . #[]) don't dictionaries have to be nested?
> >
> >
> > Thanks!
> >
> >
> > ___
> > 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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] PMT Oddities

[Dave NotTelling]

I noticed today that the is_dict and is_pair checks are not appearing to
work properly.  Here is an example that shows the issue:

[code]

#!/usr/bin/python

import pmt

def print_pmt(dictVar):
print 'isPair:%05s, isDict:%05s, isTuple:%05s  =>  %s' %
(pmt.is_pair(dictVar), pmt.is_dict(dictVar), pmt.is_tuple(dictVar), dictVar)

print 'DICT'

d = pmt.make_dict()
print_pmt(d)

d = pmt.dict_add(d, pmt.intern('a'), pmt.intern('b'))
print_pmt(d)

d = pmt.dict_add(d, pmt.intern('c'), pmt.intern('d'))
print_pmt(d)

d = pmt.dict_add(d, pmt.intern('e'), pmt.intern('f'))
print_pmt(d)

print '\nCONS'

p = pmt.cons(pmt.make_dict(), pmt.make_u8vector(0,0))
print_pmt(p)

[/code]

Run that and you'll see what I consider strange behavior.  The values of
is_pair and is_dict to not match what is expected.  Is that by design?  If
so, why?

((a . b)) is not a pair...  It's a single element dictionary
((c . d) (a . b)) i can sorta see this being a pair, but it wasn't created
that way
((e . f) (c . d) (a . b)) definitely not a pair as it's 3 elements

(() . #[]) don't dictionaries have to be nested?


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

Re: [Discuss-gnuradio] Attribute error: and support with external class and header files

[Dave NotTelling]

Is it safe to add the c++11 flag?  I was under the impression that the GNU
Radio build system didn't use c++11 for a reason.  If that's not the case
then I'll start using c++11 too :D

On Tue, Aug 30, 2016 at 4:25 AM, Pranav Padalkar <
pranav.padal...@esk.fraunhofer.de> wrote:

> Good Morning everyone,
>
>
> I figured out how to add my own source files in GNURadio and also how to
> add support for external libraries, in my case it was for Protobuf. I will
> just write a note here, hoping that it will help someone in the future.
>
>
> 1. I placed all of my own .h and .cpp files in the "lib" folder of my
> module, along with the "impl.cc" files.
>
> 2. I edited "CMakeLists.txt" of the "lib" folder; in that I added all of
> my own .cpp file names in "Setup library" section in the statement "
> list(APPEND ...) ".
>
>
> To add C++11 flag -
>
> 1. I edited "CMakeLists.txt" in the home folder of my module (i.e.
> gnuradio/gr-*modulename*/CMakeLists.txt); in that I added a command 
> *set(CMAKE_CXX_FLAGS
> "-std=c++11") *in "Compiler specific setup" section after
> *add_definitions()*.
>
>
> To add external libraries, in my case Protobuf -
>
> 1. I edited "CMakeLists.txt" in the "lib" folder of my module.
>
> 2. In "Setup library" section, i added some commands to find the library I
> am looking for and then added them in "include_directories()" and in
> "link_directories()".
>
>
> include(FindProtobuf)
> find_package(Protobuf REQUIRED)
>
> include_directories(${Boost_INCLUDE_DIR} ${Protobuf_INCLUDE_DIRS})
> link_directories(${Boost_LIBRARY_DIRS} ${Protobuf_LIBRARIES})
>
> target_link_libraries(gnuradio-*modulename* ${Boost_LIBRARIES}
> ${GNURADIO_ALL_LIBRARIES} ${Protobuf_LIBRARIES})
>
>
>  After doing this it works for me now and I don't get attribute error
> which was happening because of my source files and libraries not being
> linked.
>
>
> Regards,
> Pranav Padalkar
> Fraunhofer-Institut für Eingebettete Systeme und Kommunikationstechnik ESK
>
> --
> *From:* Discuss-gnuradio  fraunhofer...@gnu.org> on behalf of Pranav Padalkar  fraunhofer.de>
> *Sent:* Wednesday, August 24, 2016 9:19 AM
> *To:* Dave NotTelling
> *Cc:* discuss-gnuradio@gnu.org
> *Subject:* Re: [Discuss-gnuradio] Attribute error: and support with
> external class and header files
>
>
> Hi Dave,
>
>
>
> Thanks for your reply. Actually I figured out the problem. After going
> through the files of the already existing blocks, especially the
> CMakeLists.txt, I figured out where I need to add my own header files. I
> added entries of all the class files in the CMakeLists.txt inside “lib”
> folder. I am not sure if this has solved the problem, but at least it is
> compiling now. Currently I am facing the problem of how to make the
> GnuRadio compiler to get the C++11 flag. I know it has to be added to the
> CMake file, but I am not sure where exactly. If anyone knows about this,
> then kindly let me know. I also need to include other libraries like
> pthread, libboost_filesystem, etc.
>
>
>
> Thanks and Regards,
>
> Pranav
>
>
>
> *Von:* Dave NotTelling [mailto:dmp250...@gmail.com]
> *Gesendet:* Dienstag, 23. August 2016 18:50
> *An:* Pranav Padalkar
> *Cc:* discuss-gnuradio@gnu.org
> *Betreff:* Re: [Discuss-gnuradio] Attribute error: and support with
> external class and header files
>
>
>
> I've had bad luck just putting my own headers in OOT modules.  The way I
> do things now is to use gr_modtool add and select 'noblock'.  Then just
> remove the grc XML file created.  Seems that YourModuleName_API is needed
> before structs and classes or it doesn't get seen by Swig.  Could be wrong
> about that.  Might just work for me on a fluke =\
>
>
>
> On Tue, Aug 23, 2016 at 6:47 AM, Pranav Padalkar  fraunhofer.de> wrote:
>
> Hello all,
>
>
>
> I have written a c++ code and I wish to implement as a block in GNURadio.
> I created a module (named "newblocks") and a block (named "my_client) and
> made appropriate changes. The thing is, I have many class and header files
> for my c++ code, for eg. Protobuf. I put those files in a folder called
> "client" inside "include" folder of my module 
> (gr-newblocks/include/newblocks/client).
> It showed no error during cmake, make, make install and ldconfig. But when
> I put the block in the flowgraph and run it, it gives me following error.
>
>
>
> File "/home/sdr/workspace/develop/Pranav/

Re: [Discuss-gnuradio] Microwave Link Demodulation

[Dave NotTelling]

One way I check for bottlenecks it to run 'top -H' and watch the various
threads.  If you see any one thread pegged at 100% then it needs to be
optimized.  At least that's my method :)

On Mon, Aug 29, 2016 at 9:46 AM, Ihab Zine  wrote:

> Hi Marcus,
>
> I have been through the GNU RADIO tutorials , I also dived into adapting
> gr-dvbt, and it worked for me. But how can i find out where my transceiver
> BER bottlenecks and where my computational bottlenecks come from? Is the a
> method or steps i can follow? I need some hints on this.
>
> Best Regards
> Ihab
>
> On 24 August 2016 at 15:12, Ihab Zine  wrote:
>
>> Hi Ron and Marcus,
>>
>> For frequency higher than 6 Ghz,  a down converter can be used to over
>> come this problem.
>>
>> for the data rate and bandwidth, the PC i'm using has the following
>> specifications:
>>
>> Architecture:  x86_64
>> CPU op-mode(s):  32-bit, 64-bit
>> Byte Order:Little Endian
>> CPU(s):  20
>> On-line CPU(s) list:0-19
>> Thread(s) per core:2
>> Core(s) per socket:10
>> Socket(s):  1
>> NUMA node(s): 1
>> Vendor ID: GenuineIntel
>> CPU family:   6
>> Model:   63
>> Model name: Intel(R) Xeon(R) CPU E5-2660 v3 @ 2.60GHz
>> Stepping:  2
>> CPU MHz:1553.804
>> CPU max MHz: 3300.
>> CPU min MHz:  1200.
>> BogoMIPS:5197.32
>> Virtualization:VT-x
>> L1d cache:32K
>> L1i cache: 32K
>> L2 cache: 256K
>> L3 cache: 25600K
>> NUMA node0 CPU(s): 0-19
>>
>> I think it can handle this rate. Please correct me if i'm Wrong.
>>
>> i have other questions:
>>
>>
>>- There are (synchronizers, equalizers, channel codes etc) blocks in
>>the gr-dvbt project why I cant use them?
>>- when you mentioned channel coding do you mean that i need to create
>>a new one? and Why would I need it?
>>- If i need BCH performance Why is difficult to achieve?
>>- if the data requirement is fine (CPU and etc), what is the best way
>>to start building the receiver? How can I figure out the blocks That i 
>> need
>>for this receiver?
>>
>>
>> Regards
>> Ihab
>>
>>
>> On 23 August 2016 at 14:34, Ihab Zine  wrote:
>>
>>> Hi Ron,
>>>
>>> 1) Frequency range: 1.5 - 38 GHz
>>>
>>> 2) Bandwidth range : 2 - 56 MHz
>>>
>>> 3) Modulation : Qpsk - 256 QAM
>>>
>>> 4) Data rate range : 150Mbit/s - 326Mbit/s.
>>>
>>> 5) Error correction method : i thinks it is FEC.
>>>
>>> Ihab
>>>
>>> On 22 August 2016 at 12:33, Ihab Zine  wrote:
>>>
 Hi All,

 I'm working on a project using GnuRadio And USRP 205 mini, i'm at the
 stage where i need to demodulate a microwave link signal.

 Anyone has an experience with Microwave link or tried to do something 
 similar?
 Is it possiable to do it in gnuradio? or is there another approaches to do
 it?

 I'd appreciate any information you could give me.

 Thanks
 Ihab

>>>
>>>
>>
>
> ___
> 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] Transmit and Receive hopping Sequence in FHSS (using gr-spread module) mismtach

[Dave NotTelling]

I have had issues with scheduling transmissions at ~ 10 ms per hop and
ending up with transmissions happening on the wrong frequencies.  Usually
it's one channel off.  If you slow the system down does everything work
properly?  Also, are you pegging out any single core in your system?  I
have seen lots of issues with scheduling bursts when the CPU utilization is
high or even a single core that's maxed out.

On Fri, Aug 26, 2016 at 3:00 PM, Ajinkya D Kadam 
wrote:

> Dave,
>
> Thanks for replying.
>
> we are hopping every 80ms.
> ᐧ
>
> On Fri, Aug 26, 2016 at 12:32 PM, Dave NotTelling 
> wrote:
>
>> Ajinkya,
>>
>>  How fast are you hopping?  I've had loads of issues with hopping
>> rapidly and not having the correct frequencies used.
>>
>> -Dave
>>
>> On Tue, Aug 23, 2016 at 7:16 PM, Ajinkya D Kadam 
>> wrote:
>>
>>> HI All,
>>>
>>> I am using gr-spread
>>> <https://github.com/CIG-SDR/CIG/tree/master/gr-spread> module to
>>> transmit a signal using FHSS. When I receive the FHSS signal, the received
>>> signal has a completely different hopping sequence as from the transmitted
>>> one. I am using USRP N210 for transmission and reception. I am not sure why
>>> this is happening. The transmitted sequence is (frequencies in Khz)
>>>
>>> 187.5
>>>-12.5
>>>162.5
>>>-62.5
>>> 62.5
>>>137.5
>>>-112.5
>>>-37.5
>>>112.5
>>>-162.5
>>>-137.5
>>>-87.5
>>>12.5
>>>37.5
>>>87.5
>>>
>>>  and the received sequence is
>>>
>>>   37.5
>>>   62.5
>>>   112.5
>>>   -187.5
>>>   12.5
>>>   187.5
>>>  -37.5
>>>   87.5
>>>   162.5
>>>  -87.5
>>>   0
>>>   137.5
>>>  -137.5
>>>  -112.5
>>>   -62.5
>>>   37.5
>>>   62.5
>>>
>>> I have created a movie out of the images which plots the IQ, FFT and
>>> WaterFall plot for the transmitted signal and the received signal using the
>>> "plot_psd_base.py" file in gr-utils. Please have a look at both of them
>>> here <https://drive.google.com/file/d/0B-Ksc0hMVyDVLW11QW1BekJtS0E/view>
>>>  and here
>>> <https://drive.google.com/file/d/0B-Ksc0hMVyDVSmU4YzlBVXA5ZFE/view?usp=sharing>
>>> .
>>>
>>> Please see the attached files for the flowgraphs, I am using as the
>>> transmitter and receiver.
>>>
>>> I have stored the received and transmitted signal to a file. Since these
>>> are large files I have uploaded them to google drive here
>>> <https://drive.google.com/a/nyu.edu/file/d/0B-Ksc0hMVyDVRTdaVTV5ZmhCVkE/view>
>>> .
>>>
>>> Could someone please help me understand the behavior I am observing ?
>>>
>>> Is this some sort of synchronization issue ? What am I missing ?
>>>
>>> Thanks in advance.
>>>
>>> ᐧ
>>>
>>> ___
>>> 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] Transmit and Receive hopping Sequence in FHSS (using gr-spread module) mismtach

[Dave NotTelling]

Ajinkya,

 How fast are you hopping?  I've had loads of issues with hopping
rapidly and not having the correct frequencies used.

-Dave

On Tue, Aug 23, 2016 at 7:16 PM, Ajinkya D Kadam 
wrote:

> HI All,
>
> I am using gr-spread
> <https://github.com/CIG-SDR/CIG/tree/master/gr-spread> module to transmit
> a signal using FHSS. When I receive the FHSS signal, the received signal
> has a completely different hopping sequence as from the transmitted one. I
> am using USRP N210 for transmission and reception. I am not sure why this
> is happening. The transmitted sequence is (frequencies in Khz)
>
> 187.5
>-12.5
>162.5
>-62.5
> 62.5
>137.5
>-112.5
>-37.5
>112.5
>-162.5
>-137.5
>-87.5
>12.5
>37.5
>87.5
>
>  and the received sequence is
>
>   37.5
>   62.5
>   112.5
>   -187.5
>   12.5
>   187.5
>  -37.5
>   87.5
>   162.5
>  -87.5
>   0
>   137.5
>  -137.5
>  -112.5
>   -62.5
>   37.5
>   62.5
>
> I have created a movie out of the images which plots the IQ, FFT and
> WaterFall plot for the transmitted signal and the received signal using the
> "plot_psd_base.py" file in gr-utils. Please have a look at both of them
> here <https://drive.google.com/file/d/0B-Ksc0hMVyDVLW11QW1BekJtS0E/view>
>  and here
> <https://drive.google.com/file/d/0B-Ksc0hMVyDVSmU4YzlBVXA5ZFE/view?usp=sharing>
> .
>
> Please see the attached files for the flowgraphs, I am using as the
> transmitter and receiver.
>
> I have stored the received and transmitted signal to a file. Since these
> are large files I have uploaded them to google drive here
> <https://drive.google.com/a/nyu.edu/file/d/0B-Ksc0hMVyDVRTdaVTV5ZmhCVkE/view>
> .
>
> Could someone please help me understand the behavior I am observing ?
>
> Is this some sort of synchronization issue ? What am I missing ?
>
> Thanks in advance.
>
> ᐧ
>
> ___
> 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] Attribute error: and support with external class and header files

[Dave NotTelling]

I've had bad luck just putting my own headers in OOT modules.  The way I do
things now is to use gr_modtool add and select 'noblock'.  Then just remove
the grc XML file created.  Seems that YourModuleName_API is needed before
structs and classes or it doesn't get seen by Swig.  Could be wrong about
that.  Might just work for me on a fluke =\

On Tue, Aug 23, 2016 at 6:47 AM, Pranav Padalkar <
pranav.padal...@esk.fraunhofer.de> wrote:

> Hello all,
>
>
> I have written a c++ code and I wish to implement as a block in GNURadio.
> I created a module (named "newblocks") and a block (named "my_client) and
> made appropriate changes. The thing is, I have many class and header files
> for my c++ code, for eg. Protobuf. I put those files in a folder called
> "client" inside "include" folder of my module 
> (gr-newblocks/include/newblocks/client).
> It showed no error during cmake, make, make install and ldconfig. But when
> I put the block in the flowgraph and run it, it gives me following error.
>
>
> File "/home/sdr/workspace/develop/Pranav/USRP_client/usrp_client.py",
> line 115, in __init__
> self.newblocks_my_client_0 = newblocks.my_client("123", "8080")
> AttributeError: 'module' object has no attribute 'my_client'
>
>
> I already had a working block in the same module, which I had created
> earlier. And now even that block gives me same error. If I don't use any of
> the two blocks, the flowgraph works fine.
>
>
> I, then, also added a CMakeLists.txt file in that "client" folder and
> entered all the .h and .c files in the text file. I added the entry for
> "client" folder in the "Add subdirectories" part of the CMakeLists.txt in
> (gr-newblocks/ ). Is there anything else I need to do in order to use my
> own class and header files? Do I also need to put the .o files along with
> the header and class files? I tried with both, putting the .o files and not
> putting them, it still shows the same error.
>
> I even created a new module and a new block and copy pasted my code and
> header and class files. I still get the same error. I kindly ask for help
> in this regard. I am using Ubuntu 14.04 LTS, GnuRadio 3.7.9.2, I am using a
> lot of Boost 1.61.
>
>
> Thank you in advance.
>
> Best Regards,
> Pranav Padalkar
> Fraunhofer-Institut für Eingebettete Systeme und Kommunikationstechnik ESK
>
>
> ___
> 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] SWIG std::vector issue

[Dave NotTelling]

Thank you very much Marcus!  I'll give that a go later today :D

On Tue, Aug 2, 2016 at 2:38 AM, Marcus Müller 
wrote:

> Hi Dave,
>
> that's a bit hard to tell without context; generally, Python can construct
> wrapper code for std::vector that makes those iterable, and handles the
> interna a bit different, but with PMTs the non-bracket method of access
> might work:
>
> your_vector_of_pmts_in_python.at(index)
>
> if that works, you can tell SWIG that your vector type should be an
> iterable; try going into your OOT's swig/ootname.i and add a
>
> %include 
>
> pretty much at the beginneing, and make sure to have in your %{%}:
>
> %{
> #include 
> #include 
> %}
>
>
> and further down, declare
>
> %template(ootname_vector_pmt_t) std::vector;
>
> And then hope that SWIG does what you want :(
>
>
> Best regards,
>
> Marcus
> On 01.08.2016 23:49, Dave NotTelling wrote:
>
> Anyone able to help with this?  I had to create helper methods to
> serialize the PMT objects and return a vector of strings.  Not the best
> solution :(
>
> On Thu, Jul 28, 2016 at 11:04 AM, Dave NotTelling 
> wrote:
>
>> I have a utility lib in C++ created with 'gr_modtool add noblock' that
>> has a function that returns a vector of pmt::pmt_t values.  I need to then
>> be able to access the elements of that vector via Python.  Right now I get
>> the following error when using a for loop to iterate over the vector:
>>
>>
>> TypeError: 'SwigPyObject' object is not iterable
>> swig/python detected a memory leak of type 'std::vector<
>> boost::intrusive_ptr< pmt::pmt_base >,std::allocator< boost::intrusive_ptr<
>> pmt::pmt_base > > > *', no destructor found.
>>
>>
>> How does one iterate over the elements of a std::vector in
>> Python?
>>
>> Thanks!
>>
>
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] SWIG std::vector issue

[Dave NotTelling]

Anyone able to help with this?  I had to create helper methods to serialize
the PMT objects and return a vector of strings.  Not the best solution :(

On Thu, Jul 28, 2016 at 11:04 AM, Dave NotTelling 
wrote:

> I have a utility lib in C++ created with 'gr_modtool add noblock' that has
> a function that returns a vector of pmt::pmt_t values.  I need to then be
> able to access the elements of that vector via Python.  Right now I get the
> following error when using a for loop to iterate over the vector:
>
>
> TypeError: 'SwigPyObject' object is not iterable
> swig/python detected a memory leak of type 'std::vector<
> boost::intrusive_ptr< pmt::pmt_base >,std::allocator< boost::intrusive_ptr<
> pmt::pmt_base > > > *', no destructor found.
>
>
> How does one iterate over the elements of a std::vector in
> Python?
>
> Thanks!
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [GSoC] gr-inspector update / ask for feedback

[Dave NotTelling]

Great work!

On Fri, Jul 29, 2016 at 10:36 AM, Sebastian Müller  wrote:

> Hi all,
>
> week 10 of GSoC is over and I managed to implement an OFDM sync block:
> https://grinspector.wordpress.com/2016/07/29/week-10-sync/
>
> Since I make good time, I will try to add a FM demod block to the toolbox.
> Target is to have one example workflow from Ether to demod data (= sound).
>
> Cheers,
> Sebastian
>
> 2016-07-22 16:11 GMT+02:00 Sebastian Müller :
>
>> Hi list,
>>
>> in week 9 of my GSoC I finally managed to implement a working OFDM
>> parameter estimation block. Read here about it:
>> https://grinspector.wordpress.com/2016/07/22/week-9-ofdm-finale/
>>
>> Next up is a frequency and timing synchronization block.
>>
>> Cheers
>> Sebastian
>>
>> 2016-07-18 9:57 GMT+02:00 Sebastian Müller :
>>
>>> Hi Martin,
>>>
>>> I have no problem with keeping the 'old' algo in the toolbox. But still
>>> I'm not sure if it is usable in real-world scenarios with sampling offsets.
>>> Maybe someone can improve it if interested.
>>>
>>> Cheers, Sebastian
>>>
>>> 2016-07-15 19:22 GMT+02:00 Martin Braun :
>>>
 To clarify, if Koslowski's algorithm (since you already coined the
 term...) is *as* good as your original one, but also faster, you should
 not have duplicates. But if you did all the work to create software that
 actually outperforms the fast algorithm in some other aspect, there's no
 harm in keeping it around.

 Cheers,
 M

 On 07/15/2016 10:20 AM, Martin Braun wrote:
 > Sebastian,
 >
 > thanks for sharing, and your awesome work! I would suggest if you have
 > an algorithm with great detection characteristics, you should keep it.
 > If you want another suboptimal but fast one, create a second block (or
 > whatever it is). The first algorithm did cost you time, and its
 superior
 > detection performance might be interesting to other people.
 >
 > Cheers,
 > Martin
 >
 > On 07/15/2016 08:10 AM, Sebastian Müller wrote:
 >> Hi list,
 >>
 >> week 8 of GSoC is over and the latest news on gr-inspector are
 online:
 >>
 https://grinspector.wordpress.com/2016/07/15/week-8-performance-issues/
 >>
 >> This week was a bit disappointing because the algorithm for the OFDM
 >> estimation, which did show nice estimation results, and which I dealt
 >> with 2 weeks now, had to be replaced because of performance issues.
 Now
 >> I'll try a more straight-forward algorithm and hope to get started
 with
 >> synchronization in two weeks.
 >>
 >> Cheers,
 >> Sebastian
 >>
 >> Sebastian Müller mailto:gse...@gmail.com>>
 schrieb am
 >> Fr., 8. Juli 2016 um 13:48 Uhr:
 >>
 >> Hi all,
 >>
 >> week 7 of GSoC is over and I have written a blog post about what
 >> I've been up to:
 >>
 https://grinspector.wordpress.com/2016/07/08/week-7-ofdm-prototype/
 >>
 >> I started implementing an OFDM parameter estimation block in
 python.
 >> Also, I did some performance tests, which look quite good. Next,
 I
 >> will implement this algorithm in C++. Stay tuned!
 >>
 >> Cheers,
 >> Sebastian
 >>
 >> Am 01.07.2016 um 15:37 schrieb Sebastian Müller:
 >>> Hi all,
 >>>
 >>> this week's GSoC blog post is ready! Check it out here:
 >>> https://grinspector.wordpress.com/2016/07/01/week-6-tweaking/
 >>>
 >>> I have finished the GUI so far and improved the Signal
 Separator.
 >>> In the next time I will start with an OFDM parameter estimation,
 >>> so stay tuned.
 >>>
 >>> Cheers,
 >>> Sebastian
 >>>
 >>> 2016-06-28 16:34 GMT+02:00 Sebastian Müller >>> >>> >:
 >>>
 >>> Hi Ben,
 >>>
 >>> thanks for your interest. The manual signal selection is
 like
 >>> the demod function in gqrx. You can move and resize an
 overlay
 >>> that will determine the signal information that gets passed
 >>> downstream. I have not dealt with AMC for now, but based on
 my
 >>> own experience with manual modulation recognition I don't
 see
 >>> a problem when not exactly hitting the signal edges. If your
 >>> concern is too narrow selection, there is an oversampling
 >>> factor parameter in the Signal Separator block, that will
 >>> allow filtering wider than actually from the GUI specified,
 to
 >>> compensate the naturally underestimated bandwidth when using
 >>> energy detection. Also, the GUI now supports zooming so a
 user
 >>> can work really precise if needed :)
 >>>
 >>> Thanks again for the feedback!
 >>> Cheers,
 >>> Sebastian
 >>>
 >>> 2016-06-27 16:

[Discuss-gnuradio] SWIG std::vector issue

[Dave NotTelling]

I have a utility lib in C++ created with 'gr_modtool add noblock' that has
a function that returns a vector of pmt::pmt_t values.  I need to then be
able to access the elements of that vector via Python.  Right now I get the
following error when using a for loop to iterate over the vector:


TypeError: 'SwigPyObject' object is not iterable
swig/python detected a memory leak of type 'std::vector<
boost::intrusive_ptr< pmt::pmt_base >,std::allocator< boost::intrusive_ptr<
pmt::pmt_base > > > *', no destructor found.


How does one iterate over the elements of a std::vector in
Python?

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

Re: [Discuss-gnuradio] Streaming IQ File Compression

[Dave NotTelling]

Marcus,

 Thanks for the idea anyway :)  It sounded like a really neat outside
the box idea.


I ran some quick tests with FLAC and found that it does a really good job
compressing a constant filtered gaussian noise output.  I just created a
flow graph with:

 fast noise source [float] -> low pass filter [float] -> float to short
-> file sink

The filter was just there so that the spectrum wasn't completely flat.
Running the signal through FLAC with little endian, 16 bit, single channel
resulted in a 2GB file ending up at ~ 400 MB.  But, that was just a
constant signal.  I need to throw some 900 MHz captures through to see how
that works.

I also found someone who modified FLAC to be multithreaded [1] as well as a
CUDA implementation (windows only) [2]

[1] https://www.akalin.com/parallelizing-flac-encoding
[2] http://www.cuetools.net/wiki/FLACCL

On Sun, Jul 17, 2016 at 7:49 AM, Marcus Müller 
wrote:

> Well, having wasted a couple of hours of sleep time on this, maybe you
> shouldn't do the logarithmic storage... at its core its the same idea as
> storing floating point, but with a fixed mantissa.
>
> The mathematical effects of the "rounding to the nearest exponential step"
> on superimposed sinusoids of different amplitude are … funky.
>
> Best regards,
>
> Marcus
>
> On 16.07.2016 21:57, Juha Vierinen wrote:
>
> Can you reduce the number of bits that you are using?
>
> With radar signals, the receiver noise most of the time excites only about
> 8 bits out of 16. Ground clutter or meteor echoes excite nearly all of the
> bits occasionally, so I can't just truncate to 8 bits. In this case, bzip2
> actually does a pretty good job of getting rid of the 8/16 most significant
> bits that are zero most of the time. Thus, I get a compression ratio close
> to 50% when using sc16. pbzip2 is a good tool for doing parallel
> compression on files.
>
> juha
>
> On Sat, Jul 16, 2016 at 3:59 AM, Dave NotTelling 
> wrote:
>
>> Anyone have experience with streaming 100+ MSPS of 16 bit IQ data through
>> a compression tool and then to disk?  I'd like to be able to take really
>> wide band snaps for several minutes.  Currently that would take up 16 * 2 *
>> SAMP_RATE bits per second.  So, for 200 MSPS that would end up being 800
>> MBytes/s.  That rate eats up a hard drive pretty quickly.  Running it
>> through gzip by way of pigz was my first thought, but even on an 8 core
>> Intel machine pigz just can't keep up.  I can sustain maybe 300 MBytes/s
>> but that's it.  And I know it's not a hard disk limitation as the M.2 drive
>> I am using can easily sustain 800 MBytes/s of uncompressed data.
>>
>> Thoughts?
>>
>> Thank you!
>>
>>
>> -Dave
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Streaming IQ File Compression

[Dave NotTelling]

Chris,

 Excellent, then I will start benchmarking tomorrow :)

Thanks!

On Sat, Jul 16, 2016 at 9:35 PM, Chris Kuethe 
wrote:

> Flac doesn't really need to know what the actual sample rate is; you
> could tell it 500e3 and you should get the same data out after
> compressing and decompressing it.
>
> On Sat, Jul 16, 2016 at 11:20 AM, Dave NotTelling 
> wrote:
> > Marcus & Dan,
> >
> >  Thank you very, very much for the detailed information!
> >
> > Dan: That's exactly what I thought when going into this at first.  But, I
> > decided to give gzip a shot just to see how well it did.  Turns out that
> (at
> > least for bursty environments) it almost halves the size of the original
> > file.  It should be noted that the file was in fc32 format so there were
> > likely a lot of unused bits there (or so I guess).
> >
> > Marcus: I have been giving thought to truncating some of the bits.
> Going as
> > far as thinking about dropping from sc16 to sc8.  I have worked with 8
> bit
> > sample files before and had plenty of success demodulating, so I'm
> thinking
> > that it might be an okay path to go down.  Dynamic range goes to hell,
> but
> > it it's worked in the past...  I think that re-packing as 12 bit would
> give
> > considerable space savings without a lot of CPU overhead.  I'll have to
> give
> > that one a go :)  I really like your idea of using FLAC.  Just a quick
> > Google search netted
> http://www.rtl-sdr.com/compressing-filtering-iq-data/.
> > What concerns me is that when I tried to use the command line flac in
> Ubuntu
> > it said that the sample rate must be between 1 and 655349 Hz.  I'll have
> to
> > poke around at it to see what happens when I set an incorrect bit rate
> > (maybe a multiple of will be fine?).
> >
> > Thank you both!
> >
> > -Dave
> >
> > On Sat, Jul 16, 2016 at 5:14 AM, Marcus Müller  >
> > wrote:
> >>
> >> Ah!
> >>
> >> On 16.07.2016 11:04, Marcus Müller wrote:
> >> > and maybe, but this is really speculation, you can just modify the
> >> > error calculation to just ignore the 4 lower bits of the actual sample
> >> > data, and safe another few percents of data volume.
> >> Yeah, there's a FLAC__stream_encoder_set_bits_per_sample[0] function--
> >> guess that you don't need to modify anything. Also, there's a whole
> >> listing of things .._set_compression_level[1] sets internally. This
> >> approach (using FLAC as lossless waveform encoder) might be really
> >> interesting.
> >>
> >>
> >>
> >> [0]
> >>
> >>
> https://xiph.org/flac/api/group__flac__stream__encoder.html#gabfa3c989377785cda7c496b69dcb98cb
> >> [1]
> >>
> >>
> https://xiph.org/flac/api/group__flac__stream__encoder.html#ga07fc8c7806381a055a1eef26387e509f
> >>
> >> ___
> >> 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
> >
>
>
>
> --
> GDB has a 'break' feature; why doesn't it have 'fix' too?
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Streaming IQ File Compression

[Dave NotTelling]

Juha,

 I'm worried about truncating too far because I could be close to the
emitters which would cause a large SNR which (as far as I understand) also
means more dynamic range.  Losing bits will chop dynamic range :(  Now, I
assume that as long as I am on top of the RX gain I can ensure that I don't
get massive SNR signals thus not needing the extra bits.  Please correct me
if that's wrong as I'm not 100% sure that's right.

 As for the various parallel compression algorithms, I found a list at
http://askubuntu.com/questions/258202/multi-core-compression-tools (about
half way down) of tools.  I tried out pbzip2 earlier with `cat
largeFile.sc16 | pzip2 -1 | pv > /dev/null` and found that it was only
running at ~ 25 MBytes/s which is too slow.  That number is from my i7
4870HD Macbook Pro.  If I run pgzip with `cat largeFile.sc16 | pigz -1 | pv
> /dev/null` I get around 120 MBytes/s.  Also, the file was stored in
/dev/shm for best results.  I know that my desktop machine which will be
doing the recording can run an sc16 file through at around 300-350 MBytes/s
but that maxes out the entire machine.  Do you know of any tweaks that can
be done to increase the speed with a slight trade off in compression?

Marcus,

 I should probably have stated the problem a little more clearly.  I
would like to be able to record 100+ MHz swaths of busy spectrum.  Think
900 MHz in a busy city or LTE, WiFi, 433 MHz, etc.  Just trying to build up
a large collection of signals to learn how to demodulate with.  I also hope
one day to be able to pull down entire transponders of satellites :D  So,
the basic point here is that there will be a lot going on in the spectrum
that I am recording.  Oh, and the captures could be several minutes long.
Sometimes I find really interesting signals that look crazy in the
waterfall (fosphor) plot so I want to record large files of those to poke
at later.

 I'm really intrigued by your idea of storing the log magnitudes.  It
will take me a bit to wrap my head around it, but it sounds really
interesting :D

Thank you both very much!!

-Dave

On Sat, Jul 16, 2016 at 4:29 PM, Marcus Müller 
wrote:

> Hello Juha,
>
> idea: if Dave's distribution of amplitudes was a little more benign than
> the Radar near/far problem, and he would favor full resolution when the
> signal is weak, but could live with a bit of degradation due to
> quantization when the signal is strong, what about storing a logarithm of
> the I and Q magnitudes instead of their linear value? That way, he could
> get the same weak-signal-resolution with less bits, and only suffer
> inaccuracies due to quantization for situations where signal is strong,
> anyway.
> Best regards,
> Marcus
>
>
> On 16.07.2016 21:57, Juha Vierinen wrote:
>
> Can you reduce the number of bits that you are using?
>
> With radar signals, the receiver noise most of the time excites only about
> 8 bits out of 16. Ground clutter or meteor echoes excite nearly all of the
> bits occasionally, so I can't just truncate to 8 bits. In this case, bzip2
> actually does a pretty good job of getting rid of the 8/16 most significant
> bits that are zero most of the time. Thus, I get a compression ratio close
> to 50% when using sc16. pbzip2 is a good tool for doing parallel
> compression on files.
>
> juha
>
> On Sat, Jul 16, 2016 at 3:59 AM, Dave NotTelling 
> wrote:
>
>> Anyone have experience with streaming 100+ MSPS of 16 bit IQ data through
>> a compression tool and then to disk?  I'd like to be able to take really
>> wide band snaps for several minutes.  Currently that would take up 16 * 2 *
>> SAMP_RATE bits per second.  So, for 200 MSPS that would end up being 800
>> MBytes/s.  That rate eats up a hard drive pretty quickly.  Running it
>> through gzip by way of pigz was my first thought, but even on an 8 core
>> Intel machine pigz just can't keep up.  I can sustain maybe 300 MBytes/s
>> but that's it.  And I know it's not a hard disk limitation as the M.2 drive
>> I am using can easily sustain 800 MBytes/s of uncompressed data.
>>
>> Thoughts?
>>
>> Thank you!
>>
>>
>> -Dave
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Streaming IQ File Compression

[Dave NotTelling]

Marcus & Dan,

 Thank you very, very much for the detailed information!

Dan: That's exactly what I thought when going into this at first.  But, I
decided to give gzip a shot just to see how well it did.  Turns out that
(at least for bursty environments) it almost halves the size of the
original file.  It should be noted that the file was in fc32 format so
there were likely a lot of unused bits there (or so I guess).

Marcus: I have been giving thought to truncating some of the bits.  Going
as far as thinking about dropping from sc16 to sc8.  I have worked with 8
bit sample files before and had plenty of success demodulating, so I'm
thinking that it might be an okay path to go down.  Dynamic range goes to
hell, but it it's worked in the past...  I think that re-packing as 12 bit
would give considerable space savings without a lot of CPU overhead.  I'll
have to give that one a go :)  I really like your idea of using FLAC.  Just
a quick Google search netted
http://www.rtl-sdr.com/compressing-filtering-iq-data/.  What concerns me is
that when I tried to use the command line flac in Ubuntu it said that the
sample rate must be between 1 and 655349 Hz.  I'll have to poke around at
it to see what happens when I set an incorrect bit rate (maybe a multiple
of will be fine?).

Thank you both!

-Dave

On Sat, Jul 16, 2016 at 5:14 AM, Marcus Müller 
wrote:

> Ah!
>
> On 16.07.2016 11:04, Marcus Müller wrote:
> > and maybe, but this is really speculation, you can just modify the
> > error calculation to just ignore the 4 lower bits of the actual sample
> > data, and safe another few percents of data volume.
> Yeah, there's a FLAC__stream_encoder_set_bits_per_sample[0] function--
> guess that you don't need to modify anything. Also, there's a whole
> listing of things .._set_compression_level[1] sets internally. This
> approach (using FLAC as lossless waveform encoder) might be really
> interesting.
>
>
>
> [0]
>
> https://xiph.org/flac/api/group__flac__stream__encoder.html#gabfa3c989377785cda7c496b69dcb98cb
> [1]
>
> https://xiph.org/flac/api/group__flac__stream__encoder.html#ga07fc8c7806381a055a1eef26387e509f
>
> ___
> 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] Streaming IQ File Compression

[Dave NotTelling]

Anyone have experience with streaming 100+ MSPS of 16 bit IQ data through a
compression tool and then to disk?  I'd like to be able to take really wide
band snaps for several minutes.  Currently that would take up 16 * 2 *
SAMP_RATE bits per second.  So, for 200 MSPS that would end up being 800
MBytes/s.  That rate eats up a hard drive pretty quickly.  Running it
through gzip by way of pigz was my first thought, but even on an 8 core
Intel machine pigz just can't keep up.  I can sustain maybe 300 MBytes/s
but that's it.  And I know it's not a hard disk limitation as the M.2 drive
I am using can easily sustain 800 MBytes/s of uncompressed data.

Thoughts?

Thank you!


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

Re: [Discuss-gnuradio] Installation of GNU Radio/UHD on Windows

[Dave]

Geof,

 

Thanks for the input.  Here is what I get when running gnuradio_companion for 
the bin directory after running run_gr.bat.  I’m not a programmer so I don’t 
know what all to look for.  I used the application rapid environment editor to 
see what my environment variables were.  I don’t see a PYTHONPATH variable nor 
do I see any entries in PATH related to GNURadio other than a path to the bin 
directory which I added manually.  

D:\Program Files\GNURadio-3.7\bin>gunradio_companion

'gunradio_companion' is not recognized as an internal or external command,

operable program or batch file.

 

D:\Program Files\GNURadio-3.7\bin>run_gr.bat

setting gnuradio environment

Microsoft Windows [Version 6.1.7601]

Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

 

D:\Program Files\GNURadio-3.7\bin>gnuradio-companion.py

ImportError

 

Cannot import gnuradio.

 

Is the python path environment variable set correctly?

All OS: PYTHONPATH

 

Is the library path environment variable set correctly?

Linux: LD_LIBRARY_PATH

Windows: PATH

MacOSX: DYLD_LIBRARY_PATH

 

 

(DLL load failed: %1 is not a valid Win32 application.)

 

D:\Program Files\GNURadio-3.7\bin>

 

 

If I run gnuradio comanion from the start menu, it does seem to load correctly 
however the WBFM receive example does not execute.  I get “python.exe has 
stopped working” windows error and the following in the grc window.

 

Generating: 'D:\\Program 
Files\\GNURadio-3.7\\share\\gnuradio\\examples\\uhd\\uhd_wbfm_receive.py'

 

Executing: D:\Program Files\GNURadio-3.7\gr-python27\python.exe -u D:\Program 
Files\GNURadio-3.7\share\gnuradio\examples\uhd\uhd_wbfm_receive.py

 

Win32; Microsoft Visual C++ version 14.0; Boost_106000; 
UHD_003.009.003-0-unknown

 

-- USRP-B100 clock control: 10

--   r_counter: 2

--   a_counter: 0

--   b_counter: 20

--   prescaler: 8

--   vco_divider: 5

--   chan_divider: 5

--   vco_rate: 1600.00MHz

--   chan_rate: 320.00MHz

--   out_rate: 64.00MHz

-- 

-- Loading FPGA image: D:\Program 
Files\GNURadio-3.7\share\uhd\images\usrp_b100_fpga.bin... done

Using Volk machine: avx

fft_impl_fftw: J[1]\Users\Dav1\AppData\Roaming\.gr_fftw_wisdom: Invalid argument

 

As a side note, I have installed the software to my D: drive rather than C: if 
that matters.

Also, when loading gqrx all of the buttons below the menu appear however none 
of them have labels (although you can see a description when you hover over the 
button).

 

Thanks for all you help.

 

Dave

 

From: Geof Nieboer [mailto:gnieb...@corpcomm.net] 
Sent: Wednesday, July 13, 2016 2:04 PM
To: Derek Kozel
Cc: Dave; GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] Installation of GNU Radio/UHD on Windows

 

Derek/Dave,

 

My development equipment is still in transit so I can't look at anything until 
Monday, but...

 

The UHD build should be 64-bit, so it is mostly likely a labelling issue.  But 
I will check to be sure.  

 

If you want to run -any- GNURadio utilities, I recommend doing so from the 
GNURadio Command Prompt (shortcut in start menu or run_gr.bat in the /bin 
subdir) ... that will set all the Python/etc environment variables up 
correctly.  Then you should not need to specify where the UHD images are.

 

Geof

 

 

On Tue, Jul 12, 2016 at 10:11 PM, Derek Kozel  wrote:

Hi Dave,

Yes, there is no state held in UHD so you will always need to include the 
--args "fw.." in your UHD commands. I should have also mentioned that this 
means you will need to add that exact "fw= D:\Program 
Files\GNURadio-3.7\share\uhd\images\usrp_b100_fw.ihx,fpga= D:\Program 
Files\GNURadio-3.7\share\uhd\images\usrp_b100_fpga.bin" string in the USRP 
Source or Sink block Device Arguments field for any GNU Radio flowgraph. You 
can try modifying the wbfm example for instance.

The ability to specify specific FPGA and firmware images is usually a 
development feature if you have multiple versions of UHD installed alongside 
each other or are building custom images. In this case we are using it to get 
around a path problem.

 

If you create the D:\Program Files\UHD\share\uhd\images\... folder with images 
UHD will hopefully pick them up automatically. I have not tried a Windows 
install where D is the system drive so I'm unsure of the exact behavior.

Ok, I had the wrong python command there, but python itself did run. Here's a 
line which certainly should work, but there's likely nothing additional to be 
gained by running it.
python -c "import gnuradio; print gnuradio"

Regards,

Derek

 

On Tue, Jul 12, 2016 at 7:02 PM, Dave  wrote:

Derek,

 

I ran rx_samles _to_file.  Although using the location arrguments you gave me 
for uhd_find_devices allows for the B100 to be found it does not look like the 
knowledge of where the images are located is retained.  Running the 
samles_to_file  command again results in a con

Re: [Discuss-gnuradio] CppUnit Issue

[Dave NotTelling]

That one doesn't output the message or line number either.  Event '-VV'
doesn't show the message.

On Wed, Jul 13, 2016 at 12:47 PM, Marcus Müller 
wrote:

> Maybe it was 'ctest -V' ? inconsistent capitalization always confuses me...
>
>
> On 07/13/2016 06:44 PM, Dave NotTelling wrote:
>
> Marcus,
>
>  I was not aware of the ctest application.  Thank you for that!  Sadly
> 'ctest -v', 'ctest -V', 'ctest -VV', 'ctest --output-on-failure' and 'ctest
> --debug' all fail to print the message or line number.  Seems the only
> thing that I can do is dump the XML file in lib/.unittests.  Not ideal, but
> workable.
>
> Thanks!
>
> -Dave
>
> On Wed, Jul 13, 2016 at 11:57 AM, Marcus Müller 
> wrote:
>
>> The actual output is written to XML logs – but if you're interested in
>> seeing it live, I'd recommend just running "ctest -v" from your build
>> directory.
>>
>> Best regards,
>> Marcus
>>
>>
>> On 07/13/2016 03:39 PM, Dave NotTelling wrote:
>>
>> I am trying to test out my OOT module with CppUnit tests, but I am not
>> able to get the message from CPPUNIT_ASSERT_MESSAGE("moo", 1 == 2) to
>> output.  All I get is that the test failed (F).  Just getting that message
>> is terrible for debugging.  Is there a flag I missed somewhere or some
>> configuration that isn't set right?  The only option I have right now is to
>> use an if statement to check the condition, print out a message if the
>> condition fails, and then call CPPUNIT_FAIL() to bomb out.
>>
>> Thank you!
>>
>> -Dave
>>
>>
>> ___
>> Discuss-gnuradio mailing 
>> listDiscuss-gnuradio@gnu.orghttps://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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] CppUnit Issue

[Dave NotTelling]

Marcus,

 I was not aware of the ctest application.  Thank you for that!  Sadly
'ctest -v', 'ctest -V', 'ctest -VV', 'ctest --output-on-failure' and 'ctest
--debug' all fail to print the message or line number.  Seems the only
thing that I can do is dump the XML file in lib/.unittests.  Not ideal, but
workable.

Thanks!

-Dave

On Wed, Jul 13, 2016 at 11:57 AM, Marcus Müller 
wrote:

> The actual output is written to XML logs – but if you're interested in
> seeing it live, I'd recommend just running "ctest -v" from your build
> directory.
>
> Best regards,
> Marcus
>
>
> On 07/13/2016 03:39 PM, Dave NotTelling wrote:
>
> I am trying to test out my OOT module with CppUnit tests, but I am not
> able to get the message from CPPUNIT_ASSERT_MESSAGE("moo", 1 == 2) to
> output.  All I get is that the test failed (F).  Just getting that message
> is terrible for debugging.  Is there a flag I missed somewhere or some
> configuration that isn't set right?  The only option I have right now is to
> use an if statement to check the condition, print out a message if the
> condition fails, and then call CPPUNIT_FAIL() to bomb out.
>
> Thank you!
>
> -Dave
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] CppUnit Issue

[Dave NotTelling]

I am trying to test out my OOT module with CppUnit tests, but I am not able
to get the message from CPPUNIT_ASSERT_MESSAGE("moo", 1 == 2) to output.
All I get is that the test failed (F).  Just getting that message is
terrible for debugging.  Is there a flag I missed somewhere or some
configuration that isn't set right?  The only option I have right now is to
use an if statement to check the condition, print out a message if the
condition fails, and then call CPPUNIT_FAIL() to bomb out.

Thank you!

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

Re: [Discuss-gnuradio] Installation of GNU Radio/UHD on Windows

[Dave]

Derek,

 

I ran rx_samles _to_file.  Although using the location arrguments you gave me 
for uhd_find_devices allows for the B100 to be found it does not look like the 
knowledge of where the images are located is retained.  Running the 
samles_to_file  command again results in a condition where firmware could not 
be found.

 

D:\Program Files\GNURadio-3.7\share\uhd\examples>rx_samples_to_file

Win32; Microsoft Visual C++ version 14.0; Boost_106000; 
UHD_003.009.003-0-unknown

 

 

Creating the usrp device with: ...

 

UHD Warning:

Could not locate B100 firmware. As an Administrator, please run:

"C:\Program Files\UHD\lib\uhd\utils\uhd_images_downloader.py"

Error: LookupError: KeyError: No devices found for ->

Empty Device Address

 

I also ran the python command you gave me with the results to follow:

 

 

D:\Program Files\GNURadio-3.7>python.exe -c "from gruel import pmt; print pmt"

Traceback (most recent call last):

  File "", line 1, in 

ImportError: No module named gruel

 

D:\Program Files\GNURadio-3.7>

 

If there is anything else you want me to run, I will do so.

 

Dave

 

From: Derek Kozel [mailto:derek.ko...@ettus.com] 
Sent: Tuesday, July 12, 2016 6:29 PM
To: Dave
Cc: GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] Installation of GNU Radio/UHD on Windows

 

Hi Dave,

I'm glad that the B100 was able to be detected. If you want to confirm that it 
is fully operating you could run any of the examples included with UHD, for 
instance uhd_benchmark_rate or rx_samples_to_file. These are standalone from 
GNU Radio so should avoid whatever Python issue may exist.

I've just noticed, the UHD version installed is Win32. I'm surprised at this as 
the GNU Radio binary builds are all 64 bit. If the developer of these Windows 
binary installers sees the thread hopefully he can comment.

GNU Radio is certainly easier to use on Linux or OS X, but there is a desire to 
see Windows support improve over time. This may not happen quickly, but it's a 
great sign that binary installers exist at all and I believe that most if not 
all of the changes which were needed to make that possible are now in the 
latest releases.

The binary installer at the moment includes it's own Python install in order to 
minimize external dependencies and possible conflicts. I haven't seen the 
"Stopped working" error before, it would be interesting to find out why. If you 
have the time and curiosity, could you try running a super simple flow graph 
such as a signal source into a null sink? This will have minimal complexity and 
test if GNU Radio runs on it's own without any hardware interactions. The 
gr_fftw_wisdom warning can be ignored.

Can you test the Python install? Here is a very simple command which should 
execute. I'm on Linux so cannot test it at the moment.
python.exe -c "from gruel import pmt; print pmt"

 

Regards,

Derek

 

On Tue, Jul 12, 2016 at 6:08 PM, Dave  wrote:

Derek, 

 

More success and a new problem.  I used the example uhd_find_devices arguments 
you show below modified for my system and the device was correctly found.  Note 
the windows installer does not create a UHD folder in the Program Files folder 
but rather in the GnuRadio-3.7\share folder.

 

After finding the device I tested it using the uhd_wbfm_receive example and got 
and error “python.exe has stopped working”.  Below is the transcript.  I guess 
at this point, I’m not looking for solutions.  I’m guessing windows installs 
are just not prime time yet and if we solve this next problem another will 
install issues will take its place.  However, I will keep reporting problems if 
it means something to the developers.   Thank you very much for your help!

 

 

Generating: 'D:\\Program 
Files\\GNURadio-3.7\\share\\gnuradio\\examples\\uhd\\uhd_wbfm_receive.py'

 

Executing: D:\Program Files\GNURadio-3.7\gr-python27\python.exe -u D:\Program 
Files\GNURadio-3.7\share\gnuradio\examples\uhd\uhd_wbfm_receive.py

 

Win32; Microsoft Visual C++ version 14.0; Boost_106000; 
UHD_003.009.003-0-unknown

 

-- USRP-B100 clock control: 10

--   r_counter: 2

--   a_counter: 0

--   b_counter: 20

--   prescaler: 8

--   vco_divider: 5

--   chan_divider: 5

--   vco_rate: 1600.00MHz

--   chan_rate: 320.00MHz

--   out_rate: 64.00MHz

-- 

Using Volk machine: avx

fft_impl_fftw: B[1]\Users\Dav1\AppData\Roaming\.gr_fftw_wisdom: Invalid argument

 

 

 

 

From: Derek Kozel [mailto:derek.ko...@ettus.com] 
Sent: Tuesday, July 12, 2016 4:51 PM


To: Dave
Cc: GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] Installation of GNU Radio/UHD on Windows

 

Hi Dave,

 

That's great news. This means the B100 is being found.

The images downloader is a Python script. Do you have a D:\Program Files\UHD 
folder? Can you look there to see if the uhd_images_downloader.py script is 
install

Re: [Discuss-gnuradio] Installation of GNU Radio/UHD on Windows

[Dave]

Derek, 

 

More success and a new problem.  I used the example uhd_find_devices arguments 
you show below modified for my system and the device was correctly found.  Note 
the windows installer does not create a UHD folder in the Program Files folder 
but rather in the GnuRadio-3.7\share folder.

 

After finding the device I tested it using the uhd_wbfm_receive example and got 
and error “python.exe has stopped working”.  Below is the transcript.  I guess 
at this point, I’m not looking for solutions.  I’m guessing windows installs 
are just not prime time yet and if we solve this next problem another will 
install issues will take its place.  However, I will keep reporting problems if 
it means something to the developers.   Thank you very much for your help!

 

 

Generating: 'D:\\Program 
Files\\GNURadio-3.7\\share\\gnuradio\\examples\\uhd\\uhd_wbfm_receive.py'

 

Executing: D:\Program Files\GNURadio-3.7\gr-python27\python.exe -u D:\Program 
Files\GNURadio-3.7\share\gnuradio\examples\uhd\uhd_wbfm_receive.py

 

Win32; Microsoft Visual C++ version 14.0; Boost_106000; 
UHD_003.009.003-0-unknown

 

-- USRP-B100 clock control: 10

--   r_counter: 2

--   a_counter: 0

--   b_counter: 20

--   prescaler: 8

--   vco_divider: 5

--   chan_divider: 5

--   vco_rate: 1600.00MHz

--   chan_rate: 320.00MHz

--   out_rate: 64.00MHz

-- 

Using Volk machine: avx

fft_impl_fftw: B[1]\Users\Dav1\AppData\Roaming\.gr_fftw_wisdom: Invalid argument

 

 

 

 

From: Derek Kozel [mailto:derek.ko...@ettus.com] 
Sent: Tuesday, July 12, 2016 4:51 PM
To: Dave
Cc: GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] Installation of GNU Radio/UHD on Windows

 

Hi Dave,

 

That's great news. This means the B100 is being found.

The images downloader is a Python script. Do you have a D:\Program Files\UHD 
folder? Can you look there to see if the uhd_images_downloader.py script is 
installed?

If, and I believe this is the case, the GNU Radio binary installer you are 
using has the release version of UHD 3.9.3 then you can manually download the 
images here:
http://files.ettus.com/binaries/images/uhd-images_003.009.003-release.zip

I'm not sure the exact folder they should be unzipped into for the UHD library 
to find them given the custom build (UHD isn't usually in the GNU Radio bin 
folder). However you can download the files, extract them somewhere (into 
D:\Program Files\UHD\share\uhd\images if the UHD folder already exists) and try 
manually specifying the fw and fpga paths.

For example but modify as needed:

uhd_find_devices --args "fw= D:\Program 
Files\UHD\share\uhd\images\usrp_b100_fw.ihx,fpga= D:\Program 
Files\UHD\share\uhd\images\usrp_b100_fpga.bin"

Regards,

Derek

 

On Tue, Jul 12, 2016 at 4:05 PM, Dave  wrote:

Thanks Derek,

 

I tried using Admin privileges and that did not make a difference.  I believe 
all the ports on my machine are USB3 however I’m not sure they use exactly the 
same hardware.  In any event I tried another one and it did make a difference.  
I now get the message below regarding the need to run uhd_images_downloader.  I 
ran it (also below) and it indicates it needs me to specify a device however I 
have not figured out the correct way to do that.  Note:  All the images appear 
to be already on the machine in the share/uhd/images directory.  Also as you 
see below the message states to run 
C:\ProgramFiles\UHD\lib\utils\uhd_images_dowloader.py.  My installation is on 
the D: drive not the C: drive and the downloader appears to be an .exe file in 
the GNURadio-3.7\bin file.  I don’t know if something is looking for code in 
the wrong places or not.

 

D:\Program Files\GNURadio-3.7\bin>uhd_find_devices

Win32; Microsoft Visual C++ version 14.0; Boost_106000; 
UHD_003.009.003-0-unknown

 

 

UHD Warning:

Could not locate B100 firmware. As an Administrator, please run:

"C:\Program Files\UHD\lib\uhd\utils\uhd_images_downloader.py"

No UHD Devices Found

 

D:\Program Files\GNURadio-3.7\bin>uhd_image_loader.exe

Win32; Microsoft Visual C++ version 14.0; Boost_106000; 
UHD_003.009.003-0-unknown

 

Error: RuntimeError: You must specify a device type.

 

Thanks again,

 

Dave

 

 

From: Derek Kozel [mailto:derek.ko...@ettus.com] 
Sent: Tuesday, July 12, 2016 3:06 PM
To: Dave
Cc: GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] Installation of GNU Radio/UHD on Windows

 

Hello Dave,

Thanks for posting again. I don't know if anyone else has tried the B100 using 
the Windows UHD+GNU Radio binaries. Are you connected to a USB 2 only port or 
to a USB 3 port? I would try a dedicated USB 2 port if possible.

Also, I don't believe that permissions issues exist to the same degree on 
Windows, but can you try running uhd_find_devices in an administrator prompt?

Regards,

Derek

 

On Tue, Jul 12, 2016 at 2:58 PM, Dave  wrote:

I am trying to install GNURadio on a Windows 7,  

Re: [Discuss-gnuradio] Installation of GNU Radio/UHD on Windows

[Dave]

Thanks Derek,

 

I tried using Admin privileges and that did not make a difference.  I believe 
all the ports on my machine are USB3 however I’m not sure they use exactly the 
same hardware.  In any event I tried another one and it did make a difference.  
I now get the message below regarding the need to run uhd_images_downloader.  I 
ran it (also below) and it indicates it needs me to specify a device however I 
have not figured out the correct way to do that.  Note:  All the images appear 
to be already on the machine in the share/uhd/images directory.  Also as you 
see below the message states to run 
C:\ProgramFiles\UHD\lib\utils\uhd_images_dowloader.py.  My installation is on 
the D: drive not the C: drive and the downloader appears to be an .exe file in 
the GNURadio-3.7\bin file.  I don’t know if something is looking for code in 
the wrong places or not.

 

D:\Program Files\GNURadio-3.7\bin>uhd_find_devices

Win32; Microsoft Visual C++ version 14.0; Boost_106000; 
UHD_003.009.003-0-unknown

 

 

UHD Warning:

Could not locate B100 firmware. As an Administrator, please run:

"C:\Program Files\UHD\lib\uhd\utils\uhd_images_downloader.py"

No UHD Devices Found

 

D:\Program Files\GNURadio-3.7\bin>uhd_image_loader.exe

Win32; Microsoft Visual C++ version 14.0; Boost_106000; 
UHD_003.009.003-0-unknown

 

Error: RuntimeError: You must specify a device type.

 

Thanks again,

 

Dave

 

 

From: Derek Kozel [mailto:derek.ko...@ettus.com] 
Sent: Tuesday, July 12, 2016 3:06 PM
To: Dave
Cc: GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] Installation of GNU Radio/UHD on Windows

 

Hello Dave,

Thanks for posting again. I don't know if anyone else has tried the B100 using 
the Windows UHD+GNU Radio binaries. Are you connected to a USB 2 only port or 
to a USB 3 port? I would try a dedicated USB 2 port if possible.

Also, I don't believe that permissions issues exist to the same degree on 
Windows, but can you try running uhd_find_devices in an administrator prompt?

Regards,

Derek

 

On Tue, Jul 12, 2016 at 2:58 PM, Dave  wrote:

I am trying to install GNURadio on a Windows 7,  64 bit  machine for use with a 
Ettus B100 usrp.   I used the gnuradio_3.7.9.2_win64 installer referenced on 
the GNURadio installation guide.

 

When I run uhd_find_devices I get the following:

 

D:\Program Files\GNURadio-3.7\bin>uhd_find_devices

Win32; Microsoft Visual C++ version 14.0; Boost_106000; 
UHD_003.009.003-0-unknown

 

No UHD Devices Found

 

When I look in my device manager I do see a USRPs device show as “Ettus 
Research LCC B100”

 

I posted this issue last week on the USRP discussion list and was advised to 
make sure I had only one instance of UHD.  I discovered I had incorrectly 
installed gnuradio using the installer mentioned above and also installed UHD 
using the installer on the ETTUS website not realizing the GNU radio installer 
took care of both.  I uninstalled GNU radio and uhd and removed everything I 
could find for both.  I then re-ran the gnuradio_3.7.9.2_win64 installer.  I 
still have exactly the same problem shown above with the inability to find the 
device.

 

Note:  I can successfully use gnuradio and the USRP device on this same 
computer using the LiveUSB image thus I don’t believe there are any hardware 
issues.

 

Can anyone provide me more tips on how to troubleshoot my installation?

 

Thanks,

 

Dave

 

 

 


___
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] Installation of GNU Radio/UHD on Windows

[Dave]

I am trying to install GNURadio on a Windows 7,  64 bit  machine for use
with a Ettus B100 usrp.   I used the gnuradio_3.7.9.2_win64 installer
referenced on the GNURadio installation guide.

 

When I run uhd_find_devices I get the following:

 

D:\Program Files\GNURadio-3.7\bin>uhd_find_devices

Win32; Microsoft Visual C++ version 14.0; Boost_106000;
UHD_003.009.003-0-unknown

 

No UHD Devices Found

 

When I look in my device manager I do see a USRPs device show as "Ettus
Research LCC B100"

 

I posted this issue last week on the USRP discussion list and was advised to
make sure I had only one instance of UHD.  I discovered I had incorrectly
installed gnuradio using the installer mentioned above and also installed
UHD using the installer on the ETTUS website not realizing the GNU radio
installer took care of both.  I uninstalled GNU radio and uhd and removed
everything I could find for both.  I then re-ran the gnuradio_3.7.9.2_win64
installer.  I still have exactly the same problem shown above with the
inability to find the device.

 

Note:  I can successfully use gnuradio and the USRP device on this same
computer using the LiveUSB image thus I don't believe there are any hardware
issues.

 

Can anyone provide me more tips on how to troubleshoot my installation?

 

Thanks,

 

Dave

 

 

 

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

Re: [Discuss-gnuradio] Installation of gr-fosphor via PyBombs

[Dave]

Cinaed, Sylvain, Thanks again for all your help.  It is clear I have a lot to 
learn but I appreciate your willingness to step in.

I checked and libglfw3-dev is installed.

This is what I get when I run pybombs install gr-fosphor:

dave@MintJulips:~/pybombsprefix1/bin$ pybombs install gr-fosphor
PyBOMBS - INFO - PyBOMBS Version 2.1.1a
Install tree:
|
\- gr-fosphor
PyBOMBS.install_manager - INFO - Installing package: gr-fosphor
Cloning: (100%) 
[==]
Configuring: (100%) 
[==]
Building:(100%) 
[==]
Installing:  (100%) 
[==]
PyBOMBS.install_manager - INFO - Installation successful.


I don't get the messages you mention below (in reference to Gnuradio enabled 
and disabled components).

I do see fosphor sink (GLFW), QT fosphor sink, and WX fosphor sink in 
gnuradio-companion however they don't seem to work.  I get the following 
message:
X Error: BadValue (integer parameter out of range for 
operation) 2
Extension: 154 (Uknown extension)
Minor opcode: 3 (Unknown request)
Resource id: 0x0
gr::log :INFO: audio source - Audio sink arch: alsa
QGLContext::makeCurrent(): Cannot make invalid context current.
I also tried running osmocom_fft and I get the same error with or without the 
–F option.  I had never tried osmocom_fft before so I don’t know if it had once 
worked before all the fosphor install activitiy.

    dave@MintJulips:~/pybombsprefix1/bin$ osmocom_fft
linux; GNU C++ version 5.3.1 20160413; Boost_105800; 
UHD_003.010.000.git-0-ef57ffcb

gr-osmosdr v0.1.4-72-g164a09fc (0.1.5git) gnuradio 
v3.7.10-1-ge55666b7
built-in source types: file osmosdr fcd rtl rtl_tcp uhd hackrf 
bladerf rfspace airspy redpitaya 
-- USRP-B100 clock control: 10
-- r_counter: 2
-- a_counter: 0
-- b_counter: 20
-- prescaler: 8
-- vco_divider: 5
-- chan_divider: 5
-- vco_rate: 1600.00MHz
-- chan_rate: 320.00MHz
-- out_rate: 64.00MHz
-- 
-- Using subdev spec 'A:0'.
The program 'osmocom_fft' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadValue (integer parameter out of range for 
operation)'.
(Details: serial 496 error_code 2 request_code 154 minor_code 
24)
(Note to programmers: normally, X errors are reported 
asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() 
function.)

>>> Done (return code -11)

Thanks,  Dave


-Original Message-
From: Cinaed Simson [mailto:cinaed.sim...@gmail.com] 
Sent: Saturday, July 09, 2016 8:38 AM
To: Dave; 'Sylvain Munaut'
Cc: 'GNURadio Discussion List'
Subject: Re: [Discuss-gnuradio] Installation of gr-fosphor via PyBombs

On 07/09/2016 01:52 AM, Dave wrote:
> It looks like libfreetype6-dev,  ocl-icd-opencl-dev, and libqt4-opengl-dev 
> are already installed.  I can't find libghc-glfw-dev in my package manager.

Okay, try

  apt-get install libglfw3-dev

If its not already installed, install it and blow away the build directory and 
build it again.

Note, when cmake finishes running, it should print out

-- ##
-- # Gnuradio enabled components
-- ##
--   * Python
--   * GLFW
--   * QT
--   * WX

There should be no components under

-- ##
-- # Gnuradio disabled components
-- ##


The GLFW component - or libglfw3-dev - is the OpenGL package.

If GLFW is disabled it will still successfully install but you wont have OpenGL 
support.

-- Cinaed


> 
> Pybombs says the install of gr-fosphor was successful however I can't find an 
> executable on m

Re: [Discuss-gnuradio] Installation of gr-fosphor via PyBombs

[Dave]

It looks like libfreetype6-dev,  ocl-icd-opencl-dev, and libqt4-opengl-dev are 
already installed.  I can't find libghc-glfw-dev in my package manager.

Pybombs says the install of gr-fosphor was successful however I can't find an 
executable on my system.  Where would it be located.  It does not seem to be 
anywhere in my pybombs prefix directory or anywhere else on the system that I 
can find.   I see the gr-fosphor folder in my src directory but I don't see any 
executables.

Thanks, Dave

-Original Message-
From: Cinaed Simson [mailto:cinaed.sim...@gmail.com] 
Sent: Saturday, July 09, 2016 1:24 AM
To: Sylvain Munaut; Dave
Cc: GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] Installation of gr-fosphor via PyBombs

On 07/08/2016 10:55 PM, Sylvain Munaut wrote:
> Hi,
> 
>> Your suggestion helped.  I got past the x11 error.
>> Now it fails with this line:
>> -- Could NOT find OpenCL (missing: OpenCL_LIBRARY OpenCL_INCLUDE_DIR) 
>> I don't see either one of those entries explicitly in the Ubuntu 
>> package manager so I'm not sure what I should load next.
> 
> Try installing ocl-icd-opencl-dev package
> 
> 
> Cheers,
> 
> Sylvain
> .
> 

After Sylvain's suggestion - which should work - try

  apt-get install libqt4-opengl-dev libghc-glfw-dev

If that works, blow away the build directory and then try building it again.


-- Cinaed



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

Re: [Discuss-gnuradio] Installation of gr-fosphor via PyBombs

[Dave]

You did it again!  I got the message "Installation successful".  Now my last 
hurdle (I hope).  I can't find whatever or wherever  the executable is located.

Thanks for your help,

Dave

-Original Message-
From: Sylvain Munaut [mailto:246...@gmail.com] 
Sent: Friday, July 08, 2016 10:56 PM
To: Dave
Cc: Cinaed Simson; GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] Installation of gr-fosphor via PyBombs

Hi,

> Your suggestion helped.  I got past the x11 error.
> Now it fails with this line:
> -- Could NOT find OpenCL (missing: OpenCL_LIBRARY OpenCL_INCLUDE_DIR) 
> I don't see either one of those entries explicitly in the Ubuntu 
> package manager so I'm not sure what I should load next.

Try installing ocl-icd-opencl-dev package


Cheers,

Sylvain


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

Re: [Discuss-gnuradio] Installation of gr-fosphor via PyBombs

[Dave]

Cinaed,
Your suggestion helped.  I got past the x11 error.
Now it fails with this line:
-- Could NOT find OpenCL (missing: OpenCL_LIBRARY OpenCL_INCLUDE_DIR)
I don't see either one of those entries explicitly in the Ubuntu package
manager so I'm not sure what I should load next.
Again, any help would be appreciated.
Thanks,
Dave

-Original Message-
From: Discuss-gnuradio
[mailto:discuss-gnuradio-bounces+davidcbasham=msn@gnu.org] On Behalf Of
Cinaed Simson
Sent: Friday, July 08, 2016 6:46 PM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Installation of gr-fosphor via PyBombs

Try

   apt-get install cmake xorg-dev libglu1-mesa-dev

-- Cinaed



On 07/08/2016 05:29 PM, Dave wrote:
> I attempted to install gr-fosphor via pybombs and got the following 
> error on an Ubuntu 16.04 machine.
> 
>  
> 
> dave@MintJulips:~/pybombsprefix1/bin$ pybombs install gr-fosphor
> 
> PyBOMBS - INFO - PyBOMBS Version 2.1.1a
> 
> Install tree:
> 
> |
> 
> \- gr-fosphor
> 
> |
> 
> \- glfw3
> 
> |
> 
> \- x11
> 
> PyBOMBS.install_manager - INFO - Installing package: x11
> 
> PyBOMBS.Packager.source - WARNING - Cannot find a source URI for 
> package x11
> 
> PyBOMBS.install_manager - ERROR - Error installing package x11. Aborting.
> 
>  
> 
> I see that gr-fosphor is also available in the ubuntu package manager 
> however it will want to install gnuradio and all the associated 
> dependencies as well.  I assume that will conflict with the 
> installation of gnuradio already performed via pybombs.  Is that 
> correct?  Is there a work around to make the pybombs install of gr-fosphor
work?
> 
>  
> 
> Thanks,  Dave
> 
> 
> 
> ___
> 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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Process for relinquishing driver control in a flowgraph before starting a new one

[Dave NotTelling]

Tim,

 Glad to see that works for you.  For me that ended up leaving things
in a bad state.  The destructor (in C++) of one of my modules wasn't called
unless I set the flowgraph to None and then re-initialized it.  I'll have
to give that a try for my case at some point.

-Dave

On Fri, Jul 8, 2016 at 4:17 PM, Tim Castiglia  wrote:

> I found a workaround that's not so pretty, but it works. Setting the
> flowgraph to None does not work for me because it makes my other python
> threads that are running throw errors. The problem turns out is more of a
> low level hardware problem, or at least that's the case for when I use my
> specific hardware driver.
>
> The file descriptor my hardware was open on was closed, but an error
> occurred when restarting the flowgraph in closing and reopening the file
> descriptor. I cannot track down what exactly is causing the error, but
> instead of fixing it, I just took out the close(fileDescriptor) line in my
> code. This doesn't harm the system because the same file descriptor is use
> anyway when the flowgraph is restarted.
>
> I also realized that having a global flowgraph will be difficult to change
> within python, so I made a wrapper class that holds the flowgraph as a
> member variable, and made the class global instead. On top of this, when I
> restart the flowgraph, I change the wrappers flowgraph, and then set a
> member variable flowgraph in the socket class to be equal to the wrapper's
> flowgraph. This might be overkill, but it works.
>
> #I import that object into my server code
> import flowgraphInit from flowgraph
> #I can also import my other flowgraph
> import newFlowgraphConstructor from flowgraph2
>
> class wrapper():
> __init__(self):
> self.flowgraph = flowgraph
>
> #At global level
> flowgraph = flowgraphInit()
> flowgraph.start()
> wr = wrapper()
>
> class ClientSocketConnection
> __init__(self):
> self.flowgraph = wr.flowgraph
> #other functions
> def onMessage(payload):
> #Parse message
> #If we need to change to a different flowgraph
> wr.flowgraph.stop()
> wr.flowgraph.wait()
> time.sleep(5)
> self.resetFlowgraph()
>
> def resetFlowgraph(self):
> wr.flowgraph = newFlowgraphConstructor()
> wr.flowgraph.start()
> self.flowgraph = wr.flowgraph
>
> def main():
> #create socket factory so we can allow many connections
>
>
> On Fri, Jul 8, 2016 at 10:35 AM, Dave NotTelling 
> wrote:
>
>> Tim,
>>
>>  One thing I have found with the Python stuff is that you need to set
>> the flow graph variable to None for resource to be released.  moo =
>> myGraph(); moo.start(); time.sleep(10); moo.stop(); moo.wait(); moo = None;
>> moo = myGraph(); moo.start() .
>>
>> -Dave
>>
>> On Thu, Jul 7, 2016 at 6:14 PM, Tim Castiglia  wrote:
>>
>>> First I should give some context on my project. What we are trying to
>>> build is a python server that utilizes gnuradio's blocks to get information
>>> from hardware and send it outbound, as well as receiving requests from
>>> clients to the server about configuration of flowgraph. More specifically,
>>> right now, I have:
>>>
>>> Oscom Source -->Log Power FFT --> Vector Probe
>>>
>>> For simplicity, I am using the RTL-SDR for testing purposes. In the
>>> future, we will be using our own device driver created within the SoapySDR
>>> framework, hence why we are using the oscom block.
>>>
>>> The problem starts with the fact that this may not be the only flowgraph
>>> we utilize. The hardware we are using may start pumping out FFT values
>>> instead of IQ values. Which means we would need a flowgraph that looks more
>>> like:
>>>
>>> Oscom Source --> Vector Probe
>>> (Ignore the fact that this is not possible with the oscom block
>>> currently, we will cross that bridge in the future)
>>>
>>> So I need to be able to stop my current running flowgraph, and start a
>>> new one. This is where I run into trouble. I can stop my flowgraph
>>> perfectly fine with:
>>>
>>> flowgraph.stop()
>>> flowgraph.wait()
>>> time.sleep(5)
>>>
>>> But I would like to keep the variable the same in my python code even
>>> when I change the flowgraph. So I try:
>>>
>>> flowgraph = newFlowgraphConstructor()
>>>
>>> But this causes a python error at the flowgraph.stop() line: "variable
>>> mentioned before instantiated"
>

Re: [Discuss-gnuradio] Installation of gr-fosphor via PyBombs

[Dave]

I have and Intel Motherboard and NVIDIA graphics board so I hope that is not an 
issue for me.

-Original Message-
From: Dennis Glatting [mailto:gnura...@pki2.com] 
Sent: Friday, July 08, 2016 5:53 PM
To: Dave; 'GNURadio Discussion List'
Subject: Re: [Discuss-gnuradio] Installation of gr-fosphor via PyBombs

On Fri, 2016-07-08 at 17:29 -0700, Dave wrote:
> I see that gr-fosphor is also available in the ubuntu package manager 
> however it will want to install gnuradio and all the associated 
> dependencies as well.  I assume that will conflict with the 
> installation of gnuradio already performed via pybombs.  Is that 
> correct?  Is there a work around to make the pybombs install of gr- 
> fosphor work?


OpenCL isn't supported well under 16.04 for AMD GPUs.




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

[Discuss-gnuradio] Installation of gr-fosphor via PyBombs

[Dave]

I attempted to install gr-fosphor via pybombs and got the following error on
an Ubuntu 16.04 machine.

 

dave@MintJulips:~/pybombsprefix1/bin$ pybombs install gr-fosphor

PyBOMBS - INFO - PyBOMBS Version 2.1.1a

Install tree:

|

\- gr-fosphor

|

\- glfw3

|

\- x11

PyBOMBS.install_manager - INFO - Installing package: x11

PyBOMBS.Packager.source - WARNING - Cannot find a source URI for package x11

PyBOMBS.install_manager - ERROR - Error installing package x11. Aborting.

 

I see that gr-fosphor is also available in the ubuntu package manager
however it will want to install gnuradio and all the associated dependencies
as well.  I assume that will conflict with the installation of gnuradio
already performed via pybombs.  Is that correct?  Is there a work around to
make the pybombs install of gr-fosphor work?

 

Thanks,  Dave

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

Re: [Discuss-gnuradio] Process for relinquishing driver control in a flowgraph before starting a new one

[Dave NotTelling]

Tim,

 One thing I have found with the Python stuff is that you need to set
the flow graph variable to None for resource to be released.  moo =
myGraph(); moo.start(); time.sleep(10); moo.stop(); moo.wait(); moo = None;
moo = myGraph(); moo.start() .

-Dave

On Thu, Jul 7, 2016 at 6:14 PM, Tim Castiglia  wrote:

> First I should give some context on my project. What we are trying to
> build is a python server that utilizes gnuradio's blocks to get information
> from hardware and send it outbound, as well as receiving requests from
> clients to the server about configuration of flowgraph. More specifically,
> right now, I have:
>
> Oscom Source -->Log Power FFT --> Vector Probe
>
> For simplicity, I am using the RTL-SDR for testing purposes. In the
> future, we will be using our own device driver created within the SoapySDR
> framework, hence why we are using the oscom block.
>
> The problem starts with the fact that this may not be the only flowgraph
> we utilize. The hardware we are using may start pumping out FFT values
> instead of IQ values. Which means we would need a flowgraph that looks more
> like:
>
> Oscom Source --> Vector Probe
> (Ignore the fact that this is not possible with the oscom block currently,
> we will cross that bridge in the future)
>
> So I need to be able to stop my current running flowgraph, and start a new
> one. This is where I run into trouble. I can stop my flowgraph perfectly
> fine with:
>
> flowgraph.stop()
> flowgraph.wait()
> time.sleep(5)
>
> But I would like to keep the variable the same in my python code even when
> I change the flowgraph. So I try:
>
> flowgraph = newFlowgraphConstructor()
>
> But this causes a python error at the flowgraph.stop() line: "variable
> mentioned before instantiated"
>
> To get around this, I made a resetFlowgraph function:
> def resetFlowgraph():
> flowgraph = newFlowgraphConstructor()
> flowgraph.start()
>
> and call things in this order:
> flowgraph.stop()
> flowgraph.wait()
> time.sleep(5)
> resetFlowgraph()
>
> The flowgraph starts successfully, but fails to "claim" the RTL-SDR from
> the old flowgraph. I have also tried the same with only my device plugged
> in, and a similar problem occurs. Is there a way to force the flowgraph to
> relinquish its hold on the hardware? Our python server code needs to
> continue running, so I need to be able to do this restart without ending
> the program (The idea is to have the server always be running and not be
> manned most of the time).
>
> Here's some pseudo code to give you an idea of how the code is structured:
>
> #First I have a premade object generated from gnuradio-companion
> #I import that object into my server code
> import flowgraphInit from flowgraph
> #I can also import my other flowgraph
> import newFlowgraphConstructor from flowgraph2
>
> #At global level
> flowgraph = flowgraphInit()
> flowgraph.start()
>
> class ClientSocketConnection
> ...#init and other functions
> def onMessage(payload):
> #Parse message
> #If we need to change to a different flowgraph
> flowgraph.stop()
> flowgraph.wait()
> time.sleep(5)
> resetFlowgraph()
>
> def resetFlowgraph():
> flowgraph = newFlowgraphConstructor()
> flowgraph.start()
>
> def main():
> #create socket factory so we can allow many connections
> #So there is only one flowgraph, but many people can see it and
> potentially change it
>
> (I have seen this question asked before here
> https://lists.gnu.org/archive/html/discuss-gnuradio/2014-01/msg00411.html
> but there was no solution in the thread)
>
> Any help is appreciated!
>
> ___
> 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] Issues with Pybombs and Package Manager Install on Ubuntu 16.04

[Dave]

Thanks Derek and Martin.

 

I followed the instructions regarding permission access to USB.  I’m not 
positive but I think I had to rerun setup_env.sh as well.   Now 
uhd_find_devices functions as expected.  Thanks you.  I ran the 
uhd_wbfm_receive flow graph.  At first I did not get any audio.  I don’t know 
why but looking in my sound settings, the audio was going to Digital Output 
rather than Headphones output (never did that before).  You will see at the 
bottom of the transcript below  that there are UHD warnings  and an 
“Environment Error” but it is not clear to me if I need to address them.  I 
will do more homework.

 

One more question however, should I run volk_profile or did the pybombs install 
already take care of that?

 

One more comment, it seemed previously I could just type the python script 
names our click on a script in my file manager.  Now I need to precede the 
scripts with ./ and clicking on scripts in the file manager no longer executes 
them.  Again I will do more homework on my own.

 

Thanks again for all your help.


Dave

 

Generating: 
'/home/dave/pybombsprefix1/share/gnuradio/examples/uhd/uhd_wbfm_receive.py'

Executing: /usr/bin/python2 -u 
/home/dave/pybombsprefix1/share/gnuradio/examples/uhd/uhd_wbfm_receive.py

linux; GNU C++ version 5.3.1 20160413; Boost_105800; 
UHD_003.010.000.git-0-ef57ffcb

-- USRP-B100 clock control: 10

-- r_counter: 2

-- a_counter: 0

-- b_counter: 20

-- prescaler: 8

-- vco_divider: 5

-- chan_divider: 5

-- vco_rate: 1600.00MHz

-- chan_rate: 320.00MHz

-- out_rate: 64.00MHz

-- 

UHD Warning:

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

gr::log :INFO: audio source - Audio sink arch: alsa

Volk warning: no arch found, returning generic impl

 

 

 

 

 

From: Derek Kozel [mailto:derek.ko...@ettus.com] 
Sent: Thursday, July 07, 2016 2:58 PM
To: Dave
Cc: Martin Braun; GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] Issues with Pybombs and Package Manager Install 
on Ubuntu 16.04

 

Hello Dave,

Here are the instructions for setting up USB permissions on Linux.
http://files.ettus.com/manual/page_transport.html#transport_usb_udev

Regards,

Derek

 

On Thu, Jul 7, 2016 at 2:19 PM, Dave  wrote:

Thanks Martin.

I successfully deleted UHD and I believe successfully installed gnuradio et el 
using pybombs.  I then ran setup_env.sh.

However now I cannot seem to connect to the B100.

I ran uhd_find_devices and followed the instructions to download images as per 
the transcript that follows.  Was PyBombs supposed to take care of downloading 
the images?  If not, it seems the pybombs instructions should tell one to do so.

In any event per the following transcript it now appears I have a permission 
issue to access my USB ports.Any advice as to what to do next?

Thanks,  Dave

Transcript of error follows.

dave@MintJulips:~/pybombsprefix1$ . ./setup_env.sh

dave@MintJulips:~/pybombsprefix1/bin$ uhd_find_devices

linux; GNU C++ version 5.3.1 20160413; Boost_105800; 
UHD_003.010.000.git-0-ef57ffcb

 

UHD Warning:

Could not locate B100 firmware. Please run:

     "/home/dave/pybombsprefix1/lib/uhd/utils/uhd_images_downloader.py"

No UHD Devices Found

dave@MintJulips:~/pybombsprefix1/bin$ 
/home/dave/pybombsprefix1/lib/uhd/utils/uhd_images_downloader.py

Images destination:  /home/dave/pybombsprefix1/share/uhd/images

Downloading images from: 
http://files.ettus.com/binaries/images/uhd-images_003.010.git-197-g053111dc.zip

Downloading images to:   /tmp/tmpi2vldX/uhd-images_003.010.git-197-g053111dc.zip

52600 kB / 52600 kB (100%)

Images successfully installed to: /home/dave/pybombsprefix1/share/uhd/images

dave@MintJulips:~/pybombsprefix1/bin$ uhd_find_devices

linux; GNU C++ version 5.3.1 20160413; Boost_105800; 
UHD_003.010.000.git-0-ef57ffcb

 

UHD Error:

USB open failed: insufficient permissions.

See the application notes for your device.

No UHD Devices Found

End of transcript...

-Original Message-
From: Discuss-gnuradio 
[mailto:discuss-gnuradio-bounces+davidcbasham=msn@gnu.org] On Behalf Of 
Martin Braun
Sent: Thursday, July 07, 2016 10:05 AM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Issues with Pybombs and Package Manager Install 
on Ubuntu 16.04

On 07/06/2016 11:53 PM, Dave wrote:

> Thanks Martin.  I have changed my subscription to individual messages.

> 

> I ran the command you mentioned below and attached the result.  I’m 

> not sure if I should delete all the entries listed or even why I get 

> all the “permission denied” messages.  As you will see I executed the 

> command both with and without “sudo”.

> 

> dave@MintJulips:~$ find / -name multi_usrp.hpp

> 

> find: ‘/sys/kernel/debu

Re: [Discuss-gnuradio] Issues with Pybombs and Package Manager Install on Ubuntu 16.04

[Dave]

Thanks Martin.

I successfully deleted UHD and I believe successfully installed gnuradio et
el using pybombs.  I then ran setup_env.sh.

However now I cannot seem to connect to the B100.

I ran uhd_find_devices and followed the instructions to download images as
per the transcript that follows.  Was PyBombs supposed to take care of
downloading the images?  If not, it seems the pybombs instructions should
tell one to do so.

In any event per the following transcript it now appears I have a permission
issue to access my USB ports.Any advice as to what to do next?

Thanks,  Dave

Transcript of error follows.

dave@MintJulips:~/pybombsprefix1$ . ./setup_env.sh

dave@MintJulips:~/pybombsprefix1/bin$ uhd_find_devices
linux; GNU C++ version 5.3.1 20160413; Boost_105800;
UHD_003.010.000.git-0-ef57ffcb


UHD Warning:
Could not locate B100 firmware. Please run:

"/home/dave/pybombsprefix1/lib/uhd/utils/uhd_images_downloader.py"
No UHD Devices Found
    dave@MintJulips:~/pybombsprefix1/bin$
/home/dave/pybombsprefix1/lib/uhd/utils/uhd_images_downloader.py
Images destination:
/home/dave/pybombsprefix1/share/uhd/images
Downloading images from:
http://files.ettus.com/binaries/images/uhd-images_003.010.git-197-g053111dc.
zip
Downloading images to:
/tmp/tmpi2vldX/uhd-images_003.010.git-197-g053111dc.zip
52600 kB / 52600 kB (100%)

Images successfully installed to:
/home/dave/pybombsprefix1/share/uhd/images
    dave@MintJulips:~/pybombsprefix1/bin$ uhd_find_devices
linux; GNU C++ version 5.3.1 20160413; Boost_105800;
UHD_003.010.000.git-0-ef57ffcb


UHD Error:
USB open failed: insufficient permissions.
See the application notes for your device.
No UHD Devices Found

End of transcript...


-Original Message-
From: Discuss-gnuradio
[mailto:discuss-gnuradio-bounces+davidcbasham=msn@gnu.org] On Behalf Of
Martin Braun
Sent: Thursday, July 07, 2016 10:05 AM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Issues with Pybombs and Package Manager
Install on Ubuntu 16.04

On 07/06/2016 11:53 PM, Dave wrote:
> Thanks Martin.  I have changed my subscription to individual messages.
> 
> I ran the command you mentioned below and attached the result.  I'm 
> not sure if I should delete all the entries listed or even why I get 
> all the "permission denied" messages.  As you will see I executed the 
> command both with and without "sudo".
> 
> dave@MintJulips:~$ find / -name multi_usrp.hpp
> 
> find: '/sys/kernel/debug': Permission denied
> 
> /usr/include/uhd/usrp/multi_usrp.hpp

Here's the culprit. You still have an old UHD installed. Remove that and
start from scratch.

M


___
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] Issues with Pybombs and Package Manager Install on Ubuntu 16.04

[Dave]

(I accidentally posted this to the usrp group.  This is a repost back in the
gnuradio group.)

 

Thanks Martin.  I have changed my subscription to individual messages.

 

I ran the command you mentioned below and attached the result.  I'm not sure
if I should delete all the entries listed or even why I get all the
"permission denied" messages.  As you will see I executed the command both
with and without "sudo".

 

dave@MintJulips:~$ find / -name multi_usrp.hpp

find: '/sys/kernel/debug': Permission denied

/usr/include/uhd/usrp/multi_usrp.hpp

/home/dave/pybombsprefix1/src/uhd/host/include/uhd/usrp/multi_usrp.hpp

/home/dave/pybombsprefix1/include/uhd/usrp/multi_usrp.hpp

/home/dave/.local/share/Trash/files/pybombsprefix1/src/uhd/host/include/uhd/
usrp/multi_usrp.hpp

/home/dave/.local/share/Trash/files/pybombsprefix1/include/uhd/usrp/multi_us
rp.hpp

find: '/lost+found': Permission denied

find: '/root': Permission denied

find: '/var/spool/rsyslog': Permission denied

find: '/var/spool/cups': Permission denied

find: '/var/spool/cron/atspool': Permission denied

find: '/var/spool/cron/atjobs': Permission denied

find: '/var/spool/cron/crontabs': Permission denied

find: '/var/cache/lightdm/dmrc': Permission denied

find: '/var/cache/apt/archives/partial': Permission denied

find: '/var/cache/ldconfig': Permission denied

find: '/var/cache/cups': Permission denied

find: '/var/log/speech-dispatcher': Permission denied

find: '/var/lib/lightdm': Permission denied

find: '/var/lib/apt/lists/partial': Permission denied

find: '/var/lib/udisks2': Permission denied

find: '/var/lib/lightdm-data/lightdm': Permission denied

find: '/var/lib/polkit-1': Permission denied

find: '/var/lib/colord/.cache': Permission denied

find:
'/var/tmp/systemd-private-ecb1c088127a4dfb807716e5e4e34b68-colord.service-Qf
ymyD': Permission denied

find:
'/var/tmp/systemd-private-ecb1c088127a4dfb807716e5e4e34b68-rtkit-daemon.serv
ice-gzl5oM': Permission denied

find:
'/var/tmp/systemd-private-749c30d892ed450d9e8720d354679a23-colord.service-7a
5Gt6': Permission denied

find:
'/var/tmp/systemd-private-749c30d892ed450d9e8720d354679a23-rtkit-daemon.serv
ice-XWE7qs': Permission denied

find:
'/var/tmp/systemd-private-4b70f9be02d04cdcb23ac9674e8d12c8-colord.service-2i
7a3O': Permission denied

. hundreds of more similar lines...

Second attempt with the "sudo"

dave@MintJulips:~$ sudo find / -name multi_usrp.hpp

/usr/include/uhd/usrp/multi_usrp.hpp

/home/dave/pybombsprefix1/src/uhd/host/include/uhd/usrp/multi_usrp.hpp

/home/dave/pybombsprefix1/include/uhd/usrp/multi_usrp.hpp

/home/dave/.local/share/Trash/files/pybombsprefix1/src/uhd/host/include/uhd/
usrp/multi_usrp.hpp

/home/dave/.local/share/Trash/files/pybombsprefix1/include/uhd/usrp/multi_us
rp.hpp

find: '/run/user/1000/gvfs': Permission denied

 

 

 


From: 

Martin Braun


Subject: 

Re: [Discuss-gnuradio] Issues with Pybombs and Package Manager Install on
Ubuntu 16.04


Date: 

Wed, 6 Jul 2016 17:47:53 -0700


User-agent: 

Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0

  _  

On 07/06/2016 05:20 PM, Dave wrote:

> I'm not sure how to respond to the list when I receive the daily archive

> of the email traffic.  As such I just copied your response text and am

> responding to that.

 

If you want to post and have discussions, you should consider changing

your subscription to individual messages, not digests.

 

This also helps other people trying to help you, since that way,

messages can be sorted by threads.

 

> I used apt-get remove uhd and apt-get remove gnuradio.  I also looked

> for anything with gnuradio and UHD in the Synaptic Package manager and

> removed anything I found.  I also deleted my directory "pybombprefix1".

 

Can you please confirm that there's *no* UHD files anywhere on your

computer (e.g. find / -name multi_usrp.hpp will return nothing).

 

M

 

 

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

Re: [Discuss-gnuradio] Issues with Pybombs and Package Manager Install on Ubuntu 16.04

[Dave]

I'm not sure how to respond to the list when I receive the daily archive of
the email traffic.  As such I just copied your response text and am
responding to that.

 

Thank you Martin for your help.

 

I used apt-get remove uhd and apt-get remove gnuradio.  I also looked for
anything with gnuradio and UHD in the Synaptic Package manager and removed
anything I found.  I also deleted my directory "pybombprefix1".

 

Then I re-executed the command:

 

pybombs prefix init pybombsprefix1 -a myprefix -R gnuradio-default

 

Again it failed in exactly the same place as mentioned below.

 

Thanks again for your help.

 

Dave

 

 


From: 

Martin Braun


Subject: 

Re: [Discuss-gnuradio] Issues with Pybombs and Package Manager Install on
Ubuntu 16.04


Date: 

Wed, 6 Jul 2016 13:33:48 -0700


User-agent: 

Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0

  _  

Dave,
 
let's stick to one issue at a time. Your compile is probably failing
because you have the package manager version still installed. Make sure
you've removed everything you installed via apt-get (or whatever you
used), that includes all UHD and GNU Radio packages, and retry PyBOMBS.
 
Once we get that working, let's tackle the other issues.
 
M
 
On 07/06/2016 12:23 PM, Dave wrote:
> I am attempting to install gnuradio on a Ubuntu 16.04 machine.  Using
> pybombs I get about 85% of the way along and then I get the errors show
> at the end of this post.  After this attempt I used the package manager
> to load gnuradio with limited success.  I'm new to gnuradio and I'm
> using an ETTUS B100 device.  Everything about gnuradio and the usrp
> seems to work just fine if I boot from the current gnuradio usb stick
> image.  As such I think both my PC and my usrp are functioning
> properly.  After loading gnuradio from the package manager an running a
> simple usrp source and QT Gui Sink, I got an error indicating "No USD
> devices found"  I ran uhd_find_devices and got the error  message listed
> below with my subsequent actions.  I could then run my simple usrp
> sources and QT Gui Sink and get results however I cannot use a sample
> rate higher than about 2M samples/sec.  Again this flow graph works fine
> when booted from the usb image all the way to 8M samples/sec.  Also when
> running the uhd_wbfm_receive example flow graph I don't get any audio
> from the Audio Sink but again it works just fine from the gnuradio usb
> stick image.  As such I'm trying to solve three problems.  1) install
> via pybombs to completion 2) using the package manger manager version of
> the install figure out why I can't get 8M sample rate and 3) Audio sink
> output.  Note: Through a separate post on the USRP list, I am trying to
> work usrp "device not found" issues with my windows 7 install as well.
> 
> I appreciate any help you folks can provide.
> 
> Thanks,  Dave
> 
> Error from uhd_find_devices:
> 
> address@hidden:~$ uhd_find_devices
> 
> linux; GNU C++ version 5.3.1 20151219; Boost_105800;
> UHD_003.009.002-0-unknown
> 
> UHD Warning:
> 
> Could not locate B100 firmware. Please run:
> 
> "/usr/lib/uhd/utils/uhd_images_downloader.py"
> 
> No UHD Devices Found
> 
> address@hidden:~$ /usr/lib/uhd/utils/uhd_images_downloader.py
> 
> Images destination: /usr/share/uhd/images
> 
> You do not have sufficient permissions to write to: /usr/share
> 
> Are you root?
> 
> address@hidden:~$ sudo /usr/lib/uhd/utils/uhd_images_downloader.py
> 
> [sudo] password for dave:
> 
> Images destination: /usr/share/uhd/images
> 
> Downloading images from:
> http://files.ettus.com/binaries/images/uhd-images_003.009.002-release.zip
> 
> Downloading images to: /tmp/tmpozhdaY/uhd-images_003.009.002-release.zip
> 
> 26296 kB / 26296 kB (100%)
> 
> Images successfully installed to: /usr/share/uhd/images
> 
> address@hidden:~$ uhd_find_devices
> 
> linux; GNU C++ version 5.3.1 20151219; Boost_105800;
> UHD_003.009.002-0-unknown
> 
> -- Loading firmware image: /usr/share/uhd/images/usrp_b100_fw.ihx... done
> 
> --
> 
> -- UHD Device 0
> 
> --
> 
> Device Address:
> 
> type: b100
> 
> name: b100
> 
> serial: EBR12XEB1
> 
>  
> 
>  
> 
> Pybombs Failure Transcript below:
> 
> [ 85%] Built target _uhd_swig_swig_tag
> 
> [ 85%] Built target uhd_swig_gr_uhd_swig_5e3ce
> 
> [ 85%] Building CXX object
> gr-uhd/swig/CMakeFiles/_uhd_swig.dir/uhd_swigPYTHON_wrap.cxx.o
> 
>
/home/dave/pybombsprefix1/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap
.cxx:
> In function 'PyObject* _wrap_dboard_i