gr-gfdm

[Mike Sousa]

 i'm trying to execute gr-gfdm in gnuradio companion v3.10. There are a lot of 
Flowgraph errors out of the box. For example: Block : import_cyclic_prefix, 
Aspect : Param ‘Import’, Message : Import “from gfdm.pygfdm import 
cyclic_prefix” failed.  Any idea how to get the rest of the gr-gfdm package

Re: gr-adsb

[Mike Sousa]

 
Thanks Ivan and John.  Ivan I would like to see your spoofer if that's ok. 
Could it be converted completely into a grc simulation? John, I have no 
intention of broadcasting a signal into the air, I have the output connected to 
a spectrum analyzer. Thought it would be worth looking at.   Thanks...

On Monday, July 3, 2023 at 10:36:03 AM EDT, kron...@tiscali.it 
 wrote:  
 
 Hello guys!Few years ago I implemented a ADS-B spoofer (transmitter) composed 
by an external python module that evaluates the ADS-B payload (given position 
information and aircraft ID) and a gnuradio OOT module that generates the 
waveform.I should share my code on github, let me know if you really need 
it.Regards.Ivan
Il 03.07.2023 16:04 John Sallay ha scritto:

I've used this package recently and it would not be trivial to convert from rx 
to tx.  With that said, ADS-B is a pretty simple signal, I don't think it would 
be a monumental effort to do it.  You would need to write the reverse of the 
decoder block that would create ADS-B messages from your input data.  
Additionally, you might need to write a block that converts that message to the 
Pulse Position Modulation used by ADS-B (I'm not sure if there are any standard 
blocks that can do this for you) and appends the preamble sequence.I'm not sure 
what your application is, but I would make sure that whatever you are planning 
to do it legal where you are located.  I'm not a lawyer, but I would imagine 
that you could get in trouble while building up your transmitter if other 
aircraft or flight controllers were able to pick up on your signal.
On Mon, Jul 3, 2023 at 9:44 AM Mike Sousa  wrote:
The gr-adsb package has a receiver example. Is there an example of a adsb 
transmitter? If not, how difficult would it be to convert the rx into tx? Would 
it be similar to replacing the USRP Source with a Signal Source and replacing 
the ZMQ PUB message Sink with a USRO Sink (this sounds too simplistic, but one 
can hope)?
https://github.com/mhostetter/gr-adsb

 



  

gr-adsb

[Mike Sousa]

 The gr-adsb package has a receiver example. Is there an example of a adsb 
transmitter? If not, how difficult would it be to convert the rx into tx? Would 
it be similar to replacing the USRP Source with a Signal Source and replacing 
the ZMQ PUB message Sink with a USRO Sink (this sounds too simplistic, but one 
can hope)?

https://github.com/mhostetter/gr-adsb



   

Re: gr-ieee802-11 handle 802-11ac & 801-11ax protocols?

[Mike Sousa]

 
Also, these would be 256 QAM and 1024 QAM respectively.

If not, how much work would it possibly take to add them?




 
  

gr-ieee802-11 handle 802-11ac & 801-11ax protocols?

[Mike Sousa]

Hi,  can gr-ieee802-11 create 802.11ac and 802.11ax signals?  Thanks…

 

gr-ham : gnuradio's amatuer radio package

[Mike Sousa]

 Hi
Are there any examples, notes, etc, using the gr-ham 
package?https://github.com/argilo/gr-ham

Thanks... 
  
 

Re: gr-dvbt

[Mike Sousa]

 Marcus, Ron, thank you very much, this helped a lot 
Thanks…
 
  
 

gr-dvbt

[Mike Sousa]

 Hi 
Has there been an updated gr-dvbt package that will work with a newer gnuradio 
(v3.10)?
 
Thanks…
 
  
   

Re: gr-ieee802-11

[Mike Sousa]

Hi

Following directions from Felipe last week, I've been able to get my wi-fi 
example of gr-ieee802-11 to output a signal. A few more questions if you don’t 
mind:

Can this package be set up for either ieee802.11ac or ieee802-11ax  (5Ghz or 
6Ghz))?

Is there a way to select channels, ex for 5Ghz: 50 52 54 58, or for 6Ghz: 65 to 
93?

 

Thanks…

gr-ham

[Mike Sousa]

 Hi
I'd like to try gnuradio for CB Radio UHF and HF. Is the gr-radio package the 
correct way to go? Are there examples or tutorials to use this? Would another 
package be preferable? Thanks... 
  https://github.com/argilo/gr-ham



   

Re: gr-ieee802-11

[Mike Sousa]

 Thanks Felipe for the advise. I’m using the examples from Bastian Bloessl:
 
https://github.com/bastibl/gr-ieee802-11/tree/maint-3.8/examples
 
Setting up the wifi_tx.grc  example.  Only thing I’ve changed is the address 
for my B210 in the UHD: USRP Sink. Selected the sample rate of 20Mhz and the 
freq==2412GHz. Not sure what the 11g is in the pull down selection?I’m 
connecting the B210 output to a signal analyzer first. Seems to work out of the 
box. I will try a few other selections before trying theXlinx Zynq UltraScale.  
Has there been any research or experiments with this package? Thanks…
 
  
 
  
 
  
 
  
 

Re: gr-ieee802-11

[Mike Sousa]

Those tutorials have been helpful. I have some questions that may be applicable 
to other packages I try besides the gr-ieee-11. Some of the parameters I wish 
to try are:

 

I’m looking for the blocks/fields to set the following:

Channels 50, 52, 54, 58 which I understand to be 160Mhz, 20Mhz, 40Mhz and 
80Mhz: (the freq block?)?

Intercept Power of -90dBm

Modulation: QAM (encoding block?)

OFDM symbol duration

Data rate

 

Thanks for your help…

Fw: gr-ieee802-11

[Mike Sousa]

 Thanks Felipe for the advise. I’m using the examples from Bastian Bloessl:
 
https://github.com/bastibl/gr-ieee802-11/tree/maint-3.8/examples
 
Setting up the wifi_tx.grc  example.  Only thing I’ve changed is the address 
for my B210 in the UHD: USRP Sink. Selected the sample rate of 20Mhz and the 
freq==2412GHz. Not sure what the 11g is in the pull down selection?I’m 
connecting the B210 output to a signal analyzer first. Seems to work out of the 
box. I will try a few other selections before trying theXlinx Zynq UltraScale.  
Has there been any research or experiments with this package? Thanks…
 
  
 
  
 
  
 
  
   

Re: gr-ieee803-11

[Mike Sousa]

 
My image of the flow of control did not go through, so here it is using plain 
text
GNU Radio  commands --->  B210  ---  output from TX/RX port on a wire  ---> 
 Xlinx Zynq UltraScale
I've connected and sent commands to the B210, but I'm curious about how to get 
wifi from the B210 to the Xilinx.  Is it possible to create a block, if none 
exists to send the output from the gr-ieee-11 block to the Xlinx?

Re: gr-ieee803-11

[Mike Sousa]

 

The flow of control/signals




On Thursday, June 22, 2023 at 03:22:45 PM EDT, Mike Sousa 
 wrote:  
 
  Hi

First off, I want you to know that I have limited gnuradio and grc experience.  
I have gr-ieee803-11, maint-3.10 loaded into grc. I am planning to just use the 
transmit parts of the package. It looks like it takes a number of blocks on the 
output of the the USRP (in my case, a B210) to get Wi-Fi. My B210 is physically 
wired to the input of another radio (not sure of make but I've been told it 
operates on a Xilinx  Zynq UltraScale - if that helps).What I would like to do 
is command the B210 to send Wi-Fi to the radio that is physically connected to 
it. Can I do this with gr-ieee803-11? If not, is it possible to modify 
gr-ieee803-11 to do this? If not, is it possible to do this some other way with 
gnuradio?
Thanks for your time...

gr-ieee803-11

[Mike Sousa]

 Hi

First off, I want you to know that I have limited gnuradio and grc experience.  
I have gr-ieee803-11, maint-3.10 loaded into grc. I am planning to just use the 
transmit parts of the package. It looks like it takes a number of blocks on the 
output of the the USRP (in my case, a B210) to get Wi-Fi. My B210 is physically 
wired to the input of another radio (not sure of make but I've been told it 
operates on a Xilinx  Zynq UltraScale - if that helps).What I would like to do 
is command the B210 to send Wi-Fi to the radio that is physically connected to 
it. Can I do this with gr-ieee803-11? If not, is it possible to modify 
gr-ieee803-11 to do this? If not, is it possible to do this some other way with 
gnuradio?
Thanks for your time...  

Re: How can I split a periodic signal?

[Mike Markowski]

James,

I find an easy approach is to write the signal out as alternating i/q 
binary if it's not already.  That can be read into audacity as stereo 
(File -> Import -> Raw), edited and written back out as raw data without 
header (File -> Export -> Export Multiple, and choose Raw Headerless). 
Don't worry about audacity's sample rate because you're editing raw i/q 
anyway.  This allows editing down to the sample level.


Good luck!
Mike ab3ap

On 8/25/22 1:52 PM, James Wanga wrote:
I'm receiving a phase modulated signal representing a periodic pulsed 
byte that looks something like this:


-|-|||--||-|||---|---|-

I'm trying to understand how I might split this signal roughly halfway 
between each pulse of activity so I can save each pulse as a separate IQ 
fil, bit like this:


--|-|||--||--

---|||-----

--|---|--

The split does not have to be precise, it only needs to avoid bisecting 
any of the pulses. Here are some things I've tried.- Creating a custom 
block on the receiver that uses a timing interval. Unfortunately, the 
pulses aren't perfectly periodic so eventually this causes the split to 
drift.[...]

Receive packet handler problem in UHD 4.1 via radioconda

[Mike]

Hello,

I have a C++ program running under Red Hat Enterprise Linux 8.5 using 
UHD 4.1.0 via radioconda with a B200 that experienced a receive packet 
handler exception (see the trace below).  The exception occurred after 
several days of continuous execution.


I'm looking for the proper steps to debug this problem and ultimately 
correct it.


Would the recently announced UHD 4.2.0 correct this problem?  Do I need 
to fall back to the UHD 3.15, which appears to be more reliable?  Could 
there be something in my code that could cause this problem?



Thanks!


[INFO] [UHD] linux; GNU C++ version 9.4.0; Boost_107400; 
UHD_4.1.0.HEAD-release

[INFO] [B200] Detected Device: B200
[INFO] [B200] Operating over USB 3.
[INFO] [B200] Initialize CODEC control...
[INFO] [B200] Initialize Radio control...
[INFO] [B200] Performing register loopback test...
[INFO] [B200] Register loopback test passed
[INFO] [B200] Setting master clock rate selection to 'automatic'.
[INFO] [B200] Asking for clock rate 16.00 MHz...
[INFO] [B200] Actually got clock rate 16.00 MHz.
Setting RX Rate: 5000.00...
[INFO] [B200] Asking for clock rate 50.00 MHz...
[INFO] [B200] Actually got clock rate 50.00 MHz.

(Code runs for some time)


[ERROR] [STREAMER] The receive packet handler caught a value exception.
ValueError: bad vrt header or packet fragment
[ERROR] [UHD] Exception caught in safe-call.
  in virtual tx_vita_core_3000_impl::~tx_vita_core_3000_impl()
  at 
/home/conda/feedstock_root/build_artifacts/uhd_1643679623734/work/host/lib/usrp/cores/tx_vita_core_3000.cpp:49

this->clear(); -> AssertionError: accum_timeout < _timeout
  in uint64_t b200_radio_ctrl_core_impl::wait_for_ack(bool)
  at 
/home/conda/feedstock_root/build_artifacts/uhd_1643679623734/work/host/lib/usrp/b200/b200_radio_ctrl_core.cpp:228


[ERROR] [UHD] Exception caught in safe-call.
  in virtual b200_radio_ctrl_core_impl::~b200_radio_ctrl_core_impl()
  at 
/home/conda/feedstock_root/build_artifacts/uhd_1643679623734/work/host/lib/usrp/b200/b200_radio_ctrl_core.cpp:66
this->peek32(0); _async_task.reset(); -> AssertionError: accum_timeout < 
_timeout

  in uint64_t b200_radio_ctrl_core_impl::wait_for_ack(bool)
  at 
/home/conda/feedstock_root/build_artifacts/uhd_1643679623734/work/host/lib/usrp/b200/b200_radio_ctrl_core.cpp:228


[ERROR] [UHD] Exception caught in safe-call.
  in virtual b200_radio_ctrl_core_impl::~b200_radio_ctrl_core_impl()
  at 
/home/conda/feedstock_root/build_artifacts/uhd_1643679623734/work/host/lib/usrp/b200/b200_radio_ctrl_core.cpp:66
this->peek32(0); _async_task.reset(); -> AssertionError: accum_timeout < 
_timeout

  in uint64_t b200_radio_ctrl_core_impl::wait_for_ack(bool)
  at 
/home/conda/feedstock_root/build_artifacts/uhd_1643679623734/work/host/lib/usrp/b200/b200_radio_ctrl_core.cpp:228

Re: RHEL repository for latest GNURadio?

[Mike]

Thank you for your response.  Is there a repository for a more recent 
version, like 3.10?



Regards,

Mike



On 2/27/2022 3:33 AM, Vasil Velichkov wrote:

Hi Mike,

You can install gnuradio 3.8.0.0 from the EPEL repository.

https://docs.fedoraproject.org/en-US/epel/#_el8

Regards,
Vasil

On Sun, Feb 27, 2022, 07:05 Mike  wrote:

Hello,

I'm moving an existing application that relies on GNURadio from
Ubuntu
to Red Hat Enterprise Linux 8.5.

The default RHEL repositories don't know about gnuradio:

> $ sudo yum install gnuradio
> Updating Subscription Management repositories.
> Last metadata expiration check: 0:52:27 ago
> No match for argument: gnuradio
> Error: Unable to find a match: gnuradio
Which repository do I need to add in order to install the current
gnuradio?


Thanks!

RHEL repository for latest GNURadio?

[Mike]

Hello,

I'm moving an existing application that relies on GNURadio from Ubuntu 
to Red Hat Enterprise Linux 8.5.


The default RHEL repositories don't know about gnuradio:


$ sudo yum install gnuradio
Updating Subscription Management repositories.
Last metadata expiration check: 0:52:27 ago
No match for argument: gnuradio
Error: Unable to find a match: gnuradio

Which repository do I need to add in order to install the current gnuradio?


Thanks!

Questions on B200 PPS

[Mike]

Hello,

We are using an external GPSDO to provide 10 MHz and PPS into a B200.

Our application collects a fixed number of samples at 50 MSPS using a
stream command (UHD_STREAM_MODE_NUM_SAMPS_AND_DONE and the timespec for
the next PPS).  In this way we rely on the USRP to provide samples that
begin at the instant of PPS arrival.

This works almost all the time.  Occasionally, it appears we miss one
sample (20 ns) and thus our timing is off.  We suspect this is due some
behavior in the B200 related to the PPS.

We are using a Stanford Research FS740 for our GPSDO and have it set to
provide a 5 volt PPS pulse with a duration of 8 microseconds.

Questions:

1.  Is 8 milliseconds long enough for a PPS signal?  If not, what value
would be appropriate?

2.  Documentation shows an alternate for the

usrp->set_time_source("external");

command that uses underscores on either side of the word, as

usrp->set_time_source("_external_");

What exactly does this command do relative to the leading edge of the
PPS signal?


To the extent it matters, we are operating under Ubuntu 20.04 with UHD 3.15.


Thanks!

UHD function to determine USB version?

[Mike]

Hello,

I apologize if I missed it in the documentation, but is there a UHD
function that will return the USB version (e.g. USB 2 or USB 3) that the
USRP is using?

I'm using a B200 in a custom C++ program and would like to
programmatically verify the USB connection speed before attempting high
rate sampling.


Thanks!

Re: Working Narrowband FM examples?

[Mike Markowski]

You bet, Nathan.  I just verified that the flowgraph demods NWR, so 
either osmocom Source or Audio Sink needs configuring.  You might try 
simply playing a recording into your audio sink.  It might be as simple 
as adjusting audio rate.  Regarding osmocom Source set up, another 
flowgraph for HackRF was mentioned in this thread, and you might compare 
that src setting to yours.  (Also, not sure why I had RF gain maxed. 
Better to lower that...)


Good luck,
Mike

On 8/4/21 1:40 PM, Nathan Van Ymeren wrote:

Hi Mike,

That's exactly what I was looking for, thanks.

However:  I swapped out the USRP source for an osmocom source, and it 
seems to be "mostly working" but the audio comes through like the adults 
from the old Charlie Brown show from when I was a kid.  Instead of 
clearly-intelligible speech like I can hear through GQRX, using gnuradio 
I can only get speech that sounds like "mwah mwah mwah mwah"


Attached is a .png of my flowgraph, hope it's not too large for the list 
(about 100kB).


Appreciate any advice anyone might have.

Nathan

On 8/3/21 3:47 AM, Mike Markowski wrote:

Nathan,

When I was refreshing my gnuradio awareness - I hesitate to use the 
word "skills" :-)  - I ran through the official tutorials and modified 
them as needed to work with a usrp b210.  On the page


   https://udel.edu/~mm/gr/

about halfway down is the title "Gnuradio Official Tutorials" with the 
link "Here are my versions" where you'll find nbfm.grc.  It's very 
simple, using filter/squelch/NBFM Receive block and runs here on grc 
3.8.2.0, a promising sign.


Hope it's useful,
Mike

On 8/3/21 2:40 AM, Nathan Van Ymeren wrote:

Hello,

I am seeking a working NBFM receiver example, as the one on the 
wiki[0] produces unintelligible output.  I am confident that my 
hardware is functioning properly because if I tune to the same 
frequency (162.525 MHz ) in gqrx, I can hear the weather radio 
broadcasts clearly.  I am on OpenSUSE Tumbleweed, running gnuradio 
3.8.x with a HackRF One and a standard telescopic antenna.


I have reproduced [0] verbatim except with the following change: 
Instead of a ZeroMQ source, I am using an osmocom source for my hackrf.


I’ve also tried adapting the flowgraph from the “SDR with HackRF” 
tutorial[1], which implements a wideband FM receiver in gnuradio, but 
I wasn’t able to make it produce anything resembling speech when I 
changed it to narrowband FM.


Additionally, I’ve tried a few NOAA weather radio flowgraphs found 
online but most of what I’ve found either didn’t work or else was for 
an older version of gnuradio and thus had errors that I wasn’t able 
to work around since I am a gnuradio novice.


Can anyone recommend a working flowgraph for narrowband FM, ideally 
something simple and working in gnuradio 3.8+?


Thanks,

Nathan

[0] 
https://wiki.gnuradio.org/index.php/Simulation_example:_Narrowband_FM_transceiver#NBFM_receiver 


[1] https://greatscottgadgets.com/sdr/1/

Re: Working Narrowband FM examples?

[Mike Markowski]

Nathan,

When I was refreshing my gnuradio awareness - I hesitate to use the word 
"skills" :-)  - I ran through the official tutorials and modified them 
as needed to work with a usrp b210.  On the page


   https://udel.edu/~mm/gr/

about halfway down is the title "Gnuradio Official Tutorials" with the 
link "Here are my versions" where you'll find nbfm.grc.  It's very 
simple, using filter/squelch/NBFM Receive block and runs here on grc 
3.8.2.0, a promising sign.


Hope it's useful,
Mike

On 8/3/21 2:40 AM, Nathan Van Ymeren wrote:

Hello,

I am seeking a working NBFM receiver example, as the one on the wiki[0] 
produces unintelligible output.  I am confident that my hardware is functioning 
properly because if I tune to the same frequency (162.525 MHz ) in gqrx, I can 
hear the weather radio broadcasts clearly.  I am on OpenSUSE Tumbleweed, 
running gnuradio 3.8.x with a HackRF One and a standard telescopic antenna.

I have reproduced [0] verbatim except with the following change:  Instead of a 
ZeroMQ source, I am using an osmocom source for my hackrf.

I’ve also tried adapting the flowgraph from the “SDR with HackRF” tutorial[1], 
which implements a wideband FM receiver in gnuradio, but I wasn’t able to make 
it produce anything resembling speech when I changed it to narrowband FM.

Additionally, I’ve tried a few NOAA weather radio flowgraphs found online but 
most of what I’ve found either didn’t work or else was for an older version of 
gnuradio and thus had errors that I wasn’t able to work around since I am a 
gnuradio novice.

Can anyone recommend a working flowgraph for narrowband FM, ideally something 
simple and working in gnuradio 3.8+?

Thanks,

Nathan

[0] 
https://wiki.gnuradio.org/index.php/Simulation_example:_Narrowband_FM_transceiver#NBFM_receiver
[1] https://greatscottgadgets.com/sdr/1/

Using an E310 in place of a B200

[Mike]

Hello,

We are working with the srsRAN software package (www.srslte.com).  Our
hardware configuration is a laptop running the srsRAN application under
Ubuntu, connected via USB to a USRP.  It runs well with B200s, however
we do not have access to B200s at the location where our testing will
take place.

What we do have are E310s.  The srsRAN application expects a UHD-based
front end, as is standard when using a B200.  What we are looking for is
a way to make an E310s look like a B200 to the laptop, accessible via UHD.

Is there an easy way to do this, like some kind of bypass mode to give
direct access to the radio?  MATLAB appears to support this type of
operation but we're not clear how.


Thanks!

UHD buffer high water mark

[Mike]

Hello,

I am running a B200 with UHD 3.15 at 50 MSPS with sc8 on the wire and
host format.  I use a device argument of "num_recv_frames=1024" in an
attempt to minimize the occurrence of overflows.  Is there a way of
knowing how many of these frames are filled before being read, something
like a high water mark to determine how close to overflow the code is
getting?

Thanks!

Solved! - Re: USRP UHD Source problem

[Mike Markowski]

With thanks to Christophe for his excellent advice, removing 
~/.cache/grc_gnuradio/cache.json fixed things up.  After needing to do 
this now & then, I have a new gr heuristic:


  if (weirdnessReigns) { delete cache.json; }

Thanks, Christophe!

Mike

On 4/24/21 2:55 PM, Mike Markowski wrote:
Some progress.  When I log in as another user, gr runs fine with a usrp. 
  Logging in as me, I get the errors previously posted.  My environment 
