Re: [Discuss-gnuradio] Simulation with MAVLink protocol

[Andrew Davis]

Right, I've played with MAVlink before and as said it is not a wireless
standard, you can send it over hard link serial if you want. I'm assuming
your are sending the MAVlink over a pair of serial-RF adapters as is usual.

http://copter.ardupilot.com/wiki/common-using-the-3dr-radio-for-telemetry-with-apm-and-px4/

Seems to be what most use ( I have a pair of these as well ). If you look
at the technical section your can see they list FHSS GFSK as the
modulation. I would look into the datasheet for the chip for more details.
I would recommend just doing the RF demodulation in GNUradio and then send
the packets to an external program for further processing.

~Andrew


On Sat, Jun 28, 2014 at 8:06 AM, Andre Puschmann <
andre.puschm...@tu-ilmenau.de> wrote:

> Hey,
>
> I have the feeling that there maybe a misunderstanding about what
> MAVlink really is. The MAVlink protocol as such is serialization library
> that is used to transfer information, i.e. serialized data structures,
> between mobile and stationary devices rather than a whole "communication
> system". You can transfer MAVlink messages over any kind of transport
> system such as Wifi, bluetooth, Zigbee or any proprietary system.
> So what you probably want is to receive and decode the communication of
> that transfer system, maybe using GR, and then decode the actual payload
> with the MAVlink library.
>
> Cheers
> Andre
>
>
>
> On 28.06.2014 08:07, Marcus Müller wrote:
> > Hi!
> > Of course it would be helpful if you had a capture device if your
> > motivation was to capture signals of a system. Also, it will give you
> > something to test your reception algorithms on.
> > Greetings,
> > Marcus
> >
> > On June 28, 2014 6:18:36 AM CEST, Paulo Roberto
> >  wrote:
> >
> > Hello Marcus, thanks for your answer.
> > I have another question, if I have a sdr device like BladeRF or
> > HackRF, I will capture the signals without the need of simulating.
> > But I will need to decode received signals (what it's not a good
> > task), am I correct? In other words, would help me to have the sdr
> > device?
> >
> > Thank you so much.
> >
> > Paulo.
> >
> >
> 
> > Date: Sat, 28 Jun 2014 02:52:58 +0200
> > From: marcus.muel...@ettus.com
> > To: discuss-gnuradio@gnu.org
> > Subject: Re: [Discuss-gnuradio] Simulation with MAVLink protocol
> >
> > Hi Paulo,
> >
> > GNU Radio gives you but the framework to write and connect signal
> > processing blocks, as well as a nice set of "standard" blocks.
> > Among the functionalities available there are means to generate
> > packets and process the same.
> > If you know that if you can capture the signal, you could
> > mathematically/algorithmically analyze it, it's basically possible
> > to implement this in GNU Radio.
> > That being said, it's not really easy to implement a complete
> > packeted standard in GNU Radio since that might be a "logically"
> > complex task, involving different modulations, synchronization,
> > collision detection, arbitration, resend requests and much more.
> > However, there are several examples of people being able to decode
> > received signals. I like to point gr-ieee802-11 (WLAN packets
> > *transceiver*), and for a "simpler" system gr-air-modes (air traffic
> > control message decoding).
> >
> > Greetings,
> > Marcus
> > On 27.06.2014 23:12, Paulo Roberto wrote:
> >
> > Hello, I have some needs and I'd like to know if GnuRadio can
> help me with it. I have already read some material at GR website and I
> didn't get the answer.I need to receive and send packets with a specific
> protocol called MAVLink, used in mini UAVs. More specifically I am thinking
> about developing a sniffer.I don't have sdr hardware for now, then for
> starting I am thinking on simulation. My doubts are as follows:
> > - Is it possible to implement a new protocol for sending and
> receive packets? (MAVLink protocol)
> > - My idea is to simulate the exchange between a UAV and a
> control ground station. Would it possible to do it?
> > Thanks in advance.
> >
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org 
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> >
> >
> > ___ Discuss-gnuradio
> > mailing list Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> >
> > --
> > Sent from my Android device with K-9 Mail. Please excuse my brevity.
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
>
>
>
> __

Re: [Discuss-gnuradio] GNURADIO QUESTIONS

[Andrew Davis]

> May be there are ways to generate a standalone executable.

I do this on windows, if you are looking to distribute binaries then
re-write the python flow-graph in C++, then compile and you will get a
portable binary exe, if the other system does not have Gnuradio then just
include the gnuradio*.dll's with it. Follow the windows native CMake build
guide to generate those. If you want to stay in linux then it will be
libgnuradio-*.so's.

>Last, Is it possible to estimate the execution time of a specific block in
a gnuradio flow graph?

You can look into 'gnuradio performance counters'.


On Mon, Jul 7, 2014 at 6:25 AM, Manu T S  wrote:

>
>
>
> On Mon, Jul 7, 2014 at 3:16 PM, Simone Ciccia S210664 <
> simone.cic...@studenti.polito.it> wrote:
>
>> Goodmorning,
>> I'm a PhD student working with gnuradio in ubuntu.
>> The motivation for which I need to write is regarded to how gnuradio
>> treats
>> a project flow graph to make it as an application program, I have searched
>> over internet and various forum but I have not find nothing.
>>
>> Consider that I have a gnuradio flow graph that works fine, and also, I
>> have the top_block.py that works fine, when imparting ./top_block.py from
>> the terminal.
>>
>> My questions:
>>
>> Is "top_block.py" my final application program? ( for example, is the
>> executable ".exe" file equivalent in windows )
>>
>> I would use this file as an independent program, running it in an other pc
>> where gnuradio is not installed, is it possible? or Have I need some tools
>> ( for example, at least python installed ).
>>
>
> I am not aware of the exact answer to your question. Here is what I think.
>
> Since the top_block.py is a python program it will require at least python
> interpreter. When you run top_block.py, it usually imports modules from GNU
> Radio. So if you run it on a machine without GNU Radio installed, python
> will complain saying that it can not import modules required for your
> application.
>
> May be there are ways to generate a standalone executable. But the
> top_block.py is not a standalone executable. I hope someone out there knows
> a better answer to your question.
>
>
>> Last, Is it possible to estimate the execution time of a specific block in
>> a gnuradio flow graph?
>>
>>
>> If there are documentation that I have missed in the net, please give me
>> the reference...
>> I think for you these are simple questions, but I'm at the beginning and
>> gnuradio is a beautiful environment, I will learn!
>>
>> Thank you for your help in advance,
>>
>>
>> Sincerely,
>> Simone Ciccia,
>> PhD student,
>> electronic engineering,
>> Antenna and EMC lab,
>> Politechnic of Turin, Italy
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
> Regards
> --
> Manu T S
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GNU Radio Companion v3.7.0-1-g2c05acc1 python name-spaces not working

[Andrew Davis]

Hello all,

I'm using Xubuntu 13.04 and compiled from 3.7git, when I try to run GRC
almost any block that uses constants from the updates name-spaces GRC fails
with:

> Value "firdes.WIN_HAMMING" cannot be evaluated:
> name 'firdes' is not defined

or for signal source and related:

> Value "analog.GR_SIN_WAVE" cannot be evaluated:
> name 'analog' is not defined

I'm not sure where in GRC these are defined but I will continue to look for
a fix.

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

Re: [Discuss-gnuradio] GNU Radio Companion v3.7.0-1-g2c05acc1 python name-spaces not working

[Andrew Davis]

Thanks for the suggestion, I removed every trace of GNU Radio off this
machine and re-installed, it did not fix the problem. After further
investigation the problem appears to be related to another problem I have
been having, when I would run any block using filters I would get:

> ImportError: /usr/lib/libgnuradio-filter-3.7.1git.so.0.0.0: undefined
symbol: volk_32f_x2_dot_prod_16i_a

And now when I manual pull in 'analog' in python I get:

> ImportError: /usr/lib/libgnuradio-blocks-3.7.1git.so.0.0.0: undefined
symbol: volk_64u_byteswap_u

So this link problem is what is keeping 'analog' undefined.

When I run 'readelf -d /usr/lib/libgnuradio-filter-3.7.1git.so.0.0.0' I get:

> 0x0001 (NEEDED) Shared library: [libvolk.so.0.0.0]

So I think It is being linked, and when I run 'nm -D
/usr/lib/libvolk.so.0.0.0' I get:

> 002d69f0 D volk_32f_x2_dot_prod_16i
> 002d6a10 D volk_32f_x2_dot_prod_16i_a   <---
> 00042130 T volk_32f_x2_dot_prod_16i_get_func_desc

So I think libvolk exports it ( although i'm not sure why the 'D' is there
).

What else could I check to see why VOLK functions are not getting linked?

Thank you
-Andrew

On Thu, Jul 4, 2013 at 5:17 PM, Stephen Harrison
wrote:

> I had the same problem, but realized I was using the GRC .xml definitions
> from the previous version (in /usr/local/share/gnuradio/blocks).
>
>
> On Thu, Jul 4, 2013 at 2:12 PM, Tom Rondeau  wrote:
>
>> On Thu, Jul 4, 2013 at 4:58 PM, Andrew Davis 
>> wrote:
>> > Hello all,
>> >
>> > I'm using Xubuntu 13.04 and compiled from 3.7git, when I try to run GRC
>> > almost any block that uses constants from the updates name-spaces GRC
>> fails
>> > with:
>> >
>> >> Value "firdes.WIN_HAMMING" cannot be evaluated:
>> >> name 'firdes' is not defined
>> >
>> > or for signal source and related:
>> >
>> >> Value "analog.GR_SIN_WAVE" cannot be evaluated:
>> >> name 'analog' is not defined
>> >
>> > I'm not sure where in GRC these are defined but I will continue to look
>> for
>> > a fix.
>> >
>> > Thank you
>> > ~Andrew
>>
>> Have you removed all other GNU Radio versions from your machine?
>>
>> Also, if these are your own GRC files, might just try typing it in
>> again as the state might be a bit confused after an update.
>>
>> The specific cases you've mentioned have been tested for in the 3.7
>> release, so I think it's something local and/or a confusion after an
>> upgrade (the latter are bound to happen).
>>
>> Tom
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU Radio Companion v3.7.0-1-g2c05acc1 python name-spaces not working

[Andrew Davis]

OK, it appears a previous install hid an extra libvolk in
/usr/lib/x86_64-linux-gnu, removing that everything is working well so far,
thank you for the help everyone.

-Andrew


On Sun, Jul 7, 2013 at 4:12 AM, Tom Rondeau  wrote:

> On Fri, Jul 5, 2013 at 6:31 PM, Andrew Davis 
> wrote:
> > Thanks for the suggestion, I removed every trace of GNU Radio off this
> > machine and re-installed, it did not fix the problem. After further
> > investigation the problem appears to be related to another problem I have
> > been having, when I would run any block using filters I would get:
> >
> >> ImportError: /usr/lib/libgnuradio-filter-3.7.1git.so.0.0.0: undefined
> >> symbol: volk_32f_x2_dot_prod_16i_a
> >
> > And now when I manual pull in 'analog' in python I get:
> >
> >> ImportError: /usr/lib/libgnuradio-blocks-3.7.1git.so.0.0.0: undefined
> >> symbol: volk_64u_byteswap_u
> >
> > So this link problem is what is keeping 'analog' undefined.
> >
> > When I run 'readelf -d /usr/lib/libgnuradio-filter-3.7.1git.so.0.0.0' I
> get:
> >
> >> 0x0001 (NEEDED) Shared library: [libvolk.so.0.0.0]
> >
> > So I think It is being linked, and when I run 'nm -D
> > /usr/lib/libvolk.so.0.0.0' I get:
> >
> >> 002d69f0 D volk_32f_x2_dot_prod_16i
> >> 002d6a10 D volk_32f_x2_dot_prod_16i_a   <---
> >> 00042130 T volk_32f_x2_dot_prod_16i_get_func_desc
> >
> > So I think libvolk exports it ( although i'm not sure why the 'D' is
> there
> > ).
> >
> > What else could I check to see why VOLK functions are not getting linked?
> >
> > Thank you
> > -Andrew
>
> Ok, that clears up the import error. Have you just tried running
> 'ldconfig' to see if that fixes your linking problems?
>
> Tom
>
>
> > On Thu, Jul 4, 2013 at 5:17 PM, Stephen Harrison <
> msteveharri...@gmail.com>
> > wrote:
> >>
> >> I had the same problem, but realized I was using the GRC .xml
> definitions
> >> from the previous version (in /usr/local/share/gnuradio/blocks).
> >>
> >>
> >> On Thu, Jul 4, 2013 at 2:12 PM, Tom Rondeau  wrote:
> >>>
> >>> On Thu, Jul 4, 2013 at 4:58 PM, Andrew Davis 
> >>> wrote:
> >>> > Hello all,
> >>> >
> >>> > I'm using Xubuntu 13.04 and compiled from 3.7git, when I try to run
> GRC
> >>> > almost any block that uses constants from the updates name-spaces GRC
> >>> > fails
> >>> > with:
> >>> >
> >>> >> Value "firdes.WIN_HAMMING" cannot be evaluated:
> >>> >> name 'firdes' is not defined
> >>> >
> >>> > or for signal source and related:
> >>> >
> >>> >> Value "analog.GR_SIN_WAVE" cannot be evaluated:
> >>> >> name 'analog' is not defined
> >>> >
> >>> > I'm not sure where in GRC these are defined but I will continue to
> look
> >>> > for
> >>> > a fix.
> >>> >
> >>> > Thank you
> >>> > ~Andrew
> >>>
> >>> Have you removed all other GNU Radio versions from your machine?
> >>>
> >>> Also, if these are your own GRC files, might just try typing it in
> >>> again as the state might be a bit confused after an update.
> >>>
> >>> The specific cases you've mentioned have been tested for in the 3.7
> >>> release, so I think it's something local and/or a confusion after an
> >>> upgrade (the latter are bound to happen).
> >>>
> >>> Tom
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Inverted spectrum

[Andrew Davis]

Hello all,

When using pll_carriertracking_cc, the returned spectrum seems to be
inverted about 0MHz, when looking though the code line 113 of
gr-analog/lib/pll_carriertracking_cc_impl.cc
looked odd:

> optr[i] = iptr[i] * gr_complex(t_real, -t_imag);

could someone explain why the the imaginary component of the NCO is
inverted?

Thank you all,
Andrew
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] ATSC fixups

[Andrew Davis]

Hello all,

I have been working on getting gr-atsc running again, I have found a few
speedups and some bugs that prevented ATSC decoding from working with new
versions of GNURadio. I have put these fixes into a branch that can now
decode signals from my local TV station. The changes are in commit in this
branch: https://github.com/glneo/gnuradio/tree/atscfixup

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

Re: [Discuss-gnuradio] ATSC fixups

[Andrew Davis]

Sure:

- first the description is correct and not just copied from interp_short.py
- removed the writing to 'atsc_complex.data' as this uses a lot of space
and seems to have no meaning outside of debugging
- I use interleave_short_to_complex instead of s2s -> s2f -> f2c chain
- lp_coeffs and duc_coeffs uses input_rate instead of just the number,
should make changing it easier
- lp_coeffs no longer arbitrarily adds 3 gain
- duc now shifts the frequency in the correct direction
- the root raised cosine filter taps no longer need to be heterodyned into
place as I just use it at baseband
- the root raised cosine filer gets used now ( for some reason it was not
in the chain before and this was severely causing ISI )
- lower_edge and upper_edge seemed arbitrary and were not in the right spot
anyway

After this stuff and the reorganization a simple diff would not have saved
much,
also i'm working on 'atsc_tx.py',so 'all_atsc.py' would be confusing, hence
the name change.

Also the other scripts seem unnecessary with the new thread-per-block
sceduler, the also seem to cause
a lot of beginners confusion. So I felt they needed to go.

I have also built a ( semi ) working complex fpll for gr-atsc, this removes
the need for up-converting and the filtering
after the current fpll, my next atsc_rx will need the new script style.
After I finish updating the bit timing loop
we will be almost real time I believe!

P.S. I could still just do the diff to the old all_atsc.py and rename if
you want.

Thank you
Andrew


On Mon, Jul 15, 2013 at 6:52 PM, Johnathan Corgan
wrote:

> On Sun, Jul 14, 2013 at 12:03 PM, Andrew Davis wrote:
>
>
>> I have been working on getting gr-atsc running again, I have found a few
>> speedups and some bugs that prevented ATSC decoding from working with new
>> versions of GNURadio. I have put these fixes into a branch that can now
>> decode signals from my local TV station. The changes are in commit in this
>> branch: https://github.com/glneo/gnuradio/tree/atscfixup
>>
>
> Andrew, can you detail the difference in implementation between the
> atsc_rx.py file you added and the all_atsc.py file that was there already?
>
> --
> Johnathan Corgan
> Corgan Labs - SDR Training and Development Services
> http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Low cost SDR hardware

[Andrew Davis]

Hello,

For just teaching even a speaker and microphone work well to add real world
effects like AWGN, echos, delays, and Doppler effects on communication
channels. Does everyone need a transmitter? Over here we have just one USRP
and a whole lot of RTLSDR's so everyone can practice receiving and
demodulating real signals from outside sources and when needed signals
generated in lab.

Andrew


On Tue, Jul 30, 2013 at 8:42 AM, Brian Padalino  wrote:

> Hi Manu,
>
> What is your output power requirement?  Frequency coverage?  Do you have a
> target price?  Do you have LO phase coherency requirements?
>
> Support for nuand's bladeRF was just recently pushed to gr-osmosdr for
> both GNU Radio 3.6 and 3.7.  The output power is 6dBm CW, so with some
> backoff for linearity and PAPR on your transmission signal, you're probably
> at -6dBm or so for transmission.  Harmonic filtering is required if you
> plan to hook it up to an antenna.  The frequency coverage is from 300MHz -
> 3.8GHz and costs $420/board.
>
> More information can be found here:
>
>   http://nuand.com
>
> Feel free to e-mail me directly off list if you'd like to discuss more.
>
> Brian
>
> Full disclosure: I'm involved with nuand and bladeRF.
>
>
>
> On Tue, Jul 30, 2013 at 12:25 AM, Manu T S  wrote:
>
>> Hello everyone,
>>
>> A professor in my university wants to revive lab course on communication.
>> He wants to introduce some experiments involving SDR. For that we need
>> about 100 pieces of hardware( both receiver and transmitter). Buying 100
>> USRP is not a viable solution for us. We can go for RTL SDR but it has only
>> transmitter. Does anyone know of a good solution for low cost hardware,
>> (transmitter + receiver or just transmitter) preferably GNU Radio
>> compatible, that we could opt for?
>>
>> --
>> Manu T S
>>
>> ___
>> 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] ATSC Magic coupling constant

[Andrew Davis]

Hello all,

I'm working on fixing up gr-atsc and I have been working on a little
problem for a while now, there is a constant ( FPLL_BTLOOP_COUPLING_CONST )
that sets the reference for an AGC, the value is ( 2.5 * 3.125 ) and is
literally defined as "Magic", so it seems to be a value that "just works".
With that value the AGC filters the real input and then this is multiplied
by a NCO part of a PLL. This puts the value of the +/- 5 timing sync levels
at about +/- 5. The problem is when I pass samples though the AGC and then
do 'complex' multiplication on them the +/- 5 values end up at about +/- 7.
I'm not sure why but it seems like the values coming out of the complex
multiply are not the same as the real multiply. The original code is:

nco.sincos (&a_sin, &a_cos);  // compute cos and sin
float I = input * a_sin;
float Q = input * a_cos;

My code is:

nco.sincos (&a_sin, &a_cos); // compute cos and sin
gr_complex result = (gr_complex(input_real, input_imag) * gr_complex(a_cos,
a_sin));
float I = result.real();
float Q = result.imag();

I is larger in my version and so the equalizer and slicer fail downstream.
I built a coherent AGC into the sync timing loop but it still fails with
large gain differences.

My question is whether there is anyone around who worked on gr-atsc who
could give me a hint as to how the "Magic coupling constant" was derived in
the first place so I can build a new one so I don't have to rebuild the
equilizer.

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

Re: [Discuss-gnuradio] ATSC Magic coupling constant

[Andrew Davis]

The filter doesn't seem to decrease the pass-band signal, also I've tried
adding back the unneeded filter just to be sure and it doesn't change
anything. I will try the off by sqrt(2), that might put me back in range.
Also my NCO is the same in both cases and I believe it is normalized to 1.

The ATSC signal randomly changes between +/- 1,3,5,7 so the average power
should be 4 and when using this as the reference this puts my signal were
it should be and at the same level as the old code with the average power
set to 7.8125 ( written in code as 2.5 * 3.125 for some reason ) yet it
still must be off by just enough to mess up the slicer in the viterbi but
not the equalizer as it locks on correctly ( it is very finicky ).

Thanks for the idea, I will try it tomorrow when I get back to the test
machine ( which is powerful enough to be within reach of real-time decoding
if I get this figured out :)
Andrew


On Tue, Jul 30, 2013 at 6:19 PM, Brian Padalino  wrote:

> On Tue, Jul 30, 2013 at 5:55 PM, Andrew Davis wrote:
>
>> Hello all,
>>
>> I'm working on fixing up gr-atsc and I have been working on a little
>> problem for a while now, there is a constant ( FPLL_BTLOOP_COUPLING_CONST )
>> that sets the reference for an AGC, the value is ( 2.5 * 3.125 ) and is
>> literally defined as "Magic", so it seems to be a value that "just works".
>> With that value the AGC filters the real input and then this is multiplied
>> by a NCO part of a PLL. This puts the value of the +/- 5 timing sync levels
>> at about +/- 5. The problem is when I pass samples though the AGC and then
>> do 'complex' multiplication on them the +/- 5 values end up at about +/- 7.
>> I'm not sure why but it seems like the values coming out of the complex
>> multiply are not the same as the real multiply. The original code is:
>>
>> nco.sincos (&a_sin, &a_cos);  // compute cos and sin
>> float I = input * a_sin;
>> float Q = input * a_cos;
>>
>> My code is:
>>
>> nco.sincos (&a_sin, &a_cos); // compute cos and sin
>> gr_complex result = (gr_complex(input_real, input_imag) *
>> gr_complex(a_cos, a_sin));
>> float I = result.real();
>> float Q = result.imag();
>>
>> I is larger in my version and so the equalizer and slicer fail
>> downstream. I built a coherent AGC into the sync timing loop but it still
>> fails with large gain differences.
>>
>> My question is whether there is anyone around who worked on gr-atsc who
>> could give me a hint as to how the "Magic coupling constant" was derived in
>> the first place so I can build a new one so I don't have to rebuild the
>> equilizer.
>>
>
> I can't help you with your MAGIC, but if you say the real signal is mixed
> then filtered in the original code that works, whereas it is just mixed
> with your code - maybe it's just off by a sqrt(2) since you're filtering
> off your image after the NCO happens and losing 1/2 power?
>
> I did notice that sqrt(2)*5 = 7 - so maybe making your NCO a little less
> powerful might bring you to the correct power levels since I am assuming
> you aren't filtering in your chain since there is no image to filter out?
>
> Brian
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] ATSC Magic coupling constant

[Andrew Davis]

Ok, I tried the off by sqrt(2) and it put me close but now the bit_timing
_loop is running short on data again, which as a disseminator means it
probably cant find a good sync for timing and just eats all its input
samples. So I pushed my changes to where i'm at now to github, could you
see if that compiles for you, then I could walk you though whats all going
on with this and where i'm at.

Thank you
Andrew


On Tue, Jul 30, 2013 at 8:12 PM, Johnathan Corgan
wrote:

> On 07/30/2013 04:28 PM, Andrew Davis wrote:
>
> > Thanks for the idea, I will try it tomorrow when I get back to the test
> > machine ( which is powerful enough to be within reach of real-time
> > decoding if I get this figured out :)
>
> If you don't get this straightened out, I'd be happy to work with you by
> phone or chat.
>
> --
> Johnathan Corgan, Corgan Labs
> SDR Training and Development Services
> http://corganlabs.com
> Visit us at GRCON13 Oct. 1-4 http://ow.ly/ntmpL
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] ATSC Magic coupling constant

[Andrew Davis]

Hello All,

Just an update for those following along, I have ( somewhat ) finished the
ATSC transmitter, most of the blocks needed were all ready made, but they
stopped right before pilot insertion and VSB modulation ( my guess is since
the hardware back then was receive only they stopped there ), so I added
the needed blocks, and transmitted with my USRP1 to a television. It is
much faster than real time and so i'm trying to encode and transmit my
webcam live but i'm still working on getting gstreamer to output the
correct stream :)

Also the receiver is coming along but i'm still stuck with the magic
constant. I have a nice sample data recording from my USRP of my local TV
station, it is just above the threshold for decent recovery and so should
be good for testing improvements the the receiver. Would anyone like this
sample for testing?

Thank you all
Andrew


On Wed, Jul 31, 2013 at 5:00 PM, Andrew Davis wrote:

> Ok, I tried the off by sqrt(2) and it put me close but now the bit_timing
> _loop is running short on data again, which as a disseminator means it
> probably cant find a good sync for timing and just eats all its input
> samples. So I pushed my changes to where i'm at now to github, could you
> see if that compiles for you, then I could walk you though whats all going
> on with this and where i'm at.
>
> Thank you
> Andrew
>
>
> On Tue, Jul 30, 2013 at 8:12 PM, Johnathan Corgan <
> johnat...@corganlabs.com> wrote:
>
>> On 07/30/2013 04:28 PM, Andrew Davis wrote:
>>
>> > Thanks for the idea, I will try it tomorrow when I get back to the test
>> > machine ( which is powerful enough to be within reach of real-time
>> > decoding if I get this figured out :)
>>
>> If you don't get this straightened out, I'd be happy to work with you by
>> phone or chat.
>>
>> --
>> Johnathan Corgan, Corgan Labs
>> SDR Training and Development Services
>> http://corganlabs.com
>> Visit us at GRCON13 Oct. 1-4 http://ow.ly/ntmpL
>>
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] ATSC fixups

[Andrew Davis]

It was removed and left in fpll.h, i'll push a fix in just a bit, in
the meantime you could just remove the include line from fpll.h

