Re: [Discuss-gnuradio] [GSoC] Infos for mentors + students

[Martin Braun]

This is a reminder that the submission deadline for proposals *on the
summer of code website* is this Friday, March 25th! For all those who
have proposals currently in the making, post it there, even if you're
not finished, just so they don't slip through the cracks.

Thanks!

Martin

On 03/22/2016 11:33 AM, Martin Braun wrote:
> The proposal submission deadline for GSoC is approaching fast, and I'd
> like to ping everyone on the current status and some other information.
> 
> First, I've updated the wiki page with the student instructions:
> http://gnuradio.org/redmine/projects/gnuradio/wiki/GSoCStudentInfo
> 
> Please take another look to make sure your proposal includes everything
> it needs.
> 
> Some students have posted final proposals on the GSoC page, but no
> draft. Note we can't see those until the submission deadline, so that
> means you'll get no feedback. If you want feedback (and I guess you do),
> please also post a draft.
> 
> Some students have posted drafts written in Google Docs. That works well
> for us, as we can comment inline. However, maybe you want to also share
> that draft on the mailing list.
> Others have posted drafts to github. That's also great! Mentors can
> raise issues using the issue tracker. It's also easier to share
> LaTeX-generated proposals this way, which already looks better :)
> 
> Something that came up is the size of the proposals: We don't have a
> word or page count minimum, but just going through the proposals, it
> seems that the good proposals are in the 4-5 page range.
> 
> If you want to leave a good impression, it also helps to be active on
> the mailing list. Ask and answer questions, show us you're interested in
> the community.
> 
> Mentors, and any other interested person, please give generous feedback.
> 
> Thanks everyone, for participating in this fantastic program!
> 
> Cheers,
> Martin
> 
> ___
> 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] Ettus N210 GMSK 9600

[Marcus D. Leech]

On 03/23/2016 10:08 PM, Dan CaJacob wrote:
Derek is spot on.  0 dB into any USRP is screaming loud.  Most of the 
units are very sensitive, so it's perfectly fine to err on the side of 
too much attenuation to start and dial the gain as you need.  It 
depends on the USRP type, but signals much above -15dB can physically 
damage the hardware if you set the gain too high.
I'd actually said most of this to Tom privately, but forgot to copy the 
list.


It's instructive to consider what kind of "normal" signals one might 
expect to receive on a receiver intended to be connected to an antenna.


Consider your average +70dBm (10kW) FM station.10km away from the 
TX, we expect about 90dB path loss, which means that the
  theoretical power seen by your antenna would be about -20dBm. Perhaps 
a bit more, since the TX antenna won't be strictly isotropic.


At 50km away, that's 100dB of path loss, giving about -30dBm at your 
antenna terminals (ballpark, hand-waving).  Now, a signal of
  -30dBm is actually considered fairly strong, and your typical FM 
receiver will produce a very nice, nearly-noise-free output from

  signals entering your antenna at levels of -30dBm.

The RX inputs of most SDRs (Ettus radio are no exception) are designed 
for the kinds of signal levels that are typical in "connected to
  an antenna" environment.  They are less well suited to "connected to 
a laboratory signal generator", without significant attenuation.


The RF signal levels floating around in a lab are typically much 
"louder" than you might find "on air", so if one is used to lab conditions,
  it may not be obvious that a sensitive receiver designed for "from 
the air" reception would be unhappy in laboratory signal-level

  conditions.  So, keep the levels very modest indeed.




On Wed, Mar 23, 2016 at 9:35 PM Derek Kozel > wrote:


Hello Tom,

The input power to the USRP daughterboard should not be above
-15dBm. I would recommend putting as much attenuation as you have
available inline and raising the gain until just before a timesink
shows the signal clipping, as Andy says having the maximum
attenuation set will be raising your noise figure.

Regards,
Derek


On Wed, Mar 23, 2016 at 4:28 PM, Andy Walls
mailto:a...@silverblocksystems.net>>
wrote:


>  From:
> Tom Golden
>   Subject:
> Re: [Discuss-gnuradio] Ettus N210
> GMSK 9600
>  Date:
> Wed, 23 Mar 2016 13:14:18 -0600
>
>
__
> Here's my flow-graph along with a snapshot of the constellation and
> FFT.
>
>
> Thanks!!
> -Tom

Hi Tom,

A couple of things:

a) The polyphase resampler isn't going to work well without a
filter
definition in the taps field.

b) The constellation sink will not display anything meaningful
without
sample timing synchronization; it is not useful at its current
position
in the flowgraph.  The constellation sink also doesn't display
anything
useful for an FSK modulation normally; (G)MSK being an
exception, if
treating it like a PSK modulation vs. FSK.

c) You don't have any coarse or fine frequency
synchronization.  That
will cause you major problems, if trying to treat GMSK as a PSK
modulation.  It will cause you minor problems, if treating
GMSK as an
FSK modulation.

d) Timing recovery blocks usually want a signal that has peaks
(which
you get by putting the signal through a matched filter), and
those peaks
should nominally be scaled to +/- 1.0.  You don't have a
matched filter
or an AGC before the Clock Recovery block.

e) The USRP's 0 dB gain setting is actually the USRP inserting the
maximum attenuation it can (e.g. 37 dB of attenuation). That
can kill
your signal to noise ratio.  You may want to consider adding
"gain" as
long as the time domain signal doesn't look clipped (sometimes
hard to
tell with FSK).

f) You may wish to look at what Nick Foster's gr-ais does to
demodulate
a 9600 baud GMSK AIS signal.  It will probably give you a nice
starting
point; just ignore the stuff about correlating to a preamble.
https://github.com/bistromath/gr-ais

If you share your datafile somewhere, I might be inspired to
whip a
flowgraph that works on it. :)  But that could rob you of the
learning
process.

Regards,
Andy

>
> On Wed, Mar 23, 2016 at 1:01 PM, Marcus D. Leech

> wrote:
> On 

Re: [Discuss-gnuradio] Ettus N210 GMSK 9600

[Tom Golden]

Thanks Andy!!  This is great!  The demo data looks good.  Running my data
through it doesn't generate the bits I'm looking for, but I can see the
noise affecting the symbols.  Tomorrow I'll retry with a better signal.

Many many thanks!

Best Regards,
-Tom


On Wed, Mar 23, 2016 at 7:34 PM, Andy Walls 
wrote:

> On Wed, 2016-03-23 at 18:41 -0600, Tom Golden wrote:
> > Hi Andy,
>
> >
> >
> > Thanks so much for the link!  I'm digging into the gr-ais code - but
> > there's certainly a learning curve there. :)
> >
> >
> > Thanks!!
> > -Tom
>
> Hi Tom,
>
> Here's a GRC that does 9600 baud GMSK demodulation, that I whipped up
> without using your data file.
>
> To run it with the "square and sync" coarse frequency adjustment branch
> in place, you'll need the freqest block from gr-ais, and the attached
> ais_frequest.xml file, since it doesn't exist in gr-ais.  If you know
> you're on freq, you can just disable the blocks in that branch, and
> bypass the multiply that applies the coarse frequency correction.
>
>
> So a fun(?) thing you should notice about this flowgraph's output.  You
> can obviously see the GMSK soft signal before timing recovery is a 4
> level signal, because ISI drags some bits closer to 0 freq deviation.
> But the timing recovery block is outputting 6 levels.  It's getting the
> timing of some of the bits slightly wrong.  That has implications for
> achievable BER for the SNR.
>
> Regards,
> Andy
>
> >
> >
> > On Wed, Mar 23, 2016 at 5:28 PM, Andy Walls
> >  wrote:
> >
> > >  From:
> > > Tom Golden
> > >   Subject:
> > > Re: [Discuss-gnuradio] Ettus N210
> > > GMSK 9600
> > >  Date:
> > > Wed, 23 Mar 2016 13:14:18 -0600
> > >
> > >
> >
>  __
> > > Here's my flow-graph along with a snapshot of the
> > constellation and
> > > FFT.
> > >
> > >
> > > Thanks!!
> > > -Tom
> >
> > Hi Tom,
> >
> > A couple of things:
> >
> > a) The polyphase resampler isn't going to work well without a
> > filter
> > definition in the taps field.
> >
> > b) The constellation sink will not display anything meaningful
> > without
> > sample timing synchronization; it is not useful at its current
> > position
> > in the flowgraph.  The constellation sink also doesn't display
> > anything
> > useful for an FSK modulation normally; (G)MSK being an
> > exception, if
> > treating it like a PSK modulation vs. FSK.
> >
> > c) You don't have any coarse or fine frequency
> > synchronization.  That
> > will cause you major problems, if trying to treat GMSK as a
> > PSK
> > modulation.  It will cause you minor problems, if treating
> > GMSK as an
> > FSK modulation.
> >
> > d) Timing recovery blocks usually want a signal that has peaks
> > (which
> > you get by putting the signal through a matched filter), and
> > those peaks
> > should nominally be scaled to +/- 1.0.  You don't have a
> > matched filter
> > or an AGC before the Clock Recovery block.
> >
> > e) The USRP's 0 dB gain setting is actually the USRP inserting
> > the
> > maximum attenuation it can (e.g. 37 dB of attenuation).  That
> > can kill
> > your signal to noise ratio.  You may want to consider adding
> > "gain" as
> > long as the time domain signal doesn't look clipped (sometimes
> > hard to
> > tell with FSK).
> >
> > f) You may wish to look at what Nick Foster's gr-ais does to
> > demodulate
> > a 9600 baud GMSK AIS signal.  It will probably give you a nice
> > starting
> > point; just ignore the stuff about correlating to a preamble.
> > https://github.com/bistromath/gr-ais
> >
> > If you share your datafile somewhere, I might be inspired to
> > whip a
> > flowgraph that works on it. :)  But that could rob you of the
> > learning
> > process.
> >
> > Regards,
> > Andy
> >
> > >
> > > On Wed, Mar 23, 2016 at 1:01 PM, Marcus D. Leech
> > 
> > > wrote:
> > > On 03/23/2016 02:48 PM, Tom Golden wrote:
> > > Hi,
> > >
> > > I'm a novice gnu radio user.  I'm using
> > gnuradio with
> > > an Ettus N210 cabled to a modem transmitting
> > GMSK
> > > 9600bps.  This is just for a test to verify
> > the modem
> > > transmit bits.
> > >
> > > I'm having issues with resampling.  Th

Re: [Discuss-gnuradio] Ettus N210 GMSK 9600

[Dan CaJacob]

Derek is spot on.  0 dB into any USRP is screaming loud.  Most of the units
are very sensitive, so it's perfectly fine to err on the side of too much
attenuation to start and dial the gain as you need.  It depends on the USRP
type, but signals much above -15dB can physically damage the hardware if
you set the gain too high.

On Wed, Mar 23, 2016 at 9:35 PM Derek Kozel  wrote:

> Hello Tom,
>
> The input power to the USRP daughterboard should not be above -15dBm. I
> would recommend putting as much attenuation as you have available inline
> and raising the gain until just before a timesink shows the signal
> clipping, as Andy says having the maximum attenuation set will be raising
> your noise figure.
>
> Regards,
> Derek
>
>
> On Wed, Mar 23, 2016 at 4:28 PM, Andy Walls 
> wrote:
>
>>
>> >  From:
>> > Tom Golden
>> >   Subject:
>> > Re: [Discuss-gnuradio] Ettus N210
>> > GMSK 9600
>> >  Date:
>> > Wed, 23 Mar 2016 13:14:18 -0600
>> >
>> > __
>> > Here's my flow-graph along with a snapshot of the constellation and
>> > FFT.
>> >
>> >
>> > Thanks!!
>> > -Tom
>>
>> Hi Tom,
>>
>> A couple of things:
>>
>> a) The polyphase resampler isn't going to work well without a filter
>> definition in the taps field.
>>
>> b) The constellation sink will not display anything meaningful without
>> sample timing synchronization; it is not useful at its current position
>> in the flowgraph.  The constellation sink also doesn't display anything
>> useful for an FSK modulation normally; (G)MSK being an exception, if
>> treating it like a PSK modulation vs. FSK.
>>
>> c) You don't have any coarse or fine frequency synchronization.  That
>> will cause you major problems, if trying to treat GMSK as a PSK
>> modulation.  It will cause you minor problems, if treating GMSK as an
>> FSK modulation.
>>
>> d) Timing recovery blocks usually want a signal that has peaks (which
>> you get by putting the signal through a matched filter), and those peaks
>> should nominally be scaled to +/- 1.0.  You don't have a matched filter
>> or an AGC before the Clock Recovery block.
>>
>> e) The USRP's 0 dB gain setting is actually the USRP inserting the
>> maximum attenuation it can (e.g. 37 dB of attenuation).  That can kill
>> your signal to noise ratio.  You may want to consider adding "gain" as
>> long as the time domain signal doesn't look clipped (sometimes hard to
>> tell with FSK).
>>
>> f) You may wish to look at what Nick Foster's gr-ais does to demodulate
>> a 9600 baud GMSK AIS signal.  It will probably give you a nice starting
>> point; just ignore the stuff about correlating to a preamble.
>> https://github.com/bistromath/gr-ais
>>
>> If you share your datafile somewhere, I might be inspired to whip a
>> flowgraph that works on it. :)  But that could rob you of the learning
>> process.
>>
>> Regards,
>> Andy
>>
>> >
>> > On Wed, Mar 23, 2016 at 1:01 PM, Marcus D. Leech 
>> > wrote:
>> > On 03/23/2016 02:48 PM, Tom Golden wrote:
>> > Hi,
>> >
>> > I'm a novice gnu radio user.  I'm using gnuradio with
>> > an Ettus N210 cabled to a modem transmitting GMSK
>> > 9600bps.  This is just for a test to verify the modem
>> > transmit bits.
>> >
>> > I'm having issues with resampling.  The N210 clock
>> > can't be set to a multiple of 9600, so I'm attempting
>> > to resample. I've tried various mechanisms but the
>> > output after resampling to 96000 is too noisy to
>> > successfully decode bits.  I've tried the GMSK demod
>> > block as well as the combination of Quadrature
>> > Demod->Clock Recovery MM->Binary Slicer - and neither
>> > works.
>> >
>> > I've also played with the Polyphase clock sync but I
>> > don't see any noticeable difference. Can anyone
>> > recommend a solution?
>> >
>> > Thanks!!
>> > -Tom
>> >
>> > For a first step, it would be useful for you to share your
>> > flow-graph with the list.
>>
>>
>>
>> ___
>> 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
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] Handling of IQ files

