Re: [Discuss-gnuradio] INMARSAT wide signal question

[Kevin McQuiggin]

My error, typo I meant GMSK!!

Sent from my iPad

> On May 3, 2016, at 9:31 PM, Kevin McQuiggin  wrote:
> 
> Hi Henry:
> 
> The narrowest channels are 600 bps MPSK, although in Inmarsat parlance they 
> call it "A-BPSK".  There are 1200, 4800, 10200 bps channels as well, plus 
> faster ones I have not really considered yet.
> 
> The spec document describes it all.
> 
> I find the signal to be quite strong, perhaps check your polarization or 
> antenna pointing.  You'll want RHCP for Inmarsat.  Signals are well above the 
> noise floor for me.  I'm using an Ettus B200.
> 
> Also, check out a program called "JAERO", the web site has lots of relevant 
> information.
> 
> My program isn't on github yet, I'm an old timer so I'm developing it 
> locally.  I can release it once it's ready!
> 
> Kevin
> 
> Sent from my iPad
> 
>> On May 3, 2016, at 8:31 PM, Henry Barton  wrote:
>> 
>> So the control channels are the narrow ones? I’m guessing the really wide 
>> ones are the traffic. (On a side note, I’m kind of surprised that people 
>> [you and killmore231] can get Inmarsat with a patch. I just barely see the 
>> signals with 9A4QAV’s helix and an SDRplay. However, Iridium comes in like a 
>> blowtorch.) Anyway, can’t wait to see your program. Is it on Github?
>> 
>> Sent from Windows Mail
>> 
>> From: Kevin McQuiggin
>> Sent: ‎Tuesday‎, ‎May‎ ‎3‎, ‎2016 ‎10‎:‎02‎ ‎PM
>> To: Henry Barton
>> Cc: discuss-gnuradio@gnu.org
>> 
>> Hi Henry:
>> 
>> I have an Inmarsat demodulator working for the lower speed control channels. 
>>  I am writing a program to decode the traffic, but this is not a trivial 
>> task.  Think on the order of 1000 lines of C.  It is "almost" working, I am 
>> hoping for valid output in the next week or so, depending on my free time.
>> 
>> My program is currently a standalone program, but once it's done it could 
>> conceivably be converted to one or more gnuradio blocks.  
>> 
>> I suggest the following document to give you background on the channel 
>> specifications for Inmarsat:
>> 
>> http://www.icao.int/safety/acp/inactive%20working%20groups%20library/acp-wg-m-iridium-8/ird-swg08-wp07%20-%20old_amss_material_ch.4_plus_attachment.doc
>> 
>> The demodulation is fairly easy, read the spec document and the channel 
>> characteristics are pretty well described.  My gnuradio demodulator is based 
>> on the GMSK demod block.  I'm using a home brew patch antenna, and the 
>> LNA4ALL low noise amplifier.
>> 
>> Kevin
>> 
>> Sent from my iPad
>> 
>> On May 3, 2016, at 12:45 PM, Henry Barton  wrote:
>> 
>> http://rtlsdrblog.rtlsdrblog.netdna-cdn.com/wp-content/uploads/2015/10/sdrplay_lband-1024x573.png
>> I didn’t see the widest signal (bright yellow) from this picture on 
>> sigidwiki.com. Does anyone know what it is? If so, can it be decoded by 
>> GNUradio? Thanks.
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] INMARSAT wide signal question

[Kevin McQuiggin]

Hi Henry:

The narrowest channels are 600 bps MPSK, although in Inmarsat parlance they 
call it "A-BPSK".  There are 1200, 4800, 10200 bps channels as well, plus 
faster ones I have not really considered yet.

The spec document describes it all.

I find the signal to be quite strong, perhaps check your polarization or 
antenna pointing.  You'll want RHCP for Inmarsat.  Signals are well above the 
noise floor for me.  I'm using an Ettus B200.

Also, check out a program called "JAERO", the web site has lots of relevant 
information.

My program isn't on github yet, I'm an old timer so I'm developing it locally.  
I can release it once it's ready!

Kevin

Sent from my iPad

> On May 3, 2016, at 8:31 PM, Henry Barton  wrote:
> 
> So the control channels are the narrow ones? I’m guessing the really wide 
> ones are the traffic. (On a side note, I’m kind of surprised that people [you 
> and killmore231] can get Inmarsat with a patch. I just barely see the signals 
> with 9A4QAV’s helix and an SDRplay. However, Iridium comes in like a 
> blowtorch.) Anyway, can’t wait to see your program. Is it on Github?
> 
> Sent from Windows Mail
> 
> From: Kevin McQuiggin
> Sent: ‎Tuesday‎, ‎May‎ ‎3‎, ‎2016 ‎10‎:‎02‎ ‎PM
> To: Henry Barton
> Cc: discuss-gnuradio@gnu.org
> 
> Hi Henry:
> 
> I have an Inmarsat demodulator working for the lower speed control channels.  
> I am writing a program to decode the traffic, but this is not a trivial task. 
>  Think on the order of 1000 lines of C.  It is "almost" working, I am hoping 
> for valid output in the next week or so, depending on my free time.
> 
> My program is currently a standalone program, but once it's done it could 
> conceivably be converted to one or more gnuradio blocks.  
> 
> I suggest the following document to give you background on the channel 
> specifications for Inmarsat:
> 
> http://www.icao.int/safety/acp/inactive%20working%20groups%20library/acp-wg-m-iridium-8/ird-swg08-wp07%20-%20old_amss_material_ch.4_plus_attachment.doc
> 
> The demodulation is fairly easy, read the spec document and the channel 
> characteristics are pretty well described.  My gnuradio demodulator is based 
> on the GMSK demod block.  I'm using a home brew patch antenna, and the 
> LNA4ALL low noise amplifier.
> 
> Kevin
> 
> Sent from my iPad
> 
> On May 3, 2016, at 12:45 PM, Henry Barton  wrote:
> 
> http://rtlsdrblog.rtlsdrblog.netdna-cdn.com/wp-content/uploads/2015/10/sdrplay_lband-1024x573.png
> I didn’t see the widest signal (bright yellow) from this picture on 
> sigidwiki.com. Does anyone know what it is? If so, can it be decoded by 
> GNUradio? Thanks.
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GR win64 binaries v1.1 posted

[Geof Nieboer]

The initial GRC errors are known and for now occur on all the builds.

The QT/GTK error is interesting.  Unfortunately, I'm still building blind
for these older systems, in a month I'll have good direct access.  I will
try to work it regardless.

Thanks for the feedback!




On Wed, May 4, 2016 at 4:24 AM, Achilleas Anastasopoulos 
wrote:

> I had partial success with these binaries:
>
> 1) GRC starts with the following warnings which I am not sure if they are
> important:
>
> ---
> setting gnuradio environment
>
> ** (python.exe:2060): WARNING **: Trying to register gtype
> 'GMountMountFlags' as
>  enum when in fact it is of type 'GFlags'
>
> ** (python.exe:2060): WARNING **: Trying to register gtype
> 'GDriveStartFlags' as
>  enum when in fact it is of type 'GFlags'
>
> ** (python.exe:2060): WARNING **: Trying to register gtype
> 'GSocketMsgFlags' as
> enum when in fact it is of type 'GFlags'
> gnuradio-companion.py:122: GtkWarning: Could not find the icon
> 'gnuradio-grc'. T
> he 'hicolor' theme
> was not found either, perhaps you need to install it.
> You can get a copy from:
> http://icon-theme.freedesktop.org/releases
>   gtk.window_set_default_icon(gtk.IconTheme().load_icon('gnuradio-grc',
> 256, 0))
>
> <<< Welcome to GNU Radio Companion 3.7.9.2 >>>
>
> Preferences file: C:\Users\anastas/.gnuradio/grc.conf
> Block paths:
> C:\Users\anastas\.grc_gnuradio (C:\Users\anastas/.grc_gnuradio)
> C:\Program Files\GNURadio-3.7\share\gnuradio\grc\blocks
> (C:\Program File
> s\GNURadio-3.7\bin\..\share\gnuradio\grc\blocks)
> ---
>
>
> 2) A simple flowgraph with noise, throttle, filter, fft display runs
> perfectly with WX.
> The following info is displayed:
> 
> Generating: 'C:\\Users\\anastas\\Dropbox\\gnuradio_examples\\top_block.py'
>
> Executing: C:\Program Files\GNURadio-3.7\gr-python27\python.exe -u
> C:\Users\anas
> tas\Dropbox\gnuradio_examples\top_block.py
>
> Using Volk machine: ssse3
> fft_impl_fftw: ÿÿ\Users\anastas\AppData\Roaming\.gr_fftw_wisdom: No such
> file or
>  directory
> C:\Program
> Files\GNURadio-3.7\lib\site-packages\gnuradio\grc\gui\Dialogs.py:67:
> GtkWarning: gtk_text_buffer_emit_insert: assertion 'g_utf8_validate (text,
> len,
> NULL)' failed
>   self.get_buffer().insert(self.get_buffer().get_end_iter(), line)
> ¶: Invalid argument
> gr::pagesize: no info; setting pagesize = 4096
> ¶: Invalid argument
>
> >>> Done
> --
>
>
> 3) However the QT version of the above simple flowgraph does not run; it
> returns the error:
> --
> Executing: C:\Program Files\GNURadio-3.7\gr-python27\python.exe -u
> C:\Users\anas
> tas\Dropbox\gnuradio_examples\top_block.py
>
> Using Volk machine: ssse3
> fft_impl_fftw: ÿÿ\Users\anastas\AppData\Roaming\.gr_fftw_wisdomC:\Program
> Files\
> GNURadio-3.7\lib\site-packages\gnuradio\grc\gui\Dialogs.py:67: GtkWarning:
> gtk_t
> ext_buffer_emit_insert: assertion 'g_utf8_validate (text, len, NULL)'
> failed
>   self.get_buffer().insert(self.get_buffer().get_end_iter(), line)
> : No such file or directory
>
> >>> Done
> -
>
> thanks
> Achilleas
>
>
>
>
> On Tue, May 3, 2016 at 5:05 PM, Geof Nieboer 
> wrote:
>
>> All,
>>
>> An updated set of windows binaries and build scripts have been posted.
>> Quick summary:
>> 1- Added gqrx to package
>> 2- Patched 2 x issues which would cause the generic version to crash on
>> non-AVX systems (one in volk, one in FFTW)
>> 3- Added gr-newmod to package
>>
>> Plus a number of improvements to make the scripts more robust.
>>
>> Binaries at http://www.gcndevelopment.com/gnuradio/downloads.htm
>> Scripts at https://github.com/gnieboer/GNURadio_Windows_Build_Scripts
>>
>> A couple gqrx known bugs:
>> 1- Toolbar icons do not appear (our Qt5 issue)
>> 2- Switching a USRP to another modulation will cause a crash (upstream
>> UHD)
>> 3- Switching between a RTL-SDR device and a USRP device will cause a
>> crash (upstream gqrx)
>>
>> Cheers,
>>
>> Geof
>>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] INMARSAT wide signal question

[Henry Barton]

So the control channels are the narrow ones? I’m guessing the really wide ones 
are the traffic. (On a side note, I’m kind of surprised that people [you and 
killmore231] can get Inmarsat with a patch. I just barely see the signals with 
9A4QAV’s helix and an SDRplay. However, Iridium comes in like a blowtorch.) 
Anyway, can’t wait to see your program. Is it on Github?






Sent from Windows Mail





From: Kevin McQuiggin
Sent: ‎Tuesday‎, ‎May‎ ‎3‎, ‎2016 ‎10‎:‎02‎ ‎PM
To: Henry Barton
Cc: discuss-gnuradio@gnu.org





Hi Henry:




I have an Inmarsat demodulator working for the lower speed control channels.  I 
am writing a program to decode the traffic, but this is not a trivial task.  
Think on the order of 1000 lines of C.  It is "almost" working, I am hoping for 
valid output in the next week or so, depending on my free time.




My program is currently a standalone program, but once it's done it could 
conceivably be converted to one or more gnuradio blocks.  




I suggest the following document to give you background on the channel 
specifications for Inmarsat:




http://www.icao.int/safety/acp/inactive%20working%20groups%20library/acp-wg-m-iridium-8/ird-swg08-wp07%20-%20old_amss_material_ch.4_plus_attachment.doc




The demodulation is fairly easy, read the spec document and the channel 
characteristics are pretty well described.  My gnuradio demodulator is based on 
the GMSK demod block.  I'm using a home brew patch antenna, and the LNA4ALL low 
noise amplifier.




Kevin


Sent from my iPad


On May 3, 2016, at 12:45 PM, Henry Barton  wrote:






http://rtlsdrblog.rtlsdrblog.netdna-cdn.com/wp-content/uploads/2015/10/sdrplay_lband-1024x573.png

I didn’t see the widest signal (bright yellow) from this picture on 
sigidwiki.com. Does anyone know what it is? If so, can it be decoded by 
GNUradio? 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

Re: [Discuss-gnuradio] INMARSAT wide signal question

[Kevin McQuiggin]

Hi Henry:

I have an Inmarsat demodulator working for the lower speed control channels.  I 
am writing a program to decode the traffic, but this is not a trivial task.  
Think on the order of 1000 lines of C.  It is "almost" working, I am hoping for 
valid output in the next week or so, depending on my free time.

My program is currently a standalone program, but once it's done it could 
conceivably be converted to one or more gnuradio blocks.  

I suggest the following document to give you background on the channel 
specifications for Inmarsat:

http://www.icao.int/safety/acp/inactive%20working%20groups%20library/acp-wg-m-iridium-8/ird-swg08-wp07%20-%20old_amss_material_ch.4_plus_attachment.doc

The demodulation is fairly easy, read the spec document and the channel 
characteristics are pretty well described.  My gnuradio demodulator is based on 
the GMSK demod block.  I'm using a home brew patch antenna, and the LNA4ALL low 
noise amplifier.

Kevin

Sent from my iPad

> On May 3, 2016, at 12:45 PM, Henry Barton  wrote:
> 
> http://rtlsdrblog.rtlsdrblog.netdna-cdn.com/wp-content/uploads/2015/10/sdrplay_lband-1024x573.png
> I didn’t see the widest signal (bright yellow) from this picture on 
> sigidwiki.com. Does anyone know what it is? If so, can it be decoded by 
> GNUradio? 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

Re: [Discuss-gnuradio] Introducing the New GNU Radio Website

[Ben Hilburn]

> On Tue, May 3, 2016 at 4:26 PM, Richard Bell 
>  wrote:
>
>> I like the new style, it feels fresh and modern.
>>
>
I'm glad you like it!


> I've noticed that depending on the link you click, you may end up on a
>> page in the old style. For example, clicking the development link does
>> this. Will the entire website eventually get the makeover?
>>
>
Right, that's the Redmine-hosted content. Eventually, Redmine will go away
completely and all of the content will be migrated to the new site or
tossed (there is a lot of extremely old out-of-date info on Redmine). The
WordPress-based site you see now is also only half of the `new GNU Radio
site`. We are working on a self-hosted Gitlab
 instance
that we will use for developer-focused content.

I imagine part of the challenge will be keeping the various sections of the
> website which are written wiki style by the community editable.
>

The WordPress site is *not* community editable, and never will be. Content
that needs to be in a wiki (i.e., community editable) will be on the Gitlab
instance, though, and will be editable in the same way that the Redmine
content is editable.

If so, I hope that it's artisanal, and organic...  :) :)
>

It's also gluten free and rBGH free!

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

Re: [Discuss-gnuradio] Introducing the New GNU Radio Website

[West, Nathan]

The development link is intended for keeping developer focused content
which is highly dynamic. It will always go to a wiki. It won't always be
redmine, but I'll leave that as a teaser so you listen to the monthly dev
calls ;-)

-Nathan

On Tue, May 3, 2016 at 7:26 PM, Richard Bell 
wrote:

> I like the new style, it feels fresh and modern.
>
> I've noticed that depending on the link you click, you may end up on a
> page in the old style. For example, clicking the development link does
> this. Will the entire website eventually get the makeover?
>
> Rich
>
> On Tue, May 3, 2016 at 1:44 PM, Ben Hilburn  wrote:
>
>> Hi all -
>>
>> I am happy to share that primary development on the user-facing GNU Radio
>> website has been wrapped up! You can check out the new site in action at
>> gnuradio.org.
>>
>> There is still a lot of content work to do as we migrate away from
>> Redmine (you may notice that many of the links on the website take you to
>> Redmine-hosted content, at the moment), but initial development on the site
>> infrastructure itself has wrapped up. There are some items we would still
>> like to get to eventually (like integrating the site Events Calendar
>>  with the Org GCal
>> ),
>> so if you have any ideas for further improvement, feel free to send them my
>> way. Also, if you are into web development and would like to get involved,
>> please let me know!
>>
>> Going forward, community & project News  and
>> Events  will be posted on the website (in
>> addition to the mailing list, as usual), and developers will be sharing
>> articles in the Blog  area of the site. If
>> you have an idea for content that you would like to share with the broader
>> community on the site, just get in touch. And, of course, if you spot any
>> issues, please send me a note.
>>
>> A special thanks to Marcus Mueller, who did a ton of work on most of the
>> images that appear on the site, and to Johnathan Corgan, who manages our
>> server infrastructure in addition to everything else he is doing for the
>> project.
>>
>> Cheers,
>> Ben
>>
>> ___
>> 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] Feedback with Transmitters and Receiver

[Pavan Yedavalli]

Makes sense, and will do! Thanks.

On Tue, May 3, 2016 at 6:41 PM, Derek Kozel  wrote:

> That's what I put the standard deviation in for. Your photos are showing
> ~1 degree of deviation which certainly points to the system being
> synchronized. The flowgraph is crude though and can definitely be improved
> so don't pay too close attention to the exact number of the deviation. If
> you do make a more rigorous one please share it with us.
>
> On Tue, May 3, 2016 at 6:38 PM, Pavan Yedavalli 
> wrote:
>
>> Hi Derek,
>>
>> Thanks. Wrt the degrees versus dB, wouldn't it be more useful to test
>> that the phase error (not the offset) is only changing over time by less
>> than some threshold? It's already known that the offset is around 60
>> degrees, but the question is how much it varies *from* 60 degrees over
>> time, right? I thought that was magnitude of the error we were plotting - I
>> misunderstood. But thank you for clarifying.
>>
>> I have no doubt that I will have more questions regarding how to send
>> bursts and general tags/timed commands, so I will keep you posted as I
>> learn and try to do them. Thank you again for all the help.
>>
>> On Tue, May 3, 2016 at 6:06 PM, Derek Kozel 
>> wrote:
>>
>>> Just for clarity. That's a phase error in degrees not dB. :) And yes,
>>> there's expected to be an offset. The correct behaviour is that the phase
>>> offset is stable for a given frequency (assuming no other changes in the
>>> system) and that tuning away and back or restarting should produce the same
>>> phase offset (some combinations of motherboards and daughterboards can
>>> result in a 180 degree ambiguity).
>>>
>>> To see the time synchronization you'll need to try sending bursts and
>>> look at the rising/falling edge of the signals to see time alignment. But I
>>> think you can move forward feeling pretty sure that that is working
>>> correctly. When you get timed commands working bursts are a natural thing
>>> to implement so you can verify your alignment then.
>>>
>>> Good luck with the next steps.
>>>
>>> On Tue, May 3, 2016 at 4:50 PM, Pavan Yedavalli 
>>> wrote:
>>>
 Hi Derek,

 Thanks for getting back to me. I lowered the Tx gain by about 15 dB on
 each channel, and then now it's looking good. It makes sense that it was
 clipping. Using your flowgraph (thanks!), I am appearing to get good
 results for setup (2), which is what we want. Looking at phase_error.png,
 we are getting a phase error of about -60 dB, which is very good. And we
 can see from i_and_q_both_channels.png that the phase offset is about 60
 degrees (pi/3) (looking at both I and Q). I think this shows that both
 transmitters are transmitting at the same time. If I applied accurate
 beamforming weights, then ideally that phase offset would be eliminated
 (which is what I plan to do). I just want to make sure from you that this
 behavior makes sense.

 I believe my next step would be to look into timed commands in UHD and
 tags in GNU Radio to see how I can now transmit something from these two
 aligned transmitters to just one receiver, then calculate that power at the
 receiver, and then send it back to the transmitters for some processing
 before transmitting again.

 On Tue, May 3, 2016 at 4:05 PM, Derek Kozel 
 wrote:

> Hello Pavan,
>
> Your signal strength is much too high. You can see on the plots that
> the received signal is greater than 1 (assuming a sinusoid input). Lower
> the transmit gain and/or the receive gain until you are no longer 
> clipping.
> The ADC is being overloaded so the spikes are entirely to be expected. You
> have the 20dB attenuation which should be preventing any damage, but the
> N210+SBX is still plenty sensitive enough to clip.
>
> Test 1, where the receivers are not synchronized, will tell you none
> of time, frequency, or phase alignment since the receivers could be in any
> state compared to each other and the synchronized transmitter pair.
>
> Test 2, where the receivers are synchronized with 1PPS and 10 MHz
> references from the same octoclock as the transmitters (or another GPSDO 
> of
> similar grade) will give you time, frequency, and phase (with SBXs)
> information.
>
> I suggest not using complex to float conversion blocks and looking at
> the raw complex values. It should be easy to see time and frequency sink
> with the time sink.
>
> To measure phase alignment you can take the two outputs of your source
> block and use a conjugate multiply to view the relative phase offset. I've
> attached a flowgraph which I use to prove B210 phase alignment. You should
> be able to copy the flowgraph over to your setup pretty simply.
>
> Cheers,
> Derek
>
> 

Re: [Discuss-gnuradio] Feedback with Transmitters and Receiver

[Derek Kozel]

That's what I put the standard deviation in for. Your photos are showing ~1
degree of deviation which certainly points to the system being
synchronized. The flowgraph is crude though and can definitely be improved
so don't pay too close attention to the exact number of the deviation. If
you do make a more rigorous one please share it with us.

On Tue, May 3, 2016 at 6:38 PM, Pavan Yedavalli 
wrote:

> Hi Derek,
>
> Thanks. Wrt the degrees versus dB, wouldn't it be more useful to test that
> the phase error (not the offset) is only changing over time by less than
> some threshold? It's already known that the offset is around 60 degrees,
> but the question is how much it varies *from* 60 degrees over time,
> right? I thought that was magnitude of the error we were plotting - I
> misunderstood. But thank you for clarifying.
>
> I have no doubt that I will have more questions regarding how to send
> bursts and general tags/timed commands, so I will keep you posted as I
> learn and try to do them. Thank you again for all the help.
>
> On Tue, May 3, 2016 at 6:06 PM, Derek Kozel  wrote:
>
>> Just for clarity. That's a phase error in degrees not dB. :) And yes,
>> there's expected to be an offset. The correct behaviour is that the phase
>> offset is stable for a given frequency (assuming no other changes in the
>> system) and that tuning away and back or restarting should produce the same
>> phase offset (some combinations of motherboards and daughterboards can
>> result in a 180 degree ambiguity).
>>
>> To see the time synchronization you'll need to try sending bursts and
>> look at the rising/falling edge of the signals to see time alignment. But I
>> think you can move forward feeling pretty sure that that is working
>> correctly. When you get timed commands working bursts are a natural thing
>> to implement so you can verify your alignment then.
>>
>> Good luck with the next steps.
>>
>> On Tue, May 3, 2016 at 4:50 PM, Pavan Yedavalli 
>> wrote:
>>
>>> Hi Derek,
>>>
>>> Thanks for getting back to me. I lowered the Tx gain by about 15 dB on
>>> each channel, and then now it's looking good. It makes sense that it was
>>> clipping. Using your flowgraph (thanks!), I am appearing to get good
>>> results for setup (2), which is what we want. Looking at phase_error.png,
>>> we are getting a phase error of about -60 dB, which is very good. And we
>>> can see from i_and_q_both_channels.png that the phase offset is about 60
>>> degrees (pi/3) (looking at both I and Q). I think this shows that both
>>> transmitters are transmitting at the same time. If I applied accurate
>>> beamforming weights, then ideally that phase offset would be eliminated
>>> (which is what I plan to do). I just want to make sure from you that this
>>> behavior makes sense.
>>>
>>> I believe my next step would be to look into timed commands in UHD and
>>> tags in GNU Radio to see how I can now transmit something from these two
>>> aligned transmitters to just one receiver, then calculate that power at the
>>> receiver, and then send it back to the transmitters for some processing
>>> before transmitting again.
>>>
>>> On Tue, May 3, 2016 at 4:05 PM, Derek Kozel 
>>> wrote:
>>>
 Hello Pavan,

 Your signal strength is much too high. You can see on the plots that
 the received signal is greater than 1 (assuming a sinusoid input). Lower
 the transmit gain and/or the receive gain until you are no longer clipping.
 The ADC is being overloaded so the spikes are entirely to be expected. You
 have the 20dB attenuation which should be preventing any damage, but the
 N210+SBX is still plenty sensitive enough to clip.

 Test 1, where the receivers are not synchronized, will tell you none of
 time, frequency, or phase alignment since the receivers could be in any
 state compared to each other and the synchronized transmitter pair.

 Test 2, where the receivers are synchronized with 1PPS and 10 MHz
 references from the same octoclock as the transmitters (or another GPSDO of
 similar grade) will give you time, frequency, and phase (with SBXs)
 information.

 I suggest not using complex to float conversion blocks and looking at
 the raw complex values. It should be easy to see time and frequency sink
 with the time sink.

 To measure phase alignment you can take the two outputs of your source
 block and use a conjugate multiply to view the relative phase offset. I've
 attached a flowgraph which I use to prove B210 phase alignment. You should
 be able to copy the flowgraph over to your setup pretty simply.

 Cheers,
 Derek

 On Tue, May 3, 2016 at 3:51 PM, Pavan Yedavalli 
 wrote:

> Hi Derek,
>
> I was able to put in another USRP as a receiver, so I have the same
> transmit setup (connected to Octoclock 

Re: [Discuss-gnuradio] Feedback with Transmitters and Receiver

[Pavan Yedavalli]

Hi Derek,

Thanks. Wrt the degrees versus dB, wouldn't it be more useful to test that
the phase error (not the offset) is only changing over time by less than
some threshold? It's already known that the offset is around 60 degrees,
but the question is how much it varies *from* 60 degrees over time, right?
I thought that was magnitude of the error we were plotting - I
misunderstood. But thank you for clarifying.

I have no doubt that I will have more questions regarding how to send
bursts and general tags/timed commands, so I will keep you posted as I
learn and try to do them. Thank you again for all the help.

On Tue, May 3, 2016 at 6:06 PM, Derek Kozel  wrote:

> Just for clarity. That's a phase error in degrees not dB. :) And yes,
> there's expected to be an offset. The correct behaviour is that the phase
> offset is stable for a given frequency (assuming no other changes in the
> system) and that tuning away and back or restarting should produce the same
> phase offset (some combinations of motherboards and daughterboards can
> result in a 180 degree ambiguity).
>
> To see the time synchronization you'll need to try sending bursts and look
> at the rising/falling edge of the signals to see time alignment. But I
> think you can move forward feeling pretty sure that that is working
> correctly. When you get timed commands working bursts are a natural thing
> to implement so you can verify your alignment then.
>
> Good luck with the next steps.
>
> On Tue, May 3, 2016 at 4:50 PM, Pavan Yedavalli 
> wrote:
>
>> Hi Derek,
>>
>> Thanks for getting back to me. I lowered the Tx gain by about 15 dB on
>> each channel, and then now it's looking good. It makes sense that it was
>> clipping. Using your flowgraph (thanks!), I am appearing to get good
>> results for setup (2), which is what we want. Looking at phase_error.png,
>> we are getting a phase error of about -60 dB, which is very good. And we
>> can see from i_and_q_both_channels.png that the phase offset is about 60
>> degrees (pi/3) (looking at both I and Q). I think this shows that both
>> transmitters are transmitting at the same time. If I applied accurate
>> beamforming weights, then ideally that phase offset would be eliminated
>> (which is what I plan to do). I just want to make sure from you that this
>> behavior makes sense.
>>
>> I believe my next step would be to look into timed commands in UHD and
>> tags in GNU Radio to see how I can now transmit something from these two
>> aligned transmitters to just one receiver, then calculate that power at the
>> receiver, and then send it back to the transmitters for some processing
>> before transmitting again.
>>
>> On Tue, May 3, 2016 at 4:05 PM, Derek Kozel 
>> wrote:
>>
>>> Hello Pavan,
>>>
>>> Your signal strength is much too high. You can see on the plots that the
>>> received signal is greater than 1 (assuming a sinusoid input). Lower the
>>> transmit gain and/or the receive gain until you are no longer clipping. The
>>> ADC is being overloaded so the spikes are entirely to be expected. You have
>>> the 20dB attenuation which should be preventing any damage, but the
>>> N210+SBX is still plenty sensitive enough to clip.
>>>
>>> Test 1, where the receivers are not synchronized, will tell you none of
>>> time, frequency, or phase alignment since the receivers could be in any
>>> state compared to each other and the synchronized transmitter pair.
>>>
>>> Test 2, where the receivers are synchronized with 1PPS and 10 MHz
>>> references from the same octoclock as the transmitters (or another GPSDO of
>>> similar grade) will give you time, frequency, and phase (with SBXs)
>>> information.
>>>
>>> I suggest not using complex to float conversion blocks and looking at
>>> the raw complex values. It should be easy to see time and frequency sink
>>> with the time sink.
>>>
>>> To measure phase alignment you can take the two outputs of your source
>>> block and use a conjugate multiply to view the relative phase offset. I've
>>> attached a flowgraph which I use to prove B210 phase alignment. You should
>>> be able to copy the flowgraph over to your setup pretty simply.
>>>
>>> Cheers,
>>> Derek
>>>
>>> On Tue, May 3, 2016 at 3:51 PM, Pavan Yedavalli 
>>> wrote:
>>>
 Hi Derek,

 I was able to put in another USRP as a receiver, so I have the same
 transmit setup (connected to Octoclock and with MIMO cable to another
 USRP), and the receive setup is now 2 USRPs, not connected by anything, and
 in two different setups:

 1.) Neither receiver is connected to the Octoclock, and instead all of
 the time/sync properties are set to Default and PPS is set to don't sync
 (see received_not_connected_to_octoclock.png). We can see from
 recv_real_parts_no_octo_on_recv.png that they seem to be offset in phase
 slightly, which is what we expect, but the frequencies appear the same. One

Re: [Discuss-gnuradio] GR win64 binaries v1.1 posted

[Achilleas Anastasopoulos]

I had partial success with these binaries:

1) GRC starts with the following warnings which I am not sure if they are
important:

---
setting gnuradio environment

** (python.exe:2060): WARNING **: Trying to register gtype
'GMountMountFlags' as
 enum when in fact it is of type 'GFlags'

** (python.exe:2060): WARNING **: Trying to register gtype
'GDriveStartFlags' as
 enum when in fact it is of type 'GFlags'

** (python.exe:2060): WARNING **: Trying to register gtype
'GSocketMsgFlags' as
enum when in fact it is of type 'GFlags'
gnuradio-companion.py:122: GtkWarning: Could not find the icon
'gnuradio-grc'. T
he 'hicolor' theme
was not found either, perhaps you need to install it.
You can get a copy from:
http://icon-theme.freedesktop.org/releases
  gtk.window_set_default_icon(gtk.IconTheme().load_icon('gnuradio-grc',
256, 0))

<<< Welcome to GNU Radio Companion 3.7.9.2 >>>

Preferences file: C:\Users\anastas/.gnuradio/grc.conf
Block paths:
C:\Users\anastas\.grc_gnuradio (C:\Users\anastas/.grc_gnuradio)
C:\Program Files\GNURadio-3.7\share\gnuradio\grc\blocks (C:\Program
File
s\GNURadio-3.7\bin\..\share\gnuradio\grc\blocks)
---


2) A simple flowgraph with noise, throttle, filter, fft display runs
perfectly with WX.
The following info is displayed:

Generating: 'C:\\Users\\anastas\\Dropbox\\gnuradio_examples\\top_block.py'

Executing: C:\Program Files\GNURadio-3.7\gr-python27\python.exe -u
C:\Users\anas
tas\Dropbox\gnuradio_examples\top_block.py

Using Volk machine: ssse3
fft_impl_fftw: ÿÿ\Users\anastas\AppData\Roaming\.gr_fftw_wisdom: No such
file or
 directory