Thank you
Andrew


On Mon, Aug 5, 2013 at 1:46 PM, M. Ranganathan  wrote:

> Hello,
>
> I git cloned the atscfixup branch and tried building it. Here's as far as
> I got:
>
> In file included from
> /users/mranga/gr-atscfixup/gnuradio/gr-atsc/lib/receiver/atsc_fpll.cc:27:
> /users/mranga/gr-atscfixup/gnuradio/gr-atsc/include/gnuradio/atsc/fpll.h:32:44:
> error: gnuradio/atsc/diag_output_impl.h: No such file or directory
>
> Perhaps this file was accidentally left out of the repository (?)
>
> Ranga
>
>
>
>
>
> On Mon, Jul 15, 2013 at 10:56 PM, Johnathan Corgan <
> johnat...@corganlabs.com> wrote:
>
>> On 07/15/2013 07:01 PM, Andrew Davis wrote:
>>
>> > After this stuff and the reorganization a simple diff would not have
>> > saved much, also i'm working on 'atsc_tx.py',so 'all_atsc.py' would
>> > be confusing, hence the name change.
>>
>> First, let me say that I'm very happy this code is getting some
>> attention. It was originally written to use the low-IF output of a TV
>> tuner and ADC, and also when GNU Radio only had a single-threaded
>> scheduler.  Later, it was only minimally modified to use the USRP
>> complex baseband IQ output. (I wasn't around GNU Radio at the time and
>> the above is only what I surmise by looking at the code history.)
>>
>> The changes you describe are more like it would have been written had
>> the USRP existed at the time.
>>
>> The all_atsc.py file was a work-in-progress effort by Ben Reynwar that I
>> merged in, but he and I never finished what we were going to do with it.
>>
>> > Also the other scripts seem unnecessary with the new
>> > thread-per-block sceduler, the also seem to cause a lot of beginners
>> > confusion. So I felt they needed to go.
>>
>> Agree.
>>
>> > I have also built a ( semi ) working complex fpll for gr-atsc, this
>> > removes the need for up-converting and the filtering after the
>> > current fpll, my next atsc_rx will need the new script style. After I
>> > finish updating the bit timing loop we will be almost real time I
>> > believe!
>>
>> The upconversion and filtering is a large CPU waste when it could be
>> done at baseband, but it seems this was just a quick-and-dirty way to
>> get the baseband IQ from a USRP to look like a low-IF output instead in
>> order to re-use what was already written and working.
>>
>> Real-time execution would be a welcome accomplishment!
>>
>> > P.S. I could still just do the diff to the old all_atsc.py and rename
>> > if you want.
>>
>> No need.
>>
>> By the way, before any of this can be merged, we'll need a copyright
>> assignment from you.  I'll email you off-list about how this works.
>>
>> Thanks again for working on this.
>>
>> --
>> Johnathan Corgan
>> Corgan Labs - SDR Training and Development Services
>> http://corganlabs.com
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
>
> --
> M. Ranganathan
>
> ___
> 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] ATSC fixups

[Andrew Davis]

OK, pushed, could you see if that works better?

Thank you
Andrew


On Mon, Aug 5, 2013 at 2:50 PM, Andrew Davis wrote:

> It was removed and left in fpll.h, i'll push a fix in just a bit, in
> the meantime you could just remove the include line from fpll.h
>
> Thank you
> Andrew
>
>
> On Mon, Aug 5, 2013 at 1:46 PM, M. Ranganathan  wrote:
>
>> Hello,
>>
>> I git cloned the atscfixup branch and tried building it. Here's as far as
>> I got:
>>
>> In file included from
>> /users/mranga/gr-atscfixup/gnuradio/gr-atsc/lib/receiver/atsc_fpll.cc:27:
>> /users/mranga/gr-atscfixup/gnuradio/gr-atsc/include/gnuradio/atsc/fpll.h:32:44:
>> error: gnuradio/atsc/diag_output_impl.h: No such file or directory
>>
>> Perhaps this file was accidentally left out of the repository (?)
>>
>> Ranga
>>
>>
>>
>>
>>
>> On Mon, Jul 15, 2013 at 10:56 PM, Johnathan Corgan <
>> johnat...@corganlabs.com> wrote:
>>
>>> On 07/15/2013 07:01 PM, Andrew Davis wrote:
>>>
>>> > After this stuff and the reorganization a simple diff would not have
>>> > saved much, also i'm working on 'atsc_tx.py',so 'all_atsc.py' would
>>> > be confusing, hence the name change.
>>>
>>> First, let me say that I'm very happy this code is getting some
>>> attention. It was originally written to use the low-IF output of a TV
>>> tuner and ADC, and also when GNU Radio only had a single-threaded
>>> scheduler.  Later, it was only minimally modified to use the USRP
>>> complex baseband IQ output. (I wasn't around GNU Radio at the time and
>>> the above is only what I surmise by looking at the code history.)
>>>
>>> The changes you describe are more like it would have been written had
>>> the USRP existed at the time.
>>>
>>> The all_atsc.py file was a work-in-progress effort by Ben Reynwar that I
>>> merged in, but he and I never finished what we were going to do with it.
>>>
>>> > Also the other scripts seem unnecessary with the new
>>> > thread-per-block sceduler, the also seem to cause a lot of beginners
>>> > confusion. So I felt they needed to go.
>>>
>>> Agree.
>>>
>>> > I have also built a ( semi ) working complex fpll for gr-atsc, this
>>> > removes the need for up-converting and the filtering after the
>>> > current fpll, my next atsc_rx will need the new script style. After I
>>> > finish updating the bit timing loop we will be almost real time I
>>> > believe!
>>>
>>> The upconversion and filtering is a large CPU waste when it could be
>>> done at baseband, but it seems this was just a quick-and-dirty way to
>>> get the baseband IQ from a USRP to look like a low-IF output instead in
>>> order to re-use what was already written and working.
>>>
>>> Real-time execution would be a welcome accomplishment!
>>>
>>> > P.S. I could still just do the diff to the old all_atsc.py and rename
>>> > if you want.
>>>
>>> No need.
>>>
>>> By the way, before any of this can be merged, we'll need a copyright
>>> assignment from you.  I'll email you off-list about how this works.
>>>
>>> Thanks again for working on this.
>>>
>>> --
>>> Johnathan Corgan
>>> Corgan Labs - SDR Training and Development Services
>>> http://corganlabs.com
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>
>>
>> --
>> M. Ranganathan
>>
>> ___
>> 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] ATSC fixups

[Andrew Davis]

Yeah, That doesn't seem to be anything I messed with, anyway I pushed
another commit that if compiles for everyone could be merged into the
Gnuradio master. I found that the "Magic coupling constant" isn't so magic
and can be complexly removed and replaced with an AGC block set to a
reference level of 4 ( the mean value of the pseudo-random 1 3 5 7 levels
of the ATSC PAM signal ). So I separated that out of the fpll block. For
some reason I simply cannot make a complex PLL that works the same way the
old PLL works, I get close but i'm still missing something, once I get that
figured out it will shave off approximately 12% from the decoding time (
thanks to the new performance counters I can now easily track what my
fix-ups are doing and whats left before real-time decoding ).

Thanks you,
Andrew


On Wed, Aug 7, 2013 at 4:11 PM, Souryal, Michael
wrote:

>  I tried building this later push and this is as far as I got.
>
> ** **
>
> [ 70%] Building CXX object
> gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/TimeDomainDisplayPlot.cc.o
>
> /raid/souryal/gnuradio-atscfixup/gr-qtgui/lib/TimeDomainDisplayPlot.cc: In
> member function ‘void TimeDomainDisplayPlot::setSemilogy(bool)’:
>
> /raid/souryal/gnuradio-atscfixup/gr-qtgui/lib/TimeDomainDisplayPlot.cc:358:
> error: ‘class QwtScaleDiv’ has no member named ‘upperBound’
>
> make[2]: ***
> [gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/TimeDomainDisplayPlot.cc.o]
> Error 1
>
> make[1]: *** [gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/all] Error 2
>
> make: *** [all] Error 2
>
> ** **
>
> It doesn’t look related to ATSC, though.
>
> ** **
>
> *From:* discuss-gnuradio-bounces+souryal=nist@gnu.org [mailto:
> discuss-gnuradio-bounces+souryal=nist@gnu.org] *On Behalf Of *Andrew
> Davis
> *Sent:* Monday, August 05, 2013 3:37 PM
> *To:* M. Ranganathan
> *Cc:* GNURadio Discussion List
> *Subject:* Re: [Discuss-gnuradio] ATSC fixups
>
> ** **
>
> OK, pushed, could you see if that works better?
>
> ** **
>
> Thank you
>
> Andrew
>
> ** **
>
> On Mon, Aug 5, 2013 at 2:50 PM, Andrew Davis 
> wrote:
>
> It was removed and left in fpll.h, i'll push a fix in just a bit, in
> the meantime you could just remove the include line from fpll.h
>
> ** **
>
> Thank you
>
> Andrew
>
> ** **
>
> On Mon, Aug 5, 2013 at 1:46 PM, M. Ranganathan  wrote:**
> **
>
> Hello,
>
> I git cloned the atscfixup branch and tried building it. Here's as far as
> I got:
>
>
> In file included from
> /users/mranga/gr-atscfixup/gnuradio/gr-atsc/lib/receiver/atsc_fpll.cc:27:
> /users/mranga/gr-atscfixup/gnuradio/gr-atsc/include/gnuradio/atsc/fpll.h:32:44:
> error: gnuradio/atsc/diag_output_impl.h: No such file or directory
>
> Perhaps this file was accidentally left out of the repository (?)
>
> Ranga
>
>
>
> 
>
> ** **
>
> On Mon, Jul 15, 2013 at 10:56 PM, Johnathan Corgan <
> johnat...@corganlabs.com> wrote:
>
>   On 07/15/2013 07:01 PM, Andrew Davis wrote:
>
> > After this stuff and the reorganization a simple diff would not have
> > saved much, also i'm working on 'atsc_tx.py',so 'all_atsc.py' would
> > be confusing, hence the name change.
>
> First, let me say that I'm very happy this code is getting some
> attention. It was originally written to use the low-IF output of a TV
> tuner and ADC, and also when GNU Radio only had a single-threaded
> scheduler.  Later, it was only minimally modified to use the USRP
> complex baseband IQ output. (I wasn't around GNU Radio at the time and
> the above is only what I surmise by looking at the code history.)
>
> The changes you describe are more like it would have been written had
> the USRP existed at the time.
>
> The all_atsc.py file was a work-in-progress effort by Ben Reynwar that I
> merged in, but he and I never finished what we were going to do with it.**
> **
>
>
> > Also the other scripts seem unnecessary with the new
> > thread-per-block sceduler, the also seem to cause a lot of beginners
> > confusion. So I felt they needed to go.
>
> Agree.
>
>
> > I have also built a ( semi ) working complex fpll for gr-atsc, this
> > removes the need for up-converting and the filtering after the
> > current fpll, my next atsc_rx will need the new script style. After I
> > finish updating the bit timing loop we will be almost real time I
> > believe!
>
> The upconversion and filtering is a large CPU waste when it could be
> done at baseband, but it seems this was just a quick-and-dirty wa

Re: [Discuss-gnuradio] Xlate FIR filter broken in gr 3.7

[Andrew Davis]

It's not just you, I noticed this too. This change broke gr-atsc ( but I
fixed that ).
The problem is on line 80 of
gr-filter/lib/freq_xlating_fir_filter_XXX_impl.cc.t: the 2 was not negative
in 3.6 but is now, i'm not sure why.

Andrew


On Thu, Aug 8, 2013 at 12:16 PM, Stephen Harrison
wrote:

> Is it just me or did the polarity of the frequency offset in
> freq_xlating_fir_filter get reversed between 3.6 and 3.7?
>
>
>
>
> On Thu, Aug 8, 2013 at 6:04 AM, Anton Komarov wrote:
>
>> Who can help me to open a ticket?
>>
>>
>> On Wed, Aug 7, 2013 at 4:53 PM, Anton Komarov 
>> wrote:
>>
>>> Ok, but it is not clear for me how to open a ticket in gr bug tracker...
>>>
>>>
>>> On Wed, Aug 7, 2013 at 4:35 PM, Marcus Müller wrote:
>>>
  Yes, please attach it to your ticket.

 Am 07.08.2013 14:28, schrieb Anton Komarov:

 Marcus, am i supposed to share e.g. 10 seconds of captured spectrum so
 you can play with it on your side?


 On Wed, Aug 7, 2013 at 4:18 PM, Marcus Müller wrote:

>  Hi Anton,
> it is really hard to capture apco25 signals in Germany.
> Could you really open a ticket, attach a few captured samples saved
> using a file sink,
> and the 3.6 and 3.7 flowgraphs; or provide some kind of test case with
> GNU Radio Signal sources
> that simulate a signal. Be sure to attach screenshots of your
> waterfall plots.
> It is really hard to guess what goes  wrong otherwise.
>
> Greetings,
> Marcus
>
> Am 07.08.2013 13:56, schrieb Anton Komarov:
>
> Ok, i've attached very simple grc chart
> with slider you can change the frequency, two waterfalls shows
> spectrums before and after xlating.
> So i had test it in apco25 env and took apco signals as a reference.
> So when i saw signal e.g. at 451.378 MHz and tuned to it i saw no signal
> after xlating nevertheless it was the same time on waterfall before 
> xlating.
>
>  You can test this chart with you radio environment.
>
>  Then i testing the same logic with gr 3.6 (code is not compatible i
> have to redraw it..) and here it is! xlating worked like a charm.
>
>
> On Wed, Aug 7, 2013 at 1:48 PM, Martin Braun (CEL) <
> martin.br...@kit.edu> wrote:
>
>> On Wed, Aug 07, 2013 at 01:00:32PM +0400, Anton Komarov wrote:
>> > Hi, made an attempt to test my python scripts with new 3.7.0 of GR
>> >
>> > and what i am seeing xlate fir filter is broken
>> >
>> >
>> > previously xlate worked perfect with 3.6 version
>> >
>> >
>> > tested with waterfalls and i see wrong xlating
>> >
>> > i think developers should pay attention to this issue
>>
>>  Hi Anton,
>>
>> can you please elaborate on this bug. Ideally, could you post an issue
>> on our tracker: http://gnuradio.org/redmine/projects/gnuradio/issues
>>
>> Specify what you configured, what the expected outcome was and what
>> happened instead.
>>
>> Thanks,
>> MB
>>
>> --
>> Karlsruhe Institute of Technology (KIT)
>> Communications Engineering Lab (CEL)
>>
>> Dipl.-Ing. Martin Braun
>> Research Associate
>>
>> Kaiserstraße 12
>> Building 05.01
>> 76131 Karlsruhe
>>
>> Phone: +49 721 608-43790
>> Fax: +49 721 608-46071
>> www.cel.kit.edu
>>
>> KIT -- University of the State of Baden-Württemberg and
>> National Laboratory of the Helmholtz Association
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


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


>>>
>>
>> ___
>> 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] Xlate FIR filter broken in gr 3.7

[Andrew Davis]

Center frequency of the received signal or center where I want to move it
to? It's not intuitive ether way, the parameter name should be changed to
what it actually is: 'frequency_shift' and it should behave exactly like
multiplication does, you multiply a positive frequency you get a positive
shift, negative frequency, down shift by that much, simple.

Andrew


On Thu, Aug 8, 2013 at 3:45 PM, Tom Rondeau  wrote:

> On Thu, Aug 8, 2013 at 4:37 PM, Stephen Harrison
>  wrote:
> > I agree.. the new way is more intuitive but then again it broke a bunch
> of
> > my GRC patches.. :)
> >
> >
> > On Thu, Aug 8, 2013 at 1:36 PM, Sylvain Munaut <246...@gmail.com> wrote:
> >>
> >> Hi,
> >>
> >> > The "old style" version of the block in gnuradio-core in 3.6.5.1 works
> >> > correctly.  The "new style" version of the block in gr-filter in
> 3.6.5.1
> >> > has the sign change.  When all the old-style blocks were removed for
> >> > 3.7, this of course left only the changed one.
> >>
> >> Personally I always thought that the previous block (in 3.6) was
> >> "weird" because the parameter was named "Center freq" but you in fact
> >> had to give it the frequency shift you wanted. The new one behaves
> >> more like I expect.
> >>
> >> Cheers,
> >>
> >> Sylvain
>
> Yes, this change was made on purpose for exactly that reason. As
> Johnathan noted, the new block after the 3.7 API change had this new
> way of handling the parameter, but the old block didn't change (for
> API compatibility reasons). I think the new way is more intuitive as
> well since I, too, always messed it up myself. As Sylvain said, we
> called it 'center frequency' but it was being treated as the value
> used to actually shift the signal, not the center frequency of the
> channel.
>
> The real mistake here was not announcing this as a change in our 3.6 -
> 3.7 conversion document.
>
> --
> Tom
> Visit us at GRCon13 Oct. 1 - 4
> http://www.trondeau.com/grcon13
>
> ___
> 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] Xlate FIR filter broken in gr 3.7

[Andrew Davis]

Also, this change breaks a very important and very used part of hundreds of
projects over the last ten years to make a variable name make slightly more
since, when you could just change the variable name to 'frequency_shift'
and leave the functionality the way it was.

Andrew


On Thu, Aug 8, 2013 at 3:56 PM, Andrew Davis wrote:

> Center frequency of the received signal or center where I want to move it
> to? It's not intuitive ether way, the parameter name should be changed to
> what it actually is: 'frequency_shift' and it should behave exactly like
> multiplication does, you multiply a positive frequency you get a positive
> shift, negative frequency, down shift by that much, simple.
>
> Andrew
>
>
> On Thu, Aug 8, 2013 at 3:45 PM, Tom Rondeau  wrote:
>
>> On Thu, Aug 8, 2013 at 4:37 PM, Stephen Harrison
>>  wrote:
>> > I agree.. the new way is more intuitive but then again it broke a bunch
>> of
>> > my GRC patches.. :)
>> >
>> >
>> > On Thu, Aug 8, 2013 at 1:36 PM, Sylvain Munaut <246...@gmail.com>
>> wrote:
>> >>
>> >> Hi,
>> >>
>> >> > The "old style" version of the block in gnuradio-core in 3.6.5.1
>> works
>> >> > correctly.  The "new style" version of the block in gr-filter in
>> 3.6.5.1
>> >> > has the sign change.  When all the old-style blocks were removed for
>> >> > 3.7, this of course left only the changed one.
>> >>
>> >> Personally I always thought that the previous block (in 3.6) was
>> >> "weird" because the parameter was named "Center freq" but you in fact
>> >> had to give it the frequency shift you wanted. The new one behaves
>> >> more like I expect.
>> >>
>> >> Cheers,
>> >>
>> >> Sylvain
>>
>> Yes, this change was made on purpose for exactly that reason. As
>> Johnathan noted, the new block after the 3.7 API change had this new
>> way of handling the parameter, but the old block didn't change (for
>> API compatibility reasons). I think the new way is more intuitive as
>> well since I, too, always messed it up myself. As Sylvain said, we
>> called it 'center frequency' but it was being treated as the value
>> used to actually shift the signal, not the center frequency of the
>> channel.
>>
>> The real mistake here was not announcing this as a change in our 3.6 -
>> 3.7 conversion document.
>>
>> --
>> Tom
>> Visit us at GRCon13 Oct. 1 - 4
>> http://www.trondeau.com/grcon13
>>
>> ___
>> 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] Xlate FIR filter broken in gr 3.7

[Andrew Davis]

> "center_frequency" /always/ refers to the frequency of the incoming
signal.

So what if i'm transmitting, or just "shifting" a signal "frequency" for
another reason?

I understand that "center freq" maybe should mean what you think it does,
but wouldn't it make more sense to change the internal parameter name to
one that makes more intuitive sense instead of changing the whole block
functionality and breaking backwards compatibility just to match the
internal variable's name?

Google "freq xlating fir filter" you can see just how many papers,
projects, videos, tutorials, etc.. will need to be fixed less
they cause more confusion and no one can figure out which way it works.

If your decision is firm, we need to at least fix the internal Gnuradio
demo apps that may need fixed or their tuning sliders reversed.

Sorry if this post sounded like a rant ( API breaks bug me :) )

Thank you for you consideration,
Andrew


On Thu, Aug 8, 2013 at 5:46 PM, Tom Rondeau  wrote:

> On Thu, Aug 8, 2013 at 5:51 PM, Marcus D. Leech  wrote:
> > On 08/08/2013 05:01 PM, Andrew Davis wrote:
> >
> > Also, this change breaks a very important and very used part of hundreds
> of
> > projects over the last ten years to make a variable name make slightly
> more
> > since, when you could just change the variable name to 'frequency_shift'
> and
> > leave the functionality the way it was.
> >
> > Andrew
>
>
> Referring to an earlier comment, "center_frequency" /always/ refers to
> the frequency of the incoming signal. It would/could/should never be
> confused as the center frequency of the signal used to down convert
> the incoming signal. This was a bug in the original code and I took
> the opportunity to fix it in the 3.7 block.
>
> > I have to agree.  It's one thing to muck with the API semantics of a
> block
> > that is "new" and hardly anyone has used.  It's quite another to
> >   make a change like this on a block that has been in use for many years,
> > with folks having figured out the semantics, despite the odd naming.
> >
> >
> > --
> > Marcus Leech
> > Principal Investigator
> > Shirleys Bay Radio Astronomy Consortium
> > http://www.sbrac.org
>
> With everything else that we've changed in 3.7, changing a + to a -
> seems like a pretty simple thing. The fix will stay.
>
> I have updated the wiki page that discusses the changes needed to go
> from 3.6 to 3.7 to include this omission
> (http://gnuradio.org/redmine/projects/gnuradio/wiki/Move_3-6_to_3-7).
>
> --
> Tom
> Visit us at GRCon13 Oct. 1 - 4
> http://www.trondeau.com/grcon13
>
> ___
> 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] Overrun issue and packet loss

[Andrew Davis]

Try running it without anything else on the network or on your computer,
not even X11.

Andrew


On Mon, Aug 19, 2013 at 3:44 AM, Sam mite  wrote:

> can somebody please comment on it ? Thanks a head of time.
>
>
> --
> Sam
>
>
>
> On Fri, Aug 16, 2013 at 10:11 AM, Sam mite  wrote:
>
>> I am facing Overrun issue on 500K sampling rate with USRPN210. I see an
>> 'O' after irregular time intervals when I use my flowgrpah . PC is directly
>> connected to USRP with Ethernet cable. PC details:
>>
>> Processor: Intel® Core™ i7-2600 CPU @ 3.40GHz × 8
>> Memory: 3.8GiB
>>
>> GNU C++ version 4.6.3; Boost_104601; UHD_003.005.000-26-gb65a3924
>> Gnruadio version: 3.6.3rc0
>>
>> Also to check, I ran ./benchmark_rate --rx_rate 500e3 --duration 300,
>> three times and following are the outputs:
>>
>> Testing receive rate 0.50 Msps
>> OO
>> Benchmark rate summary:
>>   Num received samples:149997045
>>   Num dropped samples: 726
>>   Num overflows detected:  2
>>
>> Testing receive rate 0.50 Msps
>>
>> Benchmark rate summary:
>>   Num received samples:149998497
>>   Num dropped samples: 0
>>   Num overflows detected:  0
>>
>> Testing receive rate 0.50 Msps
>> OOO
>> Benchmark rate summary:
>>   Num received samples:149997408
>>   Num dropped samples: 1089
>>   Num overflows detected:  3
>>
>>
>> What could be the issue here? And what can I do to fix this issue as I am
>> losing 3 to 4 packets in every 10k packets when I use my flow-graph. Any
>> comments would be appreciated.
>>
>> --
>>
>> Best Regards,
>>
>> Sam
>>
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Problem with cmake not finding includes

[Andrew Davis]

Wow, what a coincidence, I just ran into this problem this morning and was
about to ask about it right before I saw your post, I too am having the
exact same problem on xubuntu amd64. I have not done a git pull for a few
days so this problem was not caused this morning by any commit if that
helps.

Thanks,
Andrew




On Fri, Aug 23, 2013 at 6:11 AM,  wrote:

>
> Hi,
>
> I'm porting my real time Doppler correction block from 3.6 to 3.7 but
> have come across an issue that when I try to cmake it, I get an error
> saying it cannot find the runtime includes. To replicate this I
> created a new block ('howto') and tried to cmake that and got the same
> error:
>
> # gr_modtool newmod howto
> Creating out-of-tree module in ./gr-howto... Done.
> Use 'gr_modtool add' to add a new block to this currently empty module.
>
> # cd gr-howto
>
> # ls
> apps  cmake  CMakeLists.txt  docs  grc  include  lib  python  swig
>
> # mkdir build
> # cd build/
> # cmake ../
> -- The CXX compiler identification is GNU 4.8.1
> -- The C compiler identification is GNU 4.8.1
> -- Check for working CXX compiler: /usr/bin/c++
> -- Check for working CXX compiler: /usr/bin/c++ -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Check for working C compiler: /usr/bin/cc
> -- Check for working C compiler: /usr/bin/cc -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Build type not specified: defaulting to release.
> -- Boost version: 1.54.0
> -- Found the following Boost libraries:
> --   filesystem
> --   system
> -- Found PkgConfig: /usr/bin/pkg-config (found version "0.26")
> -- checking for module 'gnuradio-runtime'
> --   found gnuradio-runtime, version 3.7.0
> -- Could NOT find GNURADIO_RUNTIME (missing:
>  GNURADIO_RUNTIME_INCLUDE_DIRS)
> -- checking for module 'cppunit'
> --   found cppunit, version 1.13.1
> -- Found CPPUNIT: /usr/lib/x86_64-linux-gnu/libcppunit.so;dl
> CMake Error at CMakeLists.txt:98 (message):
>   GnuRadio Runtime required to compile howto
>
>
> -- Configuring incomplete, errors occurred!
>
>
> I've tried to figure out what cmake is actually looking for, but
> quickly ran out of enthusiasm for trying to debug cmake
> (--debug-output is of very limited help, and my usual method of
> 'strace' to see what files a process is actually looking for is
> thwarted due to the use of pipes/subprocesses). If I look in
> /usr/lib/cmake/gnuradio/GnuradioConfig.cmake I see that there is a
> line:
> GR_MODULE(RUNTIME gnuradio-runtime gnuradio/top_block.h gnuradio-runtime)
> which to me implies that it might be looking for top_block.h to check
> that runtime include are installed. If I do:
>
> # ls -l /usr/include/gnuradio/top_block.h
>
> -rw-r--r-- 1 root root 4822 Jun  9 20:44 /usr/include/gnuradio/top_block.h
>
>
> I'm running debian unstable on amd64 with gnuradio-dev (3.7.0-5)
> installed.
>
> Any suggestions as to how to fix or debug this issue would be
> gratefully received!
>
> Thanks,
>
> Matt
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Problem with cmake not finding includes