seems to (suddenly) be the issue, so I:


1. Moved ~/.bashrc to a new name to avoid any improper env var settings.

2. Moved ~/.config/GNU\ RADIO

But I still get errors previously posted.  Are there other files 
gnuradio-companion is looking at that could be the culprit?


Thanks,
Mike

On 4/24/21 1:04 PM, Mike Markowski wrote:
Thanks for checking, Christophe.  I agree that it's strange.  I've 
been away from gnuradio doing some cyclostationary work, so haven't 
touched any flowgraphs in weeks.  I see that my newest flowgraphs were 
built April 7 and that gnuradio-companion, no doubt after an Ubuntu 
upgrade, shows a date of April 9.


I'll share debugging breakthroughs, but would be glad to hear from 
others if your GR 3.8.1.0 is or isn't running fine.  Most likely, it's 
my environment since I don't see a flurry of 'me too' notes.


Mike

On 4/24/21 12:16 PM, Christophe Seguinot wrote:
This flowgraph is correctly build under GR 3.9.0.0 (no USRP source to 
test further)


The error is quite strange, I think there is no "len_tag_name" 
parameter in such a simple flowgraph


On 24/04/2021 16:35, Mike Markowski wrote:
I'm running gnuradio companion 3.8.1.0 (Python 3.8.6) on Ubuntu 
2020.10.  After a few weeks away from gnuradio, today I get errors 
with the USRP UHD Source, and previously working flowgraphs no 
longer build. (Previously built flowgraph python files still run 
fine.)  The attached flowgraph doesn't get much simpler, but 
building yields:


