Re: [Discuss-gnuradio] B2xx rates

[Ralph A. Schmid, dk5ras]

61.44 MHz with the latest UHD stuff.

Ralph.

> -Original Message-
> From: Discuss-gnuradio [mailto:discuss-gnuradio-
> bounces+ralph=schmid@gnu.org] On Behalf Of Ron Economos
> Sent: Wednesday, April 13, 2016 4:56 PM
> To: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] B2xx rates
> 
> Correction. The master clock rate can be set to anything from 5 MHz to
> 56 MHz. The bandwidth is 200 kHz to 56 MHz.
> 
> Ron
> 
> On 04/13/2016 07:46 AM, Ron Economos wrote:
> > The B2X0 series has a programmable master clock. You can set it to
> > anything from 200 kHz to 56 MHz.
> >
> > Ron
> >
> > On 04/13/2016 05:55 AM, Alexander Levedahl wrote:
> >> Hello,
> >>
> >> Is there a list of sample rates and associated bandwidths supported
> >> by the B2xx series or a way to generate the list? E.g., the list for
> >> the X310 is to take 120MHz, 184.32MHz, and 200MHz and divide by an
> >> integer.
> >>
> >> Thanks,
> >> Alex
> >>
> >
> 
> 
> ___
> 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] Question about packet sequence

[Marcus Müller]

SangHyuk,

I'm really getting desparate.
The fact that your application generates 400B over-the-air packets has
*nothing* to do with the size of the sample packets going through
Ethernet. Stop assuming that.
> I expected one send() be represented one packet at wireshark.
You should not expect that. send() can, and will, fragment your data.
See the documentation[1] that explicitely explains that:
>
> Send buffers containing samples described by the metadata.
>
> Send handles fragmentation as follows: If the buffer has more items
> than the maximum per packet, the send method will fragment the samples
> across several packets. Send will respect the burst flags when
> fragmenting to ensure that start of burst can only be set on the first
> fragment and that end of burst can only be set on the final fragment.
>
So, to answer the question you've been asking several times, and got the
same answer every time:
> Why does number of packet shown in wireshark is differ from
> transmitted packets ?
Because what you consider "packets" has *nothing* to do with what
wireshark sees as network packets.

Best regards,
Marcus

[1]
http://files.ettus.com/manual/classuhd_1_1tx__streamer.html#aeb2e0f44810693d9da99ea1e04fad21f
On 14.04.2016 08:46, SangHyuk Kim wrote:
> Hi,
>
> I counted number of sending packet in code and wireshark.
>
> I send 400Bytes packet, but wireshark packet be shown about 1500Bytes.
>
> While coded counter shows about 50,000 packets (data packet),
> wireshark captured 450,000 packets.
>
> I expected one send() be represented one packet at wireshark.
>
> Why does number of packet shown in wireshark is differ from
> transmitted packets ?
>
> Thanks for your help.
>
> 2016-04-14 15:20 GMT+09:00 Laur Joost  >:
>
> While UDP gives no order guarantee, the USRP still sends them out
> in order. The uncertainty comes in cases where routing happens
> between the USRP and the host. Still, within a LAN you can expect
> with relative certainty, that packets will still arrive in order,
> as there is usually only one route from device to host.
>
> 1. The sequence of the packets is important. It would be rather
> bad if two bunches of samples in your IQ stream suddenly switched
> places.
> 2. The host PC network stack does no reordering. It can't, by
> definition of UDP, as there's nothing to reorder by.
> 3. AFAIK, the UHD also does no reordering. However, the packets
> arriving from the USRP __are__ numbered. If UHD detects a missing
> packet, it* prints a D (to signify a Dropped packet) to stdout,
> and emits a new rx_time tag for the next packet.
>
> * Actually, I don't know whether that's UHD or gr-uhd that does this.
>
> Hope it helped
> Laur
>
> 2016-04-14 8:41 GMT+03:00 SangHyuk Kim  >:
>
> Hi all,
>
> I'm wondering about packet sequence.
>
> USRP sends UDP packets which is result of sampling to host PC.
>
>
> UDP packets tend to be out-of-order at high speed.
>
> My question is:
> - When USRP sends UDP packet high speed to host PC, the
> sequence of these packets is important ?
> - Do host PC reorder these packet ? (Do PC waits for certain
> packet ?)
>
> 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] raspi FAQ/HOWTO/recipe ??????

[Marcus Müller]

Hi Rob,

first feeling: make sure you've actually got enough RAM on your Pi; the
"VOLK: Error allocating memory" errors are kind of unusual.

Best regards,
Marcus

On 13.04.2016 13:45, Rob Roschewsk wrote:
>
> Marcus,
>
> Thanks for responding.
>
> I'm looking to build a headless FM receiver to record and stream
> public service communication (fire, police, etc.). We will stream as
> many channels as possible that fall into a given passband.
>
> I already have a system running on a PC and now would like to port it
> to the PI.
>
> I understand it maybe an "up hill" path, but the thought is to deploy
> multiple inexpensive units around a geographic area all feeding a
> central streaming server.
>
> The Pi is running Raspian Jesse  I started with the distribution
> packages but ran into problems right out of the blocks and thought it
> would be best to use the latest code before asking questions :)
>
> I understand cross compiling is the way to go.
>
> Since I brought it up, here was the error I saw when I tried to run
> the script that runs on the PC but fails spectacularly on the
> raspberry pi with the precompiled packages 
>
> roschews@raspberrypi:~/sdr/multirx $ ./multirx_nogui.py
>  -s 49 noaa.xml
> linux; GNU C++ version 4.9.1; Boost_105500; UHD_003.007.003-0
> -unknown
>
> high=16250 low=16240 span=10
> center=16245
> gr-osmosdr 0.1.3 (0.1.3) gnuradio 3.7.5
> built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf
> bladerf rfspace airspy
> Using device #0 Realtek RTL2838UHIDIR SN: 0108
> Found Elonics E4000 tuner
> Exact sample rate is: 100 .026491 Hz
> Using Volk machine: generic_orc
> VOLK: Error allocating memory (posix_memalign: 22)
> VOLK: Error allocating memory (posix_memalign: 22)
> VOLK: Error allocating memory (posix_memalign: 22)
> Segmentation fault
>
>
>
> ___
> 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] 3.7.9.2 Win64 binaries ready + Build scripts

[Geof Nieboer]

All,

Some may recall in the fall I posted a link to a beta windows installer.
I'm happy to report that I'm releasing new versions today for the 3.7.9.2
release, compatible with Windows 7/8/10.  All dependencies are included,
and all are built natively using MSVC 2015, no Cygwin or MinGW required.
It's about a 300MB package download.

I've also refactored the entire build process used to make the msi's and
gotten it down to a series of Powershell scripts that can either:
1- Build the entire GNURadio windows dependency chain from source and then
build GNURadio itself.
2- Download a prebuilt "dependency pack" as binaries and then
build GNURadio and a couple OOT modules

The binaries (for both GR and the dependencies) can be found at
http://www.gcndevelopment.com/gnuradio.  The scripts themselves are hosted
at http://github.com/gnieboer/gnuradio_windows_build_scripts.  While the
binaries have no dependencies, the build scripts have several, but all
mandatory dependencies are free to install.  The various patches required
to make everything build on Win32/MSVC are either workarounds built into
the scripts, patches downloadable on the website, or forked repos on my
github account.  For the most part pull requests have been submitted
upstream.

All GR components except gr-comedi are installed, and several OOT blocks
are also included by default, including UHD 3.9.3, gr-fosphor,
and gr-osmosdr with most drivers.  The windows audio sink has also been
refactored to double buffer to avoid the skipping others have reported.

It uses OpenBLAS for numpy/scipy to stay GPLv3 compliant...users can
replace it with an MKL-based version as a wheel from the downloads page
should more performance be desired.

More information is available on the website.  I hope both the binaries and
scripts are useful and look forward to feedback.

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

Re: [Discuss-gnuradio] Read file metadata

[Tom Rondeau]

On Thu, Apr 14, 2016 at 7:44 AM, Yan Huang  wrote:

