Re: [Discuss-gnuradio] XM on GR

[Sylvain Munaut]

Hi,


> I was thinking about XM radio today and how channel 1 on it is sent in the
> clear (if you don't have a subscription, you can tune to it and hear their
> adds).  I haven't found a lot of information (so I think I know the answer),
> but has anyone looked into an XM receiver in GR?

The audio codec is proprietary and not documented anywhere AFAIK so
even if you demod the bitstream, you won't be able to do much with it.

Cheers,

Sylvain

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

Re: [Discuss-gnuradio] [Docker] New GNU Radio images with GUI support

[Stefan Wunsch]

Hey,

Using hardware with docker containers is pretty easy. Just use the
--device flag and (effectively) share a folder/file of your host with
the container or use the --net=host flag to share the network
connection. Basically, that's all!

And Nick Foster is right, there should be almost no overhead (that's
what the people are saying about using docker). Obviously, dependent on
the additional services such as the VNC server.

Greetings
Stefan

On 04/08/2016 12:47 AM, Ben Hilburn wrote:
> Hi Stefan -
> 
> This is really cool! Thanks so much for sharing your images and for
> posting instructions. It looks like a number of people have started
> playing with GNU Radio containers - I recognize some of the other names
> that have publicly shared images (e.g., Nick Foster aka 'bistromath').
> We chatted a bit about using Docker as a way to get a "known state"
> machine up-and-running with GNU Radio quickly at GRCon15, and it seems
> like it could greatly simplify the installation process for certain use
> cases.
> 
> What was your experience like when it came to using the RTL dongle? Was
> there any complexity there? If you have hardware that can stream at
> higher rates, I'd be interested in how those perform in the container,
> as well.
> 
> Cheers,
> Ben
> 
> On Wed, Apr 6, 2016 at 4:23 AM, Stefan Wunsch
> mailto:stefan.wun...@student.kit.edu>>
> wrote:
> 
> Hi all!
> 
> I have build a docker tool-chain for an image with GNU Radio and UHD
> installed via PyBOMBS on top of Ubuntu. It's even possible to run it
> dockerized with a GUI using VNC and it should work as well on windows
> and mac (so far, not tested). The build files are available on github
> and the precompiled images on hub.docker.com
> . If you are interested,
> have a look! In the following, I will give a short description.
> 
> How to run the image with VNC server and how to access the container:
> 
> # Run the image with GNU Radio and VNC server:
> # The run command will download (pull) the image automatically.
> # Use the additional option '-device=/dev/bus/usb' for USB access,
> # e.g., to use rtl dongles. You have to plugin the devices before you
> # start the container!
> 
> $ docker run -it --rm -p 5901:5901 -e USER=root \
> stwunsch/docker-pybombs-gnuradio-vnc bash -c \
> "vncserver :1 -geometry 1280x800 -depth 24 && tail -F /root/.vnc/*.log"
> 
> # Get graphical access using a VNC client. I suppose you are running
> # the container on the same machine. Here an example command using
> # vncviewer. As well, it's possible to use X forwarding.
> 
> $ vncviewer localhost:5901
> 
> So far, it's only tested on a Linux machine, but it should work on every
> system with an installed docker daemon. I was able to run a rtl dongle
> with gr-osmosdr. To install new OOTs, just open a terminal and type, for
> example, 'pybombs install gr-osmosdr'.
> 
> Here, the image chain. You can pull these images from hub.docker.com
> .
> All images are build automatically on change of the appropriate GitHub
> repository (except the GNU Radio base image, see below for more info on
> that).
> 
> Base-image: ubuntu 14.04
> -> ubuntu + pybombs (stwunsch/docker-pybombs)
> -> ubuntu + pybombs + uhd (stwunsch/docker-pybombs-uhd)
> -> ubuntu + pybombs + uhd + gnuradio dependencies
> (stwunsch/docker-pybombs-gnuradio-depsonly)
> -> ubuntu + pybombs + uhd + gnuradio (stwunsch/docker-pybombs-gnuradio)
> -> ubuntu + pybombs + uhd + gnuradio + vnc server
> (stwunsch/docker-pybombs-gnuradio-vnc)
> 
> A single problem so far: It is not possible to build the GNU Radio image
> (docker-pybombs-gnuradio) on the docker servers, because they have a 2h
> build limitation. I have preinstalled everything (pybombs and all
> dependencies), but it is not possible to run the compilation below 2h on
> a single core.
> 
> Does anyone know whether it's possible to split the compilation or speed
> it up (without using the -jX flag)? Now the image has to be build
> locally and then pushed to hub.docker.com 
> manually. Not the best solution!
> 
> I would be highly interested whether it really works on other systems,
> especially on windows! That could be a nice alternative to MSVC
> compilations.
> 
> Greetings
> Stefan
> 
> ___
> 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] Power Line Communications - GNURadio

[FredWatrous]

Hi Paul,

I saw your post and thought I would respond.  I found the HackRF a while
back, it's a comparable instrument to one which my company sells for PLC,
just so you know, and I've developed the PC software for displaying the
data.  RF and metering is an area we've done a lot of work in, and SDR is
really improving diagnostics for field work.

By now you've learned that PRIME is a star network, that doesn't use mesh,
and for diagnostic purposes, the strobe beacon is a real pain.  It's
basically the same as token ring if you remember IBM's old network
technology.  It sends out a pulse every few milliseconds and thus tells the
meters when they can talk.

If you setup anything, you need to be able to look at buffers in between
different samples in order to see anything of value, (you need to have a FFT
data rate under 50-60 ms per buffer and be able to look at individual FFT
curves).  Otherwise the beacon will kill any detail that would be of
interest.

Different modes are interesting for lab work and checking performance, but
not really in the field, other than to point to general problem areas.  On
the AC communication side you need to be able to find a particular AC/DC
network adapter in a substation area of 3 - 400 homes / apartments.  (It's
something we also do for various utilities.)  Though this is less
interesting in your case with DC connections.  However, having done a little
TPC and FTT10 between substations, cables running in parallel, (signal
transfer from non-shielded cables or heavily loaded power cable proximity),
and splices can definitely create problems.

For PRIME 1.3.6 you need 1024 samples at 250 kHz, and the signal is between
41 and 89 kHz.  PRIME 1.4 has 4096 samples at 1.0 MHz and uses 41 to 472
kHz.  Good luck!

Sincerely,

Fred



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Power-Line-Communications-GNURadio-tp59330p59429.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

Re: [Discuss-gnuradio] Ubunto 15.04 (right off the .iso) recipe for success

[camski.watersport]

Yes it works.

You may need to do some research (before asking questions) if things 
don't work due to pip issues and build issues, this will all help you 
understand your OS, pip, Pybombs and GNU radio.


If you have pip issue this may help