Generating: '/home/mm/sdr/fm/uhdTest.py'
Generate Error: (NameError("'len_tag_name' is not defined"), 
'uhd.usrp_source(\n    ",".join((${dev_addr}, ${dev_args})),\n 
uhd.stream_args(\n    cpu_format="${type}",\n


[... on and on ...]

, uhd.ALL_MBOARDS)\n% else:\n# No synchronization enforced.\n% 
endif\n')

>>> Failure
Traceback (most recent call last):
  File "memory:0x7f3082ab36d0", line 136, in render_body
  File "/usr/lib/python3/dist-packages/mako/runtime.py", line 106, 
in __getitem__

    return compat_builtins.__dict__[key]
KeyError: 'len_tag_name'

[... still more...]

Is anyone else seeing this error?

Thanks,
Mike

Re: USRP UHD Source problem

[Mike Markowski]

Some progress.  When I log in as another user, gr runs fine with a usrp. 
 Logging in as me, I get the errors previously posted.  My environment 
seems to (suddenly) be the issue, so I:


1. Moved ~/.bashrc to a new name to avoid any improper env var settings.

2. Moved ~/.config/GNU\ RADIO

But I still get errors previously posted.  Are there other files 
gnuradio-companion is looking at that could be the culprit?


Thanks,
Mike

On 4/24/21 1:04 PM, Mike Markowski wrote:
Thanks for checking, Christophe.  I agree that it's strange.  I've been 
away from gnuradio doing some cyclostationary work, so haven't touched 
any flowgraphs in weeks.  I see that my newest flowgraphs were built 
April 7 and that gnuradio-companion, no doubt after an Ubuntu upgrade, 
shows a date of April 9.


I'll share debugging breakthroughs, but would be glad to hear from 
others if your GR 3.8.1.0 is or isn't running fine.  Most likely, it's 
my environment since I don't see a flurry of 'me too' notes.


Mike

On 4/24/21 12:16 PM, Christophe Seguinot wrote:
This flowgraph is correctly build under GR 3.9.0.0 (no USRP source to 
test further)


The error is quite strange, I think there is no "len_tag_name" 
parameter in such a simple flowgraph


On 24/04/2021 16:35, Mike Markowski wrote:
I'm running gnuradio companion 3.8.1.0 (Python 3.8.6) on Ubuntu 
2020.10.  After a few weeks away from gnuradio, today I get errors 
with the USRP UHD Source, and previously working flowgraphs no longer 
build. (Previously built flowgraph python files still run fine.)  The 
attached flowgraph doesn't get much simpler, but building yields:


Generating: '/home/mm/sdr/fm/uhdTest.py'
Generate Error: (NameError("'len_tag_name' is not defined"), 
'uhd.usrp_source(\n    ",".join((${dev_addr}, ${dev_args})),\n 
uhd.stream_args(\n    cpu_format="${type}",\n


[... on and on ...]

, uhd.ALL_MBOARDS)\n% else:\n# No synchronization enforced.\n% endif\n')
>>> Failure
Traceback (most recent call last):
  File "memory:0x7f3082ab36d0", line 136, in render_body
  File "/usr/lib/python3/dist-packages/mako/runtime.py", line 106, in 
__getitem__

    return compat_builtins.__dict__[key]
KeyError: 'len_tag_name'

[... still more...]

Is anyone else seeing this error?

Thanks,
Mike

Re: USRP UHD Source problem

[Mike Markowski]

Thanks for checking, Christophe.  I agree that it's strange.  I've been 
away from gnuradio doing some cyclostationary work, so haven't touched 
any flowgraphs in weeks.  I see that my newest flowgraphs were built 
April 7 and that gnuradio-companion, no doubt after an Ubuntu upgrade, 
shows a date of April 9.


I'll share debugging breakthroughs, but would be glad to hear from 
others if your GR 3.8.1.0 is or isn't running fine.  Most likely, it's 
my environment since I don't see a flurry of 'me too' notes.


Mike

On 4/24/21 12:16 PM, Christophe Seguinot wrote:
This flowgraph is correctly build under GR 3.9.0.0 (no USRP source to 
test further)


The error is quite strange, I think there is no "len_tag_name" parameter 
in such a simple flowgraph


On 24/04/2021 16:35, Mike Markowski wrote:
I'm running gnuradio companion 3.8.1.0 (Python 3.8.6) on Ubuntu 
2020.10.  After a few weeks away from gnuradio, today I get errors 
with the USRP UHD Source, and previously working flowgraphs no longer 
build. (Previously built flowgraph python files still run fine.)  The 
attached flowgraph doesn't get much simpler, but building yields:


Generating: '/home/mm/sdr/fm/uhdTest.py'
Generate Error: (NameError("'len_tag_name' is not defined"), 
'uhd.usrp_source(\n    ",".join((${dev_addr}, ${dev_args})),\n 
uhd.stream_args(\n    cpu_format="${type}",\n


[... on and on ...]

, uhd.ALL_MBOARDS)\n% else:\n# No synchronization enforced.\n% endif\n')
>>> Failure
Traceback (most recent call last):
  File "memory:0x7f3082ab36d0", line 136, in render_body
  File "/usr/lib/python3/dist-packages/mako/runtime.py", line 106, in 
__getitem__

    return compat_builtins.__dict__[key]
KeyError: 'len_tag_name'

[... still more...]

Is anyone else seeing this error?

Thanks,
Mike

USRP UHD Source problem

[Mike Markowski]

I'm running gnuradio companion 3.8.1.0 (Python 3.8.6) on Ubuntu 2020.10. 
 After a few weeks away from gnuradio, today I get errors with the USRP 
UHD Source, and previously working flowgraphs no longer build. 
(Previously built flowgraph python files still run fine.)  The attached 
flowgraph doesn't get much simpler, but building yields:


Generating: '/home/mm/sdr/fm/uhdTest.py'
Generate Error: (NameError("'len_tag_name' is not defined"), 
'uhd.usrp_source(\n",".join((${dev_addr}, ${dev_args})),\n 
uhd.stream_args(\ncpu_format="${type}",\n


[... on and on ...]

, uhd.ALL_MBOARDS)\n% else:\n# No synchronization enforced.\n% endif\n')
>>> Failure
Traceback (most recent call last):
  File "memory:0x7f3082ab36d0", line 136, in render_body
  File "/usr/lib/python3/dist-packages/mako/runtime.py", line 106, in 
__getitem__

return compat_builtins.__dict__[key]
KeyError: 'len_tag_name'

[... still more...]

Is anyone else seeing this error?

Thanks,
Mike


uhdTest.grc
Description: application/gnuradio-grc

Re: Receive amplitude consistency

[Mike]

Marcus,

Thank you for your response.

The variation is on the order of 20%, although it changes from run to run.

Power level from the generator is 10 mV through 40 dB of attenuation.

The B200 is set for maximum gain (minimum attenuation) and is using sc8
format with peak=0.1.


Thanks!


On 4/21/2021 10:42 AM, Marcus D Leech wrote:
> What is the magnitude of the inconsistency?
>
> If you replace the signal generator with a 50 ohm terminator and increase the 
> gain to near maximum, do you still see the inconsistency?
>
> What power level are you injecting from the signal generator. 
>
> Sent from my iPhone
>
>> On Apr 21, 2021, at 12:27 AM, Mike  wrote:
>>
>> Hello,
>>
>> I'm hoping someone can shed some light on an apparent inconsistency
>> issue I'm seeing with received I/Q amplitude.
>>
>> I have a B200 directly connected to an arbitrary waveform generator
>> through an attenuator.  The generator is programmed to repeatedly send a
>> fixed sequence of AM pulses at a set power level.  On the host (Ubuntu
>> 20.04, UHD 3.15.0), a C++ program simply gathers samples (48 MSPS, sc8
>> OTW and CPU) and computes the average amplitude as I^2 + Q^2.
>>
>> During a run of the host software, the reported amplitudes are
>> consistent from sequence to sequence.
>>
>> However, if the host software is stopped and immediately restarted,
>> without changing the generator, the reported amplitudes are again
>> consistent but at a different level than the previous invocation.
>>
>> Is there some internal adjustment or variable setting performed during
>> USRP creation and setup that would cause the received I/Q sample
>> amplitudes to vary with each startup?
>>
>>
>> Thanks!
>>
>>
>>

Receive amplitude consistency

[Mike]

Hello,

I'm hoping someone can shed some light on an apparent inconsistency
issue I'm seeing with received I/Q amplitude.

I have a B200 directly connected to an arbitrary waveform generator
through an attenuator.  The generator is programmed to repeatedly send a
fixed sequence of AM pulses at a set power level.  On the host (Ubuntu
20.04, UHD 3.15.0), a C++ program simply gathers samples (48 MSPS, sc8
OTW and CPU) and computes the average amplitude as I^2 + Q^2.

During a run of the host software, the reported amplitudes are
consistent from sequence to sequence.

However, if the host software is stopped and immediately restarted,
without changing the generator, the reported amplitudes are again
consistent but at a different level than the previous invocation.

Is there some internal adjustment or variable setting performed during
USRP creation and setup that would cause the received I/Q sample
amplitudes to vary with each startup?


Thanks!

Re: B200 clock and pulse timing

[Mike]

Marcus,

Yes, I should have been more specific.  I am interested in the timestamp
clock that provides values to the uhd_rx_streamer_recv () metadata and
to the get_time_last_pps() calls.

I am sampling at 48 MSPS (with sc8 samples).

Your recollection is good; the schematic and wiki show a 40 MHz VCTCXO.

I don't mind buffering as long as the sample buffer metadata timestamp
and the last PPS timestamp come from the same clock and that clock has
sufficient resolution and stability (low jitter?).  What I'm trying to
get to is, how much resolution is available (at 48 MSPS) in these
timestamps and how close can I expect the sample and PPS timestamps to
be to their respective "actual" signal reception?  I expect there to be
more delay in the sampling path than the PPS path, but is there a way to
characterize those different delays?

Thanks!


On 4/6/2021 9:34 PM, Marcus D. Leech wrote:
> On 04/06/2021 07:14 PM, Mike wrote:
>>
>> Hello,
>>
>> I’d like to better understand the clock in the B200/B210.
>>
>> First, what is the actual resolution of the clock?  Is it any more
>> precise than the 100 nanoseconds a 10 MHz external reference
>> provides?  When the USRP timing is set to external, does the 10 MHz
>> directly increment the clock or is the on-board oscillator still
>> involved somehow?
>>
>>  
>>
> By "resolution of the clock", you presumably mean the Timestamp
> clock--there are many clocks used in a radio system.  The timestamp
>   clock "ticks" at the rate of the master-clock rate at which the
> AD9361 runs.  Usually, the master clock rate is some multiple of the
>   sample-rate.
>
> The clock architecture of the B2xx has an on-board TCXO that provides
> top-level clock-reference for a number of functions, including
>   deriving the master-clock used by the AD9361 RFFE chip.   I recall
> that TCXO runs at 40MHz, but the schematics can be consulted for
>   a definitive answer. 
>
> https://files.ettus.com/schematics/b200/b210.pdf
>
> When you use an external reference, it drives a PLL chip to provide
> the top-level clock for everything on the board.  It is typically the
>   case that you use an external reference because it is better than
> the on-board TCXO (or because you want synchronization across
>   multiple units in some cases).  The on-board TCXO is a +/- 2PPM
> part. External references such as an OCXO, GPSDO, Rubidium clock
>   are very much better than this.
>
>
>> I’d also like to confirm that my approach to using the B200 clock is
>> correct.
>>
>> I'm using a B200 and UHD 3.15.0 under Ubuntu 20.04 and am employing
>> the PPS port as a trigger, trying to collect a set number of samples
>> as soon after the a pulse is received on the PPS port as possible.  I
>> have an external 10 MHz reference feeding the B200, although my
>> understanding is that it shouldn’t matter since I’m using the same
>> clock for relative comparisons as described below.
>>
>> My software begins streaming samples from the B200 at a fixed rate.
>>
>> Inside a loop I call uhd_rx_streamer_recv () and use the associated
>> metadata timestamp to note the time the first sample in the read
>> buffer arrived.  Obviously the read buffer has a fixed length and
>> therefore represents a fixed amount of time at my sample rate; the
>> software uses this value in the processing below.
>>
>> Also in that loop, the software calls get_time_last_pps() and
>> compares the result to a previous get_time_last_pps() call to
>> determine if a pulse arrived on the PPS port.
>>
>> Prior to receiving a PPS pulse, this loop continues, discarding the
>> sample buffer after the PPS comparison.
>>
>> When a pulse arrives, the software compares the sample buffer
>> metadata timestamp to the last PPS timestamp.  The software uses that
>> time difference to determine if the sample buffer should be
>> discarded; the goal is to discard all of the samples that arrived
>> prior to the PPS pulse.  If the difference between the sample buffer
>> timestamp and the PPS timestamp is greater than the buffer length
>> time, the sample buffer is discarded and the uhd_rx_streamer_recv()
>> is called again to read the next set of samples.
>>
>> When the difference between the most recently read sample buffer
>> timestamp and the PPS timestamp is less than the buffer length time,
>> the software drops the first part of the sample buffer corresponding
>> to that difference, in essence dropping the samples that arrived
>> prior to the exact PPS time.  The software then calls
>> uhd_rx_streamer_recv () repeatedly, appending new samples to the
>> fir

B200 clock and pulse timing

[Mike]

Hello,

I’d like to better understand the clock in the B200/B210.

First, what is the actual resolution of the clock?  Is it any more
precise than the 100 nanoseconds a 10 MHz external reference provides? 
When the USRP timing is set to external, does the 10 MHz directly
increment the clock or is the on-board oscillator still involved somehow?

 

I’d also like to confirm that my approach to using the B200 clock is
correct.

I'm using a B200 and UHD 3.15.0 under Ubuntu 20.04 and am employing the
PPS port as a trigger, trying to collect a set number of samples as soon
after the a pulse is received on the PPS port as possible.  I have an
external 10 MHz reference feeding the B200, although my understanding is
that it shouldn’t matter since I’m using the same clock for relative
comparisons as described below.

My software begins streaming samples from the B200 at a fixed rate.

Inside a loop I call uhd_rx_streamer_recv () and use the associated
metadata timestamp to note the time the first sample in the read buffer
arrived.  Obviously the read buffer has a fixed length and therefore
represents a fixed amount of time at my sample rate; the software uses
this value in the processing below.

Also in that loop, the software calls get_time_last_pps() and compares
the result to a previous get_time_last_pps() call to determine if a
pulse arrived on the PPS port.

Prior to receiving a PPS pulse, this loop continues, discarding the
sample buffer after the PPS comparison.

When a pulse arrives, the software compares the sample buffer metadata
timestamp to the last PPS timestamp.  The software uses that time
difference to determine if the sample buffer should be discarded; the
goal is to discard all of the samples that arrived prior to the PPS
pulse.  If the difference between the sample buffer timestamp and the
PPS timestamp is greater than the buffer length time, the sample buffer
is discarded and the uhd_rx_streamer_recv() is called again to read the
next set of samples.

When the difference between the most recently read sample buffer
timestamp and the PPS timestamp is less than the buffer length time, the
software drops the first part of the sample buffer corresponding to that
difference, in essence dropping the samples that arrived prior to the
exact PPS time.  The software then calls uhd_rx_streamer_recv ()
repeatedly, appending new samples to the first partial sample buffer
until the desired total number of samples are collected.

Does this method make sense to achieve my goal of collecting samples
immediately after a PPS trigger pulse?  Is there an easier way to
achieve this goal?

Testing this method has shown that the number of sample buffers returned
via the recv() call relative to the PPS pulse varies, sometimes
significantly.  On average, discarding two or three sample buffers
brings the subsequent sample timestamp to within the fixed buffer length
(time) of the last PPS pulse.  However, there are circumstances when
dozens or even a hundred sample buffers need to be discarded because
their metadata timestamps are all prior to the PPS timestamp.

Is it reasonable that the sample buffer timestamp could be so far behind
the PPS pulse time on occasion?

 

Thanks!

Re: Combined constellation modulator/Decoder do not seem to work

[Mike Markowski]

Hi George,

You used differential encoding but forgot differential decode.  I added 
the block in the attached.  (I disabled your file creation and displayed 
to gui, easier for me to check.)


Little things are the hardest to spot.  :-)

Mike Markowski

On 3/12/21 4:46 PM, George Edwards wrote:

Hi Mike,

Thanks for your help!

As I mentioned in my email, my flowgraph consists of some of the blocks 
in the example. I dropped some of the blocks because I am doing concept 
testing to ensure I know how to set parameters for the blocks. In 
terms of delays, that is not a problem. I am dumping the outputs into 2- 
file sinks, so in post processing I can compensate for that. The problem 
is that the tx and rx data are not the same, so I am missing in setting 
parameters.


Thanks again!
George

On Fri, Mar 12, 2021 at 3:31 PM Mike Markowski <mailto:mike.ab...@gmail.com>> wrote:


I can't make out details in your image, George, but attach one I made
when working through the tutorial and works just now under gnuradio
3.8.1.0.  Like someone else mentioned in another reply, I found the
delay to be 58 and set it as the default in the attached flowgraph.
Zoom in on the bit stream plot and allow a second or two after changing
delay to see the effect.

Hope this helps,
Mike Markowski

On 3/12/21 10:37 AM, George Edwards wrote:
 > Hello,
 >
 > I cannot get the combined Constellation Modulator/Decoder as
shown below
 > to work. The figure below is an example from the online Guided
Tutorial
 > PSK Demodulation I leave out the Equalizer, Costas Loop
blocks, the
 > channel was set to pass the signal unimpaired and the Poly Clock
Sync
 > was set for Output sps=1. The constellation plot of the output of
the
 > Poly Clock Sync is perfect. Now, in the flowgraph below, the signal
 > entering the Constellation Modulator and that leaving the
Constellation
 > Decoder are routed into Time Sinks for display. I route these
signals
 > into File Sinks so I can print them and compare 1's and 0's. The
results
 > show they are not the same. I passed Constellation Rect.Object
 > parameters to both the Constellation Modulator and Decoder, which
seems
 > logical to me, but I could be wrong???
 > Will appreciate any help you can provide because what enters the
 > modulator should be the same as what is leaving the demodulator.
 > Regards,
 > George
 >
 > image.png



qpskModDem.grc
Description: application/gnuradio-grc

Re: Combined constellation modulator/Decoder do not seem to work

[Mike Markowski]

I can't make out details in your image, George, but attach one I made 
when working through the tutorial and works just now under gnuradio 
3.8.1.0.  Like someone else mentioned in another reply, I found the 
delay to be 58 and set it as the default in the attached flowgraph. 
Zoom in on the bit stream plot and allow a second or two after changing 
delay to see the effect.


Hope this helps,
Mike Markowski

On 3/12/21 10:37 AM, George Edwards wrote:

Hello,

I cannot get the combined Constellation Modulator/Decoder as shown below 
to work. The figure below is an example from the online Guided Tutorial 
PSK Demodulation I leave out the Equalizer, Costas Loop blocks, the 
channel was set to pass the signal unimpaired and the Poly Clock Sync 
was set for Output sps=1. The constellation plot of the output of the 
Poly Clock Sync is perfect. Now, in the flowgraph below, the signal 
entering the Constellation Modulator and that leaving the Constellation 
Decoder are routed into Time Sinks for display. I route these signals 
into File Sinks so I can print them and compare 1's and 0's. The results 
show they are not the same. I passed Constellation Rect.Object 
parameters to both the Constellation Modulator and Decoder, which seems 
logical to me, but I could be wrong???
Will appreciate any help you can provide because what enters the 
modulator should be the same as what is leaving the demodulator.

Regards,
George

image.png


mpsk_stage6.grc
Description: application/gnuradio-grc

Accuracy of rx_time in UHD API stream receive command?

[Mike]

Hello,

I apologize if this is covered in a document somewhere, but from exactly
where is the rx_time value in the UHD API stream receive command derived?

I'd like to determine how close that value is to the actual arrival time
of the signal at the antenna (in nanoseconds) and the variance I might
expect over time.  I'm using a B200 and UHD 3.15.0 under Ubuntu 20.04. 
The intent is to use rx_time in a ranging application and I'd like to
work out the timing error budget.

Thanks!

gnuradio error

[Mike Gilmer]

I installed gnuradio on  Fedora  5.4.17-200.fc31.x86_64 using sudo dnf
install gnuradio

Afterwards when I attempt to run gnuradio-companion (typing
gnuradio-companion in a terminal) I see several errors at start up
Warning: restarting the docstring loader (crashed while loading
'qtgui_bercurve_sink')
Warning: restarting the docstring loader (crashed while loading
'qtgui_const_sink_x')
Warning: restarting the docstring loader (crashed while loading
'qtgui_edit_box_msg')
Warning: restarting the docstring loader (crashed while loading
'qtgui_freq_sink_x')
Warning: restarting the docstring loader (crashed while loading
'qtgui_histogram_sink_x')
Warning: docstring loader crashed too often

The gnuradio GUI opens up but using QT widgets causes a seg fault.

Any help appreciated.

Mike

Re: Recommendation for high sample rate receiver?

[Mike]

Thank you to all who commented.


The target signal of interest uses pulse modulation where each pulse is
1 microsecond in duration, with a rise time of less than 0.1 microsecond
and a decay time of less than 0.2 microseconds.  The goal is to identify
the start (arrival) of a transmission at each receiver site as
accurately as possible (better than 25 ns).


Interpolation adds no useful information regarding start time, of
course.  Lower sampling rates lose arrival time resolution.


No affordable SDR supports 500 MS/sec; I'm looking at A/D evaluation
boards with an RF front end.



Thanks!




On 1/29/2020 10:34 PM, Kyeong Su Shin wrote:
> To whom it may concern:
>
> Forgot to mention: There is a Wikipedia article, listing SDR receivers
> with various capabilities
> ( https://en.wikipedia.org/wiki/List_of_software-defined_radios ).
> There's also something called OneRadio ( http://www.oneradiocorp.com/
> ). I saw an actual build of OneRadio, and it was pretty impressive
> (but expensive, of course).
>
> Do not expect these receivers to be well-supported by GNU Radio,
> however. However (I think it is not necessary, but), if you still want
> to get a fast receiver and do not want to roll out your own receiver
> using oscilloscopes or FPGAs, then I guess these are possible
> alternatives.
>
> Regards,
> Kyeong Su Shin
> 
> *보낸 사람:* Kyeong Su Shin  대신 Discuss-gnuradio
> 
> *보낸 날짜:* 2020년 1월 30일 목요일 오후 12:10
> *받는 사람:* discuss-gnuradio@gnu.org ;
> mike.nel...@rdss.com 
> *제목:* Re: Recommendation for high sample rate receiver?
>  
> To whom it may concern:
>
> It is already well-discussed, but I would like to add a few points:
>
> -If you absolutely want to have a such receiver (it's pretty
> meaningless, as discussed already, but if you still want to), then you
> can grab a digital oscilloscope or a similar hardware and attach a RF
> frontend to it. You will end up losing some (actually, most of)
> samples, but you cannot run non-trivial data processing chains at
> 500MS/s in real-time with a generic desktop CPU anyway.
>
> -Regarding on why this is pretty meaningless (not using the Nyquist
> criterion or maths, but using intuitions): consider two consecutive
> samples, sampled by your receiver. Since the sampling rate is way
> higher than the bandwidth of the signal, these values are going to be
> nearly identical. There could be a bit of differences in the amplitude
> and the phase, but the differences will be pretty small and will be
> easily washed out by the noise. You cannot expect to get reliable TDOA
> results from that. You will have to use more samples to get more
> reliable results.. or just use a slower receiver, anything that
> satisfies the Nyquist criterion.
>
> -If you know the structure of the transmitted signal (like PRNs in
> GPS), and if you are dealing with CDMA-like signals, then maybe you
> want to review the GPS receiver design principles and apply that to
> your design. Not sure if that's the case, though..
>
> -Please consider power difference of arrival or phase interferometry
> as alternative methods.
>
> Regards,
> Kyeong Su Shin
> 
> *보낸 사람:* Qasim Chaudhari  대신
> Discuss-gnuradio 
> *보낸 날짜:* 2020년 1월 30일 목요일 오전 11:05
> *받는 사람:* discuss-gnuradio@gnu.org ;
> mike.nel...@rdss.com 
> *제목:* Re: Recommendation for high sample rate receiver?
>  
> Hi
>    A high sample rate for such ns times of arrival resolution is
> impractical. Same holds for high SNR and longer times of measurement.
> GPS and most other high resolution positioning systems stitch the
> information together from the signal time of arrival with the carrier
> phase of arrival. Since carrier frequencies are incredibly high, their
> phase can provide such ns accuracy because the phase information is
> preserved across the downconversion stages with sufficient linearity.
> For this purpose, the algorithms also need to determine the integer
> number of arriving wavelengths.
>
> Cheers,
> Qasim

Re: Recommendation for high sample rate receiver?

[Mike]

The device in question is to replace an existing RF-to-baseband
component of a geographically distributed signal collection system. 
Each receiving station samples the 6 MHz passband, detects a signal and
estimates a time-of-arrival, then sends it on to a central facility that
performs the multilateration calculations.  The existing TOA codebase
(and other decoders) expects 2 ns samples.

Thanks!


On 1/26/2020 3:38 PM, Marcus Müller wrote:

> Seconding what Brian says:
> Math says *any* signal up to a bandwidth of 6 MHz can be represented by
> 6 MS/s. So, either, your signal isn't that bandlimited, or you forgot
> to tell us an important requirement (or you might have your math
> wrong).
>
> Best regards,
> Marcus
>
> On Sun, 2020-01-26 at 14:13 -0500, Brian Padalino wrote:
>> On Sun, Jan 26, 2020 at 1:20 PM Mike  wrote:
>>> Hello,
>>>
>>> I am hoping someone on the list could suggest a device that
>>> receives in
>>> lower L-band (1.0 to 1.6 GHz) and can cover 6 MHz (+/- 3 MHz around
>>> center) at (and here's the trick) 500 MS/second with at least 8
>>> bits of
>>> resolution.  I'm looking for 2 ns baseband samples from multiple
>>> receivers to perform trilateration.
>> Interesting conflicting requirements with the baseband bandwidth of
>> 6MHz but 500MSPS ADC.
>>
>> Are you sure you don't need a much wider baseband bandwidth as well?
>>
>> Brian

Recommendation for high sample rate receiver?

[Mike]

Hello,

I am hoping someone on the list could suggest a device that receives in
lower L-band (1.0 to 1.6 GHz) and can cover 6 MHz (+/- 3 MHz around
center) at (and here's the trick) 500 MS/second with at least 8 bits of
resolution.  I'm looking for 2 ns baseband samples from multiple
receivers to perform trilateration.

Thank you!

Re: [Discuss-gnuradio] multi_usrp: RX channel LARGENUMBER out of range for configured RX frontends

[Mike Johnson]

I guess I should have debugged a bit longer before posting.  The problem
has been solved.  Once I entered in "[0,1]" into the Stream Channels text
box in the USRP Source element in my GRC flow graph, both channels began
receiving.  Thanks.

On Tue, Feb 19, 2019 at 9:50 AM Mike Johnson  wrote:

> I have an X310 with two UBX-160 v2 daughter cards installed.  I've built a
> single channel GRC flow graph, using Subdev Spec of "A:0" then "B:0", to
> confirm that each of the daughter cards receives correctly.  However, when
> I increase the Num Channels from 1 to 2 in GRC, and use a Subdev Spec of
> "A:0 B:0", I get this error:
>
> RuntimeError: LookupError: IndexError: multi_usrp: RX channel
> 139784932838560 out of range for configured RX frontends
>
> I am using GNURadio version: 3.8tech-preview-215-g7e5396b2
>
> I am using UHD version: UHD_3.14.0.0-0-gd20a7ae2
>
> I'm attempting to build a dual-channel satellite surrogate system.  Any
> assistance is greatly appreciated.
>
>
> Output of uhd_usrp_probe is as follows:
>
>  /
> |   Device: X-Series Device
> | _
> |/
> |   |   Mboard: X310
> |   |   revision: 11
> |   |   revision_compat: 7
> |   |   product: 30818
> |   |   mac-addr0: 00:80:2f:24:1a:86
> |   |   mac-addr1: 00:80:2f:24:1a:87
> |   |   gateway: 192.168.10.1
> |   |   ip-addr0: 192.168.10.2
> |   |   subnet0: 255.255.255.0
> |   |   ip-addr1: 192.168.20.2
> |   |   subnet1: 255.255.255.0
> |   |   ip-addr2: 192.168.30.2
> |   |   subnet2: 255.255.255.0
> |   |   ip-addr3: 192.168.40.2
> |   |   subnet3: 255.255.255.0
> |   |   serial: 317A1EE
> |   |   FW Version: 6.0
> |   |   FPGA Version: 36.0
> |   |   FPGA git hash: 4f25ed1
> |   |   RFNoC capable: Yes
> |   |
> |   |   Time sources:  internal, external, gpsdo
> |   |   Clock sources: internal, external, gpsdo
> |   |   Sensors: ref_locked
> |   | _
> |   |/
> |   |   |   RX Dboard: A
> |   |   |   ID: UBX-160 v2 (0x007e)
> |   |   |   Serial: 3176381
> |   |   | _
> |   |   |/
> |   |   |   |   RX Frontend: 0
> |   |   |   |   Name: UBX RX
> |   |   |   |   Antennas: TX/RX, RX2, CAL
> |   |   |   |   Sensors: lo_locked
> |   |   |   |   Freq range: 10.000 to 6000.000 MHz
> |   |   |   |   Gain range PGA0: 0.0 to 31.5 step 0.5 dB
> |   |   |   |   Bandwidth range: 16000.0 to 16000.0 step 0.0 Hz
> |   |   |   |   Connection Type: IQ
> |   |   |   |   Uses LO offset: No
> |   |   | _
> |   |   |/
> |   |   |   |   RX Codec: A
> |   |   |   |   Name: ads62p48
> |   |   |   |   Gain range digital: 0.0 to 6.0 step 0.5 dB
> |   | _
> |   |/
> |   |   |   RX Dboard: B
> |   |   |   ID: UBX-160 v2 (0x007e)
> |   |   |   Serial: 3176382
> |   |   | _
> |   |   |/
> |   |   |   |   RX Frontend: 0
> |   |   |   |   Name: UBX RX
> |   |   |   |   Antennas: TX/RX, RX2, CAL
> |   |   |   |   Sensors: lo_locked
> |   |   |   |   Freq range: 10.000 to 6000.000 MHz
> |   |   |   |   Gain range PGA0: 0.0 to 31.5 step 0.5 dB
> |   |   |   |   Bandwidth range: 16000.0 to 16000.0 step 0.0 Hz
> |   |   |   |   Connection Type: IQ
> |   |   |   |   Uses LO offset: No
> |   |   | _
> |   |   |/
> |   |   |   |   RX Codec: B
> |   |   |   |   Name: ads62p48
> |   |   |   |   Gain range digital: 0.0 to 6.0 step 0.5 dB
> |   | _
> |   |/
> |   |   |   TX Dboard: A
> |   |   |   ID: UBX-160 v2 (0x007d)
> |   |   |   Serial: 3176381
> |   |   | _
> |   |   |/
> |   |   |   |   TX Frontend: 0
> |   |   |   |   Name: UBX TX
> |   |   |   |   Antennas: TX/RX, CAL
> |   |   |   |   Sensors: lo_locked
> |   |   |   |   Freq range: 10.000 to 6000.000 MHz
> |   |   |   |   Gain range PGA0: 0.0 to 31.5 step 0.5 dB
> |   |   |   |   Bandwidth range: 16000.0 to 16000.0 step 0.0 Hz
> |   |   |   |   Connection Type: QI
> |   |   |   |   Uses LO offset: No
> |   |   | _
> |   |   |/
> |   |   |   |   TX Codec: A
> |   |   |   |   Name: ad9146
> |   |   |   |   Gain Elements: None
> |   | _
> |

[Discuss-gnuradio] multi_usrp: RX channel LARGENUMBER out of range for configured RX frontends

[Mike Johnson]

I have an X310 with two UBX-160 v2 daughter cards installed.  I've built a
single channel GRC flow graph, using Subdev Spec of "A:0" then "B:0", to
confirm that each of the daughter cards receives correctly.  However, when
I increase the Num Channels from 1 to 2 in GRC, and use a Subdev Spec of
"A:0 B:0", I get this error:

RuntimeError: LookupError: IndexError: multi_usrp: RX channel
139784932838560 out of range for configured RX frontends

I am using GNURadio version: 3.8tech-preview-215-g7e5396b2

I am using UHD version: UHD_3.14.0.0-0-gd20a7ae2

I'm attempting to build a dual-channel satellite surrogate system.  Any
assistance is greatly appreciated.


Output of uhd_usrp_probe is as follows:

 /
|   Device: X-Series Device
| _
|/
|   |   Mboard: X310
|   |   revision: 11
|   |   revision_compat: 7
|   |   product: 30818
|   |   mac-addr0: 00:80:2f:24:1a:86
|   |   mac-addr1: 00:80:2f:24:1a:87
|   |   gateway: 192.168.10.1
|   |   ip-addr0: 192.168.10.2
|   |   subnet0: 255.255.255.0
|   |   ip-addr1: 192.168.20.2
|   |   subnet1: 255.255.255.0
|   |   ip-addr2: 192.168.30.2
|   |   subnet2: 255.255.255.0
|   |   ip-addr3: 192.168.40.2
|   |   subnet3: 255.255.255.0
|   |   serial: 317A1EE
|   |   FW Version: 6.0
|   |   FPGA Version: 36.0
|   |   FPGA git hash: 4f25ed1
|   |   RFNoC capable: Yes
|   |
|   |   Time sources:  internal, external, gpsdo
|   |   Clock sources: internal, external, gpsdo
|   |   Sensors: ref_locked
|   | _
|   |/
|   |   |   RX Dboard: A
|   |   |   ID: UBX-160 v2 (0x007e)
|   |   |   Serial: 3176381
|   |   | _
|   |   |/
|   |   |   |   RX Frontend: 0
|   |   |   |   Name: UBX RX
|   |   |   |   Antennas: TX/RX, RX2, CAL
|   |   |   |   Sensors: lo_locked
|   |   |   |   Freq range: 10.000 to 6000.000 MHz
|   |   |   |   Gain range PGA0: 0.0 to 31.5 step 0.5 dB
|   |   |   |   Bandwidth range: 16000.0 to 16000.0 step 0.0 Hz
|   |   |   |   Connection Type: IQ
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |/
|   |   |   |   RX Codec: A
|   |   |   |   Name: ads62p48
|   |   |   |   Gain range digital: 0.0 to 6.0 step 0.5 dB
|   | _
|   |/
|   |   |   RX Dboard: B
|   |   |   ID: UBX-160 v2 (0x007e)
|   |   |   Serial: 3176382
|   |   | _
|   |   |/
|   |   |   |   RX Frontend: 0
|   |   |   |   Name: UBX RX
|   |   |   |   Antennas: TX/RX, RX2, CAL
|   |   |   |   Sensors: lo_locked
|   |   |   |   Freq range: 10.000 to 6000.000 MHz
|   |   |   |   Gain range PGA0: 0.0 to 31.5 step 0.5 dB
|   |   |   |   Bandwidth range: 16000.0 to 16000.0 step 0.0 Hz
|   |   |   |   Connection Type: IQ
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |/
|   |   |   |   RX Codec: B
|   |   |   |   Name: ads62p48
|   |   |   |   Gain range digital: 0.0 to 6.0 step 0.5 dB
|   | _
|   |/
|   |   |   TX Dboard: A
|   |   |   ID: UBX-160 v2 (0x007d)
|   |   |   Serial: 3176381
|   |   | _
|   |   |/
|   |   |   |   TX Frontend: 0
|   |   |   |   Name: UBX TX
|   |   |   |   Antennas: TX/RX, CAL
|   |   |   |   Sensors: lo_locked
|   |   |   |   Freq range: 10.000 to 6000.000 MHz
|   |   |   |   Gain range PGA0: 0.0 to 31.5 step 0.5 dB
|   |   |   |   Bandwidth range: 16000.0 to 16000.0 step 0.0 Hz
|   |   |   |   Connection Type: QI
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |/
|   |   |   |   TX Codec: A
|   |   |   |   Name: ad9146
|   |   |   |   Gain Elements: None
|   | _
|   |/
|   |   |   TX Dboard: B
|   |   |   ID: UBX-160 v2 (0x007d)
|   |   |   Serial: 3176382
|   |   | _
|   |   |/
|   |   |   |   TX Frontend: 0
|   |   |   |   Name: UBX TX
|   |   |   |   Antennas: TX/RX, CAL
|   |   |   |   Sensors: lo_locked
|   |   |   |   Freq range: 10.000 to 6000.000 MHz
|   |   |   |   Gain range PGA0: 0.0 to 31.5 step 0.5 dB
|   |   |   |   Bandwidth range: 16000.0 to 16000.0 step 0.0 Hz
|   |   |   |   Connection Type: QI
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |/
|   |   |   |   TX Codec: B
|   |   |   |   Name: ad9146
|   |   |   |   Gain Elements: None
|   | _
|   |/
|   |   |   RFNoC blocks on this device:
|   |   |
|   |   |   * 

[Discuss-gnuradio] uhd_swig still missing

[Mike Gilmer]

I reported this problem previously (July 2018 timeframe) and I am still
wrestling with it.

Running Fedora 28 on Dell laptop. Prior to updating laptop to Fed 28,
gnuradio worked fine.

I ran dnf remove uhd (which removed gnu radio as well)  and then
reinstalled them using dnf install

And just like before, I can run gnuradio companion and build my grc file
but I cannot load it to my Ettus B210

I get the error:

Traceback (most recent call last):
  File "/home/foofoo/dev/B210/b210fftdisplay.py", line 24, in 
from gnuradio import uhd
  File "/usr/local/lib64/python2.7/site-packages/gnuradio/uhd/__init__.py",
line 135, in 
_prepare_uhd_swig()
  File "/usr/local/lib64/python2.7/site-packages/gnuradio/uhd/__init__.py",
line 38, in _prepare_uhd_swig
import uhd_swig
  File "/usr/local/lib64/python2.7/site-packages/gnuradio/uhd/uhd_swig.py",
line 17, in 
_uhd_swig = swig_import_helper()
  File "/usr/local/lib64/python2.7/site-packages/gnuradio/uhd/uhd_swig.py",
line 16, in swig_import_helper
return importlib.import_module('_uhd_swig')
  File "/usr/lib64/python2.7/importlib/__init__.py", line 37, in
import_module
__import__(name)
ImportError: No module named _uhd_swig
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] E310: Setting "master clock"

[Mike Gilmer]

I've had no problem implementing several command line options using GNU
Radio's parameters blocks.  I can set sample rate, bandwidth, center
frequency successfully.

My command line looks like this:

 python E310_GP.py  --samprate 20 --ctrfrq 91500 ...

However, I wanted to also set the "master clock rate" or whatever it's
called.  After significant googling  and hacking I found  the term I wanted
was apparently "clock_rate" .

I added a parameter block (like I had for sample rate, etc., previously)
and generated a grc (and .py)  but had several key errors.

1) It listed clock-rate (not clock_rate) in the  def argument_parser():
part of the script :

parser.add_option(
"", "--clock-rate", dest="clock_rate", type="eng_float",
default=eng_notation.num_to_str(3200.0),
help="Set clock_rate [default=%default]")

( I have not used a dash anywhere in my grc that I can tell )

2) The .py  was missing the call to the *set* function which I had to add
manually.  As such

   self.uhd_usrp_source_0.set_clock_rate(clock_rate)

It seems to work properly. I get indications during start up that the E310
is selecting the clock_rate per my settings, and it's also not throwing any
decimation error when I deliberately mismanage the clock-sample rate ratio.

So, does anyone see a problem with what I've done or how?
Is there a doc with these settings spelled out?  I recall digging hard even
for samp_rate and center_freq.

Thanks!

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

Re: [Discuss-gnuradio] Missing uhd_swig

[Mike Gilmer]

IIRC

I built from source both this time and previously (under Fedora 23)
because the "package" would not build successfully.

Mike

On Mon, Jul 9, 2018 at 1:53 PM, Müller, Marcus (CEL) 
wrote:

> Hm, did you also build UHD from source on your old Fedora?
> On Mon, 2018-07-09 at 13:46 -0400, Mike Gilmer wrote:
> > I updated my Fedora version release 28
> >
> > Afterwards I had to rebuild GNU radio (of course) to get GNU radio
> companion to even load.
> > I though my work was done, but now that I've tried to use GRC, I am
> getting the following error when I go to "Execute":
> >
> > 
> > Generating: '/home/myself/dev/B210/top_block.py'
> >
> > Executing: /usr/bin/python2 -u /home/myself/dev/B210/top_block.py
> >
> > Traceback (most recent call last):
> >   File "/home/myself/dev/B210/top_block.py", line 24, in 
> > from gnuradio import uhd
> >   File "/usr/local/lib64/python2.7/site-packages/gnuradio/uhd/__init__.py",
> line 135, in 
> > _prepare_uhd_swig()
> >   File "/usr/local/lib64/python2.7/site-packages/gnuradio/uhd/__init__.py",
> line 38, in _prepare_uhd_swig
> > import uhd_swig
> >   File "/usr/local/lib64/python2.7/site-packages/gnuradio/uhd/uhd_swig.py",
> line 17, in 
> > _uhd_swig = swig_import_helper()
> >   File "/usr/local/lib64/python2.7/site-packages/gnuradio/uhd/uhd_swig.py",
> line 16, in swig_import_helper
> > return importlib.import_module('_uhd_swig')
> >   File "/usr/lib64/python2.7/importlib/__init__.py", line 37, in
> import_module
> > __import__(name)
> > ImportError: No module named _uhd_swig
> > 
> >
> > Any help appreciated.
> >
> > Thanks
> > Mike
> > ___
> > 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] Missing uhd_swig

[Mike Gilmer]

I updated my Fedora version release 28

Afterwards I had to rebuild GNU radio (of course) to get GNU radio
companion to even load.
I though my work was done, but now that I've tried to use GRC, I am getting
the following error when I go to "Execute":


Generating: '/home/myself/dev/B210/top_block.py'

Executing: /usr/bin/python2 -u /home/myself/dev/B210/top_block.py

Traceback (most recent call last):
  File "/home/myself/dev/B210/top_block.py", line 24, in 
from gnuradio import uhd
  File "/usr/local/lib64/python2.7/site-packages/gnuradio/uhd/__init__.py",
line 135, in 
_prepare_uhd_swig()
  File "/usr/local/lib64/python2.7/site-packages/gnuradio/uhd/__init__.py",
line 38, in _prepare_uhd_swig
import uhd_swig
  File "/usr/local/lib64/python2.7/site-packages/gnuradio/uhd/uhd_swig.py",
line 17, in 
_uhd_swig = swig_import_helper()
  File "/usr/local/lib64/python2.7/site-packages/gnuradio/uhd/uhd_swig.py",
line 16, in swig_import_helper
return importlib.import_module('_uhd_swig')
  File "/usr/lib64/python2.7/importlib/__init__.py", line 37, in
import_module
__import__(name)
ImportError: No module named _uhd_swig


Any help appreciated.

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

Re: [Discuss-gnuradio] Import Error running companion after upgrade to Fedora 27

[Mike Gilmer]

Yes, thanks - I figured out I needed to have been doing that. ;-)