C:\Program
Files\GNURadio-3.7\lib\site-packages\gnuradio\grc\gui\Dialogs.py:67:
GtkWarning: gtk_text_buffer_emit_insert: assertion 'g_utf8_validate (text,
len,
NULL)' failed
  self.get_buffer().insert(self.get_buffer().get_end_iter(), line)
¶: Invalid argument
gr::pagesize: no info; setting pagesize = 4096
¶: Invalid argument

>>> Done
--


3) However the QT version of the above simple flowgraph does not run; it
returns the error:
--
Executing: C:\Program Files\GNURadio-3.7\gr-python27\python.exe -u
C:\Users\anas
tas\Dropbox\gnuradio_examples\top_block.py

Using Volk machine: ssse3
fft_impl_fftw: ÿÿ\Users\anastas\AppData\Roaming\.gr_fftw_wisdomC:\Program
Files\
GNURadio-3.7\lib\site-packages\gnuradio\grc\gui\Dialogs.py:67: GtkWarning:
gtk_t
ext_buffer_emit_insert: assertion 'g_utf8_validate (text, len, NULL)' failed
  self.get_buffer().insert(self.get_buffer().get_end_iter(), line)
: No such file or directory

>>> Done
-

thanks
Achilleas




On Tue, May 3, 2016 at 5:05 PM, Geof Nieboer  wrote:

> All,
>
> An updated set of windows binaries and build scripts have been posted.
> Quick summary:
> 1- Added gqrx to package
> 2- Patched 2 x issues which would cause the generic version to crash on
> non-AVX systems (one in volk, one in FFTW)
> 3- Added gr-newmod to package
>
> Plus a number of improvements to make the scripts more robust.
>
> Binaries at http://www.gcndevelopment.com/gnuradio/downloads.htm
> Scripts at https://github.com/gnieboer/GNURadio_Windows_Build_Scripts
>
> A couple gqrx known bugs:
> 1- Toolbar icons do not appear (our Qt5 issue)
> 2- Switching a USRP to another modulation will cause a crash (upstream UHD)
> 3- Switching between a RTL-SDR device and a USRP device will cause a crash
> (upstream gqrx)
>
> Cheers,
>
> Geof
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Feedback with Transmitters and Receiver

[Derek Kozel]

Just for clarity. That's a phase error in degrees not dB. :) And yes,
there's expected to be an offset. The correct behaviour is that the phase
offset is stable for a given frequency (assuming no other changes in the
system) and that tuning away and back or restarting should produce the same
phase offset (some combinations of motherboards and daughterboards can
result in a 180 degree ambiguity).

To see the time synchronization you'll need to try sending bursts and look
at the rising/falling edge of the signals to see time alignment. But I
think you can move forward feeling pretty sure that that is working
correctly. When you get timed commands working bursts are a natural thing
to implement so you can verify your alignment then.

Good luck with the next steps.

On Tue, May 3, 2016 at 4:50 PM, Pavan Yedavalli 
wrote:

> Hi Derek,
>
> Thanks for getting back to me. I lowered the Tx gain by about 15 dB on
> each channel, and then now it's looking good. It makes sense that it was
> clipping. Using your flowgraph (thanks!), I am appearing to get good
> results for setup (2), which is what we want. Looking at phase_error.png,
> we are getting a phase error of about -60 dB, which is very good. And we
> can see from i_and_q_both_channels.png that the phase offset is about 60
> degrees (pi/3) (looking at both I and Q). I think this shows that both
> transmitters are transmitting at the same time. If I applied accurate
> beamforming weights, then ideally that phase offset would be eliminated
> (which is what I plan to do). I just want to make sure from you that this
> behavior makes sense.
>
> I believe my next step would be to look into timed commands in UHD and
> tags in GNU Radio to see how I can now transmit something from these two
> aligned transmitters to just one receiver, then calculate that power at the
> receiver, and then send it back to the transmitters for some processing
> before transmitting again.
>
> On Tue, May 3, 2016 at 4:05 PM, Derek Kozel  wrote:
>
>> Hello Pavan,
>>
>> Your signal strength is much too high. You can see on the plots that the
>> received signal is greater than 1 (assuming a sinusoid input). Lower the
>> transmit gain and/or the receive gain until you are no longer clipping. The
>> ADC is being overloaded so the spikes are entirely to be expected. You have
>> the 20dB attenuation which should be preventing any damage, but the
>> N210+SBX is still plenty sensitive enough to clip.
>>
>> Test 1, where the receivers are not synchronized, will tell you none of
>> time, frequency, or phase alignment since the receivers could be in any
>> state compared to each other and the synchronized transmitter pair.
>>
>> Test 2, where the receivers are synchronized with 1PPS and 10 MHz
>> references from the same octoclock as the transmitters (or another GPSDO of
>> similar grade) will give you time, frequency, and phase (with SBXs)
>> information.
>>
>> I suggest not using complex to float conversion blocks and looking at the
>> raw complex values. It should be easy to see time and frequency sink with
>> the time sink.
>>
>> To measure phase alignment you can take the two outputs of your source
>> block and use a conjugate multiply to view the relative phase offset. I've
>> attached a flowgraph which I use to prove B210 phase alignment. You should
>> be able to copy the flowgraph over to your setup pretty simply.
>>
>> Cheers,
>> Derek
>>
>> On Tue, May 3, 2016 at 3:51 PM, Pavan Yedavalli 
>> wrote:
>>
>>> Hi Derek,
>>>
>>> I was able to put in another USRP as a receiver, so I have the same
>>> transmit setup (connected to Octoclock and with MIMO cable to another
>>> USRP), and the receive setup is now 2 USRPs, not connected by anything, and
>>> in two different setups:
>>>
>>> 1.) Neither receiver is connected to the Octoclock, and instead all of
>>> the time/sync properties are set to Default and PPS is set to don't sync
>>> (see received_not_connected_to_octoclock.png). We can see from
>>> recv_real_parts_no_octo_on_recv.png that they seem to be offset in phase
>>> slightly, which is what we expect, but the frequencies appear the same. One
>>> issue I'm seeing is that there are these periodic spikes in the channel 1
>>> curve - is that because it may not be connected perfectly? I'm not sure
>>> where those are coming from.
>>>
>>> 2.) Both receivers are connected to the Octoclock (separately directly
>>> to the Octoclock, not one connected to the other via MIMO cable and only
>>> one connected to Octoclock), and all of the time/sync properties and PPS
>>> are what you had described in a previous e-mail (see
>>> received_connected_to_octoclock.png). Looking at
>>> recvd_real_parts_octo_on_recv.png and recvd_real_parts_octo_on_recv_2.png,
>>> we can see that the frequencies appear to be slightly different (I think?),
>>> and that there is also a spike in the channel 2 capture as well, so I'm not
>>> sure what is happening 

Re: [Discuss-gnuradio] GR win64 binaries v1.1 posted

[Anon Lister]

Nice. Will def check this out.
On May 3, 2016 5:05 PM, "Geof Nieboer"  wrote:

> All,
>
> An updated set of windows binaries and build scripts have been posted.
> Quick summary:
> 1- Added gqrx to package
> 2- Patched 2 x issues which would cause the generic version to crash on
> non-AVX systems (one in volk, one in FFTW)
> 3- Added gr-newmod to package
>
> Plus a number of improvements to make the scripts more robust.
>
> Binaries at http://www.gcndevelopment.com/gnuradio/downloads.htm
> Scripts at https://github.com/gnieboer/GNURadio_Windows_Build_Scripts
>
> A couple gqrx known bugs:
> 1- Toolbar icons do not appear (our Qt5 issue)
> 2- Switching a USRP to another modulation will cause a crash (upstream UHD)
> 3- Switching between a RTL-SDR device and a USRP device will cause a crash
> (upstream gqrx)
>
> Cheers,
>
> Geof
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Introducing the New GNU Radio Website

[Derek Kozel]

"There is still a lot of content work to do as we migrate away from Redmine
(you may notice that many of the links on the website take you to
Redmine-hosted content, at the moment)"

:)

I imagine part of the challenge will be keeping the various sections of the
website which are written wiki style by the community editable.

On Tue, May 3, 2016 at 4:26 PM, Richard Bell 
wrote:

> I like the new style, it feels fresh and modern.
>
> I've noticed that depending on the link you click, you may end up on a
> page in the old style. For example, clicking the development link does
> this. Will the entire website eventually get the makeover?
>
> Rich
>
> On Tue, May 3, 2016 at 1:44 PM, Ben Hilburn  wrote:
>
>> Hi all -
>>
>> I am happy to share that primary development on the user-facing GNU Radio
>> website has been wrapped up! You can check out the new site in action at
>> gnuradio.org.
>>
>> There is still a lot of content work to do as we migrate away from
>> Redmine (you may notice that many of the links on the website take you to
>> Redmine-hosted content, at the moment), but initial development on the site
>> infrastructure itself has wrapped up. There are some items we would still
>> like to get to eventually (like integrating the site Events Calendar
>>  with the Org GCal
>> ),
>> so if you have any ideas for further improvement, feel free to send them my
>> way. Also, if you are into web development and would like to get involved,
>> please let me know!
>>
>> Going forward, community & project News  and
>> Events  will be posted on the website (in
>> addition to the mailing list, as usual), and developers will be sharing
>> articles in the Blog  area of the site. If
>> you have an idea for content that you would like to share with the broader
>> community on the site, just get in touch. And, of course, if you spot any
>> issues, please send me a note.
>>
>> A special thanks to Marcus Mueller, who did a ton of work on most of the
>> images that appear on the site, and to Johnathan Corgan, who manages our
>> server infrastructure in addition to everything else he is doing for the
>> project.
>>
>> Cheers,
>> Ben
>>
>> ___
>> 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] Introducing the New GNU Radio Website

[Marcus D. Leech]

On 05/03/2016 07:26 PM, Richard Bell wrote:

I like the new style, it feels fresh and modern.

I've noticed that depending on the link you click, you may end up on a 
page in the old style. For example, clicking the development link does 
this. Will the entire website eventually get the makeover?


Rich

If so, I hope that it's artisanal, and organic...  :) :)




On Tue, May 3, 2016 at 1:44 PM, Ben Hilburn > wrote:


Hi all -

I am happy to share that primary development on the user-facing
GNU Radio website has been wrapped up! You can check out the new
site in action at gnuradio.org .

There is still a lot of content work to do as we migrate away from
Redmine (you may notice that many of the links on the website take
you to Redmine-hosted content, at the moment), but initial
development on the site infrastructure itself has wrapped up.
There are some items we would still like to get to eventually
(like integrating the site Events Calendar
 with the Org GCal

),
so if you have any ideas for further improvement, feel free to
send them my way. Also, if you are into web development and would
like to get involved, please let me know!

Going forward, community & project News
 and Events
 will be posted on the website (in
addition to the mailing list, as usual), and developers will be
sharing articles in the Blog  area of
the site. If you have an idea for content that you would like to
share with the broader community on the site, just get in touch.
And, of course, if you spot any issues, please send me a note.

A special thanks to Marcus Mueller, who did a ton of work on most
of the images that appear on the site, and to Johnathan Corgan,
who manages our server infrastructure in addition to everything
else he is doing for the project.

Cheers,
Ben

___
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] Introducing the New GNU Radio Website

[Richard Bell]

I like the new style, it feels fresh and modern.

I've noticed that depending on the link you click, you may end up on a page
in the old style. For example, clicking the development link does this.
Will the entire website eventually get the makeover?

Rich

On Tue, May 3, 2016 at 1:44 PM, Ben Hilburn  wrote:

> Hi all -
>
> I am happy to share that primary development on the user-facing GNU Radio
> website has been wrapped up! You can check out the new site in action at
> gnuradio.org.
>
> There is still a lot of content work to do as we migrate away from Redmine
> (you may notice that many of the links on the website take you to
> Redmine-hosted content, at the moment), but initial development on the site
> infrastructure itself has wrapped up. There are some items we would still
> like to get to eventually (like integrating the site Events Calendar
>  with the Org GCal
> ),
> so if you have any ideas for further improvement, feel free to send them my
> way. Also, if you are into web development and would like to get involved,
> please let me know!
>
> Going forward, community & project News  and
> Events  will be posted on the website (in
> addition to the mailing list, as usual), and developers will be sharing
> articles in the Blog  area of the site. If you
> have an idea for content that you would like to share with the broader
> community on the site, just get in touch. And, of course, if you spot any
> issues, please send me a note.
>
> A special thanks to Marcus Mueller, who did a ton of work on most of the
> images that appear on the site, and to Johnathan Corgan, who manages our
> server infrastructure in addition to everything else he is doing for the
> project.
>
> Cheers,
> Ben
>
> ___
> 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] Getting one or more Ds after hours of running a GRC app on Ubuntu

[Marcus D. Leech]

On 05/03/2016 04:25 PM, John Shields wrote:

Thanks Marcus,


I have moved the N200 over to another cable to 
see if the situation improves but I think that the best solution is to 
move the Ubuntu box into the shack rather than move house/shack closer :)

Lazy :) :)




   Slainte,

   John

On 03/05/16 19:12, mle...@ripnet.com wrote:


The native BER of 1000BASE-T is better than 1.0e-11 or so.

Which means you'd expect a bad bit roughly every half-hour at 2msps 
(64Mbit/sec), the bad-bit probabilities get worse as you make the 
cable longer.


On 2016-05-03 12:59, John Shields wrote:


On 03/05/16 15:01, mle...@ripnet.com wrote:


It's possible that we're dealing with a memory leak somewhere.  
Could you watch the memory consumption of simple_ra over time?


Also, could you just run something like uhd_fft with the same 
sample rate for long periods to see if it gets the same 'D' treatment?


On 2016-05-03 04:32, John Shields wrote:

Thanks Marcus,

Have put answers in-line.

   Kind Regards,

   John


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

Ok, Marcus, will do. Overnight (NZ time) I got 1 D with the Atheros. 
I should have said that the N200 was in the shack and the Ubuntu 
system in the house. I have several runs of Ethernet out to the 
shack so will do some experimentation on the different connections. 
Then I will move the Ubuntu system to the shack and see if 
colocation helps. These investigations will take some days but will 
let you know.


 Kind Regards,

  John


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

[Discuss-gnuradio] GR win64 binaries v1.1 posted

[Geof Nieboer]

All,

An updated set of windows binaries and build scripts have been posted.
Quick summary:
1- Added gqrx to package
2- Patched 2 x issues which would cause the generic version to crash on
non-AVX systems (one in volk, one in FFTW)
3- Added gr-newmod to package

Plus a number of improvements to make the scripts more robust.

Binaries at http://www.gcndevelopment.com/gnuradio/downloads.htm
Scripts at https://github.com/gnieboer/GNURadio_Windows_Build_Scripts

A couple gqrx known bugs:
1- Toolbar icons do not appear (our Qt5 issue)
2- Switching a USRP to another modulation will cause a crash (upstream UHD)
3- Switching between a RTL-SDR device and a USRP device will cause a crash
(upstream gqrx)

Cheers,

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

[Discuss-gnuradio] Introducing the New GNU Radio Website

[Ben Hilburn]

Hi all -

I am happy to share that primary development on the user-facing GNU Radio
website has been wrapped up! You can check out the new site in action at
gnuradio.org.

There is still a lot of content work to do as we migrate away from Redmine
(you may notice that many of the links on the website take you to
Redmine-hosted content, at the moment), but initial development on the site
infrastructure itself has wrapped up. There are some items we would still
like to get to eventually (like integrating the site Events Calendar
 with the Org GCal
),
so if you have any ideas for further improvement, feel free to send them my
way. Also, if you are into web development and would like to get involved,
please let me know!

Going forward, community & project News  and
Events  will be posted on the website (in
addition to the mailing list, as usual), and developers will be sharing
articles in the Blog  area of the site. If you
have an idea for content that you would like to share with the broader
community on the site, just get in touch. And, of course, if you spot any
issues, please send me a note.

A special thanks to Marcus Mueller, who did a ton of work on most of the
images that appear on the site, and to Johnathan Corgan, who manages our
server infrastructure in addition to everything else he is doing for the
project.

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

Re: [Discuss-gnuradio] INMARSAT wide signal question

[Henry Barton]

[The answers to both 1) and 2) are yes.]

That's great. Thank you.

 

[Stay tuned.]

What does that mean? Do you have more info?

 

  _  

From: Ian Buckley [mailto:i...@ionconcepts.com] 
Sent: Tuesday, May 03, 2016 4:37 PM
To: Marcus D. Leech
Cc: Henry Barton; Discuss-gnuradio; discuss-gnuradio
Subject: Re: [Discuss-gnuradio] INMARSAT wide signal question

 