[Andrew Davis]

OK, rebuild and reinstalled Gnuradio after revoking that commit, then build
a new module with modtool and still had the same problem:

checking for module 'gnuradio-runtime'

found gnuradio-runtime, version 3.7.1git

Could NOT find GNURADIO_RUNTIME (missing: GNURADIO_RUNTIME_INCLUDE_DIRS)

checking for module 'cppunit'

found cppunit, version 1.12.1

Found CPPUNIT: /usr/lib/libcppunit.so;dl

CMake Error at CMakeLists.txt:98 (message):

GnuRadio Runtime required to compile howto


It looks like it finds gnuradio-runtime, but not the headers...


Andrew


On Sat, Aug 24, 2013 at 6:38 AM,  wrote:

> Tom Rondeau writes:
>  > On Fri, Aug 23, 2013 at 10:51 AM,   wrote:
>  > > Tom Rondeau writes:
>  > >  > On Fri, Aug 23, 2013 at 6:11 AM,  
> wrote:
>  > >  > >
>  > >  > > Hi,
>  > >  > >
>  > >  > > I'm porting my real time Doppler correction block from 3.6 to
> 3.7 but
>  > >  > > have come across an issue that when I try to cmake it, I get an
> error
>  > >  > > saying it cannot find the runtime includes. To replicate this I
>  > >  > > created a new block ('howto') and tried to cmake that and got
> the same
>  > >  > > error:
>  > >  > >
>  > >  > > # gr_modtool newmod howto
>  > >  > > Creating out-of-tree module in ./gr-howto... Done.
>  > >  > > Use 'gr_modtool add' to add a new block to this currently empty
> module.
>  > >  > >
>  > >  > > # cd gr-howto
>  > >  > >
>  > >  > > # ls
>  > >  > > apps  cmake  CMakeLists.txt  docs  grc  include  lib  python
>  swig
>  > >  > >
>  > >  > > # mkdir build
>  > >  > > # cd build/
>  > >  > > # cmake ../
>  > >  > > -- The CXX compiler identification is GNU 4.8.1
>  > >  > > -- The C compiler identification is GNU 4.8.1
>  > >  > > -- Check for working CXX compiler: /usr/bin/c++
>  > >  > > -- Check for working CXX compiler: /usr/bin/c++ -- works
>  > >  > > -- Detecting CXX compiler ABI info
>  > >  > > -- Detecting CXX compiler ABI info - done
>  > >  > > -- Check for working C compiler: /usr/bin/cc
>  > >  > > -- Check for working C compiler: /usr/bin/cc -- works
>  > >  > > -- Detecting C compiler ABI info
>  > >  > > -- Detecting C compiler ABI info - done
>  > >  > > -- Build type not specified: defaulting to release.
>  > >  > > -- Boost version: 1.54.0
>  > >  > > -- Found the following Boost libraries:
>  > >  > > --   filesystem
>  > >  > > --   system
>  > >  > > -- Found PkgConfig: /usr/bin/pkg-config (found version "0.26")
>  > >  > > -- checking for module 'gnuradio-runtime'
>  > >  > > --   found gnuradio-runtime, version 3.7.0
>  > >  > > -- Could NOT find GNURADIO_RUNTIME (missing:
>  GNURADIO_RUNTIME_INCLUDE_DIRS)
>  > >  > > -- checking for module 'cppunit'
>  > >  > > --   found cppunit, version 1.13.1
>  > >  > > -- Found CPPUNIT: /usr/lib/x86_64-linux-gnu/libcppunit.so;dl
>  > >  > > CMake Error at CMakeLists.txt:98 (message):
>  > >  > >   GnuRadio Runtime required to compile howto
>  > >  > >
>  > >  > >
>  > >  > > -- Configuring incomplete, errors occurred!
>  > >  > >
>  > >  > >
>  > >  > > I've tried to figure out what cmake is actually looking for, but
>  > >  > > quickly ran out of enthusiasm for trying to debug cmake
>  > >  > > (--debug-output is of very limited help, and my usual method of
>  > >  > > 'strace' to see what files a process is actually looking for is
>  > >  > > thwarted due to the use of pipes/subprocesses). If I look in
>  > >  > > /usr/lib/cmake/gnuradio/GnuradioConfig.cmake I see that there is
> a
>  > >  > > line:
>  > >  > > GR_MODULE(RUNTIME gnuradio-runtime gnuradio/top_block.h
> gnuradio-runtime)
>  > >  > > which to me implies that it might be looking for top_block.h to
> check
>  > >  > > that runtime include are installed. If I do:
>  > >  > >
>  > >  > > # ls -l /usr/include/gnuradio/top_block.h
>  > >  > >
>  > >  > > -rw-r--r-- 1 root root 4822 Jun  9 20:44
> /usr/include/gnuradio/top_block.h
>  > >  > >
>  > >  > >
>  > >  > > I'm running debian unstable on amd64 with gnuradio-dev (3.7.0-5)
>  > >  > > installed.
>  > >  > >
>  > >  > > Any suggestions as to how to fix or debug this issue would be
>  > >  > > gratefully received!
>  > >  > >
>  > >  > > Thanks,
>  > >  > >
>  > >  > > Matt
>  > >  >
>  > >  >
>  > >  > Matt,
>  > >  >
>  > >  > If you run 'pkg-config --modversion gnuradio-runtime' does it
> return
>  > >  > the correct version number? If pkg-config can't find it, something
>  > >  > either didn't get installed correctly or pkg-config is
> misconfigured
>  > >  > (because it looks like you've installed into /usr, and pkg-config
>  > >  > should look in /usr/lib/pkgconfig by default).
>  > >  >
>  > >  > --
>  > >  > Tom
>  > >  > Visit us at GRCon13 Oct. 1 - 4
>  > >  > http://www.trondeau.com/grcon13
>  > >
>  > > Tom,
>  > >
>  > > 'pkg-config --modversion gnuradio-runtime' returns '3.7.0'.
>  > >
>  > > These are the debian (unstable) packages, I'm not sure how they were
>  > > configured. If its only me that has this problem, I'll raise a bug
>  > > against the debian packages.
> 

Re: [Discuss-gnuradio] Problem with cmake not finding includes

[Andrew Davis]

I don't think this is a modtool specific problem ether, I can no longer
build ANY out of tree project now, even ones that compiled just fine
before, it can't find the headers for any Gnuradio components (
GNURADIO_BLOCKS_INCLUDE_DIRS, GNURADIO_UHD_INCLUDE_DIRS, etc.. ).

Andrew


On Sat, Aug 24, 2013 at 12:39 PM, Andrew Davis wrote:

> OK, rebuild and reinstalled Gnuradio after revoking that commit, then
> build a new module with modtool and still had the same problem:
>
> checking for module 'gnuradio-runtime'
>
> found gnuradio-runtime, version 3.7.1git
>
> Could NOT find GNURADIO_RUNTIME (missing: GNURADIO_RUNTIME_INCLUDE_DIRS)
>
> checking for module 'cppunit'
>
> found cppunit, version 1.12.1
>
> Found CPPUNIT: /usr/lib/libcppunit.so;dl
>
> CMake Error at CMakeLists.txt:98 (message):
>
> GnuRadio Runtime required to compile howto
>
>
> It looks like it finds gnuradio-runtime, but not the headers...
>
>
> Andrew
>
>
> On Sat, Aug 24, 2013 at 6:38 AM,  wrote:
>
>> Tom Rondeau writes:
>>  > On Fri, Aug 23, 2013 at 10:51 AM,   wrote:
>>  > > Tom Rondeau writes:
>>  > >  > On Fri, Aug 23, 2013 at 6:11 AM,  
>> wrote:
>>  > >  > >
>>  > >  > > Hi,
>>  > >  > >
>>  > >  > > I'm porting my real time Doppler correction block from 3.6 to
>> 3.7 but
>>  > >  > > have come across an issue that when I try to cmake it, I get an
>> error
>>  > >  > > saying it cannot find the runtime includes. To replicate this I
>>  > >  > > created a new block ('howto') and tried to cmake that and got
>> the same
>>  > >  > > error:
>>  > >  > >
>>  > >  > > # gr_modtool newmod howto
>>  > >  > > Creating out-of-tree module in ./gr-howto... Done.
>>  > >  > > Use 'gr_modtool add' to add a new block to this currently empty
>> module.
>>  > >  > >
>>  > >  > > # cd gr-howto
>>  > >  > >
>>  > >  > > # ls
>>  > >  > > apps  cmake  CMakeLists.txt  docs  grc  include  lib  python
>>  swig
>>  > >  > >
>>  > >  > > # mkdir build
>>  > >  > > # cd build/
>>  > >  > > # cmake ../
>>  > >  > > -- The CXX compiler identification is GNU 4.8.1
>>  > >  > > -- The C compiler identification is GNU 4.8.1
>>  > >  > > -- Check for working CXX compiler: /usr/bin/c++
>>  > >  > > -- Check for working CXX compiler: /usr/bin/c++ -- works
>>  > >  > > -- Detecting CXX compiler ABI info
>>  > >  > > -- Detecting CXX compiler ABI info - done
>>  > >  > > -- Check for working C compiler: /usr/bin/cc
>>  > >  > > -- Check for working C compiler: /usr/bin/cc -- works
>>  > >  > > -- Detecting C compiler ABI info
>>  > >  > > -- Detecting C compiler ABI info - done
>>  > >  > > -- Build type not specified: defaulting to release.
>>  > >  > > -- Boost version: 1.54.0
>>  > >  > > -- Found the following Boost libraries:
>>  > >  > > --   filesystem
>>  > >  > > --   system
>>  > >  > > -- Found PkgConfig: /usr/bin/pkg-config (found version "0.26")
>>  > >  > > -- checking for module 'gnuradio-runtime'
>>  > >  > > --   found gnuradio-runtime, version 3.7.0
>>  > >  > > -- Could NOT find GNURADIO_RUNTIME (missing:
>>  GNURADIO_RUNTIME_INCLUDE_DIRS)
>>  > >  > > -- checking for module 'cppunit'
>>  > >  > > --   found cppunit, version 1.13.1
>>  > >  > > -- Found CPPUNIT: /usr/lib/x86_64-linux-gnu/libcppunit.so;dl
>>  > >  > > CMake Error at CMakeLists.txt:98 (message):
>>  > >  > >   GnuRadio Runtime required to compile howto
>>  > >  > >
>>  > >  > >
>>  > >  > > -- Configuring incomplete, errors occurred!
>>  > >  > >
>>  > >  > >
>>  > >  > > I've tried to figure out what cmake is actually looking for, but
>>  > >  > > quickly ran out of enthusiasm for trying to debug cmake
>>  > >  > > (--debug-output is of very limited help, and my usual method of
>>  > >  > > 'strace' to see what files a process is actually looking for is
>>  &

Re: [Discuss-gnuradio] Problem with cmake not finding includes

[Andrew Davis]

No only things from my new install, I deleted everything Gnuradio in
/usr/lib/pkgconfig and reinstalled them.

I did notice something strange
though, /usr/lib/pkgconfig/gnuradio-runtime.pc contains:

prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include

Name: DRI2Proto
Description: DRI2 extension headers
Version: 2.8
Cflags: -I${includedir}

And when I do the following I get:

w9yb@w9yb-5:~$ pkg-config --modversion gnuradio-runtime
3.7.1git
w9yb@w9yb-5:~$ pkg-config --libs gnuradio-runtime
-lgnuradio-runtime -lgnuradio-pmt
w9yb@w9yb-5:~$ pkg-config --cflags gnuradio-runtime

w9yb@w9yb-5:~$

As you can see --cflags returns nothing, it does this now for all packages
on my system, I think this might be a pkg-config bug?

Andrew


On Sat, Aug 24, 2013 at 1:22 PM, Marcus Müller  wrote:

>  Perhaps it's a lingering pkgconfig file from another installation?
> Does
> find /usr/lib*/pkgconfig /usr/local/lib*/pkgconfig /lib*/pkgconfig -iname
> 'gnuradio*pc'
> yield anything that does not belong to your current installation?
>
>
>
> On 08/24/2013 06:45 PM, Andrew Davis wrote:
>
> I don't think this is a modtool specific problem ether, I can no longer
> build ANY out of tree project now, even ones that compiled just fine
> before, it can't find the headers for any Gnuradio components (
> GNURADIO_BLOCKS_INCLUDE_DIRS, GNURADIO_UHD_INCLUDE_DIRS, etc.. ).
>
>  Andrew
>
>
> On Sat, Aug 24, 2013 at 12:39 PM, Andrew Davis wrote:
>
>> OK, rebuild and reinstalled Gnuradio after revoking that commit, then
>> build a new module with modtool and still had the same problem:
>>
>>  checking for module 'gnuradio-runtime'
>>
>> found gnuradio-runtime, version 3.7.1git
>>
>> Could NOT find GNURADIO_RUNTIME (missing: GNURADIO_RUNTIME_INCLUDE_DIRS)
>>
>> checking for module 'cppunit'
>>
>> found cppunit, version 1.12.1
>>
>> Found CPPUNIT: /usr/lib/libcppunit.so;dl
>>
>> CMake Error at CMakeLists.txt:98 (message):
>>
>> GnuRadio Runtime required to compile howto
>>
>>
>>  It looks like it finds gnuradio-runtime, but not the headers...
>>
>>
>>  Andrew
>>
>>
>>  On Sat, Aug 24, 2013 at 6:38 AM,  wrote:
>>
>>>  Tom Rondeau writes:
>>>  > On Fri, Aug 23, 2013 at 10:51 AM,   wrote:
>>>  > > Tom Rondeau writes:
>>>  > >  > On Fri, Aug 23, 2013 at 6:11 AM,  
>>> wrote:
>>>  > >  > >
>>>  > >  > > Hi,
>>>  > >  > >
>>>  > >  > > I'm porting my real time Doppler correction block from 3.6 to
>>> 3.7 but
>>>  > >  > > have come across an issue that when I try to cmake it, I get
>>> an error
>>>  > >  > > saying it cannot find the runtime includes. To replicate this I
>>>  > >  > > created a new block ('howto') and tried to cmake that and got
>>> the same
>>>  > >  > > error:
>>>  > >  > >
>>>  > >  > > # gr_modtool newmod howto
>>>  > >  > > Creating out-of-tree module in ./gr-howto... Done.
>>>  > >  > > Use 'gr_modtool add' to add a new block to this currently
>>> empty module.
>>>  > >  > >
>>>  > >  > > # cd gr-howto
>>>  > >  > >
>>>  > >  > > # ls
>>>  > >  > > apps  cmake  CMakeLists.txt  docs  grc  include  lib  python
>>>  swig
>>>  > >  > >
>>>  > >  > > # mkdir build
>>>  > >  > > # cd build/
>>>  > >  > > # cmake ../
>>>  > >  > > -- The CXX compiler identification is GNU 4.8.1
>>>  > >  > > -- The C compiler identification is GNU 4.8.1
>>>  > >  > > -- Check for working CXX compiler: /usr/bin/c++
>>>  > >  > > -- Check for working CXX compiler: /usr/bin/c++ -- works
>>>  > >  > > -- Detecting CXX compiler ABI info
>>>  > >  > > -- Detecting CXX compiler ABI info - done
>>>  > >  > > -- Check for working C compiler: /usr/bin/cc
>>>  > >  > > -- Check for working C compiler: /usr/bin/cc -- works
>>>  > >  > > -- Detecting C compiler ABI info
>>>  > >  > > -- Detecting C compiler ABI info - done
>>>  > >  > > -- Build type not specified: defaulting to release.
>>>  > >  > > -- Boost version: 1.54.0
>&g

Re: [Discuss-gnuradio] Problem with cmake not finding includes

[Andrew Davis]

Sorry, I printed the content of dri2proto.pc, gnuradio-runtime.pc contains:

prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include

Name: gnuradio-runtime
Description: GNU Radio core runtime infrastructure
Requires:
Version: 3.7.1git
Libs: -L${libdir} -lgnuradio-runtime -lgnuradio-pmt
Cflags: -I${includedir}

pkg-config --cflags dri2proto also shows nothing also, that is how I knew
it wasn't just Gnuradio

Andrew


On Sat, Aug 24, 2013 at 1:48 PM, Andrew Davis wrote:

> No only things from my new install, I deleted everything Gnuradio in
> /usr/lib/pkgconfig and reinstalled them.
>
> I did notice something strange
> though, /usr/lib/pkgconfig/gnuradio-runtime.pc contains:
>
> prefix=/usr
> exec_prefix=${prefix}
> libdir=${exec_prefix}/lib
> includedir=${prefix}/include
>
> Name: DRI2Proto
> Description: DRI2 extension headers
> Version: 2.8
> Cflags: -I${includedir}
>
> And when I do the following I get:
>
> w9yb@w9yb-5:~$ pkg-config --modversion gnuradio-runtime
> 3.7.1git
> w9yb@w9yb-5:~$ pkg-config --libs gnuradio-runtime
> -lgnuradio-runtime -lgnuradio-pmt
> w9yb@w9yb-5:~$ pkg-config --cflags gnuradio-runtime
>
> w9yb@w9yb-5:~$
>
> As you can see --cflags returns nothing, it does this now for all packages
> on my system, I think this might be a pkg-config bug?
>
> Andrew
>
>
> On Sat, Aug 24, 2013 at 1:22 PM, Marcus Müller  wrote:
>
>>  Perhaps it's a lingering pkgconfig file from another installation?
>> Does
>> find /usr/lib*/pkgconfig /usr/local/lib*/pkgconfig /lib*/pkgconfig -iname
>> 'gnuradio*pc'
>> yield anything that does not belong to your current installation?
>>
>>
>>
>> On 08/24/2013 06:45 PM, Andrew Davis wrote:
>>
>> I don't think this is a modtool specific problem ether, I can no longer
>> build ANY out of tree project now, even ones that compiled just fine
>> before, it can't find the headers for any Gnuradio components (
>> GNURADIO_BLOCKS_INCLUDE_DIRS, GNURADIO_UHD_INCLUDE_DIRS, etc.. ).
>>
>>  Andrew
>>
>>
>> On Sat, Aug 24, 2013 at 12:39 PM, Andrew Davis 
>> wrote:
>>
>>> OK, rebuild and reinstalled Gnuradio after revoking that commit, then
>>> build a new module with modtool and still had the same problem:
>>>
>>>  checking for module 'gnuradio-runtime'
>>>
>>> found gnuradio-runtime, version 3.7.1git
>>>
>>> Could NOT find GNURADIO_RUNTIME (missing: GNURADIO_RUNTIME_INCLUDE_DIRS)
>>>
>>> checking for module 'cppunit'
>>>
>>> found cppunit, version 1.12.1
>>>
>>> Found CPPUNIT: /usr/lib/libcppunit.so;dl
>>>
>>> CMake Error at CMakeLists.txt:98 (message):
>>>
>>> GnuRadio Runtime required to compile howto
>>>
>>>
>>>  It looks like it finds gnuradio-runtime, but not the headers...
>>>
>>>
>>>  Andrew
>>>
>>>
>>>  On Sat, Aug 24, 2013 at 6:38 AM,  wrote:
>>>
>>>>  Tom Rondeau writes:
>>>>  > On Fri, Aug 23, 2013 at 10:51 AM,  
>>>> wrote:
>>>>  > > Tom Rondeau writes:
>>>>  > >  > On Fri, Aug 23, 2013 at 6:11 AM,  
>>>> wrote:
>>>>  > >  > >
>>>>  > >  > > Hi,
>>>>  > >  > >
>>>>  > >  > > I'm porting my real time Doppler correction block from 3.6 to
>>>> 3.7 but
>>>>  > >  > > have come across an issue that when I try to cmake it, I get
>>>> an error
>>>>  > >  > > saying it cannot find the runtime includes. To replicate this
>>>> I
>>>>  > >  > > created a new block ('howto') and tried to cmake that and got
>>>> the same
>>>>  > >  > > error:
>>>>  > >  > >
>>>>  > >  > > # gr_modtool newmod howto
>>>>  > >  > > Creating out-of-tree module in ./gr-howto... Done.
>>>>  > >  > > Use 'gr_modtool add' to add a new block to this currently
>>>> empty module.
>>>>  > >  > >
>>>>  > >  > > # cd gr-howto
>>>>  > >  > >
>>>>  > >  > > # ls
>>>>  > >  > > apps  cmake  CMakeLists.txt  docs  grc  include  lib  python
>>>>  swig
>>>>  > >  > >
>>>>  > >  > > # mkdir build
>>>>  > >  > &

Re: [Discuss-gnuradio] Antennas

[Andrew Davis]

Kinda OT, but sure, what I use for most experiments is a handheld dipole
with telescoping elements, it can tune between about 80 and 400 MHz, for
everything else I use a simple 800MHz rubber duck, these work well enough
for everything i'm doing.

Andrew


On Tue, Aug 27, 2013 at 9:06 PM, Richard Thornton  wrote:

> Hi everyone,
>
> Apologies if this is slightly OT but I am new to gnu-radio, radio and SDR.
>
> I am interested in what people are doing for antennas, I was thinking
> that some kind of modular antenna would be cool, basically an SMA
> connector, some cable, a groundplane with a hole to slot the antenna
> in to, you could then change the actual antenna piece for different
> frequencies, no doubt I am missing something fundamental?
>
> So my SDR has a frequency range of 300MHz - 3.8GHz, so you could have
> 20 pieces of thick wire (your antenna), each one a different length.
>
> Thanks for looking.
>
> Cheers
> Richard
>
> ___
> 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] WavFile_Sink Issues: slowed down sound - multiplied playing time

[Andrew Davis]

I'm not sure exactly what you are doing, but some sound cards don't support
very many rates, windows always re-samples to some rate supported by the
card, in linux you get more direct access to sound hardware and so you can
send it rates it may not like, you could add a re-sampler/sound manager
like pulse to handle all this for you, worked for me with similar issues.

Andrew


On Fri, Aug 30, 2013 at 10:53 AM, Luke Berndt  wrote:

> So I clearly have a sample rate mis-match. I am trying to record the audio
> from the gr-dsd block. I don't seem to have an issue doing it using GRC.
> However when I try doing using C++ the audio sounds extra slow and choppy
> and the playing time is much longer than I was actually recording for. I
> gr-dsd block is supposed to output audio at 8khz. I have the wavfile_sink
> set at 8000 for the samples per sec parameter. I use the same setting in
> GRC and it works fine. I have also tried passing this through a resampler
> to get the audio rate up to 44.1khz and I still have the same problem. If I
> use an audio_sink set to a sample rate of 44100 instead, I am able to
> listen to the audio with no problem.
>
> Any idea what is going on or what I can try?
>
> Here is a sample of the output:
> https://soundcloud.com/hackrfsounds/moto-smartnet-recording
>
> 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] WavFile_Sink Issues: slowed down sound - multiplied playing time

[Andrew Davis]

I'm not sure about dsd but becouse of the ratio of symbol rate to sample
rate, some digital decoders will take a variable number of inputs per
output, this could without a sizable buffer under-run your sound card, some
sound servers handle these gaps in the sample stream for you.

Also have you tried just playing the .wav's in a music player? I have had
issues with the wavfile_sink messing up the format. Also check that you are
feeding the wavfile_sink in the format, could you just post your .grc file
here?

Andrew


On Fri, Aug 30, 2013 at 8:23 PM, Luke Berndt  wrote:

> Thanks Andrew! - I am actually able to play the sound fine through sound
> card using the audio_sink block. It was is when I try recording it to a
> .wav file using the wavfile_sink block that the sounds becomes distorted. I
> have tired using a resampler and also tried a variety of different sample
> rate on the wavfile_sink, but none of them sounded normal.
>
> gr-dsd is a vocoder block and its decoding is sort of bursty. Sometimes it
> seems to only take 4 input packets to equal 1 output, others it is 8 or 11.
> Any wise, I am wondering I am getting some form of under run. I am not
> getting 'aUaU' on the screen. Sometimes the sound from audio sink initially
> sound garbled but then becomes normal, so I wonder if it is an issue of
> needing to buffer up. I have tried adding in a Forecast, but it didn't help.
>
> Any other tips would be great!
>
>  - Luke
>
> On Aug 30, 2013, at 5:03 PM, Andrew Davis  wrote:
>
> I'm not sure exactly what you are doing, but some sound cards don't
> support very many rates, windows always re-samples to some rate supported
> by the card, in linux you get more direct access to sound hardware and so
> you can send it rates it may not like, you could add a re-sampler/sound
> manager like pulse to handle all this for you, worked for me with similar
> issues.
>
> Andrew
>
>
> On Fri, Aug 30, 2013 at 10:53 AM, Luke Berndt  wrote:
>
>> So I clearly have a sample rate mis-match. I am trying to record the
>> audio from the gr-dsd block. I don't seem to have an issue doing it using
>> GRC. However when I try doing using C++ the audio sounds extra slow and
>> choppy and the playing time is much longer than I was actually recording
>> for. I gr-dsd block is supposed to output audio at 8khz. I have the
>> wavfile_sink set at 8000 for the samples per sec parameter. I use the same
>> setting in GRC and it works fine. I have also tried passing this through a
>> resampler to get the audio rate up to 44.1khz and I still have the same
>> problem. If I use an audio_sink set to a sample rate of 44100 instead, I am
>> able to listen to the audio with no problem.
>>
>> Any idea what is going on or what I can try?
>>
>> Here is a sample of the output:
>> https://soundcloud.com/hackrfsounds/moto-smartnet-recording
>>
>> 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] WavFile_Sink Issues: slowed down sound - multiplied playing time