What a drudgery - I had to make changes to many files to get as far as I've
gotten (now up to 87% finished) and now I'm getting the errors:

/usr/bin/ld: warning: libboost_date_time.so.1.58.0, needed by
/usr/local/lib64/libuhd.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libboost_filesystem.so.1.58.0, needed by
/usr/local/lib64/libuhd.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libboost_program_options.so.1.58.0, needed by
/usr/local/lib64/libuhd.so, not found (try using -rpath or -rpath-link)
.
.
.

Any ideas?

Thanks.
Mike

On Tue, Jan 30, 2018 at 11:29 AM, Jeff Long <willco...@gmail.com> wrote:

> Import errors can happen for a variety of reasons, even if the packages
> are still in the right place. A common reason is that libraries provided by
> rpms, and that gnuradio depends on, have changed. Since Boost has changed
> to version 1.64 in Fedora 27, you'll have to rebuild gnuradio.
>
>
> On 01/30/2018 11:17 AM, Mike Gilmer wrote:
>
>> I recently upgraded my Fedora 23 laptop (on which gnuradio companion
>> worked fine) to Fedora 27
>>
>> Now when I try to run gnuradio-companion I get an error window.
>>
>> 
>>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
>> 
>>
>> (libboost_date_time.so.1.58.0: cannot open shared object file: No such
>> file or directory)
>>
>> I've checked the two env variables and they are set properly AFAIK.
>>
>> $ echo $PYTHONPATH
>> /usr/local/lib64/python2.7/site-packages
>>
>>
>> $ echo $LD_LIBRARY_PATH
>> /usr/lib64
>>
>> Any advice would be appreciated.
>>
>> -Mike
>>
>>
>> ___
>> 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] Import Error running companion after upgrade to Fedora 27

[Mike Gilmer]

I recently upgraded my Fedora 23 laptop (on which gnuradio companion worked
fine) to Fedora 27

Now when I try to run gnuradio-companion I get an error window.


  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


(libboost_date_time.so.1.58.0: cannot open shared object file: No such file
or directory)

I've checked the two env variables and they are set properly AFAIK.

$ echo $PYTHONPATH
/usr/local/lib64/python2.7/site-packages


$ echo $LD_LIBRARY_PATH
/usr/lib64

Any advice would be appreciated.

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

[Discuss-gnuradio] Getting consistent noutput_items

[Mike Rex]

I am having a problem adapting a UDP sink block for sending raw protocol 
frames. I am using a 32KB binary file source connected to my Sink 
connecting to my Source on another PC, finally outputting to a file 
sink.  My expectation/goal is that my output file is identical to the 
input file so that nothing is lost or added to the data.


When I use a 32KB input file and using byte data size, the noitems are 
32768 and I divide that down into 4 equal 8192 packets with 32 bytes 
frame overhead. I can do this and get the 4 expected packets received 
and file output matches input file.


However, when I go to 64KB input file, the expectation is simply for it 
to send 8 packets of same size.  However, my initial debug is showing 
entering the sink block 3 times instead of twice; getting noitems values 
of 32768, 32767, and 1.  What this means, is my 8th packet is missing 
the very last byte, and a 9th packet is sent with the final byte plus 27 
bytes padding, which means the resultant file is short by a byte, or 
long by the padding.


noutput_items (dec): 32768
d_block_size (dec): 1
pay_len (dec): 8192
numPackets: 4
lastPayloadSize (dec): 0

noutput_items (dec): 32767
d_block_size (dec): 1
numPackets: 4
lastPayloadSize (dec): 8191

noutput_items (dec): 1
d_block_size (dec): 1
numPackets: 1
lastPayloadSize (dec): 1


When using complex, then 8 bytes are pushed into a 9th packet, so 
remainder bytes change with the itemsize.  Is there something I can do 
to make noutput_items consistently be 32768, or will I need to find a 
workaround to preventing/stripping the padding on the receiver side?  
I'm pretty sure the intended user will need to be able to input files 
larger than 32KB.


noutput_items (dec): 4096
d_block_size (dec): 8
numPackets: 4
lastPayloadSize (dec): 0

noutput_items (dec): 4095
d_block_size (dec): 8
numPackets: 4
lastPayloadSize (dec): 8184

noi (dec): 8
noutput_items (dec): 1
d_block_size (dec): 8
numPackets: 1
lastPayloadSize (dec): 8

Is this related to noutput_items being an int?  I wouldn't expect it to 
be an issue at 65535.  Is there anything I can do to get a consistent or 
even number of noutput_items? Not sure what my best work around options 
are, but getting noutput_items of 32768 consistently sure would make my 
life easier. I thought I just needed to make the input file a multiple 
of 32 bytes to ensure I'm not needing to pad the final packet, but 64KB 
is a multiple of 32 and has this dangling data issue.  I believe the 
user will be inputting both a file source (with/without repeat) and 
later streaming to it.  This might not be an issue for streaming, but I 
do believe this will be an issue for file sources.


Thanks in advance for any ideas or solutions.
Mike


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

Re: [Discuss-gnuradio] XML parameter checking

[Mike Rex]

Thanks Marcus!  That should have been a natural next step for me, but so 
many Google search results for xml operators put "=" as a comparison!  
Knowing it just needs to be a valid Python expression is good to know 
for future needs.


Much appreciated for your assistance once again.

p.s. for anyone who finds this thread in the future, Marcus meant 
gr-/analog//grc/analog_nbfm_rx.xml for an example of a mod in check tag.


On 2017-10-19 2:36 AM, Marcus Müller wrote:

Hi Mike,

what's in the  tag just needs to be a valid Python expression, 
afaik. So,


$psize % 8 == 0

would work (notice the double =; this is comparison, not assignment!).

For comparison, see the gr-audio/grc/analog_nbfm_rx.xml, for example.

Best regards,

Marcus


On 2017-10-19 04:02, Mike Rex wrote:
What would be the best way to make sure the user enters a parameter 
that is a multiple of 8 in the GRC XML file?  My first thought is 
this might do the trick, but seems there is no mod function for XML.  
Any suggestions?


$psize % 8 = 0 or $psize mod 8 = 0

Thanks in advance,
Mike


___
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] XML parameter checking

[Mike Rex]

What would be the best way to make sure the user enters a parameter that 
is a multiple of 8 in the GRC XML file?  My first thought is this might 
do the trick, but seems there is no mod function for XML.  Any suggestions?


$psize % 8 = 0 or $psize mod 8 = 0

Thanks in advance,
Mike


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

Re: [Discuss-gnuradio] Install GNU Radio Live CD to Hard Disk

[Mike Rex]

Murray,

You can make the Live DVD have persistence if you use a USB drive 
instead of DVD.  I use a 32GB USB key for this purpose.  I strongly 
recommend USB 3.0.


https://www.gnuradio.org/blog/using-gnu-radio-live-sdr-environment/

Scroll down to the section "Creating a Bootable USB Drive with 
Persistence".  Make sure you grab the updated grub files from the 
mailing list link that's in that section.


Regards,

Mike


On 2017-09-07 7:09 AM, Murray Thomson wrote:

Hi Marcus,

Thanks for the explanation, I was mistaken about removing the install 
option.


My specific situation was that I wanted to test my project in the 
latest GnuRadio. This version was released but not in the Ubuntu repo. 
I was worried about breaking my current setup trying to upgrade or 
install two instances of GnuRadio. The Live DVD wasn't a good option 
for me because is not persistent. I solved this creating a VirtualBox 
and installing GnuRadio after. As you said, it wasn't hard, but it 
took me a while to do and I did had some problems with PyBOMBS (it was 
my first attempt ;).


It would be nice to have a VirtualBox image that a new user can import 
and start using, specially for Windows users.


Just as a related note, this maybe interesting for someone that wants 
to create an iso from a working system and then install it in a 
different machine:

http://pinguyos.com/2015/09/pinguy-builder-an-app-to-backupremix-buntu/

Kind Regards,
Murray


On 7 September 2017 at 11:53, Marcus Müller <muel...@kit.edu 
<mailto:muel...@kit.edu>> wrote:


Hi Murray,

technically, corganlabs (who's designing that liveDVD) didn't
*remove* the install option – it's just that the Ubuntu doesn't
come with a solution to install stuff like it's installed on the
DVD to disk. You just end up with a default Ubuntu.

That's why it's kinda hard to do this right.

I do have a live system of my own, Fedora-based, which comes with
a lot less modules than the official live DVD. But: Fedora does
package a lot of the popular OOT modules. Also, when you start
with a working GNU Radio installation, building OOTs from source
shouldn't be all that hard, even without tools like PyBOMBS.

So, maybe this is the point to actually specifically ask you: what
did you try to do? Is there something that we can make better
about the ecosystem (and we actually intentionally carry
"ecosystem" in the logo!) so that things are less of a hassle for you?

Best regards,
Marcus


On 09/07/2017 12:47 AM, Murray Thomson wrote:

Hi,

In the last couple of years I have read this same request from
different people, including myself. It iss true that installing
GnuRadio on top of a fresh Ubuntu install is not hard, but it
does take time. Sometimes, being able to create an quick
installation with a known to work setup is useful. In my case, I
just wanted to create a Virtualbox to test the latest GnuRadio.

I see no benefit on removing the install option and I would
appreciate if this is considered for the next Live DVD.

Regards,
Murray

On 6 September 2017 at 19:41, Marcus Müller <muel...@kit.edu
<mailto:muel...@kit.edu>> wrote:

Dear Srinivasan,

please try to keep discussions on-list!

Regarding your question: I don't understand. My email says
exactly that you can't

Best regards,

Marcus


On 09/06/2017 05:34 PM, Srinivasan wrote:

Thanks. The problems , installing each module introduce
another problems. Looks like Live CD is working fine with
all modules.
Any way , can we install in HD using iso image ? anything
you can suggest !


Sent with ProtonMail <https://protonmail.com> Secure Email.


 Original Message 
Subject: Re: [Discuss-gnuradio] Install GNU Radio Live CD
to Hard Disk
Local Time: September 6, 2017 9:57 PM
UTC Time: September 6, 2017 2:57 PM
From: muel...@kit.edu <mailto:muel...@kit.edu>
To: discuss-gnuradio@gnu.org <mailto:discuss-gnuradio@gnu.org>


As far as I'm aware of, there's no direct way.

Also, little benefit, as with modern Ubuntu, you can also
use Ubuntu's gnuradio package (unless you /want/ to build
GNU Radio from source or use a specific version of a
dependency of GNU Radio, but neither are use cases for
users of the live DVD).

So, instead, just install Ubuntu 16.04, or Fedora 26, or
Gentoo, or Arch Linux, or the most recent Debian, on your
hard drive using their installation methods, and then
install GNU Radio using the respective package manager.

Best regards,

Marcus Müller


On 09/06/2017 04:24 PM, Srinivasan wrote:

Hi There,

I want to install and run gnuradio live C

Re: [Discuss-gnuradio] RuntimeError: udp_sink(1): insufficient connected output ports

[Mike Rex]

Ron,

You can take these caps as enthusiastic shouting:  THANK YOU, THANK YOU, 
THANK YOU.  That fixed my issue. I really needed that to enjoy my weekend :)


Glad you also mentioned needing to rebuild GNU Radio.  That really was 
necessary.


Have a really great weekend!

Thanks,
Mike



On 2017-08-31 8:49 PM, Ron Economos wrote:
I've been having troubles with the master branch lately myself. I've 
traced it to having liblog4cpp5 installed or not. If liblog4cpp5 is 
NOT installed, GNU Radio seems oddly unstable, especially for OOT 
modules. Note that build-gnuradio does NOT install liblog4cpp5.


Try installing liblog4cpp5-dev (sudo apt-get install liblog4cpp5-dev) 
and rebuilding GNU Radio.


Ron

On 08/31/2017 08:17 PM, Mike Rex wrote:
gnuradio version: 3.7.12git-218-g811bee8c installed from 
build-gnuradio script.
Dev PC: Xubuntu 16.04 running in VM Workstation  (mentioned because 
some python bugs are hypervisor effected only)
Problem: I am getting errors when running flow graphs in GRC after 
adding variables to the udp_sink_impl.h file.


I've been struggling all week making changes to an existing project 
(https://github.com/ghostop14/gr-grnet) that are alternate versions 
of TCP/UDP sink/source. I planned on starting with this project, 
adding in some missing bits from the gr-blocks UDP sink/source, and 
then finally modifying it for our particular application (raw 
protocol instead of UDP with IP).


I'm having problems adding variables to 
udp_sink_impl.h/udp_source_impl.h without getting errors when running 
the flow graph. I may be overlooking something simple, but I'm really 
just trying to append the new variable following the usage of other 
existing variables.  I think there is either something wrong with my 
python 2.7 on my xubuntu 16.04 PC, or there needs to be additional 
memory allocated somewhere. Typically, when adding a new variable to 
udp_sink_impl.h, I'll get the following, where the "NUM needed" 
varies from run to run:


Traceback (most recent call last):
  File "/home/mike/top_block.py", line 110, in 
    main()
  File "/home/mike/top_block.py", line 99, in main
    tb.start()
  File 
"/usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py", 
line 109, in start

    top_block_start_unlocked(self._impl, max_noutput_items)
  File 
"/usr/local/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py", 
line 5681, in top_block_start_unlocked

    return _runtime_swig.top_block_start_unlocked(r, max_noutput_items)
RuntimeError: udp_sink(1): insufficient connected output ports 
(54929632 needed, 0 connected)



Other times, the flowgraph will start and then crash after the 
private  constructor finishes and the error will be related to 
python2 and corrupted size vs prev_size...


*** Error in `/usr/bin/python2': corrupted size vs. prev_size: 
0x03428620 ***


Comment out the variable, and then it runs every time.  Geez, while 
writing this email, I restored the variable to get the corrupted size 
error.  Pressed Play again and it ran.  Sometimes 2/3 tries works, 
and other times 2/3 tries gets the python error (I did not notice 
that behavior until just now). Added another variable, and then it 
went up to like 1 in 6 worked or 1 in 10 worked, and with another 
variable added, it doesn't ever work again.  So this looks like a 
memory allocation/corruption problem that somehow randomly works.


When testing block changes, what is the correct process to ensure 
gnuradio sees the newest installed code only? I've been doing:


(current dir is build)
sudo make uninstall && sudo ldconfig && cd .. && rm -rf build
mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE="Debug" ../
make -j8 && sudo make install && sudo ldconfig

Is there something I'm missing that completely removes old stuff or 
failing to import all the new stuff?


I do have another local repo where I have many more changes and the 
payload_size is working (don't know what changed when it suddenly 
started working), but further adding variables like 'eof' result in 
the error in question.  The simplest changes I can make and reproduce 
this can be seen here: 
https://github.com/ghostop14/gr-grnet/compare/master...BCITMike:master. 
I'm changing 4 files:

modified: grc/grnet_udp_sink.xml
modified: include/grnet/udp_sink.h
modified: lib/udp_sink_impl.cc
modified: lib/udp_sink_impl.h

So either I'm missing something fundamental or my dev setup is bad.  
If someone can point out what I'm missing to make this work, I would 
greatly appreciate it!


Thanks!
Mike


___
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] RuntimeError: udp_sink(1): insufficient connected output ports

[Mike Rex]

gnuradio version: 3.7.12git-218-g811bee8c installed from build-gnuradio 
script.
Dev PC: Xubuntu 16.04 running in VM Workstation  (mentioned because some 
python bugs are hypervisor effected only)
Problem: I am getting errors when running flow graphs in GRC after 
adding variables to the udp_sink_impl.h file.


I've been struggling all week making changes to an existing project 
(https://github.com/ghostop14/gr-grnet) that are alternate versions of 
TCP/UDP sink/source. I planned on starting with this project, adding in 
some missing bits from the gr-blocks UDP sink/source, and then finally 
modifying it for our particular application (raw protocol instead of UDP 
with IP).


I'm having problems adding variables to 
udp_sink_impl.h/udp_source_impl.h without getting errors when running 
the flow graph. I may be overlooking something simple, but I'm really 
just trying to append the new variable following the usage of other 
existing variables.  I think there is either something wrong with my 
python 2.7 on my xubuntu 16.04 PC, or there needs to be additional 
memory allocated somewhere. Typically, when adding a new variable to 
udp_sink_impl.h, I'll get the following, where the "NUM needed" varies 
from run to run:


Traceback (most recent call last):
  File "/home/mike/top_block.py", line 110, in 
    main()
  File "/home/mike/top_block.py", line 99, in main
    tb.start()
  File 
"/usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py", line 
109, in start

    top_block_start_unlocked(self._impl, max_noutput_items)
  File 
"/usr/local/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py", 
line 5681, in top_block_start_unlocked

    return _runtime_swig.top_block_start_unlocked(r, max_noutput_items)
RuntimeError: udp_sink(1): insufficient connected output ports (54929632 
needed, 0 connected)



Other times, the flowgraph will start and then crash after the private  
constructor finishes and the error will be related to python2 and 
corrupted size vs prev_size...


*** Error in `/usr/bin/python2': corrupted size vs. prev_size: 
0x03428620 ***


Comment out the variable, and then it runs every time.  Geez, while 
writing this email, I restored the variable to get the corrupted size 
error.  Pressed Play again and it ran.  Sometimes 2/3 tries works, and 
other times 2/3 tries gets the python error (I did not notice that 
behavior until just now). Added another variable, and then it went up to 
like 1 in 6 worked or 1 in 10 worked, and with another variable added, 
it doesn't ever work again.  So this looks like a memory 
allocation/corruption problem that somehow randomly works.


When testing block changes, what is the correct process to ensure 
gnuradio sees the newest installed code only? I've been doing:


(current dir is build)
sudo make uninstall && sudo ldconfig && cd .. && rm -rf build
mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE="Debug" ../
make -j8 && sudo make install && sudo ldconfig

Is there something I'm missing that completely removes old stuff or 
failing to import all the new stuff?


I do have another local repo where I have many more changes and the 
payload_size is working (don't know what changed when it suddenly 
started working), but further adding variables like 'eof' result in the 
error in question.  The simplest changes I can make and reproduce this 
can be seen here: 
https://github.com/ghostop14/gr-grnet/compare/master...BCITMike:master. 
I'm changing 4 files:

modified: grc/grnet_udp_sink.xml
modified: include/grnet/udp_sink.h
modified: lib/udp_sink_impl.cc
modified: lib/udp_sink_impl.h

So either I'm missing something fundamental or my dev setup is bad.  If 
someone can point out what I'm missing to make this work, I would 
greatly appreciate it!


Thanks!
Mike


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

Re: [Discuss-gnuradio] Command line compile GRC xml

[Mike Rex]

Marcus,

Hmm, not sure if this is python paths 
(https://forums.gentoo.org/viewtopic-t-1004210-start-0.html) or gnuradio 
error.  I think it's the later since we're using version 3.7.10, and I 
think the gnuradio fix went in after that release.


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

Corrective action: I will tell colleague we need newer gnuradio version.

Regards,
Mike


On 2017-08-30 7:03 PM, Mike Rex wrote:


Marcus,

Thank you for the reply. There was a miscommunication with my 
colleague.   He got a /different /error with grcc and not gtk 
related.  He ran the gnuradio-companion and received an error related 
to GTK then seg faulted.  That makes sense now that I know he ran the 
companion and not grcc.


So when I ran grcc on the embedded box, it gave:

Traceback (most recent call last):
  File "/usr/bin/grcc", line 32, in 
    from gnuradio.grc.python.Platform import Platform
ImportError: No module named python.Platform

Whereas this command ran on my xubuntu PC just fine.  So this looks 
like a problem with the embedded box's python install. It's running a 
ppc CPU and we didn't make the image its running.  So we'll need to 
track this down and fix.


Thank you for confirming X11 isn't needed or else my colleague and I 
wouldn't have caught this.  I'll look into this python.Platform issue 
and report back if grcc doesn't run successfully like it did on my 
test linux PC.


Thanks,
Mike


On 2017-08-30 6:18 PM, Marcus Müller wrote:

Dear Mike,

in theory, GRCC really shouldn't need X11 at all. Can you elaborate on
what problems you're encountering?

Cheers,

Marcus


On 30.08.2017 23:04, Mike Rex wrote:

Not sure if you posted the url you intended, that link only used the
GUI to generate the python.  This method was specifically what I was
trying to avoid.

So it sounds like grcc can't do what I was looking for if it requires
X11.

Regards

On 2017-08-29 9:11 PM, Cinaed Simson wrote:

On 08/29/2017 08:32 PM, Mike Rex wrote:

That looks like its exactly what I am looking for.  Probably good to
mention in the gnuradio wiki "Developing GNU Radio" section.  Note to
self...

Thanks!

Regards,
Mike

If you're running on a DSP device, you might not want X11 to try and
startup.

If which case, it's best to use grc to dump the python script using the
"no gui" option.

See


https://lists.gnu.org/archive/html/discuss-gnuradio/2016-07/msg00377.html


for details.

-- Cinaed



On 2017-08-29 7:56 PM, Kyeong Su Shin wrote:

Are you looking for 'grcc'?

Regards,
Kyeong Su Shin


___
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 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] Command line compile GRC xml

[Mike Rex]

Marcus,

Thank you for the reply. There was a miscommunication with my colleague. 
  He got a /different /error with grcc and not gtk related.  He ran the 
gnuradio-companion and received an error related to GTK then seg 
faulted.  That makes sense now that I know he ran the companion and not 
grcc.


So when I ran grcc on the embedded box, it gave:

Traceback (most recent call last):
  File "/usr/bin/grcc", line 32, in 
    from gnuradio.grc.python.Platform import Platform
ImportError: No module named python.Platform

Whereas this command ran on my xubuntu PC just fine.  So this looks like 
a problem with the embedded box's python install.  It's running a ppc 
CPU and we didn't make the image its running.  So we'll need to track 
this down and fix.


Thank you for confirming X11 isn't needed or else my colleague and I 
wouldn't have caught this.  I'll look into this python.Platform issue 
and report back if grcc doesn't run successfully like it did on my test 
linux PC.


Thanks,
Mike


On 2017-08-30 6:18 PM, Marcus Müller wrote:

Dear Mike,

in theory, GRCC really shouldn't need X11 at all. Can you elaborate on
what problems you're encountering?

Cheers,

Marcus


On 30.08.2017 23:04, Mike Rex wrote:

Not sure if you posted the url you intended, that link only used the
GUI to generate the python.  This method was specifically what I was
trying to avoid.

So it sounds like grcc can't do what I was looking for if it requires
X11.

Regards

On 2017-08-29 9:11 PM, Cinaed Simson wrote:

On 08/29/2017 08:32 PM, Mike Rex wrote:

That looks like its exactly what I am looking for.  Probably good to
mention in the gnuradio wiki "Developing GNU Radio" section.  Note to
self...

Thanks!

Regards,
Mike

If you're running on a DSP device, you might not want X11 to try and
startup.

If which case, it's best to use grc to dump the python script using the
"no gui" option.

See


https://lists.gnu.org/archive/html/discuss-gnuradio/2016-07/msg00377.html


for details.

-- Cinaed



On 2017-08-29 7:56 PM, Kyeong Su Shin wrote:

Are you looking for 'grcc'?

Regards,
Kyeong Su Shin



___
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 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] Command line compile GRC xml