Here is how I fixed my Ubuntu (15.04) Pip issue, this may help you also.

https://github.com/gnuradio/pybombs/issues/281

The commands were from memory so you may not need to use each one.



On 08/04/16 12:03, Gregory W. Ratcliff wrote:

Greetings,

Has anyone gone start to finish with  64 bit, desktop, 15.04, new pip 
and pybombs 2+. ?


I would like to get back to enjoying gnuradio as quickly as possible.

Thank you,

Mr. Lazy.
Gregory W. Ratcliff







___
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] XM on GR

[Jason Matusiak]

The audio codec is proprietary and not documented anywhere AFAIK so
even if you demod the bitstream, you won't be able to do much with it.


Thank you all for the conversation, it is pretty interesting.  That makes sense 
that they have a proprietary protocol, it's a shame though.  Is the text that 
comes through encoded in a proprietary way?

Does anyone know what the frequency of channel 1 is on (I'd like to see if I 
can even see the signal popping up above the noise)?

~Jason


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

Re: [Discuss-gnuradio] [Docker] New GNU Radio images with GUI support

[Ben Hilburn]

Thanks for the responses, Stefan and Nick.

It seems like Docker could make it much easier for us to support a variety
of operating systems - although the user would still need to install
Docker, itself. Presumably that's easier than earlier containerized models,
though (e.g., VMs).

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

Re: [Discuss-gnuradio] Spectrum management in cognitive radio

[Stephen Berger]

Galen,

 

You raise a very important point.  There are a lot of other systems that are
sensitive to RF but not RF transmitters.  Any new use of spectrum really
should try to foresee and avoid those impacts.

 

We had a major 'train wreck' in this area in the mid-90's when cellular went
digital.  GSM in particular caused all kinds of hearing aid and other kinds
of interference.  The FCC chairmen at the time took an active hand in
resolving that.  I found myself in congressional hearing rooms (absent the
congresspersons) because their cell phones were interfering with the mics
and audio amps, making it hard to hear the congressmen (you can imagine how
warmly the politicians responded to the press not being able to hear their
every word!!).

 

An area I work in a lot and worry about a lot is demodulated RF mimicking a
biologic signature.  We have lots of medical equipment, including implanted
pacemakers, sensing very low level signals.  If RF hits them and demodulates
in a way that it looks like a heartbeat or some other signal bad things
could happen.

 

Perhaps the best contribution the GNURadio community can make it to continue
to develop and improve the 'on ramps' to using GNURadio so that it becomes
increasingly feasible to make spectrum measurements and run tests,
especially run tests which new ideas are just that and not like the GSM case
where we learned of the problem after millions of devices were out and in
use.

 

I was actually talking to one of the FDA research staff about this
yesterday.  I would like to help build an educational on-ramp to using
GNURadio for those in the medical device community, including research staff
at the FDA.  There is a lot of great help already out there, like the
tutorials on the GNURadio site.  I would love to hear thoughts on how to
make the on-ramp shorter and smoother.  Essentially, where does more work do
the most good on this topic?

 

Best Regards,





Stephen Berger

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

Re: [Discuss-gnuradio] XM on GR

[Andy Walls]

> The audio codec is proprietary and not documented anywhere AFAIK so
> even if you demod the bitstream, you won't be able to do much with it.

> Thank you all for the conversation, it is pretty interesting.  That makes 
> sense 
> that they have a proprietary protocol, it's a shame though.  Is the text that 
> comes through encoded in a proprietary way?
> 
> Does anyone know what the frequency of channel 1 is on (I'd like to see if I 
> can even see the signal popping up above the noise)?
> 
> ~Jason

The XM center freqs are shown here:

https://www.rohde-schwarz.com/us/technologies/satellite-broadcast/xm-satellite/xm-satellite-technology/xm-satellite-technology_55613.html

The Sats are QPSK, the terrestrial is COFDM.

That page also states the audio codec for voice programming is AMBE, and
AAC+ for all other programming.


The XM radio patents give you a lot of clues:
https://www.google.com/search?tbo=p&tbm=pts&hl=en&q=inassignee:%22Xm+Satellite+Radio+Inc.%22

Images 4 and 6 of this one:
https://www.google.com/patents/US7020217?dq=inassignee:%22Xm+Satellite+Radio+Inc.%22&hl=en&sa=X&ved=0ahUKEwj5ycbeoP_LAhXEXh4KHWSdDeA4HhDoAQgwMAM
Image 4 of this one:
https://www.google.com/patents/US6510317?dq=inassignee:%22Xm+Satellite+Radio+Inc.%22&hl=en&sa=X&ved=0ahUKEwikn4Ogof_LAhVIJx4KHYaYCt44KBDoAQhTMAg

And maybe the most useful I've skimmed:
https://www.google.com/patents/US7123875?dq=inassignee:%22Xm+Satellite+Radio+Inc.%22+MCM&hl=en&sa=X&ved=0ahUKEwidqpT1of_LAhUFXh4KHXqIDuEQ6AEIKjAC
Images 1, 5, and 6.

This particular patent also indicates that after the demod, RS decoder,
viterbi decoder, and deinterleaver, that an MPEG TS *might* be the
transport multiplex.

The images show that the decryption happens after all the FEC and
deinterleaving is handled and also after SL (service layer) decoding.
The I2C connected external NVRAM is likely where the program decryption
key is stored (inside of a tamper boundary), according to other internet
pages from 7 years ago.

So I'm guessing you have to totally demodulate and decode one of the SAT
or terrestrial channels, and then dig around in a (hopefully MPEG)
transport stream to find your unencrypted "Channel 1"

Regards,
Andy


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

Re: [Discuss-gnuradio] [Docker] New GNU Radio images with GUI support

[Kevin Hofschröer]

Hello Stefan and all,

I also recently experimented with GR and Docker and at least got it working so 
far.
My approach was different in that I used the ubuntu:16.04 base image where 
gnuradio v3.7.9.1 (so pretty new) is available pre-compiled in the official 
ubuntu repositories.
Of course that approach isn't something for developers, but if you
 1. apt-get install gnuradio-dev
 2. apt-get remove gnuradio-dev
 3. install some missing header packages, thrift and other libs that are not 
included in the gnuradio-dev package and
 4. get the gnuradio v3.7.9.1 sources and compile it yourself ,
you can get a good basis for devs. Of course, if you just want to play around 
with gnuradio, you probably don't need these steps.

Another thing that might be useful:
If you want GUI-applications without using VNC (AND if you use linux), you 
might want to have a look at
http://fabiorehm.com/blog/2014/09/11/running-gui-apps-with-docker/
where the idea is to basically share your .Xauthority file and your 
/tmp/.X11-unix socket. It looks pretty hacky, but it worked perfect for me. For 
QT, you seem to need to replace
"-e DISPLAY=$DISPLAY"
within the run command (or use a Dockerfile ENV line) with
"-e DISPLAY=unix$DISPLAY".
Of course, this wouldn't work that way for Windows. But I could imagine that 
devices can cause problems there as well because of the small VM that you need.