> Hi all,
>
>
>
> I’m using Message Strobe to control UHD: USRP Source to receive signal
> with specified frequency(2.4GHz), but I find flow graph start running
> before Message Strobe set the frequency as 2.4 GHz.
>
>
>
> Message Strobe -> UHD: USRP Source ->File Sink
>
>
>
> So I want to use stream tag to know the time of first item with 2.4GHz. I
> think I can change File Sink to File Meta Sink to receive the ‘rx_time’
> stored in ‘tag_sense1.hdr’ file(attached), and I use the existing program
> called ‘gr_read_file_metadata’ to read out the header information, but it
> comes out an error:
>
>
>
> File "tag_sense1.hdr", line 1
>
> SyntaxError: Non-ASCII character '\xb5' in file tag_sense1.hdr on line 2,
> but no encoding declared; see http://www.python.org/peps/pep-0263.html
> for details
>
>
>
> I have checked the link, but I don’t understand what’s the encoding
> information of the python source file. Do need to add # -*- coding:
>  -*- to the source file?
>
>
>
> I problems are:
>
>
>
> 1.   How can I read the’ .hdr’ file?
>
> 2.   Am I right to use file meta sink to get the start receiving time?
>
> 3.   Do I need to add stream tag and then read it out using other
> blocks in this scenario?
>
>
>
> Any advice will be appreciated. Many thanks in advance.
>
>
>
> Best Regards,
>
>
>
> Yan
>


Yan,

Have you fully read over the description of the metadata files and how to
use them in the manual?

http://gnuradio.org/doc/doxygen/page_metadata.html

Specifically, since you have a .hdr file, you've set this into Detached
mode. You'll need to use the -D flag to indicate that to
gr_read_file_metadata.

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

Re: [Discuss-gnuradio] [GRC] Print samples when saving screenshot

[Tom Rondeau]

On Tue, Apr 12, 2016 at 4:55 PM, Merlin Chlosta <
merlin.chlosta+gnura...@ruhr-uni-bochum.de> wrote:

> Hi all,
>
> GRC is very handy and so is the screenshot function. It's much faster to
> take a screenshot than to record all data and plot it afterwards. However I
> found myself taking a lot of screenshots twice because e.g. the label was
> wrong. Also the plots did not meet my requirements for printing, so I had
> to go for the record-everything-method anyway.
>
> I think GRC could print out the samples when saving a screenshot. You'll
> then have 1. a fast tool to snapshot your signals and 2. accurate data in
> case you need further analysis or different plot style.
>
> I hacked this into the gr-qtgui code, see below. Any comments on this? I'm
> pretty sure it's not done right.
>
> What do you think of this feature? Does this already exist and I did not
> find it?
>
> --Merlin Chlosta
>

Merlin,

I'm certainly not opposed to this idea. Would you create a pull request
against https://github.com/gnuradio/gnuradio? It's much easier for us to
track and trade ideas on features like this in that forum rather than email.

See this page for information on that if you're not familiar with that
process:
http://gnuradio.org/redmine/projects/gnuradio/wiki/Development


I also want to point out the QTGUI Theme concept we now have. In GRC, you
can set the theme on a per-flowgraph basis by setting the QSS Theme line in
the flowgraph's Options block. Or you can do it globally by making a theme
the default by going to Tools -> Set Default QT GUI Theme.

Themes are located in $prefix/share/gnuradio/themes

The one I want to point you towards specifically is "projector.qss" which
we put together during the last GRCon15 hackfest to make the lines and
fonts large enough to show results on a projector. It also helps when
saving files for later use in papers/presentations.

Tom




> ---
> commit 5df55a2ec563002161d43cca53aad119a32a38f2
> Author: Merlin Chlosta 
> Date:   Tue Apr 12 22:41:37 2016 +0200
>
> DisplayForm: Print samples when saving screenshot
>
> diff --git a/gr-qtgui/include/gnuradio/qtgui/DisplayPlot.h
> b/gr-qtgui/include/gnuradio/qtgui/DisplayPlot.h
> index eba12e2..1e946f8 100644
> --- a/gr-qtgui/include/gnuradio/qtgui/DisplayPlot.h
> +++ b/gr-qtgui/include/gnuradio/qtgui/DisplayPlot.h
> @@ -127,6 +127,8 @@ public:
>
>virtual void replot() = 0;
>
> +  std::vector d_plot_curve;
> +
>const QColor getLineColor1 () const;
>const QColor getLineColor2 () const;
>const QColor getLineColor3 () const;
> @@ -284,7 +286,6 @@ protected slots:
>
>  protected:
>int d_nplots;
> -  std::vector d_plot_curve;
>
>QwtPlotPanner* d_panner;
>QwtPlotZoomer* d_zoomer;
> diff --git a/gr-qtgui/include/gnuradio/qtgui/displayform.h
> b/gr-qtgui/include/gnuradio/qtgui/displayform.h
> index 1da1383..c23067a 100644
> --- a/gr-qtgui/include/gnuradio/qtgui/displayform.h
> +++ b/gr-qtgui/include/gnuradio/qtgui/displayform.h
> @@ -30,6 +30,7 @@
>
>  #include 
>  #include 
> +#include 
>
>  #include 
>  #include 
> diff --git a/gr-qtgui/lib/displayform.cc b/gr-qtgui/lib/displayform.cc
> index 13c2d8a..3f78502 100644
> --- a/gr-qtgui/lib/displayform.cc
> +++ b/gr-qtgui/lib/displayform.cc
> @@ -359,6 +359,17 @@ DisplayForm::saveFigure()
>  {
>QPixmap qpix = QPixmap::grabWidget(this);
>
> +  std::vector plot_curve = getPlot()->d_plot_curve;
> +
> +  std::cout << "Screenshot:" << std::endl;
> +  for (int plot = 0; plot < plot_curve.size(); plot++) {
> +std::cout << "Plot curve #" << plot << std::endl;
> +for (int i = 0; i < plot_curve[plot]->dataSize(); i++) {
> +  std::cout << plot_curve[plot]->y(i) << ", ";
> +}
> +std::cout << std::endl;
> +  }
> +
>QString types = QString(tr("JPEG file (*.jpg);;Portable Network
> Graphics file (*.png);;Bitmap file (*.bmp);;TIFF file (*.tiff)"));
>
>QString filename, filetype;
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] 3.7.9.2 Win64 binaries ready + Build scripts

[Tom Rondeau]

On Thu, Apr 14, 2016 at 6:23 AM, Geof Nieboer  wrote:

> All,
>
> Some may recall in the fall I posted a link to a beta windows installer.
> I'm happy to report that I'm releasing new versions today for the 3.7.9.2
> release, compatible with Windows 7/8/10.  All dependencies are included,
> and all are built natively using MSVC 2015, no Cygwin or MinGW required.
> It's about a 300MB package download.
>
> I've also refactored the entire build process used to make the msi's and
> gotten it down to a series of Powershell scripts that can either:
> 1- Build the entire GNURadio windows dependency chain from source and then
> build GNURadio itself.
> 2- Download a prebuilt "dependency pack" as binaries and then
> build GNURadio and a couple OOT modules
>
> The binaries (for both GR and the dependencies) can be found at
> http://www.gcndevelopment.com/gnuradio.  The scripts themselves are
> hosted at http://github.com/gnieboer/gnuradio_windows_build_scripts.
> While the binaries have no dependencies, the build scripts have several,
> but all mandatory dependencies are free to install.  The various patches
> required to make everything build on Win32/MSVC are either workarounds
> built into the scripts, patches downloadable on the website, or forked
> repos on my github account.  For the most part pull requests have been
> submitted upstream.
>
> All GR components except gr-comedi are installed, and several OOT blocks
> are also included by default, including UHD 3.9.3, gr-fosphor,
> and gr-osmosdr with most drivers.  The windows audio sink has also been
> refactored to double buffer to avoid the skipping others have reported.
>
> It uses OpenBLAS for numpy/scipy to stay GPLv3 compliant...users can
> replace it with an MKL-based version as a wheel from the downloads page
> should more performance be desired.
>
> More information is available on the website.  I hope both the binaries
> and scripts are useful and look forward to feedback.
>
> Geof
>


Great work, Geof!

Thanks for handling this so carefully and completely and for sharing your
results!

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

Re: [Discuss-gnuradio] Docker

[Ben Hilburn]

Having almost no experience with Docker myself, I unfortunately don't have
much in the way of worthwhile technical input on this.

That said, I really do want to encourage this conversation. Installation of
GNU Radio on one machine can be a pain for many people, and doing it on
many machines over a network can be extremely difficult. I'm very
interested in what Docker could do for us in terms of accessibility and
administration.

Cheers,
Ben

On Wed, Apr 13, 2016 at 2:31 PM, Nicholas McCarthy 
wrote:

> Sorry I'm a few days late to the Docker party (and I don't have the
> original thread at hand).
>
> Thanks, Stefan, for sharing your work.  I want to share something similar
> I worked up for my stack when Martin released pybombs2 and exposed me to
> the "deploy" function.
>
> https://hub.docker.com/r/namccart/pybombs
> https://hub.docker.com/r/namccart/pybombs-dev
>
> All the stuff is on github, including a grc docker using the local X11
> setup (as Jonathan described) with this pybombs install image.
>
> https://github.com/namccart/docker_grc.git
>
> I think it would be really helpful for the GNU Radio project to support a
> standard, basic gnuradio docker install with uhd and grc enabled as well as
> an example or two to demonstrate sane ways to run OOT modules on top of
> that image.  As Ben mentioned, Docker seems like a pretty energy-efficient
> way to approach support for systems like Windows and OSX going forward.
> Not having used boot2docker personally, I won't say that it's necessarily
> time to retire the live usb image, but I think Docker may evolve quickly
> into a pretty obvious replacement, if it hasn't already.  I also appreciate
> GNU Radio looking for ways to support users and potential users attempting
> to build and deploy applications that reach beyond the immediate
> environment of GNU Radio and its core devs.
>
> One problem we have to face, though, is image size.  I'm trying to tackle
> that problem by compressing the install for transactions over the wire and
> then uncompressing locally for applications (using pybombs2, of course).
> This is all a little awkward for docker distribution, but lots of things in
> docker are a little awkward.  Developers could build on top by untarring
> the prefix, pybombs installing extra recipes (possibly custom recipes) and
> then using the deploy command again, all within the same Docker "RUN"
> section.  Locally, if you docker build applications beginning with the same
> commands to untar the image, then all applications can take advantage of
> that layer (you'll have to untar the base image only one time regardless of
> how many applications use the base image).  Alternatively, you can docker
> run with cmd or entry set to untar the image (and then, presumably, you'll
> want to commit the running container locally so you don't have to untar
> again).
>
> Does anyone have a better idea for bringing image size down without making
> it impossible to build and deploy OOTs?  Those Bistromath images are pretty
> tiny... I haven't really looked into the Alpine base image, either.
>
> ___
> 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 gr-osmosdr so file

[Jason Matusiak]

I believe we have the PyBOMBS dependency issues sorted out, so if you
use pybombs (and e.g. 'pybombs rebuild') it will do stuff in the right
order.


Martin,
Is pybombs rebuild a pybombs2 thing?  It doesn't seem to be a valid command in 
the older pybombs.

~J

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

Re: [Discuss-gnuradio] 3.7.9.2 Win64 binaries ready + Build scripts

[Geof Nieboer]

Tom,

Not a problem, glad to help.  If you give my username edit access, I'll
update the wiki to point people there if interested.

Geof

On Thu, Apr 14, 2016 at 4:58 PM, Tom Rondeau  wrote:

> On Thu, Apr 14, 2016 at 6:23 AM, Geof Nieboer 
> wrote:
>
>> All,
>>
>> Some may recall in the fall I posted a link to a beta windows installer.
>> I'm happy to report that I'm releasing new versions today for the 3.7.9.2
>> release, compatible with Windows 7/8/10.  All dependencies are included,
>> and all are built natively using MSVC 2015, no Cygwin or MinGW required.
>> It's about a 300MB package download.
>>
>> I've also refactored the entire build process used to make the msi's and
>> gotten it down to a series of Powershell scripts that can either:
>> 1- Build the entire GNURadio windows dependency chain from source and
>> then build GNURadio itself.
>> 2- Download a prebuilt "dependency pack" as binaries and then
>> build GNURadio and a couple OOT modules
>>
>> The binaries (for both GR and the dependencies) can be found at
>> http://www.gcndevelopment.com/gnuradio.  The scripts themselves are
>> hosted at http://github.com/gnieboer/gnuradio_windows_build_scripts.
>> While the binaries have no dependencies, the build scripts have several,
>> but all mandatory dependencies are free to install.  The various patches
>> required to make everything build on Win32/MSVC are either workarounds
>> built into the scripts, patches downloadable on the website, or forked
>> repos on my github account.  For the most part pull requests have been
>> submitted upstream.
>>
>> All GR components except gr-comedi are installed, and several OOT blocks
>> are also included by default, including UHD 3.9.3, gr-fosphor,
>> and gr-osmosdr with most drivers.  The windows audio sink has also been
>> refactored to double buffer to avoid the skipping others have reported.
>>
>> It uses OpenBLAS for numpy/scipy to stay GPLv3 compliant...users can
>> replace it with an MKL-based version as a wheel from the downloads page
>> should more performance be desired.
>>
>> More information is available on the website.  I hope both the binaries
>> and scripts are useful and look forward to feedback.
>>
>> Geof
>>
>
>
> Great work, Geof!
>
> Thanks for handling this so carefully and completely and for sharing your
> results!
>
> Tom
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] 3.7.9.2 Win64 binaries ready + Build scripts