[Mike Rex]

Not sure if you posted the url you intended, that link only used the GUI 
to generate the python.  This method was specifically what I was trying 
to avoid.


So it sounds like grcc can't do what I was looking for if it requires X11.

Regards

On 2017-08-29 9:11 PM, Cinaed Simson wrote:

On 08/29/2017 08:32 PM, Mike Rex wrote:

That looks like its exactly what I am looking for.  Probably good to
mention in the gnuradio wiki "Developing GNU Radio" section.  Note to
self...

Thanks!

Regards,
Mike

If you're running on a DSP device, you might not want X11 to try and
startup.

If which case, it's best to use grc to dump the python script using the
"no gui" option.

See

https://lists.gnu.org/archive/html/discuss-gnuradio/2016-07/msg00377.html

for details.

-- Cinaed




On 2017-08-29 7:56 PM, Kyeong Su Shin wrote:

Are you looking for 'grcc'?

Regards,
Kyeong Su Shin




___
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] Command line compile GRC xml

[Mike Rex]

That looks like its exactly what I am looking for.  Probably good to 
mention in the gnuradio wiki "Developing GNU Radio" section.  Note to 
self...


Thanks!

Regards,
Mike


On 2017-08-29 7:56 PM, Kyeong Su Shin wrote:

Are you looking for 'grcc'?

Regards,
Kyeong Su Shin



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

[Discuss-gnuradio] Command line compile GRC xml

[Mike Rex]

I'm looking for a way to compile a GRC xml example into a python flow 
graph to be ran on a headless DSP device.  When I googled for the 
options,  I got this Ubuntu page 
(http://manpages.ubuntu.com/manpages/xenial/man1/gnuradio-companion.1.html) 
based on 3.7.9.1 that had the "--compile" option.  However, in 3.7.12, 
that option is not present:


$ gnuradio-companion -h
Usage: gnuradio-companion [options] [saved flow graphs]

Options:
  --version   show program's version number and exit
  -h, --help  show this help message and exit

$ gnuradio-companion --version
GNU Radio Companion 3.7.12git-218-g811bee8c

This program is part of GNU Radio
GRC comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it.

Is there a way to compile GRC files from the command line in 3.7.12?

Thanks in advance!


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

Re: [Discuss-gnuradio] Scanoo_rx: New GUI, Center Freq Hopping & SSB Modulation

[Mike Jameson]

Lou,

Apologies for the late reply.

> Mike, thanks for the detailed explanation.  Is there a reason for doing
the
> channel selection via FFT/IFFT method as opposed to a frequency xlating
> filter?  Maybe it's more efficient since you needed to do the FFT anyway
for
> the spectrum sense.

I utilised the FFT/IFFT method throughout because the maximum signal was
being identified and passed on as a single FFT bin number which is then set
as the central bin number for the 'Keep M in N' block.  In this 'Keep M in
N' block, the FFT bins to the right and left are used to make up the
correct channel bandwidth so that the wanted sampling rate is obtained when
the IFFT takes place to convert the FFT frequency domain vector stream to
the time domain.

> I see the frequency selection with the mouse is a feature of the WX FFT
sink
> (Freq Set Varname).  I wonder if the same functionality is in the QT sink.

It looks as though in GNU Radio 3.7.11.1 the feature to set a GRC variable
with the 'click to tune' function is broken in both the 'WX FFT GUI sink'
and the 'QT FFT GUI sink' blocks.  Fortunately, the 'QT FFT GUI sink' block
has a message output which sends a message when a new frequency is clicked
on.  To utilise this message, I've created a 'message_to_variable' block
which receives a message from the 'QT FFT GUI sink' block containing the
new frequency information and then the center_freq GRC variable is updated
by an associated 'function probe' block.

> Anyway, yours is a good example to wrap my head around how the Probe
Signals
> work.  Looks like it may be a better method than the message queues I was
> experimenting with.  I was using a queue to grab the FFT data and compute
> the max value.

I hope you have been successful with your message queue experiments.  A
Scanoo QT version is in progress which will utilise message sending
functionality.  One essential on the list is to add a message output to the
QT push button so that when clicked, I can use the message to trigger
something.

Regards,

Mike


On Sun, Jun 15, 2014 at 1:06 AM, madengr <rfe...@everestkc.net> wrote:

> Mike, thanks for the detailed explanation.  Is there a reason for doing the
> channel selection via FFT/IFFT method as opposed to a frequency xlating
> filter?  Maybe it's more efficient since you needed to do the FFT anyway
> for
> the spectrum sense.
>
> I see the frequency selection with the mouse is a feature of the WX FFT
> sink
> (Freq Set Varname).  I wonder if the same functionality is in the QT sink.
>
> Anyway, yours is a good example to wrap my head around how the Probe
> Signals
> work.  Looks like it may be a better method than the message queues I was
> experimenting with.  I was using a queue to grab the FFT data and compute
> the max value.
>
> Thanks,
> Lou
> KD4HSO
>
>
> Mike Jameson-2 wrote
> > Lou, thanks for your interest.  Yes the entire thing was made purely with
> > GRC and there was no modification to the generated Python.  All that is
> > required to run the scanoo_rx GRC file unmodified is a UHD compatible
> > device and an installation done with "./pybombs install uhd gnuradio".
> > Johnathan's GNURadio Live DVD should work too -
> > http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioLiveDVD .
>
>
>
>
>
> --
> View this message in context: http://gnuradio.4.n7.nabble.
> com/Scanoo-rx-New-GUI-Center-Freq-Hopping-SSB-Modulation-
> tp48866p48924.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
> ___
> 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] Block position with different screen resolutions

[Mike Thebo]

Hi Sebastian,

I am not quite sure, what you mean by "running GRC from source". Do you
mean build it from source? I am using pybombs and I think this is
cloning the master branch. To test this, I would need the maint branch,
correct? Or is it already merged into the master branch?

Best regards,
Mike

Am 27.10.2016 um 23:30 schrieb Sebastian Koslowski:
> Its not rejected permanently, it was just merged it prematurely. Since GitHub 
> won't let you reopen a PR I had to issue a new one
> 
> There should be link at the bottom.
> 
> To test this you can run GRC from source, no build no install.
> Yo disable scaling you have to set your display to the native resolution
> 
> Sebastian
> ⁣
> 
> Sent from BlueMail
> 
> ​
> 
> On Oct 27, 2016, 11:13, at 11:13, Mike Thebo <mailingli...@in-box.at> wrote:
>> Hi Sebastian,
>>
>> indeed it sounded like it could help. Unfortunately I didn't get to try
>> it, as it has been rejected.
>>
>> Is there another way to disable scaling. I wouldn't mind if the
>> distances stayed static. If I switch to the notebook screen I would
>> have
>> to scroll, but this would be ok if I get usability for that.
>>
>> Best regards,
>> Mike
>>
>> Am 25.10.2016 um 11:53 schrieb Koslowski, Sebastian (CEL):
>>> Sounds like this could help:
>> https://github.com/gnuradio/gnuradio/pull/1064
>>>
>>> Sebastian
>>>
>>> On 10/24/2016 10:30 PM, Mike Thebo wrote:
>>>> Hi all,
>>>>
>>>> is it somehow possible to preserve the relative block position to
>> each
>>>> other over several screen resolutions?
>>>>
>>>> I attached 2 pictures, which show the problem. I work on a GRC
>> flowgraph
>>>> so I can see everything nice and easy to be able to change values
>> when I
>>>> am out in the field with the notebook.
>>>>
>>>> But when I open the flowgraph on my notebook screen all the blocks
>> are
>>>> squeezed. With larger flowgraphs it is even worse than the picture
>>>> shows. Out in the field, when you looking for a block to change
>>>> something, it is practically unusable. Sometimes they are even on
>> top of
>>>> each other, forming several layers.
>>>>
>>>> Of course, if I know the name, I could probably search for it. But
>> isn't
>>>> there a different solution?
>>>>
>>>> Best regards,
>>>> Mike
>>>>
>>>>
>>>> ___
>>>> 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] slicing up a 'file-sink' capture?

[Mike Walters]

The git version of inspectrum should do just what you want - you can select
a period of time with the cursors and export it by right-clicking the
spectrogram.

On 24 September 2016 at 20:44, Cinaed Simson 
wrote:

> Might want to look at inspectrum.
>
> The size of the FFT can be varied, it has zoom and an overlay for
> determining symbol timing and can handle large files.
>
> No editing features however.
>
> I don't anything about baudline.
>
> The version I'm running requires qt5.
>
> See
>
>   https://github.com/miek/inspectrum
>
> On 09/23/2016 04:02 PM, du...@duaneellis.com wrote:
> > Hi -
> >
> > I've setup a front end, and captured about 10 to 20 seconds worth of
> > data to a file sink (750M data file)
> >
> > The transmitted data is a small 8millisecond bursts, followed by a very
> > long delay.
> >
> > I would like to have some means to 'zoom in and slice out' a few bits of
> > data so I can do more work with it.
> >
> > I've tried baudline, while helpful - I can a very low level signal,
> > followed by a huge signal, and back to a low level signal.
> >
> > My question is:
> >
> > Can you suggest a tool that I can use to "slice out" - the sections
> > of interest?
> > The closest example I can think of is using "head/tail" - into baud
> > line ...
> > And manually move my start/stop sample number until I get what I
> > want.
> >
> > There's got to be a better way...
> >
> > for example I'd like to zoom in, select the region of interest then save
> > that region.
> >
> > Then - these new files as input data for some tests.
> >
> > 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] Problem with gnuradio-companion

[Mike Willis]

Oops - hit send before finishing.

So, eventually I discovered that there were some files in
/usr/lib/python2.7/dist-packages/gnuradio - not sure how they got
there but they were dated the same date I upgraded 14.04 to 16.04. I
moved them all to another place and that eliminated the error. But
these are not in the path so should not have been found - unless
python has a default path, but that would be stupid as it would cause
all sorts of issues, like this one.

But still, all my blocks are missing. How do I recompile my own block
so gnuradio running in a prefix that is not /usr/local can find it?
Presumably in a switch to cmake but there is nothing about this I can
find in the pybombs documentation.

Mike



On Wed, Aug 3, 2016 at 7:34 PM, Mike Willis <willis...@gmail.com> wrote:
> The file is there so its not that. Nor was the suggestion by Cinaed
> Simson successful. Gnuradio runs OK, but not gnuradio-companion. Hmm.
>
> mike@mjw-i7:~/gnuradio/lib/python2.7/dist-packages/gnuradio/grc$ ls -l
> total 52
> -rw-r--r-- 1 mike mike 2374 Aug  1 12:22 checks.py
> -rw-r--r-- 1 mike mike 2420 Aug  1 13:43 checks.pyc
> -rw-r--r-- 1 mike mike 2420 Aug  1 13:43 checks.pyo
> drwxrwxr-x 4 mike mike 4096 Aug  1 13:59 core
> drwxrwxr-x 2 mike mike 4096 Aug  1 13:59 gui
> -rw-r--r-- 1 mike mike0 Aug  1 12:22 __init__.py
> -rw-r--r-- 1 mike mike  135 Aug  1 13:43 __init__.pyc
> -rw-r--r-- 1 mike mike  135 Aug  1 13:43 __init__.pyo
> -rw-r--r-- 1 mike mike  834 Aug  1 12:22 __main__.py
> -rw-r--r-- 1 mike mike 1742 Aug  1 12:22 main.py
> -rw-r--r-- 1 mike mike  184 Aug  1 13:43 __main__.pyc
> -rw-r--r-- 1 mike mike 1331 Aug  1 13:43 main.pyc
> -rw-r--r-- 1 mike mike  184 Aug  1 13:43 __main__.pyo
> -rw-r--r-- 1 mike mike 1331 Aug  1 13:43 main.pyo
>
> The paths are set up in setup_env.sh
>
> # WARNING: This file is auto-generated by pybombs, any manual changes
> to it may be overwritten!
> export PATH="/home/mike/gnuradio/bin:$PATH"
> export 
> PYTHONPATH="/home/mike/gnuradio/python:/home/mike/gnuradio/lib/python2.6/site-packages:/home/mike/gnuradio/lib64/python2.6/site-packages:/home/mike/gnuradio/lib/python2.6/dist-packages:/home/mike/gnuradio/lib64/python2.6/dist-packages:/home/mike/gnuradio/lib/python2.7/site-packages:/home/mike/gnuradio/lib64/python2.7/site-packages:/home/mike/gnuradio/lib/python2.7/dist-packages:/home/mike/gnuradio/lib64/python2.7/dist-packages:$PYTHONPATH"
> export 
> LD_LIBRARY_PATH="/home/mike/gnuradio/lib:/home/mike/gnuradio/lib64/:$LD_LIBRARY_PATH"
> export 
> LIBRARY_PATH="/home/mike/gnuradio/lib:/home/mike/gnuradio/lib64/:$LIBRARY_PATH"
> export 
> PKG_CONFIG_PATH="/home/mike/gnuradio/lib/pkgconfig:/home/mike/gnuradio/lib64/pkgconfig:$PKG_CONFIG_PATH"
> export PYBOMBS_PREFIX="/home/mike/gnuradio"
> # If we're in a Python virtualenv, activate that
> if [ -r /home/mike/gnuradio/bin/activate ]; then
> source /home/mike/gnuradio/bin/activate

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

Re: [Discuss-gnuradio] Problem with gnuradio-companion

[Mike Willis]

The file is there so its not that. Nor was the suggestion by Cinaed
Simson successful. Gnuradio runs OK, but not gnuradio-companion. Hmm.

mike@mjw-i7:~/gnuradio/lib/python2.7/dist-packages/gnuradio/grc$ ls -l
total 52
-rw-r--r-- 1 mike mike 2374 Aug  1 12:22 checks.py
-rw-r--r-- 1 mike mike 2420 Aug  1 13:43 checks.pyc
-rw-r--r-- 1 mike mike 2420 Aug  1 13:43 checks.pyo
drwxrwxr-x 4 mike mike 4096 Aug  1 13:59 core
drwxrwxr-x 2 mike mike 4096 Aug  1 13:59 gui
-rw-r--r-- 1 mike mike0 Aug  1 12:22 __init__.py
-rw-r--r-- 1 mike mike  135 Aug  1 13:43 __init__.pyc
-rw-r--r-- 1 mike mike  135 Aug  1 13:43 __init__.pyo
-rw-r--r-- 1 mike mike  834 Aug  1 12:22 __main__.py
-rw-r--r-- 1 mike mike 1742 Aug  1 12:22 main.py
-rw-r--r-- 1 mike mike  184 Aug  1 13:43 __main__.pyc
-rw-r--r-- 1 mike mike 1331 Aug  1 13:43 main.pyc
-rw-r--r-- 1 mike mike  184 Aug  1 13:43 __main__.pyo
-rw-r--r-- 1 mike mike 1331 Aug  1 13:43 main.pyo

The paths are set up in setup_env.sh

# WARNING: This file is auto-generated by pybombs, any manual changes
to it may be overwritten!
export PATH="/home/mike/gnuradio/bin:$PATH"
export 
PYTHONPATH="/home/mike/gnuradio/python:/home/mike/gnuradio/lib/python2.6/site-packages:/home/mike/gnuradio/lib64/python2.6/site-packages:/home/mike/gnuradio/lib/python2.6/dist-packages:/home/mike/gnuradio/lib64/python2.6/dist-packages:/home/mike/gnuradio/lib/python2.7/site-packages:/home/mike/gnuradio/lib64/python2.7/site-packages:/home/mike/gnuradio/lib/python2.7/dist-packages:/home/mike/gnuradio/lib64/python2.7/dist-packages:$PYTHONPATH"
export 
LD_LIBRARY_PATH="/home/mike/gnuradio/lib:/home/mike/gnuradio/lib64/:$LD_LIBRARY_PATH"
export 
LIBRARY_PATH="/home/mike/gnuradio/lib:/home/mike/gnuradio/lib64/:$LIBRARY_PATH"
export 
PKG_CONFIG_PATH="/home/mike/gnuradio/lib/pkgconfig:/home/mike/gnuradio/lib64/pkgconfig:$PKG_CONFIG_PATH"
export PYBOMBS_PREFIX="/home/mike/gnuradio"
# If we're in a Python virtualenv, activate that
if [ -r /home/mike/gnuradio/bin/activate ]; then
source /home/mike/gnuradio/bin/activate

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

[Discuss-gnuradio] Excellent blog about SDR development...

[Mike Harpe]

Found this via a Xilinx Facebook posting. I don't know if this young man is
on this list but if you are I salute you. This is impressive. He uses GNU
Radio.

http://electronics.kitchen/misc/freesrp/

Your notes about the Xilinx tools made this old guy feel much better about
struggling to learn the tools. The notes about board design were also very
educational.

Mike Harpe, N4PLE
Sellersburg, IN
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Problem with gnuradio-companion

[Mike Willis]

I can't fix this one - 3 hours trying and I have given up. Ubuntu
16.04. gnuradio-companion isn't working. Everything else seems to be
fine, existing flowgraphs run OK, even gqrx. I have tried a complete
re-installation, right back to the pybombs prefix init stage but no
dice.

Any ideas?

mike@mjw-i7:~/.gnuradio$ gnuradio-companion
Traceback (most recent call last):
  File "/home/mike/gnuradio/bin/gnuradio-companion", line 29, in 
from gnuradio.grc.main import main
ImportError: No module named main

I have set the environment etc. All looks good except there is no
lib64 director in my prefix /home/mike/gnuradio

mike@mjw-i7:~/.gnuradio$ env |grep gnuradio
LIBRARY_PATH=/home/mike/gnuradio/lib:/home/mike/gnuradio/lib64/:/home/mike/gnuradio/lib:/home/mike/gnuradio/lib64/:/home/mike/gnuradio/lib:/home/mike/gnuradio/lib64/:/home/mike/gnuradio/lib:/home/mike/gnuradio/lib64/:/home/mike/gnuradio/lib:/home/mike/gnuradio/lib64/:/home/mike/gnuradio/lib:/home/mike/gnuradio/lib64/:
LD_LIBRARY_PATH=/home/mike/gnuradio/lib:/home/mike/gnuradio/lib64/:/home/mike/gnuradio/lib:/home/mike/gnuradio/lib64/:/home/mike/gnuradio/lib:/home/mike/gnuradio/lib64/:/home/mike/gnuradio/lib:/home/mike/gnuradio/lib64/:/home/mike/gnuradio/lib:/home/mike/gnuradio/lib64/:/home/mike/gnuradio/lib:/home/mike/gnuradio/lib64/:
PYBOMBS_PREFIX=/home/mike/gnuradio
PATH=/home/mike/gnuradio/bin:/home/mike/gnuradio/bin:/home/mike/gnuradio/bin:/home/mike/gnuradio/bin:/home/mike/gnuradio/bin:/home/mike/gnuradio/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
PWD=/home/mike/gnuradio
PYTHONPATH=/home/mike/gnuradio/python:/home/mike/gnuradio/lib/python2.6/site-packages:/home/mike/gnuradio/lib64/python2.6/site-packages:/home/mike/gnuradio/lib/python2.6/dist-packages:/home/mike/gnuradio/lib64/python2.6/dist-packages:/home/mike/gnuradio/lib/python2.7/site-packages:/home/mike/gnuradio/lib64/python2.7/site-packages:/home/mike/gnuradio/lib/python2.7/dist-packages:/home/mike/gnuradio/lib64/python2.7/dist-packages:
PKG_CONFIG_PATH=/home/mike/gnuradio/lib/pkgconfig:/home/mike/gnuradio/lib64/pkgconfig:/home/mike/gnuradio/lib/pkgconfig:/home/mike/gnuradio/lib64/pkgconfig:/home/mike/gnuradio/lib/pkgconfig:/home/mike/gnuradio/lib64/pkgconfig:/home/mike/gnuradio/lib/pkgconfig:/home/mike/gnuradio/lib64/pkgconfig:/home/mike/gnuradio/lib/pkgconfig:/home/mike/gnuradio/lib64/pkgconfig:/home/mike/gnuradio/lib/pkgconfig:/home/mike/gnuradio/lib64/pkgconfig:

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

[Discuss-gnuradio] Fwd: Re: Sigh - 16.04 build failure

[Mike]

Found it ! I discovered a duplicate set of headers in /usr/local/include 
and /usr/include, fixing this didn't fix the problem.