Hope you find some of this helpful.

Greetings,
Kevin

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

Re: [Discuss-gnuradio] [Docker] New GNU Radio images with GUI support

[Kevin Hofschröer]

Also, is there a reason not to use the "-j" option in a Dockerfile?

Kevin

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

Re: [Discuss-gnuradio] [Docker] New GNU Radio images with GUI support

[Stefan Wunsch]

Hi,

That's true for now, but ubuntu's repos aren't made for developing. The
repos are just too old within a few month. And then recent (or self
developed) OOTs won't work.

Regarding running the GUI: In the readme I've included the commands for
X forwarding (that's your approach). Works fine on my machine! The VNC
approach targets especially windows users.

Greetings
Stefan

On 04/08/2016 04:55 PM, Kevin Hofschröer wrote:
> Hello Stefan and all,
> 
> I also recently experimented with GR and Docker and at least got it working 
> so far.
> My approach was different in that I used the ubuntu:16.04 base image where 
> gnuradio v3.7.9.1 (so pretty new) is available pre-compiled in the official 
> ubuntu repositories.
> Of course that approach isn't something for developers, but if you
>  1. apt-get install gnuradio-dev
>  2. apt-get remove gnuradio-dev
>  3. install some missing header packages, thrift and other libs that are not 
> included in the gnuradio-dev package and
>  4. get the gnuradio v3.7.9.1 sources and compile it yourself ,
> you can get a good basis for devs. Of course, if you just want to play around 
> with gnuradio, you probably don't need these steps.
> 
> Another thing that might be useful:
> If you want GUI-applications without using VNC (AND if you use linux), you 
> might want to have a look at
> http://fabiorehm.com/blog/2014/09/11/running-gui-apps-with-docker/
> where the idea is to basically share your .Xauthority file and your 
> /tmp/.X11-unix socket. It looks pretty hacky, but it worked perfect for me. 
> For QT, you seem to need to replace
> "-e DISPLAY=$DISPLAY"
> within the run command (or use a Dockerfile ENV line) with
> "-e DISPLAY=unix$DISPLAY".
> Of course, this wouldn't work that way for Windows. But I could imagine that 
> devices can cause problems there as well because of the small VM that you 
> need.
> 
> Hope you find some of this helpful.
> 
> Greetings,
> Kevin
> 

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

Re: [Discuss-gnuradio] [Docker] New GNU Radio images with GUI support

[Stefan Wunsch]

I think (but I am not totally sure) that you can target multiple cores
from a single container. So the -j option should work on your local
machine. But not on hub.docker.com, because you have only one core on
the server machine.

Greetings

On 04/08/2016 05:08 PM, Kevin Hofschröer wrote:
> Also, is there a reason not to use the "-j" option in a Dockerfile?
> 
> Kevin
> 

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

[Discuss-gnuradio] Pybombs install fetch fail

[Freedomfighter099 .]

Hello

I’m keep running into this problem when I tried to install a gnuradio and
so on through pybombs on Ubuntu 14.4

I’m getting the following error: PyBombs.Fetcher - ERROR - Unexpected error
while fetching wget+
ftp://ftp.qt.nokia.com/qt/source/qt-everywhere-opensource-src-4.6.2.tar.gz.

PyBombs.Fetcher - ERROR - No connection adapters were found for '
ftp://ftp.qt.nokia.com/qt/source/qt-everywhere-opensource-src-4.6.2.tar.gz'

PyBombs.Packager.source - ERROR - Problem occurred while building package
qt4:

Unable to fetch recipe qt4

PyBombs.install - ERROR - Error installing package qt4. Aborting.



Any help would be appreciated
Thanks
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [Docker] New GNU Radio images with GUI support

[Johnathan Corgan]

On Fri, Apr 8, 2016 at 6:12 AM, Ben Hilburn  wrote:


> It seems like Docker could make it much easier for us to support a variety
> of operating systems - although the user would still need to install
> Docker, itself. Presumably that's easier than earlier containerized models,
> though (e.g., VMs).
>


I've been doing a lot of behind-the-scenes work with GNU Radio and docker
recently, mostly to beef up our automated test infrastructure.

There are a number of different use cases that overlap.  One is testing, as
mentioned.  Another is "full installation of all GNU Radio, dev tools, and
related items to do complete application development."  Yet a third is
"minimal set of packages needed to execute a given GNU Radio application."

I'm working out a stratification of layers that build on one another,
starting with an OS base layer, one adding minimal runtime packages, then
adding minimum build time packages, then a full development layer.

I caution, though, the containers are not the answer to everything, and
it's at least questionable whether providing a full dev environment as a
container is useful to beginners.  There's enough work required "outside"
the container (permissions, volumes, device mappings, networking config)
that the user will still need to understand the internals of Docker before
becoming productive.

That said, I'm very interested in feedback on what the community feels is
useful vs. my own perceptions.

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

Re: [Discuss-gnuradio] Pybombs install fetch fail

[Marcus D. Leech]

On 04/08/2016 11:17 AM, Freedomfighter099 . wrote:


Hello

I’m keep running into this problem when I tried to install a gnuradio 
and so on through pybombs on Ubuntu 14.4


I’m getting the following error: PyBombs.Fetcher - ERROR - Unexpected 
error while fetching 
wget+ftp://ftp.qt.nokia.com/qt/source/qt-everywhere-opensource-src-4.6.2.tar.gz.


PyBombs.Fetcher - ERROR - No connection adapters were found for 
'ftp://ftp.qt.nokia.com/qt/source/qt-everywhere-opensource-src-4.6.2.tar.gz'


PyBombs.Packager.source - ERROR - Problem occurred while building 
package qt4:


Unable to fetch recipe qt4

PyBombs.install - ERROR - Error installing package qt4. Aborting.

Any help would be appreciated

Thanks


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

My guess is that you don't have FTP installed.

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

Re: [Discuss-gnuradio] [Docker] New GNU Radio images with GUI support

[Johnathan Corgan]

On Fri, Apr 8, 2016 at 8:09 AM, Stefan Wunsch  wrote:


> Regarding running the GUI: In the readme I've included the commands for
> X forwarding (that's your approach). Works fine on my machine! The VNC
> approach targets especially windows users.
>

I've had success running GRC and QT-based GNU Radio applications using
several different display techniques from inside Docker containers (on
Linux).

- Volume mapping the local /tmp/.X11-unix into the container, setting
DISPLAY to unix$DISPLAY, and allowing access through xhost. This only works
on your local machine.

- Using --net host and -e DISPLAY when launching the container.  This is
useful when you are remotely ssh'd into a host and have X forwarding, so
the container will use the tunneled X server back at your local machine.

- Using xfvb and x11vnc to allow display access via VNC.  This is the most
flexible but slowest.

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

[Discuss-gnuradio] pybombs install fetch fail

[Freedomfighter099 .]

I’ve just double checked and the program FTP on Ubuntu is installed and up
to date.

Furthermore yesterday I installed the gnuradio on a virtual machine through
pybombs with no problems.

It seems that package gt4 is not able to be downloaded through the above
following FTP links which is strange, I these FTP addresses correct?

Or is pybombs attempting to fetch from a dead link?

Any suggestions would be appreciated
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Pybombs install fetch fail

[Kevin Hofschröer]

Actually, I often ran into the same problem myself. When you try to browse this 
link with the browser or through normal command line operation, you will have 
the same effect.
You can replace that recipe line with
"wget+http://download.qt.io/archive/qt/4.6/qt-everywhere-opensource-src-4.6.2.tar.gz";
and then retry the pybombs install command.

Greetings
Kevin

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

Re: [Discuss-gnuradio] Pybombs install fetch fail

[Freedomfighter099 .]

This may be a easy question for many but I have no idea how to replace a
recipe

in which configuration file is possible to change out receipts in this
instance wget+
ftp://ftp.qt.nokia.com/qt/source/qt-everywhere-opensource-src-4.6.2.tar.gz.
to this one  "wget+
http://download.qt.io/archive/qt/4.6/qt-everywhere-opensource-src-4.6.2.tar.gz
"

Thanks

2016-04-08 18:35 GMT+02:00 Kevin Hofschröer :

> Actually, I often ran into the same problem myself. When you try to browse
> this link with the browser or through normal command line operation, you
> will have the same effect.
> You can replace that recipe line with
> "wget+
> http://download.qt.io/archive/qt/4.6/qt-everywhere-opensource-src-4.6.2.tar.gz
> "
> and then retry the pybombs install command.
>
> Greetings
> Kevin
>
> ___
> 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 install fetch fail

[Sebastian Müller]

Hi

during PyBOMBS setup you may have added the recipe files with the command
pybombs recipes add gr-recipes git+https://github.com/gnuradio/gr-recipes.git  

The recipes will then be placed at ~/.pybombs/recipes/gr-recipes/. You can 
alter the qt4.lwr there and replace the corrupt URL by a valid one:
https://download.qt.io/archive/qt/4.6/qt-everywhere-opensource-src-4.6.3.tar.gz

Greetings
Sebastian
Am 8. April 2016 bei 19:02:32, Freedomfighter099 . 
(freedomfighter.missing.l...@gmail.com) schrieb:

This may be a easy question for many but I have no idea how to replace a recipe

in which configuration file is possible to change out receipts in this instance 
wget+ftp://ftp.qt.nokia.com/qt/source/qt-everywhere-opensource-src-4.6.2.tar.gz.
 to this one  
"wget+http://download.qt.io/archive/qt/4.6/qt-everywhere-opensource-src-4.6.2.tar.gz";

Thanks


2016-04-08 18:35 GMT+02:00 Kevin Hofschröer :
Actually, I often ran into the same problem myself. When you try to browse this 
link with the browser or through normal command line operation, you will have 
the same effect.
You can replace that recipe line with
"wget+http://download.qt.io/archive/qt/4.6/qt-everywhere-opensource-src-4.6.2.tar.gz";
and then retry the pybombs install command.

Greetings
Kevin

___
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] Ubunto 15.04 (right off the .iso) recipe for success

[Gregory W. Ratcliff]

Chris,
THANKS.  PIP seems happy.
List Python gurus I blew up with

gratcliff@ubuntu:~/gnuradio$ pybombs install gnuradio gr-osmosdr

Traceback (most recent call last):
  File "/usr/local/bin/pybombs", line 9, in 
    load_entry_point('PyBOMBS==2.0.1', 'console_scripts', 'pybombs')()
  File "/usr/local/lib/python2.7/dist-packages/pybombs/main.py", line 30, in 
main
    return dispatch() or 0
  File "/usr/local/lib/python2.7/dist-packages/pybombs/commands/base.py", line 
141, in dispatch
    return get_cmd_dict(cmd_list)[args.command](cmd=args.command, 
args=args).run()
  File "/usr/local/lib/python2.7/dist-packages/pybombs/commands/install.py", 
line 129, in run
    self._check_if_pkg_goes_into_tree if not self.args.no_deps else lambda x: 
bool(x in self.args.packages)
  File "/usr/local/lib/python2.7/dist-packages/pybombs/dep_manager.py", line 
56, in make_dep_tree
    dep_trees[pkg] = self.make_tree_recursive(pkg, filter_callback)
  File "/usr/local/lib/python2.7/dist-packages/pybombs/dep_manager.py", line 
85, in make_tree_recursive
    subtree = self.make_tree_recursive(dep, filter_callback)
  File "/usr/local/lib/python2.7/dist-packages/pybombs/dep_manager.py", line 
85, in make_tree_recursive
    subtree = self.make_tree_recursive(dep, filter_callback)
  File "/usr/local/lib/python2.7/dist-packages/pybombs/dep_manager.py", line 
76, in make_tree_recursive
    if not self.pm.exists(pkg):
  File "/usr/local/lib/python2.7/dist-packages/pybombs/package_manager.py", 
line 113, in exists
    pkg_version = pkgr.exists(r)
  File "/usr/local/lib/python2.7/dist-packages/pybombs/packagers/extern.py", 
line 102, in exists
    return self._packager_run_tree(recipe, self._package_exists)
  File "/usr/local/lib/python2.7/dist-packages/pybombs/packagers/extern.py", 
line 163, in _packager_run_tree
    return satisfy_rule.ev(satisfy_evaluator)
  File "/usr/local/lib/python2.7/dist-packages/pybombs/recipe.py", line 53, in 
ev
    return func(self.name, self.compare or ">=", self.version)
  File "/usr/local/lib/python2.7/dist-packages/pybombs/packagers/extern.py", 
line 172, in _package_exists
    or (required_version is not None and not vcompare(comparator, 
available_version, required_version)):
  File "/usr/local/lib/python2.7/dist-packages/pybombs/utils/vcompare.py", line 
34, in vcompare
    return operators[cmp_op](LooseVersion(version_x), LooseVersion(version_y))
  File "/usr/lib/python2.7/distutils/version.py", line 265, in __init__
    self.parse(vstring)
  File "/usr/lib/python2.7/distutils/version.py", line 274, in parse
    self.component_re.split(vstring))