[Tom Rondeau]

On Thu, Apr 14, 2016 at 10:51 AM, Geof Nieboer 
wrote:

> Tom,
>
> Not a problem, glad to help.  If you give my username edit access, I'll
> update the wiki to point people there if interested.
>
> Geof
>

Done. You should be able to edit the wiki.

Tom



> On Thu, Apr 14, 2016 at 4:58 PM, Tom Rondeau  wrote:
>
>> On Thu, Apr 14, 2016 at 6:23 AM, Geof Nieboer 
>> wrote:
>>
>>> All,
>>>
>>> Some may recall in the fall I posted a link to a beta windows
>>> installer.  I'm happy to report that I'm releasing new versions today for
>>> the 3.7.9.2 release, compatible with Windows 7/8/10.  All dependencies are
>>> included, and all are built natively using MSVC 2015, no Cygwin or MinGW
>>> required. It's about a 300MB package download.
>>>
>>> I've also refactored the entire build process used to make the msi's and
>>> gotten it down to a series of Powershell scripts that can either:
>>> 1- Build the entire GNURadio windows dependency chain from source and
>>> then build GNURadio itself.
>>> 2- Download a prebuilt "dependency pack" as binaries and then
>>> build GNURadio and a couple OOT modules
>>>
>>> The binaries (for both GR and the dependencies) can be found at
>>> http://www.gcndevelopment.com/gnuradio.  The scripts themselves are
>>> hosted at http://github.com/gnieboer/gnuradio_windows_build_scripts.
>>> While the binaries have no dependencies, the build scripts have several,
>>> but all mandatory dependencies are free to install.  The various patches
>>> required to make everything build on Win32/MSVC are either workarounds
>>> built into the scripts, patches downloadable on the website, or forked
>>> repos on my github account.  For the most part pull requests have been
>>> submitted upstream.
>>>
>>> All GR components except gr-comedi are installed, and several OOT blocks
>>> are also included by default, including UHD 3.9.3, gr-fosphor,
>>> and gr-osmosdr with most drivers.  The windows audio sink has also been
>>> refactored to double buffer to avoid the skipping others have reported.
>>>
>>> It uses OpenBLAS for numpy/scipy to stay GPLv3 compliant...users can
>>> replace it with an MKL-based version as a wheel from the downloads page
>>> should more performance be desired.
>>>
>>> More information is available on the website.  I hope both the binaries
>>> and scripts are useful and look forward to feedback.
>>>
>>> Geof
>>>
>>
>>
>> Great work, Geof!
>>
>> Thanks for handling this so carefully and completely and for sharing your
>> results!
>>
>> Tom
>>
>>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] raspi FAQ/HOWTO/recipe ??????

[Tom Rondeau]

On Wed, Apr 13, 2016 at 11:13 PM, Marcus D. Leech  wrote:

> On 04/13/2016 11:05 PM, Jean Luc wrote:
>
> I've been trying as well to use GR on RPi (model 3), the ultimate purpose
> would be radio astronomy. A smaller form factor such as RPI's makes a
> remote installation more palatable than a full PC.
>
> I wasn't able to compile it on RPi but compromised on using a more recent
> version (3.7.9-3~bpo8+1) taken from jessie-backports. The steps are below.
>
> sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys
> 8B48AD6246925553 7638D0442B90D010
>
> sudo vi /etc/apt/sources.list and  add the following line:
> deb http://ftp.debian.org/debian jessie-backports main
>
> sudo apt-get update
> sudo apt-get -t jessie-backports install gnuradio
>
>
>
> On the positive side, GR works on RPi3. However, it does keep one core to
> 100% in many cases. This was with input from an SDR with the 2Msps rate,
> though. Actually, one more problem: audio output. That part didn't work
> ("check topology failed on audio_alsa_sink"); I posted a message on the
> list the other day. I cannot say it's a GR problem, could be mine; I have
> yet to understand what the problem is.
>
> JL.
>
> I'll point out that ARCH generally has up-to-date packages for this stuff,
> including for most of the ARM-based SBCs.
>
> I run ARCH on various Odroid platforms, running radio-astronomy GR
> flow-graphs, with good success.  I run these "headless", without any
>   graphical display from the Odroid--it's just the digital radio +
> processing platform.
>


We also keep information about our support and capabilities on embedded
systems here:

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

Also for Android if you're running that on your embedded machine:

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


We don't have much posted on using RPis because, until recently, they were
not an exciting platform for us. The initial RPi was so woefully
underpowered as a processor that most of us trying to do actual math went
with other solutions, like the Odroid that Marcus mentioned. With the RPi2
and RPi3, they now have interesting processors where GNU Radio makes a lot
more sense.

Tom



> On Wed, Apr 13, 2016 at 7:45 AM, Rob Roschewsk  wrote:
>
>> Marcus,
>>
>> Thanks for responding.
>>
>> I'm looking to build a headless FM receiver to record and stream public
>> service communication (fire, police, etc.). We will stream as many channels
>> as possible that fall into a given passband.
>>
>> I already have a system running on a PC and now would like to port it to
>> the PI.
>>
>> I understand it maybe an "up hill" path, but the thought is to deploy
>> multiple inexpensive units around a geographic area all feeding a central
>> streaming server.
>>
>> The Pi is running Raspian Jesse  I started with the distribution
>> packages but ran into problems right out of the blocks and thought it would
>> be best to use the latest code before asking questions :)
>>
>> I understand cross compiling is the way to go.
>>
>> Since I brought it up, here was the error I saw when I tried to run the
>> script that runs on the PC but fails spectacularly on the raspberry pi with
>> the precompiled packages 
>>
>> roschews@raspberrypi:~/sdr/multirx $ ./multirx_nogui.py -s 49 noaa.xml
>> linux; GNU C++ version 4.9.1; Boost_105500; UHD_003.007.003-0
>> <0030070030>-unknown
>>
>> high=16250 low=16240 span=10
>> center=16245
>> gr-osmosdr 0.1.3 (0.1.3) gnuradio 3.7.5
>> built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf
>> bladerf rfspace airspy
>> Using device #0 Realtek RTL2838UHIDIR SN: 0108
>> Found Elonics E4000 tuner
>> Exact sample rate is: 100.026491 Hz
>> Using Volk machine: generic_orc
>> VOLK: Error allocating memory (posix_memalign: 22)
>> VOLK: Error allocating memory (posix_memalign: 22)
>> VOLK: Error allocating memory (posix_memalign: 22)
>> Segmentation fault
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Read file metadata

[Yan Huang]

Hi Tom,

Thank you for your kind remind, I find the problem that I stored the metadata 
file as inline type and I don’t need to add ‘.hdr’ with it.

Many Thanks,
Yan


From: trond...@trondeau.com [mailto:trond...@trondeau.com] On Behalf Of Tom 
Rondeau
Sent: 14 April 2016 14:57
To: Yan Huang
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Read file metadata

On Thu, Apr 14, 2016 at 7:44 AM, Yan Huang 
mailto:eexy...@nottingham.ac.uk>> wrote:
Hi all,

I’m using Message Strobe to control UHD: USRP Source to receive signal with 
specified frequency(2.4GHz), but I find flow graph start running before Message 
Strobe set the frequency as 2.4 GHz.

Message Strobe -> UHD: USRP Source ->File Sink

So I want to use stream tag to know the time of first item with 2.4GHz. I think 
I can change File Sink to File Meta Sink to receive the ‘rx_time’ stored in 
‘tag_sense1.hdr’ file(attached), and I use the existing program called 
‘gr_read_file_metadata’ to read out the header information, but it comes out an 
error:

File "tag_sense1.hdr", line 1
SyntaxError: Non-ASCII character '\xb5' in file tag_sense1.hdr on line 2, but 
no encoding declared; see http://www.python.org/peps/pep-0263.html for details

I have checked the link, but I don’t understand what’s the encoding information 
of the python source file. Do need to add # -*- coding:  -*- to 
the source file?

I problems are:


1.   How can I read the’ .hdr’ file?

2.   Am I right to use file meta sink to get the start receiving time?

3.   Do I need to add stream tag and then read it out using other blocks in 
this scenario?

Any advice will be appreciated. Many thanks in advance.

Best Regards,

Yan


Yan,

Have you fully read over the description of the metadata files and how to use 
them in the manual?

http://gnuradio.org/doc/doxygen/page_metadata.html

Specifically, since you have a .hdr file, you've set this into Detached mode. 
You'll need to use the -D flag to indicate that to gr_read_file_metadata.

Tom





This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it. 

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.

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

Re: [Discuss-gnuradio] 3.7.9.2 Win64 binaries ready + Build scripts

[Ben Hilburn]

Hey Geof -

I downloaded the any-arch installer and ran it on a SurfacePro4 Windows10
machine I have here, and it worked perfectly. I'm now using GRC and have
VOLK Profile running in the background, and everything is working
beautifully.

Thanks so much for taking the time to put this together - I think a lot of
people will benefit from it, and it's well done.

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

Re: [Discuss-gnuradio] Docker

[Nick Foster]