[Derek Kozel]

Hi Henry,

Take a look at the fftw library. It's very well regarded and looks to have
C# wrappers.

Regards,
Derek

On Wed, Mar 23, 2016 at 3:30 PM, Henry Barton  wrote:

> I'm planning to write my program from scratch in C#. I understand the
> basics of the FFT now; I had always wondered how transient signals would
> show up in a window if they were significantly shorter than the time
> covered by an FFT window, and I see now that there is a tradeoff: more
> samples = higher frequency precision but fewer FFT windows can be drawn.
> I've observed this in HDSDR where RBW can be either frequency-precise or do
> fast windowing. But as everyone says, the FFT is tremendously complex, so I
> will probably use a 3rd-party library. I'm currently working out how to use
> the AForge .NET library.
>
>
> > Date: Tue, 22 Mar 2016 09:20:41 +0100
> > From: vitt...@gmail.com
> > To: discuss-gnuradio@gnu.org
> > Subject: Re: [Discuss-gnuradio] Handling of IQ files
>
> >
> > Happy to read you replay Henry!
> > Feel free to rip/change/upgrade my work, but let me know about ur
> progress, pse!
> > Remember that it's fairly resource hungry ( file larger that 250 Mb
> > crashes the app also on my I7/16Gb), but it's a starting point.
> > I think that with GNURADIO it's possible to refine this task... I've a
> > lot to study!
> >
> > Victor I3VFJ
> >
> > 2016-03-21 20:45 GMT+01:00 Henry Barton :
> > > I like the concept of your program. It looks just like what I’m trying
> to
> > > write.
> > >
> > > Sent from Windows Mail
> > >
> > > From: Vitt Benv
> > > Sent: ‎Sunday‎, ‎March‎ ‎20‎, ‎2016 ‎4‎:‎16‎ ‎PM
> > > To: discuss-gnuradio@gnu.org
> > >
> > > Hi,
> > > this [ https://sourceforge.net/projects/automodrecog/ ] is my little
> > > effort about handling IQ files.
> > > The input IQ file is recorded with HDSDR, very nice piece of sw, that
> > > as a good recording scheduler. By the way the file provided can be
> > > played with it. I do also some tests with IQ file produced by R&S
> > > EM100 receiver.
> > > I wrote this [horrible] application for personal use and it's very raw
> > > IMO
> > > I'm interested on HF monitoring and the main goal is to find SSB
> > > emission along time, not quite simple task.
> > >
> > > In brief:
> > > - read params from input file
> > > - split it in smaller chunk and save FFT for each chunk
> > > - sum (maxhold) or avg (average) all the FFTs
> > > - find relevant ( over threshold) carrier and try to "pack" them to
> > > find "bandwidth" associated
> > > - build a report as .html page with a .png file that represent the
> result.
> > >
> > > The most difficult part is to estimate the best "threshold", and at
> > > the moment I'm almost stuck there and moreover RL reclaims my
> > > presence :-)
> > >
> > > ... my euro "cent" on the subject.
> > >
> > > Victor I3VFJ
> > >
> > > ___
> > > Discuss-gnuradio mailing list
> > > Discuss-gnuradio@gnu.org
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > >
> > > ___
> > > Discuss-gnuradio mailing list
> > > Discuss-gnuradio@gnu.org
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Ettus N210 GMSK 9600

[Andy Walls]

On Wed, 2016-03-23 at 18:41 -0600, Tom Golden wrote:
> Hi Andy,

> 
> 
> Thanks so much for the link!  I'm digging into the gr-ais code - but
> there's certainly a learning curve there. :)
> 
> 
> Thanks!!
> -Tom

Hi Tom,

Here's a GRC that does 9600 baud GMSK demodulation, that I whipped up
without using your data file.

To run it with the "square and sync" coarse frequency adjustment branch
in place, you'll need the freqest block from gr-ais, and the attached
ais_frequest.xml file, since it doesn't exist in gr-ais.  If you know
you're on freq, you can just disable the blocks in that branch, and
bypass the multiply that applies the coarse frequency correction.


So a fun(?) thing you should notice about this flowgraph's output.  You
can obviously see the GMSK soft signal before timing recovery is a 4
level signal, because ISI drags some bits closer to 0 freq deviation.
But the timing recovery block is outputting 6 levels.  It's getting the
timing of some of the bits slightly wrong.  That has implications for
achievable BER for the SNR.

Regards,
Andy

> 
> 
> On Wed, Mar 23, 2016 at 5:28 PM, Andy Walls
>  wrote:
> 
> >  From:
> > Tom Golden
> >   Subject:
> > Re: [Discuss-gnuradio] Ettus N210
> > GMSK 9600
> >  Date:
> > Wed, 23 Mar 2016 13:14:18 -0600
> >
> >
> __
> > Here's my flow-graph along with a snapshot of the
> constellation and
> > FFT.
> >
> >
> > Thanks!!
> > -Tom
> 
> Hi Tom,
> 
> A couple of things:
> 
> a) The polyphase resampler isn't going to work well without a
> filter
> definition in the taps field.
> 
> b) The constellation sink will not display anything meaningful
> without
> sample timing synchronization; it is not useful at its current
> position
> in the flowgraph.  The constellation sink also doesn't display
> anything
> useful for an FSK modulation normally; (G)MSK being an
> exception, if
> treating it like a PSK modulation vs. FSK.
> 
> c) You don't have any coarse or fine frequency
> synchronization.  That
> will cause you major problems, if trying to treat GMSK as a
> PSK
> modulation.  It will cause you minor problems, if treating
> GMSK as an
> FSK modulation.
> 
> d) Timing recovery blocks usually want a signal that has peaks
> (which
> you get by putting the signal through a matched filter), and
> those peaks
> should nominally be scaled to +/- 1.0.  You don't have a
> matched filter
> or an AGC before the Clock Recovery block.
> 
> e) The USRP's 0 dB gain setting is actually the USRP inserting
> the
> maximum attenuation it can (e.g. 37 dB of attenuation).  That
> can kill
> your signal to noise ratio.  You may want to consider adding
> "gain" as
> long as the time domain signal doesn't look clipped (sometimes
> hard to
> tell with FSK).
> 
> f) You may wish to look at what Nick Foster's gr-ais does to
> demodulate
> a 9600 baud GMSK AIS signal.  It will probably give you a nice
> starting
> point; just ignore the stuff about correlating to a preamble.
> https://github.com/bistromath/gr-ais
> 
> If you share your datafile somewhere, I might be inspired to
> whip a
> flowgraph that works on it. :)  But that could rob you of the
> learning
> process.
> 
> Regards,
> Andy
> 
> >
> > On Wed, Mar 23, 2016 at 1:01 PM, Marcus D. Leech
> 
> > wrote:
> > On 03/23/2016 02:48 PM, Tom Golden wrote:
> > Hi,
> >
> > I'm a novice gnu radio user.  I'm using
> gnuradio with
> > an Ettus N210 cabled to a modem transmitting
> GMSK
> > 9600bps.  This is just for a test to verify
> the modem
> > transmit bits.
> >
> > I'm having issues with resampling.  The N210
> clock
> > can't be set to a multiple of 9600, so I'm
> attempting
> > to resample. I've tried various mechanisms
> but the
> > output after resampling to 96000 is too
> noisy to
> > successfully decode bits.  I've tried the
> GMSK demod
> > block as well as the combination of
>

Re: [Discuss-gnuradio] Ettus N210 GMSK 9600

[Derek Kozel]

Hello Tom,

The input power to the USRP daughterboard should not be above -15dBm. I
would recommend putting as much attenuation as you have available inline
and raising the gain until just before a timesink shows the signal
clipping, as Andy says having the maximum attenuation set will be raising
your noise figure.

Regards,
Derek


On Wed, Mar 23, 2016 at 4:28 PM, Andy Walls 
wrote:

>
> >  From:
> > Tom Golden
> >   Subject:
> > Re: [Discuss-gnuradio] Ettus N210
> > GMSK 9600
> >  Date:
> > Wed, 23 Mar 2016 13:14:18 -0600
> >
> > __
> > Here's my flow-graph along with a snapshot of the constellation and
> > FFT.
> >
> >
> > Thanks!!
> > -Tom
>
> Hi Tom,
>
> A couple of things:
>
> a) The polyphase resampler isn't going to work well without a filter
> definition in the taps field.
>
> b) The constellation sink will not display anything meaningful without
> sample timing synchronization; it is not useful at its current position
> in the flowgraph.  The constellation sink also doesn't display anything
> useful for an FSK modulation normally; (G)MSK being an exception, if
> treating it like a PSK modulation vs. FSK.
>
> c) You don't have any coarse or fine frequency synchronization.  That
> will cause you major problems, if trying to treat GMSK as a PSK
> modulation.  It will cause you minor problems, if treating GMSK as an
> FSK modulation.
>
> d) Timing recovery blocks usually want a signal that has peaks (which
> you get by putting the signal through a matched filter), and those peaks
> should nominally be scaled to +/- 1.0.  You don't have a matched filter
> or an AGC before the Clock Recovery block.
>
> e) The USRP's 0 dB gain setting is actually the USRP inserting the
> maximum attenuation it can (e.g. 37 dB of attenuation).  That can kill
> your signal to noise ratio.  You may want to consider adding "gain" as
> long as the time domain signal doesn't look clipped (sometimes hard to
> tell with FSK).
>
> f) You may wish to look at what Nick Foster's gr-ais does to demodulate
> a 9600 baud GMSK AIS signal.  It will probably give you a nice starting
> point; just ignore the stuff about correlating to a preamble.
> https://github.com/bistromath/gr-ais
>
> If you share your datafile somewhere, I might be inspired to whip a
> flowgraph that works on it. :)  But that could rob you of the learning
> process.
>
> Regards,
> Andy
>
> >
> > On Wed, Mar 23, 2016 at 1:01 PM, Marcus D. Leech 
> > wrote:
> > On 03/23/2016 02:48 PM, Tom Golden wrote:
> > Hi,
> >
> > I'm a novice gnu radio user.  I'm using gnuradio with
> > an Ettus N210 cabled to a modem transmitting GMSK
> > 9600bps.  This is just for a test to verify the modem
> > transmit bits.
> >
> > I'm having issues with resampling.  The N210 clock
> > can't be set to a multiple of 9600, so I'm attempting
> > to resample. I've tried various mechanisms but the
> > output after resampling to 96000 is too noisy to
> > successfully decode bits.  I've tried the GMSK demod
> > block as well as the combination of Quadrature
> > Demod->Clock Recovery MM->Binary Slicer - and neither
> > works.
> >
> > I've also played with the Polyphase clock sync but I
> > don't see any noticeable difference. Can anyone
> > recommend a solution?
> >
> > Thanks!!
> > -Tom
> >
> > For a first step, it would be useful for you to share your
> > flow-graph with the list.
>
>
>
> ___
> 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 CtrlPort pygraphviz dependency

[Tom Rondeau]

On Wed, Mar 23, 2016 at 8:37 PM, Martin Braun 
wrote:

> Yes, submit a new recipe, but I'm not sure about making it a GNU Radio
> dependency. I haven't fully understood who needs and it if it's a soft
> requirement or a hard requirement.
>
> Cheers,
> Martin


I agree. It shouldn't be a hard requirement of GNU Radio. However, making
it a recipe and dependency in PyBOMBS is a very simple, mostly harmless(TM)
thing to do.

Tom




>
> On 03/23/2016 12:55 PM, West, Nathan wrote:
> > Yes. See twisted, python-zmq, and sip for similar types of packages.
> >
> > On Wed, Mar 23, 2016 at 3:44 PM, Laur Joost  > > wrote:
> >
> > To be clear: since there's no networkx recipe, should I just create
> > one, and add it to gnuradio dependencies?
> >
> > Laur
> >
> > 2016-03-23 20:45 GMT+02:00 Laur Joost  > >:
> >
> > Martin: I'm rebuilding from scratch this night. I'll modify the
> > recipe for networkx before starting, and if it works, I'll..
> > what? submit a pull request? Well, first time for everything.
> >
> > Nathan: As in, installing graphviz and pygraphviz should have
> > been dependencies for networkx, not something we should need to
> > worry about? Yeah, probably makes sense.
> >
> > All the best
> > Laur
> >
> > 2016-03-23 19:50 GMT+02:00 West, Nathan
> > mailto:n...@ostatemail.okstate.edu
> >>:
> >
> > It sounds like networkx is only part of the issue and maybe
> > there's an upstream bug that Tom has patched over locally.
> > Is this something we should report upstream to the distros?
> >
> >
> > On Wednesday, March 23, 2016, Martin Braun
> > mailto:martin.br...@ettus.com>>
> wrote:
> >
> > Laur,
> >
> > can you please submit a recipe to gr-recipes for
> networkx?
> >
> > Thanks,
> > Martin
> >
> > On 03/23/2016 01:50 AM, Laur Joost wrote:
> > > Thanks for the responses, and damned be the timezones.
> > >
> > > Nathan: gr-perf-monitorx needs python-networkx (which
> > is installed by
> > > pybombs, or at least, existed for me), but
> > python-networkx needs
> > > python-pygraphviz, at least for how it's used by
> > gr-perf-monitorx.
> > >
> > > Tom: Yes, the errors popped up when networkx called
> > agraph-something.
> > > Sadly, I managed to blow up my installation, so can't
> > get a traceback
> > > for you (was able to reproduce by simply doing apt-get
> > uninstall graphviz).
> > >
> > > On another note (the blowing up), I had an issue with
> > gr-uhd ABI versions:
> > > When trying to use USRP on the same install, I got:
> > >
> > > Traceback (most recent call last):
> > >   File "/home/ec/Tests/top_block.py", line 167, in
> > 
> > > main()
> > >   File "/home/ec/Tests/top_block.py", line 155, in main
> > > tb = top_block_cls()
> > >   File "/home/ec/Tests/top_block.py", line 69, in
> __init__
> > > channels=range(1),
> > >   File
> > >
> >
>  "/home/ec/gnuradio/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py",
> > line
> > > 122, in constructor_interceptor
> > > return old_constructor(*args)
> > >   File
> > >
> >
>  "/home/ec/gnuradio/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
> > line
> > > 1973, in make
> > > return _uhd_swig.usrp_source_make(*args)
> > > RuntimeError:
> > > GR-UHD detected ABI compatibility mismatch with UHD
> > library.
> > > GR-UHD was build against ABI: 3.9.0-0,
> > > but UHD library reports ABI: 3.10.0-0
> > > Suggestion: install an ABI compatible version of UHD,
> > > or rebuild GR-UHD component against this ABI version.
> > >
> > > However, install log shows:
> > >
> > > Configuring gr-uhd support...
> > > --   Dependency Boost_FOUND = 1
> > > --   Dependency UHD_FOUND = TRUE
> > > --   Dependency ENABLE_GNURADIO_RUNTIME = ON
> > > --   Dependency ENABLE_GR_FILTER = ON
> > > --   Dependency ENABLE_GR_BLOCKS = ON
> > > --   Dependency ENABLE_GR_ANALOG = ON
> > > --   Enabl