TypeError: expected string or buffer

 Gregory W. Ratcliff






 
  From: Chris Kuethe 
 To: Gregory W. Ratcliff  
Cc: discuss-gnuradio 
 Sent: Thursday, April 7, 2016 10:20 PM
 Subject: Re: [Discuss-gnuradio] Ubunto 15.04 (right off the .iso) recipe for 
success
   
I'm using 15.10 with little difficulty. I suppose I should spin up a 15.04 test 
vm. On Apr 7, 2016 19:04, "Gregory W. Ratcliff"  wrote:

Greetings,
Has anyone gone start to finish with  64 bit, desktop, 15.04, new pip and 
pybombs 2+. ?
I would like to get back to enjoying gnuradio as quickly as possible.
Thank you,
Mr. Lazy.
 Gregory W. Ratcliff





___
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 install fetch fail

[Freedomfighter099 .]

Okay that helps cheers

2016-04-08 19:23 GMT+02:00 Sebastian Müller :

> Hi
>
> during PyBOMBS setup you may have added the recipe files with the command
> pybombs recipes add gr-recipes
> git+https://github.com/gnuradio/gr-recipes.git
>
> The recipes will then be placed at ~/.pybombs/recipes/gr-recipes/. You can
> alter the qt4.lwr there and replace the corrupt URL by a valid one:
>
> https://download.qt.io/archive/qt/4.6/qt-everywhere-opensource-src-4.6.3.tar.gz
>
> Greetings
> Sebastian
>
> Am 8. April 2016 bei 19:02:32, Freedomfighter099 . (
> freedomfighter.missing.l...@gmail.com) schrieb:
>
> This may be a easy question for many but I have no idea how to replace a
> recipe
>
> in which configuration file is possible to change out receipts in this
> instance wget+
> ftp://ftp.qt.nokia.com/qt/source/qt-everywhere-opensource-src-4.6.2.tar.gz.
> to this one  "wget+
> http://download.qt.io/archive/qt/4.6/qt-everywhere-opensource-src-4.6.2.tar.gz
> "
>
> Thanks
>
> 2016-04-08 18:35 GMT+02:00 Kevin Hofschröer :
>
>> Actually, I often ran into the same problem myself. When you try to
>> browse this link with the browser or through normal command line operation,
>> you will have the same effect.
>> You can replace that recipe line with
>> "wget+
>> http://download.qt.io/archive/qt/4.6/qt-everywhere-opensource-src-4.6.2.tar.gz
>> "
>> and then retry the pybombs install command.
>>
>> Greetings
>> Kevin
>>
>> ___
>> 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] FW: HF transmitter hardware solutions