>
> I think it would be really helpful for the GNU Radio project to support a
>> standard, basic gnuradio docker install with uhd and grc enabled as well as
>> an example or two to demonstrate sane ways to run OOT modules on top of
>> that image.  As Ben mentioned, Docker seems like a pretty energy-efficient
>> way to approach support for systems like Windows and OSX going forward.
>> Not having used boot2docker personally, I won't say that it's necessarily
>> time to retire the live usb image, but I think Docker may evolve quickly
>> into a pretty obvious replacement, if it hasn't already.  I also appreciate
>> GNU Radio looking for ways to support users and potential users attempting
>> to build and deploy applications that reach beyond the immediate
>> environment of GNU Radio and its core devs.
>>
>
As far as OOT modules, that's easy. For instance, a Dockerfile for
gr-air-modes could look like this (this is untested, don't get any ideas):

FROM bistromath/gnuradio:3.7.8
MAINTAINER bistrom...@gmail.com version: 0.1
RUN apt-get install -y python-zmq
WORKDIR /opt/gr-air-modes
COPY . /opt/gr-air-modes
RUNmkdir build \
&& cd build \
&& cmake ../ \
&& make -j4 \
&& make install

...that's more or less the whole thing, although this particular example is
broken for a couple of reasons (no Qt in my base layer, other missing
prerequisites). It might be nice to include a Dockerfile template in the
OOT example. The nice part about doing OOT modules in this manner is that
Gnuradio users could potentially never have to compile Gnuradio -- just
write their OOT and base its Dockerfile upon a precompiled Gnuradio base
layer. Another benefit is bitrot is all but eliminated, as you're basing
your module on top of a versioned base layer rather than master.


>
>> One problem we have to face, though, is image size.  I'm trying to tackle
>> that problem by compressing the install for transactions over the wire and
>> then uncompressing locally for applications (using pybombs2, of course).
>> This is all a little awkward for docker distribution, but lots of things in
>> docker are a little awkward.  Developers could build on top by untarring
>> the prefix, pybombs installing extra recipes (possibly custom recipes) and
>> then using the deploy command again, all within the same Docker "RUN"
>> section.  Locally, if you docker build applications beginning with the same
>> commands to untar the image, then all applications can take advantage of
>> that layer (you'll have to untar the base image only one time regardless of
>> how many applications use the base image).  Alternatively, you can docker
>> run with cmd or entry set to untar the image (and then, presumably, you'll
>> want to commit the running container locally so you don't have to untar
>> again).
>>
>
>>
> Does anyone have a better idea for bringing image size down without making
>> it impossible to build and deploy OOTs?  Those Bistromath images are pretty
>> tiny... I haven't really looked into the Alpine base image, either.
>>
>
The Docker image I put up on Docker Hub is small-ish because it only
includes these components (and their prerequisites):

--   * python-support
--   * testing-support
--   * volk
--   * gnuradio-runtime
--   * gr-blocks
--   * gnuradio-companion
--   * gr-fft
--   * gr-filter
--   * gr-analog
--   * gr-digital
--   * gr-channels
--   * gr-uhd
--   * gr-utils
--   * gr-wxgui

It could be a lot smaller if I removed the GR build files (292MB), GR
source files (88MB), and UHD source/build (200MB). That would cut it down
to somewhat more than half its current size. I like having them there
because if I'm working inside the environment I can compile changes
incrementally. For a pure deployment system, though, they're unnecessary.

It's possible, albeit messy, to build a Gnuradio distribution in layers and
tag the individual layers separately. Because each command in a Dockerfile
produces an incremental UFS layer, if you can break the compilation of
Gnuradio into separate commands for each component in the Dockerfile, then
you can tag the various incremental layers to build different composite
Gnuradio distributions. It's probably simpler just to provide a
"bells-'n-whistles" version and a "bare bones" version.

If you like, I can see just how small I can reasonably get things. I'd
argue, though, that a one-time, couple-of-GB download is a reasonable
compromise for the convenience of versioned distribution in all but niche
applications (embedded or offline come to mind). In other words, the
benefit of getting the wire size down probably doesn't outweigh the effort
for most people.

--n


>
>>
>>
>> ___
>> 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

Re: [Discuss-gnuradio] Question about packet sequence

[Martin Braun]

On 04/14/2016 01:20 AM, Laur Joost wrote:
> 1. The sequence of the packets is important. It would be rather bad if
> two bunches of samples in your IQ stream suddenly switched places.
> 2. The host PC network stack does no reordering. It can't, by definition
> of UDP, as there's nothing to reorder by.
> 3. AFAIK, the UHD also does no reordering. However, the packets arriving
> from the USRP __are__ numbered. If UHD detects a missing packet, it*
> prints a D (to signify a Dropped packet) to stdout, and emits a new
> rx_time tag for the next packet.
> 
> * Actually, I don't know whether that's UHD or gr-uhd that does this.

It's UHD. For swapped packets, it would actually print 3 D's:

Packet sequence:   1 3 2 4

- receives 1 => OK
- receives 3 => Assumes packet was dropped, expected 2. Print D
- receives 2 => Whaaa...? Expected 4. Prints D.
- receives 4 => looks like packet 3 was dropped. Print D.

M



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

Re: [Discuss-gnuradio] Docker

[Nicholas McCarthy]

Three points to make about this OOT Docker example.
1) Everything you're doing manually here can be accomplished using
pybombs2... and pybombs2 makes itself quite amenable to existing within the
Docker image both as an interface to what's already installed on the image
and a handy way to install new OOTs and dependencies on top of the image.
I would favor using pybombs2 as a basis for gnuradio Docker images... at
least that's what I'm doing for myself.
2) Supporting a pybombs2 Docker image is a great way to ensure that
pybombs2 builds from a very, very minimal initial Linux installation.
Since pybombs2 is newish and experiencing lots of activity, the project
might benefit from anchoring itself to nightly Docker builds.
3) How to handle OOTs could be a bit more complicated if you try, as I
have, to reduce image size using the pybombs2 "deploy" mechanism.  Deploy
lets you do two nice things... it optionally strips all the src out of your
build automatically (a significant weight reduction step, as you note, but
installed .h files remain... sort of like a dev package).  It also
compresses the rest of your build.  As long as you install and then
compress in the same Docker RUN call, your UFS layer is small, too.  The
result saves GBs over the wire (I think?).  When you're using Docker to
deploy code, image sizes over the wire can be a big deal, and I'd love for
it to be convenient enough to start each day off by docker pulling the
latest build.  The "pybombs" image I posted is a vanilla pybombs2 install
with uhd forcebuilt and the source stripped (so it's pretty much a complete
gnuradio build, gui and all)... it's ~1.5G to download (Again, I think?
Sometimes you have hidden image layers that make things appear smaller than
they actually are.)  That's big in Docker world from what I've seen, but
it's not much of an inconvenience.  ~2.5G for the version retaining the
source code is a little more glaringly bad.  Fortunately, unless you're
working on code in the uhd or gnuradio repos, the 1.5G version is totally
fine.

For me, these are the "natural" GR versions to support via Docker... I'd be
interested in a version more like yours that strips the gui and other
modules, too.  Maybe it's worth cutting uhd in an image, but 200MB doesn't
sound worthwhile at that cost.

I'm interested in experiences/opinions regarding the use of pybombs deploy
to compress between intermediate UFS layers.  Am I somehow overestimating
the savings in image size?  Does it seem too complicated, and/or am I
overlooking an easier way?  Maybe no one cares about image size?
 (Actually, I know some people who definitely do care, or at least they
claim to care.  I'm pretty sure I will, too.)

I don't think building the distribution in explicit layers is very
helpful.  It's something that seems useful when you hear a description of
the UFS, but it seems to wind up being a waste of time.  One or several GR
images makes sense as a basis for images building OOTs, but what the hell
are you going to do with an image that's run pybombs install boost except
run pybombs install gnuradio?

Cheers,
Nick M.


On Thu, Apr 14, 2016 at 2:16 PM Nick Foster  wrote:

> I think it would be really helpful for the GNU Radio project to support a
>>> standard, basic gnuradio docker install with uhd and grc enabled as well as
>>> an example or two to demonstrate sane ways to run OOT modules on top of
>>> that image.  As Ben mentioned, Docker seems like a pretty energy-efficient
>>> way to approach support for systems like Windows and OSX going forward.
>>> Not having used boot2docker personally, I won't say that it's necessarily
>>> time to retire the live usb image, but I think Docker may evolve quickly
>>> into a pretty obvious replacement, if it hasn't already.  I also appreciate
>>> GNU Radio looking for ways to support users and potential users attempting
>>> to build and deploy applications that reach beyond the immediate
>>> environment of GNU Radio and its core devs.
>>>
>>
> As far as OOT modules, that's easy. For instance, a Dockerfile for
> gr-air-modes could look like this (this is untested, don't get any ideas):
>
> FROM bistromath/gnuradio:3.7.8
> MAINTAINER bistrom...@gmail.com version: 0.1
> RUN apt-get install -y python-zmq
> WORKDIR /opt/gr-air-modes
> COPY . /opt/gr-air-modes
> RUNmkdir build \
> && cd build \
> && cmake ../ \
> && make -j4 \
> && make install
>
> ...that's more or less the whole thing, although this particular example
> is broken for a couple of reasons (no Qt in my base layer, other missing
> prerequisites). It might be nice to include a Dockerfile template in the
> OOT example. The nice part about doing OOT modules in this manner is that
> Gnuradio users could potentially never have to compile Gnuradio -- just
> write their OOT and base its Dockerfile upon a precompiled Gnuradio base
> layer. Another benefit is bitrot is all but eliminated, as you're basing
> your module on top of a versioned base layer rather

[Discuss-gnuradio] Synced MIMO cable clock of both boards changes at every call to tb.start()?

[Pavan Yedavalli]

Does the start() function in GNURadio reinitialize the clocks on the USRPs
every time it is called? I have two USRPs connected via MIMO cable, so they
are synced, but my flowgraph calls start() after every loop, which I'm
realizing may be changing the constant but random offset of the clock every
time.

I looked at the documentation for start() and nothing really comes to mind
that shows what's happening to the USRP clocks when start() is called from
my top_block. Any help would be great. Thank you so much.

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

Re: [Discuss-gnuradio] Docker

[Nick Foster]

On Thu, Apr 14, 2016 at 3:54 PM Nicholas McCarthy 
wrote:

> Three points to make about this OOT Docker example.
> 1) Everything you're doing manually here can be accomplished using
> pybombs2... and pybombs2 makes itself quite amenable to existing within the
> Docker image both as an interface to what's already installed on the image
> and a handy way to install new OOTs and dependencies on top of the image.
> I would favor using pybombs2 as a basis for gnuradio Docker images... at
> least that's what I'm doing for myself.
>

The only argument I have against this is that not doing so (i.e.,
cataloging the dependencies manually in the Dockerfile) sort of obviates
the need for pybombs, in this particular case. The dependencies and build
procedures are either encoded in the individual Dockerfiles, which are
simply part of the OOT project itself, or they're centralized into pybombs
recipes. Their usefulness overlaps somewhat.

Where I see a clear win for pybombs in a Docker recipe is when you want to
compile and install multiple OOTs in a single Docker image -- it's painful
to "stack" targets to create a catchall image (i.e., uhd -> gnuradio ->
gr-air-modes -> gr-ais...), and annoying to cut and paste Dockerfile
recipes to concatenate them. It's not an issue from a production standpoint
since half the reason to use Docker in production is to isolate services
from each other, one image per service (if all your services depend on the
same base layer, there's little/no image size overhead). But if you're
putting together a single catchall image for folks to muck around with, a
pybombs base layer seems like a great way to do that and still keep a
sane-ish Dockerfile.


> 2) Supporting a pybombs2 Docker image is a great way to ensure that
> pybombs2 builds from a very, very minimal initial Linux installation.
> Since pybombs2 is newish and experiencing lots of activity, the project
> might benefit from anchoring itself to nightly Docker builds.
> 3) How to handle OOTs could be a bit more complicated if you try, as I
> have, to reduce image size using the pybombs2 "deploy" mechanism.  Deploy
> lets you do two nice things... it optionally strips all the src out of your
> build automatically (a significant weight reduction step, as you note, but
> installed .h files remain... sort of like a dev package).  It also
> compresses the rest of your build.  As long as you install and then
> compress in the same Docker RUN call, your UFS layer is small, too.  The
> result saves GBs over the wire (I think?).  When you're using Docker to
> deploy code, image sizes over the wire can be a big deal, and I'd love for
> it to be convenient enough to start each day off by docker pulling the
> latest build.  The "pybombs" image I posted is a vanilla pybombs2 install
> with uhd forcebuilt and the source stripped (so it's pretty much a complete
> gnuradio build, gui and all)... it's ~1.5G to download (Again, I think?
> Sometimes you have hidden image layers that make things appear smaller than
> they actually are.)  That's big in Docker world from what I've seen, but
> it's not much of an inconvenience.  ~2.5G for the version retaining the
> source code is a little more glaringly bad.  Fortunately, unless you're
> working on code in the uhd or gnuradio repos, the 1.5G version is totally
> fine.
>