[Andrew Davis]

That all sounds about right, I've run into problems like that before, the
example blocks all end by just return the number of output samples
requested, so some projects just do this too when they shouldn't.

Also the empty blocks idea sounds possible too. With a vocoder sometimes
there may not be enough data to fill a packet every time one is needed for
transmitting, the modulator may need more packets than can be filled and so
null packets are inserted. I've been doing a bit of work on the gnuradio
ATSC decoder, and I've found that about 10-20% of packets are just null
packets, the compression is TOO good and there is not enough data to be
send out at a given instant. The nice thing is the MPEG-TS packets come
with a time reference so you can just insert nulls or drop packets when you
need to, but i'm not sure if this is the case with the encoding used with
dsd.

Andrew


On Sat, Aug 31, 2013 at 10:18 AM, Luke Berndt  wrote:

> I think I may have figured it out. It has to do with how the signal
> processing block that goes around the vocoder was written. The general_work
> function for gr_block classes takes in a requested number of outputs and
> also returns back how many output items were produced. The way it was
> written was that it would also report back the desired number of outputs
> were produced even if they were not. This worked fine for the audio_sink. I
> had no issues like to the audio through my sound card / sound server.
> However with the wav file recorder, it lead to the slowed down sounds and
> the actual playing time of the wav file being many times longer than it
> should have been.
>
> When I switched the number of outputted items return by general_work to be
> the actual number of samples the were processed and ready to be outputted,
> the wav file sink started to work. The audio quality of the recorded wav
> file is still a little worse than the sound from sound quality. I think the
> reason this works is because the audio sink is "clocked" by the sound card
> and it only requests more samples once the buffer for the sound card is
> empty. On the other hand, I don't think the wav file sink is really rate
> limited, it seems to request more samples from the vocoder at a much higher
> rate. When the block lies and just keeps giving it empty samples whenever
> the wav file sink asks, the play time gets inflated and the actual audio
> bits get watered down with these fake samples. However, the weird thing is
> that the audio from the sound card now sounds weird when the vocoder only
> gives out samples when there is actual data. I think, this is because when
> there is actual data coming in there should be some empty blocks in between
> to reconstitute things.
>
> Is this just crazy talk or does it sound right?
>
> Here is the wav file were it is using only the actual samples produced and
> it is intelligible:
> https://soundcloud.com/hackrfsounds/only-recieved-frames
>
> And here is the wav file where the vocoder block always returns the
> requested number of samples even if nothing was output:
> https://soundcloud.com/hackrfsounds/moto-smartnet-recording
>
> My GRC file and the DSD block is here:
> https://github.com/robotastic/gr-dsd
> If you change /lib/dsd_block_ff.cc on line 365 & 366 you can change how
> the number of outputted samples is determined.
>
> I have the C++ program the uses this all here:
> https://github.com/robotastic/sdr  under the smartnet directory
>
>
>  - Luke
>
> On Aug 30, 2013, at 8:53 PM, Andrew Davis  wrote:
>
> I'm not sure about dsd but becouse of the ratio of symbol rate to sample
> rate, some digital decoders will take a variable number of inputs per
> output, this could without a sizable buffer under-run your sound card, some
> sound servers handle these gaps in the sample stream for you.
>
> Also have you tried just playing the .wav's in a music player? I have had
> issues with the wavfile_sink messing up the format. Also check that you are
> feeding the wavfile_sink in the format, could you just post your .grc file
> here?
>
> Andrew
>
>
> On Fri, Aug 30, 2013 at 8:23 PM, Luke Berndt  wrote:
>
>> Thanks Andrew! - I am actually able to play the sound fine through sound
>> card using the audio_sink block. It was is when I try recording it to a
>> .wav file using the wavfile_sink block that the sounds becomes distorted. I
>> have tired using a resampler and also tried a variety of different sample
>> rate on the wavfile_sink, but none of them sounded normal.
>>
>> gr-dsd is a vocoder block and its decoding is sort of bursty. Sometimes
>> it seems to only take 4 input packets to equal 1 output, others it is 8 or
>> 11. Any wise, I am wondering I am g

Re: [Discuss-gnuradio] What am I really seeing?

[Andrew Davis]

Hello, first I think you meant sample rate, not size. Who said you cant use
30Mhz, what kind of hardware are you using? Lastly the FFT algorithms do
not deal with frequency in that way, you are still seeing 0-50Mhz spectrum,
just the label now says 50Mhz.

Andrew


On Sat, Nov 16, 2013 at 10:11 AM, Paul B. Huter wrote:

> I have a GNU Radio setup to look at shortwave. I have my sample size set
> to 50MHz (since I was told I can't use 30). If I set my FFT to 30MHz with a
> baseband of 15MHz, am I actually seeing the shortwave spectrum (0-30MHz)?
> Also, any suggestions on setting the FFT Size?
>
> Thank you!
>
> Paul B. Huter
>
> ___
> 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] Gnuradio 3.7.2 Windows?

[Andrew Davis]

Hello,

>Has anyone actually managed to successfully install and run the latest
gnuradio in Windows 7

Yes, but not using those instruction, building from source is much more fun
:), but they look like they worked for you outside of that error.

Also If you Google your error other people are having that problem as well,
so it's not Gnuradio related but something with pyopengl on certain windows
systems. I'd say try installing an older version of pyopengl.

> I must admit to getting extremely frustrated with Gnuradio and its lack
or usability for those of us who are not professional programmers.

While I agree it's not quite user friendly it is a software defined radio
API and development system, so it's not gonna be like going to be like
installing a program and listening to the radio, you will need
some software savvyness to build a SDR. If you just want to use a SDR there
are many already made programs for individual tasks.

Andrew


On Mon, Dec 23, 2013 at 4:47 AM, Mike Willis  wrote:

>
>
> Has anyone actually managed to successfully install and run the latest
> gnuradio in Windows 7 based on these
> http://code.ettus.com/redmine/ettus/projects/uhd/wiki/GNURadio_Windowsinstructions?
>
>
>
> I don’t believe this page is up to date as I just cannot get it to work.
> It was OK if something of a struggle with 3.6.
>
>
>
> Although it nearly works, the gui modules do not work at all but produce a
> rather unhelpful error message. E.g. this is with a wxgui fft sink added to
> the dialtone example. The tone works fine but not with any gui.
>
>
>
> “TypeError: ("No array-type handler for type 
> (value: c_ulong(0L)) registered",  object at 0x0482A3D0>)
>
> ”
>
>
>
> How am I supposed to understand this? It looks to me like a problem with
> pyopengl but that has been installed as indicated in the instructions. Are
> the instructions wrong? Is this the wrong version? Does it just not work
> anyway?
>
>
>
> I must admit to getting extremely frustrated with gnuradio and its lack or
> usability for those of us who are not professional programmers.
>
>
>
> Mike
>
>
>
> Here is the debug code.
>
>
>
> self._initText()
>
>   File "C:\Program
> Files\gnuradio\lib\site-packages\gnuradio\wxgui\plotter\gltext.py", line
> 376, in _initText
>
> self._centered)
>
>   File "C:\Program
> Files\gnuradio\lib\site-packages\gnuradio\wxgui\plotter\gltext.py", line
> 73, in __init__
>
> self.createTexture()
>
>   File "C:\Program
> Files\gnuradio\lib\site-packages\gnuradio\wxgui\plotter\gltext.py", line
> 229, in createTexture
>
> self._texture = glGenTextures(1)
>
>   File
> "C:\Python27\lib\site-packages\pyopengl-3.1.0a3-py2.7.egg\OpenGL\latebind.py",
> line 61, in __call__
>
> return self.wrapperFunction( self.baseFunction, *args, **named )
>
>   File
> "C:\Python27\lib\site-packages\pyopengl-3.1.0a3-py2.7.egg\OpenGL\GL\exceptional.py",
> line 189, in glGenTextures
>
> baseFunction( count, textures)
>
>   File
> "C:\Python27\lib\site-packages\pyopengl-3.1.0a3-py2.7.egg\OpenGL\latebind.py",
> line 45, in __call__
>
> return self._finalCall( *args, **named )
>
>   File
> "C:\Python27\lib\site-packages\pyopengl-3.1.0a3-py2.7.egg\OpenGL\wrapper.py",
> line 571, in wrapperCall
>
> pyArgs = tuple( calculate_pyArgs( args ))
>
>   File
> "C:\Python27\lib\site-packages\pyopengl-3.1.0a3-py2.7.egg\OpenGL\wrapper.py",
> line 356, in calculate_pyArgs
>
> yield converter(args[index], self, args)
>
>   File
> "C:\Python27\lib\site-packages\pyopengl-3.1.0a3-py2.7.egg\OpenGL\converters.py",
> line 134, in __call__
>
> return self.function( incoming )
>
>   File
> "C:\Python27\lib\site-packages\pyopengl-3.1.0a3-py2.7.egg\OpenGL\arrays\arraydatatype.py",
> line 141, in asArray
>
> return cls.getHandler(value).asArray( value, typeCode or
> cls.typeConstant )
>
>   File
> "C:\Python27\lib\site-packages\pyopengl-3.1.0a3-py2.7.egg\OpenGL\arrays\arraydatatype.py",
> line 52, in __call__
>
> typ, repr(value)[:50]
>
> TypeError: ("No array-type handler for type 
> (value: c_ulong(0L)) registered",  object at 0x0482A3D0>)
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] A Couple Questions

[Andrew Davis]

Hello,

If the buttons aren't working then the thing is probably locked up, try
lowering the fft_rate parameter and see if that fixes things.

Andrew


On Mon, Dec 23, 2013 at 3:10 PM, Paul B. Huter wrote:

> I have a data file that was recorded to a RAMDisk and transferred to the
> hard drive on my Linux machine. When I run it through a throttle, a filter,
> and into an FFT, the file repeats. When I was running it off the RAMDisk,
> it only played for the ~15 seconds of the data. I was having the problem
> with repeating before I rebooted and lost the RAMDisk file (I thought maybe
> having it stored in RAM, too, was causing a problem). Also, the buttons on
> the FFT plot don't work (Autoscale, Stop) Can anyone provide any insight
> into why the file on my hard drive is repeating? "Repeat" is set to "No" on
> the file source block.
>
> Second question - On the FFT (same flow) how can I make it so it STARTS
> viewing all the data? The FFT shows up going from 0 to 100, and the
> majority of the data is negative. As mentioned, it only runs for about 15
> seconds, and even if the Autoscale button worked, I have such a small
> window to view everything. It is my understanding that I can't get an
> Autoscale prior to viewing the plot, but is there a way to scale it with
> the parameters on the flow block (maybe set it to go from 0 to -100)?
>
> 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] build gnuradio without volk module

[Andrew Davis]

Use CMake. I don't think anyone wants to maintain autotools and it
really should be removed.

On Wed, Mar 14, 2012 at 11:36 AM, Arturo Rinaldi  wrote:
> i'd like to build the latest tarball of gnuradio without the volk module.
> However i get the following errors (you can see them in the attached log).
> can i at least disable the module itself when running python sources ?
>
> Best Regards,
>
>     Arturo
>
> ___
> 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] This is nice

[Andrew Davis]

Saw it on Reddit a couple days ago, already have one on order. Then I
might work on making a GnuRadio driver or something for real-time use.

On Wed, Mar 21, 2012 at 3:17 AM, David Kierzkowski  wrote:
> The osmocom guys are using a 20$ USB catv tuner as a RF source in gnuradio. 
> 3.2MS/s !
>
> http://sdr.osmocom.org/trac/wiki/rtl-sdr
> ___
> 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] This is nice

[Andrew Davis]

Right, but I think the idea here is for $20 why not?

As far as a driver goes what they have now is a program that starts
the thing and tunes it, then reads samples, all of this is already
build into the UHD framework. I'm not sure but I would like to make
this a UHD compatible USB device. ( Much like the USRP1 )

~Andrew

On Thu, Mar 22, 2012 at 11:06 AM,   wrote:
> I also have a trio on order.  The issues I can see surrounding this approach
> are:
>
>    o Consumer electronics parts lineups are capricious and unreliable--the
> target device may use the "SDR-capable chip" this month, and next month,
> they've found that they can shave $0.35 of off the B.O.M. by going with a
> totally different parts line-up they will, even though it will cost them
> $50K in engineering costs up front--they sell thousands and thousands a
> month.  There are already *TWO* versions of this dongle, one using the
> "good" RTL2832U chip, and the other using an Afatech chip (AF9015 or
> AF9035). The "magic sauce" that Antti discovered in the RTL2832U chip to do
> "raw samples" is peculiar to the RTL2832U chip, and doesn't necessarily map
> on to other DVB-T digital demod chips on the market.
>
>
>
>   o The 28.8MHz master oscillator is a very cheap 100PPM part, which will
> produce unpleasant frequency offsets, and phase-noise to match
>
>
>
>   o Not sure how good the noise figure is, since there's no LNA in front of
> the E4000 tuner chip.
>
>
>
>   o Don't know how they implement re-sampling.  If it's not done right, then
> there'll be nasty aliases in the passband handed to the host
>
>
>
> None of these are fatal, but be aware that the approach of "re-purposing"
> consumer electronics is fraught with dangers as described above.
>
>
>
> -Marcus
>
>
>
> On Thu, 22 Mar 2012 10:53:13 -0400, Tom Rondeau wrote:
>
> Andrew and Sean,
>
> Glad to hear you both thinking about doing this! Coordinate as you can
> and keep us up to date on the progress.
>
> Tom
>
>
> On Thu, Mar 22, 2012 at 10:45 AM, Nowlan, Sean
>  wrote:
>
> Funny enough, a coworker mentioned it to me yesterday morning and then it
> popped up on discuss-gnuradio. He must have seen it on Reddit as well.
>
> I have one on order too, and I was also contemplating a GNUradio driver...
> let me know if you want to coordinate.
>
> Sean
>
> -Original Message-
> From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org
> [mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On
> Behalf Of Andrew Davis
> Sent: Wednesday, March 21, 2012 9:34 PM
> To: David Kierzkowski; discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] This is nice
>
> Saw it on Reddit a couple days ago, already have one on order. Then I might
> work on making a GnuRadio driver or something for real-time use.
>
> On Wed, Mar 21, 2012 at 3:17 AM, David Kierzkowski 
> wrote:
>
> The osmocom guys are using a 20$ USB catv tuner as a RF source in gnuradio.
> 3.2MS/s !
>
> http://sdr.osmocom.org/trac/wiki/rtl-sdr
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>

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

Re: [Discuss-gnuradio] error while installing gnuradio 3.4.0 and jello(papyrus)

[Andrew Davis]

Use CMake to build, autotools are deprecated and are only used for
package building. They will be removed shortly to remove the
confusion.

On Thu, Mar 22, 2012 at 9:28 AM, sumitstop
 wrote:
>
> Hi ,
> Yesterday I was trying to install gnuradio 3.4.0.actually before that I
> patched the files from jello(https://www.cgran.org/wiki/UCSBJello)to the
> folder of gnuradio.
> after that I did ./configre , make .But during sudo make install it threw
> some error like this :
> 
>
> make[12]: Leaving directory
> `/home/sumit/Downloads/gnuradio-3.4.0/gnuradio-core/src/python/gnuradio/blks2impl'
> make[11]: Leaving directory
> `/home/sumit/Downloads/gnuradio-3.4.0/gnuradio-core/src/python/gnuradio/blks2impl'
> make[10]: Leaving directory
> `/home/sumit/Downloads/gnuradio-3.4.0/gnuradio-core/src/python/gnuradio/blks2impl'
> Making install in vocoder
> make[10]: Entering directory
> `/home/sumit/Downloads/gnuradio-3.4.0/gnuradio-core/src/python/gnuradio/vocoder'
> make  install-am
> make[11]: Entering directory
> `/home/sumit/Downloads/gnuradio-3.4.0/gnuradio-core/src/python/gnuradio/vocoder'
> make[12]: Entering directory
> `/home/sumit/Downloads/gnuradio-3.4.0/gnuradio-core/src/python/gnuradio/vocoder'
> make[12]: Nothing to be done for `install-exec-am'.
> test -z "/usr/local/lib/python2.6/dist-packages/gnuradio/vocoder" ||
> /bin/mkdir -p "/usr/local/lib/python2.6/dist-packages/gnuradio/vocoder"
>  /usr/bin/install -c -m 644 __init__.py
> '/usr/local/lib/python2.6/dist-packages/gnuradio/vocoder'
> Byte-compiling python modules...
> __init__.py
> Byte-compiling python modules (optimized versions) ...
> __init__.py
> make[12]: Leaving directory
> `/home/sumit/Downloads/gnuradio-3.4.0/gnuradio-core/src/python/gnuradio/vocoder'
> make[11]: Leaving directory
> `/home/sumit/Downloads/gnuradio-3.4.0/gnuradio-core/src/python/gnuradio/vocoder'
> make[10]: Leaving directory
> `/home/sumit/Downloads/gnuradio-3.4.0/gnuradio-core/src/python/gnuradio/vocoder'
> make[10]: Entering directory
> `/home/sumit/Downloads/gnuradio-3.4.0/gnuradio-core/src/python/gnuradio'
> make[11]: Entering directory
> `/home/sumit/Downloads/gnuradio-3.4.0/gnuradio-core/src/python/gnuradio'
> make[11]: Nothing to be done for `install-exec-am'.
> make[11]: *** No rule to make target `audio.py', needed by
> `install-grpythonPYTHON'.  Stop.
> make[11]: Leaving directory
> `/home/sumit/Downloads/gnuradio-3.4.0/gnuradio-core/src/python/gnuradio'
> make[10]: *** [install-am] Error 2
> make[10]: Leaving directory
> `/home/sumit/Downloads/gnuradio-3.4.0/gnuradio-core/src/python/gnuradio'
> make[9]: *** [install-recursive] Error 1
> make[9]: Leaving directory
> `/home/sumit/Downloads/gnuradio-3.4.0/gnuradio-core/src/python/gnuradio'
> make[8]: *** [install] Error 2
> make[8]: Leaving directory
> `/home/sumit/Downloads/gnuradio-3.4.0/gnuradio-core/src/python/gnuradio'
> make[7]: *** [install-recursive] Error 1
> make[7]: Leaving directory
> `/home/sumit/Downloads/gnuradio-3.4.0/gnuradio-core/src/python'
> make[6]: *** [install] Error 2
> make[6]: Leaving directory
> `/home/sumit/Downloads/gnuradio-3.4.0/gnuradio-core/src/python'
> make[5]: *** [install-recursive] Error 1
> make[5]: Leaving directory
> `/home/sumit/Downloads/gnuradio-3.4.0/gnuradio-core/src'
> make[4]: *** [install] Error 2
> make[4]: Leaving directory
> `/home/sumit/Downloads/gnuradio-3.4.0/gnuradio-core/src'
> make[3]: *** [install-recursive] Error 1
> make[3]: Leaving directory
> `/home/sumit/Downloads/gnuradio-3.4.0/gnuradio-core'
> make[2]: *** [install] Error 2
> make[2]: Leaving directory
> `/home/sumit/Downloads/gnuradio-3.4.0/gnuradio-core'
> make[1]: *** [install-recursive] Error 1
> make[1]: Leaving directory `/home/sumit/Downloads/gnuradio-3.4.0'
> make: *** [install] Error 2
> ~~~
>
> need a little help as I have to install this proper version of gnuradio
> only.
>
>
>
>
>
> -
> Sumit Kr.
> Research Assistant
> Communication Research center
> IIIT Hyderabad
> India
> --
> View this message in context: 
> http://old.nabble.com/error-while-installing-gnuradio-3.4.0-and-jello%28papyrus%29-tp33544622p33544622.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

Re: [Discuss-gnuradio] This is nice

[Andrew Davis]

>entirely agnostic about hardware

I thought that was the point of UHD?

Devices like Funcube and even a sound card with high sampling rates
should be considered when designing this framework as they all should
be selectable from a simple source/sink API. They could have
definitions and return sampling rates and such. I'll have to
brainstorm a bit for ideas...

~Andrew

On Thu, Mar 22, 2012 at 6:45 PM, Marcus D. Leech  wrote:
> On 03/22/2012 11:17 AM, Andrew Davis wrote:
>>
>> Right, but I think the idea here is for $20 why not?
>
> Right, for $20.00, why not indeed!  I just didn't want people making
> long-term plans based on something that amounts to
>  a serendipitous accident.
>
> I really don't think doing a UHD driver is the right approach, for reasons
> of maintenance headaches, and support headaches.
>
> But this *does* raise a bigger issue of perhaps needing an abstraction layer
> for "SDR-like" hardware sinks/sources for flow-graphs
>  that could reasonably be entirely agnostic about hardware.  Myself, I have
> a couple of "radio science" applications that try to
>  be agnostic by supported both UHD devices and gr-fcd--but that required two
> separate flow-graphs because there's no reasonable
>  way to abstract that stuff away, which I think is a shortcoming.
>
>
>
>> As far as a driver goes what they have now is a program that starts
>> the thing and tunes it, then reads samples, all of this is already
>> build into the UHD framework. I'm not sure but I would like to make
>> this a UHD compatible USB device. ( Much like the USRP1 )
>>
>> ~Andrew
>>
>> On Thu, Mar 22, 2012 at 11:06 AM,  wrote:
>>>
>>> I also have a trio on order.  The issues I can see surrounding this
>>> approach
>>> are:
>>>
>>>    o Consumer electronics parts lineups are capricious and
>>> unreliable--the
>>> target device may use the "SDR-capable chip" this month, and next month,
>>> they've found that they can shave $0.35 of off the B.O.M. by going with a
>>> totally different parts line-up they will, even though it will cost them
>>> $50K in engineering costs up front--they sell thousands and thousands a
>>> month.  There are already *TWO* versions of this dongle, one using the
>>> "good" RTL2832U chip, and the other using an Afatech chip (AF9015 or
>>> AF9035). The "magic sauce" that Antti discovered in the RTL2832U chip to
>>> do
>>> "raw samples" is peculiar to the RTL2832U chip, and doesn't necessarily
>>> map
>>> on to other DVB-T digital demod chips on the market.
>>>
>>>
>>>
>>>   o The 28.8MHz master oscillator is a very cheap 100PPM part, which will
>>> produce unpleasant frequency offsets, and phase-noise to match
>>>
>>>
>>>
>>>   o Not sure how good the noise figure is, since there's no LNA in front
>>> of
>>> the E4000 tuner chip.
>>>
>>>
>>>
>>>   o Don't know how they implement re-sampling.  If it's not done right,
>>> then
>>> there'll be nasty aliases in the passband handed to the host
>>>
>>>
>>>
>>> None of these are fatal, but be aware that the approach of "re-purposing"
>>> consumer electronics is fraught with dangers as described above.
>>>
>>>
>>>
>>> -Marcus
>>>
>>>
>>>
>>> On Thu, 22 Mar 2012 10:53:13 -0400, Tom Rondeau wrote:
>>>
>>> Andrew and Sean,
>>>
>>> Glad to hear you both thinking about doing this! Coordinate as you can
>>> and keep us up to date on the progress.
>>>
>>> Tom
>>>
>>>
>>> On Thu, Mar 22, 2012 at 10:45 AM, Nowlan, Sean
>>>   wrote:
>>>
>>> Funny enough, a coworker mentioned it to me yesterday morning and then it
>>> popped up on discuss-gnuradio. He must have seen it on Reddit as well.
>>>
>>> I have one on order too, and I was also contemplating a GNUradio
>>> driver...
>>> let me know if you want to coordinate.
>>>
>>> Sean
>>>
>>> -Original Message-
>>> From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org
>>> [mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On
>>> Behalf Of Andrew Davis
>>> Sent: Wednesday, March 21, 2012 9:34 PM
>>> To: David Kierzkowski; discuss-gnuradio@gnu.org
>>> Subject: Re: [Discuss-gnur

Re: [Discuss-gnuradio] RTL2832 ($20 USB SDR) support now in gr-baz

[Andrew Davis]

This kinda thing is gonna be incredibly useful even to us with USRP's.
I've been working on a digital voice mode but without a second
expensive USRP I have no way to know what I'm broadcasting or how
reliable the modulation is. The uses for cheap, semi-disposable SDR's
are limitless!

~Andrew

On Thu, Mar 29, 2012 at 12:43 PM, Rafael Diniz  wrote:
> Indeed, Fng awesome!
> Do you plan to submit upstream your gr-baz?
>
> People, in dealextreme store the dongle is sold out.
> I do not want to start an off-topic trend, but could you please mail me in
> private where are you buying such dongle?
>
> Best regards,
> Rafael Diniz
>
>> Awesome! I'm still waiting on my RTL-based card to arrive via snail-mail
>> from an unknown factory on the other side of the world. Will test when it
>> arrives!
>>
>> From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org
>> [mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On
>> Behalf Of Balint Seeber
>> Sent: Thursday, March 29, 2012 11:22 AM
>> To: discuss-gnuradio@gnu.org
>> Subject: [Discuss-gnuradio] RTL2832 ($20 USB SDR) support now in gr-baz
>>
>> Hi folks,
>>
>> I've just added RTL2832 support to gr-baz with support for both tuners
>> (Elonics E4000 and Fitipower FC0013).
>>
>> If you're not aware, this is sold as a DVB-T USB receiver for ~$20, which
>> is a pretty decent price for a device that can do general purpose SDR at
>> 3.2 MHz and 8-bits! The journey starts with Antti
>> Palosaari
>> who discovered it can be put in a mode where it streams baseband data
>> directly over USB (for analog FM demodulation in software). This resulted
>> in Steve Markgraf's rtl-sdr
>> user-space capture utility over at Osmocom (see the Osmocom page to find
>> compatible devices).
>>
>> I've taken that source and created a fully-featured GNU Radio Source block
>> 'baz.rtl_source_c' (with
>> GRC block) that outputs complex values, and allows adjustment of
>> frequency, sample rate and LNA gain. There is also an optional automatic
>> tuner mode control for the E4000. If you also like using
>> Winrad/HDSDR/WRplus, my ExtIO
>> plugin now has support for
>> the device too. The Source block performs internal multi-threaded
>> buffering for smoother performance (this might be over-engineered, but it
>> seemed to help with the ExtIO plugin).
>>
>> You can get the source code from my
>> SVN or
>> github (though please visit the info
>> page first for more
>> info/pre-reqs - e.g. libusb-1.0, etc). It's experimental, and not the
>> prettiest because I actually ported it back from the ExtIO plugin, but it
>> works for me and if you want to help test/clean it up then that would be
>> very much appreciated!
>>
>> To see it in action, have a peek here: http://youtu.be/FUQd9HOVTk8
>>
>> Balint @spenchdotnet
>> ___
>> 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] Reorganization and restructuring on 3.6 (master) and 3.7 (next) branches

[Andrew Davis]

> free weekend
I had one once!

So any plans for the application specific top-level blocks ( noaa,
pager, atsc )? I feel these could be moved to the CGRAN, or better yet
there could be a separate top-level folder for projects like this and
some of the GCRAN projects could be merged back into the main Gnuradio
git for better maintenance. ( A lot still use USRP instead of UHD and
even more still use autotools, this is giving me non-stop problems,
I'm working on updating a few ) Never hurts to have some well working
example projects showcasing Gnuradio!

On Thu, May 3, 2012 at 12:10 AM, Marcus D. Leech  wrote:
> On 03/05/12 12:07 AM, Josh Blum wrote:
>>
>> Just another free weekend, and I will have VOLK capable of generating
>> code to handle head and tail cases.
>>
>>
>>
> I once heard tell of this mythical "free weekend".  I don't believe in
> it.  It must be some kind of
>  fairy tale.
>
>
>
> --
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
>
> ___
> 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] blks2.pfb_arb_resampler segfault

[Andrew Davis]

I have a C++ port of optfir waiting to be merged you could look at:
https://github.com/glneo/gnuradio-davisaf/tree/master/gnuradio-core/src/lib/general,
it's in there, its the gr_optfir*. It has a few bug-fixes from the
python code.

On Sun, May 13, 2012 at 4:15 PM, Alexandru Csete  wrote:
> On Sun, May 13, 2012 at 5:52 PM, Tom Rondeau  wrote:
>> On Sun, May 13, 2012 at 11:33 AM, Alexandru Csete  wrote:
>>> I was implementing the two functions from blks2/pfb_arb_resampler.py
>>> in C++ and I noticed that the python code crashes for some reason. I
>>> was trying it using the attached GRC file.
>>>
>>> I think the C++ code itself is fine because it works with my C++
>>> implementation of pfb_arb_resampler_ccf and pfb_arb_resampler_fff, so
>>> the problem must be at the python level. One of the differences
>>> between my C++ implementation and the python code is that I use
>>> gr_firdes for generating the taps instead of optfir.
>>>
>>> Alex
>>
>> Yes, must be something with optfir producing badly formed taps in this
>> case. Can you create your own taps in the GRC graph and pass them to
>> the block?
>
> Hi Tom,
>
> Yes, using firdes to generate the taps works. So the problem must be
> in the optfir package.
>
> Alex
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

Re: [Discuss-gnuradio] Components needed for Ezcap EzTV dongle

[Andrew Davis]

Although they are not technically required, python-support,
gnuradio-companion, gr-utils, and gr-wxgui are almost necessary to get
anything interesting done. Also i'm not sure UHD is required for the
RTLSDR, I think it uses it's own module ( or just write samples to
disk and process later with Gnuradio ). It all depends on what you
want to do.

On Sun, May 13, 2012 at 10:58 PM, Phil  wrote:
> Once again, thank you for reading this.
>
> Installing the UHD library was painless and now I want to know which
> components I need to use my Ezcap EzTV dongle, when it eventually arrives.
>
> -- ##
> -- # Gnuradio enabled components
> -- ##
> --   * testing-support
> --   * volk
> --   * doxygen
> --   * gruel
> --   * gnuradio-core
> --   * gr-atsc
> --   * gr-audio
> --   * gr-digital
> --   * gr-noaa
> --   * gr-pager
> --   * gr-qtgui
> --   * gr-trellis
> --   * gr-uhd
> --   * gr-video-sdl
> --   * gr-vocoder
> --   * gr-fcd
> --   * gr-wavelet
> --
> -- ##
> -- # Gnuradio disabled components
> -- ##
> --   * python-support
> --   * gnuradio-companion
> --   * gr-comedi
> --   * gr-shd
> --   * gr-utils
> --   * gr-wxgui
> --
>
> --
> Regards,
> Phil
>
> ___
> 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] Components needed for Ezcap EzTV dongle

[Andrew Davis]

well lets start with the cmake output, post everything it says here
and lets see what up.

On Sun, May 13, 2012 at 11:43 PM, Phil  wrote:
> On 14/05/12 13:16, Andrew Davis wrote:
>>
>> Although they are not technically required, python-support,
>> gnuradio-companion, gr-utils, and gr-wxgui are almost necessary to get
>> anything interesting done. Also i'm not sure UHD is required for the
>> RTLSDR, I think it uses it's own module ( or just write samples to
>> disk and process later with Gnuradio ). It all depends on what you
>> want to do.
>>
>
> Thanks Andrew,
>
> I thought I read somewhere that UHD was required but I could very easily be
> mistaken. Perhaps someone who is using on of these dongles can let me know.
> Now to complete the next step.
>
> What do I need for Python support?
>
> What do I need for  gnuradio-companion support?
>
> What do I need for gr-utils support?
>
> What do I need for gr-wxgui support?
>
> I've installed several devel packages but evidently not the correct ones. By
> the way, I'm using Mageia version 1, a fork off Mandriva.
>
>
> --
> Regards,
> Phil
>
> ___
> 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] Gnuradio online fourum