Here's a good starting point for you:

http://www.uhf-satcom.com/lband/

 

The answers to both 1) and 2) are yes. Stay tuned.

 

 

On Tue, May 3, 2016 at 12:56 PM,  wrote:

I assume you're asking "Is there a big blue DECODE ALL THE INMARSAT THINGS"
knob in Gnu Radio.  The answer to that would be a resounding NO.

If the question is, instead:

   (1) Is the Gnu Radio development environment suitable for *developing*
signal-processing chains to decode INMARSAT

   (2) Has anyone developed INMARSAT decoding/demod blocks for Gnu Radio.

For (1), the answer is yes.  For (2) the answer is--check with google.  The
phrase "inmarsat gnuradio" doesn't return a lot, but that doesn't mean
somewhere out there someone hasn't developed some capability.

 

 

 

On 2016-05-03 15:45, Henry Barton wrote:

http://rtlsdrblog.rtlsdrblog.netdna-cdn.com/wp-content/uploads/2015/10/sdrpl
ay_lband-1024x573.png

I didn't see the widest signal (bright yellow) from this picture on
sigidwiki.com. Does anyone know what it is? If so, can it be decoded by
GNUradio? Thanks.

 

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


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

 

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

Re: [Discuss-gnuradio] INMARSAT wide signal question

[Ian Buckley]

Here's a good starting point for you:
http://www.uhf-satcom.com/lband/

The answers to both 1) and 2) are yes. Stay tuned.


On Tue, May 3, 2016 at 12:56 PM,  wrote:

> I assume you're asking "Is there a big blue DECODE ALL THE INMARSAT
> THINGS" knob in Gnu Radio.  The answer to that would be a resounding NO.
>
> If the question is, instead:
>
>(1) Is the Gnu Radio development environment suitable for *developing*
> signal-processing chains to decode INMARSAT
>
>(2) Has anyone developed INMARSAT decoding/demod blocks for Gnu Radio.
>
> For (1), the answer is yes.  For (2) the answer is--check with google.
> The phrase "inmarsat gnuradio" doesn't return a lot, but that doesn't mean
> somewhere out there someone hasn't developed some capability.
>
>
>
>
>
>
> On 2016-05-03 15:45, Henry Barton wrote:
>
>
> http://rtlsdrblog.rtlsdrblog.netdna-cdn.com/wp-content/uploads/2015/10/sdrplay_lband-1024x573.png
>
> I didn’t see the widest signal (bright yellow) from this picture on
> sigidwiki.com. Does anyone know what it is? If so, can it be decoded by
> GNUradio? Thanks.
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Getting one or more Ds after hours of running a GRC app on Ubuntu

[John Shields]

Thanks Marcus,
The cable is cat-5e and the length is 52 meters 
(give or take).


Based on your calculations, it seems that I am 
setting myself for high likelihood of a dropped packet if I were to run 
for 4 or 5 days continuously.


I have moved the N200 over to another cable to 
see if the situation improves but I think that the best solution is to 
move the Ubuntu box into the shack rather than move house/shack closer :)


   Slainte,

   John

On 03/05/16 19:12, mle...@ripnet.com wrote:


The native BER of 1000BASE-T is better than 1.0e-11 or so.

Which means you'd expect a bad bit roughly every half-hour at 2msps 
(64Mbit/sec), the bad-bit probabilities get worse as you make the 
cable longer.


On 2016-05-03 12:59, John Shields wrote:


On 03/05/16 15:01, mle...@ripnet.com wrote:


It's possible that we're dealing with a memory leak somewhere.  
Could you watch the memory consumption of simple_ra over time?


Also, could you just run something like uhd_fft with the same sample 
rate for long periods to see if it gets the same 'D' treatment?


On 2016-05-03 04:32, John Shields wrote:

Thanks Marcus,

Have put answers in-line.

   Kind Regards,

   John


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

Ok, Marcus, will do. Overnight (NZ time) I got 1 D with the Atheros. 
I should have said that the N200 was in the shack and the Ubuntu 
system in the house. I have several runs of Ethernet out to the shack 
so will do some experimentation on the different connections. Then I 
will move the Ubuntu system to the shack and see if colocation helps. 
These investigations will take some days but will let you know.


 Kind Regards,

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

Re: [Discuss-gnuradio] INMARSAT wide signal question

[mleech]

I assume you're asking "Is there a big blue DECODE ALL THE INMARSAT
THINGS" knob in Gnu Radio.  The answer to that would be a resounding NO.


If the question is, instead: 

   (1) Is the Gnu Radio development environment suitable for
*developing* signal-processing chains to decode INMARSAT 

   (2) Has anyone developed INMARSAT decoding/demod blocks for Gnu
Radio. 

For (1), the answer is yes.  For (2) the answer is--check with google. 
The phrase "inmarsat gnuradio" doesn't return a lot, but that doesn't
mean somewhere out there someone hasn't developed some capability. 

On 2016-05-03 15:45, Henry Barton wrote:

> http://rtlsdrblog.rtlsdrblog.netdna-cdn.com/wp-content/uploads/2015/10/sdrplay_lband-1024x573.png
>  
> 
> I didn't see the widest signal (bright yellow) from this picture on 
> sigidwiki.com. Does anyone know what it is? If so, can it be decoded by 
> GNUradio? 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

Re: [Discuss-gnuradio] [USRP-users] minimum PPS voltage for N200

[mleech]

What you're going to need to do is provide the *simplest* flow-graph
that demonstrates the issue, rather than requiring the community to
debug your entire end-to-end setup. 

Also a diagram of your setup showing the RF and 1PPS and 10MHz paths. 

On 2016-05-03 15:39, khalid.el-darymli wrote:

> Thanks again Marcus. I really appreciate your help.
> 
> I am setting Ref Clock / PPS to external, etc. I get the syncing to work 
> properly around a year ago. Since then, we made various changes and I think 
> one or more change may be causing the issue. Among the changes are: buy N200 
> units with a new revision (could that be a problem when syncing?), upgrading 
> GNU Radio / UHD, enabling Rs 232  echoing in the GPSDO, etc.
> 
> Similar to my last year tests (I entirely unplugged the RS 232 cable), and 
> now it is not detected as an Internal GPSDO. However, I am still having issue 
> syncing the two motherboards.
> 
> Attached are two figures for the phase drift between Rx1 vs. Rx2, and Rx1 vs. 
> Rx3. This was generated through splitting the Tx and looping it back to the 
> Rx's. Signal processing was done properly (for dechirping, downsamplng, etc). 
> My application is LFMCW radar, so each 490 samples in the attachment 
> represents one sweep, and sweeping was done continuously. 
> 
> angle(Rx1./Rx2) looks great. As to angle(Rx1./Rx3), I would expect a linear 
> phase offset between different motherboards. However, as .shown in the 
> attachment, Rx1 vs. Rx3 has weird phase spikes. I think this shows that, for 
> some reason, the Tx is not properly synced with the second motherboard. Any 
> ideas on what might be causing this issue?
> 
> I am using Starttech Ethernet Adapter (ST1000SPEX4). The problem I have with 
> this card is that it won't turn AUTONEG off, it is always on. Could this 
> cause the problem? 
> 
> I tried this on two different Ubuntu machines, with similar results as shown 
> in the attachment. 
> 
> For the first machine, 
> 
> UBUNTU 14.04 LTS
> linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.008.002-80-ge28d7844
> 
> For the second machine,
> UBUNTU 14.04 LTS
> linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.008.000-46-g5b706d29
> 
> I'll highly appreciate any suggestions to solve this problem.
> 
> Thank you.
> 
> Best wishes, 
> khalid
> 
> On Tue, May 3, 2016 at 1:45 PM,  wrote:
> 
> The only way the USRP knows that there's a GPSDO present is if the serial 
> data from the GSPDO is validated.  If it doesn't see that data, it concludes 
> that there's no (internal) GPSDO present. 
> 
> There is no concept of "external GPSDO" -- only that *something* is providing 
> 10MHz and 1PPS externally.  The N2xx has no idea what that might be. 
> 
> You should set both 1PPS and 10MHz clock to "external" in your flow-graph. 
> The only time "GPSDO" is used is when you have a properly-installed 
> internally-mounted, GPSDO unit.
> 
> On 2016-05-03 12:02, khalid.el-darymli wrote: 
> 
> Thanks Marcus. 
> 
> OK, I'm communicating with the external Firefly-1A GPSDO unit using an RS 232 
> cable. I am able to do so after enabling echoing on RS 232 from the GPSDO. 
> Would that be a problem? Do I need to completely disable the RS 232 echoing, 
> even while the RS 232 cable is completely unplugged?
> 
> When the RS 232 cable is plugged-in, N200 DETECTs it as an INTERNAL GPSDO. 
> When I completely unplug the RS 232 cable on both ends, I am not getting any 
> messages for detecting neither external nor internal GPSDO. It only shows the 
> following in the terminal for both N200 devices,
> 
> (1) catch time transition at pps edge (2) set time next pps (synchronously).
> 
> khalid
> 
> On Tue, May 3, 2016 at 12:20 PM,  wrote:
> 
> The PPS input is conditioned with a: 
> 
> http://www.ti.com/product/SN74AUP1T57/description 
> 
> Looks to me like it should work just fine.
> 
> On 2016-05-03 10:23, khalid.el-darymli via USRP-users wrote: 
> 
> Hi,
> 
> I'll appreciate any help on the following. According to the link below [1], 
> the PPS voltage for N200 should be in the range [3.3, 5] V p-p.
> [1] http://files.ettus.com/manual/page_usrp2.html#usrp2_hw_leds
> 
> I am getting a PPS signal through fan-outs from an external Firefly-1A GPSDO. 
> I measured the output PPS voltage using a scope, and it is 2.52 V P-P 
> (terminated with 50 ohms).
> 
> Would this relatively low PPS voltage work for N200?  I am having a problem 
> syncing two N200 units (2 LFRX/ 1 LFTX ), and I am not sure if this would be 
> the cause?
> 
> Thank you.
> 
> Best wishes, 
> Khalid
> 
> ___
> USRP-users mailing list
> usrp-us...@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] INMARSAT wide signal question

[Henry Barton]

http://rtlsdrblog.rtlsdrblog.netdna-cdn.com/wp-content/uploads/2015/10/sdrpl
ay_lband-1024x573.png

I didn't see the widest signal (bright yellow) from this picture on
sigidwiki.com. Does anyone know what it is? If so, can it be decoded by
GNUradio? Thanks.

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

Re: [Discuss-gnuradio] [USRP-users] minimum PPS voltage for N200

[khalid.el-darymli]

Thanks again Marcus. I really appreciate your help.

I am setting Ref Clock / PPS to external, etc. I get the syncing to work
properly around a year ago. Since then, we made various changes and I think
one or more change may be causing the issue. Among the changes are: buy
N200 units with a new revision (could that be a problem when syncing?),
upgrading GNU Radio / UHD, enabling Rs 232  echoing in the GPSDO, etc.

Similar to my last year tests (I entirely unplugged the RS 232 cable), and
now it is not detected as an Internal GPSDO. However, I am still having
issue syncing the two motherboards.

Attached are two figures for the phase drift between Rx1 vs. Rx2, and Rx1
vs. Rx3. This was generated through splitting the Tx and looping it back to
the Rx's. Signal processing was done properly (for dechirping, downsamplng,
etc). My application is LFMCW radar, so each 490 samples in the attachment
represents one sweep, and sweeping was done continuously.

angle(Rx1./Rx2) looks great. As to angle(Rx1./Rx3), I would expect a linear
phase offset between different motherboards. However, as .shown in the
attachment, Rx1 vs. Rx3 has weird phase spikes. I think this shows that,
for some reason, the Tx is not properly synced with the second motherboard.
Any ideas on what might be causing this issue?

I am using Starttech Ethernet Adapter (ST1000SPEX4). The problem I have
with this card is that it won't turn AUTONEG off, it is always on. Could
this cause the problem?

I tried this on two different Ubuntu machines, with similar results as
shown in the attachment.

For the first machine,

UBUNTU 14.04 LTS
linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.008.002-80-ge28d7844

For the second machine,
UBUNTU 14.04 LTS
linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.008.000-46-g5b706d29


I'll highly appreciate any suggestions to solve this problem.

Thank you.

Best wishes,
khalid







On Tue, May 3, 2016 at 1:45 PM,  wrote:

> The only way the USRP knows that there's a GPSDO present is if the serial
> data from the GSPDO is validated.  If it doesn't see that data, it
> concludes that there's no (internal) GPSDO present.
>
> There is no concept of "external GPSDO" -- only that *something* is
> providing 10MHz and 1PPS externally.  The N2xx has no idea what that might
> be.
>
> You should set both 1PPS and 10MHz clock to "external" in your flow-graph.
> The only time "GPSDO" is used is when you have a properly-installed
> internally-mounted, GPSDO unit.
>
>
>
>
>
>
> On 2016-05-03 12:02, khalid.el-darymli wrote:
>
> Thanks Marcus.
>
> OK, I'm communicating with the external Firefly-1A GPSDO unit using an RS
> 232 cable. I am able to do so after enabling echoing on RS 232 from the
> GPSDO. Would that be a problem? Do I need to completely disable the RS 232
> echoing, even while the RS 232 cable is completely unplugged?
>
> When the RS 232 cable is plugged-in, N200 DETECTs it as an INTERNAL GPSDO.
> When I completely unplug the RS 232 cable on both ends, I am not getting
> any messages for detecting neither external nor internal GPSDO. It only
> shows the following in the terminal for both N200 devices,
>
> (1) catch time transition at pps edge
> (2) set time next pps (synchronously).
>
> khalid
>
>
>
>
> On Tue, May 3, 2016 at 12:20 PM,  wrote:
>
>> The PPS input is conditioned with a:
>>
>> http://www.ti.com/product/SN74AUP1T57/description
>>
>> Looks to me like it should work just fine.
>>
>>
>>
>>
>>
>>
>> On 2016-05-03 10:23, khalid.el-darymli via USRP-users wrote:
>>
>> Hi,
>>
>> I'll appreciate any help on the following. According to the link below
>> [1], the PPS voltage for N200 should be in the range *[3.3, 5]* V p-p.
>> [1] http://files.ettus.com/manual/page_usrp2.html#usrp2_hw_leds
>>
>> I am getting a PPS signal through fan-outs from an external Firefly-1A
>> GPSDO. I measured the output PPS voltage using a scope, and it is *2.52
>> V p-p* (terminated with 50 ohms).
>>
>> Would this relatively low PPS voltage work for N200?  I am having a
>> problem syncing two N200 units (2 LFRX/ 1 LFTX ), and I am not sure if this
>> would be the cause?
>>
>>
>> Thank you.
>>
>> Best wishes,
>> Khalid
>>
>> ___
>> USRP-users mailing list
>> usrp-us...@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Corrupted SDK installer

[Sean Nowlan]

Thanks, this is a false alarm. It must have been an issue with downloading
on Chrome for Windows on the machine I was using. I just verified that the
file's SHA256 checksum matches the expected checksum on a Ubuntu system:

$ wget
http://gnuradio.org/data/sdk/armv7hf/20160420/oecore-x86_64-armv7ahf-vfp-neon-toolchain-nodistro.0.sh
[...]
$ sha256sum oecore-x86_64-armv7ahf-vfp-neon-toolchain-nodistro.0.sh
0c50d6d44db9cb030800cfffe0ff2a4d7022a2c1c5e0b9c9f2dc155435c5657a
oecore-x86_64-armv7ahf-vfp-neon-toolchain-nodistro.0.sh

Sean

On Tue, May 3, 2016 at 1:22 PM, Tom Rondeau  wrote:

> On Tue, May 3, 2016 at 10:51 AM, Sean Nowlan  wrote:
>
>> I believe the non-GUI embedded SDK installer from 20-APR-2016 posted here
>> [1] is corrupted, or at least the download keeps failing in the same way.
>>
>> The SHA256 checksums do not match:
>> Posted
>> [2]: 0c50d6d44db9cb030800cfffe0ff2a4d7022a2c1c5e0b9c9f2dc155435c5657a
>> Actual: d99df0557e8766d02036f583cca6fb95d066d7e7c7614f271c0b84efe711e81b
>>
>> This error occurs when the script is self-extracting: [3]. Note that the
>> GUI version downloads properly and has a correct SHA256 checksum.
>>
>> Thanks,
>> Sean
>>
>> [1]
>> http://gnuradio.org/data/sdk/armv7hf/20160420/oecore-x86_64-armv7ahf-vfp-neon-toolchain-nodistro.0.sh
>> [2] http://gnuradio.org/data/sdk/
>> [3] https://gist.github.com/nowls/f25cbfd314c47e9ecabd2a33d3e3399c
>>
>
>
> Sean,
>
> I'm not getting the same results. I checked both the local file on the
> server and downloaded it myself onto another computer, and all SHA256 sums
> match what's in that table for me.
>
> Tom
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Getting one or more Ds after hours of running a GRC app on Ubuntu