Re: [Discuss-gnuradio] uhd_fft seg fault

[Marcus D. Leech]

On 03/23/2016 07:46 PM, Daniel R. Marlow wrote:

Hello,

   H/W:  Intel(R) Core(TM) i5-4430 CPU @ 3.00GHz
USRP:  Ettus B210
 OS:  Ubuntu 15.04
gnuradio:  3.7.5

The most recent step was to do a simple binary install of uhd-host and 
gnradio using

   > sudo apt-get install uhd-host
   > sudo apt-get install gnuradio

All seemed to work OK.
> uhd_usrp_probe
works as expected (displays info about B210)

However, when I try to run
 > uhd_fft -f 1420M
 the program seg fautls.

 The same is true when I try

 > gnuradio-companion
 and also
 > python top_block_ex.py
  where top_block_ex.py is a known-to-work module from another project.

See the screen dump below.   I don't believe it's a windows issue, since 
other apps open windows without problems. Full disclosure:  installation of 
the binaries was preceded with a PyBOMBS installation (which seemed to go OK, 
except that uhd_usrp_probe was not found)

Any suggestions would be most appreciated.   (Sorry if this is hopelessly 
naive.)

--Dan Marlow
Could you try a simple "sudo ldconfig" after doing those apt-based 
installs? Does that fix the issue?






marlow@sdr3:~/21cm$ uhd_fft -1420M
Segmentation fault (core dumped)
marlow@sdr3:~/21cm$ gnuradio-companion
Segmentation fault (core dumped)
marlow@sdr3:~/21cm$ python top_block_ex.py
Segmentation fault (core dumped)
marlow@sdr3:~/21cm$




  
___

Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listin


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

Re: [Discuss-gnuradio] PYBOMBS CtrlPort pygraphviz dependency

[Martin Braun]

Yes, submit a new recipe, but I'm not sure about making it a GNU Radio
dependency. I haven't fully understood who needs and it if it's a soft
requirement or a hard requirement.

Cheers,
Martin

On 03/23/2016 12:55 PM, West, Nathan wrote:
> Yes. See twisted, python-zmq, and sip for similar types of packages.
> 
> On Wed, Mar 23, 2016 at 3:44 PM, Laur Joost  > wrote:
> 
> To be clear: since there's no networkx recipe, should I just create
> one, and add it to gnuradio dependencies?
> 
> Laur
> 
> 2016-03-23 20:45 GMT+02:00 Laur Joost  >:
> 
> Martin: I'm rebuilding from scratch this night. I'll modify the
> recipe for networkx before starting, and if it works, I'll..
> what? submit a pull request? Well, first time for everything.
> 
> Nathan: As in, installing graphviz and pygraphviz should have
> been dependencies for networkx, not something we should need to
> worry about? Yeah, probably makes sense.
> 
> All the best
> Laur
> 
> 2016-03-23 19:50 GMT+02:00 West, Nathan
> mailto:n...@ostatemail.okstate.edu>>:
> 
> It sounds like networkx is only part of the issue and maybe
> there's an upstream bug that Tom has patched over locally.
> Is this something we should report upstream to the distros?
> 
> 
> On Wednesday, March 23, 2016, Martin Braun
> mailto:martin.br...@ettus.com>> wrote:
> 
> Laur,
> 
> can you please submit a recipe to gr-recipes for networkx?
> 
> Thanks,
> Martin
> 
> On 03/23/2016 01:50 AM, Laur Joost wrote:
> > Thanks for the responses, and damned be the timezones.
> >
> > Nathan: gr-perf-monitorx needs python-networkx (which
> is installed by
> > pybombs, or at least, existed for me), but
> python-networkx needs
> > python-pygraphviz, at least for how it's used by
> gr-perf-monitorx.
> >
> > Tom: Yes, the errors popped up when networkx called
> agraph-something.
> > Sadly, I managed to blow up my installation, so can't
> get a traceback
> > for you (was able to reproduce by simply doing apt-get
> uninstall graphviz).
> >
> > On another note (the blowing up), I had an issue with
> gr-uhd ABI versions:
> > When trying to use USRP on the same install, I got:
> >
> > Traceback (most recent call last):
> >   File "/home/ec/Tests/top_block.py", line 167, in
> 
> > main()
> >   File "/home/ec/Tests/top_block.py", line 155, in main
> > tb = top_block_cls()
> >   File "/home/ec/Tests/top_block.py", line 69, in __init__
> > channels=range(1),
> >   File
> >
> 
> "/home/ec/gnuradio/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py",
> line
> > 122, in constructor_interceptor
> > return old_constructor(*args)
> >   File
> >
> 
> "/home/ec/gnuradio/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
> line
> > 1973, in make
> > return _uhd_swig.usrp_source_make(*args)
> > RuntimeError:
> > GR-UHD detected ABI compatibility mismatch with UHD
> library.
> > GR-UHD was build against ABI: 3.9.0-0,
> > but UHD library reports ABI: 3.10.0-0
> > Suggestion: install an ABI compatible version of UHD,
> > or rebuild GR-UHD component against this ABI version.
> >
> > However, install log shows:
> >
> > Configuring gr-uhd support...
> > --   Dependency Boost_FOUND = 1
> > --   Dependency UHD_FOUND = TRUE
> > --   Dependency ENABLE_GNURADIO_RUNTIME = ON
> > --   Dependency ENABLE_GR_FILTER = ON
> > --   Dependency ENABLE_GR_BLOCKS = ON
> > --   Dependency ENABLE_GR_ANALOG = ON
> > --   Enabling gr-uhd support.
> > --   Override with -DENABLE_GR_UHD=ON/OFF
> > --   UHD Version: 3.10.git
> >
> > I had UHD 3.9.1 installed via package manager (wasn't
> as thorough as I'd
> > hoped in cleaning gnuradio 3.7.8 from the system), but
> if the detected
> > version in the log

[Discuss-gnuradio] uhd_fft seg fault

[Daniel R. Marlow]

Hello,

  H/W:  Intel(R) Core(TM) i5-4430 CPU @ 3.00GHz
   USRP:  Ettus B210 
OS:  Ubuntu 15.04
gnuradio:  3.7.5

   The most recent step was to do a simple binary install of uhd-host and 
gnradio using

  > sudo apt-get install uhd-host
  > sudo apt-get install gnuradio

   All seemed to work OK. 
   > uhd_usrp_probe 
   works as expected (displays info about B210)

   However, when I try to run 
> uhd_fft -f 1420M
the program seg fautls.
   
The same is true when I try 
> gnuradio-companion
and also
> python top_block_ex.py
 where top_block_ex.py is a known-to-work module from another project.

   See the screen dump below.   I don't believe it's a windows issue, since 
other apps open windows without problems. Full disclosure:  installation of 
the binaries was preceded with a PyBOMBS installation (which seemed to go OK, 
except that uhd_usrp_probe was not found)

   Any suggestions would be most appreciated.   (Sorry if this is hopelessly 
naive.)

--Dan Marlow


marlow@sdr3:~/21cm$ uhd_fft -1420M
Segmentation fault (core dumped)
marlow@sdr3:~/21cm$ gnuradio-companion 
Segmentation fault (core dumped)
marlow@sdr3:~/21cm$ python top_block_ex.py
Segmentation fault (core dumped)
marlow@sdr3:~/21cm$ 




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

[Discuss-gnuradio] SDRA-2015 recordings available

[Markus Heller]

Dear list,

the SDRA-2015 recordings are available now, with gratutude to Mika
Kjellman who did the cutting. 

Here is the SDRA 2015 website: http://www.sdra-2015.de

Here is the playlist, covering the entire day in the according sequence:

https://www.youtube.com/watch?v=SX2Qq8Bi6VA&list=PL6D0CPBQoIVpGesCCezfOfPZ6a7b-QEan

And here is the link to the SDRA Youtube-Channel:

https://www.youtube.com/channel/UC1GAlgAQrkjeeLmIkCB8pgQ

I would also like to point your attention to the current Call for Papers
for the SDRA-2016 taking place on Saturday June 25 in Friedrichshafen:

http://www.sdra-2016.de

vy73
markus
dl8rds


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

Re: [Discuss-gnuradio] Ettus N210 GMSK 9600

[Andy Walls]

>  From: 
> Tom Golden
>   Subject: 
> Re: [Discuss-gnuradio] Ettus N210
> GMSK 9600
>  Date: 
> Wed, 23 Mar 2016 13:14:18 -0600
> 
> __
> Here's my flow-graph along with a snapshot of the constellation and
> FFT.
> 
> 
> Thanks!!
> -Tom

Hi Tom,

A couple of things:

a) The polyphase resampler isn't going to work well without a filter
definition in the taps field.

b) The constellation sink will not display anything meaningful without
sample timing synchronization; it is not useful at its current position
in the flowgraph.  The constellation sink also doesn't display anything
useful for an FSK modulation normally; (G)MSK being an exception, if
treating it like a PSK modulation vs. FSK.

c) You don't have any coarse or fine frequency synchronization.  That
will cause you major problems, if trying to treat GMSK as a PSK
modulation.  It will cause you minor problems, if treating GMSK as an
FSK modulation.

d) Timing recovery blocks usually want a signal that has peaks (which
you get by putting the signal through a matched filter), and those peaks
should nominally be scaled to +/- 1.0.  You don't have a matched filter
or an AGC before the Clock Recovery block.

e) The USRP's 0 dB gain setting is actually the USRP inserting the
maximum attenuation it can (e.g. 37 dB of attenuation).  That can kill
your signal to noise ratio.  You may want to consider adding "gain" as
long as the time domain signal doesn't look clipped (sometimes hard to
tell with FSK).

f) You may wish to look at what Nick Foster's gr-ais does to demodulate
a 9600 baud GMSK AIS signal.  It will probably give you a nice starting
point; just ignore the stuff about correlating to a preamble.
https://github.com/bistromath/gr-ais

If you share your datafile somewhere, I might be inspired to whip a
flowgraph that works on it. :)  But that could rob you of the learning
process.

Regards,
Andy

> 
> On Wed, Mar 23, 2016 at 1:01 PM, Marcus D. Leech 
> wrote:
> On 03/23/2016 02:48 PM, Tom Golden wrote:
> Hi,
> 
> I'm a novice gnu radio user.  I'm using gnuradio with
> an Ettus N210 cabled to a modem transmitting GMSK
> 9600bps.  This is just for a test to verify the modem
> transmit bits.
> 
> I'm having issues with resampling.  The N210 clock
> can't be set to a multiple of 9600, so I'm attempting
> to resample. I've tried various mechanisms but the
> output after resampling to 96000 is too noisy to
> successfully decode bits.  I've tried the GMSK demod
> block as well as the combination of Quadrature
> Demod->Clock Recovery MM->Binary Slicer - and neither
> works.
> 
> I've also played with the Polyphase clock sync but I
> don't see any noticeable difference. Can anyone
> recommend a solution?
> 
> Thanks!!
> -Tom
> 
> For a first step, it would be useful for you to share your
> flow-graph with the list.



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

Re: [Discuss-gnuradio] Handling of IQ files

[Henry Barton]

I'm planning to write my program from scratch in C#. I understand the basics of 
the FFT now; I had always wondered how transient signals would show up in a 
window if they were significantly shorter than the time covered by an FFT 
window, and I see now that there is a tradeoff: more samples = higher frequency 
precision but fewer FFT windows can be drawn. I've observed this in HDSDR where 
RBW can be either frequency-precise or do fast windowing. But as everyone says, 
the FFT is tremendously complex, so I will probably use a 3rd-party library. 
I'm currently working out how to use the AForge .NET library.> Date: Tue, 22 
Mar 2016 09:20:41 +0100
> From: vitt...@gmail.com
> To: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Handling of IQ files
> 
> Happy to read you replay Henry!
> Feel free to rip/change/upgrade my work, but let me know about ur progress, 
> pse!
> Remember that it's fairly resource hungry ( file larger that 250 Mb
> crashes the app also on my I7/16Gb), but it's a starting point.
> I think that with GNURADIO it's possible to refine this task... I've a
> lot to study!
> 
> Victor I3VFJ
> 
> 2016-03-21 20:45 GMT+01:00 Henry Barton :
> > I like the concept of your program. It looks just like what I’m trying to
> > write.
> >
> > Sent from Windows Mail
> >
> > From: Vitt Benv
> > Sent: ‎Sunday‎, ‎March‎ ‎20‎, ‎2016 ‎4‎:‎16‎ ‎PM
> > To: discuss-gnuradio@gnu.org
> >
> > Hi,
> > this [ https://sourceforge.net/projects/automodrecog/ ] is my little
> > effort about handling IQ files.
> > The input IQ file is recorded with HDSDR, very nice piece of sw, that
> > as a good recording scheduler. By the way the file provided can be
> > played with it. I do also some tests with IQ file produced by R&S
> > EM100 receiver.
> > I wrote this [horrible] application for personal use and it's very raw
> > IMO
> > I'm interested on HF monitoring and the main goal is to find SSB
> > emission along time, not quite simple task.
> >
> > In brief:
> > - read params from input file
> > - split it in smaller chunk and save FFT for each chunk
> > - sum (maxhold) or avg (average) all the FFTs
> > - find relevant ( over threshold) carrier and try to "pack" them to
> > find "bandwidth" associated
> > - build a report as .html page with a .png file that represent the result.
> >
> > The most difficult part is to estimate the best "threshold", and at
> > the moment I'm almost stuck there and moreover RL reclaims my
> > presence :-)
> >
> > ... my euro "cent" on the subject.
> >
> > Victor I3VFJ
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[Discuss-gnuradio] Fwd: RF NoC Consulting