[Andrew Davis]

Hello all,

I was thinking Gnuradio might benefit from an online message board
style forum. It would be easier for beginners not familiar with the
workings of mailing-lists and would IMHO allow for easier message
traversal for people to find previously solved problem. Has there been
any consideration of this? Maybe just a help forum and development
could still happen here.

Thanks.
~Andrew

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

Re: [Discuss-gnuradio] Too weak Tx power daughterboard problem

[Andrew Davis]

>Are some for sale?

Just the broken ones :)

On Tue, May 15, 2012 at 6:35 PM, Patrik Tast  wrote:
> Are some for sale?
>
> P
>
> - Original Message -
> From: Songsong Gee
> To: gnuradio mailing list
> Sent: Tuesday, May 15, 2012 20:57
> Subject: [Discuss-gnuradio] Too weak Tx power daughterboard problem
>
> I have more than eight RFX 2400 daughterboards
> and for a long time, I have left them unused.
>
> Recently, I have tested TxRx test with those DBs
> and only one transmits signal with a proper power level
> but others cannot generate a such power level
> In addition, some of them even cannot sense or receive signals.
> (All test environment, options are same.
> Actually, no options, means I used dafault value)
>
> It seems around one month has passed since I left them unused.
>
> Am I missing something?
> Say... kind of being assigned different options for not giving a specific
> option values?
> or just a static electricity, or pine pollen problem?
>
> What do you think of it.
> Thank you for your advices in advance
>
> --
> Seokseong Jeon
>
> 
>
> ___
> 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] WX GUI FFT Sink error

[Andrew Davis]

It's not OpenGL, it's badly designed OpenGL drivers, saying OpenGL
sucks is like saying C is slow, it can with a bad implementation, but
by its self no. Back on topic, I too have had all sorts of problems
like this with WX FFT, but it's a different error on each OS on each
system 0_o. I have to just use Baudline for my FFT ( much more useful
IMHO, but not open source :( )

On Tue, May 15, 2012 at 9:10 PM, Marcus D. Leech  wrote:
>>
>> Gee, Marcus. Tell us what you really think. ;)
>>
>> --n
>>
> I edited myself considerably :-)
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
>
> ___
> 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] WX GUI FFT Sink error

[Andrew Davis]

It's up to the driver writer to handle missing components properly,
Mesa has a full software OpenGL stack, I never thought about it but
i'll try using that and see what errors I get.

On Tue, May 15, 2012 at 10:30 PM, Marcus D. Leech  wrote:
>> It's not OpenGL, it's badly designed OpenGL drivers, saying OpenGL
>> sucks is like saying C is slow, it can with a bad implementation, but
>> by its self no. Back on topic, I too have had all sorts of problems
>> like this with WX FFT, but it's a different error on each OS on each
>> system 0_o. I have to just use Baudline for my FFT ( much more useful
>> IMHO, but not open source :( )
>>
> Well, if OpenGL simple turns every rendering task I ask it to do and defers
> to the hardware, then it isn't much good as a Graphics API.
>  If, however, it's intended to simply be a universal API for rendering
> *hardware*, then perhaps it's not appropriate to use it at all for
>  simple, uncomplicated, 2D tasks such as those asked of it by Gnu Radio.
>
> But if OpenGL is intended to be an environment for rendering various
> graphical concepts, using whatever optimizations happen to be
>  available to it, or not, then it fails.
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>

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

Re: [Discuss-gnuradio] WX GUI FFT Sink error

[Andrew Davis]

Success, with a pure software renderer WX FFT works. Not sure why the
Intel graphics drivers doesn't play nice, but I don't think the WXGUI
code is to blame ( not that I doubted you :). OP try switching drivers
and see what happens.

On Wed, May 16, 2012 at 11:30 AM, Nowlan, Sean
 wrote:
> Someone reads a lot of Dickens and Douglas Adams...
>
> -Original Message-
> From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org 
> [mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On 
> Behalf Of Marcus D. Leech
> Sent: Tuesday, May 15, 2012 9:01 PM
> To: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] WX GUI FFT Sink error
>
>>>
>> Been happening for me for years now. I dont think the persistence is
>> one of those cross GL features. Only available on some GPU cards, like
>> nvidia. The sink could stand to have a graceful try/except though...
>>
>> -josh
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
> Sweet jesuit crispies on a leprotic camel.  "Persistence" is a fairly simple 
> operation.  Why, I ask rhetorically, in holy heck, should it require
>   GD GPU support?  And if the GPU doesn't support it, GL can't do it in
> fakking *software*?   I used to think GL was cool, now I think it's
>   a festering sore, a blight on the landscape, a miserable piece of 
> ill-considered flotsam, bobbing up and down on a cesspool of its own
>   creation, a putrescent mound of worthless troll spittle.
>
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
>
> ___
> 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] WX GUI FFT Sink error

[Andrew Davis]

3D performance on everything else sucked, but the FFT was exactly the
same, I think it always uses software for line drawing, just the
software in the GPU drivers isn't as good as the full software driver.

To switch, just change the driver line in your xorg.conf, I changed
mine to " Driver "vesa" ", which changes the OpenGL stack to Mesa's
full software renderer.

On Wed, May 16, 2012 at 5:14 PM, Marcus D. Leech  wrote:
>> Success, with a pure software renderer WX FFT works. Not sure why the
>> Intel graphics drivers doesn't play nice, but I don't think the WXGUI
>> code is to blame ( not that I doubted you :). OP try switching drivers
>> and see what happens.
>>
> Hmm, I wonder what the effects on performance will be?
>
> How do you get the Mesa renderer installed on Linuxoid systems?
>
>
>> On Wed, May 16, 2012 at 11:30 AM, Nowlan, Sean
>>   wrote:
>>>
>>> Someone reads a lot of Dickens and Douglas Adams...
>>>
>>> -Original Message-
>>> From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org
>>> [mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On
>>> Behalf Of Marcus D. Leech
>>> Sent: Tuesday, May 15, 2012 9:01 PM
>>> To: discuss-gnuradio@gnu.org
>>> Subject: Re: [Discuss-gnuradio] WX GUI FFT Sink error
>>>
 Been happening for me for years now. I dont think the persistence is
 one of those cross GL features. Only available on some GPU cards, like
 nvidia. The sink could stand to have a graceful try/except though...

 -josh

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


>>> Sweet jesuit crispies on a leprotic camel.  "Persistence" is a fairly
>>> simple operation.  Why, I ask rhetorically, in holy heck, should it require
>>>   GD GPU support?  And if the GPU doesn't support it, GL can't do it in
>>> fakking *software*?   I used to think GL was cool, now I think it's
>>>   a festering sore, a blight on the landscape, a miserable piece of
>>> ill-considered flotsam, bobbing up and down on a cesspool of its own
>>>   creation, a putrescent mound of worthless troll spittle.
>>>
>>>
>>>
>>> --
>>> Marcus Leech
>>> Principal Investigator
>>> Shirleys Bay Radio Astronomy Consortium
>>> http://www.sbrac.org
>>>
>>>
>>>
>>> ___
>>> 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
>>
>>
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
>
> ___
> 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] WX GUI FFT Sink - error xorg.conf ?

[Andrew Davis]

https://wiki.archlinux.org/index.php/Xorg#Monitor_settings

This section should work for any modern X environment.

What we really need to do is find a way to just tell OpenGL to use
software only, I remember something about this from my video game days
( the GL in my email :) ) but cant seem to remember how

On Thu, May 17, 2012 at 3:54 PM, Alex DEKKER  wrote:
> On 17/05/12 19:33, William Pretty Security wrote:
>>
>> I did a "find -name" in my GnuRadio directories and couldn't find any
>> xorg.conf file.
>> I found a number of xorg.conf files, but none that seem to relate
>> specifically to GnuRadio ...
>>
>> Do I have to create one ??
>
>
> xorg.conf is a system-wide config file for the X server. You may have to
> create one as modern systems auto-detect as much as possible in order to
> avoid needing one. It has nothing to do with gnuradio.
>
>
> alexd
>
>
>
> ___
> 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_spectrum_sense.py

[Andrew Davis]

There has been a lot of discussion about getting useful output, most
of the threads never go anywhere ( or at least not enough ). What I
believe really must be done is remove the python <-> C++ callbacks and
re-write it in one language ( Something that wasn't possible when it
was written ), and it needs ether a GUI or some type of sudo-frequency
translator to put the output into a file that a FFT viewer can parse.

On Sat, May 19, 2012 at 4:26 AM, Abdelrahman Ahmed  wrote:
> i am new to this and don't have enough experience in programing?
> How to get output data from usrp_spectrum_sense.py and save it to file ?
> --
> Abdelrahman Ahmed
> Sent with Sparrow
>
>
> ___
> 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] Any friend working on Hydra from UT austin? How about the performance.

[Andrew Davis]

I would assume GNUradio's OFDM is mathematically identical to Hydra,
have you tired finding what settings ( Channel spacing, FFT size,
Number of sub-carriers, Sub-carrier modulation scheme, symbol length,
guard interval, Sub-carrier spacing, and FEC ) hydra uses and setting
GnuRadio to that. It should yield identical throughput.

On Wed, May 23, 2012 at 12:49 PM, Alex Zhang  wrote:
> Hi,
>
> Considering the GNURadio provided OFDM implementaiton is not so robust, and
> my test shows its limited performance (supporting bandwidth, packet loss
> rate, etc.), I would like to port the hydra to USRP2. Hydra claims that they
> support up to 5.4Mbps for SISO OFDM. But I am not sure anyone has verified
> it in your platform? I am concerned with the computing capability of the
> host-pc. Can it really support so high data rate running the hydra+GNURadio.
> My computer is i7 4Core @3.4GHz.
>
> --
>
> Alex,
> Dreams can come true – just believe.
>
>
> ___
> 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] Any friend working on Hydra from UT austin? How about the performance.

[Andrew Davis]

I only have one USRP, and I believe only like 2% of people here have
more than one for that kind of testing, so there's not many here with
answers in this case. I saw you last thread and felt bad no one knew
the answer. Although I believe the answer could be derived from the
available bandwidth and noise.

On Wed, May 23, 2012 at 7:56 PM, Alex Zhang  wrote:
> Thanks Andrew, i will try to manually adjust these parameters to find the
> optimized performance.
> But before that, I really want to know any existing benchmark on
> the performance over this GNURadio OFDM.
> For example, on what kind of host-pc, what kind data rate have you reached,
> with how much packet loss rate?
>
>
> On Wed, May 23, 2012 at 5:29 PM, Andrew Davis 
> wrote:
>>
>> I would assume GNUradio's OFDM is mathematically identical to Hydra,
>> have you tired finding what settings ( Channel spacing, FFT size,
>> Number of sub-carriers, Sub-carrier modulation scheme, symbol length,
>> guard interval, Sub-carrier spacing, and FEC ) hydra uses and setting
>> GnuRadio to that. It should yield identical throughput.
>>
>> On Wed, May 23, 2012 at 12:49 PM, Alex Zhang 
>> wrote:
>> > Hi,
>> >
>> > Considering the GNURadio provided OFDM implementaiton is not so robust,
>> > and
>> > my test shows its limited performance (supporting bandwidth, packet loss
>> > rate, etc.), I would like to port the hydra to USRP2. Hydra claims that
>> > they
>> > support up to 5.4Mbps for SISO OFDM. But I am not sure anyone has
>> > verified
>> > it in your platform? I am concerned with the computing capability of the
>> > host-pc. Can it really support so high data rate running the
>> > hydra+GNURadio.
>> > My computer is i7 4Core @3.4GHz.
>> >
>> > --
>> >
>> > Alex,
>> > Dreams can come true – just believe.
>> >
>> >
>> > ___
>> > Discuss-gnuradio mailing list
>> > Discuss-gnuradio@gnu.org
>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> >
>
>
>
>
> --
>
> Alex,
> Dreams can come true – just believe.
>

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

Re: [Discuss-gnuradio] Persistence causes glAccum exception

[Andrew Davis]

Other then the Mesa software only stack it does not work on any Intel
or ATI driver provided stack, but nVidia blob driver DOES support it.
WXFFT also maxes out my 2 core 3Ghz machine ( a lot of people often
get locked up i7's so this is a problem ), wxfft realy needs a c++
re-write if anything.

On Thu, May 24, 2012 at 9:44 PM, Marcus D. Leech  wrote:
> So, I did a quick "audit" this evening of four different machines in my
> house, running both Ubuntu recent and Fedora recent, but with
>  different generations of video hardware/motherboards, and tried the
> "Persistence" control on all of them.
>
> EVERY SINGLE ONE OF THEM failed, provoking an OpenGL exception from glAccum,
> which, it turns out, is an optional feature, and at least in
>  this little survey, not a single piece of my hardware supported that op.
>
> How many people actually use "persistence"?  (As opposed, I must be clear,
> to "Peak Hold").  I suspect that a workable approach is to,
>  for now, remove that feature entirely, but I don't have a good feel for who
> uses it.
>
> Near as I can tell, the "persistence" feature is intended to give a kind of
> storage-scope effect, or high-persistence phosphor effect.
>  But the "effect" uses a non-mandatory OpenGL feature (the accumulator
> buffer) which appears, at least on the garden-variety
>  video hardware I use, not to be supported.  And to be clear, I'm running
> modern motherboards on two of my systems, but using
>  the on-board video, since I'm not a gamer, and really, the simple 2D
> effects Gnu Radio uses aren't particularly taxing.
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
>
> ___
> 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] Baseband GPS OTA USRP capture that anyone can share?

[Andrew Davis]

I didn't see that may 9th post. I could get some samples ( USRP with
rubber duck with clear sky, would that work? ).

Does anyone know how to feed RTKNAVI? What format does the file need to be?

On Fri, May 25, 2012 at 12:06 AM, Chris Beaumont  wrote:
> Hello,
>
> A while ago (May 9) there was a post to the list about raw GPS data as
> captured by a USRP.
>
> These web pages may or may not be useful, I don't know if the data files on
> the first one are the right format for you (they were not captured by a
> USRP) but they may still be helpful.
>
> http://michelebavaro.blogspot.com/2012/04/spring-news-in-gnss-and-sdr-domain.html
>
> If not, Michele might be able to help point you to where you could find data
> that is.
>
> Also, you should check out this web page:
>
> http://gpspp.sakura.ne.jp/indexe.html
>
> Tomoji Takasu has done quite a bit of amazing stuff with GPS including SDR
> development. (you may have to dig a bit for it but its there)
>
> Between one or the other you should be able to find what you are looking
> for.
>
>
> On Mon, 2011-05-09 at 10:27 -0500, John Andrews wrote:
>> Hi,
>>
>> Is there is anyone here who has GPS OTA capture using USRP that they
>> are willing to share? I don't have a USRP and I am interested in
>> demodulating the GPS signal.
>
> ___
> 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] Shared Sources

[Andrew Davis]

I would recommend file sources, you can filter, graph and demod them
w/o hardware.

On Mon, Jun 4, 2012 at 10:32 AM, David Powell  wrote:
> Is there a list of tcp sources which are being openly shared? I just
> installed gnuradio and I don't have any hardware yet. I would like to be
> able to see live data so I can play around.
> ___
> 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] Error -- intel_do_flush_locked with V3.6.1git on Ubuntu 12.04

[Andrew Davis]

> intel_do_flush_locked failed: Invalid argument

This is a problem with Intel graphics drivers.

Switching to a software graphics stack ( Mesa ) worked for me.

On Tue, Jun 5, 2012 at 10:48 AM, Alexandru Csete  wrote:
> On Tue, Jun 5, 2012 at 4:39 PM, Michael Hartje
>  wrote:
>> Hello list readers,
>>
>> i tried to install on fresh LinuxMInt13 (a version of Ubuntu 12.04) to
>> compile and install with the build_gnuradio-script the new 3.6.1git
>> version out of the git archives. (not josh)
>>
>> it seems to me a good idea to add the prereqs liborc-0.4-dev.
>
> That wouldn't work with e.g. Ubuntu 11.04 because it has only orc
> 0.4.11 and both UHD and GNU Radio requires a version strictly greater
> than 0.4.11
>
>
>> This works really fine. Every thing seems to be ok, simple examples did
>> work (i.e. tone generator)
>>
>> But examples with FunCube Dongle or RTL-DVB-TStick showed a "hard" error
>> which closes the the actual running grc-program at start up time..
>>
>> Example: fcd_nbfm_rx.grc gives
>> Using Volk machine: sse2_32_orc
> gr_fir_fff: using SSE
>> intel_do_flush_locked failed: Invalid argument
>
> I haven't seen this error but I can assure you that the Funcube Dongle
> source will not work on systems with libusb-1.0.9. I will submit a
> patch for that soon - until then stick to the RTL device.
>
> Alex
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

Re: [Discuss-gnuradio] Question about OpenBTS

[Andrew Davis]

If it's with his own phones it's a grey area, for others obviously
it's not legal. USRP's can get into a grey area when not used as
"Testing Equipment" pursuant to
http://www.law.cornell.edu/cfr/text/47/15.121 .

To answer your question, both USRP1 & 2 can handle the signal, so it's
up to your preference. SMS-CB would most likely work for simple
messages.

On Tue, Jun 5, 2012 at 2:17 PM, hOWARD wONG
 wrote:
> On 6/5/2012 10:01 PM, Pan, Luyuan wrote:
>>
>> On 2012/6/4 23:28, Thomas Tsou wrote:
>>>
>>> On Sun, Jun 3, 2012 at 9:49 AM, Pan, Luyuan  wrote:

 Hello,
    I want to set up the OpenBTS, and I want to know which board is
 better,
 USRP1 or USRP2? Or any other suggestion? Thank you.
>>>
>>> Both USRP1 and USRP2 work with OpenBTS and neither can be considered
>>> "better" without describing your requirements. USRP2 / N2xx will
>>> support higher bandwidths with the GigE interface if that is important
>>> to you. USRP1 (or B100) will be cheaper. For stable clocking, the
>>> USRP1 requires hardware modification to support an external 52MHz
>>> clock signal. Other devices can use a more accessible internal or
>>> external 10 MHz reference source.
>>>
>>> Also, OpenBTS is not gnuradio, and the openbts-discuss or usrp-users
>>> lists may be better sources for that type of information.
>>>
>>> http://lists.sourceforge.net/lists/listinfo/openbts-discuss
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>   Thomas
>>
>> Sorry, This may not the proper place to ask question about OpenBTS, But I
>> just want to ask one more questions. My scenario is : I want to set up a
>> BTS, scan the user nearby and get their IMSI, then attract them to my fake
>> BTS and broadcast them a message.
>> 1. I want to use USRP1 to do the project, Is it enough? (I have both of
>> USRP1 and USRP2 at hand)
>> 2. Is it that SMS-CB a better choice for me? (my ultimate goal is to
>> broadcast some messages)
>> Thank you for your help!
>
>
> Is it legal to do that?
>
>
> ___
> 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] uhd_fft freezes after some seconds

[Andrew Davis]

You are almost certainly sampling faster than your computer can
handle, the queue gets backed up and WXFFT stops responding to GUI
messages, sample at a slower rate. My old PC can not do more than 1
Msps w/o locking up.

On Wed, Jun 6, 2012 at 4:11 AM, Luong Tan Phong  wrote:
> Hi lists,
>
> I've installed the lastest GNU Radio and UHD by build-gnuradio script on
> Ubuntu 12.04 LTS, everything is OK. I run the uhd_fft.grc example with
> samplerate is 25Msps and it works well but when I change the samplerate
> (different with 25 Msps), it just freezes after some seconds.
>
> Could you help me, please?
>
> Best regards,
>
> LTP
>
> ___
> 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] Simple FM receiver - one last question

[Andrew Davis]

gr_freq_xlating_fir_filter_xxx_0 is not connected, connect it to something.

On Sat, Jun 9, 2012 at 1:35 AM, Phil  wrote:
> Thank you for reading this.
>
> I have one last error to overcome:
>
> Error 0:
> Block - gr_freq_xlating_fir_filter_xxx_0 - Frequency Xlating FIR
> Filter(gr_freq_xlating_fir_filter_xxx):
>  Sink - in(0):
>    Port is not connected.
>
> Can anyone offer a suggestion that will sort this out?
>
> --
> Regards,
> Phil
>
> ___
> 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] rational resampler question

[Andrew Davis]

The rational resampler is part of BLKS2 which is python only. I'm
currently working on porting blks2 over to C++ so the API will not be
python only, but there is a lot of python code it is built on that
needs to be converted first so it could be a bit. You could just do it
yourself, all the rational resampler block does is make it easier for
you, http://www.dspguru.com/dsp/faqs/multirate/resampling , this is a
good starting point if you need, or you could look at the code for the
rational resampler and follow it.