> For me, these are the "natural" GR versions to support via Docker... I'd
> be interested in a version more like yours that strips the gui and other
> modules, too.  Maybe it's worth cutting uhd in an image, but 200MB doesn't
> sound worthwhile at that cost.
>
> I'm interested in experiences/opinions regarding the use of pybombs deploy
> to compress between intermediate UFS layers.  Am I somehow overestimating
> the savings in image size?  Does it seem too complicated, and/or am I
> overlooking an easier way?  Maybe no one cares about image size?
>  (Actually, I know some people who definitely do care, or at least they
> claim to care.  I'm pretty sure I will, too.)
>

I'd be really interested to see what the OTW savings from deploy are! That
seems pretty useful, generally speaking. But remember that Docker Registry
already implements image compression over the wire for each of the UFS
layers it's sending. So I'd be a little concerned that the additional
compression step isn't helping actual transfer times, although optionally
removing the src will certainly help.


>
> I don't think building the distribution in explicit layers is very
> helpful.  It's something that seems useful when you hear a description of
> the UFS, but it seems to wind up being a waste of time.  One or several GR
> images makes sense as a basis for images building OOTs, but what the hell
> are you going to do with an image that's run pybombs install boost except
> run pybombs install gnuradio?
>

Only the incremental layers which have changed need to be sent over the
wire. This can be pretty painful if you're building Gnuradio monolithically
(i.e., in a single RUN comm

Re: [Discuss-gnuradio] Docker

[Nicholas McCarthy]

Yeah, this is one of the things I like most about Dockerfiles... the self
documenting aspect.  However... have you noticed how many times you end up
dealing with Docker images apart from their Dockerfiles?  For a lot of
useful images, it's difficult (maybe impossible?) to track the Dockerfile
down... I've heard it's pretty easy to reverse engineer from the
intermediate layers, but still.  With pybombs, the catalog is part of the
image at the command line.  Also, for any OOT, there might just be one guy
who's an expert at building the project (the guy who wrote the recipe,
presumably).  Anyone can use the resulting recipe to install, so if you
want to support a Docker image with dependencies in the pybombs recipe
world, you don't have to learn how to install them... just use the work
already in pybombs.

Yeah, I should run a real test pitting compression versus
non-compression I may have gotten confused with pre-existing image
layers and the source-stripping feature (which definitely helps a lot).  If
I can avoid the whole tar and untar, that'd make everything much easier.
The manual decompression takes a lot longer than the Docker decompression,
though, so maybe bzip2 is just doing a better job?  This will have to wait
until I have a really good connection, tho.

Okay, that's true... it does very much depend on what you're rebuilding
So it makes sense to isolate code that changes a lot from stable code in
layers.  To me, this means installing all the dependencies for uhd and
gnuradio in a layer, then uhd, then gnuradio... Does it make sense to layer
any more? (I mean, obviously, it could matter theoretically, but in
practice?  Am I missing a volatile dependency?)

Cheers,
Nick M.

On Thu, Apr 14, 2016 at 7:48 PM Nick Foster  wrote:

> On Thu, Apr 14, 2016 at 3:54 PM Nicholas McCarthy 
> wrote:
>
>> Three points to make about this OOT Docker example.
>> 1) Everything you're doing manually here can be accomplished using
>> pybombs2... and pybombs2 makes itself quite amenable to existing within the
>> Docker image both as an interface to what's already installed on the image
>> and a handy way to install new OOTs and dependencies on top of the image.
>> I would favor using pybombs2 as a basis for gnuradio Docker images... at
>> least that's what I'm doing for myself.
>>
>
> The only argument I have against this is that not doing so (i.e.,
> cataloging the dependencies manually in the Dockerfile) sort of obviates
> the need for pybombs, in this particular case. The dependencies and build
> procedures are either encoded in the individual Dockerfiles, which are
> simply part of the OOT project itself, or they're centralized into pybombs
> recipes. Their usefulness overlaps somewhat.
>
> Where I see a clear win for pybombs in a Docker recipe is when you want to
> compile and install multiple OOTs in a single Docker image -- it's painful
> to "stack" targets to create a catchall image (i.e., uhd -> gnuradio ->
> gr-air-modes -> gr-ais...), and annoying to cut and paste Dockerfile
> recipes to concatenate them. It's not an issue from a production standpoint
> since half the reason to use Docker in production is to isolate services
> from each other, one image per service (if all your services depend on the
> same base layer, there's little/no image size overhead). But if you're
> putting together a single catchall image for folks to muck around with, a
> pybombs base layer seems like a great way to do that and still keep a
> sane-ish Dockerfile.
>
>
>> 2) Supporting a pybombs2 Docker image is a great way to ensure that
>> pybombs2 builds from a very, very minimal initial Linux installation.
>> Since pybombs2 is newish and experiencing lots of activity, the project
>> might benefit from anchoring itself to nightly Docker builds.
>> 3) How to handle OOTs could be a bit more complicated if you try, as I
>> have, to reduce image size using the pybombs2 "deploy" mechanism.  Deploy
>> lets you do two nice things... it optionally strips all the src out of your
>> build automatically (a significant weight reduction step, as you note, but
>> installed .h files remain... sort of like a dev package).  It also
>> compresses the rest of your build.  As long as you install and then
>> compress in the same Docker RUN call, your UFS layer is small, too.  The
>> result saves GBs over the wire (I think?).  When you're using Docker to
>> deploy code, image sizes over the wire can be a big deal, and I'd love for
>> it to be convenient enough to start each day off by docker pulling the
>> latest build.  The "pybombs" image I posted is a vanilla pybombs2 install
>> with uhd forcebuilt and the source stripped (so it's pretty much a complete
>> gnuradio build, gui and all)... it's ~1.5G to download (Again, I think?
>> Sometimes you have hidden image layers that make things appear smaller than
>> they actually are.)  That's big in Docker world from what I've seen, but
>> it's not much of an inconvenience.  ~2.5G for the version ret

Re: [Discuss-gnuradio] Docker

[Nicholas McCarthy]

and then there's this
https://github.com/docker/docker/issues/12053

I'm not even sure what version of Docker I used when I did the compression
thing... it wasn't 1.10.

Cheers,
Nick M.