After several hours wondering what was wrong with the headers I found 
there were two versions of libcppunit. This must have been a leftover of 
the upgrade to 16.04 as it should surely have been deleted when replaced 
by the updated version.


The older libcppunit-1.12 in /usr/lib/ and the newer, libcppunit-1.13 
was in /usr/lib/x86_64-linux-gnu/ - why in different directory I have no 
idea.


So the right headers were there but the wrong library was being selected 
which is why it failed to build.


I deleted the older version and build progressed.

So what else has the version upgrade left lurking?

Mike





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

[Discuss-gnuradio] Sigh - 16.04 build failure

[Mike Willis]

Why is it always so difficult? Assume something broken in latest Ubuntu LTS

 pybombs -vv install gnuradio > error.txt
[ 62%] Built target pygen_volk_python_volk_modtool_fe055
[ 62%] Built target pmt_generated
[ 62%] Built target pygen_volk_python_volk_modtool_00079
[ 62%] Built target volk_obj
[ 62%] Built target pmt_swig_swig_doc
[ 62%] Built target pygen_gnuradio_runtime_python_gnuradio_82609
[ 62%] Built target runtime_swig_swig_doc
[ 62%] Built target pygen_gnuradio_runtime_python_gnuradio_gru_4cc16
[ 62%] Built target pygen_gnuradio_runtime_python_gnuradio_gr_726d4
[ 62%] Built target pygen_gnuradio_runtime_python_gnuradio_ctrlport_13b5b
[ 62%] Built target pygen_gnuradio_runtime_python_gnuradio_ctrlport_880f6
[ 62%] Built target pygen_gnuradio_runtime_python_gnuradio_ctrlport_4bc9d
[ 62%] Built target pygen_gnuradio_runtime_python_gnuradio_ctrlport_c14dc
[ 62%] Built target pygen_gnuradio_runtime_python_pmt_e34e7
[ 62%] Built target pygen_gnuradio_runtime_examples_mp_sched_57e1a
[ 62%] Built target pygen_gnuradio_runtime_examples_network_04f99
[ 62%] Built target pygen_gnuradio_runtime_examples_volk_benchmark_4316c
[ 62%] Built target blocks_generated_includes
[ 62%] Built target pygen_gr_blocks_python_grc_gnuradio_4f444
[ 62%] Built target pygen_gr_blocks_python_blocks_2317e
[ 62%] Built target pygen_gr_blocks_python_grc_gnuradio_f707b
[ 62%] Built target blocks_swig4_swig_doc
[ 62%] Built target blocks_swig5_swig_doc
[ 62%] Built target blocks_swig0_swig_doc
[ 62%] Built target blocks_swig1_swig_doc
[ 62%] Built target pygen_gr_blocks_swig_2c1e2
[ 62%] Built target blocks_swig3_swig_doc
[ 62%] Built target blocks_swig2_swig_doc
[ 62%] Built target pygen_gr_blocks_examples_tags_dc9ed
[ 62%] Built target pygen_gr_blocks_examples_ctrlport_3159a
[ 62%] Built target pygen_grc_d5c0c
[ 62%] Built target grc_generated_xml
[ 62%] Built target pygen_grc_gui_5a942
[ 62%] Built target pygen_grc_core_5d121
[ 62%] Built target pygen_grc_core_utils_714e7
[ 62%] Built target pygen_grc_scripts_16907
[ 62%] Built target pygen_grc_core_generator_43362
[ 62%] Built target gr_fec_rstest
[ 62%] Built target fec_swig_swig_doc
[ 62%] Built target pygen_gr_fec_python_fec_d0928
[ 62%] Built target pygen_gr_fec_python_fec_polar_1e75b
[ 62%] Built target pygen_gr_fec_python_fec_polar_ab18f
[ 62%] Built target pygen_gr_fec_python_fec_LDPC_ee28a
[ 62%] Built target fft_swig_swig_doc
[ 62%] Built target pygen_gr_fft_python_fft_222a1
[ 62%] Built target filter_generated_includes
[ 62%] Built target filter_swig_swig_doc
[ 62%] Built target pygen_gr_filter_python_filter_06ef7
[ 62%] Built target pygen_gr_filter_python_filter_design_9426a
[ 62%] Built target pygen_gr_filter_python_filter_gui_ab309
[ 62%] Built target pygen_gr_filter_apps_8fdce
[ 62%] Built target analog_generated_includes
[ 62%] Built target pygen_gr_filter_examples_06d4c
[ 62%] Built target pygen_gr_analog_python_analog_64942
[ 62%] Built target analog_swig_swig_doc
[ 62%] Built target pygen_gr_analog_examples_tags_46d57
[ 62%] Built target pygen_gr_analog_examples_e7c66
[ 62%] Built target digital_generated_includes
[ 62%] Built target digital_swig_swig_doc
[ 62%] Built target pygen_gr_digital_python_digital_34885
[ 62%] Built target pygen_gr_digital_python_digital_02a69
[ 62%] Built target pygen_gr_digital_python_grc_gnuradio_00653
[ 62%] Built target pygen_gr_digital_examples_1fa1f
[ 62%] Built target pygen_gr_digital_examples_d75aa
[ 62%] Built target pygen_gr_digital_examples_d8b60
[ 62%] Built target atsc_viterbi_gen
[ 62%] Built target dtv_swig_swig_doc
[ 62%] Built target pygen_gr_dtv_python_dtv_9cbe9
[ 62%] Built target pygen_gr_dtv_examples_471af
[ 62%] Built target pygen_gr_dtv_apps_588ab
[ 62%] Built target atsci_viterbi_gen
[ 62%] Built target pygen_gr_atsc_python_atsc_db624
[ 62%] Built target atsc_swig_swig_doc
[ 62%] Built target pygen_gr_atsc_python_atsc_31acc
[ 62%] Built target audio_swig_swig_doc
[ 62%] Built target pygen_gr_audio_python_audio_4f656
[ 62%] Built target pygen_gr_audio_examples_python_0ce1b
[ 62%] Built target channels_swig_swig_doc
[ 62%] Built target pygen_gr_channels_python_channels_e43cd
[ 62%] Built target noaa_swig_swig_doc
[ 62%] Built target pygen_gr_noaa_python_noaa_44430
[ 62%] Built target pygen_gr_pager_python_pager_99a2b
[ 62%] Built target pager_swig_swig_doc
[ 62%] Built target pygen_gr_pager_apps_43bb5
[ 62%] Built target qtgui_swig_swig_doc
[ 62%] Built target pygen_gr_qtgui_python_qtgui_c3482
[ 62%] Built target pygen_gr_qtgui_examples_57500
[ 62%] Built target pygen_gr_qtgui_apps_a4268
[ 62%] Built target pygen_gr_qtgui_apps_499a1
[ 62%] Built target trellis_generated_includes
[ 62%] Built target gr_trellis_xml
[ 62%] Built target trellis_swig_swig_doc
[ 62%] Built target pygen_gr_trellis_python_trellis_dc06a
[ 62%] Built target pygen_gr_trellis_examples_python_54b6b
[ 62%] Built target uhd_swig_swig_doc
[ 62%] Built target uhd_grc_xml_blocks
[ 62%] Built target pygen_gr_uhd_python_uhd_56ae0
[ 62%] Built 

[Discuss-gnuradio] Pybombs hates anaconda

[Mike Markowski]

Just curious why I can't use pybombs on an anaconda 
(https://www.continuum.io/) tree?


Since our lab is not on the internet, anaconda is a great python 
solution.  Pybombs-2.0.1 installs fine in the regular /usr/bin/python 
tree on ubuntu 15.10 boxes but not under anaconda, where it complains 
that it can't find cheetah even though cheetah v2.4.4 is in /usr/bin/.


Definitely not end of the world since is easy enough to not use anaconda 
tree, but we also have other things like gpib control, etc., that would 
be nice to not install twice.


Thanks!
Mike Markowski

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

Re: [Discuss-gnuradio] Build problems with pybombs

[Mike Willis]

Sorry - wrong one - the similar thread was from April last year

http://lists.gnu.org/archive/html/discuss-gnuradio/2015-04/msg00151.html

On Sun, Mar 6, 2016 at 2:53 PM, Mike <willis...@gmail.com> wrote:
> Here is the rather similar error I referred to earlier, not the same but
> similar characteristics

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

Re: [Discuss-gnuradio] Build problems with pybombs

[Mike]

Here is the rather similar error I referred to earlier, not the same but 
similar characteristics


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

[Discuss-gnuradio] Fwd: Pybombs 2.0 woes

[Mike Willis]

Here is the error

[  4%] Building CXX object
lib/CMakeFiles/uhd.dir/usrp/cores/rx_dsp_core_200.cpp.o
In file included from
/usr/local/src/uhd/host/lib/usrp/cores/dsp_core_utils.hpp:21:0,
 from
/usr/local/src/uhd/host/lib/usrp/cores/rx_dsp_core_200.cpp:19:
/usr/local/src/uhd/host/include/uhd/types/stdint.hpp:29:14: error:
‘int64_t’ is already declared in this scope
 using boost::int64_t;
  ^
/usr/local/src/uhd/host/include/uhd/types/stdint.hpp:51:9: error:
‘::uintptr_t’ has not been declared
 using ::uintptr_t;
 ^
make[2]: *** [lib/CMakeFiles/uhd.dir/usrp/cores/rx_dsp_core_200.cpp.o] Error 1
make[1]: *** [lib/CMakeFiles/uhd.dir/all] Error 2
make: *** [all] Error 2
PyBombs.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 - ERROR - Error installing package uhd. Aborting.
mike@mjw-toshiba:~/pybombs$

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

[Discuss-gnuradio] Pybombs 2.0 woes

[Mike Willis]

I just wasted an hour or so trying to get this to work. Clearly it is still
early beta but with promise. The first time I tried I got as far as the UHD
install, which crashed with an uninformative error 2. I think there is some
implicit assumption going on in the developers head that non developers
might understand what is going on, or know how to find out what that is.
Following advice here I descended down a rabbit hole and tried to start
again "pip uninstall pybombs". Pip was not found. Pip and by the way, its
actually called "python-pip" if you can't find it, can be installed from
apt-get install python-pip. After uninstalling pybombs with pip I tried to
re-install with pip and now I get almost nowhere as "pip list" generates an
error. So I have uninstalled pip and all is well again. 

 

That has fixed the pip problem but not the UHD installation crash, but as a
by product the error messages have become more verbose - and guess what? The
problem is an undeclared type. THIS SAME ISSUE WITH UNDEFINED TYPES (shout
so it sinks in, then repeat because it didn't) THIS SAME ISSUE WITH
UNDEFINED TYPES  that has been around for over a YEAR in UHD and in this
case rx_dsp_core_200.cpp. Every so often I point it out and someone fixes it
and later on someone else (I wonder if this is the same person who broke it
last time) then adds some new code somewhere else recreating the same
errors. In this case its uintptr_t that is not declared. A good motto is to
assume nothing and please make sure you declare everything.

 

Mike

 

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

Re: [Discuss-gnuradio] SSB/CW/FM tranceiver

[Mike Willis]

Thanks all - Ron that was just what I was looking for - and to Markus, you
don't make a transmitter because you want one, you do it because you can.
Not having antennas is hardly a handicap. You can still build a system with
lots of power to warm a dummy load, because it's fun to do that.

 

Mike

 

 

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

[Discuss-gnuradio] SSB/CW/FM tranceiver

[Mike Willis]

GQRX works very well but is there or might there be any plans to
develop a comprehensive tranceiver based on gnuradio?

SDRs like the hackRF and the Ettus USRPs provide great building blocks
for a VHF/UHF amateur radio station, with only filtering and
amplification needed to cover all bands from 4m to 6cm, yet I see
little work on such things, which is odd. Maybe there is no interest
but there might be.

Mike

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

[Discuss-gnuradio] GNU Radio Companion error: segmentation fault (core dumped)

[Mike Gilmer]

I am trying to follow the steps for the tutorials for GNU radio - at
one point I'm instructed to install/build/run the "Companion"

http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorial_GRC

 All's fine, until:

$ gnuradio-companion


I get thrown the error: Segmentation fault (core dumped)

Any ideas?

-Mike

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

Re: [Discuss-gnuradio] GNU Radio installation script

[Mike Gilmer]

Guys,

The RAM came a day late (thanks USPS) and I installed it and ran the
script again Thursday and it finished this time with no errors. Now I
have to see if I actually ended up with a usable "GNU Radio"
installation.

Thanks for the help!

Mike

On Wed, Sep 23, 2015 at 9:58 AM, Mike Gilmer <mike.gil...@gmail.com> wrote:
> LOL... good thing I already ordered some and am getting RAM in the mail today!
>
> Mike
>
> On Wed, Sep 23, 2015 at 9:53 AM, Marcus Müller <marcus.muel...@ettus.com> 
> wrote:
>> "Killed" in almost all cases means "killed by the out-of-memory watchdog of
>> your operating system". You'll still need more RAM, need to reduce the
>> number of parallel compilation threads or at least swap storage to
>> successfully compile GNU radio. I recommend getting more RAM - that is
>> always a good thing to have, especially if planning to do some buffer
>> intense signal processing.
>>
>> Best regards,
>> Marcus
>>
>> Am 23. September 2015 15:48:37 MESZ, schrieb Mike Gilmer
>> <mike.gil...@gmail.com>:
>>>
>>> I worked my way up though the email chain and ran some of the
>>> "updates" suggested and reran the script
>>>
>>> It has gotten further along than before, but still fails...
>>>
>>>  Scanning dependencies of target volk_profile
>>>  [  5%]  [32mBuilding CXX object
>>> volk/apps/CMakeFiles/volk_profile.dir/volk_profile.cc.o
>>>  mc++: internal compiler error: Killed (program cc1plus)
>>> Please submit a full bug report,
>>> with preprocessed source if appropriate.
>>> See  for instructions.
>>> make[2]: *** [volk/apps/CMakeFiles/volk_profile.dir/volk_profile.cc.o]
>>> Error 4
>>> make[1]: *** [volk/apps/CMakeFiles/volk_profile.dir/all] Error 2
>>> make: *** [all] Error 2
>>> make failed
>>> Exiting Gnu Radio build/install
>>>
>>> The complete output is at http://pastebin.com/jpA005nP  <--
>>> sorry
>>> about the control chars- next time maybe!
>>>
>>> Mike
>>>
>>> 
>>>
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

Re: [Discuss-gnuradio] GNU Radio installation script

[Mike Gilmer]

I worked my way up though the email chain and ran some of the
"updates" suggested and reran the script

It has gotten further along than before, but still fails...

Scanning dependencies of target volk_profile
[  5%] Building CXX object
volk/apps/CMakeFiles/volk_profile.dir/volk_profile.cc.o
mc++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[2]: *** [volk/apps/CMakeFiles/volk_profile.dir/volk_profile.cc.o] Error 4
make[1]: *** [volk/apps/CMakeFiles/volk_profile.dir/all] Error 2
make: *** [all] Error 2
make failed
Exiting Gnu Radio build/install

The complete output is at http://pastebin.com/jpA005nP  <-- sorry
about the control chars- next time maybe!

Mike

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

Re: [Discuss-gnuradio] GNU Radio installation script

[Mike Gilmer]

LOL... good thing I already ordered some and am getting RAM in the mail today!

Mike

On Wed, Sep 23, 2015 at 9:53 AM, Marcus Müller <marcus.muel...@ettus.com> wrote:
> "Killed" in almost all cases means "killed by the out-of-memory watchdog of
> your operating system". You'll still need more RAM, need to reduce the
> number of parallel compilation threads or at least swap storage to
> successfully compile GNU radio. I recommend getting more RAM - that is
> always a good thing to have, especially if planning to do some buffer
> intense signal processing.
>
> Best regards,
> Marcus
>
> Am 23. September 2015 15:48:37 MESZ, schrieb Mike Gilmer
> <mike.gil...@gmail.com>:
>>
>> I worked my way up though the email chain and ran some of the
>> "updates" suggested and reran the script
>>
>> It has gotten further along than before, but still fails...
>>
>>  Scanning dependencies of target volk_profile
>>  [  5%]  [32mBuilding CXX object
>> volk/apps/CMakeFiles/volk_profile.dir/volk_profile.cc.o
>>  mc++: internal compiler error: Killed (program cc1plus)
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> See  for instructions.
>> make[2]: *** [volk/apps/CMakeFiles/volk_profile.dir/volk_profile.cc.o]
>> Error 4
>> make[1]: *** [volk/apps/CMakeFiles/volk_profile.dir/all] Error 2
>> make: *** [all] Error 2
>> make failed
>> Exiting Gnu Radio build/install
>>
>> The complete output is at http://pastebin.com/jpA005nP  <--
>> sorry
>> about the control chars- next time maybe!
>>
>> Mike
>>
>> 
>>
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

Re: [Discuss-gnuradio] GNU Radio installation script

[Mike Gilmer]

I ran the mako template as suggested and the output indicated it was
already up-to-date.

I'm still looking back through this chain since it seem there are a lot of
options

Mike
On Sep 22, 2015 11:35 AM, "Peter Mathys" <mat...@colorado.edu> wrote:

> As noted elsewhere the failure to find libzmq1-dev is expected (what is
> needed is libzmq-dev) and does not affect the outcome of the installation.
> However, the UHD installation most likely fails because of the switch from
> the cheetah to the mako template engine which has not (yet?) made its way
> into the build-gnuradio script. Install the mako template engine using
>
> sudo apt-get install python-mako
>
> Then run the build-gnuradio script again (perhaps with the -v option).
>
> -Peter-
>
>
> On 9/22/2015 6:25 AM, Mike Gilmer wrote:
>
>> I've gotten further along but it still failed.  Here's the output
>>
>> +++
>> Failed to find package 'libzmq1-dev' in known package repositories
>> <-- I noted this in my previous post
>> SOME THINGS MAY NOT BUILD AS A RESULT
>> Checking for package libzmq
>> Checking for package libzmq-dev
>> Checking for package python-requests
>> Done checking packages
>> Checking for library libusb ...Found library libusb
>> Checking for library libboost ...Found library libboost
>> Checking for library libcppunit ...Found library libcppunit
>> Checking for library libfftw ...Found library libfftw
>> Checking for library libgsl ...Found library libgsl
>> Done
>> This script will fetch Gnu Radio version 3.7/maint from the
>> repositories, along with compatible
>> extras.
>> Is this OK?y
>> Fetching various packages (Gnu Radio, UHD, gr-osmosdr, gr-iqbal, etc)
>> via the Internet
>> ===> THIS MAY TAKE QUITE SOME TIME <=
>> Fetching Gnu Radio via GIT...Done
>> Fetching UHD via GIT...Fetching rtl-sdr (rtl-sdr, gr-osmosdr,
>> gr-iqbal, hackrf, bladeRF and airspy) via GIT
>> Done
>> Starting function uhd_build at: Tue Sep 22 00:10:59 EDT 2015
>> Building UHD...
>> => THIS WILL TAKE SOME TIME <=
>>
>> UHD build apparently failed
>> Exiting UHD build
>> ++
>>
>> Again, I appreciate the help!
>>
>> -Mike
>>
>> On Mon, Sep 21, 2015 at 11:48 PM, Mike Gilmer <mike.gil...@gmail.com>
>> wrote:
>>
>>> I'm running 14.04 and yes I have Internet access (that was part of the
>>> aforementioned "drama")
>>>
>>> I ran the update/upgrade and reran the script and now things are
>>> "different"
>>>
>>> This seems like it may take a while. I'll report back when it's done.
>>>
>>> Hmm.. so far one error - it couldn't find libzmq1-dev; I don't know
>>> what that'll mean
>>>
>>> Thanks!
>>>
>>> Mike
>>>
>>>
>>>
>>> On Mon, Sep 21, 2015 at 11:27 PM, James Humphries
>>> <james.humphr...@ettus.com> wrote:
>>>
>>>> Hi Mike,
>>>>
>>>> Did you update your package manager? Usually helps when I get errors.
>>>>
>>>> sudo apt-get update && sudo apt-get upgrade
>>>>
>>>> Also, make sure build-essential is installed (Do this after update and
>>>> upgrade).
>>>>
>>>> sudo apt-get install build-essential
>>>>
>>>> -Trip
>>>>
>>>> On Mon, Sep 21, 2015 at 11:13 PM, Mike Gilmer <mike.gil...@gmail.com>
>>>> wrote:
>>>>
>>>>> All,
>>>>> I recently asked the list some questions about getting GNU Radio up
>>>>> and running on a Windows machine (using cygwin). It became obvious
>>>>> there would be a lot of hurdles, for which the community would not be
>>>>> able to offer much help. So...
>>>>>
>>>>> I have installed Ubuntu on a PC ( in a dual boot configuration with
>>>>> Win7 ) <-- this is its own drama LOL
>>>>>
>>>>> I tried to follow the "Installing GNU Radio step(s) outlined on
>>>>> https://gnuradio.org/redmine/projects/gnuradio/wiki/InstallingGR/23
>>>>> using the script via
>>>>> wget http://www.sbrac.org/files/build-gnuradio && chmod a+x
>>>>> ./build-gnuradio && ./build-gnuradio
>>>>>
>>>>> and I get a bunch of errors :
>>>>> Checking for package libfontco

Re: [Discuss-gnuradio] GNU Radio installation script

[Mike Gilmer]

I've gotten further along but it still failed.  Here's the output

+++
Failed to find package 'libzmq1-dev' in known package repositories
<-- I noted this in my previous post
SOME THINGS MAY NOT BUILD AS A RESULT
Checking for package libzmq
Checking for package libzmq-dev
Checking for package python-requests
Done checking packages
Checking for library libusb ...Found library libusb
Checking for library libboost ...Found library libboost
Checking for library libcppunit ...Found library libcppunit
Checking for library libfftw ...Found library libfftw
Checking for library libgsl ...Found library libgsl
Done
This script will fetch Gnu Radio version 3.7/maint from the
repositories, along with compatible
extras.
Is this OK?y
Fetching various packages (Gnu Radio, UHD, gr-osmosdr, gr-iqbal, etc)
via the Internet
===> THIS MAY TAKE QUITE SOME TIME <=
Fetching Gnu Radio via GIT...Done
Fetching UHD via GIT...Fetching rtl-sdr (rtl-sdr, gr-osmosdr,
gr-iqbal, hackrf, bladeRF and airspy) via GIT
Done
Starting function uhd_build at: Tue Sep 22 00:10:59 EDT 2015
Building UHD...
=> THIS WILL TAKE SOME TIME <=

UHD build apparently failed
Exiting UHD build
++

Again, I appreciate the help!

-Mike

On Mon, Sep 21, 2015 at 11:48 PM, Mike Gilmer <mike.gil...@gmail.com> wrote:
> I'm running 14.04 and yes I have Internet access (that was part of the
> aforementioned "drama")
>
> I ran the update/upgrade and reran the script and now things are "different"
>
> This seems like it may take a while. I'll report back when it's done.
>
> Hmm.. so far one error - it couldn't find libzmq1-dev; I don't know
> what that'll mean
>
> Thanks!
>
> Mike
>
>
>
> On Mon, Sep 21, 2015 at 11:27 PM, James Humphries
> <james.humphr...@ettus.com> wrote:
>> Hi Mike,
>>
>> Did you update your package manager? Usually helps when I get errors.
>>
>> sudo apt-get update && sudo apt-get upgrade
>>
>> Also, make sure build-essential is installed (Do this after update and
>> upgrade).
>>
>> sudo apt-get install build-essential
>>
>> -Trip
>>
>> On Mon, Sep 21, 2015 at 11:13 PM, Mike Gilmer <mike.gil...@gmail.com> wrote:
>>>
>>> All,
>>> I recently asked the list some questions about getting GNU Radio up
>>> and running on a Windows machine (using cygwin). It became obvious
>>> there would be a lot of hurdles, for which the community would not be
>>> able to offer much help. So...
>>>
>>> I have installed Ubuntu on a PC ( in a dual boot configuration with
>>> Win7 ) <-- this is its own drama LOL
>>>
>>> I tried to follow the "Installing GNU Radio step(s) outlined on
>>> https://gnuradio.org/redmine/projects/gnuradio/wiki/InstallingGR/23
>>> using the script via
>>> wget http://www.sbrac.org/files/build-gnuradio && chmod a+x
>>> ./build-gnuradio && ./build-gnuradio
>>>
>>> and I get a bunch of errors :
>>> Checking for package libfontconfig1-dev
>>> Failed to find package 'libfontconfig1-dev' in known package repositories
>>> SOME THINGS MAY NOT BUILD AS A RESULT
>>> Checking for package libxrender-dev
>>> Failed to find package 'libxrender-dev' in known package repositories
>>> SOME THINGS MAY NOT BUILD AS A RESULT However, the descruiption
>>>
>>> etc..
>>>
>>> It appears that a major step is missing or broken.  Can someone help me on
>>> this?
>>>
>>> Thanks!
>>>
>>> Mike
>>>
>>> ___
>>> 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 installation script

[Mike Gilmer]

I'm running 14.04 and yes I have Internet access (that was part of the
aforementioned "drama")

I ran the update/upgrade and reran the script and now things are "different"

This seems like it may take a while. I'll report back when it's done.

Hmm.. so far one error - it couldn't find libzmq1-dev; I don't know
what that'll mean

Thanks!

Mike



On Mon, Sep 21, 2015 at 11:27 PM, James Humphries
<james.humphr...@ettus.com> wrote:
> Hi Mike,
>
> Did you update your package manager? Usually helps when I get errors.
>
> sudo apt-get update && sudo apt-get upgrade
>
> Also, make sure build-essential is installed (Do this after update and
> upgrade).
>
> sudo apt-get install build-essential
>
> -Trip
>
> On Mon, Sep 21, 2015 at 11:13 PM, Mike Gilmer <mike.gil...@gmail.com> wrote:
>>
>> All,
>> I recently asked the list some questions about getting GNU Radio up
>> and running on a Windows machine (using cygwin). It became obvious
>> there would be a lot of hurdles, for which the community would not be
>> able to offer much help. So...
>>
>> I have installed Ubuntu on a PC ( in a dual boot configuration with
>> Win7 ) <-- this is its own drama LOL
>>
>> I tried to follow the "Installing GNU Radio step(s) outlined on
>> https://gnuradio.org/redmine/projects/gnuradio/wiki/InstallingGR/23
>> using the script via
>> wget http://www.sbrac.org/files/build-gnuradio && chmod a+x
>> ./build-gnuradio && ./build-gnuradio
>>
>> and I get a bunch of errors :
>> Checking for package libfontconfig1-dev
>> Failed to find package 'libfontconfig1-dev' in known package repositories
>> SOME THINGS MAY NOT BUILD AS A RESULT
>> Checking for package libxrender-dev
>> Failed to find package 'libxrender-dev' in known package repositories
>> SOME THINGS MAY NOT BUILD AS A RESULT However, the descruiption
>>
>> etc..
>>
>> It appears that a major step is missing or broken.  Can someone help me on
>> this?
>>
>> Thanks!
>>
>> Mike
>>
>> ___
>> 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] GNU Radio installation script