Also the resampler base block, I believe is used by the python block
and cannot be used by itself.

On Tue, Jun 19, 2012 at 11:01 PM, Stephen  wrote:
>
> Hi,
>
> I'm trying to convert a flowgraph from grc to c++. In grc there is a
> rational resampler block and a rational resampler base block. I could
> not find a c++ version of the rational resampler block. Does a c++
> version exist? I don't much about either but I tried to use the rational
> resampler base block in both the grc flow graph and my c++ code and I
> could not get it to work in either. What's the difference between the two?
>
> Stephen
>
> ___
> 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] rational resampler question

[Andrew Davis]

>So I suppose if I do the same thing it would work right?

Only one way to find out, try it.

On Wed, Jun 20, 2012 at 11:02 PM, Stephen  wrote:
>
>
> On 6/19/2012 11:50 PM, Andrew Davis wrote:
>> The rational resampler is part of BLKS2 which is python only. I'm
>
> thanks for reminding me. I keep forgetting to look there.
>
>>
>> Also the resampler base block, I believe is used by the python block
>> and cannot be used by itself.
>
> In looking at the python code it looks like it could be used. It looks
> like all the python code does is create the filter taps and pass those
> taps to the resampler base block. So I suppose if I do the same thing it
> would work right?
>
> stephen

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

[Discuss-gnuradio] Remove USRP filters.

[Andrew Davis]

Hello all,

Not sure if this belongs here, but I found an old wireless gameboy
messager ( 
http://www.amazon.com/Game-Boy-Advance-Wireless-Messenger/dp/B0002IQOR8
) and would like to intercept the messages. It uses a CC1020 RF modem
in the 915MHz band. The problem is it uses FHSS in a 26Mhz bandwidth.
When listening with my USRP I get mostly aliasing noise form out of
band hops ( I can only hear 16MHz with the USRP ). I don't think I
need to find the hopping code as I can just listen to all channels at
once. So my plan is to somehow remove at least one stage of filtering
from the FPGA so I can sample at ~4MSPS and have all out of band
signals aliased into that bandwidth. My questions is can this be done
and is my DSP info correct ( Can this work? ).

Thank you all.

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

Re: [Discuss-gnuradio] Remove USRP filters.

[Andrew Davis]

Really cool presentation!  Thanks for the info. Now i'm running into
another problem, I sample at about 4MSPS for a bit and try to capture
the signal as it passes though my window, but I never seem to get it,
just a huge mess of noise, aliasing and ghosts.
http://i.imgur.com/w3oBP.jpg as you can see it looks like the are
about 400ms long bursts that just shake in frequencies, It also raises
the noise floor about 10db and throws images all over some lines break
up, I really can tell what i'm looking at, doesn't look like FHSS to
me. I think it is a really strong carrier just outside of the band
that causes all these images. I did capture what I think is a sync
preamble followed by FSK ( http://i.imgur.com/EpMim.jpg ) but as you
see it is mirrored many times all the way to the noise floor. Could
someone with more DSP background help me figure out what I am looking
at?

Thank you all
~Andrew

On Sun, Jul 1, 2012 at 4:10 PM, Michael Ossmann  wrote:
> On Sun, Jul 01, 2012 at 04:01:48PM -0400, Andrew Davis wrote:
>>
>> So my plan is to somehow remove at least one stage of filtering from
>> the FPGA so I can sample at ~4MSPS and have all out of band signals
>> aliased into that bandwidth. My questions is can this be done and is
>> my DSP info correct ( Can this work? ).
>
> I used that trick to sniff all Bluetooth channels with a single USRP2 a
> few years back.  I described the technique in this talk at ShmooCon 2009
> (179 MB):
>
> http://shmoocon.org/2009/videos/Bluetooth-Ossman.m4v
>
> I don't think you'll have to hack a daughterboard like I did, so you'll
> only need to work on the FPGA.  My old FPGA mod is here:
>
> http://gr-bluetooth.git.sourceforge.net/git/gitweb.cgi?p=gr-bluetooth/gr-bluetooth;a=blob_plain;f=doc/usrp2_alias.patch;hb=HEAD
>
> It is out of date, but you should be able to get the idea.  I just had
> to zero out some filter coefficients.

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

Re: [Discuss-gnuradio] Remove USRP filters.

[Andrew Davis]

>Are they supposed to be in 400ms long packets?

Well that is supposed to be the maximum time a FHSS is allowed to
dwell in a channel according to the FCC, so it makes sense.

>Do they use a slow FSK modulation?

According to the FCC test report is uses a CC1020 chip modem which in
its data sheet says it can use slow FSK.

> What daughterboard are you using?  Have you modified the FPGA?

WBX and nope.

> First there is a short burst I not sure about

I was thinking about using a 400ms hop time and I realized how long it
would take for synchronization to occur listening to any one
frequency, what I would do is use a quick burst on a listening
frequency to sync. That may be what that is?

> I read the time ruler in reverse.

Yeah it's strange, the waterfall is flowing up away from the
spectrogram ( as is should ), baudline is counting ms back in time
form the present ( I'm scrolling back in time to find the burst ).

I think I now need to find another old gameboy so I can start a
conversation between them to see if messages are plain text. I am
currently just probably getting the one announcing its presence
signal.

Thanks
~Andrew

On Mon, Jul 2, 2012 at 9:36 PM, Michael Ossmann  wrote:
> On Mon, Jul 02, 2012 at 08:27:01PM -0400, Andrew Davis wrote:
>>
>> Really cool presentation!  Thanks for the info. Now i'm running into
>> another problem, I sample at about 4MSPS for a bit and try to capture
>> the signal as it passes though my window, but I never seem to get it,
>> just a huge mess of noise, aliasing and ghosts.
>> http://i.imgur.com/w3oBP.jpg
>
> That actually doesn't look so bad to me.  Do you know anything about the
> transmissions from your target device?  Are they supposed to be in 400
> ms long packets?  Do they use a slow FSK modulation?  Are packets
> supposed to happen as often as every 600 ms?  If you don't know that
> stuff, try looking up the FCC test report for the device.
>
> You can ignore all the spurs and images in the frequency domain that are
> 20 dB or more below the loudest thing going on at any particular moment.
> You'll see stuff like that with a USRP, much more so when you are
> intentionally aliasing.
>
> What daughterboard are you using?  Have you modified the FPGA?
>
>> I really can tell what i'm looking at, doesn't look like FHSS to me.
>
> It does to me.  First there is a short burst I not sure about, but then
> there are two events of the same duration, the first was received at a
> lower power than the second.  The first event could be a packet outside
> your band that you are not receiving properly, and the second is within
> your band.  Oh, sorry.  I read the time ruler in reverse.
>
>> I did capture what I think is a sync preamble followed by FSK (
>> http://i.imgur.com/EpMim.jpg )
>
> That looks beautiful!  Except I think it is the time ruler itself that
> is reversed, not my reading of it.  The image is much lower power than
> the main signal.  Just ignore it.  That packet is decodable by eyeball
> in the spectrogram, which is kind of a rare treat.
>
> Throw that thing into grc and decode it!  :-)
>
> If you need help, post the raw file shown in EpMim.jpg somewhere.

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

Re: [Discuss-gnuradio] PCI Express SDR Cards and GNU Radio

[Andrew Davis]

Nice pic Tom! FTA:

>It could only capture a narrow slice of spectrum: 100 kHz at most. That was 
>enough for Law and Order reruns..

How does that work :)

~Andrew

On Sat, Jul 7, 2012 at 9:22 AM, ikjtel  wrote:
>
>
>> It has a photo of *both*
>
> Well, two separate photos, if one wanted to be technical ;-)
>
> Max
>
>
> ___
> 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] Spectrum Analyser Output from XCVR2450

[Andrew Davis]

> my J1 port is lower then that of my J2 port! About 30dB lower!

Are you transmitting out of your J1 port? 30dB sounds like cross talk
on a non-transmitting port.

>One thing i've started to notice is that as I step up the uhd gain the 
>readings I get on the spectrum analyser do not appear to linear.

I'm not sure if this is exactly right, but it has been said before,
the USRP is not testing equipment, it is a radio, so the gains and
frequencies may not be perfectly calibrated.

On Mon, Jul 9, 2012 at 7:08 AM, Michael Hill  wrote:
> I'm doing a bunch of testing on the USRP N210 with the XCVR2450.
> In particular i'm looking at areas where there is odd behaviour at extremes
> etc and at trying to put it in context.
>
> One thing i've started to notice is that as I step up the uhd gain the
> readings I get on the spectrum analyser do not appear to linear.
> Is this correct? E.g. if I go up by 10dB, I get about 7 or 8dB increase in
> the output measured. It of course becomes non-linear as it approaches the
> maximum of 35dB.
>
> Another odd observation i've made with mine is that the power I get coming
> out of my J1 port is lower then that of my J2 port! About 30dB lower!
> Is this normal? I hope I haven't damaged my device in some way.. :/
>
>
>
>
>
> ___
> 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] Wxgui strange problem

[Andrew Davis]

Hello all,

I just freshly installed Xubuntu 11.10 and installed Gnuradio with the
build_gnuradio script with out any problems. When I use uhd_fft.py or any
program that uses the FFT sink ( all other sinks work ) I get a very
strange problem, as long as some part of the FFT plots line is hidden it
will run with no problems, but a soon as I change a parameter which results
in the showing of the entire blue line from start to finish it crashes with
no errors ( just falls back to prompt quietly ). I can change the gain so
the line comes up into view and when it does it crashes, I can also scale
the plot down until the line is completely shown or scale up to the line or
even just change to a frequency with a higher noise level, the result is
the same, if the line is completely on the screen it crashes. I'm not sure
where to start with this one, I don't know if it's in Wxgui or WX itself,
or something with my system. How should I start finding the problem?

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

Re: [Discuss-gnuradio] Wxgui strange problem

[Andrew Davis]

libwxbase2.8-dev - 2.8.11.0-0ubuntu10
wx2.8-headers - 2.8.11.0-0ubuntu10
libwxbase2.8-0 - 2.8.11.0-0ubuntu10
libwxgtk2.8-dev
python-wxgtk2.8
python-gnuradio-wxgui - 3.2.2.dfsg-1ubuntu7
python-gnuradio-core - 3.2.2.dfsg-1ubuntu7

I'm not sure how to find what checkout I'm using.

On Mon, Dec 19, 2011 at 1:34 PM, Ben Hilburn  wrote:

> Andrew -
>
> It would probably be helpful if we could confirm that someone else with
> the same setup sees the same issue.
>
> What versions of of the WX libraries and development packages do you have
> installed?  What checkout of GNU Radio do you have?  What about the
> relevant Python packages?
>
> Cheers,
> Ben
>
>
> On Sun, Dec 18, 2011 at 12:53 PM, Andrew Davis wrote:
>
>> Hello all,
>>
>> I just freshly installed Xubuntu 11.10 and installed Gnuradio with the
>> build_gnuradio script with out any problems. When I use uhd_fft.py or any
>> program that uses the FFT sink ( all other sinks work ) I get a very
>> strange problem, as long as some part of the FFT plots line is hidden it
>> will run with no problems, but a soon as I change a parameter which results
>> in the showing of the entire blue line from start to finish it crashes with
>> no errors ( just falls back to prompt quietly ). I can change the gain so
>> the line comes up into view and when it does it crashes, I can also scale
>> the plot down until the line is completely shown or scale up to the line or
>> even just change to a frequency with a higher noise level, the result is
>> the same, if the line is completely on the screen it crashes. I'm not sure
>> where to start with this one, I don't know if it's in Wxgui or WX itself,
>> or something with my system. How should I start finding the problem?
>>
>> Thank you all. <http://www.sbrac.org/files/build-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] UHD default subdevice.

[Andrew Davis]

Hello all,

Some programs don't let you specify a subdevice, they let UHD decide, in my
case it picks wrong. Is there a uhd config file to chose the default
subdevice if one is not specified ( I also wouldn't have to type "--spec
"A:0" so much ).

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

Re: [Discuss-gnuradio] UHD default subdevice.

[Andrew Davis]

Could you give me a hint? How do you interface with UHD before a C++/python
program requests the device?

On Fri, Dec 23, 2011 at 3:21 PM, Marcus D. Leech  wrote:

> > Hello all,
> >
> > Some programs don't let you specify a subdevice, they let UHD decide,
> > in my case it picks wrong. Is there a uhd config file to chose the
> > default subdevice if one is not specified ( I also wouldn't have to
> > type "--spec "A:0" so much ).
> >
> > Thank you!
> You could always write a little startup script that provides all the
> defaults you want.
>
>
>
> --
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] UHD default subdevice.

[Andrew Davis]

I see what your saying but typing "--address 'type=usrp1' --spec 'A:0'
--antenna 'TX/RX'" every time wasn't my problem.
The problem is programs that let UHD pick the default device, I don't know
how UHD chooses but it could check ~/.uhd/uhd.conf
or something instead of guessing. As you said I could just fix the
programs, but many of them are not maintained and why
fix up useless old programs when I could be fixing UHD which is still
maintained and would fix the old programs in the process.
Same for main GNUradio programs, the default device/subdevice/antenna
parser options could be read from a config file too.
So does this already exist somewhere or how can I help implement it?



On Fri, Dec 23, 2011 at 5:13 PM, Marcus D. Leech  wrote:

> Could you give me a hint? How do you interface with UHD before a
>> C++/python program requests the device?
>>
>>
>>  Well, you complained about having to "type --spec A:0" a lot, which is a
> natural for a shell script that starts your program--whether that
>  program is written in C++ or Python, and simply pass in a fixed value for
> "the --spec" option to the program you're trying to run.
>
> For example, any of the setup parameters (well, *most*) of a
> uhd_usrp_source or uhd_usrp_sink can be taken from a variable or
> command-line
>  parameter, using the "variables" section in GRC, so you make them come
> from command-line parameters, and default those
>  parameters, and again, you can make it fancier with a shell script
> surrounding the invocation of the target program.  In fact,
>  I have one startup script that parses the output of "uhd_usrp_probe" to
> determine what cards I'm dealing with, and set command-line
>  parameters appropriately from parsing the output of "uhd_usrp_probe".
>  I'm also working on an easier-to-use little python program
>  that is intended to set a bunch of shell variables based on probing the
> hardware and setting a bunch of standard variables--specifically
>  to support better autoconfiguration from within shell scripts, etc.
>
> If the target program *doesn't support* the parameter you want as a
> command-line parameter, then *add it*, and submit it
>  to be folded back in to the mainline.  I recently did this for uhd_fft.py
> and rx_cfile.py to support the "sc8" alternative wire-format, which is
>  necessary to support 33.33Msps and 50Msps sample rates out of USRP2/N2XX.
>
> --
> Marcus Leech
>
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] UHD default subdevice.

[Andrew Davis]

That might work, but why worry about people who reconfigure just yet, us
who use the device consistently still have to type several args every-time
we run a program, the first step is a simple default device config file.

On Fri, Dec 23, 2011 at 9:09 PM, Tom Rondeau  wrote:

> On Fri, Dec 23, 2011 at 8:23 PM, Andrew Davis wrote:
>
>> I see what your saying but typing "--address 'type=usrp1' --spec 'A:0'
>> --antenna 'TX/RX'" every time wasn't my problem.
>> The problem is programs that let UHD pick the default device, I don't
>> know how UHD chooses but it could check ~/.uhd/uhd.conf
>> or something instead of guessing. As you said I could just fix the
>> programs, but many of them are not maintained and why
>> fix up useless old programs when I could be fixing UHD which is still
>> maintained and would fix the old programs in the process.
>> Same for main GNUradio programs, the default device/subdevice/antenna
>> parser options could be read from a config file too.
>> So does this already exist somewhere or how can I help implement it?
>
>
> An interesting proposition. The problem is that the modularity of the
> USRPs allows people to switch daughterboards easily and quickly. How would
> you propose to set the defaults if people change their d'boards? Some kind
> of a hash on the description of the device to see if it's the same USRP and
> d'board configuraiton?
>
> Tom
>
>
>
>>
>>
>> On Fri, Dec 23, 2011 at 5:13 PM, Marcus D. Leech wrote:
>>
>>>  Could you give me a hint? How do you interface with UHD before a
>>>> C++/python program requests the device?
>>>>
>>>>
>>>>  Well, you complained about having to "type --spec A:0" a lot, which is
>>> a natural for a shell script that starts your program--whether that
>>>  program is written in C++ or Python, and simply pass in a fixed value
>>> for "the --spec" option to the program you're trying to run.
>>>
>>> For example, any of the setup parameters (well, *most*) of a
>>> uhd_usrp_source or uhd_usrp_sink can be taken from a variable or
>>> command-line
>>>  parameter, using the "variables" section in GRC, so you make them come
>>> from command-line parameters, and default those
>>>  parameters, and again, you can make it fancier with a shell script
>>> surrounding the invocation of the target program.  In fact,
>>>  I have one startup script that parses the output of "uhd_usrp_probe" to
>>> determine what cards I'm dealing with, and set command-line
>>>  parameters appropriately from parsing the output of "uhd_usrp_probe".
>>>  I'm also working on an easier-to-use little python program
>>>  that is intended to set a bunch of shell variables based on probing the
>>> hardware and setting a bunch of standard variables--specifically
>>>  to support better autoconfiguration from within shell scripts, etc.
>>>
>>> If the target program *doesn't support* the parameter you want as a
>>> command-line parameter, then *add it*, and submit it
>>>  to be folded back in to the mainline.  I recently did this for
>>> uhd_fft.py and rx_cfile.py to support the "sc8" alternative wire-format,
>>> which is
>>>  necessary to support 33.33Msps and 50Msps sample rates out of
>>> USRP2/N2XX.
>>>
>>> --
>>> Marcus Leech
>>>
>>> Principal Investigator
>>> Shirleys Bay Radio Astronomy Consortium
>>> http://www.sbrac.org
>>>
>>>
>>>
>>
>> ___
>> 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] UHD default subdevice.

[Andrew Davis]