[John Malsbury]

-- Forwarded message --
From: John Malsbury 
Date: Wed, Mar 23, 2016 at 1:56 PM
Subject: RF NoC Consulting
To: "usrp-us...@lists.ettus.com" 


I may have a need to offload some RF NoC projects.  If you think you are an
expert in RF NoC and interested in some work, send me a message.

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

[Discuss-gnuradio] Embedding qtgui widgets inside QFrame

[West, Nathan]

I've got a really dumb UI made from qt4-designer, pythonized with pyuic4,
and an app that imports and creates the ui. Inside this app I make a
qtgui.time_sink_c and a qtgui.freq_sink_c. My UI has empty frames that I
place a sip-wrapped instance of the qtgui widgets in.

On one machine, let's call it pepper (running i3), the qtgui widgets load
up and the whole things displays/behaves nicely. On another machine, let's
call it saffron (running KDE), the UI shows up blank and I can't exit (have
to kill it from terminal).

Both machines have GNU Radio v3.7.9.1 on Debian 8.3 with the only major
software difference being KDE vs i3.

As a sanity check I use a third machine (let's not call it anything
special) also running Debian 8.3 and KDE which has the same issue as
saffron (no widgets displayed). Switching to gnome shows the same behavior.
Switching to i3 works (all widgets show up and qtgui widgets are
displayed). If I never create the qtgui widgets in KDE/Gnome then the other
widgets will show up. If I create the qtgui widgets, but don't do anything
with the I have the same issue (no other widgets show up)

Has anyone run in to this and if so how did you solve it? Does anyone know
what KDE/Gnome is doing to make qtgui widgets kill my UI? Run this script
to try it: https://github.com/n-west/gr-vsg/blob/master/vsg.py

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

Re: [Discuss-gnuradio] Ettus N210 GMSK 9600

[Tom Golden]

The modem's output is ~30dBm and I have ~30dB of attenuation.  I figured
that the FFT is showing a lot of power, so the gain wasn't necessary.

Thanks for the idea.  Implementing a LPF in front of the resampler doesn't
seem to make a difference though.




On Wed, Mar 23, 2016 at 1:29 PM, Marcus D. Leech  wrote:

> On 03/23/2016 03:14 PM, Tom Golden wrote:
>
> Here's my flow-graph along with a snapshot of the constellation and FFT.
>
> Thanks!!
> -Tom
>
> What output level is the RF modem producing?  Are you using attenuators
> between it and the RF input of the USRP?
>
> I note that you have the RF gain on your capture set to 0.
>
> Also, I don't recall whether the polyphase resampler requires that the
> input already be Nyquist-limited before it gets resampled.
>   I know some of the other resamplers do that, otherwise, you get aliases
> in your output passband.
>
> Since you're looking at a 9600BPS signal, you should probably have sampled
> this at 250ksps--the lowest rate possible with the N210--
>   that makes filtering later less computationally intensive.
>
>
>
>
> On Wed, Mar 23, 2016 at 1:01 PM, Marcus D. Leech 
> wrote:
>
>> On 03/23/2016 02:48 PM, Tom Golden wrote:
>>
>>> Hi,
>>>
>>> I'm a novice gnu radio user.  I'm using gnuradio with an Ettus N210
>>> cabled to a modem transmitting GMSK 9600bps.  This is just for a test to
>>> verify the modem transmit bits.
>>>
>>> I'm having issues with resampling.  The N210 clock can't be set to a
>>> multiple of 9600, so I'm attempting to resample. I've tried various
>>> mechanisms but the output after resampling to 96000 is too noisy to
>>> successfully decode bits.  I've tried the GMSK demod block as well as the
>>> combination of Quadrature Demod->Clock Recovery MM->Binary Slicer - and
>>> neither works.
>>>
>>> I've also played with the Polyphase clock sync but I don't see any
>>> noticeable difference. Can anyone recommend a solution?
>>>
>>> Thanks!!
>>> -Tom
>>>
>>> For a first step, it would be useful for you to share your flow-graph
>> with the list.
>>
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] PYBOMBS CtrlPort pygraphviz dependency

[West, Nathan]

Yes. See twisted, python-zmq, and sip for similar types of packages.

On Wed, Mar 23, 2016 at 3:44 PM, Laur Joost  wrote:

> To be clear: since there's no networkx recipe, should I just create one,
> and add it to gnuradio dependencies?
>
> Laur
>
> 2016-03-23 20:45 GMT+02:00 Laur Joost :
>
>> Martin: I'm rebuilding from scratch this night. I'll modify the recipe
>> for networkx before starting, and if it works, I'll.. what? submit a pull
>> request? Well, first time for everything.
>>
>> Nathan: As in, installing graphviz and pygraphviz should have been
>> dependencies for networkx, not something we should need to worry about?
>> Yeah, probably makes sense.
>>
>> All the best
>> Laur
>>
>> 2016-03-23 19:50 GMT+02:00 West, Nathan :
>>
>>> It sounds like networkx is only part of the issue and maybe there's an
>>> upstream bug that Tom has patched over locally. Is this something we should
>>> report upstream to the distros?
>>>
>>>
>>> On Wednesday, March 23, 2016, Martin Braun 
>>> wrote:
>>>
 Laur,

 can you please submit a recipe to gr-recipes for networkx?

 Thanks,
 Martin

 On 03/23/2016 01:50 AM, Laur Joost wrote:
 > Thanks for the responses, and damned be the timezones.
 >
 > Nathan: gr-perf-monitorx needs python-networkx (which is installed by
 > pybombs, or at least, existed for me), but python-networkx needs
 > python-pygraphviz, at least for how it's used by gr-perf-monitorx.
 >
 > Tom: Yes, the errors popped up when networkx called agraph-something.
 > Sadly, I managed to blow up my installation, so can't get a traceback
 > for you (was able to reproduce by simply doing apt-get uninstall
 graphviz).
 >
 > On another note (the blowing up), I had an issue with gr-uhd ABI
 versions:
 > When trying to use USRP on the same install, I got:
 >
 > Traceback (most recent call last):
 >   File "/home/ec/Tests/top_block.py", line 167, in 
 > main()
 >   File "/home/ec/Tests/top_block.py", line 155, in main
 > tb = top_block_cls()
 >   File "/home/ec/Tests/top_block.py", line 69, in __init__
 > channels=range(1),
 >   File
 >
 "/home/ec/gnuradio/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py",
 line
 > 122, in constructor_interceptor
 > return old_constructor(*args)
 >   File
 >
 "/home/ec/gnuradio/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
 line
 > 1973, in make
 > return _uhd_swig.usrp_source_make(*args)
 > RuntimeError:
 > GR-UHD detected ABI compatibility mismatch with UHD library.
 > GR-UHD was build against ABI: 3.9.0-0,
 > but UHD library reports ABI: 3.10.0-0
 > Suggestion: install an ABI compatible version of UHD,
 > or rebuild GR-UHD component against this ABI version.
 >
 > However, install log shows:
 >
 > Configuring gr-uhd support...
 > --   Dependency Boost_FOUND = 1
 > --   Dependency UHD_FOUND = TRUE
 > --   Dependency ENABLE_GNURADIO_RUNTIME = ON
 > --   Dependency ENABLE_GR_FILTER = ON
 > --   Dependency ENABLE_GR_BLOCKS = ON
 > --   Dependency ENABLE_GR_ANALOG = ON
 > --   Enabling gr-uhd support.
 > --   Override with -DENABLE_GR_UHD=ON/OFF
 > --   UHD Version: 3.10.git
 >
 > I had UHD 3.9.1 installed via package manager (wasn't as thorough as
 I'd
 > hoped in cleaning gnuradio 3.7.8 from the system), but if the detected
 > version in the log was 3.10, I would've thought that that would be the
 > version built against. I guess its mostly PEBKAC, but still, weird.
 >
 > I'll try building again this night, this time without 3.9 installed.
 If
 > the issue persists, I'll make another thread.
 >
 > 2016-03-23 1:30 GMT+02:00 Tom Rondeau >>> > >:
 >
 > On Tue, Mar 22, 2016 at 7:05 PM, West, Nathan
 > mailto:n...@ostatemail.okstate.edu
 >>
 > wrote:
 >
 > Sorry, may or may not be talking about the same thing here.
 > gr-perf-monitorx requires python-networkx, which (I think) is
 an
 > untracked dependency.
 >
 >
 >
 > For utilities like this, we have not previously made Python
 modules
 > a required dependency of GNU Radio. We could, but that would put
 an
 > extra burden on just building the project even if you don't use
 the
 > particular app or example. Generally, we try to provide a friendly
 > message explaining the problem. PyBOMBS probably should add these
 > dependencies, though. At least scipy.
 >
 > Also, I believe I ran into this issue recently new versions of
 > networkx that broke out a dependency that used to not be required
 as
 > a separate install, which I think is what the OP's problem is
 > related to. See PR #768:
 >
 > https://

Re: [Discuss-gnuradio] PYBOMBS CtrlPort pygraphviz dependency

[Laur Joost]

To be clear: since there's no networkx recipe, should I just create one,
and add it to gnuradio dependencies?

Laur

2016-03-23 20:45 GMT+02:00 Laur Joost :

> Martin: I'm rebuilding from scratch this night. I'll modify the recipe for
> networkx before starting, and if it works, I'll.. what? submit a pull
> request? Well, first time for everything.
>
> Nathan: As in, installing graphviz and pygraphviz should have been
> dependencies for networkx, not something we should need to worry about?
> Yeah, probably makes sense.
>
> All the best
> Laur
>
> 2016-03-23 19:50 GMT+02:00 West, Nathan :
>
>> It sounds like networkx is only part of the issue and maybe there's an
>> upstream bug that Tom has patched over locally. Is this something we should
>> report upstream to the distros?
>>
>>
>> On Wednesday, March 23, 2016, Martin Braun 
>> wrote:
>>
>>> Laur,
>>>
>>> can you please submit a recipe to gr-recipes for networkx?
>>>
>>> Thanks,
>>> Martin
>>>
>>> On 03/23/2016 01:50 AM, Laur Joost wrote:
>>> > Thanks for the responses, and damned be the timezones.
>>> >
>>> > Nathan: gr-perf-monitorx needs python-networkx (which is installed by
>>> > pybombs, or at least, existed for me), but python-networkx needs
>>> > python-pygraphviz, at least for how it's used by gr-perf-monitorx.
>>> >
>>> > Tom: Yes, the errors popped up when networkx called agraph-something.
>>> > Sadly, I managed to blow up my installation, so can't get a traceback
>>> > for you (was able to reproduce by simply doing apt-get uninstall
>>> graphviz).
>>> >
>>> > On another note (the blowing up), I had an issue with gr-uhd ABI
>>> versions:
>>> > When trying to use USRP on the same install, I got:
>>> >
>>> > Traceback (most recent call last):
>>> >   File "/home/ec/Tests/top_block.py", line 167, in 
>>> > main()
>>> >   File "/home/ec/Tests/top_block.py", line 155, in main
>>> > tb = top_block_cls()
>>> >   File "/home/ec/Tests/top_block.py", line 69, in __init__
>>> > channels=range(1),
>>> >   File
>>> >
>>> "/home/ec/gnuradio/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py",
>>> line
>>> > 122, in constructor_interceptor
>>> > return old_constructor(*args)
>>> >   File
>>> >
>>> "/home/ec/gnuradio/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
>>> line
>>> > 1973, in make
>>> > return _uhd_swig.usrp_source_make(*args)
>>> > RuntimeError:
>>> > GR-UHD detected ABI compatibility mismatch with UHD library.
>>> > GR-UHD was build against ABI: 3.9.0-0,
>>> > but UHD library reports ABI: 3.10.0-0
>>> > Suggestion: install an ABI compatible version of UHD,
>>> > or rebuild GR-UHD component against this ABI version.
>>> >
>>> > However, install log shows:
>>> >
>>> > Configuring gr-uhd support...
>>> > --   Dependency Boost_FOUND = 1
>>> > --   Dependency UHD_FOUND = TRUE
>>> > --   Dependency ENABLE_GNURADIO_RUNTIME = ON
>>> > --   Dependency ENABLE_GR_FILTER = ON
>>> > --   Dependency ENABLE_GR_BLOCKS = ON
>>> > --   Dependency ENABLE_GR_ANALOG = ON
>>> > --   Enabling gr-uhd support.
>>> > --   Override with -DENABLE_GR_UHD=ON/OFF
>>> > --   UHD Version: 3.10.git
>>> >
>>> > I had UHD 3.9.1 installed via package manager (wasn't as thorough as
>>> I'd
>>> > hoped in cleaning gnuradio 3.7.8 from the system), but if the detected
>>> > version in the log was 3.10, I would've thought that that would be the
>>> > version built against. I guess its mostly PEBKAC, but still, weird.
>>> >
>>> > I'll try building again this night, this time without 3.9 installed. If
>>> > the issue persists, I'll make another thread.
>>> >
>>> > 2016-03-23 1:30 GMT+02:00 Tom Rondeau >> > >:
>>> >
>>> > On Tue, Mar 22, 2016 at 7:05 PM, West, Nathan
>>> > mailto:n...@ostatemail.okstate.edu>>
>>> > wrote:
>>> >
>>> > Sorry, may or may not be talking about the same thing here.
>>> > gr-perf-monitorx requires python-networkx, which (I think) is
>>> an
>>> > untracked dependency.
>>> >
>>> >
>>> >
>>> > For utilities like this, we have not previously made Python modules
>>> > a required dependency of GNU Radio. We could, but that would put an
>>> > extra burden on just building the project even if you don't use the
>>> > particular app or example. Generally, we try to provide a friendly
>>> > message explaining the problem. PyBOMBS probably should add these
>>> > dependencies, though. At least scipy.
>>> >
>>> > Also, I believe I ran into this issue recently new versions of
>>> > networkx that broke out a dependency that used to not be required
>>> as
>>> > a separate install, which I think is what the OP's problem is
>>> > related to. See PR #768:
>>> >
>>> > https://github.com/gnuradio/gnuradio/pull/768
>>> >
>>> > Tom
>>> >
>>> >
>>> >
>>> >
>>> > On Tue, Mar 22, 2016 at 7:04 PM, West, Nathan
>>> > >> > > wrote:
>>> >
>>> > gr-perf-monitorx. It's just been the kind 