[Mike Gilmer]

All,
I recently asked the list some questions about getting GNU Radio up
and running on a Windows machine (using cygwin). It became obvious
there would be a lot of hurdles, for which the community would not be
able to offer much help. So...

I have installed Ubuntu on a PC ( in a dual boot configuration with
Win7 ) <-- this is its own drama LOL

I tried to follow the "Installing GNU Radio step(s) outlined on
https://gnuradio.org/redmine/projects/gnuradio/wiki/InstallingGR/23
using the script via
wget http://www.sbrac.org/files/build-gnuradio && chmod a+x
./build-gnuradio && ./build-gnuradio

and I get a bunch of errors :
Checking for package libfontconfig1-dev
Failed to find package 'libfontconfig1-dev' in known package repositories
SOME THINGS MAY NOT BUILD AS A RESULT
Checking for package libxrender-dev
Failed to find package 'libxrender-dev' in known package repositories
SOME THINGS MAY NOT BUILD AS A RESULT However, the descruiption

etc..

It appears that a major step is missing or broken.  Can someone help me on this?

Thanks!

Mike

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

[Discuss-gnuradio] pybombs installation fails

[Mike Gilmer]

Following the instriuctions on
http://gnuradio.org/redmine/projects/pybombs/wiki/QuickStart

I tried to run the installation:  ./pybombs install gnuradio

It appears to start up OK, but after "Loading recipes" it displays
"Installing packages" and gets through several dozen of them until it
displays * gnuradio.

At that point an Exception error is displayed:

"Exception RuntimeError: 'maximum recursion depth exceeded' in >
ignored"

and the installation fails.(many "failed to install gcc" errors are
outputted, followed by "failed to install make")

Can anyone help me through this step?

Thanks.
Mike

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

Re: [Discuss-gnuradio] pybombs installation fails

[Mike Gilmer]

Thanks guys.

The output (somewhat abbreviated) is at http://pastebin.com/BqvwB58y

I am running Windows 8.1

Mike

On Wed, Sep 16, 2015 at 3:52 PM, Tom Rondeau <t...@trondeau.com> wrote:
> On Wed, Sep 16, 2015 at 3:48 PM, Chris Kuethe <chris.kue...@gmail.com>
> wrote:
>>
>> capture the output from "./pybombs install -v -v -v gnuradio", and
>> stick it on pastebin so we can have a look at it.
>>
>> It looks like pybombs is trying to recompile make and gcc and goodness
>> knows what else... I'm curious about why it decided to do that.
>>
>> On Wed, Sep 16, 2015 at 9:25 AM, Mike Gilmer <mike.gil...@gmail.com>
>> wrote:
>> > Following the instriuctions on
>> > http://gnuradio.org/redmine/projects/pybombs/wiki/QuickStart
>> >
>> > I tried to run the installation:  ./pybombs install gnuradio
>> >
>> > It appears to start up OK, but after "Loading recipes" it displays
>> > "Installing packages" and gets through several dozen of them until it
>> > displays * gnuradio.
>> >
>> > At that point an Exception error is displayed:
>> >
>> > "Exception RuntimeError: 'maximum recursion depth exceeded' in > > method Popen.__del__ of >
>> > ignored"
>> >
>> > and the installation fails.(many "failed to install gcc" errors are
>> > outputted, followed by "failed to install make")
>> >
>> > Can anyone help me through this step?
>> >
>> > Thanks.
>> > Mike
>
>
>
> Also, what OS are you running? That might be important.
>
> Tom
>

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

Re: [Discuss-gnuradio] pybombs installation fails

[Mike Gilmer]

I'm new to this. ..are you asking me to run that install command. .. or?

Mike
On Sep 16, 2015 5:03 PM, "Chris Kuethe" <chris.kue...@gmail.com> wrote:

> This is what PyBOMBS does...
>
> https://github.com/gnuradio/pybombs/blob/0382f9253a44135677b656ef08ba438f57f65625/mod_pybombs/sysutils.py#L393
>
> https://github.com/gnuradio/pybombs/blob/dc593faf9e1557133c5801fe4aa58198e34407db/mod_pybombs/recipe.py
>
> if you could do something like "cygpkg install fftw gcc cmake", for
> example, then we could easily add the right logic.
>
> On Wed, Sep 16, 2015 at 1:49 PM, Mike Gilmer <mike.gil...@gmail.com>
> wrote:
> > I'm running a cygwin shell.
> >
> > Mike
> >
> > On Wed, Sep 16, 2015 at 4:33 PM, Mike Gilmer <mike.gil...@gmail.com>
> wrote:
> >> Thanks guys.
> >>
> >> The output (somewhat abbreviated) is at http://pastebin.com/BqvwB58y
> >>
> >> I am running Windows 8.1
> >>
> >> Mike
> >>
> >> On Wed, Sep 16, 2015 at 3:52 PM, Tom Rondeau <t...@trondeau.com> wrote:
> >>> On Wed, Sep 16, 2015 at 3:48 PM, Chris Kuethe <chris.kue...@gmail.com>
> >>> wrote:
> >>>>
> >>>> capture the output from "./pybombs install -v -v -v gnuradio", and
> >>>> stick it on pastebin so we can have a look at it.
> >>>>
> >>>> It looks like pybombs is trying to recompile make and gcc and goodness
> >>>> knows what else... I'm curious about why it decided to do that.
> >>>>
> >>>> On Wed, Sep 16, 2015 at 9:25 AM, Mike Gilmer <mike.gil...@gmail.com>
> >>>> wrote:
> >>>> > Following the instriuctions on
> >>>> > http://gnuradio.org/redmine/projects/pybombs/wiki/QuickStart
> >>>> >
> >>>> > I tried to run the installation:  ./pybombs install gnuradio
> >>>> >
> >>>> > It appears to start up OK, but after "Loading recipes" it displays
> >>>> > "Installing packages" and gets through several dozen of them until
> it
> >>>> > displays * gnuradio.
> >>>> >
> >>>> > At that point an Exception error is displayed:
> >>>> >
> >>>> > "Exception RuntimeError: 'maximum recursion depth exceeded' in
>  >>>> > method Popen.__del__ of >
> >>>> > ignored"
> >>>> >
> >>>> > and the installation fails.(many "failed to install gcc" errors are
> >>>> > outputted, followed by "failed to install make")
> >>>> >
> >>>> > Can anyone help me through this step?
> >>>> >
> >>>> > Thanks.
> >>>> > Mike
> >>>
> >>>
> >>>
> >>> Also, what OS are you running? That might be important.
> >>>
> >>> Tom
> >>>
> >
> > ___
> > 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] pybombs installation fails

[Mike Gilmer]

I'm running a cygwin shell.

Mike

On Wed, Sep 16, 2015 at 4:33 PM, Mike Gilmer <mike.gil...@gmail.com> wrote:
> Thanks guys.
>
> The output (somewhat abbreviated) is at http://pastebin.com/BqvwB58y
>
> I am running Windows 8.1
>
> Mike
>
> On Wed, Sep 16, 2015 at 3:52 PM, Tom Rondeau <t...@trondeau.com> wrote:
>> On Wed, Sep 16, 2015 at 3:48 PM, Chris Kuethe <chris.kue...@gmail.com>
>> wrote:
>>>
>>> capture the output from "./pybombs install -v -v -v gnuradio", and
>>> stick it on pastebin so we can have a look at it.
>>>
>>> It looks like pybombs is trying to recompile make and gcc and goodness
>>> knows what else... I'm curious about why it decided to do that.
>>>
>>> On Wed, Sep 16, 2015 at 9:25 AM, Mike Gilmer <mike.gil...@gmail.com>
>>> wrote:
>>> > Following the instriuctions on
>>> > http://gnuradio.org/redmine/projects/pybombs/wiki/QuickStart
>>> >
>>> > I tried to run the installation:  ./pybombs install gnuradio
>>> >
>>> > It appears to start up OK, but after "Loading recipes" it displays
>>> > "Installing packages" and gets through several dozen of them until it
>>> > displays * gnuradio.
>>> >
>>> > At that point an Exception error is displayed:
>>> >
>>> > "Exception RuntimeError: 'maximum recursion depth exceeded' in >> > method Popen.__del__ of >
>>> > ignored"
>>> >
>>> > and the installation fails.(many "failed to install gcc" errors are
>>> > outputted, followed by "failed to install make")
>>> >
>>> > Can anyone help me through this step?
>>> >
>>> > Thanks.
>>> > Mike
>>
>>
>>
>> Also, what OS are you running? That might be important.
>>
>> Tom
>>

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

Re: [Discuss-gnuradio] pybombs installation fails

[Mike Gilmer]

If I understood the process better I'd be willing to help ferret out
the right procedure for cygwin, but I don't think I'd be very
effective at it.  I'm willing to try a few suggestions though... I
mean I'm sure to learn something!

I wrestled with which way to go originally - figure out how to install
linux,and in theory have an easier time of gnuradio, or try the
windows procedure. A co-worker thought the windows path would be
better but these kinds of problems are exactly why I was (and still
am)  seriously considering the linux route.

Mike

On Wed, Sep 16, 2015 at 6:38 PM, Chris Kuethe <chris.kue...@gmail.com> wrote:
> I don't disagree. I'm happy to write the write, I just don't have any
> cygwin machines to test with.
>
> On Wed, Sep 16, 2015 at 3:34 PM, Tom Rondeau <t...@trondeau.com> wrote:
>> On Wed, Sep 16, 2015 at 6:12 PM, Chris Kuethe <chris.kue...@gmail.com>
>> wrote:
>>>
>>> It's been a decade since I last played with cygwin, but under the hood
>>> pybomb can do things like "apt-get install gcc" or "rpm -i fftw-devel"
>>> - I'm trying to figure out what the command is to to get cygwin to go
>>> out and download/install some package from the internet, and how you
>>> can query what packages are installed.
>>
>>
>>
>> For the record, I think it would be great to get support on this platform
>> with PyBOMBS. The big problem is keeping people around to contribute with
>> knowledge of that environment and able to help, test, etc.
>>
>> Tom
>>
>>
>>
>>>
>>> On Wed, Sep 16, 2015 at 3:02 PM, Mike Gilmer <mike.gil...@gmail.com>
>>> wrote:
>>> > I'm new to this. ..are you asking me to run that install command. .. or?
>>> >
>>> > Mike
>>> >
>>> > On Sep 16, 2015 5:03 PM, "Chris Kuethe" <chris.kue...@gmail.com> wrote:
>>> >>
>>> >> This is what PyBOMBS does...
>>> >>
>>> >>
>>> >> https://github.com/gnuradio/pybombs/blob/0382f9253a44135677b656ef08ba438f57f65625/mod_pybombs/sysutils.py#L393
>>> >>
>>> >>
>>> >> https://github.com/gnuradio/pybombs/blob/dc593faf9e1557133c5801fe4aa58198e34407db/mod_pybombs/recipe.py
>>> >>
>>> >> if you could do something like "cygpkg install fftw gcc cmake", for
>>> >> example, then we could easily add the right logic.
>>> >>
>>> >> On Wed, Sep 16, 2015 at 1:49 PM, Mike Gilmer <mike.gil...@gmail.com>
>>> >> wrote:
>>> >> > I'm running a cygwin shell.
>>> >> >
>>> >> > Mike
>>> >> >
>>> >> > On Wed, Sep 16, 2015 at 4:33 PM, Mike Gilmer <mike.gil...@gmail.com>
>>> >> > wrote:
>>> >> >> Thanks guys.
>>> >> >>
>>> >> >> The output (somewhat abbreviated) is at http://pastebin.com/BqvwB58y
>>> >> >>
>>> >> >> I am running Windows 8.1
>>> >> >>
>>> >> >> Mike
>>> >> >>
>>> >> >> On Wed, Sep 16, 2015 at 3:52 PM, Tom Rondeau <t...@trondeau.com>
>>> >> >> wrote:
>>> >> >>> On Wed, Sep 16, 2015 at 3:48 PM, Chris Kuethe
>>> >> >>> <chris.kue...@gmail.com>
>>> >> >>> wrote:
>>> >> >>>>
>>> >> >>>> capture the output from "./pybombs install -v -v -v gnuradio", and
>>> >> >>>> stick it on pastebin so we can have a look at it.
>>> >> >>>>
>>> >> >>>> It looks like pybombs is trying to recompile make and gcc and
>>> >> >>>> goodness
>>> >> >>>> knows what else... I'm curious about why it decided to do that.
>>> >> >>>>
>>> >> >>>> On Wed, Sep 16, 2015 at 9:25 AM, Mike Gilmer
>>> >> >>>> <mike.gil...@gmail.com>
>>> >> >>>> wrote:
>>> >> >>>> > Following the instriuctions on
>>> >> >>>> > http://gnuradio.org/redmine/projects/pybombs/wiki/QuickStart
>>> >> >>>> >
>>> >> >>>> > I tried to run the installation:  ./pybombs install gnuradio
>>> >> >>>> >
>>> >> >>>> > It appears to start up OK, but afte

Re: [Discuss-gnuradio] pybombs installation fails

[Mike Gilmer]

Rich,
I started down that path, ran into trouble (VOLK needed Cheetah or
similar, etc.) and got some advice to follow the pybombs route, which
generated its own trouble.

Academically, of course, I think it would be great to iron out the
Windows issues. As I said, if there are suggestions I'd be willing to
try, but I am concerned that my employer may tire of my not making
progress!

I have an old XP laptop (that I'd like to keep native since it has a
real comm port) and a newer Vista-era laptop (updated to Win 7) that
has no real function any more (daughter's machine, replaced for
college with a Mac)
So perhaps I'll repurpose the newer machine as a Linux box.

Mike

On Wed, Sep 16, 2015 at 9:51 PM, Richard Bell <richard.be...@gmail.com> wrote:
> Mike,
>
> Have you stepped through the procedures outlined in the following two links
> already:
> https://gnuradio.org/redmine/projects/gnuradio/wiki/CygwinInstallMain
> https://gnuradio.org/redmine/projects/gnuradio/wiki/CygwinGettingStarted
>
> They are dated, but still helps guide you a fair amount of the way.
>
> I tried doing this on my Windows laptop a few months ago, but I ran into
> issues. I can't remember what they were now. I posted questions about it
> here but didn't get any responses, so I knew that was a bad sign. I'd be
> very interested in learning how to get gnuradio working on a Windows
> computer, without a VM, as well.
>
> Rich
>
>
>
> On Wed, Sep 16, 2015 at 5:04 PM, Martin Braun <martin.br...@ettus.com>
> wrote:
>>
>> On 16.09.2015 16:58, Mike Gilmer wrote:
>> > I wrestled with which way to go originally - figure out how to install
>> > linux,and in theory have an easier time of gnuradio, or try the
>> > windows procedure. A co-worker thought the windows path would be
>> > better but these kinds of problems are exactly why I was (and still
>> > am)  seriously considering the linux route.
>>
>> Most of us end up with this conclusion, and I'd bet that most of us
>> Linux users are not actually born Windows haters, we simply gravitate to
>> whatever lets us hack with the least amount of friction.
>>
>> Cheers,
>> 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
>

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

Re: [Discuss-gnuradio] A small error in benchmark_tx file

[Mike Jameson]

Hi Dave,

Firstly, please sign up and post to the GNU Radio mailing list via the
official method, not the Ruby forum. GNU Radio has nothing to do with Ruby!

Official GNU Radio mailing list sign-up link:

https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

In regard to your question, make sure you specify all parameters on the
command line, especially frequency, lo-offset and antenna to see whether
that fixes it for you.  I believe the 'none-type' error pops up because
some parameter hasn't been specified and the empty parameter isn't error
checked/initialised to '0' correctly if not specified on the command line.
This may be related to the following bug:

https://gnuradio.org/redmine/issues/705

Mike

--
Mike Jameson M0MIK BSc MIET
Email: m...@scanoo.com
Web: http://scanoo.com

On Sun, Sep 6, 2015 at 10:08 PM, Dave Allen <li...@ruby-forum.com> wrote:

> Hi all,
> I have been trying to send data between 2 USRP's from the benchmark_tx
> file only to observe that I have been receiving this error.
>
> Traceback (most recent call last):
>   File "./benchmark_tx.py", line 147, in 
> main()
>   File "./benchmark_tx.py", line 111, in main
> tb = my_top_block(mods[options.modulation], options)
>   File "./benchmark_tx.py", line 49, in __init__
> options.antenna, options.verbose)
>   File
> "/usr/local/share/gnuradio/examples/digital/narrowband/uhd_interface.py",
> line 135, in __init__
> freq, gain, antenna)
>   File
> "/usr/local/share/gnuradio/examples/digital/narrowband/uhd_interface.py",
> line 62, in __init__
> self._rate, self._sps = self.set_sample_rate(bitrate, sps)
>   File
> "/usr/local/share/gnuradio/examples/digital/narrowband/uhd_interface.py",
> line 70, in set_sample_rate
> asked_samp_rate = bitrate * req_sps
> TypeError: unsupported operand type(s) for *: 'float' and 'NoneType'
>
> I am unable to understand what this error means? I have tried to search
> in the Internet about this but found nothing relevant. Please advice as
> to what I can do?
>
> Thanks,
> Dave
>
> --
> Posted via http://www.ruby-forum.com/.
>
> ___
> 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] gr-rds

[Mike]

Hi Marcus,