On Thu, Apr 14, 2016 at 8:40 PM Nicholas McCarthy 
wrote:

> Yeah, this is one of the things I like most about Dockerfiles... the self
> documenting aspect.  However... have you noticed how many times you end up
> dealing with Docker images apart from their Dockerfiles?  For a lot of
> useful images, it's difficult (maybe impossible?) to track the Dockerfile
> down... I've heard it's pretty easy to reverse engineer from the
> intermediate layers, but still.  With pybombs, the catalog is part of the
> image at the command line.  Also, for any OOT, there might just be one guy
> who's an expert at building the project (the guy who wrote the recipe,
> presumably).  Anyone can use the resulting recipe to install, so if you
> want to support a Docker image with dependencies in the pybombs recipe
> world, you don't have to learn how to install them... just use the work
> already in pybombs.
>
> Yeah, I should run a real test pitting compression versus
> non-compression I may have gotten confused with pre-existing image
> layers and the source-stripping feature (which definitely helps a lot).  If
> I can avoid the whole tar and untar, that'd make everything much easier.
> The manual decompression takes a lot longer than the Docker decompression,
> though, so maybe bzip2 is just doing a better job?  This will have to wait
> until I have a really good connection, tho.
>
> Okay, that's true... it does very much depend on what you're
> rebuilding So it makes sense to isolate code that changes a lot from
> stable code in layers.  To me, this means installing all the dependencies
> for uhd and gnuradio in a layer, then uhd, then gnuradio... Does it make
> sense to layer any more? (I mean, obviously, it could matter theoretically,
> but in practice?  Am I missing a volatile dependency?)
>
> Cheers,
> Nick M.
>
> On Thu, Apr 14, 2016 at 7:48 PM Nick Foster  wrote:
>
>> On Thu, Apr 14, 2016 at 3:54 PM Nicholas McCarthy 
>> wrote:
>>
>>> Three points to make about this OOT Docker example.
>>> 1) Everything you're doing manually here can be accomplished using
>>> pybombs2... and pybombs2 makes itself quite amenable to existing within the
>>> Docker image both as an interface to what's already installed on the image
>>> and a handy way to install new OOTs and dependencies on top of the image.
>>> I would favor using pybombs2 as a basis for gnuradio Docker images... at
>>> least that's what I'm doing for myself.
>>>
>>
>> The only argument I have against this is that not doing so (i.e.,
>> cataloging the dependencies manually in the Dockerfile) sort of obviates
>> the need for pybombs, in this particular case. The dependencies and build
>> procedures are either encoded in the individual Dockerfiles, which are
>> simply part of the OOT project itself, or they're centralized into pybombs
>> recipes. Their usefulness overlaps somewhat.
>>
>> Where I see a clear win for pybombs in a Docker recipe is when you want
>> to compile and install multiple OOTs in a single Docker image -- it's
>> painful to "stack" targets to create a catchall image (i.e., uhd ->
>> gnuradio -> gr-air-modes -> gr-ais...), and annoying to cut and paste
>> Dockerfile recipes to concatenate them. It's not an issue from a production
>> standpoint since half the reason to use Docker in production is to isolate
>> services from each other, one image per service (if all your services
>> depend on the same base layer, there's little/no image size overhead). But
>> if you're putting together a single catchall image for folks to muck around
>> with, a pybombs base layer seems like a great way to do that and still keep
>> a sane-ish Dockerfile.
>>
>>
>>> 2) Supporting a pybombs2 Docker image is a great way to ensure that
>>> pybombs2 builds from a very, very minimal initial Linux installation.
>>> Since pybombs2 is newish and experiencing lots of activity, the project
>>> might benefit from anchoring itself to nightly Docker builds.
>>> 3) How to handle OOTs could be a bit more complicated if you try, as I
>>> have, to reduce image size using the pybombs2 "deploy" mechanism.  Deploy
>>> lets you do two nice things... it optionally strips all the src out of your
>>> build automatically (a significant weight reduction step, as you note, but
>>> installed .h files remain... sort of like a dev package).  It also
>>> compresses the rest of your build.  As long as you install and then
>>> compress in the same Docker RUN call, your UFS layer is small, too.  The
>>> result saves GBs over the wire (I think?).  When you're using Docker to
>>> deploy code, image sizes over the wire can be a big deal, and I'd love for
>>> it to be convenient enough to start each day off by docker pulling the
>>> latest build.  The "pybombs" image I posted is a vanilla pybombs2 install
>>> with uhd fo

Re: [Discuss-gnuradio] Docker

[Nick Foster]

On Thu, Apr 14, 2016 at 5:40 PM Nicholas McCarthy 
wrote:

> Yeah, this is one of the things I like most about Dockerfiles... the self
> documenting aspect.  However... have you noticed how many times you end up
> dealing with Docker images apart from their Dockerfiles?  For a lot of
> useful images, it's difficult (maybe impossible?) to track the Dockerfile
> down... I've heard it's pretty easy to reverse engineer from the
> intermediate layers, but still.  With pybombs, the catalog is part of the
> image at the command line.  Also, for any OOT, there might just be one guy
> who's an expert at building the project (the guy who wrote the recipe,
> presumably).  Anyone can use the resulting recipe to install, so if you
> want to support a Docker image with dependencies in the pybombs recipe
> world, you don't have to learn how to install them... just use the work
> already in pybombs.
>

Distribute a Dockerfile in the root folder of each OOT. Then you don't have
to have any expert build, you just do "docker build ." and pow, it's
recreated anytime, anywhere. Whether you use pybombs or you just put the
dependencies and build process in the Dockerfile shouldn't matter, the
entire recipe should be in there for anyone to recreate.


>
> Yeah, I should run a real test pitting compression versus
> non-compression I may have gotten confused with pre-existing image
> layers and the source-stripping feature (which definitely helps a lot).  If
> I can avoid the whole tar and untar, that'd make everything much easier.
> The manual decompression takes a lot longer than the Docker decompression,
> though, so maybe bzip2 is just doing a better job?  This will have to wait
> until I have a really good connection, tho.
>
> Okay, that's true... it does very much depend on what you're
> rebuilding So it makes sense to isolate code that changes a lot from
> stable code in layers.  To me, this means installing all the dependencies
> for uhd and gnuradio in a layer, then uhd, then gnuradio... Does it make
> sense to layer any more? (I mean, obviously, it could matter theoretically,
> but in practice?  Am I missing a volatile dependency?)
>

It means that if you're doing daily Gnuradio builds you'll have to pull the
whole layer down each day. If you only want daily builds of your OOT
module, then no, there's no reason you'd want to layer any more finely
grained than that. The incremental cost of updating an OOT should be just a
few MB.

--n


>
> Cheers,
> Nick M.
>
> On Thu, Apr 14, 2016 at 7:48 PM Nick Foster  wrote:
>
>> On Thu, Apr 14, 2016 at 3:54 PM Nicholas McCarthy 
>> wrote:
>>
>>> Three points to make about this OOT Docker example.
>>> 1) Everything you're doing manually here can be accomplished using
>>> pybombs2... and pybombs2 makes itself quite amenable to existing within the
>>> Docker image both as an interface to what's already installed on the image
>>> and a handy way to install new OOTs and dependencies on top of the image.
>>> I would favor using pybombs2 as a basis for gnuradio Docker images... at
>>> least that's what I'm doing for myself.
>>>
>>
>> The only argument I have against this is that not doing so (i.e.,
>> cataloging the dependencies manually in the Dockerfile) sort of obviates
>> the need for pybombs, in this particular case. The dependencies and build
>> procedures are either encoded in the individual Dockerfiles, which are
>> simply part of the OOT project itself, or they're centralized into pybombs
>> recipes. Their usefulness overlaps somewhat.
>>
>> Where I see a clear win for pybombs in a Docker recipe is when you want
>> to compile and install multiple OOTs in a single Docker image -- it's
>> painful to "stack" targets to create a catchall image (i.e., uhd ->
>> gnuradio -> gr-air-modes -> gr-ais...), and annoying to cut and paste
>> Dockerfile recipes to concatenate them. It's not an issue from a production
>> standpoint since half the reason to use Docker in production is to isolate
>> services from each other, one image per service (if all your services
>> depend on the same base layer, there's little/no image size overhead). But
>> if you're putting together a single catchall image for folks to muck around
>> with, a pybombs base layer seems like a great way to do that and still keep
>> a sane-ish Dockerfile.
>>
>>
>>> 2) Supporting a pybombs2 Docker image is a great way to ensure that
>>> pybombs2 builds from a very, very minimal initial Linux installation.
>>> Since pybombs2 is newish and experiencing lots of activity, the project
>>> might benefit from anchoring itself to nightly Docker builds.
>>> 3) How to handle OOTs could be a bit more complicated if you try, as I
>>> have, to reduce image size using the pybombs2 "deploy" mechanism.  Deploy
>>> lets you do two nice things... it optionally strips all the src out of your
>>> build automatically (a significant weight reduction step, as you note, but
>>> installed .h files remain... sort of like a dev package).  It also
>>