[Daniel Pocock]

On 07/04/16 20:01,  John Petrich wrote:
> Dan, Lou, Ron, and others,
> 
> Dan you are doing a great job of beating the drum: searching for "solutions
> for transmitting on HF"  The question is a big one and can be broken down
> into three basic issues.  The basic or elemental SDR platform solutions are
> changing rapidly.  With the third generation SDRs, and tightly integrated
> RFICs, there are a number of excellent, high performance, solutions, as has
> been pointed out, and as you well know.
> 
> I think your real question, Dan, asks about the rest of the HF system: the
> elements necessary to complete the transmitter for practical communication
> purposes.  The question moves beyond SDR hardware to that of station
> building.  That station building part of the system, I call the "interface".

Yes, this is very much where I was aiming with this question/email thread

> The "interface" provides the receive and transmit filtering and antenna
> switching, power control, amplifier stages, and other functions.  The
> "interface" is built upon analog technology.  Much information along these
> lines is addressed by the QRP (low power) movement within Amateur Radio.
> The American Radio Relay League (ARRL) publishes small paperback books
> devoted to QRP equipment and station building, and available for purchase
> on-line.  The material covers homemade solutions, as well as purchased kits
> and turnkey solutions.  Maybe, a group of interested GRC/SDR enthusiasts can
> collect and publish a few example systems as starters for those who want to
> experiment in this area.
> 

One thing that arises with SDR is that we will see more people in this
field who have software and DSP knowledge but slightly less hardware
knowledge than the traditional ham.

That is why I keep coming back to the idea of listing some off-the-shelf
solutions on the wiki.

> The second aspect of the "solutions" question asks if there are suitable GRC
> DSPs as starters, at least.  With Lou's help, I have authored a library of
> transceiver DSPs for all of the commonly used HF transmission modes.  The
> GRC DSPs are  'ham friendly' in the sense that they implement functional,
> ordinary and familiar transceiver interfaces.  However, I have no easy means
> to publish the DSP's.  Would collecting and publishing GRC DSPs be helpful
> at addressing your "solutions" question?  If so, what is the best approach
> for maximum visibility to the experimenter community?
> 

It could be interesting to look at how gqrx is being produced and then
packaged in the Debian world and try to get your designs delivered in a
similar way.

Somebody on Debian or Ubuntu can just do

   $ sudo apt-get install gqrx-sdr

and they get everything installed automatically.

> Last but not least, a third issue for communication system functionality, is
> to use the GRC GUI to control the auxiliary functions of an HF transmitter,
> e.g. transmit / receiver relay.  I do not know of a means to access the GPIO
> from the GRC GUI.  My present solution is to use current from the USRP
> transmit or receive LED signal to control external equipment via a relay
> system.  Maybe someone can publish a different solution.
>

There are actually two approaches:

- sensing: the hardware key activates the transmitter and power amp
directly and the GUI is able to sense this transition somehow, through
some input connector

- managed: the hardware key (possibly a joystick button) sends a signal
to the GUI application and the application then sends some control
signal through the GPIO or similar hardware to activate the transmitter
circuits

This type of thing is not too hard with Python and C++ code.

If the flow graph is running in an embedded device like a Raspberry Pi
then it has its own GPIO pins too.

Regards,

Daniel

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

Re: [Discuss-gnuradio] Pybombs install fetch fail

[Martin Braun]

I've changed the recipe in the repo. FYI, PyBOMBS doesn't use FTP, but
whatever Python requests uses.

M

On 04/08/2016 09:35 AM, Kevin Hofschröer wrote:
> Actually, I often ran into the same problem myself. When you try to browse 
> this link with the browser or through normal command line operation, you will 
> have the same effect.
> You can replace that recipe line with
> "wget+http://download.qt.io/archive/qt/4.6/qt-everywhere-opensource-src-4.6.2.tar.gz";
> and then retry the pybombs install command.
> 
> Greetings
> Kevin
> 
> ___
> 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 install fetch fail

[Martin Braun]

...I pushed the changes not realizing Sebastian had already submitted a
PR and Chris had merged it. Thanks guys!

M