I did some further testing. Took me some time unfortunately. The RDS
reception outside is slightly better. But I still got "Lost Sync" info
in the terminal window. However, I could see decoded information. I
can't fight the feeling, that I am missing quite a bit of sensitivity. I
did some more testing with a flowgraph from the gr-gsm packet in the
apps directory. There must be BTSs out there ;-). But I could not see
anything. I used the Ettus Log-Per antenna.

I want to check the hardware and make sure everything is working
correctly. But I will move my question concerning the hardware to the
USPR-users mailing list.

Best regards,
Mike

> Hi Marcus,
> 
> I hoped so, that is why I bought one ;-). I think the max is 73dB. The
> actual value I set with a slider is 90dB. Thus I am pretty much maxed
> out there. But like I wrote earlier, that is the only way to receive at
> least one station. Don't have good RF working conditions. Even cellular
> is a problem.
> 
> BR
> Mike
> 
> 
>> Hi Mike,
>> the B200 should usually be a little more reliable than the RTL dongles;
>> what gain setting are you using?
>>
>> Best regards,
>> Marcus
>>
>> On 08/25/2015 02:08 PM, Michael Thelen DK4MT wrote:
>>> Hi Andreas,
>>>
>>> thanks for the hint. However I am using a Ettus B200 and do not have
>>> access to a different SDR right now. I will test outside and then trying
>>> to find out what is going on.
>>>
>>> BR
>>> Mike
>>>
>>>
>>>> Hi Michael,
>>>>
>>>> i read your mail and i could remember i had a similar problem with a lot
>>>> of lost sync and bad block messages.
>>>>
>>>> My solution was to use a different RTL USB stick and to play with
>>>> antenna type / antenna position and the gain of the RTL stick.
>>>>
>>>> I used a "classical" lamda / 2 dipol UKW Radio antenna. The stick was a
>>>> noname.
>>>>
>>>> regards,
>>>> Andreas
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Am 23.08.2015 um 20:02 schrieb Michael Thelen DK4MT:
>>>>> Hi Marcus,
>>>>>
>>>>> thanks, tried your script and found out, that it is always a little bit
>>>>> uncomely if something is not really reproducible. This is the status:
>>>>>
>>>>> With your script I did not get the earlier error anymore. However with
>>>>> my original I did not get it either. Instead I get the following message
>>>>> in GRC:
>>>>> @ Sync State Detected
>>>>> @ Lost Sync (Got 50 bad blocks on 50 total)
>>>>>
>>>>> I do not get this message if I run your script. Both scripts though do
>>>>> not show RDS information. So before I steal somebody's time I wonder if
>>>>> one reason could be, that I can only receive one station really at the
>>>>> limit and only if I set gain to a max. I can hear fairly clear audio,
>>>>> but I am not sure if I can conclude from, that RDS decoding should work.
>>>>> I am pretty much insulated from RF at my place. What would be in favor
>>>>> by people being sensitive to EM waves, but for experimenting it is
>>>>> pretty bad.
>>>>>
>>>>> So I might gonna check this outside, where I can see in my car, that RDS
>>>>> reception is working on my radio and then I can compare. Just want to
>>>>> make sure we or you aren't chasing an error which might be based on poor
>>>>> reception.
>>>>>
>>>>> However the messages in the terminal have been there last time and the I
>>>>> copied to also were there. Still don't no if this is part of the problem
>>>>> though. Therefore probably more testing on my side.
>>>>>
>>>>> Best regards,
>>>>> Mike
>>>>>
>>>>>
>>>>>
>>>>>> Hi Mike,
>>>>>>
>>>>>> dashed only means "message port connection" rather than "item stream",
>>>>>> so that's nothing to worry about, usually.
>>>>>> So the bad news is that this is possible a GRC bug, which on the other
>>>>>> hand is good news, because it means that gr-rds isn't broken, GRC just
>>>>>> has a hard time correctly generating the python file.
>>>>>> Since that worked for me: can 

Re: [Discuss-gnuradio] pybombs difficulty

[Mike Markowski]

Thanks, Nathan, and all who replied publicly and privately,

The problem seems to be that I had installed Anaconda (from Continuum
Analytics) which does not include Cheetah by default.  It does exist,
however, in the python tree installed by ubuntu, and that seemed to confuse
things.  I installed Cheetah within the anaconda tree and I believe all is
well.  I can say for sure when compiling completes!

Thanks for the speedy and helpful replies,
Mike

On Mon, Aug 3, 2015 at 8:38 PM, West, Nathan n...@ostatemail.okstate.edu
wrote:

 Logan,

 For your case deleting inventory.dat would do the trick of effectively
 resetting pybombs state (and if your done with an install rm the prefix)

 Mike,

 Pybombs is hiding the true error. Cmake failed for either VOLK or GNU
 Radio. Try running pybombs again with -v -v


 On Monday, August 3, 2015, lwas...@ostatemail.okstate.edu wrote:

 Mike,

 When I ran into this problem, I had to reinstall pybombs. I think the
 problem lies in changing the installation prefix after installing pybombs.

 I'm sure there is another way to fix this, I just don't know what it is.

 When I reinstalled pybombs, I defined the installation prefix when the
 several prompts are asked at the beginning.

 Sent from my Cyanogen phone

 On Aug 3, 2015 4:39 PM, Mike Markowski mike.ab...@gmail.com wrote:
 
  I use gentoo at home and have no difficulty keeping gnuradio up to date.
 
  At work we're on a standalone network (no internet) so occasionally
 bring computers home to update them.  Lately, I've been having trouble with
 pybombs.  Using a freshly installed ubuntu 15.04, then doing an
 
apt-get update
apt-get upgrade [not sure the update was necessary]
 
  I first used
 
apt-get install gnuradio
 
  Thinking better of it, I ran
 
apt-get remove gnuradio
apt-get autoremove
 
  Then went with pybombs
 
git clone git://github.com/pybombs/pybombs
cd pybombs
./pybombs config [use install path /usr/local/gnuradio]
./pybombs install gnuradio
 
  And after several tries continue to receive this error:
 
  [...many lines of install...]
  Unpacking liblog4cpp5-dev (1.0-4) ...
  Setting up liblog4cpp5-dev (1.0-4) ...
  installation ok via: deb
  Installing from source: gnuradio
  Cloning into 'gnuradio'...
  Checking connectivity... done.
  Cloning into 'volk'...
  remote: Counting objects: 5450, done.
  remote: Compressing objects: 100% (10/10), done.
  remote: Total 5450 (delta 2), reused 0 (delta 0), pack-reused 5440
  Receiving objects: 100% (5450/5450), 1.54 MiB | 0 bytes/s, done.
  Resolving deltas: 100% (3918/3918), done.
  Checking connectivity... done.
 
  CC=gcc CXX=g++ cmake .. -DCMAKE_BUILD_TYPE=RelWithDebInfo
 -DCMAKE_INSTALL_PREFIX=/usr/local/gnuradio  -DENABLE_DOXYGEN=OFF
 
  Configuring: (100%)
 [==]
  Configuration failed. Re-trying with higher verbosity.
  make: *** No targets specified and no makefile found.  Stop.
  Build failed. See output above for error messages.
 
  Any hints as to what is going wrong?
 
  Thanks,
  Mike
 ___
 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] pybombs difficulty

[Mike Markowski]

I use gentoo at home and have no difficulty keeping gnuradio up to date.

At work we're on a standalone network (no internet) so occasionally bring
computers home to update them.  Lately, I've been having trouble with
pybombs.  Using a freshly installed ubuntu 15.04, then doing an

  apt-get update
  apt-get upgrade [not sure the update was necessary]

I first used

  apt-get install gnuradio

Thinking better of it, I ran

  apt-get remove gnuradio
  apt-get autoremove

Then went with pybombs

  git clone git://github.com/pybombs/pybombs
  cd pybombs
  ./pybombs config [use install path /usr/local/gnuradio]
  ./pybombs install gnuradio

And after several tries continue to receive this error:

[...many lines of install...]
Unpacking liblog4cpp5-dev (1.0-4) ...
Setting up liblog4cpp5-dev (1.0-4) ...
installation ok via: deb
Installing from source: gnuradio
Cloning into 'gnuradio'...
Checking connectivity... done.
Cloning into 'volk'...
remote: Counting objects: 5450, done.
remote: Compressing objects: 100% (10/10), done.
remote: Total 5450 (delta 2), reused 0 (delta 0), pack-reused 5440
Receiving objects: 100% (5450/5450), 1.54 MiB | 0 bytes/s, done.
Resolving deltas: 100% (3918/3918), done.
Checking connectivity... done.

CC=gcc CXX=g++ cmake .. -DCMAKE_BUILD_TYPE=RelWithDebInfo
-DCMAKE_INSTALL_PREFIX=/usr/local/gnuradio  -DENABLE_DOXYGEN=OFF

Configuring: (100%)
[==]
Configuration failed. Re-trying with higher verbosity.
make: *** No targets specified and no makefile found.  Stop.
Build failed. See output above for error messages.

Any hints as to what is going wrong?

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

Re: [Discuss-gnuradio] Fwd: Creating a FFT plot like the one in this youtube variable

[Mike Harpe]

Seconded.

I am a reader of this list. I am working to learn DSP using Gnuradio and I
can tell you firsthand that you have got to do the reading. DSP is very
complex math. If you don't have that background it's very slow going. I
have had to re-learn trigonometry and basic calculus just to read the
introductory material. It's starting to make sense after investing months
of hobby time in it.

This list is an invaluable resource as well.

Mike Harpe, N4PLE
Sellersburg, IN

On Thu, Jul 23, 2015 at 9:27 AM, Marcus Müller marcus.muel...@ettus.com
wrote:

 Hi Ashraf,

 A single complex sine tone will only have one spectral peak.
 I think you will see great profit in understanding a bit of the
 math/signal theory involved. GNU Radio has a suggested reading page,
 especially made for these cases:
 https://gnuradio.org/redmine/projects/gnuradio/wiki/SuggestedReading
 Go through Michael Ossman's tutorial (under Math).

 In fact, reading through that list, there's a distinct lack of free
 ressources that bridge the gap between why? and what are complex signals?
 and digital communication basics, ie. stuff like what is the spectrum/a
 fourier transform.
 If you have access to a university library or so, grab a book on basics of
 signals and linear systems; like in every mature scientific community,
 there's some healthy dispute on what students should be having access to,
 but if you're looking for something relative precise, yet not too
 mathematical and free, have a look at Lapidoth, which is available here as
 a PDF:

 http://www.afidc.ethz.ch/A_Foundation_in_Digital_Communication/Getting_The_Book.html
 Read chapters 2 and 6.

 Best regards,
 Marcus


 ___
 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] Pybombs UHD install

[Mike Willis]

Ah – and what is Mako? Google reveals:

 

“Mako is a template library written in Python. It provides a familiar, non-XML 
syntax which compiles into Python modules for maximum performance”

 

Wonder why I didn’t think of that!

 

Mike

 

From: West, Nathan [mailto:n...@ostatemail.okstate.edu] 
Sent: 19 July 2015 21:32
To: Nathan West
Cc: Mike Willis; discuss-gnuradio
Subject: Re: [Discuss-gnuradio] Pybombs UHD install

 

Sorry, to clarify: the recent transition to mako. Update your recipes and the 
latest ones will have mako.

 

On Sun, Jul 19, 2015 at 4:29 PM, West, Nathan n...@ostatemail.okstate.edu 
mailto:n...@ostatemail.okstate.edu  wrote:

This is probably because of the recent transition to UHD. I just came across 
this while bringing up a new PC. Mako needs to be added as a dependency in the 
UHD recipe or LibUHD will get disabled. The result is very fast compilation 
with no lib built.

 

Cheers,

-Nathan

 

On Sun, Jul 19, 2015 at 2:29 PM, Chris Kuethe chris.kue...@gmail.com 
mailto:chris.kue...@gmail.com  wrote:

Two things I can suggest:
1) make pybombs forget about UHD: ./pybombs inv uhd
2) rebuild with increased verbosity to see what went wrong: ./pybombs
install -v -v uhd


On Sun, Jul 19, 2015 at 9:15 AM, Mike Willis willis...@gmail.com 
mailto:willis...@gmail.com  wrote:
 Did I do something wrong? I just tried to update gnuradio and in pybombs UHD
 downloads lots of data which it then compiles and installs in about 5
 seconds. I can't imagine it is really doing that. Then the following
 gnuradio build fails because it can't find the UHD libs. Not surprising
 really as although pybombs thinks they are, they are not installed.

 Mike


 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org mailto: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 mailto: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] Pybombs UHD install

[Mike Willis]

Yes! sudo apt-get install python-mako

After searching I found a post from 7th July about this.

Currently it appears the recipes are out of date on the server. I had
already tried an update and did so again just now. I tend to update at
the weekend as the data doesn't count towards my monthly data cap.
AFter installing mako UHD compiled. Unfortunately, without this new
package. it doesn't seem to give error messages, it just doesn't do it
so its not an obvious error.

I was hoping Ettus might have fixed the USB3 flakiness that prevents
the B200/B210 from working sometimes. I will see once it finishes
compiling.

Mike

On Sun, Jul 19, 2015 at 10:27 PM, Mike Willis willis...@gmail.com wrote:
 Ah – and what is Mako? Google reveals:



 “Mako is a template library written in Python. It provides a familiar,
 non-XML syntax which compiles into Python modules for maximum performance”



 Wonder why I didn’t think of that!



 Mike



 From: West, Nathan [mailto:n...@ostatemail.okstate.edu]
 Sent: 19 July 2015 21:32
 To: Nathan West
 Cc: Mike Willis; discuss-gnuradio
 Subject: Re: [Discuss-gnuradio] Pybombs UHD install



 Sorry, to clarify: the recent transition to mako. Update your recipes and
 the latest ones will have mako.



 On Sun, Jul 19, 2015 at 4:29 PM, West, Nathan n...@ostatemail.okstate.edu
 wrote:

 This is probably because of the recent transition to UHD. I just came across
 this while bringing up a new PC. Mako needs to be added as a dependency in
 the UHD recipe or LibUHD will get disabled. The result is very fast
 compilation with no lib built.



 Cheers,

 -Nathan



 On Sun, Jul 19, 2015 at 2:29 PM, Chris Kuethe chris.kue...@gmail.com
 wrote:

 Two things I can suggest:
 1) make pybombs forget about UHD: ./pybombs inv uhd
 2) rebuild with increased verbosity to see what went wrong: ./pybombs
 install -v -v uhd


 On Sun, Jul 19, 2015 at 9:15 AM, Mike Willis willis...@gmail.com wrote:
 Did I do something wrong? I just tried to update gnuradio and in pybombs
 UHD
 downloads lots of data which it then compiles and installs in about 5
 seconds. I can't imagine it is really doing that. Then the following
 gnuradio build fails because it can't find the UHD libs. Not surprising
 really as although pybombs thinks they are, they are not installed.

 Mike


 ___
 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





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

[Discuss-gnuradio] gentoo compile errors

[Mike Markowski]

I've been getting these errors when trying to update gnuradio for a week 
or so now.  (I admit to not having tried to tackle them yet, hoping it 
would cure itself!)  Have any other gentoo'ers?


Thanks,
Mike

# emerge gnuradio
[...]
[ 36%] Building CXX object 
gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/and_bb_impl.cc.o
cd 
/var/tmp/portage/net-wireless/gnuradio-3.7.7/work/gnuradio-3.7.7_build/gr-blocks/lib 
 /usr/bin/i686-pc-linux-gnu-g++  -DENABLE_GR_LOG -DGR_PERFORMANC
E_COUNTERS -DHAVE_ARPA_INET_H -DHAVE_BYTESWAP_H -DHAVE_COSF 
-DHAVE_LINUX_PPDEV_H -DHAVE_LOG4CPP -DHAVE_MALLOC_H -DHAVE_NETDB_H 
-DHAVE_NETINET_IN_H -DHAVE_
SELECT -DHAVE_SIGNAL_H -DHAVE_SINCOS -DHAVE_SINCOSF -DHAVE_SINF 
-DHAVE_SYS_IPC_H -DHAVE_SYS_
MMAN_H -DHAVE_SYS_SELECT_H -DHAVE_SYS_SHM_H -DHAVE_SYS_SOCKET_H 
-DHAVE_SYS_TIME_H -DHAVE_SYS_TYPES_H -DHAVE_UNISTD_H 
-Dgnuradio_blocks_EXPORTS  -O2 -march=i686 -pipe  -fvisibility=hidden 
-Wsign-compare -Wall -Wno-uninitialized -fPIC 
-I/var/tmp/portage/net-wireless/gnuradio-3.7.7/work/gnuradio-3.7.7/gr-blocks/lib 
-I/var/tmp/portage/net-wireless/gnuradio-3.7.7/work/gnuradio-3.7.7_build/gr-blocks/lib 
-I/var/tmp/portage/net-wireless/gnuradio-3.7.7/work/gnuradio-3.7.7_build/gr-blocks/lib/../include 
-I/var/tmp/portage/net-wireless/gnuradio-3.7.7/work/gnuradio-3.7.7/gr-blocks/include 
-I/var/tmp/portage/net-wireless/gnuradio-3.7.7/work/gnuradio-3.7.7_build/gr-blocks/include 
-I/var/tmp/portage/net-wireless/gnuradio-3.7.7/work/gnuradio-3.7.7_build 
-I/var/tmp/portage/net-wireless/gnuradio-3.7.7/work/gnuradio-3.7.7/gnuradio-runtime/include 
-I/var/tmp/portage/net-wireless/gnuradio-3.7.7/work/gnuradio-3.7.7_build/gnuradio-runtime/include 
-I/var/tmp/portage/net-wireless/gnuradio-3.7.7/work/gnuradio-3.7.7/volk/include 
-I/var/tmp/portage/net-wireless/gnuradio-3.7.7/work/gnuradio-3.7.7_build/volk/include 
   -o CMakeFiles/gnuradio-blocks.dir/and_bb_impl.cc.o -c 
/var/tmp/portage/net-wireless/gnuradio-3.7.7/work/gnuradio-3.7.7_build/gr-blocks/lib/and_bb_impl.cc
In file included from 
/var/tmp/portage/net-wireless/gnuradio-3.7.7/work/gnuradio-3.7.7/gr-zeromq/lib/pub_sink_impl.h:27:0,
 from 
/var/tmp/portage/net-wireless/gnuradio-3.7.7/work/gnuradio-3.7.7/gr-zeromq/lib/pub_sink_impl.cc:28:

/usr/include/zmq.hpp:550:47: error: ‘zmq_event_t’ does not name a type
 virtual void on_event_connected(const zmq_event_t event_, 
const char*

   ^
/usr/include/zmq.hpp:551:53: error: ‘zmq_event_t’ does not name a type
 virtual void on_event_connect_delayed(const zmq_event_t 
event_, const

 ^
/usr/include/zmq.hpp:552:53: error: ‘zmq_event_t’ does not name a type
 virtual void on_event_connect_retried(const zmq_event_t 
event_, const

 ^
[...]

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

[Discuss-gnuradio] Input items vs Output items

[Mike Willis]

I am slightly confused with the way you implement a general work
function - here is my AX25 decoder which takes in bits and outputs
decoded packets in text format as a stream of 8 bit integers. This was
based on the general work example in the GR tutorial.

int ax25_impl::general_work (int noutput_items,
  gr_vector_int ninput_items,
  gr_vector_const_void_star input_items,
  gr_vector_void_star output_items)
{
int i;
const char *bit = (const char *) input_items[0];
out = (char *) output_items[0];

d_numchars=0;
for (i=0;i noutput_items; i++)
{
hdlc_rxbit( bit[i] );
}

// Tell runtime system how many output items we produced.
consume_each (noutput_items);
return d_numchars;
}

I keep a tally of how many characters I output in the class member
variable d_numchars. I do this by initially printing to the out
buffer (see above code) with the vsprintf() function and then using
the strlen() function to find out how long the out string is.

It works for a while, perhaps 200-300 packets and then crashes with a
segfault and error 7. I know the crash is related to the number of
output items because if I reduce the number of characters I output it
will run for longer. If I don't output anything its fine, but not very
useful.

It gets complicated because the block outputs nothing at all until it
decodes a packet, then it outputs that entire packet, which might be
up to 1000 characters or so.

I think I have made a fundamental error somewhere. Finding it is
proving problematic. I am also confused by ninput_items and
noutput_items variables as to me they appear reversed but that is how
they are in the tutorial.


Mike

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

Re: [Discuss-gnuradio] Input items vs Output items

[Mike Willis]

I should have added, the packet decoding is based on Volkers rather nifty 
gr-ax25, which I think is based on earlier implementations so I don't think 
that is where the bug is. I have heavily modified that code as I am using BPSK 
demodulator but the hdlc parts are the same. 

Mike

-Original Message-
From: Mike Willis [mailto:willis...@gmail.com] 
Sent: 18 April 2015 13:58
To: GNURadio Discussion List
Subject: Input items vs Output items

I am slightly confused with the way you implement a general work function - 
here is my AX25 decoder which takes in bits and outputs decoded packets in text 
format as a stream of 8 bit integers. This was based on the general work 
example in the GR tutorial.

int ax25_impl::general_work (int noutput_items,
  gr_vector_int ninput_items,
  gr_vector_const_void_star input_items,
  gr_vector_void_star output_items) { int i; const char *bit = 
(const char *) input_items[0]; out = (char *) output_items[0];

d_numchars=0;
for (i=0;i noutput_items; i++)
{
hdlc_rxbit( bit[i] );
}

// Tell runtime system how many output items we produced.
consume_each (noutput_items);
return d_numchars;
}

I keep a tally of how many characters I output in the class member variable 
d_numchars. I do this by initially printing to the out
buffer (see above code) with the vsprintf() function and then using the 
strlen() function to find out how long the out string is.

It works for a while, perhaps 200-300 packets and then crashes with a segfault 
and error 7. I know the crash is related to the number of output items because 
if I reduce the number of characters I output it will run for longer. If I 
don't output anything its fine, but not very useful.

It gets complicated because the block outputs nothing at all until it decodes a 
packet, then it outputs that entire packet, which might be up to 1000 
characters or so.

I think I have made a fundamental error somewhere. Finding it is proving 
problematic. I am also confused by ninput_items and noutput_items variables as 
to me they appear reversed but that is how they are in the tutorial.


Mike


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