[mleech]

The native BER of 1000BASE-T is better than 1.0e-11 or so. 

Which means you'd expect a bad bit roughly every half-hour at 2msps
(64Mbit/sec), the bad-bit probabilities get worse as you make the cable
longer. 

On 2016-05-03 12:59, John Shields wrote:

> On 03/05/16 15:01, mle...@ripnet.com wrote: 
> 
> It's possible that we're dealing with a memory leak somewhere.  Could you 
> watch the memory consumption of simple_ra over time? 
> 
> Also, could you just run something like uhd_fft with the same sample rate for 
> long periods to see if it gets the same 'D' treatment? 
> 
> On 2016-05-03 04:32, John Shields wrote: 
> Thanks Marcus,
> 
> Have put answers in-line.
> 
> Kind Regards,
> 
> John
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 Ok, Marcus, will do. Overnight (NZ time) I got 1 D with the Atheros. I
should have said that the N200 was in the shack and the Ubuntu system in
the house. I have several runs of Ethernet out to the shack so will do
some experimentation on the different connections. Then I will move the
Ubuntu system to the shack and see if colocation helps. These
investigations will take some days but will let you know.

 Kind Regards,

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

[Discuss-gnuradio] PyBOMBS Update

[Martin Braun]

Everyone,

a couple of notes on PyBOMBS: First, GSoC participant Ravi Sharan will
be part of PyBOMBS development over the next weeks (see his announcement
and blog). Expect some cool features coming! If you want to see what
else we've planned, check out the issue tracker on github.

But, right now, there's a couple of new things I'd like to talk about.
There's been a lot of merges into PyBOMBS, and I'll be tagging a 2.1.0
release pretty soon. Since the last release, we've had some cool new
features:

- Macports and pacman support (we're still working on the recipes though)
- pybombs recipes allows updating all remote recipe repos and listing them
- Some recipe features: Satisfiers can be set to 'True' to skip them
(this way, we can keep alsa as a dependency for GNU Radio, but skip it
on Macs), 'make' can be run interactively (e.g. for the niusrprio
installer).
- Prefixes can be set up through recipes (more on that later)

Also, there's a ton of bugfixes. Probably, there were also new bugs, but
we're getting a lot of testing (thanks to everyone for this!) and as
such I think we're doing fairly well on the bug front. Still, given the
large amount of changes, I would like to give the codebase some time to
settle before making a release (but not too much, so Ravi's stuff can go
onto the next release).

*Prefix Recipes*:

Personally, I think this is a really cool feature, and it's something
that exists in different forms for other build tools, especially in the
embedded world. In a nutshell, it's an instruction to set up a full
prefix, including all config settings and packages.

There's already an example in gr-recipes. If you run the following command:

$ pybombs prefix init /path/to/prefix -R gnuradio-default

it will create a new prefix, then configure it and then install
gnuradio, gr-osmosdr and all dependencies in there. System-level
dependencies (such as Boost, CMake etc.) are still installed in the
system with this particular recipe, but you can write other recipes to
avoid that.

If you want to try the command above, you will need to update both the
PyBOMBS code *and* the recipes:

$ [sudo] pip install [--upgrade] git+https://github.com/gnuradio/pybombs.git
$ pybombs recipes update

We'll be providing more prefix-recipes coming soon.

Cheers,
Martin


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

Re: [Discuss-gnuradio] Getting one or more Ds after hours of running a GRC app on Ubuntu

[mleech]

This has me thinking that this is a PHY-layer issue. 

How long are your Ethernet runs, and are you using Cat5e cabling? 

On 2016-05-03 12:59, John Shields wrote:

> On 03/05/16 15:01, mle...@ripnet.com wrote: 
> 
> It's possible that we're dealing with a memory leak somewhere.  Could you 
> watch the memory consumption of simple_ra over time? 
> 
> Also, could you just run something like uhd_fft with the same sample rate for 
> long periods to see if it gets the same 'D' treatment? 
> 
> On 2016-05-03 04:32, John Shields wrote: 
> Thanks Marcus,
> 
> Have put answers in-line.
> 
> Kind Regards,
> 
> John
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 Ok, Marcus, will do. Overnight (NZ time) I got 1 D with the Atheros. I
should have said that the N200 was in the shack and the Ubuntu system in
the house. I have several runs of Ethernet out to the shack so will do
some experimentation on the different connections. Then I will move the
Ubuntu system to the shack and see if colocation helps. These
investigations will take some days but will let you know.

 Kind Regards,

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

Re: [Discuss-gnuradio] ORC support on armhf w/ embedded SDK

[Tom Rondeau]

On Tue, May 3, 2016 at 11:53 AM, Sean Nowlan  wrote:

> Sorry, email confusion with IEEE email forwarding. Resending to hit
> discuss-gnuradio list.
>
> Ok, thanks. FYI, it looks like ORC 0.4.23 is being used in OpenEmbedded
> Jethro. This version incorporated the bugfix, so it could theoretically be
> enabled in meta-sdr's gnuradio build.
>


ORC is still left out of the VOLK/GNU Radio builds. Frankly, I don't trust
ORC both for bugs but more importantly for how long it took to get this bug
addressed. I don't find that it provides enough benefits to us to worry
about making it work.

Tom




> On Tue, May 3, 2016 at 11:51 AM, Sean Nowlan  wrote:
>
>> Ok, thanks. FYI, it looks like ORC 0.4.23 is being used in OpenEmbedded
>> Jethro. This version incorporated the bugfix, so it could theoretically be
>> enabled in meta-sdr's gnuradio build.
>>
>> Sean
>>
>> On Tue, May 3, 2016 at 11:39 AM, West, Nathan <
>> n...@ostatemail.okstate.edu> wrote:
>>
>>> ORC is still in VOLK, but it doesn't give you much.
>>>
>>> On Tue, May 3, 2016 at 11:32 AM, Philip Balister 
>>> wrote:
>>>
 On 05/03/2016 10:47 AM, Sean Nowlan wrote:
 > According to the wiki [1], ORC support was disabled on armhf due to a
 bug,
 > which has apparently since been resolved [2]. Was ORC support added
 back
 > for armhf in the most recent SDK from 20-APR-2016 [3]? I.e., is the
 wiki
 > page just out of date?
 >
 > Thanks,
 > Sean
 >
 > [1] http://gnuradio.org/redmine/projects/gnuradio/wiki/Embedded
 > [2] https://bugzilla.gnome.org/show_bug.cgi?id=727464
 > [3] http://gnuradio.org/data/sdk/

 I feel like we've replaced all the places we used orc, so we
 (uhd/gnuradio/volk) are not really using it anymore.

 It tends to show up in images, just that it may not be used by gnuradio
 and friends.

 Philip

 >
 >
 >
 > ___
 > 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] Corrupted SDK installer

[Tom Rondeau]

On Tue, May 3, 2016 at 10:51 AM, Sean Nowlan  wrote:

> I believe the non-GUI embedded SDK installer from 20-APR-2016 posted here
> [1] is corrupted, or at least the download keeps failing in the same way.
>
> The SHA256 checksums do not match:
> Posted
> [2]: 0c50d6d44db9cb030800cfffe0ff2a4d7022a2c1c5e0b9c9f2dc155435c5657a
> Actual: d99df0557e8766d02036f583cca6fb95d066d7e7c7614f271c0b84efe711e81b
>
> This error occurs when the script is self-extracting: [3]. Note that the
> GUI version downloads properly and has a correct SHA256 checksum.
>
> Thanks,
> Sean
>
> [1]
> http://gnuradio.org/data/sdk/armv7hf/20160420/oecore-x86_64-armv7ahf-vfp-neon-toolchain-nodistro.0.sh
> [2] http://gnuradio.org/data/sdk/
> [3] https://gist.github.com/nowls/f25cbfd314c47e9ecabd2a33d3e3399c
>


Sean,

I'm not getting the same results. I checked both the local file on the
server and downloaded it myself onto another computer, and all SHA256 sums
match what's in that table for me.

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

Re: [Discuss-gnuradio] Pybomb installation error

[Martin Braun]

You may have a broken pip. Does 'pip list' work for you on the command line?

M