[Discuss-gnuradio] Looking for Inmarsat Documentation Diagram - "Figure A2-1"

[Kevin McQuiggin]

Hi All:

Here’s an esoteric request:

I am working on an Inmarsat decoder for 600 bps P-Channel frames.  Gnuradio on 
the front end, and a C program for decoding the recovered data frames.  I’m 
using an Ettus B200 for the reception and gnuradio as the demodulator.  The 
satellite is on 1545.110 MHz.

I have valid frames and checksums, and my C code successfully de-interleaves, 
decodes, and descrambles the payload data in each frame.  I am using the open 
source Viterbi decoder package from http://spiral.net  for 
the deconvolution.

So, now I have apparently valid data frames (“SUs” in Inmarsat parlance), but a 
key diagram on decoding these data frames is missing in the only technical 
documentation I could find on Inmarsat.

This document is entitled "MANUAL FOR AERONAUTICAL MOBILE SATELLITE (ROUTE) 
SERVICE - Part III – Inmarsat and MTSAT”.  It’s a pretty complex document but 
the info I need is in there.

The missing diagram is “Figure A2-1” on page 209.  It doesn’t seem to render 
properly in either Word or Pages (the Mac’s word processor).  The ~100 other 
diagrams in the document render fine.  Murphy’s law...

Does anyone happen to have a readable copy of that figure?

Thanks in advance,

Kevin



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] gr-osmosdr python question

[Richard Bell]

I'm new to using gr-osmosdr and I'm trying to implement the equivalent set
of USRP function calls for a HackRF

set_center_freq(target_freq)
get_sensor("lo_locked")

which amounts to measuring how long it takes to command a frequency change
and lock at the new frequency.

The set_center_freq function happens to be the same, but I don't know where
to find documentation or example code that shows the get_sensor equivalent,
or if it's even needed. Would someone direct me to an API manual for
gr-osmosdr, or source code that defines these things?

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

Re: [Discuss-gnuradio] gr-osmosdr python question

[Marcus D. Leech]

On 04/14/2016 10:44 PM, Richard Bell wrote:
I'm new to using gr-osmosdr and I'm trying to implement the equivalent 
set of USRP function calls for a HackRF


set_center_freq(target_freq)
get_sensor("lo_locked")

which amounts to measuring how long it takes to command a frequency 
change and lock at the new frequency.


The set_center_freq function happens to be the same, but I don't know 
where to find documentation or example code that shows the get_sensor 
equivalent, or if it's even needed. Would someone direct me to an API 
manual for gr-osmosdr, or source code that defines these things?


Thanks,
Rich


The "get_sensor" API is a distinctly UHD thing, as far as I know.

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

Re: [Discuss-gnuradio] Overflow error in benchmark receiver side "DDDD"

[monika bansal]

Hii,

Thank you for your help.
That "" issue is not coming with original benchmark files.
I added one python block in between the chain in benchmark code. I think
due to which it was not fast enough to process the incoming data resulting
"" issue.

Regards,
Monika

On Tue, Apr 5, 2016 at 11:51 PM,  wrote:

> What if you make the file "/dev/null" -- does this still happen?
>
>
>
>
>
>
> On 2016-04-05 14:12, monika bansal wrote:
>
> Hii,
>
> I am running benchmark code and on the receiver side after receiving some
> number of packets(8000 so), it starts showing overflow errors ("") on
> terminal.
> Following is the system configuration
>
> python benchmark_rx.py -f 1100M --args "addr=10.32.38.163"
> --to-file=/home/ashokbandi/GNU/a_rx.txt --bandwidth=50
>
> Decreasing the bandwidth delays the error.
>
> I tried changing buffer size by setting net.core.rmem_max and
> net.core.wmem_max to 33445532 but to no avail.
>
>
> Following is the screen shot of terminal
>
> DDok: True  pktno: 24116  n_rcvd: 9730  n_right: 9723
> ok: True  pktno: 24182  n_rcvd: 9731  n_right: 9724
> DDok: True  pktno: 24319  n_rcvd: 9732  n_right:
> 9725
> ok: True  pktno: 24442  n_rcvd: 9733  n_right:
> 9726
> DDDok: True  pktno: 24477  n_rcvd: 9734  n_right: 9727
> Dok: True  pktno: 24568  n_rcvd: 9735  n_right: 9728
> Dok:
> False  pktno: 22729  n_rcvd: 9736  n_right: 9728
>
>
> Thanks
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-osmosdr python question

[Chris Kuethe]

None of the common host libraries seem to have that kind of an API call:
https://github.com/librtlsdr/librtlsdr/blob/master/include/rtl-sdr.h
https://github.com/mossmann/hackrf/blob/master/host/libhackrf/src/hackrf.h
https://github.com/airspy/host/blob/master/libairspy/src/airspy.h

But here's gr-osmosdr's API
https://github.com/osmocom/gr-osmosdr/blob/master/lib/source_iface.h

On Thu, Apr 14, 2016 at 7:44 PM, Richard Bell  wrote:
> I'm new to using gr-osmosdr and I'm trying to implement the equivalent set
> of USRP function calls for a HackRF
>
> set_center_freq(target_freq)
> get_sensor("lo_locked")
>
> which amounts to measuring how long it takes to command a frequency change
> and lock at the new frequency.
>
> The set_center_freq function happens to be the same, but I don't know where
> to find documentation or example code that shows the get_sensor equivalent,
> or if it's even needed. Would someone direct me to an API manual for
> gr-osmosdr, or source code that defines these things?
>
> Thanks,
> Rich
>
> ___
> 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] 3.7.9.2 Win64 binaries ready + Build scripts

[Anon Lister]

This is awesome, I will test out the build process this weekend on 10. Any
reason for the slightly older uhd release? I'd love to get gr-baz and gqrx
working on Win.

I'm also somewhat interested in stealing a pre-compiled list of
dependencies for my somewhat crazy project of building GR + some OOTs on
RHEL 6. Talk about dependency hell. ;p
On Apr 14, 2016 6:24 AM, "Geof Nieboer"  wrote:

> All,
>
> Some may recall in the fall I posted a link to a beta windows installer.
> I'm happy to report that I'm releasing new versions today for the 3.7.9.2
> release, compatible with Windows 7/8/10.  All dependencies are included,
> and all are built natively using MSVC 2015, no Cygwin or MinGW required.
> It's about a 300MB package download.
>
> I've also refactored the entire build process used to make the msi's and
> gotten it down to a series of Powershell scripts that can either:
> 1- Build the entire GNURadio windows dependency chain from source and then
> build GNURadio itself.
> 2- Download a prebuilt "dependency pack" as binaries and then
> build GNURadio and a couple OOT modules
>
> The binaries (for both GR and the dependencies) can be found at
> http://www.gcndevelopment.com/gnuradio.  The scripts themselves are
> hosted at http://github.com/gnieboer/gnuradio_windows_build_scripts.
> While the binaries have no dependencies, the build scripts have several,
> but all mandatory dependencies are free to install.  The various patches
> required to make everything build on Win32/MSVC are either workarounds
> built into the scripts, patches downloadable on the website, or forked
> repos on my github account.  For the most part pull requests have been
> submitted upstream.
>
> All GR components except gr-comedi are installed, and several OOT blocks
> are also included by default, including UHD 3.9.3, gr-fosphor,
> and gr-osmosdr with most drivers.  The windows audio sink has also been
> refactored to double buffer to avoid the skipping others have reported.
>
> It uses OpenBLAS for numpy/scipy to stay GPLv3 compliant...users can
> replace it with an MKL-based version as a wheel from the downloads page
> should more performance be desired.
>
> More information is available on the website.  I hope both the binaries
> and scripts are useful and look forward to feedback.
>
> Geof
>
>
>
> ___
> 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