Re: [Discuss-gnuradio] FPGA update

[Marcus D. Leech]

On 03/23/2016 03:32 PM, Diyar Muhammed wrote:

Dear All,
I have got new usrp x310 with UBX160 daughter board, I assembled the 
usrp, but when I run the uhd_usrp_probe --args addr=192.168.10.2 there 
is a UHD Warning:


/X300 unknown product code in EEPROM:30818/
/Error: RuntimeError: Expected firmware compatibility number 3.0, but 
got 4.0:/

/The firmware build is not compatible with the host code build./
/Please run:/
/ "/usr/local/lib/uhd/utils/uhd_images_downloader.py"/

I found from ettus website how I can download and update image 
(http://files.ettus.com/manual/page_usrp_x3x0.html#x3x0_hw_1gige) but 
when I run uhd_image_loader 
--args="type=x300,addr=192.168.10.2,fpga=HGS", I got from terminal 
uhd_image_loader: command not found.

I need advace, about this problem:
*uhd_image_loader: command not found.
*
*
*
*FYI, I use Live_USB.*

--
Regards,
Diyar Muhammed
Ministry of Higher Education and Scientific Research
Duty: Network Administration and Design
Website: www.mhe-krg.org 
Cell Phone: 009647504690060
Office Phone:   00964662554683


This properly belongs on the usrp-users mailing list.

Please re-post there.



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

[Discuss-gnuradio] FPGA update

[Diyar Muhammed]

Dear All,
I have got new usrp x310 with UBX160 daughter board, I assembled the usrp,
but when I run the uhd_usrp_probe --args addr=192.168.10.2 there is a UHD
Warning:

*X300 unknown product code in EEPROM:30818*
*Error: RuntimeError: Expected firmware compatibility number 3.0, but got
4.0:*
*The firmware build is not compatible with the host code build.*
*Please run:*
* "/usr/local/lib/uhd/utils/uhd_images_downloader.py"*

I found from ettus website how I can download and update image (
http://files.ettus.com/manual/page_usrp_x3x0.html#x3x0_hw_1gige) but when I
run uhd_image_loader --args="type=x300,addr=192.168.10.2,fpga=HGS", I got
from terminal uhd_image_loader: command not found.
I need advace, about this problem:

*uhd_image_loader: command not found.*

*FYI, I use Live_USB.*

-- 
Regards,
Diyar Muhammed
Ministry of Higher Education and Scientific Research
Duty: Network Administration and Design
Website:  www.mhe-krg.org
Cell Phone: 009647504690060
Office Phone:   00964662554683
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Ettus N210 GMSK 9600

[Marcus D. Leech]

On 03/23/2016 03:14 PM, Tom Golden wrote:

Here's my flow-graph along with a snapshot of the constellation and FFT.

Thanks!!
-Tom
What output level is the RF modem producing?  Are you using attenuators 
between it and the RF input of the USRP?


I note that you have the RF gain on your capture set to 0.

Also, I don't recall whether the polyphase resampler requires that the 
input already be Nyquist-limited before it gets resampled.
  I know some of the other resamplers do that, otherwise, you get 
aliases in your output passband.


Since you're looking at a 9600BPS signal, you should probably have 
sampled this at 250ksps--the lowest rate possible with the N210--

  that makes filtering later less computationally intensive.





On Wed, Mar 23, 2016 at 1:01 PM, Marcus D. Leech > wrote:


On 03/23/2016 02:48 PM, Tom Golden wrote:

Hi,

I'm a novice gnu radio user.  I'm using gnuradio with an Ettus
N210 cabled to a modem transmitting GMSK 9600bps.  This is
just for a test to verify the modem transmit bits.

I'm having issues with resampling.  The N210 clock can't be
set to a multiple of 9600, so I'm attempting to resample. I've
tried various mechanisms but the output after resampling to
96000 is too noisy to successfully decode bits.  I've tried
the GMSK demod block as well as the combination of Quadrature
Demod->Clock Recovery MM->Binary Slicer - and neither works.

I've also played with the Polyphase clock sync but I don't see
any noticeable difference. Can anyone recommend a solution?

Thanks!!
-Tom

For a first step, it would be useful for you to share your
flow-graph with the list.




___
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] Ettus N210 GMSK 9600

[Tom Golden]

Here's my flow-graph along with a snapshot of the constellation and FFT.

Thanks!!
-Tom


On Wed, Mar 23, 2016 at 1:01 PM, Marcus D. Leech  wrote:

> On 03/23/2016 02:48 PM, Tom Golden wrote:
>
>> Hi,
>>
>> I'm a novice gnu radio user.  I'm using gnuradio with an Ettus N210
>> cabled to a modem transmitting GMSK 9600bps.  This is just for a test to
>> verify the modem transmit bits.
>>
>> I'm having issues with resampling.  The N210 clock can't be set to a
>> multiple of 9600, so I'm attempting to resample. I've tried various
>> mechanisms but the output after resampling to 96000 is too noisy to
>> successfully decode bits.  I've tried the GMSK demod block as well as the
>> combination of Quadrature Demod->Clock Recovery MM->Binary Slicer - and
>> neither works.
>>
>> I've also played with the Polyphase clock sync but I don't see any
>> noticeable difference. Can anyone recommend a solution?
>>
>> Thanks!!
>> -Tom
>>
>> For a first step, it would be useful for you to share your flow-graph
> with the list.
>
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>


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

Re: [Discuss-gnuradio] Ettus N210 GMSK 9600

[Marcus D. Leech]

On 03/23/2016 02:48 PM, Tom Golden wrote:

Hi,

I'm a novice gnu radio user.  I'm using gnuradio with an Ettus N210 
cabled to a modem transmitting GMSK 9600bps.  This is just for a test 
to verify the modem transmit bits.


I'm having issues with resampling.  The N210 clock can't be set to a 
multiple of 9600, so I'm attempting to resample. I've tried various 
mechanisms but the output after resampling to 96000 is too noisy to 
successfully decode bits.  I've tried the GMSK demod block as well as 
the combination of Quadrature Demod->Clock Recovery MM->Binary Slicer 
- and neither works.


I've also played with the Polyphase clock sync but I don't see any 
noticeable difference. Can anyone recommend a solution?


Thanks!!
-Tom

For a first step, it would be useful for you to share your flow-graph 
with the list.





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

[Discuss-gnuradio] Ettus N210 GMSK 9600

[Tom Golden]

Hi,

I'm a novice gnu radio user.  I'm using gnuradio with an Ettus N210 cabled
to a modem transmitting GMSK 9600bps.  This is just for a test to verify
the modem transmit bits.

I'm having issues with resampling.  The N210 clock can't be set to a
multiple of 9600, so I'm attempting to resample.  I've tried various
mechanisms but the output after resampling to 96000 is too noisy to
successfully decode bits.  I've tried the GMSK demod block as well as the
combination of Quadrature Demod->Clock Recovery MM->Binary Slicer - and
neither works.

I've also played with the Polyphase clock sync but I don't see any
noticeable difference. Can anyone recommend a solution?

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

Re: [Discuss-gnuradio] PYBOMBS CtrlPort pygraphviz dependency

[Laur Joost]

Martin: I'm rebuilding from scratch this night. I'll modify the recipe for
networkx before starting, and if it works, I'll.. what? submit a pull
request? Well, first time for everything.

Nathan: As in, installing graphviz and pygraphviz should have been
dependencies for networkx, not something we should need to worry about?
Yeah, probably makes sense.

All the best
Laur

2016-03-23 19:50 GMT+02:00 West, Nathan :

> It sounds like networkx is only part of the issue and maybe there's an
> upstream bug that Tom has patched over locally. Is this something we should
> report upstream to the distros?
>
>
> On Wednesday, March 23, 2016, Martin Braun  wrote:
>
>> Laur,
>>
>> can you please submit a recipe to gr-recipes for networkx?
>>
>> Thanks,
>> Martin
>>
>> On 03/23/2016 01:50 AM, Laur Joost wrote:
>> > Thanks for the responses, and damned be the timezones.
>> >
>> > Nathan: gr-perf-monitorx needs python-networkx (which is installed by
>> > pybombs, or at least, existed for me), but python-networkx needs
>> > python-pygraphviz, at least for how it's used by gr-perf-monitorx.
>> >
>> > Tom: Yes, the errors popped up when networkx called agraph-something.
>> > Sadly, I managed to blow up my installation, so can't get a traceback
>> > for you (was able to reproduce by simply doing apt-get uninstall
>> graphviz).
>> >
>> > On another note (the blowing up), I had an issue with gr-uhd ABI
>> versions:
>> > When trying to use USRP on the same install, I got:
>> >
>> > Traceback (most recent call last):
>> >   File "/home/ec/Tests/top_block.py", line 167, in 
>> > main()
>> >   File "/home/ec/Tests/top_block.py", line 155, in main
>> > tb = top_block_cls()
>> >   File "/home/ec/Tests/top_block.py", line 69, in __init__
>> > channels=range(1),
>> >   File
>> >
>> "/home/ec/gnuradio/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py",
>> line
>> > 122, in constructor_interceptor
>> > return old_constructor(*args)
>> >   File
>> >
>> "/home/ec/gnuradio/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
>> line
>> > 1973, in make
>> > return _uhd_swig.usrp_source_make(*args)
>> > RuntimeError:
>> > GR-UHD detected ABI compatibility mismatch with UHD library.
>> > GR-UHD was build against ABI: 3.9.0-0,
>> > but UHD library reports ABI: 3.10.0-0
>> > Suggestion: install an ABI compatible version of UHD,
>> > or rebuild GR-UHD component against this ABI version.
>> >
>> > However, install log shows:
>> >
>> > Configuring gr-uhd support...
>> > --   Dependency Boost_FOUND = 1
>> > --   Dependency UHD_FOUND = TRUE
>> > --   Dependency ENABLE_GNURADIO_RUNTIME = ON
>> > --   Dependency ENABLE_GR_FILTER = ON
>> > --   Dependency ENABLE_GR_BLOCKS = ON
>> > --   Dependency ENABLE_GR_ANALOG = ON
>> > --   Enabling gr-uhd support.
>> > --   Override with -DENABLE_GR_UHD=ON/OFF
>> > --   UHD Version: 3.10.git
>> >
>> > I had UHD 3.9.1 installed via package manager (wasn't as thorough as I'd
>> > hoped in cleaning gnuradio 3.7.8 from the system), but if the detected
>> > version in the log was 3.10, I would've thought that that would be the
>> > version built against. I guess its mostly PEBKAC, but still, weird.
>> >
>> > I'll try building again this night, this time without 3.9 installed. If
>> > the issue persists, I'll make another thread.
>> >
>> > 2016-03-23 1:30 GMT+02:00 Tom Rondeau > > >:
>> >
>> > On Tue, Mar 22, 2016 at 7:05 PM, West, Nathan
>> > mailto:n...@ostatemail.okstate.edu>>
>> > wrote:
>> >
>> > Sorry, may or may not be talking about the same thing here.
>> > gr-perf-monitorx requires python-networkx, which (I think) is an
>> > untracked dependency.
>> >
>> >
>> >
>> > For utilities like this, we have not previously made Python modules
>> > a required dependency of GNU Radio. We could, but that would put an
>> > extra burden on just building the project even if you don't use the
>> > particular app or example. Generally, we try to provide a friendly
>> > message explaining the problem. PyBOMBS probably should add these
>> > dependencies, though. At least scipy.
>> >
>> > Also, I believe I ran into this issue recently new versions of
>> > networkx that broke out a dependency that used to not be required as
>> > a separate install, which I think is what the OP's problem is
>> > related to. See PR #768:
>> >
>> > https://github.com/gnuradio/gnuradio/pull/768
>> >
>> > Tom
>> >
>> >
>> >
>> >
>> > On Tue, Mar 22, 2016 at 7:04 PM, West, Nathan
>> > > > > wrote:
>> >
>> > gr-perf-monitorx. It's just been the kind of thing that
>> > everyone that uses it already has and no one tracks it.
>> > There's a couple of minor deps for utilities like this that
>> > sneak through the cracks, but they're very hard to keep
>> > track of until you run this on a brand new image.
>> >

Re: [Discuss-gnuradio] PYBOMBS CtrlPort pygraphviz dependency

[West, Nathan]

It sounds like networkx is only part of the issue and maybe there's an
upstream bug that Tom has patched over locally. Is this something we should
report upstream to the distros?

On Wednesday, March 23, 2016, Martin Braun  wrote:

> Laur,
>
> can you please submit a recipe to gr-recipes for networkx?
>
> Thanks,
> Martin
>
> On 03/23/2016 01:50 AM, Laur Joost wrote:
> > Thanks for the responses, and damned be the timezones.
> >
> > Nathan: gr-perf-monitorx needs python-networkx (which is installed by
> > pybombs, or at least, existed for me), but python-networkx needs
> > python-pygraphviz, at least for how it's used by gr-perf-monitorx.
> >
> > Tom: Yes, the errors popped up when networkx called agraph-something.
> > Sadly, I managed to blow up my installation, so can't get a traceback
> > for you (was able to reproduce by simply doing apt-get uninstall
> graphviz).
> >
> > On another note (the blowing up), I had an issue with gr-uhd ABI
> versions:
> > When trying to use USRP on the same install, I got:
> >
> > Traceback (most recent call last):
> >   File "/home/ec/Tests/top_block.py", line 167, in 
> > main()
> >   File "/home/ec/Tests/top_block.py", line 155, in main
> > tb = top_block_cls()
> >   File "/home/ec/Tests/top_block.py", line 69, in __init__
> > channels=range(1),
> >   File
> >
> "/home/ec/gnuradio/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py",
> line
> > 122, in constructor_interceptor
> > return old_constructor(*args)
> >   File
> >
> "/home/ec/gnuradio/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
> line
> > 1973, in make
> > return _uhd_swig.usrp_source_make(*args)
> > RuntimeError:
> > GR-UHD detected ABI compatibility mismatch with UHD library.
> > GR-UHD was build against ABI: 3.9.0-0,
> > but UHD library reports ABI: 3.10.0-0
> > Suggestion: install an ABI compatible version of UHD,
> > or rebuild GR-UHD component against this ABI version.
> >
> > However, install log shows:
> >
> > Configuring gr-uhd support...
> > --   Dependency Boost_FOUND = 1
> > --   Dependency UHD_FOUND = TRUE
> > --   Dependency ENABLE_GNURADIO_RUNTIME = ON
> > --   Dependency ENABLE_GR_FILTER = ON
> > --   Dependency ENABLE_GR_BLOCKS = ON
> > --   Dependency ENABLE_GR_ANALOG = ON
> > --   Enabling gr-uhd support.
> > --   Override with -DENABLE_GR_UHD=ON/OFF
> > --   UHD Version: 3.10.git
> >
> > I had UHD 3.9.1 installed via package manager (wasn't as thorough as I'd
> > hoped in cleaning gnuradio 3.7.8 from the system), but if the detected
> > version in the log was 3.10, I would've thought that that would be the
> > version built against. I guess its mostly PEBKAC, but still, weird.
> >
> > I'll try building again this night, this time without 3.9 installed. If
> > the issue persists, I'll make another thread.
> >
> > 2016-03-23 1:30 GMT+02:00 Tom Rondeau 
> > >:
> >
> > On Tue, Mar 22, 2016 at 7:05 PM, West, Nathan
> >   n...@ostatemail.okstate.edu >>
> > wrote:
> >
> > Sorry, may or may not be talking about the same thing here.
> > gr-perf-monitorx requires python-networkx, which (I think) is an
> > untracked dependency.
> >
> >
> >
> > For utilities like this, we have not previously made Python modules
> > a required dependency of GNU Radio. We could, but that would put an
> > extra burden on just building the project even if you don't use the
> > particular app or example. Generally, we try to provide a friendly
> > message explaining the problem. PyBOMBS probably should add these
> > dependencies, though. At least scipy.
> >
> > Also, I believe I ran into this issue recently new versions of
> > networkx that broke out a dependency that used to not be required as
> > a separate install, which I think is what the OP's problem is
> > related to. See PR #768:
> >
> > https://github.com/gnuradio/gnuradio/pull/768
> >
> > Tom
> >
> >
> >
> >
> > On Tue, Mar 22, 2016 at 7:04 PM, West, Nathan
> > 
> > > wrote:
> >
> > gr-perf-monitorx. It's just been the kind of thing that
> > everyone that uses it already has and no one tracks it.
> > There's a couple of minor deps for utilities like this that
> > sneak through the cracks, but they're very hard to keep
> > track of until you run this on a brand new image.
> >
> > nw
> >
> > On Tue, Mar 22, 2016 at 6:46 PM, Martin Braun
> >   martin.br...@ettus.com >> wrote:
> >
> > Who is calling pygraphviz? If we need this for GNU
> > Radio, we probably
> > need to update some recipes.
> >
> > M
> >
> > On 03/22/2016 12:12 PM, Laur Joost wrote:
> > > Hi all!
> > >
> > > Fresh install of gnuradio-3.7.9.1 via PyBOMBS-2.0.1 on
> > 

Re: [Discuss-gnuradio] PYBOMBS CtrlPort pygraphviz dependency

[Martin Braun]

Laur,

can you please submit a recipe to gr-recipes for networkx?

Thanks,
Martin

On 03/23/2016 01:50 AM, Laur Joost wrote:
> Thanks for the responses, and damned be the timezones.
> 
> Nathan: gr-perf-monitorx needs python-networkx (which is installed by
> pybombs, or at least, existed for me), but python-networkx needs
> python-pygraphviz, at least for how it's used by gr-perf-monitorx.
> 
> Tom: Yes, the errors popped up when networkx called agraph-something.
> Sadly, I managed to blow up my installation, so can't get a traceback
> for you (was able to reproduce by simply doing apt-get uninstall graphviz).
> 
> On another note (the blowing up), I had an issue with gr-uhd ABI versions:
> When trying to use USRP on the same install, I got:
> 
> Traceback (most recent call last):
>   File "/home/ec/Tests/top_block.py", line 167, in 
> main()
>   File "/home/ec/Tests/top_block.py", line 155, in main
> tb = top_block_cls()
>   File "/home/ec/Tests/top_block.py", line 69, in __init__
> channels=range(1),
>   File
> "/home/ec/gnuradio/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py", line
> 122, in constructor_interceptor
> return old_constructor(*args)
>   File
> "/home/ec/gnuradio/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py", line
> 1973, in make
> return _uhd_swig.usrp_source_make(*args)
> RuntimeError: 
> GR-UHD detected ABI compatibility mismatch with UHD library.
> GR-UHD was build against ABI: 3.9.0-0,
> but UHD library reports ABI: 3.10.0-0
> Suggestion: install an ABI compatible version of UHD,
> or rebuild GR-UHD component against this ABI version.
> 
> However, install log shows:
> 
> Configuring gr-uhd support...
> --   Dependency Boost_FOUND = 1
> --   Dependency UHD_FOUND = TRUE
> --   Dependency ENABLE_GNURADIO_RUNTIME = ON
> --   Dependency ENABLE_GR_FILTER = ON
> --   Dependency ENABLE_GR_BLOCKS = ON
> --   Dependency ENABLE_GR_ANALOG = ON
> --   Enabling gr-uhd support.
> --   Override with -DENABLE_GR_UHD=ON/OFF
> --   UHD Version: 3.10.git
> 
> I had UHD 3.9.1 installed via package manager (wasn't as thorough as I'd
> hoped in cleaning gnuradio 3.7.8 from the system), but if the detected
> version in the log was 3.10, I would've thought that that would be the
> version built against. I guess its mostly PEBKAC, but still, weird.
> 
> I'll try building again this night, this time without 3.9 installed. If
> the issue persists, I'll make another thread.
> 
> 2016-03-23 1:30 GMT+02:00 Tom Rondeau  >:
> 
> On Tue, Mar 22, 2016 at 7:05 PM, West, Nathan
> mailto:n...@ostatemail.okstate.edu>>
> wrote:
> 
> Sorry, may or may not be talking about the same thing here.
> gr-perf-monitorx requires python-networkx, which (I think) is an
> untracked dependency.
> 
> 
> 
> For utilities like this, we have not previously made Python modules
> a required dependency of GNU Radio. We could, but that would put an
> extra burden on just building the project even if you don't use the
> particular app or example. Generally, we try to provide a friendly
> message explaining the problem. PyBOMBS probably should add these
> dependencies, though. At least scipy.
> 
> Also, I believe I ran into this issue recently new versions of
> networkx that broke out a dependency that used to not be required as
> a separate install, which I think is what the OP's problem is
> related to. See PR #768:
> 
> https://github.com/gnuradio/gnuradio/pull/768
> 
> Tom
> 
> 
>  
> 
> On Tue, Mar 22, 2016 at 7:04 PM, West, Nathan
>  > wrote:
> 
> gr-perf-monitorx. It's just been the kind of thing that
> everyone that uses it already has and no one tracks it.
> There's a couple of minor deps for utilities like this that
> sneak through the cracks, but they're very hard to keep
> track of until you run this on a brand new image.
> 
> nw
> 
> On Tue, Mar 22, 2016 at 6:46 PM, Martin Braun
> mailto:martin.br...@ettus.com>> wrote:
> 
> Who is calling pygraphviz? If we need this for GNU
> Radio, we probably
> need to update some recipes.
> 
> M
> 
> On 03/22/2016 12:12 PM, Laur Joost wrote:
> > Hi all!
> >
> > Fresh install of gnuradio-3.7.9.1 via PyBOMBS-2.0.1 on
> Ubuntu 15.10
> >
> > When trying to run CrtlPort Performance Monitor on a
> fresh 3.7.9.1
> > install, I got errors about missing pygraphviz.
> >
> > sudo apt-get python-pygraphviz
> >
> > solved it for me. The supposedly equivalent
> >
> > sudo apt-get install graphviz
> >

Re: [Discuss-gnuradio] Draft Proposal GSoC: Offline Analysis and Visualization Tools

[West, Nathan]

Looking through the proposal I mostly see your translation of the idea from
the GSoC ideas list to a proposal format. All of that is fine, but we've
already decided this is a reasonable idea and the proposal should convince
us that you're the right person to work on it.

You've provided the right evidence that you've read some of the GSoC pages,
but my current criticism boils down to missing information that we ask for
here: http://gnuradio.org/redmine/projects/gnuradio/wiki/GSoCStudentInfo

I'll point out *some* specifics but please don't just list responses to
these things in the proposal. Rather reshape it to giving us an idea of
what you want to do (which you have) and why you're the right person. The
list I'm providing is not meant to be exhaustive, and I'm not suggesting
that you're not the right person to do this, just that you haven't
addressed that (or your eligibility for GSoC in your proposal. It's also
possible I am being dense and missed some of this information.

>From the page I linked you're missing:
* Proof of your coding capabilities (this is the big one)
* University and student status (more of a formality)
* why do you want to do *this* project? (this is not critical, but if
you've done any classes or work in areas related to your proposal idea than
that looks very good)

Ideally this is all more than a single sentence that says "I did a matlab
simulation once in a class and it was cool", but much less than a college
admissions essay on why DSP will save the world.

Looking forward to the next draft (and hopefully faster turnaround),
-Nathan

PS - most of this email can be copy and pasted as feedback for several
other proposals I've read so far.


On Wed, Mar 23, 2016 at 6:19 AM, Usman Haider 
wrote:

> I have not get any feedback on this yet. I hope I have not missed anything
> important? Please, provide feedback on this.
>
>
> Regards,
> Usman
>
>
> On Mon, Mar 21, 2016 at 11:45 PM, Usman Haider 
> wrote:
>
>> I have added lambda expression in deliverables based on Tim's comments.
>> This will allow user to enter lambda expression in GUI. That expression
>> will be then evaluated on samples and result will be displayed. Rather than
>> providing fixed mathematical function (scale/normalize), user  can apply
>> anonymous functions, they want, on samples using Lambda construct. This
>> will give user more flexibility. I have updated my proposal. You can see it
>> on following link
>>
>> https://github.com/UHaider/GSoC/blob/master/GSOC%20Proposal.pdf
>>
>> Awaiting feedback.
>>
>> Regards,
>> Usman
>>
>> On Thu, Mar 17, 2016 at 1:07 PM, Usman Haider 
>> wrote:
>>
>>> Hi Community,
>>>
>>> I have made my proposal for the subject GSoC idea. Please have a look
>>> and give feedback. Thanks for your time.
>>>
>>> https://github.com/UHaider/GSoC/blob/master/GSOC%20Proposal.pdf
>>>
>>> Regards,
>>> Usman
>>>
>>
>>
>
> ___
> 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] Draft Proposal GSoC: Offline Analysis and Visualization Tools

[Marcus Müller]

Doh'. I'm stupid!

On 23.03.2016 15:49, Jan Krämer wrote:
> Marcus,
>
> just for you to know, the sentence with the polar codes can stay :D
> see https://gnuradio.org/redmine/projects/gnuradio/wiki/GSoCStudentInfo
>
> Cheers,
> Jan
>
> 2016-03-23 15:26 GMT+01:00 Marcus Müller  >:
>
> Hi Usman,
>
> make sure your punctuation is right; only use "?" after a sentence
> that /really/ is a question. Make sure there is always a space
> after punctuation, and don't make generalizing (and hence, wrong)
> statements like "And yes,Polar Codes are the coolest codes", which
> are a bit /too/ colloquial for an application. Also, after make
> sure that the words after abbreviations ("e.g." etc) have the
> right capitalization. There's also still some typos; get a friend
> to cross-read the document critically; four eyes see more than two.
>
> We're usually not very picky about that, but considering this is
> an application, I might add that on the website, and in the
> documentation, we generally use the capitalization "GNU Radio",
> not "Gnu Radio"; we didn't invent the GNU project, it was already
> there when Eric Blossom started with GNU Radio.
>
> Content-wise, you've got a very fine, week-wise breakdown of your
> plans; however, the items you'd do in those weeks seem of very
> different size and defined at vastly different precisions. Comparing
>
>> Week 8 (11th July - 17th July):
>> a. Add functionality for saving selected plot as a picture.
>> b. Extract user selected samples and save it to another file.
>
> and
>
>> Week 6 (27th June - 03rd July):
>> a. Coding for signal visualization in time, frequency and scatter
>> plots in
>> tabbed manner.
>> b. Updating of plots based on tags. e.g sample rate change can
>> translate to
>> change in time-axis of time domain plot.
>
> I'd say that Week 6 contains the a significant of the core
> deliverable of your GSoC proposal, whilst week 8 really has only
> two features to complete.  Maybe you can balance that timeline a
> little more; not all things take the same time!
>
> Also, after literature, I'm still not sure what you mean with
> displaying something in a "tabbed manner"; you should explain that.
>
> Best regards,
> Marcus
>
> On 23.03.2016 11:19, Usman Haider wrote:
>> I have not get any feedback on this yet. I hope I have not missed
>> anything important? Please, provide feedback on this.
>>
>>
>> Regards,
>> Usman
>>
>> On Mon, Mar 21, 2016 at 11:45 PM, Usman Haider
>> mailto:usmanhaide...@gmail.com>> wrote:
>>
>> I have added lambda expression in deliverables based on Tim's
>> comments. This will allow user to enter lambda expression in
>> GUI. That expression will be then evaluated on samples and
>> result will be displayed. Rather than providing fixed
>> mathematical function (scale/normalize), user  can apply
>> anonymous functions, they want, on samples using Lambda
>> construct. This will give user more flexibility. I have
>> updated my proposal. You can see it on following link
>>
>> https://github.com/UHaider/GSoC/blob/master/GSOC%20Proposal.pdf
>>
>> Awaiting feedback.
>>
>> Regards,
>> Usman
>>
>> On Thu, Mar 17, 2016 at 1:07 PM, Usman Haider
>> mailto:usmanhaide...@gmail.com>> wrote:
>>
>> Hi Community,
>>
>> I have made my proposal for the subject GSoC idea. Please
>> have a look and give feedback. Thanks for your time.
>>
>> https://github.com/UHaider/GSoC/blob/master/GSOC%20Proposal.pdf
>>
>> Regards,
>> Usman
>>
>>
>>
>>
>>
>> ___
>> 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] Draft Proposal GSoC: Offline Analysis and Visualization Tools