On 05/02/2016 08:50 PM, Shahnaz Shirazi wrote:
> Just an update.
> 
> I found the Pybomb source cod got updated to try it one more time
> All step went through without error except the installation.
> I got bellow error after running last command to install the Gnu radio:
> 
> 
> PyBombs.Packager.pip - ERROR - Command '['pip', 'list']' returned
> non-zero exit status 2PyBombs.Packager.pip - ERROR - Could not run pip
> list. Hm.PyBombs.Packager.pip - DEBUG - Loading pip install cache.
> 
> my Pymobmbs version is 2.0.1
> pip 1.5.4 from /usr/lib/python2.7/dist-packages (python 2.7)
> 
> Ununtu 14.04.4-desktop-
> 
> look forward for an update.
> If anyone got it to work recently I would appreciate your feedback.
> 
> 
> On Sat, Apr 23, 2016 at 4:50 PM, Shahnaz Shirazi  > wrote:
> 
> Hi Nathan,
> 
> After trying the new Pybomb cod I'm not able to initialize the prefix.
> I think some dependency is broken in new pybomb source file.
> I get below error after installing pybombs
> 
>  
> Installing pybombs script to /usr/local/bin
>  *Could not find .egg-info directory in install record for
> PyBOMBS==2.0.1 from git+https://github.com/gnuradio/pybombs.git in
> /usr/local/lib/python2.7/dist-packages*
> Successfully installed setuptools requests PyBOMBS
> Cleaning up...
> 
> after trying to use any pybomb command I'm getting an error.
> here is after trying to make a prefix:
> 
> shahnaz@ubuntu:~$ pybombs prefix init /home/shahnaz/lab -a mylab
> Traceback (most recent call last):
>   File "/usr/local/bin/pybombs", line 9, in 
> load_entry_point('PyBOMBS==2.0.1', 'console_scripts', 'pybombs')()
>   File "/usr/local/lib/python2.7/dist-packages/pybombs/main.py",
> line 30, in main
> return dispatch() or 0
>   File
> "/usr/local/lib/python2.7/dist-packages/pybombs/commands/base.py",
> line 141, in dispatch
> return get_cmd_dict(cmd_list)[args.command](cmd=args.command,
> args=args).run()
>   File
> "/usr/local/lib/python2.7/dist-packages/pybombs/commands/prefix.py",
> line 102, in run
> return
> self.prefix_cmd_name_list[self.args.prefix_command]['run'](self)
>   File
> "/usr/local/lib/python2.7/dist-packages/pybombs/commands/prefix.py",
> line 150, in _run_init
> if op.exists(op.join(path, self.prefix.prefix_conf_dir)):
> *AttributeError: 'NoneType' object has no attribute 'prefix_conf_dir'
> *
> *
> *
> I've deleted and reinstalled my virtual machine multiple times to
> make sure it's new and nothing broken before running the cod.
> 
> Thanks,
> Shahnaz
> *
> *
> 
> On Thu, Apr 21, 2016 at 8:53 AM, West, Nathan
> >
> wrote:
> 
> This was a bug that's been fixed recently.
> 
> https://github.com/gnuradio/pybombs/commit/38ed9d169ed67ef090e6015b07c4918f7c112209
> 
> On Thu, Apr 21, 2016 at 11:23 AM, Jason Matusiak
>  > wrote:
> 
> > $ pybombs [-p myprefix] install gnuradio gr-osmosdr -v
> 
> I ran it, but it thinks that -v is a recipe and it errors
> out there.  If instead I run $ pybombs -v [-p myprefix] -v
> install gnuradio gr-osmosdr, i get:
> 
> PyBombs.Packager.source - DEBUG - Configuring recipe uhd
> PyBombs.Packager.source - DEBUG - Using vars -
> {'config_opt': '', 'builddir':
> '/home/jmat/gnuradio/src/uhd/build'}
> PyBombs.Packager.source - DEBUG - In cwd -
> /home/jmat/gnuradio/src/uhd/build
> PyBombs._process_thread() - DEBUG - Executing command `CC=
> CXX= cmake .. -DCMAKE_BUILD_TYPE=RelWithDebInfo
> -DCMAKE_INSTALL_PREFIX=/home/jmat/gnuradio  -Wno-dev'
> CMake Error: The source directory
> "/home/jmat/gnuradio/src/uhd" does not appear to contain
> CMakeLists.txt.
> Specify --help for usage, or press the help button on the
> CMake GUI.
> PyBombs.monitor_process() - DEBUG - Thread signaled
> termination or returned
> PyBombs.monitor_process() - DEBUG - Return value: 1
> PyBombs.Packager.source - ERROR - Problem occurred while
> building package uhd:
> Process returned value: 1
> PyBombs.install - ERROR - Error installing package uhd.
> Aborting.
> jmatusiak@wk-jmatusiak-02:~/.pybombs/recipes/gr-recipes$
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org 

Re: [Discuss-gnuradio] Getting one or more Ds after hours of running a GRC app on Ubuntu

[John Shields]

On 03/05/16 15:01, mle...@ripnet.com wrote:


It's possible that we're dealing with a memory leak somewhere. Could 
you watch the memory consumption of simple_ra over time?


Also, could you just run something like uhd_fft with the same sample 
rate for long periods to see if it gets the same 'D' treatment?


On 2016-05-03 04:32, John Shields wrote:


Thanks Marcus,

Have put answers in-line.

   Kind Regards,

   John


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org 
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Ok, Marcus, will do. Overnight (NZ time) I got 1 D with the Atheros. I 
should have said that the N200 was in the shack and the Ubuntu system in 
the house. I have several runs of Ethernet out to the shack so will do 
some experimentation on the different connections. Then I will move the 
Ubuntu system to the shack and see if colocation helps. These 
investigations will take some days but will let you know.


 Kind Regards,

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

Re: [Discuss-gnuradio] [USRP-users] minimum PPS voltage for N200

[Marcus Müller]

Dear Khalid,

the RS232 connection, as you've noticed, is necessary for detection.
Without being detected, the GPSDO can still supply a PPS (and 10 MHz
clock) over the coax connectors – however, I'm not even sure they will
discipline those correctly when not initialized via RS232 by UHD.

Why would you want to unplug RS232?

Best regards,
Marcus

On 03.05.2016 18:02, khalid.el-darymli wrote:
> Thanks Marcus.
>
> OK, I'm communicating with the external Firefly-1A GPSDO unit using an
> RS 232 cable. I am able to do so after enabling echoing on RS 232 from
> the GPSDO. Would that be a problem? Do I need to completely disable
> the RS 232 echoing, even while the RS 232 cable is completely unplugged?
>
> When the RS 232 cable is plugged-in, N200 DETECTs it as an INTERNAL
> GPSDO. When I completely unplug the RS 232 cable on both ends, I am
> not getting any messages for detecting neither external nor internal
> GPSDO. It only shows the following in the terminal for both N200 devices,
>
> (1) catch time transition at pps edge
> (2) set time next pps (synchronously).
>
> khalid
>
>
>
>
> On Tue, May 3, 2016 at 12:20 PM,  > wrote:
>
> The PPS input is conditioned with a:
>
> http://www.ti.com/product/SN74AUP1T57/description
>
> Looks to me like it should work just fine.
>
>  
>
>  
>
>  
>
> On 2016-05-03 10:23, khalid.el-darymli via USRP-users wrote:
>
>> Hi,
>>
>> I'll appreciate any help on the following. According to the link
>> below [1], the PPS voltage for N200 should be in the range *[3.3,
>> 5]* V p-p.
>> [1] http://files.ettus.com/manual/page_usrp2.html#usrp2_hw_leds
>>
>> I am getting a PPS signal through fan-outs from an external
>> Firefly-1A GPSDO. I measured the output PPS voltage using a
>> scope, and it is *2.52 V p-p* (terminated with 50 ohms).
>>
>> Would this relatively low PPS voltage work for N200?  I am having
>> a problem syncing two N200 units (2 LFRX/ 1 LFTX ), and I am not
>> sure if this would be the cause?
>>
>>  
>> Thank you.
>>
>> Best wishes,
>> Khalid
>>
>>
>> ___
>> USRP-users mailing list
>> usrp-us...@lists.ettus.com 
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

Re: [Discuss-gnuradio] [USRP-users] minimum PPS voltage for N200

[mleech]

The only way the USRP knows that there's a GPSDO present is if the
serial data from the GSPDO is validated.  If it doesn't see that data,
it concludes that there's no (internal) GPSDO present. 

There is no concept of "external GPSDO" -- only that *something* is
providing 10MHz and 1PPS externally.  The N2xx has no idea what that
might be. 

You should set both 1PPS and 10MHz clock to "external" in your
flow-graph. The only time "GPSDO" is used is when you have a
properly-installed internally-mounted, GPSDO unit. 

On 2016-05-03 12:02, khalid.el-darymli wrote:

> Thanks Marcus. 
> 
> OK, I'm communicating with the external Firefly-1A GPSDO unit using an RS 232 
> cable. I am able to do so after enabling echoing on RS 232 from the GPSDO. 
> Would that be a problem? Do I need to completely disable the RS 232 echoing, 
> even while the RS 232 cable is completely unplugged?
> 
> When the RS 232 cable is plugged-in, N200 DETECTs it as an INTERNAL GPSDO. 
> When I completely unplug the RS 232 cable on both ends, I am not getting any 
> messages for detecting neither external nor internal GPSDO. It only shows the 
> following in the terminal for both N200 devices,
> 
> (1) catch time transition at pps edge (2) set time next pps (synchronously).
> 
> khalid
> 
> On Tue, May 3, 2016 at 12:20 PM,  wrote:
> 
> The PPS input is conditioned with a: 
> 
> http://www.ti.com/product/SN74AUP1T57/description 
> 
> Looks to me like it should work just fine.
> 
> On 2016-05-03 10:23, khalid.el-darymli via USRP-users wrote: 
> 
> Hi,
> 
> I'll appreciate any help on the following. According to the link below [1], 
> the PPS voltage for N200 should be in the range [3.3, 5] V p-p.
> [1] http://files.ettus.com/manual/page_usrp2.html#usrp2_hw_leds
> 
> I am getting a PPS signal through fan-outs from an external Firefly-1A GPSDO. 
> I measured the output PPS voltage using a scope, and it is 2.52 V P-P 
> (terminated with 50 ohms).
> 
> Would this relatively low PPS voltage work for N200?  I am having a problem 
> syncing two N200 units (2 LFRX/ 1 LFTX ), and I am not sure if this would be 
> the cause?
> 
> Thank you.
> 
> Best wishes, 
> Khalid
> 
> ___
> USRP-users mailing list
> usrp-us...@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How to test and change SNR in GNURadio by B210

[Marcus Müller]

Hi Yan,

the output buffer size has nothing to do with this. The FFT will give
you a 512-element vector of complex numbers. You can for example use the
matrix multiplication block to select the right elements from those vectors.

However:
Really, go for the newer blocks I described in the bottom part of my
email. You can easily specify which subcarriers are used with that.

I'm going to stop responding to your plain "how do I calculate SNR?"
questions. The point of the ~1300 words I wrote in my last emails was
that you need to be mathematically aware of what you're doing. I'm not
aware of what you're doing, and frankly, I've spent enough time pointing
out things you should look into.

Best regards,
Marcus

On 03.05.2016 17:40, Yan Huang wrote:
>
> Hi Marcus,
>
>  
>
> Thanks a lot, following your suggestion:
>
> · I add a 512-FFT on the receiver side, but how can I only
> pick the first 200 subcarriers? I set the max output buffer of FFT as
> 200, but I don’t think it works.  How can I deal with it?
>
> · After FFT in receiver side, I connect the estimator to it,
> the output is unstable with some fluctuations. The picture ‘SNR
> output’ is the first 1024 output of estimator, how can I calculate the
> SNR?
>
>  
>
> Many thanks,
>
> Yan
>
> *From:*Marcus Müller [mailto:marcus.muel...@ettus.com]
> *Sent:* 03 May 2016 13:10
> *To:* Yan Huang; discuss-gnuradio@gnu.org
> *Cc:* Martin Braun
> *Subject:* Re: [Discuss-gnuradio] How to test and change SNR in
> GNURadio by B210
>
>  
>
> Dear Yan,
>
>   If I want to change the SNR, can I add a Noise Source to the USRP
> Source to change it?
>
> Well, sure, but then you have two sources of noise: the noise inferred
> via reception of the signal with additive noise, and the added noise
> source power.
> It's a change, but it's pretty hard to quantify. You should really be
> starting with a simulation only! Don't add more unknowns to a system
> you need to estimate.
>
>
> But the problem is I don’t know how to estimate the noise power of the
> receive signal.
>
> Well, that is the hard part, indeed.
> You could really just reverse the OFDM mapping by doing an FFT of
> appropriate size, but you'd infer errors: You don't have any timing or
> frequency recovery, and I really *don't know* how the existing
> estimators react to that.
>
> To be completely honest: reading the comments/documention of the
> estimators, it's clear that they were designed for the use case of PSK
> in time domain, and some were hand-tweaked to give good numbers in
> that case.
> I'd have to do quite some math to figure out how the different
> estimators would react to things like jitter or to ISI due to
> imperfect orthogonality, phase impairments due to overly high PAPR...
>
> You could really just reverse the 512-IFFT you do on the transmitter
> side, pick the 200 subcarriers that actually contain your 200 PSK
> signals, estimate the SNR in these, convert those SNR values back to a
> signal-only powers by means of observing the overall power per
> subcarrier, subtract that overall signal power from the overall input
> power to calculate noise power, and calculate overall SNR based on
> that. That ignores the effects mentioned in the previous paragraph,
> but would give you a rough number. It's worth mentioning that this
> includes the (512-200) unused subcarriers of your OFDM transmitter –
> but you said you want to apply Parseval, and hence, we'll have to roll
> with all the frequency and time domain. Frankly, you could as well
> just estimate the powers in the unoccupied FFT bins, postulate noise
> is white, extrapolate from that to the overall noise in all bins, and
> calculate SNR based on that. I think that's the obvious route here –
> but it seems you have already discarded that idea; why?
>
> If you need this for more than giving you a rough idea of how noisy
> the transmission is, you won't get around describing your exact
> assumptions about the PSK signal, and the statistical properties of
> your noise, after the OFDM de-mapping. I'm pretty sure there's quite
> some literature out there that already deals with SNR in OFDM systems.
>
> However, as explained in my previous mail, for all practical purposes,
> the raw sum-SNR is pretty irrelevant, probably. For example, have a
> look at the LTE standards – they have pretty complex methods, based on
> estimating a lot of known pilot symbols that are deliberately spread
> all over the time-frequency plane. Yes, that "wastes" spectrum just to
> obtain channel state information (not only noise power and signal
> attenuation, but also phase shift on the individual subcarriers), but
> since the receivers needs that CSI anyway to reliably decode the
> signal(s), the "transmission quality estimates" are pretty much a
> lucky by-product.
>
> Now, I'd like to recommend removing  the "OFDM mod" block, which is
> outdated and really not recommended for usage in new designs, and
> using "OFDM Transmitter" instead. Refer to
> 

[Discuss-gnuradio] AUTO: Frank Zeppenfeldt is out of the office (returning 09/05/2016)

[Frank . Zeppenfeldt]

I am out of the office until 09/05/2016.

Back on Monday 9 May. Sporadic email access during this period.


Note: This is an automated response to your message  "Discuss-gnuradio
Digest, Vol 162, Issue 1" sent on 03/05/2016 17:41:15.

This is the only notification you will receive while this person is away.
This message and any attachments are intended for the use of the addressee or 
addressees only.
The unauthorised disclosure, use, dissemination or copying (either in whole or 
in part) of its
content is not permitted.
If you received this message in error, please notify the sender and delete it 
from your system.
Emails can be altered and their integrity cannot be guaranteed by the sender.

Please consider the environment before printing this email.

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

Re: [Discuss-gnuradio] [USRP-users] minimum PPS voltage for N200

[khalid.el-darymli]

Thanks Marcus.

OK, I'm communicating with the external Firefly-1A GPSDO unit using an RS
232 cable. I am able to do so after enabling echoing on RS 232 from the
GPSDO. Would that be a problem? Do I need to completely disable the RS 232
echoing, even while the RS 232 cable is completely unplugged?

When the RS 232 cable is plugged-in, N200 DETECTs it as an INTERNAL GPSDO.
When I completely unplug the RS 232 cable on both ends, I am not getting
any messages for detecting neither external nor internal GPSDO. It only
shows the following in the terminal for both N200 devices,

(1) catch time transition at pps edge
(2) set time next pps (synchronously).

khalid




On Tue, May 3, 2016 at 12:20 PM,  wrote:

> The PPS input is conditioned with a:
>
> http://www.ti.com/product/SN74AUP1T57/description
>
> Looks to me like it should work just fine.
>
>
>
>
>
>
> On 2016-05-03 10:23, khalid.el-darymli via USRP-users wrote:
>
> Hi,
>
> I'll appreciate any help on the following. According to the link below
> [1], the PPS voltage for N200 should be in the range *[3.3, 5]* V p-p.
> [1] http://files.ettus.com/manual/page_usrp2.html#usrp2_hw_leds
>
> I am getting a PPS signal through fan-outs from an external Firefly-1A
> GPSDO. I measured the output PPS voltage using a scope, and it is *2.52 V
> p-p* (terminated with 50 ohms).
>
> Would this relatively low PPS voltage work for N200?  I am having a
> problem syncing two N200 units (2 LFRX/ 1 LFTX ), and I am not sure if this
> would be the cause?
>
>
> Thank you.
>
> Best wishes,
> Khalid
>
>
> ___
> USRP-users mailing list
> usrp-us...@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] ORC support on armhf w/ embedded SDK

[Sean Nowlan]

Sorry, email confusion with IEEE email forwarding. Resending to hit
discuss-gnuradio list.

Ok, thanks. FYI, it looks like ORC 0.4.23 is being used in OpenEmbedded
Jethro. This version incorporated the bugfix, so it could theoretically be
enabled in meta-sdr's gnuradio build.

On Tue, May 3, 2016 at 11:51 AM, Sean Nowlan  wrote:

> Ok, thanks. FYI, it looks like ORC 0.4.23 is being used in OpenEmbedded
> Jethro. This version incorporated the bugfix, so it could theoretically be
> enabled in meta-sdr's gnuradio build.
>
> Sean
>
> On Tue, May 3, 2016 at 11:39 AM, West, Nathan  > wrote:
>
>> ORC is still in VOLK, but it doesn't give you much.
>>
>> On Tue, May 3, 2016 at 11:32 AM, Philip Balister 
>> wrote:
>>
>>> On 05/03/2016 10:47 AM, Sean Nowlan wrote:
>>> > According to the wiki [1], ORC support was disabled on armhf due to a
>>> bug,
>>> > which has apparently since been resolved [2]. Was ORC support added
>>> back
>>> > for armhf in the most recent SDK from 20-APR-2016 [3]? I.e., is the
>>> wiki
>>> > page just out of date?
>>> >
>>> > Thanks,
>>> > Sean
>>> >
>>> > [1] http://gnuradio.org/redmine/projects/gnuradio/wiki/Embedded
>>> > [2] https://bugzilla.gnome.org/show_bug.cgi?id=727464
>>> > [3] http://gnuradio.org/data/sdk/
>>>
>>> I feel like we've replaced all the places we used orc, so we
>>> (uhd/gnuradio/volk) are not really using it anymore.
>>>
>>> It tends to show up in images, just that it may not be used by gnuradio
>>> and friends.
>>>
>>> Philip
>>>
>>> >
>>> >
>>> >
>>> > ___
>>> > 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] How to test and change SNR in GNURadio by B210

[Yan Huang]

Hi Marcus,

Thanks a lot, following your suggestion:

· I add a 512-FFT on the receiver side, but how can I only pick the 
first 200 subcarriers? I set the max output buffer of FFT as 200, but I don't 
think it works.  How can I deal with it?

· After FFT in receiver side, I connect the estimator to it, the output 
is unstable with some fluctuations. The picture 'SNR output' is the first 1024 
output of estimator, how can I calculate the SNR?


Many thanks,
Yan
From: Marcus Müller [mailto:marcus.muel...@ettus.com]
Sent: 03 May 2016 13:10
To: Yan Huang; discuss-gnuradio@gnu.org
Cc: Martin Braun
Subject: Re: [Discuss-gnuradio] How to test and change SNR in GNURadio by B210

Dear Yan,

  If I want to change the SNR, can I add a Noise Source to the USRP Source to 
change it?
Well, sure, but then you have two sources of noise: the noise inferred via 
reception of the signal with additive noise, and the added noise source power.
It's a change, but it's pretty hard to quantify. You should really be starting 
with a simulation only! Don't add more unknowns to a system you need to 
estimate.


But the problem is I don't know how to estimate the noise power of the receive 
signal.
Well, that is the hard part, indeed.
You could really just reverse the OFDM mapping by doing an FFT of appropriate 
size, but you'd infer errors: You don't have any timing or frequency recovery, 
and I really *don't know* how the existing estimators react to that.

To be completely honest: reading the comments/documention of the estimators, 
it's clear that they were designed for the use case of PSK in time domain, and 
some were hand-tweaked to give good numbers in that case.
I'd have to do quite some math to figure out how the different estimators would 
react to things like jitter or to ISI due to imperfect orthogonality, phase 
impairments due to overly high PAPR...

You could really just reverse the 512-IFFT you do on the transmitter side, pick 
the 200 subcarriers that actually contain your 200 PSK signals, estimate the 
SNR in these, convert those SNR values back to a signal-only powers by means of 
observing the overall power per subcarrier, subtract that overall signal power 
from the overall input power to calculate noise power, and calculate overall 
SNR based on that. That ignores the effects mentioned in the previous 
paragraph, but would give you a rough number. It's worth mentioning that this 
includes the (512-200) unused subcarriers of your OFDM transmitter - but you 
said you want to apply Parseval, and hence, we'll have to roll with all the 
frequency and time domain. Frankly, you could as well just estimate the powers 
in the unoccupied FFT bins, postulate noise is white, extrapolate from that to 
the overall noise in all bins, and calculate SNR based on that. I think that's 
the obvious route here - but it seems you have already discarded that idea; why?

If you need this for more than giving you a rough idea of how noisy the 
transmission is, you won't get around describing your exact assumptions about 
the PSK signal, and the statistical properties of your noise, after the OFDM 
de-mapping. I'm pretty sure there's quite some literature out there that 
already deals with SNR in OFDM systems.

However, as explained in my previous mail, for all practical purposes, the raw 
sum-SNR is pretty irrelevant, probably. For example, have a look at the LTE 
standards - they have pretty complex methods, based on estimating a lot of 
known pilot symbols that are deliberately spread all over the time-frequency 
plane. Yes, that "wastes" spectrum just to obtain channel state information 
(not only noise power and signal attenuation, but also phase shift on the 
individual subcarriers), but since the receivers needs that CSI anyway to 
reliably decode the signal(s), the "transmission quality estimates" are pretty 
much a lucky by-product.

Now, I'd like to recommend removing  the "OFDM mod" block, which is outdated 
and really not recommended for usage in new designs, and using "OFDM 
Transmitter" instead. Refer to 
/usr/(local)/share/gnuradio/examples/digital/ofdm/ofdm_loopback.grc for usage 
of that.
When you look at rx_ofdm.grc in that directory (which contains practically the 
insides of the "OFDM Receiver" block) , you'll notice the "OFDM Channel 
Estimation" and the "OFDM Frame Equalizer" blocks, as well as the 
"header_equalizer" variable. All these are backed by C++ classes in gr-digital, 
and I can only recommend reading the documentation, and in your case, since 
this seems to be your scientific focus, the source code of those - [1] should 
be your entry point; have a look at the documentation of 
gr::digital::ofdm_chanest_vcvc first. Reading Schmidl and Cox is probably an 
interesting thing to do, too! Especially the second half of that paper goes 
into detail about how they actually estimated and evaluated performance, which 
is a nice thing that imho more papers should do.

The equalizer taps generated 

Re: [Discuss-gnuradio] ORC support on armhf w/ embedded SDK

[West, Nathan]

ORC is still in VOLK, but it doesn't give you much.

On Tue, May 3, 2016 at 11:32 AM, Philip Balister 
wrote:

> On 05/03/2016 10:47 AM, Sean Nowlan wrote:
> > According to the wiki [1], ORC support was disabled on armhf due to a
> bug,
> > which has apparently since been resolved [2]. Was ORC support added back
> > for armhf in the most recent SDK from 20-APR-2016 [3]? I.e., is the wiki
> > page just out of date?
> >
> > Thanks,
> > Sean
> >
> > [1] http://gnuradio.org/redmine/projects/gnuradio/wiki/Embedded
> > [2] https://bugzilla.gnome.org/show_bug.cgi?id=727464
> > [3] http://gnuradio.org/data/sdk/
>
> I feel like we've replaced all the places we used orc, so we
> (uhd/gnuradio/volk) are not really using it anymore.
>
> It tends to show up in images, just that it may not be used by gnuradio
> and friends.
>
> Philip
>
> >
> >
> >
> > ___
> > 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] ORC support on armhf w/ embedded SDK

[Philip Balister]

On 05/03/2016 10:47 AM, Sean Nowlan wrote:
> According to the wiki [1], ORC support was disabled on armhf due to a bug,
> which has apparently since been resolved [2]. Was ORC support added back
> for armhf in the most recent SDK from 20-APR-2016 [3]? I.e., is the wiki
> page just out of date?
> 
> Thanks,
> Sean
> 
> [1] http://gnuradio.org/redmine/projects/gnuradio/wiki/Embedded
> [2] https://bugzilla.gnome.org/show_bug.cgi?id=727464
> [3] http://gnuradio.org/data/sdk/

I feel like we've replaced all the places we used orc, so we
(uhd/gnuradio/volk) are not really using it anymore.

It tends to show up in images, just that it may not be used by gnuradio
and friends.

Philip

> 
> 
> 
> ___
> 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] Getting one or more Ds after hours of running a GRC app on Ubuntu

[mleech]

It's possible that we're dealing with a memory leak somewhere.  Could
you watch the memory consumption of simple_ra over time? 

Also, could you just run something like uhd_fft with the same sample
rate for long periods to see if it gets the same 'D' treatment? 

On 2016-05-03 04:32, John Shields wrote:

> Thanks Marcus,
> 
> Have put answers in-line.
> 
> Kind Regards,
> 
> John
> 
> ___
> 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] Corrupted SDK installer

[Sean Nowlan]

I believe the non-GUI embedded SDK installer from 20-APR-2016 posted here
[1] is corrupted, or at least the download keeps failing in the same way.

The SHA256 checksums do not match:
Posted [2]: 0c50d6d44db9cb030800cfffe0ff2a4d7022a2c1c5e0b9c9f2dc155435c5657a
Actual: d99df0557e8766d02036f583cca6fb95d066d7e7c7614f271c0b84efe711e81b

This error occurs when the script is self-extracting: [3]. Note that the
GUI version downloads properly and has a correct SHA256 checksum.

Thanks,
Sean

[1]
http://gnuradio.org/data/sdk/armv7hf/20160420/oecore-x86_64-armv7ahf-vfp-neon-toolchain-nodistro.0.sh
[2] http://gnuradio.org/data/sdk/
[3] https://gist.github.com/nowls/f25cbfd314c47e9ecabd2a33d3e3399c
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [USRP-users] minimum PPS voltage for N200

[mleech]

The PPS input is conditioned with a: 

http://www.ti.com/product/SN74AUP1T57/description 

Looks to me like it should work just fine. 

On 2016-05-03 10:23, khalid.el-darymli via USRP-users wrote:

> Hi,
> 
> I'll appreciate any help on the following. According to the link below [1], 
> the PPS voltage for N200 should be in the range [3.3, 5] V p-p.
> [1] http://files.ettus.com/manual/page_usrp2.html#usrp2_hw_leds
> 
> I am getting a PPS signal through fan-outs from an external Firefly-1A GPSDO. 
> I measured the output PPS voltage using a scope, and it is 2.52 V P-P 
> (terminated with 50 ohms).
> 
> Would this relatively low PPS voltage work for N200?  I am having a problem 
> syncing two N200 units (2 LFRX/ 1 LFTX ), and I am not sure if this would be 
> the cause?
> 
> Thank you.
> 
> Best wishes, 
> Khalid
> 
> ___
> USRP-users mailing list
> usrp-us...@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] ORC support on armhf w/ embedded SDK

[Sean Nowlan]

According to the wiki [1], ORC support was disabled on armhf due to a bug,
which has apparently since been resolved [2]. Was ORC support added back
for armhf in the most recent SDK from 20-APR-2016 [3]? I.e., is the wiki
page just out of date?

Thanks,
Sean

[1] http://gnuradio.org/redmine/projects/gnuradio/wiki/Embedded
[2] https://bugzilla.gnome.org/show_bug.cgi?id=727464
[3] http://gnuradio.org/data/sdk/
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] minimum PPS voltage for N200

[khalid.el-darymli]

Hi,

I'll appreciate any help on the following. According to the link below [1],
the PPS voltage for N200 should be in the range *[3.3, 5]* V p-p.
[1] http://files.ettus.com/manual/page_usrp2.html#usrp2_hw_leds

I am getting a PPS signal through fan-outs from an external Firefly-1A
GPSDO. I measured the output PPS voltage using a scope, and it is *2.52 V
p-p* (terminated with 50 ohms).

Would this relatively low PPS voltage work for N200?  I am having a problem
syncing two N200 units (2 LFRX/ 1 LFTX ), and I am not sure if this would
be the cause?


Thank you.

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

Re: [Discuss-gnuradio] How to test and change SNR in GNURadio by B210

[Marcus Müller]

Dear Yan,
>   If I want to change the SNR, can I add a Noise Source to the USRP
> Source to change it?
Well, sure, but then you have two sources of noise: the noise inferred
via reception of the signal with additive noise, and the added noise
source power.
It's a change, but it's pretty hard to quantify. You should really be
starting with a simulation only! Don't add more unknowns to a system you
need to estimate.

> But the problem is I don’t know how to estimate the noise power of the
> receive signal.
Well, that is the hard part, indeed.
You could really just reverse the OFDM mapping by doing an FFT of
appropriate size, but you'd infer errors: You don't have any timing or
frequency recovery, and I really *don't know* how the existing
estimators react to that.

To be completely honest: reading the comments/documention of the
estimators, it's clear that they were designed for the use case of PSK
in time domain, and some were hand-tweaked to give good numbers in that
case.
I'd have to do quite some math to figure out how the different
estimators would react to things like jitter or to ISI due to imperfect
orthogonality, phase impairments due to overly high PAPR...

You could really just reverse the 512-IFFT you do on the transmitter
side, pick the 200 subcarriers that actually contain your 200 PSK
signals, estimate the SNR in these, convert those SNR values back to a
signal-only powers by means of observing the overall power per
subcarrier, subtract that overall signal power from the overall input
power to calculate noise power, and calculate overall SNR based on that.
That ignores the effects mentioned in the previous paragraph, but would
give you a rough number. It's worth mentioning that this includes the
(512-200) unused subcarriers of your OFDM transmitter – but you said you
want to apply Parseval, and hence, we'll have to roll with all the
frequency and time domain. Frankly, you could as well just estimate the
powers in the unoccupied FFT bins, postulate noise is white, extrapolate
from that to the overall noise in all bins, and calculate SNR based on
that. I think that's the obvious route here – but it seems you have
already discarded that idea; why?

If you need this for more than giving you a rough idea of how noisy the
transmission is, you won't get around describing your exact assumptions
about the PSK signal, and the statistical properties of your noise,
after the OFDM de-mapping. I'm pretty sure there's quite some literature
out there that already deals with SNR in OFDM systems.

However, as explained in my previous mail, for all practical purposes,
the raw sum-SNR is pretty irrelevant, probably. For example, have a look
at the LTE standards – they have pretty complex methods, based on
estimating a lot of known pilot symbols that are deliberately spread all
over the time-frequency plane. Yes, that "wastes" spectrum just to
obtain channel state information (not only noise power and signal
attenuation, but also phase shift on the individual subcarriers), but
since the receivers needs that CSI anyway to reliably decode the
signal(s), the "transmission quality estimates" are pretty much a lucky
by-product.

Now, I'd like to recommend removing  the "OFDM mod" block, which is
outdated and really not recommended for usage in new designs, and using
"OFDM Transmitter" instead. Refer to
/usr/(local)/share/gnuradio/examples/digital/ofdm/ofdm_loopback.grc for
usage of that.
When you look at rx_ofdm.grc in that directory (which contains
practically the insides of the "OFDM Receiver" block) , you'll notice
the "OFDM Channel Estimation" and the "OFDM Frame Equalizer" blocks, as
well as the "header_equalizer" variable. All these are backed by C++
classes in gr-digital, and I can only recommend reading the
documentation, and in your case, since this seems to be your scientific
focus, the source code of those – [1] should be your entry point; have a
look at the documentation of gr::digital::ofdm_chanest_vcvc first.
Reading Schmidl and Cox is probably an interesting thing to do, too!
Especially the second half of that paper goes into detail about how they
actually estimated and evaluated performance, which is a nice thing that
imho more papers should do.

The equalizer taps generated are of central importance here – you'll
notice that their amplitude response should be inversely proportional to
the frequency attenuation of the channel. That, together with
observation of the output power of the equalizer used with these taps,
in relation to the input power, would probably be an interesting
starting point to acquire an SNR estimate. Sadly, I don't have cited
Kammeyer at hand – and it's in German, so I guess your university's
library won't have it around, so I can't look up the mentioned channel
estimation noise reduction method.**However, the code //TODO comment
mentions it's really just using an FFT to get rid of the noise in bins
that aren't relevant to the signal, anyway. It seems to be kind of a
low-pass 

Re: [Discuss-gnuradio] How to test and change SNR in GNURadio by B210

[Yan Huang]

Hi Marcus,

Thank you for kind reply. Actually I want to calculate the sum-Signal to 
sum-Noise ratio, as you have referred Parseval to calculate it.


· But the problem is I don't know how to estimate the noise power of 
the receive signal.

· If I want to change the SNR, can I add a Noise Source to the USRP 
Source to change it?

Many thanks,
Yan

From: Discuss-gnuradio 
[mailto:discuss-gnuradio-bounces+eexyh22=nottingham.ac...@gnu.org] On Behalf Of 
Marcus Müller
Sent: 29 April 2016 19:20
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] How to test and change SNR in GNURadio by B210

Dear Yan,


 2.Can I use  'MPSK USRP Estimator' to test SNR to test SNR in this situation?

OFDM containing BPSK symbols is not a PSK modulation in time domain; so you're 
using the wrong estimator as is.

Therefore:


 1.why the SNR I get is nearly 0(about 10^-3)? If I increase the noise 
amplitude, the SNR increase slightly(about 10^-1), I think it will decrease as 
noise increase.
Because you're sending something that to the wrong receiver should look like 
wideband, not-quite-white noise. More energy from a white noise source seems to 
accidentally increase the SNR estimate.



 3.How can I read the SNR information by using  'MPSK USRP Estimator prob'?
Not at all, if you want to use OFDM.

Generally, this is a very specific estimator for a very specific problem.

In multi-carrier system, definining a single SNR is challenging theoretically - 
and questionable in effect, too. What's the bandwidth of your signal if you've 
got unoccupied carriers? What's the signal power? Do you look at noise and 
signal power for the whole system as one, or do you consider the individual 
carriers individually? If individually, is overall SNR the minimum subcarrier 
SNR, a sum-Signal to sum-Noise ratio (for OFDM, Parseval would make that 
simple), or is it maybe some non-linear combination that might make more sense 
when considering the overall system?
And: What is the meaning of SNR here, and what do you intend to use it for? 
Wouldn't [$\frac{\textE_b}{N_0}$] make more sense? If it does, what is 
[$N_0$] in the constellation domain (ie. after reversing the OFDM modulation)?

Of course, you can OFDM-demodulate (read: DFT) the receiver signal and put it 
through the MPSK SNR estimator; but that would mean that you'll have to do all 
the mathematical derivation of how that SNR relates to its input. Notice that 
if the noise your channel adds isn't really white for all DFT bins (it's 
probably not, because OFDM in practice isn't infinitely steep at the edges, and 
due to some effects the subcarriers might not be perfectly orthogonal, either, 
adding self-interference), you might end up with more noise in some subcarriers 
than others. BER-over-SNR curves tend to be nonlinear, so this might pose a 
problem for the interpretation of the SNR as tool to estimate the BER. I 
haven't actually measured that effect, and to be honest, I don't think it's 
going to be terrible.

What's more important, however, is that you use OFDM exactly when your channel 
is non-flat; that's because dividing your overall bandwidth into smaller 
subchannels allows for easier per-subchannel equalization.
Now, that means that the signal power will vary between different subcarriers 
in a situation where you'd prefer OFDM over single-carrier systems - and that 
makes it necessary to estimate the signal power per subcarrier, which means you 
will very likely have different SNRs for different subcarriers.

Best regards,
Marcus
On 29.04.2016 19:02, Yan Huang wrote:

Hi all,



I'm using USRP B210 to employ spectrum sensing, I want to plot ROC curve of the 
sensing output  signal.



So I need to test and change the SNR of the receive signal. The attached 
picture is the flowgraph I use.



I choose 'MPSK USRP Estimator' to test SNR since my tx signal is BPSK.



The problem is:



 1.why the SNR I get is nearly 0(about 10^-3)? If I increase the noise 
amplitude, the SNR increase slightly(about 10^-1), I think it will decrease as 
noise increase.



 2.Can I use  'MPSK USRP Estimator' to test SNR to test SNR in this situation?



 3.How can I read the SNR information by using  'MPSK USRP Estimator prob'?



Many thanks in advance.



Kind regards,



Yan







This message and any attachment are intended solely for the addressee

and may contain confidential information. If you have received this

message in error, please send it back to me, and immediately delete it.



Please do not use, copy or disclose the information contained in this

message or in any attachment.  Any views or opinions expressed by the

author of this email do not necessarily reflect the views of the

University of Nottingham.



This message has been checked for viruses but the contents of an

attachment may still contain software viruses which could damage your

computer system, you are advised to perform your own checks. Email

communications with the 

Re: [Discuss-gnuradio] Getting one or more Ds after hours of running a GRC app on Ubuntu

[Marcus Müller]

Hi John,
agreeed,
  we need to shorten this thread :)

Hence: replies below!

Best regards,
Marcus

>> They are certainly not the greatest NICs in the world when it comes to
>> CPU efficiency, but I'm not aware of any specific prolems. Can you
>> actually just try with the atheros interface? That would rule them out
>> as possible source of problems.
> Yes, I will give the on-board Atheros a try.
Great!
>> 1. could you share what "glxinfo | grep renderer" says? (or was it
>> glxinfo64? If both are present, send both :) )
>> 2. there was a way to dis/enable wx OpenGL usage per config file. My
>> brain feels a bit holey these days; I'd have to research that.
>
> john@i7Ubuntu:~$ glxinfo | grep renderer
> GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer,
> GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer,
> OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Desktop
>
> not sure if it is significant or not but I had to install glxinfo (
> sudo apt-get install mesa-utils)
Ah, right, sorry, I forgot it doesn't come with the X server. That looks
fine, however. No "Mesa software renderer" etc.
>> do you need to power-cycle the N210?
> no Marcus, I just restart simple_ra and it goes off running fine - no
> need to touch the N200.
That's a relief; I really wanted to make sure nothing unusual makes the
N200's control mechanisms lock up.

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

Re: [Discuss-gnuradio] Getting one or more Ds after hours of running a GRC app on Ubuntu

[John Shields]

Thanks Marcus,

Have put answers in-line.

   Kind Regards,

   John

On 03/05/16 08:20, Marcus Müller wrote:

On 03.05.2016 09:52, John Shields wrote:

On 03/05/16 02:58, Marcus D. Leech wrote:

On 05/02/2016 10:40 PM, John Shields wrote:

the system runs along happily for several maybe even up to 20 odd
hours but, as below, I start to see one or more Ds. In one run of 23
hours, I had 10 Ds and eventually a segmentation fault - not sure if
it is coincident with issuing of the final 'D'. Sometimes the D is
not accompanied by UHD errors

here is the terminal output from the last run:

linux; GNU C++ version 4.8.4; Boost_105400;
UHD_003.010.git-156-g2d68f228

Using Volk machine: avx_64_mmx_orc
gr-osmosdr v0.1.4-72-g164a09fc (0.1.5git) gnuradio 3.7.9.1
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf
rfspace airspy redpitaya
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
-- Detecting internal GPSDO Found an internal GPSDO
-- Setting references to the internal GPSDO
-- Using subdev spec 'A:0'.
-- Using LO offset of 1e+07 Hz.
WARNING: Overriding original sample rate of 1e+07 with 2e+06
-- Loaded /home/john/.uhd/cal/rx_iq_cal_v0.2_E2R10Z1XS.csv
D
UHD Error:
 Control packet attempt 0, sequence number 10594:
 RuntimeError: no control response, possible packet loss

UHD Error:
 Control packet attempt 1, sequence number 10595:
 RuntimeError: no control response, possible packet loss

UHD Error:
 Control packet attempt 2, sequence number 10596:
 RuntimeError: no control response, possible packet loss

UHD Error:
 An unexpected exception was caught in a task loop.
 The task loop will now exit, things may not work.
 RuntimeError: link dead: timeout waiting for control packet ACK
Terminated


00:02.0 VGA compatible controller: Intel Corporation 2nd Generation
Core Processor Family Integrated Graphics Controller (rev 09) (prog-if
00 [VGA controller])
...
 Kernel driver in use: i915

02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 01)
...
 Kernel driver in use: r8169

03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 01)
...
 Kernel driver in use: r8169


06:00.0 Ethernet controller: Qualcomm Atheros AR8151 v2.0 Gigabit
Ethernet (rev c0)
...
 Kernel driver in use: atl1c

by looking at the Realtek card, the PHY chip is the RTL8168B
(single-chip Gigabit NIC Ethernet Controller for PCI Express)

not sure if there is general knowledge of this Taiwanese NIC/Chip re:
dropping packets or other performance issues? I note these boards are
rev 1.0!

They are certainly not the greatest NICs in the world when it comes to
CPU efficiency, but I'm not aware of any specific prolems. Can you
actually just try with the atheros interface? That would rule them out
as possible source of problems.

Yes, I will give the on-board Atheros a try.

re: relatively high CPU for 8 cores running simple_ra - the '8' is
actually only 4 real cores (2 logical cores per physical) but as can
be seen from below,
I don't believe I splashed out on a graphics card and just took the
motherboard's capability. Perhaps my Scottish accent can be detected?
Will look into getting something along those lines if it improves the
graphics performance.

00:02.0 VGA compatible controller: Intel Corporation 2nd Generation
Core Processor Family Integrated Graphics Controller (rev 09) (prog-if
00 [VGA controller])
..
 Kernel driver in use: i915

That's an Intel HD 4000 or so, right? At any rate, they should have
enough horsepower to update a few plots via OpenGL. What indeed could be
happening is that hardware rendering is not used (the wx GUI toolkit
seems to be a little special sometimes, but then, who or what isn't?).
So two things:

1. could you share what "glxinfo | grep renderer" says? (or was it
glxinfo64? If both are present, send both :) )
2. there was a way to dis/enable wx OpenGL usage per config file. My
brain feels a bit holey these days; I'd have to research that.


john@i7Ubuntu:~$ glxinfo | grep renderer
GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer,
GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer,
OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Desktop

not sure if it is significant or not but I had to install glxinfo ( sudo 
apt-get install mesa-utils)




General question: After things crashed, using the N210 works if you
re-start simple_ra (or any other UHD sample streaming program), or do
you need to power-cycle the N210?
no Marcus, I just restart simple_ra and it goes off running fine - no 
need to touch the N200.


Best regards,
Marcus

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org

Re: [Discuss-gnuradio] Getting one or more Ds after hours of running a GRC app on Ubuntu

[Marcus Müller]

On 03.05.2016 09:52, John Shields wrote:
> On 03/05/16 02:58, Marcus D. Leech wrote:
>> On 05/02/2016 10:40 PM, John Shields wrote:
>>>
>>> the system runs along happily for several maybe even up to 20 odd
>>> hours but, as below, I start to see one or more Ds. In one run of 23
>>> hours, I had 10 Ds and eventually a segmentation fault - not sure if
>>> it is coincident with issuing of the final 'D'. Sometimes the D is
>>> not accompanied by UHD errors
>>>
>>> here is the terminal output from the last run:
>>>
>>> linux; GNU C++ version 4.8.4; Boost_105400;
>>> UHD_003.010.git-156-g2d68f228
>>>
>>> Using Volk machine: avx_64_mmx_orc
>>> gr-osmosdr v0.1.4-72-g164a09fc (0.1.5git) gnuradio 3.7.9.1
>>> built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf
>>> rfspace airspy redpitaya
>>> -- Opening a USRP2/N-Series device...
>>> -- Current recv frame size: 1472 bytes
>>> -- Current send frame size: 1472 bytes
>>> -- Detecting internal GPSDO Found an internal GPSDO
>>> -- Setting references to the internal GPSDO
>>> -- Using subdev spec 'A:0'.
>>> -- Using LO offset of 1e+07 Hz.
>>> WARNING: Overriding original sample rate of 1e+07 with 2e+06
>>> -- Loaded /home/john/.uhd/cal/rx_iq_cal_v0.2_E2R10Z1XS.csv
>>> D
>>> UHD Error:
>>> Control packet attempt 0, sequence number 10594:
>>> RuntimeError: no control response, possible packet loss
>>>
>>> UHD Error:
>>> Control packet attempt 1, sequence number 10595:
>>> RuntimeError: no control response, possible packet loss
>>>
>>> UHD Error:
>>> Control packet attempt 2, sequence number 10596:
>>> RuntimeError: no control response, possible packet loss
>>>
>>> UHD Error:
>>> An unexpected exception was caught in a task loop.
>>> The task loop will now exit, things may not work.
>>> RuntimeError: link dead: timeout waiting for control packet ACK
>>> Terminated
>>>
> 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation
> Core Processor Family Integrated Graphics Controller (rev 09) (prog-if
> 00 [VGA controller])
> ...
> Kernel driver in use: i915
>
> 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 01)
> ...
> Kernel driver in use: r8169
>
> 03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 01)
> ...
> Kernel driver in use: r8169
>
>
> 06:00.0 Ethernet controller: Qualcomm Atheros AR8151 v2.0 Gigabit
> Ethernet (rev c0)
> ...
> Kernel driver in use: atl1c
>
> by looking at the Realtek card, the PHY chip is the RTL8168B
> (single-chip Gigabit NIC Ethernet Controller for PCI Express)
>
> not sure if there is general knowledge of this Taiwanese NIC/Chip re:
> dropping packets or other performance issues? I note these boards are
> rev 1.0!
They are certainly not the greatest NICs in the world when it comes to
CPU efficiency, but I'm not aware of any specific prolems. Can you
actually just try with the atheros interface? That would rule them out
as possible source of problems.
>
> re: relatively high CPU for 8 cores running simple_ra - the '8' is
> actually only 4 real cores (2 logical cores per physical) but as can
> be seen from below,
> I don't believe I splashed out on a graphics card and just took the
> motherboard's capability. Perhaps my Scottish accent can be detected?
> Will look into getting something along those lines if it improves the
> graphics performance.
>
> 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation
> Core Processor Family Integrated Graphics Controller (rev 09) (prog-if
> 00 [VGA controller])
> ..
> Kernel driver in use: i915
That's an Intel HD 4000 or so, right? At any rate, they should have
enough horsepower to update a few plots via OpenGL. What indeed could be
happening is that hardware rendering is not used (the wx GUI toolkit
seems to be a little special sometimes, but then, who or what isn't?).
So two things:

1. could you share what "glxinfo | grep renderer" says? (or was it
glxinfo64? If both are present, send both :) )
2. there was a way to dis/enable wx OpenGL usage per config file. My
brain feels a bit holey these days; I'd have to research that.

General question: After things crashed, using the N210 works if you
re-start simple_ra (or any other UHD sample streaming program), or do
you need to power-cycle the N210?

Best regards,
Marcus

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

Re: [Discuss-gnuradio] Getting one or more Ds after hours of running a GRC app on Ubuntu

[John Shields]

On 03/05/16 02:58, Marcus D. Leech wrote:

On 05/02/2016 10:40 PM, John Shields wrote:

Hi,
   I am using Ubunutu 14.04 LTS with GNURadio 3.7.9.1 and have a USRP 
N200 with SBXv3. I have been using the aptly-named and highly useful 
Simple_ra though I believe this is orthogonal to the issues I am seeing.


when I run simple_ra with :

 simple_ra  --srate 2e6 --freq 848e6 --gain 37 --dcg 1 --devid 
uhd=a,type=usrp2,addr=192.168.20.2,lo_offset=10e6,subdev=A:0 
--longitude 172.57027 --latitude -43.51944 --spde


the system runs along happily for several maybe even up to 20 odd 
hours but, as below, I start to see one or more Ds. In one run of 23 
hours, I had 10 Ds and eventually a segmentation fault - not sure if 
it is coincident with issuing of the final 'D'. Sometimes the D is 
not accompanied by UHD errors


here is the terminal output from the last run:

linux; GNU C++ version 4.8.4; Boost_105400; 
UHD_003.010.git-156-g2d68f228


Using Volk machine: avx_64_mmx_orc
gr-osmosdr v0.1.4-72-g164a09fc (0.1.5git) gnuradio 3.7.9.1
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf 
rfspace airspy redpitaya

-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
-- Detecting internal GPSDO Found an internal GPSDO
-- Setting references to the internal GPSDO
-- Using subdev spec 'A:0'.
-- Using LO offset of 1e+07 Hz.
WARNING: Overriding original sample rate of 1e+07 with 2e+06
-- Loaded /home/john/.uhd/cal/rx_iq_cal_v0.2_E2R10Z1XS.csv
D
UHD Error:
Control packet attempt 0, sequence number 10594:
RuntimeError: no control response, possible packet loss

UHD Error:
Control packet attempt 1, sequence number 10595:
RuntimeError: no control response, possible packet loss

UHD Error:
Control packet attempt 2, sequence number 10596:
RuntimeError: no control response, possible packet loss

UHD Error:
An unexpected exception was caught in a task loop.
The task loop will now exit, things may not work.
RuntimeError: link dead: timeout waiting for control packet ACK
Terminated


I have a fairly powerful cpu Intel® Core™ i7-2600 CPU @ 3.40GHz × 8, 
15.6 GiB of memory and run 64-bit os and have the USRP on it's own 
subnet and NIC.

Apart from setting:
net.core.rmem_max = 5000
net.core.wmem_max = 1048576

I have not 'tuned' any os settings. When the application is running, 
the 8 cores are between 40-50% utilised.


When I restart simple_ra after the error, it runs again fine until it 
hits an issue n-hours in the future.


Any ideas of how I can narrow down the cause of this?

  Kind Regards,

   John




Do you happen to know what kind of NIC you have?

Also, 2MSPS should not be chewing up much of your CPU--what kind of 
graphics card do you have?  Is this a real, or virtual, machine setup?


There Intel 82579LM is known for dropping packets under certain 
circumstances that shouldn't cause it to drop packets.  This is basically
  fatal to the way UHD does network I/O--since it uses UDP, with no 
retry mechanism (and, indeed, it's easy to see that at higher sample
  rates in particular, any TCP-like mechanism is going to cause 
heartburn for real-time flows).


If you do a:

lspci -v

It should show you what the Ethernet interface(s) are.

If this is a *server* motherboard, the underlying graphics subsystem 
may be just a framebuffer, in which case, your CPU is working really

  hard to render even simple graphics.




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Sorry, but forgot to answer the question re: real or virtual setup - I 
run real.


 Slainte,

John

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

Re: [Discuss-gnuradio] Getting one or more Ds after hours of running a GRC app on Ubuntu

[John Shields]

On 03/05/16 02:58, Marcus D. Leech wrote:

On 05/02/2016 10:40 PM, John Shields wrote:

Hi,
   I am using Ubunutu 14.04 LTS with GNURadio 3.7.9.1 and have a USRP 
N200 with SBXv3. I have been using the aptly-named and highly useful 
Simple_ra though I believe this is orthogonal to the issues I am seeing.


when I run simple_ra with :

 simple_ra  --srate 2e6 --freq 848e6 --gain 37 --dcg 1 --devid 
uhd=a,type=usrp2,addr=192.168.20.2,lo_offset=10e6,subdev=A:0 
--longitude 172.57027 --latitude -43.51944 --spde


the system runs along happily for several maybe even up to 20 odd 
hours but, as below, I start to see one or more Ds. In one run of 23 
hours, I had 10 Ds and eventually a segmentation fault - not sure if 
it is coincident with issuing of the final 'D'. Sometimes the D is 
not accompanied by UHD errors


here is the terminal output from the last run:

linux; GNU C++ version 4.8.4; Boost_105400; 
UHD_003.010.git-156-g2d68f228


Using Volk machine: avx_64_mmx_orc
gr-osmosdr v0.1.4-72-g164a09fc (0.1.5git) gnuradio 3.7.9.1
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf 
rfspace airspy redpitaya

-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
-- Detecting internal GPSDO Found an internal GPSDO
-- Setting references to the internal GPSDO
-- Using subdev spec 'A:0'.
-- Using LO offset of 1e+07 Hz.
WARNING: Overriding original sample rate of 1e+07 with 2e+06
-- Loaded /home/john/.uhd/cal/rx_iq_cal_v0.2_E2R10Z1XS.csv
D
UHD Error:
Control packet attempt 0, sequence number 10594:
RuntimeError: no control response, possible packet loss

UHD Error:
Control packet attempt 1, sequence number 10595:
RuntimeError: no control response, possible packet loss

UHD Error:
Control packet attempt 2, sequence number 10596:
RuntimeError: no control response, possible packet loss

UHD Error:
An unexpected exception was caught in a task loop.
The task loop will now exit, things may not work.
RuntimeError: link dead: timeout waiting for control packet ACK
Terminated


I have a fairly powerful cpu Intel® Core™ i7-2600 CPU @ 3.40GHz × 8, 
15.6 GiB of memory and run 64-bit os and have the USRP on it's own 
subnet and NIC.

Apart from setting:
net.core.rmem_max = 5000
net.core.wmem_max = 1048576

I have not 'tuned' any os settings. When the application is running, 
the 8 cores are between 40-50% utilised.


When I restart simple_ra after the error, it runs again fine until it 
hits an issue n-hours in the future.


Any ideas of how I can narrow down the cause of this?

  Kind Regards,

   John




Do you happen to know what kind of NIC you have?

Also, 2MSPS should not be chewing up much of your CPU--what kind of 
graphics card do you have?  Is this a real, or virtual, machine setup?


There Intel 82579LM is known for dropping packets under certain 
circumstances that shouldn't cause it to drop packets.  This is basically
  fatal to the way UHD does network I/O--since it uses UDP, with no 
retry mechanism (and, indeed, it's easy to see that at higher sample
  rates in particular, any TCP-like mechanism is going to cause 
heartburn for real-time flows).


If you do a:

lspci -v

It should show you what the Ethernet interface(s) are.

If this is a *server* motherboard, the underlying graphics subsystem 
may be just a framebuffer, in which case, your CPU is working really

  hard to render even simple graphics.




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

Thanks very much, as always, Marcus.

To the NICs : the command gave the following (edited to remove USB, IDE 
etc.)


00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core 
Processor Family Integrated Graphics Controller (rev 09) (prog-if 00 
[VGA controller])

Subsystem: Gigabyte Technology Co., Ltd Device d000
Flags: bus master, fast devsel, latency 0, IRQ 47
Memory at f740 (64-bit, non-prefetchable) [size=4M]
Memory at e000 (64-bit, prefetchable) [size=256M]
I/O ports at f000 [size=64]
Expansion ROM at  [disabled]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [d0] Power Management version 2
Capabilities: [a4] PCI Advanced Features
Kernel driver in use: i915

02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 01)
Subsystem: Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express 
Gigabit Ethernet controller

Flags: bus master, fast devsel, latency 0, IRQ 44
I/O ports at e000 [size=256]
Memory at f7b0 (64-bit, non-prefetchable) [size=4K]
Expansion ROM at dfb0 [disabled] [size=128K]
Capabilities: [40] Power Management version 2
Capabilities: [48] Vital Product Data
Capabilities: [50] MSI: Enable+