On 04/08/2016 12:56 PM, Martin Braun wrote:
> I've changed the recipe in the repo. FYI, PyBOMBS doesn't use FTP, but
> whatever Python requests uses.
> 
> M
> 
> On 04/08/2016 09:35 AM, Kevin Hofschröer wrote:
>> Actually, I often ran into the same problem myself. When you try to browse 
>> this link with the browser or through normal command line operation, you 
>> will have the same effect.
>> You can replace that recipe line with
>> "wget+http://download.qt.io/archive/qt/4.6/qt-everywhere-opensource-src-4.6.2.tar.gz";
>> and then retry the pybombs install command.
>>
>> Greetings
>> Kevin
>>
>> ___
>> 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] Ubunto 15.04 (right off the .iso) recipe for success

[Martin Braun]

I wrote 90% of PyBOMBS 2 on 15.10. That distro is least likely to fail.

M

On 04/07/2016 07:03 PM, Gregory W. Ratcliff wrote:
> Greetings,
> 
> Has anyone gone start to finish with  64 bit, desktop, 15.04, new pip
> and pybombs 2+. ?
> 
> I would like to get back to enjoying gnuradio as quickly as possible.
> 
> Thank you,
> 
> Mr. Lazy.
>  
> Gregory W. Ratcliff
> 
> 
> 
> 
> 
> 
> 
> ___
> 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] [Docker] New GNU Radio images with GUI support

[Stefan Wunsch]

Keep in mind the automated build service of hub.docker.com! For those
who don't know how it works:
It is connected to the github repo and rebuilds after each new commit
the needed images (or layers) automatically.
As well, it would be possible to build automatically images for each
release of gnuradio using different tags (and the 'latest' tag for the
current head).

This would allow developers to alter the official image with their
specific programs (e.g., OOTs) with the commit function of docker and
push the image back on hub.docker.com using their own account. Then,
everyone could test their application without thinking about
dependencies or sth else (and this on linux, mac and windows!).

E.g., you have a demo application running at the lab in university or
for clients at a company. Just spawn the container from the image you
have done before and you can be sure it's running fine.

I think that docker is really convenient (and it is super popular atm!).

Greetings
Stefan


On 04/08/2016 05:21 PM, Johnathan Corgan wrote:
> On Fri, Apr 8, 2016 at 6:12 AM, Ben Hilburn  > wrote:
>  
> 
> It seems like Docker could make it much easier for us to support a
> variety of operating systems - although the user would still need to
> install Docker, itself. Presumably that's easier than earlier
> containerized models, though (e.g., VMs).
> 
> 
>  
> I've been doing a lot of behind-the-scenes work with GNU Radio and
> docker recently, mostly to beef up our automated test infrastructure.
> 
> There are a number of different use cases that overlap.  One is testing,
> as mentioned.  Another is "full installation of all GNU Radio, dev
> tools, and related items to do complete application development."  Yet a
> third is "minimal set of packages needed to execute a given GNU Radio
> application."
> 
> I'm working out a stratification of layers that build on one another,
> starting with an OS base layer, one adding minimal runtime packages,
> then adding minimum build time packages, then a full development layer.
> 
> I caution, though, the containers are not the answer to everything, and
> it's at least questionable whether providing a full dev environment as a
> container is useful to beginners.  There's enough work required
> "outside" the container (permissions, volumes, device mappings,
> networking config) that the user will still need to understand the
> internals of Docker before becoming productive.
> 
> That said, I'm very interested in feedback on what the community feels
> is useful vs. my own perceptions.
> 
> -Johnathan
>  

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

[Discuss-gnuradio] error msg of hardware not supporting the requested RX frequency

[Vinit Shah]

Dear all,
I am a beginner in Linux and So far I have successfully installed gnuradio
and hardware dependencies.
The very basic program which is just connecting usrp source with WX gui fft
sink is not working correctly.
I am getting following error messaege

linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.005.005-0-unknown

Using Volk machine: sse4_2_64_orc
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes

UHD Warning:
Unable to set the thread priority. Performance may be negatively
affected.
Please see the general application notes in the manual for instructions.
EnvironmentError: OSError: error in pthread_setschedparam

UHD Warning:
The hardware does not support the requested RX frequency:
Target frequency: 97.90 MHz
Actual frequency: -2.10 MHz

>>> Done

My daughter board has range up to 250 Gigs... but I do not know why even
with 10 M sampling frequency my system is aliasing ??
This is a common problem I found on internet but no effective solution so
far, I think.
Any help would be highly appreciated.
I request you please explain explicitly because I am novice in this field(
with linux), and if possible with example..??

Thank you very much in advance
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] pybombs install fetch fail

[Chris Kuethe]

Thanks for the report. The issue has been corrected in
https://github.com/gnuradio/gr-recipes/commit/f813f4a210ccae91ffe0a907ae24da69f4877fb6#diff-bba2064f54ef357a8407fe54e2d30ee3

On Fri, Apr 8, 2016 at 8:59 AM, Freedomfighter099 .
 wrote:
> I’ve just double checked and the program FTP on Ubuntu is installed and up
> to date.
>
> Furthermore yesterday I installed the gnuradio on a virtual machine through
> pybombs with no problems.
>
> It seems that package gt4 is not able to be downloaded through the above
> following FTP links which is strange, I these FTP addresses correct?
>
> Or is pybombs attempting to fetch from a dead link?
>
> Any suggestions would be appreciated
>
>
> ___
> 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] error msg of hardware not supporting the requested RX frequency

[Derek Kozel]

Hello Vinit,

This question is much more about UHD so I'm adding the usrp-users mailing
list [1].

There is no USRP daughterboard which goes to 250 GHz so I assume you mean
250 MHz which would point towards the BasicRx daughterboard. This
daughterboard has no mixer and so the N200 will use aliasing to receive
non-baseband signals. The N200's ADC runs at 100 MSPS, but Gigabit Ethernet
isn't able to transport that much data so it is always decimated by some
factor. This means that a target frequency of 97.9 MHz (A good choice for a
first test) is in a higher Nyquist band. What you're seeing is correct
behaviour.


UHD 3.5.5 is very old and I'd recommend removing the current version and
install a newer release. I would guess that you are on Ubuntu 14.04 and
installed it using apt. If you are very unfamiliar with Linux and don't
have anyone locally who you could get some assistance from it's worth
considering using the GNU Radio Live Environment [2] which can be written
to a USB drive and booted from. This comes with up to date versions of GNU
Radio and UHD, as well as a variety of additional SDR related packages.

You can also look at PyBOMBS[3] or the build-gnuradio [4] script, either of
which will install the latest UHD and GNU Radio.

Regards,
Derek

[1] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[2] https://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioLiveDVD
[3] https://github.com/gnuradio/pybombs/
[4]
https://gnuradio.org/redmine/projects/gnuradio/wiki/InstallingGRFromSource#Using-the-build-gnuradio-script

On Fri, Apr 8, 2016 at 1:12 PM, Vinit Shah  wrote:

> Dear all,
> I am a beginner in Linux and So far I have successfully installed gnuradio
> and hardware dependencies.
> The very basic program which is just connecting usrp source with WX gui
> fft sink is not working correctly.
> I am getting following error messaege
>
> linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.005.005-0-unknown
>
> Using Volk machine: sse4_2_64_orc
> -- Opening a USRP2/N-Series device...
> -- Current recv frame size: 1472 bytes
> -- Current send frame size: 1472 bytes
>
> UHD Warning:
> Unable to set the thread priority. Performance may be negatively
> affected.
> Please see the general application notes in the manual for
> instructions.
> EnvironmentError: OSError: error in pthread_setschedparam
>
> UHD Warning:
> The hardware does not support the requested RX frequency:
> Target frequency: 97.90 MHz
> Actual frequency: -2.10 MHz
>
> >>> Done
>
> My daughter board has range up to 250 Gigs... but I do not know why even
> with 10 M sampling frequency my system is aliasing ??
> This is a common problem I found on internet but no effective solution so
> far, I think.
> Any help would be highly appreciated.
> I request you please explain explicitly because I am novice in this field(
> with linux), and if possible with example..??
>
> Thank you very much in advance
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Pybombs install fetch fail

[Marcus Müller]

Adding what I know
python requests is a pure HTTP library; it really can't do FTP at all.
You could write or install a FTP protocol adapter for it… and instead,
Chris went ahead and simply found HTTP sources for all four recipes
depending on FTP.
The awesome thing was that we realized that the source lines of the form:

source: wget+http://…

contains some redundancy.
As the pybombs source fetchers define regexes that match different kinds
of URLs, we just went ahead and removed all the explicit "wget+" from
the recipes in gr-recipes.

So if you happen to be writing recipes: I think it'd be cooler if you
just used

source: http://theserver/file.tar.gz

instead of the "oldschool"

source: wget+http://theserver/file.tar.gz

(which, by the way, continues to work).

Cheers,
Marcus

On 08.04.2016 22:00, Martin Braun wrote:
> ...I pushed the changes not realizing Sebastian had already submitted a
> PR and Chris had merged it. Thanks guys!
>
> M
>
> On 04/08/2016 12:56 PM, Martin Braun wrote:
>> I've changed the recipe in the repo. FYI, PyBOMBS doesn't use FTP, but
>> whatever Python requests uses.
>>
>> M
>>
>> On 04/08/2016 09:35 AM, Kevin Hofschröer wrote:
>>> Actually, I often ran into the same problem myself. When you try to browse 
>>> this link with the browser or through normal command line operation, you 
>>> will have the same effect.
>>> You can replace that recipe line with
>>> "wget+http://download.qt.io/archive/qt/4.6/qt-everywhere-opensource-src-4.6.2.tar.gz";
>>> and then retry the pybombs install command.
>>>
>>> Greetings
>>> Kevin
>>>
>>> ___
>>> 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] [VOLK] Release v1.2.2 - Build fixes!

[Nathan West]

Hi all,

VOLK v1.2.2 is available and the GNU Radio submodule pointer currently
points to this release.

Release notes: http://libvolk.org/release-v122.html
Raw form for maintainers that like such things:
http://libvolk.org/news_raw/release-1.2.2.md
Tarball: http://libvolk.org/releases/volk-1.2.2.tar.gz
Md5sum of tarball: 540e2c55e525c04920e0e63d0de530b3

Contributors

   - Jaroslav Škarvada jskar...@redhat.com
   - Nathan West nathan.w...@okstate.edu
   - Paul Cercueil paul.cercu...@analog.com
   - gnieboer gnieb...@corpcomm.net

Changes

This is a maintenance release the primarily addresses build issues,
primarily for MSVC. Additionally, this fixes an issue when building as a
sub-project of GNU Radio with cmake versions >= 3.5


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

[Discuss-gnuradio] GR-RADAR - TEST FMCW ON HARDWARE

[Giovanni Bengalis]

Hi Stefan,

I'm Giovanni,actually I'm working on my last engineering project for
university , I'm trying to implement an altimeter radio with SDR like USRP
N210 or PicoDigitizer 250.
I need your help , actually the simulation works very well , so I can
simulate the FMCW with a bandwidth of 40 MHz . When I removed the static
target simulator and add
a USRP Source to receive the signal by antenna , the range printed is
random. I used a USRP N210.


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

Re: [Discuss-gnuradio] GR-RADAR - TEST FMCW ON HARDWARE

[Marcus Müller]

Well, there's more than a USRP source to a radar; how did you configure
that? How are you transmitting your FMCW signal? What are your RF
settings, what is your antenna, what's your radar target?

Best,
Marcus


On 08.04.2016 23:51, Giovanni Bengalis wrote:
> Hi Stefan, 
>
> I'm Giovanni,actually I'm working on my last engineering project for
> university , I'm trying to implement an altimeter radio with SDR like
> USRP N210 or PicoDigitizer 250. 
> I need your help , actually the simulation works very well , so I can
> simulate the FMCW with a bandwidth of 40 MHz . When I removed the
> static target simulator and add
> a USRP Source to receive the signal by antenna , the range printed is
> random. I used a USRP N210.
>
>
> Sincerely,
> Giovanni B.
>
>
> ___
> 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 install fetch fail

[Martin Braun]

The only problem here is that we have a fetcher called 'wget' which is
actually a badly chosen name for 'a python requests fetcher for tarballs
over http'.

So please, leave the wget+ in source URLs if they point to tarballs, and
sorry for the name 'wget'. I'll blame PyBOMBS 1 code :)

M


On 04/08/2016 02:21 PM, Marcus Müller wrote:
> Adding what I know
> python requests is a pure HTTP library; it really can't do FTP at all.
> You could write or install a FTP protocol adapter for it… and instead,
> Chris went ahead and simply found HTTP sources for all four recipes
> depending on FTP.
> The awesome thing was that we realized that the source lines of the form:
> 
> source: wget+http://…
> 
> contains some redundancy.
> As the pybombs source fetchers define regexes that match different kinds
> of URLs, we just went ahead and removed all the explicit "wget+" from
> the recipes in gr-recipes.
> 
> So if you happen to be writing recipes: I think it'd be cooler if you
> just used
> 
> source: http://theserver/file.tar.gz
> 
> instead of the "oldschool"
> 
> source: wget+http://theserver/file.tar.gz
> 
> (which, by the way, continues to work).
> 
> Cheers,
> Marcus
> 
> On 08.04.2016 22:00, Martin Braun wrote:
>> ...I pushed the changes not realizing Sebastian had already submitted a
>> PR and Chris had merged it. Thanks guys!
>>
>> M
>>
>> On 04/08/2016 12:56 PM, Martin Braun wrote:
>>> I've changed the recipe in the repo. FYI, PyBOMBS doesn't use FTP, but
>>> whatever Python requests uses.
>>>
>>> M
>>>
>>> On 04/08/2016 09:35 AM, Kevin Hofschröer wrote:
 Actually, I often ran into the same problem myself. When you try to browse 
 this link with the browser or through normal command line operation, you 
 will have the same effect.
 You can replace that recipe line with
 "wget+http://download.qt.io/archive/qt/4.6/qt-everywhere-opensource-src-4.6.2.tar.gz";
 and then retry the pybombs install command.

 Greetings
 Kevin

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