[Jan Krämer]

Marcus,

just for you to know, the sentence with the polar codes can stay :D see
https://gnuradio.org/redmine/projects/gnuradio/wiki/GSoCStudentInfo

Cheers,
Jan

2016-03-23 15:26 GMT+01:00 Marcus Müller :

> Hi Usman,
>
> make sure your punctuation is right; only use "?" after a sentence that
> *really* is a question. Make sure there is always a space after
> punctuation, and don't make generalizing (and hence, wrong) statements like
> "And yes,Polar Codes are the coolest codes", which are a bit *too*
> colloquial for an application. Also, after make sure that the words after
> abbreviations ("e.g." etc) have the right capitalization. There's also
> still some typos; get a friend to cross-read the document critically; four
> eyes see more than two.
>
> We're usually not very picky about that, but considering this is an
> application, I might add that on the website, and in the documentation, we
> generally use the capitalization "GNU Radio", not "Gnu Radio"; we didn't
> invent the GNU project, it was already there when Eric Blossom started with
> GNU Radio.
>
> Content-wise, you've got a very fine, week-wise breakdown of your plans;
> however, the items you'd do in those weeks seem of very different size and
> defined at vastly different precisions. Comparing
>
> Week 8 (11th July - 17th July):
> a. Add functionality for saving selected plot as a picture.
> b. Extract user selected samples and save it to another file.
>
>
> and
>
> Week 6 (27th June - 03rd July):
> a. Coding for signal visualization in time, frequency and scatter plots in
> tabbed manner.
> b. Updating of plots based on tags. e.g sample rate change can translate to
> change in time-axis of time domain plot.
>
>
> I'd say that Week 6 contains the a significant of the core deliverable of
> your GSoC proposal, whilst week 8 really has only two features to
> complete.  Maybe you can balance that timeline a little more; not all
> things take the same time!
>
> Also, after literature, I'm still not sure what you mean with displaying
> something in a "tabbed manner"; you should explain that.
>
> Best regards,
> Marcus
>
> On 23.03.2016 11:19, Usman Haider wrote:
>
> I have not get any feedback on this yet. I hope I have not missed anything
> important? Please, provide feedback on this.
>
>
> Regards,
> Usman
>
> On Mon, Mar 21, 2016 at 11:45 PM, Usman Haider < 
> usmanhaide...@gmail.com> wrote:
>
>> I have added lambda expression in deliverables based on Tim's comments.
>> This will allow user to enter lambda expression in GUI. That expression
>> will be then evaluated on samples and result will be displayed. Rather than
>> providing fixed mathematical function (scale/normalize), user  can apply
>> anonymous functions, they want, on samples using Lambda construct. This
>> will give user more flexibility. I have updated my proposal. You can see it
>> on following link
>>
>> https://github.com/UHaider/GSoC/blob/master/GSOC%20Proposal.pdf
>>
>> Awaiting feedback.
>>
>> Regards,
>> Usman
>>
>> On Thu, Mar 17, 2016 at 1:07 PM, Usman Haider 
>> wrote:
>>
>>> Hi Community,
>>>
>>> I have made my proposal for the subject GSoC idea. Please have a look
>>> and give feedback. Thanks for your time.
>>>
>>> https://github.com/UHaider/GSoC/blob/master/GSOC%20Proposal.pdf
>>>
>>> Regards,
>>> Usman
>>>
>>
>>
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Announcing NEWSDR at NEU on Thr/Fri June 2/3