What I'm proposing is simply for the UHD, when not given a specific device,
to check for a configuration file ( in the users home directory preferably
) and load its default device and settings. This way if you dont have this
config file it will still make up the default device ( I believe this is
ordered by a hash as my B side d'board is first for some reason ). So my
guess it to read in the config when UHD pulls devices off the device hash
table. Also it cannot be a command parameter as this would bring us back to
square-one as some 3rd party programs will not support it and will offer no
easy way to change what UHD picks.

On Fri, Dec 23, 2011 at 10:18 PM, Tom Rondeau wrote:

> On Fri, Dec 23, 2011 at 9:23 PM, Andrew Davis wrote:
>
>> That might work, but why worry about people who reconfigure just yet, us
>> who use the device consistently still have to type several args every-time
>> we run a program, the first step is a simple default device config file.
>>
>
> I'm more concerned that changing the default would screw up people who
> change their d'boards. Or are you suggesting we have a config file that you
> would enter as the parameter (-F ~/.gnuradio/usrp.conf)?
>
> Would you be up for outlining the process that would go in to creating and
> using the file? What exactly would be automated? How would people set the
> defaults and decide to use them or not? That type of thing.
>
> Of course, in the meantime, you could create a file that just contains a
> line of the standard parameters (-a, -A, --subdev, etc.) and use `cat file`
> in the command line to put it inline with command. Or make a shell script
> with the program with the parameters already specified (with the $* for any
> extras you want to put in). I'm not suggesting these as a real solution,
> but they might help you temporarily.
>
> Tom
>
>
>
>
>>  On Fri, Dec 23, 2011 at 9:09 PM, Tom Rondeau wrote:
>>
>>> On Fri, Dec 23, 2011 at 8:23 PM, Andrew Davis 
>>> wrote:
>>>
>>>> I see what your saying but typing "--address 'type=usrp1' --spec 'A:0'
>>>> --antenna 'TX/RX'" every time wasn't my problem.
>>>> The problem is programs that let UHD pick the default device, I don't
>>>> know how UHD chooses but it could check ~/.uhd/uhd.conf
>>>> or something instead of guessing. As you said I could just fix the
>>>> programs, but many of them are not maintained and why
>>>> fix up useless old programs when I could be fixing UHD which is still
>>>> maintained and would fix the old programs in the process.
>>>> Same for main GNUradio programs, the default device/subdevice/antenna
>>>> parser options could be read from a config file too.
>>>> So does this already exist somewhere or how can I help implement it?
>>>
>>>
>>> An interesting proposition. The problem is that the modularity of the
>>> USRPs allows people to switch daughterboards easily and quickly. How would
>>> you propose to set the defaults if people change their d'boards? Some kind
>>> of a hash on the description of the device to see if it's the same USRP and
>>> d'board configuraiton?
>>>
>>> Tom
>>>
>>>
>>>
>>>>
>>>>
>>>> On Fri, Dec 23, 2011 at 5:13 PM, Marcus D. Leech wrote:
>>>>
>>>>>  Could you give me a hint? How do you interface with UHD before a
>>>>>> C++/python program requests the device?
>>>>>>
>>>>>>
>>>>>>  Well, you complained about having to "type --spec A:0" a lot, which
>>>>> is a natural for a shell script that starts your program--whether that
>>>>>  program is written in C++ or Python, and simply pass in a fixed value
>>>>> for "the --spec" option to the program you're trying to run.
>>>>>
>>>>> For example, any of the setup parameters (well, *most*) of a
>>>>> uhd_usrp_source or uhd_usrp_sink can be taken from a variable or
>>>>> command-line
>>>>>  parameter, using the "variables" section in GRC, so you make them
>>>>> come from command-line parameters, and default those
>>>>>  parameters, and again, you can make it fancier with a shell script
>>>>> surrounding the invocation of the target program.  In fact,
>>>>>  I have one startup script that parses the output of "uhd_usrp_probe"
>>>>> to determine what cards I'm dealing with, and s

Re: [Discuss-gnuradio] UHD default subdevice.

[Andrew Davis]

It's going to have to be part of UHD because a lot of programs I'm having
problems with are not using GNUradio, they just read from UHD. UHD guesses
on a lot of things ( device, sub-device, antenna, fpga image, fpga
frequency etc. ) when not defined in the program, currently it's up to the
program to ask the user for these and set them, but some programs built for
one persons needs have built-in defaults or simply let UHD guess and on
there system it guesses right but on mine it often doesn't. Also I'm having
problems with the order of commands sent to UHD, some programs converted
from the usrp-driver set frequency out of order with sub-device selection,
this is OK if your sub-devices support the same range but mine do not and
this causes problems so I have to rewrite programs ordering. The better way
I believe is to send a list of settings to UHD and let it put things in
order, this might make the list of setting in a config file easier to parse
also. We could also have a seperate GNUradio config file that the python
OptionParser class reads in first for some GNUradio program specific
defaults ( fft-size, fft-rate... ).


As you said it should look to UHD_CONFIG_DIR or GNURADIO_CONFIG_DIR first
then check other spots. Also I don't think anything will have to be done in
python as UHD already returns its selection to python when you ask for a
device.

On Wed, Dec 28, 2011 at 9:39 PM, Tom Rondeau  wrote:

> On Sat, Dec 24, 2011 at 6:52 AM, Andrew Davis wrote:
>
>> What I'm proposing is simply for the UHD, when not given a specific
>> device, to check for a configuration file ( in the users home directory
>> preferably ) and load its default device and settings. This way if you dont
>> have this config file it will still make up the default device ( I believe
>> this is ordered by a hash as my B side d'board is first for some reason ).
>> So my guess it to read in the config when UHD pulls devices off the device
>> hash table. Also it cannot be a command parameter as this would bring us
>> back to square-one as some 3rd party programs will not support it and will
>> offer no easy way to change what UHD picks.
>>
>
> Ok, so here's what I'm seeing now. We have the program options interface
> and on top of that, we have a check for a config file. This config file
> should work with the standard directory look-up path: current dir, home
> dir, system dir (maybe /etc/gnuradio [and a Windows equivalent] and
> possibly set with a GNURADIO_CONFIG_DIR -- will want to think on that more
> to make sure we support other environmental variables like that).
>
> We should have a function defined in GNU Radio that parses this file. It
> would take in a dictionary, or kwargs (we have used
> the _modulator_class.extract_kwargs_from_options(options) to convert the
> 'options' object from the OptionParser class to kwargs). If the config file
> is not found, nothing happens. If there is a config file but they option
> has already been set through the command line, then the command-line value
> should supersede the file. Otherwise, the dictionary is updated to include
> the new setting.
>
> Of course, I'm using dictionary in the sense of Python, and this kind of
> function would be trivial to write in Python, but we'd want to do it in C++
> for anyone working in that domain.
>
> Tom
>
>
>
>
>> On Fri, Dec 23, 2011 at 10:18 PM, Tom Rondeau wrote:
>>
>>> On Fri, Dec 23, 2011 at 9:23 PM, Andrew Davis 
>>> wrote:
>>>
>>>> That might work, but why worry about people who reconfigure just yet,
>>>> us who use the device consistently still have to type several args
>>>> every-time we run a program, the first step is a simple default device
>>>> config file.
>>>>
>>>
>>> I'm more concerned that changing the default would screw up people who
>>> change their d'boards. Or are you suggesting we have a config file that you
>>> would enter as the parameter (-F ~/.gnuradio/usrp.conf)?
>>>
>>> Would you be up for outlining the process that would go in to creating
>>> and using the file? What exactly would be automated? How would people set
>>> the defaults and decide to use them or not? That type of thing.
>>>
>>> Of course, in the meantime, you could create a file that just contains a
>>> line of the standard parameters (-a, -A, --subdev, etc.) and use `cat file`
>>> in the command line to put it inline with command. Or make a shell script
>>> with the program with the parameters already specified (with the $* for any
>>> extras you want to put in). I'm not suggesting these as a real solution,
&

Re: [Discuss-gnuradio] UHD default subdevice.

[Andrew Davis]

I will, but a lot are unmaintained. This is something that UHD should do
anyway, and if it helps eliminate bad code then it's a win-win situation.
Theres really no reason a program should have to ask for and set every UHD
variable every time, this just adds a lot of clutter at the top of a
program and if you don't have ALL variables user settable, someone
somewhere with an oddball setup will have to rewrite every program they use
for there setup, or they could just edit the default config file. Much
simpler.

On Thu, Dec 29, 2011 at 1:00 PM, Matt Mills  wrote:

> On Thu, Dec 29, 2011 at 9:27 AM, Andrew Davis wrote:
>
>> It's going to have to be part of UHD because a lot of programs I'm having
>> problems with are not using GNUradio, they just read from UHD.
>>
>
>  It seems like there is a lot of effort going into fixing problems with
> bad code; Perhaps these are issues you should take up with the developers
> of those applications that are not written correctly.
>
> -Matt.
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GR standard UHD options parser module (was UHD default subdevice.)

[Andrew Davis]

Very true, all of it, GNUradio is quite the hodgepodge of different APIs,
Languages, and Ideas.
And that's not always a bad thing, it can allow great flexibility, but
sadly it is currently doing the opposite. With required versions of SWIG,
Python 2.x/3.x and other helper programs it ONLY compiles reliably on
ubuntu and fedora, and only Ubuntu, not kubuntu or Xubuntu as the small
differences in GTK versions break most of wxgui. I am also a die-hard
FreeBSD user forced into Ubuntu as no other operating system can compile
GNUradio since 3.2. OK sorry for the rant.

What we are here to fix in this thread is the program to hardware
incompatibility, as stated earlier many programs are created for one device
configuration. UHD solves this though a unified interface to hardware with
many settable parameters for anyone's hardware. The problem comes about
when programers, not considering outside use of there work, do not extend
control to the user and hard-code the parameters into there code. The way I
believe it should be done is the programmer simple asks UHD for the default
device, and UHD looks to a config file and finds what device, sub-device,
and antenna to use. The programmer could of course overwrite this and tell
UHD specifically what it wants for special cases. Now the lazy programmer
just trying to get it working will not have to write out a long program
header reading command line arguments and setting up the device in code but
simply ask for a device and he can set what device it will return in the
config file. This will motivate programmers to write more compatible code
as it will be the easier route to simply ask for and setup a default device.

For the Python world we do need a more standardized option parser set, so
that every program will not need that long command reading header but a
simple call to a command parser.

Also I noticed a patch was submitted that fixed a problem with the new
uhd_rx_cfile.py, before it was setting the gain before it picked out the
sub-device, with the USRP1 being the only device with two sides this bug
will only effect USRP1 users. This is the kind of thing that can be fixed
by giving UHD a set of parameters and then letting it turn them on in order
( GAIN 45, WBX, 192.168.1.44, TX/RX, SIDE B, 250ks/s ).

On Fri, Dec 30, 2011 at 2:18 PM, LRK  wrote:

> On Thu, Dec 29, 2011 at 07:01:19PM -0500, Marcus D. Leech wrote:
> > On 29/12/11 06:48 PM, Tom Rondeau wrote:
> > >
> > >
> > > I absolutely agree on this. We should definitely have a standard uhd
> > > options parser that we can pull in to any program using a uhd device.
> > > Excellent suggestion.
> > >
> > > If we have/had one for GNU Radio before, I never used it or knew about
> > > it. Having recently just fixed most of the examples, I never ran
> > > across it, either. We do have a preferred style and suggested options
> > > in our style guide on the Wiki, though.
> > >
> > > For this, we probably don't have enough general use options to have a
> > > default GR options parser module, though. We should definitely make a
> > > UHD one though.
> > That was my suspicion--that there just aren't really any "general" Gnu
> > Radio options, except perhaps for scheduler
> >   tweaks (TPB vs not-TPB is the only one I can think of).
>
> I keep thinking this may be a reason for the lower interest in GnuRadio.
> If someone writes a program to run on a USRP2 and daughterboard and I want
> to run it on my USRP1, the UHD part should take care of the differences
> if the frequencies and such are compatible. The computer should be able
> to tell what hardware is connected and use the appropriate parts or
> default to the most likely.
>
> I finally got programs to work with UHD and my USRP1 but only after much
> searching and adding command-line info. I know I'm old school, but the
> computer is supposed to work for the user as best it can rather than the
> user having to work for the computer. This, of course, is about the
> programming but I spend far too much time trying to get older programs
> to work because of some update that breaks everything.
>
> If I find some neat new block in GRC I spend way too much time trying to
> figure out what parameters to enter rather than tweaking default params.
> Of course the error messages are seldom useful either. The uhd_fft.py
> finally worked on my 3 GHz 4-core machine after I figured out the options
> but just hung when I clicked on anything. Seem to be the frame rate problem
> which should have been fixed long ago.
>
> It is hardly worth updating the hardware if the same problems will be
> encountered. I'm afraid to update Ubuntu or GnuRadio at the moment since
> my experiments will likely be stopped again. I have some programs I run
> under FreeBSD, since that is my preferred OS, but I can't update any of
> them because GnuRadio won't compile there at all since 3.2.2. Most of the
> problems are probably like the header files in the TCP sink code when
> something was probably "updated

Re: [Discuss-gnuradio] Gnu Radio architecture, etc

[Andrew Davis]

Well it's not the language choice, it's all the helper programs that are
version locked that annoy me most. Python is in a weird state of limbo
right now with the version 3 switchover. Many systems are defaulting to
python 3 and we should probably do the same. Python would work great if I
was just putting together an FM radio by connecting blocks, but for any
more computational advanced program I would want to switch to C++. GNUradio
is almost catered to Pyhton, this should not be the case, it should be
modular so I can call it from any scripting language or GRC. For just
connecting blocks Python has way too much overhead, a simpler scripting
environment would suffice. Then for more advance programs you almost have
to switch to C++. Take usrp_spectrum_sence for example, this program has
it's own block ( bin_statistics ) that has no use other than basically
being the heart of usrp_spectrum_sence, it just shows python isn't up to
the task of real DSP work beyond just connecting real C++ code. Whats
needed is a common block connecting API that can be run directly from GRC
without using python as an intermediary. Without the need for python/swig
we eliminate a great deal of version locking and system incompatibility.


On Fri, Dec 30, 2011 at 3:45 PM, Marcus D. Leech  wrote:

> Very true, all of it, GNUradio is quite the hodgepodge of different APIs,
>> Languages, and Ideas.
>> And that's not always a bad thing, it can allow great flexibility, but
>> sadly it is currently doing the opposite. With required versions of SWIG,
>> Python 2.x/3.x and other helper programs it ONLY compiles reliably on
>> ubuntu and fedora, and only Ubuntu, not kubuntu or Xubuntu as the small
>> differences in GTK versions break most of wxgui. I am also a die-hard
>> FreeBSD user forced into Ubuntu as no other operating system can compile
>> GNUradio since 3.2. OK sorry for the rant.
>>
> See my earlier rant about "shoulders of giants".
>
> I think that what happens for *some* people is that Gnu Radio isn't
> written using their programming language/paradigm of choice.
>  To *them* it's "obvious it should have been written in
> {C,C++,Ruby,Java,Fortran,**Pascal,Erlang,Cobol} and I can't understand why
>  these Gnu Radio idiots picked Python/C++".  I admit that back in 2005,
> when I first started using Gnu Radio, I was resentful of
>  the choice of Python/C++.  Two languages that I was ill-prepared for.  I
> spend most of my professional life coding in C, with
>  occasional excursions into C++.  Gnu Radio forced me to learn enough
> Python to get by.  Now, I love it.  I find that I'm much more
>  likely to write a "throw away" program in Python than C these days, and
> I've been a C programmer since 1979!  I taught my son
>  Python when he was 8.  He still loves it at nearly-14, and even taught
> Python to his class-mates when he was at a private school.
>
> With the advent of GRC, you don't even have to know Python or C++ to
> accomplish a great deal of stuff.  If the "plugging lego together"
>  paradigm isn't "natural" or is too restricting, you can always program in
> a soup of Python and C++.  It's all doable.
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
>
> __**_
> 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 standard UHD options parser module

[Andrew Davis]

It's not a problem with not having a script for FreeBSD, it simple cannot
be made to compile reasonably in its current state for a lot of systems do
to required versions of programs and such. I think i'm going to go try to
install it again today and make a list of problems and solutions, my goal
at some point is to put 3.3.0 or newer in the FreeBSD ports tree.

On Fri, Dec 30, 2011 at 3:35 PM, Marcus D. Leech  wrote:

> Andrew Davis  writes:
>>
>>> FreeBSD user forced into Ubuntu as no other operating system can compile
>>> GNUradio since 3.2. OK sorry for the rant.
>>>
>> It does build here on debian unstable.
>>
>> __**_
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/**listinfo/discuss-gnuradio<https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
>>
>>
>>  It compiles and builds on Fedora 12-16, and Ubuntu 9.04 to 11.10, and
> many other Linux variants.  But the
>  *build-gnuradio* script only deals with Fedora and Ubuntu, because:
>
>   o The biggest swath of Linux-using population for Gnu Radio uses Fedora
> and Ubuntu--biggest bang for the buck
>   o The author of that script (me) happens to be a user of Fedora
> (primarily) and Ubuntu (secondarily), so
>  had familiarity with the "build recipes" for those two distributions.
>
> I've always said that I invite patches that give a matching "recipe" (as
> embodied in the shell script) for other
>  Linux distributions.  I'm not any kind of Fedora/Ubuntu purist fanboy.
>  That's just what I happen to have been
>  familiar with when I wrote build-gnuradio.
>
> And you don't *have* to use build-gnuradio.  There are "recipes" for a
> number of Linux distributions up on the
>  website for those who want to go the manual route (and testing and
> inevitable tweaking of those recipes
>  when they're incorrect or out-of-date).  I can't maintain those recipes
> myself--Fedora and Ubuntu are enough
>  work by themselves.
>
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
>
> __**_
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/**listinfo/discuss-gnuradio<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] building under FreeBSD

[Andrew Davis]

For us following along at home, do you think you could give us a running
command list? I just finished getting UHD installed with just "cmake
-DLIBUSB_INCLUDE_DIR=/usr/include -DLIBUSB_LIBRARIES=/usr/lib/
libusb.so ../" , someone should put UHD in the ports collection, it
compiles very easily. But now I'm stuck in a dependency hell with qwt and
pyQwt5, what versions do you have installed? None of them seem to include
the headers, is there a dev package that installs the headers?


On Sat, Jan 7, 2012 at 10:28 AM, LRK  wrote:

> On Thu, Jan 05, 2012 at 09:52:11AM -0600, LRK wrote:
> >
> >   The current GnuRadio now builds under FreeBSD using my script. Volk
> > is disabled in my script because it did not build and I have not looked
> > into that.
>
> Ok, I enable volk again and find this:
>
>
> g++ -DHAVE_CONFIG_H -I. -I..  -DBOOST_TEST_DYN_LINK -DBOOST_TEST_MAIN
> -I../inclu
> de -I../lib -I/usr/local/include  -I../gen/include -I../include
> -Dvolk_EXPORTS -
> fvisibility=hidden-g -O2 -nostdinc++ -I/usr/include/c++/4.2.2
> -I/usr/include
> /c++/4.2.2/ -MT testqa-testqa.o -MD -MP -MF .deps/testqa-testqa.Tpo -c -o
> testqa
> -testqa.o `test -f 'testqa.cc' || echo './'`testqa.cc
>
> qa_utils.h:4:19: error: cstdlib: No such file or directory
> qa_utils.h:5:18: error: string: No such file or directory
> qa_utils.h:6:18: error: vector: No such file or directory
> ../include/volk/volk_complex.h:22:19: error: complex: No such file or
> directory
> /usr/local/include/boost/config/select_stdlib_config.hpp:17:19: error:
> cstddef:
> No such file or directory
> /usr/local/include/boost/config/no_tr1/utility.hpp:21:21: error: utility:
> No suc
> h file or directory
>
> The errors are due to the code looking for files in /usr/include/c++/4.2.2
> which are installed in /usr/include/c++/4.2
> FreeBSD uses gcc 4.2.2 in the kernel code and gcc46 installed from the
> port,
> normally only used by some ports.
>
> /usr/include/c++/4.2/tr1/cstdlib
> /usr/include/c++/4.2/cstdlib
> /usr/local/include/boost/compatibility/cpp_c_headers/cstdlib
> /usr/local/lib/gcc46/include/c++/tr1/cstdlib
> /usr/local/lib/gcc46/include/c++/cstdlib
> /usr/src/contrib/libstdc++/include/tr1/cstdlib
> /usr/X11R6/include/boost/compatibility/cpp_c_headers/cstdlib
> /usr/X11R6/lib/gcc46/include/c++/tr1/cstdlib
> /usr/X11R6/lib/gcc46/include/c++/cstdlib
>
> If I make a link so 4.2.2 is there pointing to the 4.2 directory, it
> compiles, with only 23 warnings about volk.
>
> The autotools build installs and it runs dial_tone.py so it looks better.
>
> The cmake build does not install the gnuradio stuff in the site-packages
> directory in PYTHONPATH like autotools did. I found the way to put the
> GR_PREFIX in for the other installs but not the PYTHONPATH part.
>
> Onward..
>
>
> --
> LRK
> gr-user . ovillatx.sytes.net
>
> ___
> 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] building under FreeBSD

[Andrew Davis]

I dont think this is BSD related but ./configure cant find the qwt headers
"checking qwt/qwt_math.h presence... no", they are in
"/usr/local/include/qwt/qwt_math". --with-qwt-incdir=/usr/local/include/qwt
fixes that, but then it doesn't find the libs in /usr/local, it finds other
libs in there but not qwt ( and libqwt.so is present )? I tried --prefix
/usr/local but that does nothing. Any Ideas on why qwt is so special?

On Sat, Jan 7, 2012 at 5:04 PM, Tom Rondeau  wrote:

> On Sat, Jan 7, 2012 at 1:53 PM, Andrew Davis wrote:
>
>> For us following along at home, do you think you could give us a running
>> command list? I just finished getting UHD installed with just "cmake
>> -DLIBUSB_INCLUDE_DIR=/usr/include -DLIBUSB_LIBRARIES=/usr/lib/
>> libusb.so ../" , someone should put UHD in the ports collection, it
>> compiles very easily. But now I'm stuck in a dependency hell with qwt and
>> pyQwt5, what versions do you have installed? None of them seem to include
>> the headers, is there a dev package that installs the headers?
>>
>
> We will also want to put any of these instruction onto the Build Guide on
> gnuradio.org.
>
> We should also work out any of these details in the code where we can and
> where they make sense.
>
> Thanks for pushing on this!
>
> Tom
>
>
>
>
>> On Sat, Jan 7, 2012 at 10:28 AM, LRK  wrote:
>>
>>> On Thu, Jan 05, 2012 at 09:52:11AM -0600, LRK wrote:
>>> >
>>> >   The current GnuRadio now builds under FreeBSD using my script. Volk
>>> > is disabled in my script because it did not build and I have not looked
>>> > into that.
>>>
>>> Ok, I enable volk again and find this:
>>>
>>>
>>> g++ -DHAVE_CONFIG_H -I. -I..  -DBOOST_TEST_DYN_LINK -DBOOST_TEST_MAIN
>>> -I../inclu
>>> de -I../lib -I/usr/local/include  -I../gen/include -I../include
>>> -Dvolk_EXPORTS -
>>> fvisibility=hidden-g -O2 -nostdinc++ -I/usr/include/c++/4.2.2
>>> -I/usr/include
>>> /c++/4.2.2/ -MT testqa-testqa.o -MD -MP -MF .deps/testqa-testqa.Tpo -c
>>> -o testqa
>>> -testqa.o `test -f 'testqa.cc' || echo './'`testqa.cc
>>>
>>> qa_utils.h:4:19: error: cstdlib: No such file or directory
>>> qa_utils.h:5:18: error: string: No such file or directory
>>> qa_utils.h:6:18: error: vector: No such file or directory
>>> ../include/volk/volk_complex.h:22:19: error: complex: No such file or
>>> directory
>>> /usr/local/include/boost/config/select_stdlib_config.hpp:17:19: error:
>>> cstddef:
>>> No such file or directory
>>> /usr/local/include/boost/config/no_tr1/utility.hpp:21:21: error:
>>> utility: No suc
>>> h file or directory
>>>
>>> The errors are due to the code looking for files in
>>> /usr/include/c++/4.2.2
>>> which are installed in /usr/include/c++/4.2
>>> FreeBSD uses gcc 4.2.2 in the kernel code and gcc46 installed from the
>>> port,
>>> normally only used by some ports.
>>>
>>> /usr/include/c++/4.2/tr1/cstdlib
>>> /usr/include/c++/4.2/cstdlib
>>> /usr/local/include/boost/compatibility/cpp_c_headers/cstdlib
>>> /usr/local/lib/gcc46/include/c++/tr1/cstdlib
>>> /usr/local/lib/gcc46/include/c++/cstdlib
>>> /usr/src/contrib/libstdc++/include/tr1/cstdlib
>>> /usr/X11R6/include/boost/compatibility/cpp_c_headers/cstdlib
>>> /usr/X11R6/lib/gcc46/include/c++/tr1/cstdlib
>>> /usr/X11R6/lib/gcc46/include/c++/cstdlib
>>>
>>> If I make a link so 4.2.2 is there pointing to the 4.2 directory, it
>>> compiles, with only 23 warnings about volk.
>>>
>>> The autotools build installs and it runs dial_tone.py so it looks better.
>>>
>>> The cmake build does not install the gnuradio stuff in the site-packages
>>> directory in PYTHONPATH like autotools did. I found the way to put the
>>> GR_PREFIX in for the other installs but not the PYTHONPATH part.
>>>
>>> Onward..
>>>
>>>
>>> --
>>> LRK
>>> gr-user . ovillatx.sytes.net
>>>
>>> ___
>>> 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] building under FreeBSD

[Andrew Davis]

Also I'm trying to make UHD install with ports, this will be useful to
projects that use USRP hardware without GNUradio and the GNUradio port can
pull this in as a dependency so it can be made with it, but I cant find
where the tarballs are at, github has releases but they use some rediection
so I cant pin down exactly where there at, does anyone have a mirror with
"uhd-3.3.1.tar.gz" or similar file on it?

On Sat, Jan 7, 2012 at 6:10 PM, Andrew Davis wrote:

> I dont think this is BSD related but ./configure cant find the qwt headers
> "checking qwt/qwt_math.h presence... no", they are in
> "/usr/local/include/qwt/qwt_math". --with-qwt-incdir=/usr/local/include/qwt
> fixes that, but then it doesn't find the libs in /usr/local, it finds other
> libs in there but not qwt ( and libqwt.so is present )? I tried --prefix
> /usr/local but that does nothing. Any Ideas on why qwt is so special?
>
>
> On Sat, Jan 7, 2012 at 5:04 PM, Tom Rondeau wrote:
>
>> On Sat, Jan 7, 2012 at 1:53 PM, Andrew Davis wrote:
>>
>>> For us following along at home, do you think you could give us a running
>>> command list? I just finished getting UHD installed with just "cmake
>>> -DLIBUSB_INCLUDE_DIR=/usr/include -DLIBUSB_LIBRARIES=/usr/lib/
>>> libusb.so ../" , someone should put UHD in the ports collection, it
>>> compiles very easily. But now I'm stuck in a dependency hell with qwt and
>>> pyQwt5, what versions do you have installed? None of them seem to include
>>> the headers, is there a dev package that installs the headers?
>>>
>>
>> We will also want to put any of these instruction onto the Build Guide on
>> gnuradio.org.
>>
>> We should also work out any of these details in the code where we can and
>> where they make sense.
>>
>> Thanks for pushing on this!
>>
>> Tom
>>
>>
>>
>>
>>> On Sat, Jan 7, 2012 at 10:28 AM, LRK  wrote:
>>>
>>>> On Thu, Jan 05, 2012 at 09:52:11AM -0600, LRK wrote:
>>>> >
>>>> >   The current GnuRadio now builds under FreeBSD using my script. Volk
>>>> > is disabled in my script because it did not build and I have not
>>>> looked
>>>> > into that.
>>>>
>>>> Ok, I enable volk again and find this:
>>>>
>>>>
>>>> g++ -DHAVE_CONFIG_H -I. -I..  -DBOOST_TEST_DYN_LINK -DBOOST_TEST_MAIN
>>>> -I../inclu
>>>> de -I../lib -I/usr/local/include  -I../gen/include -I../include
>>>> -Dvolk_EXPORTS -
>>>> fvisibility=hidden-g -O2 -nostdinc++ -I/usr/include/c++/4.2.2
>>>> -I/usr/include
>>>> /c++/4.2.2/ -MT testqa-testqa.o -MD -MP -MF .deps/testqa-testqa.Tpo -c
>>>> -o testqa
>>>> -testqa.o `test -f 'testqa.cc' || echo './'`testqa.cc
>>>>
>>>> qa_utils.h:4:19: error: cstdlib: No such file or directory
>>>> qa_utils.h:5:18: error: string: No such file or directory
>>>> qa_utils.h:6:18: error: vector: No such file or directory
>>>> ../include/volk/volk_complex.h:22:19: error: complex: No such file or
>>>> directory
>>>> /usr/local/include/boost/config/select_stdlib_config.hpp:17:19: error:
>>>> cstddef:
>>>> No such file or directory
>>>> /usr/local/include/boost/config/no_tr1/utility.hpp:21:21: error:
>>>> utility: No suc
>>>> h file or directory
>>>>
>>>> The errors are due to the code looking for files in
>>>> /usr/include/c++/4.2.2
>>>> which are installed in /usr/include/c++/4.2
>>>> FreeBSD uses gcc 4.2.2 in the kernel code and gcc46 installed from the
>>>> port,
>>>> normally only used by some ports.
>>>>
>>>> /usr/include/c++/4.2/tr1/cstdlib
>>>> /usr/include/c++/4.2/cstdlib
>>>> /usr/local/include/boost/compatibility/cpp_c_headers/cstdlib
>>>> /usr/local/lib/gcc46/include/c++/tr1/cstdlib
>>>> /usr/local/lib/gcc46/include/c++/cstdlib
>>>> /usr/src/contrib/libstdc++/include/tr1/cstdlib
>>>> /usr/X11R6/include/boost/compatibility/cpp_c_headers/cstdlib
>>>> /usr/X11R6/lib/gcc46/include/c++/tr1/cstdlib
>>>> /usr/X11R6/lib/gcc46/include/c++/cstdlib
>>>>
>>>> If I make a link so 4.2.2 is there pointing to the 4.2 directory, it
>>>> compiles, with only 23 warnings about volk.
>>>>
>>>> The autotools build installs and it runs dial_tone.py so it looks
>>>> better.
>>>>
>>>> The cmake build does not install the gnuradio stuff in the site-packages
>>>> directory in PYTHONPATH like autotools did. I found the way to put the
>>>> GR_PREFIX in for the other installs but not the PYTHONPATH part.
>>>>
>>>> Onward..
>>>>
>>>>
>>>> --
>>>> LRK
>>>> gr-user . ovillatx.sytes.net
>>>>
>>>> ___
>>>> 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] build UHD on FreeBSD 8.x

[Andrew Davis]

Great, I cant wait for the script, but also maybe we could work on a
Makefile so we could update the ports, i'm working on one but cant find
tarballs for UHD, the links are all redirects and the tarball name changes,
there really should be a "uhd-3.3.1.tar.gz" somewhere. After that just "cd
/usr/ports/comms/gnuradio && sudo make install clean"

On Tue, Jan 10, 2012 at 5:08 PM, LRK  wrote:

>
>  I did a fresh git clone of UHD this morning. Using my script to build
> it, there was a problem finding Cheetah. After trying the usual suspects,
> I deinstalled and newly installed cheetah (py27-cheetah-2.4.4). That did
> the trick although I don't know why.
>
>  Here is the list:
>
> -- ##
> -- # UHD enabled components
> -- ##
> --   * LibUHD
> --   * Examples
> --   * Utils
> --   * Tests
> --   * ORC
> --   * USB
> --   * USRP1
> --   * USRP2
> --   * B100
> --
> -- ##
> -- # UHD disabled components
> -- ##
> --   * Manual
> --   * Doxygen
> --   * E100
> --   * USRP-E Utils
> --
> -- Building version: 003.004.000-3ebc4ed
>
>
> --
> LRK
> gr-user . ovillatx.sytes.net
>
> ___
> 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] build UHD on FreeBSD 8.x

[Andrew Davis]

Well for GnuRadio, the 3.5.1 tarball is probably close enough to just add a
FreeBSD patch to the port and use it. For UHD I'm still looking for a
stable tarball somewhere, maybe someone could put up a mirror of UHD 3.3.1
on the GnuRadio site so I can finish the port Makefile.

On Wed, Jan 11, 2012 at 12:45 AM, LRK  wrote:

> On Tue, Jan 10, 2012 at 08:46:55PM -0500, Andrew Davis wrote:
> >
> > Great, I cant wait for the script, but also maybe we could work on a
> > Makefile so we could update the ports, i'm working on one but cant find
> > tarballs for UHD, the links are all redirects and the tarball name
> changes,
> > there really should be a "uhd-3.3.1.tar.gz" somewhere. After that just
> "cd
> > /usr/ports/comms/gnuradio && sudo make install clean"
>
> The script gets simpler as the bugs are fixed. Mine run under tcsh, though.
> UHD did install at $GR_PREFIX with "-DCMAKE_INSTALL_PREFIX=$GR_PREFIX" on
> cmake and the GnuRadio build found it. Getting close.
>
> The tarball may be a problem for UHD. The pointers found them but they were
> not named with the 'tar.gz' or 'tgz' suffix. FreeBSD ports need to have a
> stable one available somewhere. GnuRadio so far has the tarball of the
> 3.2.2 release still in the same place, I think. It needed a lot of patches.
>
>
> --
> LRK
> gr-user . ovillatx.sytes.net
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] cmake build gnuradio on FreeBSD

[Andrew Davis]

Yeah, I asked about that earlier, for some reason qwt is hard coded to
/usr/include in the configure script. It really should just use the system
path and not check just one predefined path, this also is a problem on
Gentoo and any other OS that uses "/usr/local/" instead of "/usr/".

What the configure script should do is make two C programs:

#include < qwt/qwt_math.h >

and

#include < qwt5/qwt_math.h >

then see which compiles to find the qwt include folder name, or just not
check and assume the first as that is what the code expects and most
systems do anyway. Checking breaks more systems than it helps at this
point, if anyone uses qwt5 directory they should just change it themselves.

On Wed, Jan 11, 2012 at 9:55 AM, LRK  wrote:

>
>  I do not find anything in the README about qt4 or qwt but they seem
> to be required for gr-qtgui.
>
>  I used portinstall to install py27-qt4 and several hours and 57 packages
> later, cmake could find qt4.
>
>  Then I installed py27-pyqwt and it also installed qwt-5.2.2. Cmake
> still would not find qwt. (QWT_FOUND = FALSE).
>
>  I finally tried adding the QWT_INCLUDE_DIRS line below and cmake now
> finds qwt and shows gr-qtgui to be built. Trying that next.
>
>cmake \
>  -DCMAKE_INSTALL_PREFIX=$GR_PREFIX \
>  -DQWT_INCLUDE_DIRS=/usr/local/include/qwt \
>  ../
>
>
> --
> LRK
> gr-user . ovillatx.sytes.net
>
> ___
> 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] cmake build gnuradio on FreeBSD

[Andrew Davis]

It worked for me other than the qwt so I think so.

On Wed, Jan 11, 2012 at 12:40 PM, Josh Blum  wrote:

>
>
> On 01/11/2012 06:55 AM, LRK wrote:
> >
> >   I do not find anything in the README about qt4 or qwt but they seem
> > to be required for gr-qtgui.
> >
> >   I used portinstall to install py27-qt4 and several hours and 57
> packages
> > later, cmake could find qt4.
> >
> >   Then I installed py27-pyqwt and it also installed qwt-5.2.2. Cmake
> > still would not find qwt. (QWT_FOUND = FALSE).
> >
> >   I finally tried adding the QWT_INCLUDE_DIRS line below and cmake now
> > finds qwt and shows gr-qtgui to be built. Trying that next.
> >
> > cmake \
> >   -DCMAKE_INSTALL_PREFIX=$GR_PREFIX \
> >   -DQWT_INCLUDE_DIRS=/usr/local/include/qwt \
> >   ../
> >
> >
>
> On this branch, I have 2 patches.
>
> http://gnuradio.org/cgit/jblum.git/commit/?h=freebsd_tweaks&id=ca3868256079060993ebb643e34b39c558052ce0
>
> 1) make qwt find script better. Its fixes the need to manually specify
> -DQWT_INCLUDE_DIRS
>
> 2) Use CLOCK_GETTIME and not MACH_ABSOLUTE_TIME. Question: Did gr-qtgui
> compile for you without this change? In other words, does your OS have
> mach kernel headers?
>
> -Josh
>
> ___
> 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] cmake build gnuradio on FreeBSD

[Andrew Davis]

I did that and is works, I was just saying that's the only thing that is
keeping it from being a simple "./configure  && make install".

On Thu, Jan 12, 2012 at 8:56 PM, Tom Rondeau  wrote:

> On Wed, Jan 11, 2012 at 9:27 PM, Andrew Davis wrote:
>
>> It worked for me other than the qwt so I think so.
>
>
> Just a quick explanation here. Qwt has a very simple, kind of non-standard
> installation that's hard to generalize. They don't use standard tools for
> auto-discovery of the lib or include paths, so we search the "common"
> locations for it.
>
> You should be able to pass this information to the configure scripts. I
> don't know what these parameters are off the top of my head, though.
>
> Tom
>
>
>
>
>> On Wed, Jan 11, 2012 at 12:40 PM, Josh Blum  wrote:
>>
>>>
>>>
>>> On 01/11/2012 06:55 AM, LRK wrote:
>>> >
>>> >   I do not find anything in the README about qt4 or qwt but they seem
>>> > to be required for gr-qtgui.
>>> >
>>> >   I used portinstall to install py27-qt4 and several hours and 57
>>> packages
>>> > later, cmake could find qt4.
>>> >
>>> >   Then I installed py27-pyqwt and it also installed qwt-5.2.2. Cmake
>>> > still would not find qwt. (QWT_FOUND = FALSE).
>>> >
>>> >   I finally tried adding the QWT_INCLUDE_DIRS line below and cmake now
>>> > finds qwt and shows gr-qtgui to be built. Trying that next.
>>> >
>>> > cmake \
>>> >   -DCMAKE_INSTALL_PREFIX=$GR_PREFIX \
>>> >   -DQWT_INCLUDE_DIRS=/usr/local/include/qwt \
>>> >   ../
>>> >
>>> >
>>>
>>> On this branch, I have 2 patches.
>>>
>>> http://gnuradio.org/cgit/jblum.git/commit/?h=freebsd_tweaks&id=ca3868256079060993ebb643e34b39c558052ce0
>>>
>>> 1) make qwt find script better. Its fixes the need to manually specify
>>> -DQWT_INCLUDE_DIRS
>>>
>>> 2) Use CLOCK_GETTIME and not MACH_ABSOLUTE_TIME. Question: Did gr-qtgui
>>> compile for you without this change? In other words, does your OS have
>>> mach kernel headers?
>>>
>>> -Josh
>>>
>>> ___
>>> 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] FreeBSD build instructions in wiki

[Andrew Davis]

Hello all,

I have added some simple build instructions for FreeBSD to the wiki :
http://gnuradio.org/redmine/projects/gnuradio/wiki/FreeBSDInstall
These are off the top of my head as I do not have access right now to a
clean FreeBSD install to test, If someone could walk though them on a clean
system and record all dependencies that would help. I will do it my self at
the end of the week ether way, Also if you see anything wrong please do
tell.

I hope we can get the instructrions down to just typing "cd
/usr/ports/comms/gnuradio && sudo make install clean" but until I hope this
helps.

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

Re: [Discuss-gnuradio] Error while using uhd usrp blocks

[Andrew Davis]

Type " uhd_find_devices " into console, then " uhd_usrp_probe " then give
us the results, and the code for the program you're trying to run.

On Fri, Jan 27, 2012 at 9:39 AM, shashank gaur wrote:

> Hello
>
> I am simply trying to build a transmitter and receiver for bpsk modulation
> and demodulation using mpsk receiver at receiving end. I am using USRP1
> (Flex900 Daughter boards))with Gnuradio Companion 3.5.0rc0 on Ubuntu 10.10.
> When I run either (trransmitter or receiver) of any grc applications first
> the grc executes it successfully and when I run other the grc gives
> following error.
> linux; GNU C++ version 4.4.5; Boost_104200; UHD_003.003.001-8ff8f20
>
> Traceback (most recent call last):
>   File "/home/sunny/Examples/top_block.py", line 105, in 
> tb = top_block()
>   File "/home/sunny/Examples/top_block.py", line 40, in __init__
> num_channels=1,
>   File "/usr/local/lib/python2.6/dist-packages/gnuradio/uhd/__init__.py",
> line 93, in constructor_interceptor
> return old_constructor(*args, **kwargs)
>   File "/usr/local/lib/python2.6/dist-packages/gnuradio/uhd/uhd_swig.py",
> line 2003, in usrp_sink
> return _uhd_swig.usrp_sink(*args, **kwargs)
> RuntimeError: LookupError: KeyError: No devices found for ->
> Device Address:
> serial: 4d9de875
>
>
> I think it has something to do with USRP UHD Source/Sink block parameters.
> Either the grc is not able to recognize the daughter board or there is
> problem with hardware. may be I am wrong.
> Please help me to recognize the error.
> Thank you very much for your time
> Shashank Gaur
>
> ___
> 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] Running tunnel.py/benchmark_tx.py (OFDM) with XCVR2450?

[Andrew Davis]

>One thing that I noticed was that the --tx-amp=0.8. That's very high for
OFDM with it's large PAPR.

I'm thinking that too, there really should be some kind of warning when you
drive the DAC to saturation.

If you need more range use an external amp.

On Tue, Jan 31, 2012 at 8:28 AM, Tom Rondeau  wrote:

> On Mon, Jan 30, 2012 at 11:12 AM, Martin Braun wrote:
>
>> On Mon, Jan 30, 2012 at 04:11:05PM +0100, Florian Schlembach wrote:
>> > We have now extended our tests to the tests with two USRP2s with
>> > daughterboards: Neither the benchmark_tx.py example nor the tunnel.py is
>> > receiving any packets. We checked the spectrum and tuned the gains as
>> well.
>> > (OFDM)
>> >
>> > Now, we played with the benchmark files and tunnel.py located in the
>> narrowband
>> > folder and therefore changed the modulation scheme from BPSK to GMSK and
>> > ultimately receiving all the packets!! That's strange.
>> >
>> > Does anybody knows what code be the problem that we can't establish any
>> > connection using higher order modulation schemes? Could it possibly be
>> our
>> > slightly outdated UHD version?
>> >
>> > We are totally clueless, so we appreciate any idea/help!
>>
>> This won't really help, but I remember we had exactly the same troubles
>> here.
>> This was before UHD was even released, so I doubt that's the reason.
>> Unfortunately, I can't remember how (or: if) we fixed it :( but I'll
>> keep you updated if my memory comes up with something.
>>
>> But fiddling with gain values is often useful; even if you've already
>> done that I recommend trying again, by reducing tx-amplitude and the
>> actual gain values, shifting the terminals around (perhaps they're too
>> close?).
>>
>> MB
>>
>
>
> The benchmark OFDM scripts were made as simple examples of OFDM and were
> not made very robust. I can get them working within an office space fairly
> easily, but I seem to be the only one. When I moved everything over the
> using the UHD interface, I tested everything OTA successfully, so they do
> still work.
>
> One thing that I noticed was that the --tx-amp=0.8. That's very high for
> OFDM with it's large PAPR. Try backing off on that (to around 0.2 - 0.3)
> and try again. You won't get much range from this signal, though.
>
> Tom
>
>
> ___
> 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] Running tunnel.py/benchmark_tx.py (OFDM) with XCVR2450?

[Andrew Davis]

That's kinda odd now that I think about it, I had a similar problem and on
an oscilloscope it looked like DAC clipping, but I could have been
non-linearity in the final amp, what kind of problems do XCVR2450 have at
high outputs?

On Tue, Jan 31, 2012 at 9:00 AM, Marcus D. Leech  wrote:

> **
> On 31/01/12 08:37 AM, Andrew Davis wrote:
>
> >One thing that I noticed was that the --tx-amp=0.8. That's very high for
> OFDM with it's large PAPR.
>
>  I'm thinking that too, there really should be some kind of warning when
> you drive the DAC to saturation.
>
> It's not the DAC that's typically the problem, it's the final RF amplifier
> on the daughter-card, and
>   that's not precisely predictable from the software side.
>
>
>
> --
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
>
>
> ___
> 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] software for antenna designers

[Andrew Davis]

Well the core ( nec2 ) is open source and so runs on linux, but your GUI (
EZNEC+ ) is not. You could try Wine, I believe 4nec2 works well with it,
4nec2 is a much more advanced program too.

On Tue, Jan 31, 2012 at 7:48 PM, Patrik Tast wrote:

> **
> Hi All,
>
> Do you know of an/any antenna software you would use for linux that does
> like EZNEC+ v5.0 (licenced) http://www.eznec.com/
>
> Patrik
>
> ___
> 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] software for antenna designers

[Andrew Davis]

Well nec2 does all the work and it is already cross-platform, all someone
would have to do is make a GUI to display the results.

On Wed, Feb 1, 2012 at 5:05 AM, Patrik Tast  wrote:

> **
> Thanks Andrew,
>
> Yeah, I found those two options too. It seems like there is no other..?
> Wine seems to be needed if...
> It would be a perfect "task"/thesis for a student group to make a *pure*
> crossplatform one.
>
> Patrik
>
> ----- Original Message -
> *From:* Andrew Davis 
> *To:* Patrik Tast  ; discuss-gnuradio@gnu.org
> *Sent:* Wednesday, February 01, 2012 5:11
> *Subject:* Re: [Discuss-gnuradio] software for antenna designers
>
> Well the core ( nec2 ) is open source and so runs on linux, but your GUI (
> EZNEC+ ) is not. You could try Wine, I believe 4nec2 works well with it,
> 4nec2 is a much more advanced program too.
>
> On Tue, Jan 31, 2012 at 7:48 PM, Patrik Tast wrote:
>
>> **
>> Hi All,
>>
>> Do you know of an/any antenna software you would use for linux that does
>> like EZNEC+ v5.0 (licenced) http://www.eznec.com/
>>
>> Patrik
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] problem running uhd_fft.py

[Andrew Davis]

This just means your PC is not fast enough to sample at that speed and
update the window. Try keeping the sample rate low.

On Sat, Feb 4, 2012 at 2:50 AM, davood ahmady  wrote:

> hello all
> when I run uhd_fft.py and change sample rate from 1 to 2 the graph is
> being locked and i couldnot change anythig,
> what is my fault?
> Thank you.
> Davood
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] problem running uhd_fft.py

[Andrew Davis]

Well that should be fast enough, could you give us the exact command you
used to start uhd_fft.py

Also what do you mean by "installing ubuntu 10.04 using windows installer",
are you running linux in a VM?

On Sun, Feb 5, 2012 at 3:11 AM, davood ahmady  wrote:

> Hello Andrew
> thanks for your reply
> My desktop pc has 4 Giga Ram, Daul processor 2.8 Giaga, and installing
> ubuntu 10.04 using windows installer. you mean that it is not enough?
> thank you,
> Davood
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Feature #394

[Andrew Davis]

Hello all,

I would like to help expand the C++ API, so I'm attempting to work on
Feature #394 or "Re-implement hierarchical blocks currently living in blks2
in C++ and put into gnuradio-core/src/lib/hier." I've started on
am_demod.py but this requires optfir, which is also in python, I think this
should also be available to us C++ users, so i'm converting it too.  I'm
new to GnuRadio and would like to know if i'm on the right track before I
get to far. The files so far are included.

Thank you.
/*
 * Copyright 2012 Free Software Foundation, Inc.
 * 
 * This file is part of GNU Radio
 * 
 * GNU Radio is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 3, or (at your option)
 * any later version.
 * 
 * GNU Radio is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with GNU Radio; see the file COPYING.  If not, write to
 * the Free Software Foundation, Inc., 51 Franklin Street,
 * Boston, MA 02110-1301, USA.
 */

#include 
#include 

class gr_demod_10k0a3e_cf;
typedef boost::shared_ptr gr_demod_10k0a3e_cf_sptr;

GR_CORE_API gr_demod_10k0a3e_cf_sptr gr_make_demod_10k0a3e_cf(int channel_rate=25,
	int audio_decim=5);

/*!
 * \brief 10K0A3E Emission Standard Demodulator
 *
 * This block demodulates an AM channel conformant to 10K0A3E emission
 * standards, such as broadcast band AM transmissions.
 * \ingroup misc_blk
 */
class GR_CORE_API gr_demod_10k0a3e_cf : public gr_blks2_am_demod
{
private:
	gr_demod_10k0a3e_cf(
	int channel_rate,   /* incoming sample rate of the AM baseband */
	int audio_rate);   /* input to output decimation rate */

	friend GR_CORE_API gr_demod_10k0a3e_cf_sptr gr_make_demod_10k0a3e_cf(int channel_rate,
	int audio_decim);
};

gr_blks2_am_demod.cc
Description: Binary data
/*
 * Copyright 2012 Free Software Foundation, Inc.
 * 
 * This file is part of GNU Radio
 * 
 * GNU Radio is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 3, or (at your option)
 * any later version.
 * 
 * GNU Radio is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with GNU Radio; see the file COPYING.  If not, write to
 * the Free Software Foundation, Inc., 51 Franklin Street,
 * Boston, MA 02110-1301, USA.
 */

#include 
#include 

class gr_blks2_am_demod;
typedef boost::shared_ptr gr_blks2_am_demod_sptr;

GR_CORE_API gr_blks2_am_demod_sptr gr_make_blks2_am_demod(int channel_rate=25,
		int audio_decim=5,
		double audio_pass=5000,
		double audio_stop=5500);

/*!
 * \brief Generalized AM demodulation block with audio filtering.
 *
 * This block demodulates a band-limited, complex down-converted AM 
 * channel into the the original baseband signal, applying low pass 
 * filtering to the audio output. It produces a float stream in the
 * range [-1.0, +1.0].
 * \ingroup misc_blk
 */
class GR_CORE_API gr_blks2_am_demod : public gr_hier_block2
{
private:
	gr_blks2_am_demod(
		int channel_rate,   /* incoming sample rate of the AM baseband */
		int audio_decim,   /* input to output decimation rate */
		double audio_pass, /* audio low pass filter passband frequency */
		double audio_stop); /* audio low pass filter stop frequency */

	friend GR_CORE_API gr_blks2_am_demod_sptr gr_blks2_make_am_demod(int channel_rate,
		int audio_decim,
		double audio_pass,
		double audio_stop);

	gr_complex_to_mag_sptr d_mag;
	gr_add_const_ff_sptr d_dcr;
	std::vector d_audio_taps;
	gr_fir_filter_fff_sptr d_lpf;
};


gr_demod_10k0a3e_cf.cc
Description: Binary data
/* -*- c++ -*- */
/*
 * Copyright 2012 Free Software Foundation, Inc.
 * 
 * This file is part of GNU Radio
 * 
 * GNU Radio is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 3, or (at your option)
 * any later version.
 * 
 * GNU Radio is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with GNU Radio; see the file COPYING.  If not, write to
 * the Free Software Foundation, Inc., 51 Franklin Street,

Re: [Discuss-gnuradio] Feature #394

[Andrew Davis]

Thanks, I think i'll work on QA too while i'm at it then.

On Wed, Feb 8, 2012 at 10:32 PM, Tom Rondeau  wrote:

> On Tue, Feb 7, 2012 at 9:52 PM, Andrew Davis wrote:
>
>> Hello all,
>>
>> I would like to help expand the C++ API, so I'm attempting to work on
>> Feature #394 or "Re-implement hierarchical blocks currently living in
>> blks2 in C++ and put into gnuradio-core/src/lib/hier." I've started on
>> am_demod.py but this requires optfir, which is also in python, I think this
>> should also be available to us C++ users, so i'm converting it too.  I'm
>> new to GnuRadio and would like to know if i'm on the right track before I
>> get to far. The files so far are included.
>>
>> Thank you.
>>
>
>
> Hi Andrew,
> It looks to me like you're on the right track! Thanks for making a go at
> it.
>
> So you seem to have the general style correct in the files that I looked
> at. Once it's coded, the ultimate test is, obviously, to make sure that the
> data produced by any of these guys is the same as is produced by the Python
> versions. This is a good case where the QA code would be useful, so we
> would have a set of tests with known output that you could compare against
> the new implementations. Unfortunately, I don't see an QA for the optfir,
> but it would probably be good to have one.
>
> Tom
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Tune UHD - as fast as possible

[Andrew Davis]

self.uhd_usrp_sink_0.set_center_freq(self.freq, 0) will take forever, the
whole front end has to re-settle. How far are you moving the center
frequency? If it's less than 50MHz you could change the sin signal
frequency. You could even hook up a Frequency modulator and change the
frequency continually and with absolutely no delay.

On Thu, Feb 9, 2012 at 7:02 AM, Marius Ciepluch wrote:

> Hi!
>
> I have put a Flow-Graph together, which is quite simple:
> Sine Signal -> USRP2 UHD
>
> Now I want to change the center-frequency as fast as possible.
>
> My initial idea was a while True loop and to issue the
> self.uhd_usrp_sink_0.set_center_freq(self.freq, 0) command from Python.
> This does not work. It remains at the initial frequency.
>
> Do you use the Function Probe block in GRC? Or is there any other way to
> make it tune without ending the Flow-Graph?
>
> Best,
> Marius
>
>
> ___
> 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] Tune UHD - as fast as possible

[Andrew Davis]

http://gnuradio.org/doc/doxygen/classuhd__usrp__sink.html#a279a28c250e2ae657aa9c43b5742c2fa


Is the current API, i'm not sure how it gets to python world, but it looks
like you can still call it with just the frequency.

Also it there any reason your doing this with GRC and not python?

On Fri, Feb 10, 2012 at 4:14 AM, Marius Ciepluch wrote:

> Hi Andrew,
>
> thanks for the reply. I need the RF Frontend to change. I'm doing
> measurements in order to find out how fast the RF Frontend can tune over
> more than 25 MHz (on a USRP2). I need some exact data here, e.g. plots.
> So in fact I want it to tune with no workarounds. And I want to see it
> tune ;)
>
> I pinpoint the Transceiver of the XCVR
> (http://datasheets.maxim-ic.com/en/ds/MAX2828-MAX2829.pdf) in order to
> get a down-scaled frequency.  I want to set a new frequency. An then I
> want to plot how long it takes the device to issue the change. That's
> UHD Device driver command + Ethernet latency + FPGA reaction.
>
> My problem is, that I know of no way to tune it. Automatically changing
> the center-frequency from GRC seems to be impossible to me.
>
> http://lists.gnu.org/archive/html/discuss-gnuradio/2011-09/msg00309.html
> - I found that. But
> uhd.tune_request(target_freq, dsp_freq=0,
> dsp_freq_policy=uhd.tune_request.POLICY_MANUAL) tells me, that it cannot
> be evaluated in GRC. Variables set of course. I guess the constructor
> changed, but there's no docu here.
>
> - I can use a WX GUI slider, but I need an automated change. Actually a
> switch between 50 and 75 MHz (so that my Oscilloscope copes with that).
> Here I use the WBX. My overall goal is to understand more about the
> hardware.
>
>
> So if someone knows how I can implement a callback or a polling function
> to make the device tune for real, but as fast as possible, that'd be
> very helpful.
>
> Best,
> Marius
>
>
>
>
>
>
>
> On 02/09/2012 10:41 PM, Andrew Davis wrote:
> > self.uhd_usrp_sink_0.set_center_freq(self.freq, 0) will take forever, the
> > whole front end has to re-settle. How far are you moving the center
> > frequency? If it's less than 50MHz you could change the sin signal
> > frequency. You could even hook up a Frequency modulator and change the
> > frequency continually and with absolutely no delay.
> >
> > On Thu, Feb 9, 2012 at 7:02 AM, Marius Ciepluch  >wrote:
> >
> >> Hi!
> >>
> >> I have put a Flow-Graph together, which is quite simple:
> >> Sine Signal -> USRP2 UHD
> >>
> >> Now I want to change the center-frequency as fast as possible.
> >>
> >> My initial idea was a while True loop and to issue the
> >> self.uhd_usrp_sink_0.set_center_freq(self.freq, 0) command from Python.
> >> This does not work. It remains at the initial frequency.
> >>
> >> Do you use the Function Probe block in GRC? Or is there any other way to
> >> make it tune without ending the Flow-Graph?
> >>
> >> Best,
> >> Marius
> >>
> >>
> >> ___
> >> 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] About the use of gr.probe_signal_f()

[Andrew Davis]

http://gnuradio.org/doc/doxygen/modules.html is a good place to browse what
available.

2012/2/15 Wu Ting 

> Hi Tom,
>
> ** **
>
> Thank you very much for your detailed explanation. That really works!
>
> ** **
>
> I really want to learn more about GNURadio by myself. But I don’t know how
> should I go on. How can I find the right function/module/block for some
> specific purpose? Do you have any suggestion?
>
> ** **
>
> Thanks again.
>
> ** **
>
> Wu
>
> ** **
>
> *From:* trond...@trondeau.com [mailto:trond...@trondeau.com] *On Behalf
> Of *Tom Rondeau
> *Sent:* 2012年2月15日 0:01
> *To:* Wu Ting
> *Cc:* discuss-gnuradio@gnu.org
> *Subject:* Re: [Discuss-gnuradio] About the use of gr.probe_signal_f()
>
> ** **
>
> On Tue, Feb 14, 2012 at 4:00 AM, Wu Ting <
> wu.t...@comf5.comm.eng.osaka-u.ac.jp> wrote:
>
> Hi all,
>
>  
>
> I’m trying to read the real-time value of a stream from USRP. I’m
> considering using gr.probe_signal_f, but it seems to not work. I’m really
> new to GNURadio, so please forgive me if I ask some stupid question.
>
>  
>
> My method is like this:
>
>  
>
> #First generate a source from USRP:
>
> self.source = uhd.usrp_source(device_addr=’’,
> stream_args=uhd.stream_args(‘fc32’, ‘sc16’), args=’scalar=1024’)
>
>  
>
> #change from complex to interleaved short:
>
> op1 = gr.complex_to_interleaved_short()
>
>  
>
> #change from short to float
>
> op2 = gr.short_to_float()
>
>  
>
> #create probe
>
> self.probe = gr.probe_signal_f()
>
>  
>
> self.connect(self.source, op1, op2, self.probe)
>
>  
>
> And in a true while loop, I print the value of the probe, but the value is
> always 0.0
>
>  
>
> Could anyone tell me what is the problem? And is there any better way to
> realize this function?
>
>  
>
> Thanks.
>
>  
>
> Wu
>
> ** **
>
> Hi Wu,
>
> A couple of things. First, you're doing one too many operations. You are
> going from complex float to short to float. You could just go from complex
> to float.  There is gr.complex_to_float that will provide two output
> streams for I and Q; complex_to_real or complex_to_imag for each stream
> independently; of you could use complex_to_mag or complex_to_mag_squared
> for the magnitude of the complex number.
>
> ** **
>
> Second, and the main reason for your question, is that you are never
> running the flow graph. You construct a flow graph using the connect
> functions, but that doesn't start any samples running through it. So, given
> the class you've defined here, call it wu_top_block, we need to return an
> object:
>
> ** **
>
> tb = wu_top_block()
>
> ** **
>
> Then you need to run the flowgraph:
>
> ** **
>
> tb.start()
>
> ** **
>
> This will start your system running and collecting data. After this, you
> should be able to set a while loop to look at the data:
>
> ** **
>
> while(1):
>
> print tb.probe.value()
>
> time.sleep(1000)
>
> ** **
>
> So the value get's printed every second.
>
> ** **
>
> Something like that.
>
> ** **
>
> Tom
>
> ** **
>
> ___
> 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