[Marcus Müller]

I just realized that what I've written was stupid, and a bad thing to
do, for a host of reasons, among these that the fetcher's autodection by
now only works for URLs like
http(s):///something.tar.gz
which isn't every possible source.
SO: Please don't heed my wrong approach, and keep the "wget+" at the
beginning of your http-sources.

On 08.04.2016 23:21, Marcus Müller wrote:
> Adding what I know
> python requests is a pure HTTP library; it really can't do FTP at all.
> You could write or install a FTP protocol adapter for it… and instead,
> Chris went ahead and simply found HTTP sources for all four recipes
> depending on FTP.
> The awesome thing was that we realized that the source lines of the form:
>
> source: wget+http://…
>
> contains some redundancy.
> As the pybombs source fetchers define regexes that match different kinds
> of URLs, we just went ahead and removed all the explicit "wget+" from
> the recipes in gr-recipes.
>
> So if you happen to be writing recipes: I think it'd be cooler if you
> just used
>
> source: http://theserver/file.tar.gz
>
> instead of the "oldschool"
>
> source: wget+http://theserver/file.tar.gz
>
> (which, by the way, continues to work).
>
> Cheers,
> Marcus
>
> On 08.04.2016 22:00, Martin Braun wrote:
>> ...I pushed the changes not realizing Sebastian had already submitted a
>> PR and Chris had merged it. Thanks guys!
>>
>> M
>>
>> On 04/08/2016 12:56 PM, Martin Braun wrote:
>>> I've changed the recipe in the repo. FYI, PyBOMBS doesn't use FTP, but
>>> whatever Python requests uses.
>>>
>>> M
>>>
>>> On 04/08/2016 09:35 AM, Kevin Hofschröer wrote:
 Actually, I often ran into the same problem myself. When you try to browse 
 this link with the browser or through normal command line operation, you 
 will have the same effect.
 You can replace that recipe line with
 "wget+http://download.qt.io/archive/qt/4.6/qt-everywhere-opensource-src-4.6.2.tar.gz";
 and then retry the pybombs install command.

 Greetings
 Kevin

 ___
 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] IEEE 802.11 Transmitter in X310s

[Abhinav Jadon]

Hi,
My setup consists of two X310s - one transmitter and one receiver -
connected with SMA cable.
The receiver code has been independently tested by capturing the AP packets.
The transmitter code was tested in a software loopback with the receiver.
The gains on both sides were adjusted such that  there was no clipping.
attenuator (-10db) were used to connect the two USRPs over SMA link.

The transmitter transmits the packet but at the receiver end, these packets
are not successfully decoded. A deeper look reveals that for a high
correlation value (0.8) , packets are being detected by the packet
detection mechanism but the signal field is decoded wrongly in all the
packets detected. . Since unit testing of every block was successful, it
was my hypothesis that the source of error lies on the transmitter-hardware
side.

I began scraping thorough the mail archives and got hold of this :
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-September/015576.html

This thread details on the problem related to burst transmissions in X310.
Apparently, the successive bursts are not same - the end of first burst is
appended to the second burst.

I don't have the hardware to verify the claim, but assuming that it is
correct. It still doesn't explain the wrong decoding of the signal field.

What am I missing ?



Abhinav PS  Jadon
2012122
Electronics and Communication Engineering Undergraduate
IIIT - Delhi
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] gr-ieee-802154 sample configuration

[Todd Lutton]

Basic question -


Installed gr-ieee-802154 using pyBombs, and correctly built all samples.

Currently focused on transceiver_CSS_USRP.grc


Two laptops, each w/ Ettus N210;  enable wireshark connector & files sink on 
both

Laptop 1:

  - set socket PDU as UDP server

  - set USRP Source & Sink IP as .10.4 (to match connected USRP)

  - Change text_msg to alphabet

Laptop 2:

 - set socket PDU as UDP Client

  - set USRP Source & Sink IP as .10.2 (to match connected USRP)

  - Change text_msg to numbers


Start flowgraph on both laptops and monitor /tmp/sensor.pcap

 - channels are same

 - from wire shark only see self generated message, it doesn't look like any 
message is xmt/rcv from Laptop 2 to 1


I'm sure this is simple, but what configuration setting am I missing?

Thanks


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

Re: [Discuss-gnuradio] GR-RADAR - TEST FMCW ON HARDWARE

[Stefan Wunsch]

Hi,

Try to use the echotimer shipped with gr-radar. Actually, for FMCW you
don't need a tight TX/RX sync, but probably that fixes it.

As well, have a look at the spectrum and check the output of the peak
detector. Do you have a high enough SNR for an unambigious peak
detection? Or you are just detecting clutter? If you are just detection
clutter, it could look like random targets.

Furthermore, have a look at grradar.wordpress.com and the videos showing
the setup of the Dual CW/FSK radars. Probably that helps you too.

Greetings
Stefan

On 04/08/2016 11:51 PM, Giovanni Bengalis wrote:
> Hi Stefan, 
> 
> I'm Giovanni,actually I'm working on my last engineering project for
> university , I'm trying to implement an altimeter radio with SDR like
> USRP N210 or PicoDigitizer 250. 
> I need your help , actually the simulation works very well , so I can
> simulate the FMCW with a bandwidth of 40 MHz . When I removed the static
> target simulator and add
> a USRP Source to receive the signal by antenna , the range printed is
> random. I used a USRP N210.
> 
> 
> Sincerely,
> Giovanni B.
> 
> 
> ___
> 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-RADAR - TEST FMCW ON HARDWARE

[Giovanni Bengalis]

Hi marcus,

Thank for your help.
Actually my parameters are :

   - sample rate is 40 MHz
   - center frequency 4.3 GHz
   - Sweep frequency 20 MHz
   - Samp UP= Samp Down= 65536
   - Samp CW = 16 384
   - USRP N210 with SBX 400MHz to 4400MHz
   - Antenna boeing 767 for Altimeter Radio

Sink : gain 10 dB , TX/RX
Source : gain 10dB , RX2

For transmitting FMCW , I use the toolbox of stefan  USRP Sink .
Here the flowgraph + configuration

http://screenpresso.com/=4tfSb

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