[Neel Pandeya]

*
NEWSDR 2016

New England Workshop on Software-Defined Radio

Sixth-Annual

 Main Event
   Friday June 3
 8:00 AM - 4:00 PM

 Workshops
  Thursday June 2
 6:00 PM - 9:00 PM

Northeastern University (NEU)
  Boston, MA, USA

  http://www.sdr-boston.org/

   Free Registration

 Poster Submissions Accepted Until Friday May 6

*
 INVITATION TO PARTICIPATE

You are cordially invited to the 2016 New England Workshop on
Software Defined Radio (NEWSDR 2016), which is the sixth installment
of an annual series of workshops organized by the Boston SDR User
Group (SDR-Boston).

This year, NEWSDR will be held at the Raytheon Amphitheater at
Northeastern University (NEU), and consists of a day-long Main Event
on Friday, as well as several Workshops the evening before. You are
welcome to attend either or both.

Attendance is typically about 100 people, and attendees are from
both academia and industry.

*
MAIN EVENT

   Friday June 3
 8:00 AM - 4:00 PM

   Raytheon Amphitheater

Plenary Speakers:
  *  Mr. Richard Reinhart, NASA Glenn Research Center
  *  Prof. Tommaso Melodia, Northeastern University

Technical Poster Presentations:
  *  Covering the recent work in SDR and cognitive radio technology
  *  Poster presentations are now being solicited
  *  See link at the bottom of this email to submit your abstract

Corporate Sponsors:
  *  Analog Devices
  *  Ettus Research / National Instruments
  *  MathWorks
  *  MediaTek Wireless

The Main Event features plenary speakers, technical poster
presentation sessions, hardware and software demonstrations from the
event sponsors, and workshops from the event sponsors, all focusing
on recent work in SDR and cognitive radio technology. Free breakfast,
lunch, and coffee will be provided.

The event provides an excellent networking opportunity and a terrific
venue to exchange thoughts and ideas with other people working in
the SDR space.

*
 WORKSHOPS

  Thursday June 2
 6:00 PM - 9:00 PM

   Raytheon Amphitheater

MathWorks and Ettus Research / National Instruments will each run
a workshop on the evening before the main event. Workshops are
technical, practical, hands-on activities in a group setting.
Specific topics and further details about the workshops will be
announced shortly. Attendance is free, but advance registration
is required. Free pizza and soda will be provided.

*
   REGISTRATION

  *  Register for the Workshops or the Main Event or both

  *  Registration is required but is completely free

  *  Registration takes less than 5 minutes

  *  Registration includes free food

  *  Parking available

  *  You must register online for food and parking

  *  Attendance, food, parking are all limited, so please register
 online as soon as possible to secure your spot

  *  Registration deadline is Friday May 20

  *  See link at the bottom of this announcement to register online

*
   LINKS

Attendee Registration:
https://docs.google.com/forms/d/1QCIyKIVzpZfzh4ptim7zCIbcKvi2drDLurkptokdqN4

Poster Abstract Submission:
https://docs.google.com/forms/d/17faN0FQuifOHS4xX1TZWN9ABMlY__s3g81ZUfIwdtqE

*
  ADDITIONAL INFORMATION

 More information, and the event schedule,
for this event can be found at our website:

http://www.sdr-boston.org/

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

Re: [Discuss-gnuradio] Draft Proposal GSoC: Offline Analysis and Visualization Tools

[Marcus Müller]

Hi Usman,

make sure your punctuation is right; only use "?" after a sentence that
/really/ is a question. Make sure there is always a space after
punctuation, and don't make generalizing (and hence, wrong) statements
like "And yes,Polar Codes are the coolest codes", which are a bit /too/
colloquial for an application. Also, after make sure that the words
after abbreviations ("e.g." etc) have the right capitalization. There's
also still some typos; get a friend to cross-read the document
critically; four eyes see more than two.

We're usually not very picky about that, but considering this is an
application, I might add that on the website, and in the documentation,
we generally use the capitalization "GNU Radio", not "Gnu Radio"; we
didn't invent the GNU project, it was already there when Eric Blossom
started with GNU Radio.

Content-wise, you've got a very fine, week-wise breakdown of your plans;
however, the items you'd do in those weeks seem of very different size
and defined at vastly different precisions. Comparing

> Week 8 (11th July - 17th July):
> a. Add functionality for saving selected plot as a picture.
> b. Extract user selected samples and save it to another file.

and

> Week 6 (27th June - 03rd July):
> a. Coding for signal visualization in time, frequency and scatter plots in
> tabbed manner.
> b. Updating of plots based on tags. e.g sample rate change can
> translate to
> change in time-axis of time domain plot.

I'd say that Week 6 contains the a significant of the core deliverable
of your GSoC proposal, whilst week 8 really has only two features to
complete.  Maybe you can balance that timeline a little more; not all
things take the same time!

Also, after literature, I'm still not sure what you mean with displaying
something in a "tabbed manner"; you should explain that.

Best regards,
Marcus
On 23.03.2016 11:19, Usman Haider wrote:
> I have not get any feedback on this yet. I hope I have not missed
> anything important? Please, provide feedback on this.
>
>
> Regards,
> Usman
>
> On Mon, Mar 21, 2016 at 11:45 PM, Usman Haider
> mailto:usmanhaide...@gmail.com>> wrote:
>
> I have added lambda expression in deliverables based on Tim's
> comments. This will allow user to enter lambda expression in GUI.
> That expression will be then evaluated on samples and result will
> be displayed. Rather than providing fixed mathematical function
> (scale/normalize), user  can apply anonymous functions, they want,
> on samples using Lambda construct. This will give user more
> flexibility. I have updated my proposal. You can see it on
> following link
>
> https://github.com/UHaider/GSoC/blob/master/GSOC%20Proposal.pdf
>
> Awaiting feedback.
>
> Regards,
> Usman
>
> On Thu, Mar 17, 2016 at 1:07 PM, Usman Haider
> mailto:usmanhaide...@gmail.com>> wrote:
>
> Hi Community,
>
> I have made my proposal for the subject GSoC idea. Please have
> a look and give feedback. Thanks for your time.
>
> https://github.com/UHaider/GSoC/blob/master/GSOC%20Proposal.pdf
>
> Regards,
> Usman
>
>
>
>
>
> ___
> 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] GSOC 2016: Help Review Project Proposal

[Tom Rondeau]

On Wed, Mar 23, 2016 at 4:03 AM, Jan Krämer  wrote:

> Hi Tanero,
>
> It seems that you know your way around LDPC Codes and the theory behind
> it, which is a really good thing. But there are still things to improve.
>
> - Check your spelling and grammar again. Also the formatting needs
> reshaping (at least in Githubs preview and Fedoras document viewer) .
> - Regarding optimizations. If you manage to highlight a bit more, how SIMD
> could help improve the speed by parallelizing steps and how reducing the
> Parity check matrixes helps with random memory accesses that would be a
> great plus for your proposal.
> - You should try to get a bit more familiar with the FEC-API. You have an
> extra timeslot dedicated to integrating the finished OOT blocks into the
> FEC-API. Just for the record, you can have your own OOT block that is
> already using the FEC-API. Transferring that OOT block is to core-GNURadio
> would just be a copy of the source files and adjusting of the gr-fec
> CMakeLists.txt. I think it would fine with developing the blocks first as
> an OOT module (if it is using the FEC-API from the beginning) and then
> porting it to gr-fec. But directly integrating the LDPC blocks in gr-fec
> would be also an option.
>
> Cheers and happy hacking,
> Jan
>
>
>
> 2016-03-22 5:11 GMT+01:00 Tanero Juthero :
>
>>   I made an update to the proposal,mentors please help me review the
>> proposal,your opinions highly
>>
>> awaited.Here is the link
>> https://github.com/tanerochris/gsoc-2016/blob/master/%20gsoc_2016_application.pdf
>>
>> Thanks.
>>
>

Following on from Jan's suggestion, please make sure you understand the
FEC-API and gr-fec. We have different implementations of LDPC already in
GNU Radio's gr-fec component. More than new codes, we need to optimize the
structures that we currently have. And new LDPC work should be close enough
to the current LDPC to make choosing different implementations easy and
efficient.

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

Re: [Discuss-gnuradio] Draft Proposal GSoC: Offline Analysis and Visualization Tools

[Usman Haider]

I have not get any feedback on this yet. I hope I have not missed anything
important? Please, provide feedback on this.


Regards,
Usman

On Mon, Mar 21, 2016 at 11:45 PM, Usman Haider 
wrote:

> I have added lambda expression in deliverables based on Tim's comments.
> This will allow user to enter lambda expression in GUI. That expression
> will be then evaluated on samples and result will be displayed. Rather than
> providing fixed mathematical function (scale/normalize), user  can apply
> anonymous functions, they want, on samples using Lambda construct. This
> will give user more flexibility. I have updated my proposal. You can see it
> on following link
>
> https://github.com/UHaider/GSoC/blob/master/GSOC%20Proposal.pdf
>
> Awaiting feedback.
>
> Regards,
> Usman
>
> On Thu, Mar 17, 2016 at 1:07 PM, Usman Haider 
> wrote:
>
>> Hi Community,
>>
>> I have made my proposal for the subject GSoC idea. Please have a look and
>> give feedback. Thanks for your time.
>>
>> https://github.com/UHaider/GSoC/blob/master/GSOC%20Proposal.pdf
>>
>> Regards,
>> Usman
>>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Editing usrp_spectrum_sense.py

[Marcus Müller]

Hi Fikrat,

no need to apologize :) Just keep the list in CC:, as I did now.

In fact, we're usually pretty happy to meet a few software engineers in
the GNU Radio community. We've got our own experience in writing
efficient algorithms, and our own experts in making things highly
accelerated on different platforms, and our hardware accelleration
experts, but to be honest, people with more background on how to plan
and implement software architecture are always welcome!

So, I'd like to point you to the "suggested reading" page in the GNU
Radio wiki [1]. I think what is said on the "suggested reading order"
page[2] is true for you, you might want to start by reading a few pages
of a good DSP entry level book. The beginning of Lyons' [3] might  be
good, and maybe your uni's library has it in paper form :) Anyway,
reading the first chapter of that won't be overly hard, but it will
probably help you in your final year project :)

Regarding EE basics like power: hm, it might really be worth getting
whatever first semester EE students at your university read accompanying
to their basic "linear electrical networks" lecture, just to have a
quick reference to look things up :)

Best regards,
Marcus

[1] https://gnuradio.org/redmine/projects/gnuradio/wiki/SuggestedReading
[2]
https://gnuradio.org/redmine/projects/gnuradio/wiki/SuggestedReadingOrder
[3] Lyons, Richard G. /Understanding digital signal processing/. Pearson
Education, 2010.
Pearson has the first ~80 pages as sample read: I think they might fit
you well:
http://ptgmedia.pearsoncmg.com/images/9780137027415/samplepages/0137027419.pdf

On 23.03.2016 10:27, Fikrat Al-Kazimi wrote:
> Dear Marcus,
>
> I truly apologize for any inconvenience. I clicked on the reply button
> instead of the reply all without noticing. You've been really helpful
> and I'm truly grateful.
>
> I am a software engineering student, so I don't really know much about
> power and signals. However, my final year project  includes a portion
> of Wi-Fi signal monitoring and processing, so I'm required to learn
> and work on gnuRadio!
>
> Thank you for your help again!
>
> Best regards, 
> Fikrat
>
> On Tue, Mar 22, 2016 at 10:10 PM, Marcus Müller
> mailto:marcus.muel...@ettus.com>> wrote:
>
> Dear Fikrat,
>
> the physical power depends on your waveform. Generally, the power
> is always $P(t) = U(t)\cdot I(t)$, which, thanks to Ohm's law
> ($U=R\cdot I\rightarrow I = \frac UR$) is $P(t) =
> \frac{U^2(t)}{R}$. As you might know from the basics of electrical
> engineering, one can represent harmonic functions such as a
> voltage sine generated by a function generator as complex number
> with magnitude $A$ and phase $\varphi$ , i.e. as ${\underline
> U}(t) = A \cdot e^{j\varphi}$; notice that for the power
> consideration, you can omit the $e^{j\varphi}$, it always having
> the magnitude 1. Use your math basics to find the average power by
> integrating over a period. For harmonic signals you'll find that
> if you set $A=U_{eff}=\frac 1{\sqrt 2} U_{max}$.
>> 2.  Moreover, am I supposed to connect the signal generator
>> directly to the TX/RX port?
> If you can make sure your signal generator doesn't push more than
> -15dBm into the USRP, then sure. Otherwise, use a calibrated
> attenuator and adjust your measurement.
>
> I don't know which signal generator you use, but most RF signal
> generators I know accept both, either voltage/amplitude or power
> as setting.
> Also make sure your signal generator is set to 50Ohm impedance, if
> that is adjustable.
>
>> 3.  Finally, if that was the case, how do I observe the digital
>> power on the USRP n210?
> Well, the magnitude of the imaginary and real part of the digital
> samples are proportional to the voltage on the I and Q input of
> the ADC... S: Digital power is just I²+Q² = |s|², the
> magnitude squared.
>
> All in all, these are pretty basic questions; we're constantly
> working on making GNU Radio more beginner-friendly, but to do
> that, we might at times need to refer people to adequate literature.
> So: May I ask what background you come from?
>
> Best regards,
> Marcus
>
> PS: could you also try to keep the discuss-gnuradio@gnu.org
>  mailing list at least in CC:?
> It's always better to ask the whole list instead of individual
> people. I might not always have the time...
>
> On 22.03.2016 17:48, Fikrat Al-Kazimi wrote:
>> Dear Marcus,
>>
>> Thanks a lot for your reply. I'm really grateful!
>>
>> I have a few more inquiries I wish to get your help with if you
>> don't mind. I just got access to a function generator and I plan
>> on generating my injected signal using it. 
>>
>> 1.  The physical power of the injected signal is measured as
>> Vmax^2 / 2R ?
>> 2.  Moreover, am I supposed to connect the signal generat

Re: [Discuss-gnuradio] problem with packet encoder block

[Marcus Müller]

Hi Miguel,
:)

Having had a night of sleep:
Normally in GNU Radio, you've got input- and output buffers, and if
there's no space in your output buffer, you can't process input, so you
stall until there's space in your output buffer.
That's how the throttle block works: by not taking samples from its
input buffer faster than specified by the "throttle rate", it not only
slows down the blocks downstream in the flow graph, but it also keeps
the input buffer full. Its input buffer is the output buffer of the
block upstream, and so, that block can't run arbitrarily fast (that
mechanism is called /backpressure/, by the way).

But: The packet_encoder, old as it is, internally uses an old-style
message sink. Which means it takes samples out of its input buffer,
processes them somehow, and shoves them into a FIFO.
That FIFO does not have a way of saying "I'm full", but just grows and
grows and grows... So, the packet_encoder breaks up the backpressure
chain, and that's a bad thing, architecturally, as you can see, because
the block upstream (i.e. the vector source) can now run as fast as it
can – that is, as fast as the packet_encoder consumes the items it
produces, and as fast as the file sink consumes them, whatever is slower.

Without the packet_encoder, backpressure from the throttle block works,
so that's why your file is smaller.

Hope that explains the observation, at least a bit :)

Best regards,
Marcus

On 23.03.2016 00:11, Miguel Santos wrote:
> Sadly, we all need some sleep...
> Well, thanks, A LOT! I'll try that.
> Have a good night, you deserve a statue or a Nobel or something like that!
>
> Best regards,
> Miguel
>
> On 22-03-2016 22:41, Marcus Müller wrote:
>> Indeed, there seems to be a problem here; sadly, I'll really need
>> some sleep tonight ;)
>>
>> To answer your question, yes, Packet Encoder is really old and IMHO
>> should be deprecated in favor of the architecture you'd find in the
>> ofdm_tx.grc example (should be installed somewhere like
>> /usr/(local/)share/gnuradio/examples/gnuradio/digital/ofdm )
>>
>> However, if you just need a preamble:
>> use a second vector source for the preamble (or something else), and
>> use the "patterned interleaver", e.g. with something like pattern =
>> [1]*header_len + [0]*payload_len
>>
>> Best regards,
>> Marcus
>>
>> On 22.03.2016 23:17, Miguel Santos wrote:
>>> As an attachment I send the .grc on which I'm doing tests.
>>> So:
>>>  - with head and/or throttle between source and packet encoder -> fine
>>>  - bypassing Head and Throttle -> huge file
>>>  - bypassing Head, Throttle and Encoder -> fine
>>> I answered your questions below.
>>>
>>> Another question: I'm using Packet Encoder only to add a preamble to 
>>> perform frame sync. Is it the only way?
>>>
>>> On 22-03-2016 21:42, Marcus Müller wrote:
 Hi Miguel,

 On 22.03.2016 21:54, Miguel Santos wrote:
> On 22-03-2016 20:32, Marcus Müller wrote:
>> Hi Miguel,
>>
>> On 22.03.2016 17:14, Miguel Santos wrote:
>>> Yes, it's set to repeat.
>> oh!
>>> My real flow graph ends with a file sink, but
>>> here, as an example to test which block was the problem, I used a number
>>> sink just to be able to run it and test it.
>> But then, how does your flow graph decide it's done?
> It doesn't. For now, I'm dealing with transmitting and receiving
> problems, so I don't really care about the message. For testing purposes
> I'm transmitting an infinite amount of 0s and 1s (the same repeated
> sequence defined in Vector Source block) and I manually stop the flow
> graph after a certain amount of time.
 Ah, so there's no "right" amount of samples. It all depends on when you
 decide to manually stop, and on the speed at which samples are processed.
 I'd recommend adding a "head" block somewhere. That will signal "hey,
 we're done" as soon as the specified amount of samples have passed.
>>> Exactly! I tested with the Head block and it behaves as it should. I 
>>> think the problem occurs only when vector source is connected directly 
>>> to packet encoder.
>>> By the way, why does the file becomes empty if "Num items"<4096? I'm new 
>>> to this world and there's a LOT of things I don't understand.
>>>
>   The differences between the two
> cases I presented were noted running the flow graph for, for instance, 5
> seconds (counted by me). It's not very accurate, I know, but we're
> talking of a big difference (like a few KB or MB to hundreds of MB or
> even a few GB), so it's not important.
 So, sorry for asking again, but I really want to be sure: *with* the
 packet_encoder, the file is much much larger than without, right?

 Best regards,
 Marcus
>>> Yeah, that's it: WITH
>>>
> Thanks for your time and sorry for not being explicit enough.
 Don't worry! If this is a bug, it's really worth figuring out.
 Also, we're a helpful bunch of people.

 Best regards,

Re: [Discuss-gnuradio] PYBOMBS CtrlPort pygraphviz dependency

[Laur Joost]

Thanks for the responses, and damned be the timezones.

Nathan: gr-perf-monitorx needs python-networkx (which is installed by
pybombs, or at least, existed for me), but python-networkx needs
python-pygraphviz, at least for how it's used by gr-perf-monitorx.

Tom: Yes, the errors popped up when networkx called agraph-something.
Sadly, I managed to blow up my installation, so can't get a traceback for
you (was able to reproduce by simply doing apt-get uninstall graphviz).

On another note (the blowing up), I had an issue with gr-uhd ABI versions:
When trying to use USRP on the same install, I got:

Traceback (most recent call last):
  File "/home/ec/Tests/top_block.py", line 167, in 
main()
  File "/home/ec/Tests/top_block.py", line 155, in main
tb = top_block_cls()
  File "/home/ec/Tests/top_block.py", line 69, in __init__
channels=range(1),
  File
"/home/ec/gnuradio/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py",
line 122, in constructor_interceptor
return old_constructor(*args)
  File
"/home/ec/gnuradio/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
line 1973, in make
return _uhd_swig.usrp_source_make(*args)
RuntimeError:
GR-UHD detected ABI compatibility mismatch with UHD library.
GR-UHD was build against ABI: 3.9.0-0,
but UHD library reports ABI: 3.10.0-0
Suggestion: install an ABI compatible version of UHD,
or rebuild GR-UHD component against this ABI version.

However, install log shows:

Configuring gr-uhd support...
--   Dependency Boost_FOUND = 1
--   Dependency UHD_FOUND = TRUE
--   Dependency ENABLE_GNURADIO_RUNTIME = ON
--   Dependency ENABLE_GR_FILTER = ON
--   Dependency ENABLE_GR_BLOCKS = ON
--   Dependency ENABLE_GR_ANALOG = ON
--   Enabling gr-uhd support.
--   Override with -DENABLE_GR_UHD=ON/OFF
--   UHD Version: 3.10.git

I had UHD 3.9.1 installed via package manager (wasn't as thorough as I'd
hoped in cleaning gnuradio 3.7.8 from the system), but if the detected
version in the log was 3.10, I would've thought that that would be the
version built against. I guess its mostly PEBKAC, but still, weird.

I'll try building again this night, this time without 3.9 installed. If the
issue persists, I'll make another thread.

2016-03-23 1:30 GMT+02:00 Tom Rondeau :

> On Tue, Mar 22, 2016 at 7:05 PM, West, Nathan  > wrote:
>
>> Sorry, may or may not be talking about the same thing here.
>> gr-perf-monitorx requires python-networkx, which (I think) is an untracked
>> dependency.
>>
>
>
> For utilities like this, we have not previously made Python modules a
> required dependency of GNU Radio. We could, but that would put an extra
> burden on just building the project even if you don't use the particular
> app or example. Generally, we try to provide a friendly message explaining
> the problem. PyBOMBS probably should add these dependencies, though. At
> least scipy.
>
> Also, I believe I ran into this issue recently new versions of networkx
> that broke out a dependency that used to not be required as a separate
> install, which I think is what the OP's problem is related to. See PR #768:
>
> https://github.com/gnuradio/gnuradio/pull/768
>
> Tom
>
>
>
>
>> On Tue, Mar 22, 2016 at 7:04 PM, West, Nathan <
>> n...@ostatemail.okstate.edu> wrote:
>>
>>> gr-perf-monitorx. It's just been the kind of thing that everyone that
>>> uses it already has and no one tracks it. There's a couple of minor deps
>>> for utilities like this that sneak through the cracks, but they're very
>>> hard to keep track of until you run this on a brand new image.
>>>
>>> nw
>>>
>>> On Tue, Mar 22, 2016 at 6:46 PM, Martin Braun 
>>> wrote:
>>>
 Who is calling pygraphviz? If we need this for GNU Radio, we probably
 need to update some recipes.

 M

 On 03/22/2016 12:12 PM, Laur Joost wrote:
 > Hi all!
 >
 > Fresh install of gnuradio-3.7.9.1 via PyBOMBS-2.0.1 on Ubuntu 15.10
 >
 > When trying to run CrtlPort Performance Monitor on a fresh 3.7.9.1
 > install, I got errors about missing pygraphviz.
 >
 > sudo apt-get python-pygraphviz
 >
 > solved it for me. The supposedly equivalent
 >
 > sudo apt-get install graphviz
 > [sudo apt-get install graphviz-dev libgraphviz-dev]
 > pip install pygraphviz
 >
 > threw a bunch of errors and claimed to be successful, but didn't work.
 > So beware PyPI, in this case.
 >
 >
 > ___
 > 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] GSOC 2016: Help Review Project Proposal

[Jan Krämer]

Hi Tanero,

It seems that you know your way around LDPC Codes and the theory behind it,
which is a really good thing. But there are still things to improve.

- Check your spelling and grammar again. Also the formatting needs
reshaping (at least in Githubs preview and Fedoras document viewer) .
- Regarding optimizations. If you manage to highlight a bit more, how SIMD
could help improve the speed by parallelizing steps and how reducing the
Parity check matrixes helps with random memory accesses that would be a
great plus for your proposal.
- You should try to get a bit more familiar with the FEC-API. You have an
extra timeslot dedicated to integrating the finished OOT blocks into the
FEC-API. Just for the record, you can have your own OOT block that is
already using the FEC-API. Transferring that OOT block is to core-GNURadio
would just be a copy of the source files and adjusting of the gr-fec
CMakeLists.txt. I think it would fine with developing the blocks first as
an OOT module (if it is using the FEC-API from the beginning) and then
porting it to gr-fec. But directly integrating the LDPC blocks in gr-fec
would be also an option.

Cheers and happy hacking,
Jan



2016-03-22 5:11 GMT+01:00 Tanero Juthero :

>   I made an update to the proposal,mentors please help me review the
> proposal,your opinions highly
>
> awaited.Here is the link
> https://github.com/tanerochris/gsoc-2016/blob/master/%20gsoc_2016_application.pdf
>
> 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