[Discuss-gnuradio] how to use the gr_mpsk_receiver_cc

Hi all:
      I want to use the gr_mpsk_receiver_cc block to receive the pi/4 DQPSK  signal. Because it said that
it should use for pi/4 DQPSK.But how should I set the parameter of the block?Did anyone use it to receive
pi/4 DQPSK signal before?

Re: [Discuss-gnuradio] Trouble With UHD Tune Request

I've been thinking about this issue and I have a feeling that the problem is that swig may not support my use of pointers as function parameters. My block accepts a boost::shared_ptr<uhd_usrp_sink> and a boost::shared_ptr<uhd_usrp_source> as parameters. Disabling swig as I did before seems to have created other issues. Is there any way that I can either fix the swig error or disable swig altogether for this block and just install and link for c++, and not python, flowgraphs?

Previous message with link to swig error

-Dan

Re: [Discuss-gnuradio] Transmit and Received Signals are Different

On Thu, Jul 26, 2012 at 04:09:31PM -0700, Frederick Lee wrote:
> The channel model block contains a timing offset, and noise adder
> which I didn't use in my simulations. The only things I changed were
> the frequency offsets and the multipath variable (from what I found
> online, it's used to change amplitude and phase shift of the signal).
> The only difference that I can see between the channel model and using
> actual USRPs is that USRPs up converts the signal into IF ( I believe
> ), converts it to analog, and the daughter board converts it to RF.
> Then the reverse happens in the other USRP. When the two USRPs are
> transmitting, any of the four things that the channel model does can
> happen, but the main ones I'm concerned about is the frequency shift.,
> and the DPSK block seemed to have taken care of that ( at least in the
> simulation ).
> I was using the */gr-uhd/examples/grc/uhd_dpsk_mod.grc and other
> similar examples as somewhat of a guide, and I don't see anything that
> looks very different from what I used. What kind of other adjustments
> must I make?


Frederick,

all kinds of stuff can go wrong.

When you say you see 'nothing' on the FFT sink, do you mean you see only
noise, or literally nothing?

Here's a typical ist of things I do when debugging such a link:

1) Use a spectral analyzer to see if the transmitter is actually
transmitting (where you want it to)
2) Connect an FFT sink directly to the UHD source to see if the signal
looks as expected

You've got a couple of things that surprise me in your FG:
- the packet decoder (I'm not 100% what that does) searches for a bit
string? If so, you have no way to guarantee you're actually receiving
that specific sequence. If you're literally rx'ing nothing, perhaps that
doesn't trigger.
- Why do you LPF bits?

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

Re: [Discuss-gnuradio] Trying to use the complex int16 option of the UHD blocks

Thanks, Josh.

How can I specify the peak from GRC generated Python code? For example, when I select the sc8 wire format, the following code is generated through GRC.

stream_args=uhd.stream_args(
                cpu_format="fc32",
                otw_format="sc8",
                channels=range(1),
            ),

If I want to limit the peak to 0.1 (if the received signal is very weak), can I just use the following?

stream_args=uhd.stream_args(
                cpu_format="fc32",
                otw_format="sc8",
                peak = 0.5,
                channels=range(1),
            ),

Thanks,

Nazmul

On Thu, Jul 26, 2012 at 8:15 PM, Josh Blum <josh@ettus.com> wrote:

On 07/26/2012 05:09 PM, Nazmul Islam wrote:
> Hi Josh,
>
> I am just wondering how the USRP performs the 8 bit mapping for I & Q
> samples. The ADC & DAC have 12 - 14 bit precision, I think. When I select
> the sc8 wire format, does the USRP divide the entire received signal range
> into 2^8 sectors and uses one number to represent each of those?
>

Technically, there is just a multiply and slice operation. You can
specify peak to optimize for the best use of t 8 bits of dynamic range.
See:
http://files.ettus.com/uhd_docs/doxygen/html/structuhd_1_1stream__args__t.html#a4463f2eec2cc7ee70f84baacbb26e1ef

-josh

> Thanks,
>
> Nazmul
>
> On Sun, Jul 22, 2012 at 4:22 PM, Josh Blum <josh@ettus.com> wrote:
>
>>
>>
>> On 07/22/2012 01:14 PM, Nazmul Islam wrote:
>>> Hello,
>>>
>>>  I am trying to use the complex int16 option of the UHD (source/sink)
>>> blocks in my GRC generated python codes. I am doing wide band spectral
>>> analysis in my experiments. Therefore, 50 MS/s will be very helpful for
>> me.
>>>
>>
>> The host format and the wire format are totally independent options
>> here. Both of these properties also configurable properties in the GRC
>> USRP source/sink blocks.
>>
>> * You need to set the wire format to sc8 (thats 2 bytes per complex
>> sample) to achieve 50 Msps over gigabit ethernet.
>>
>> * The desired host format does not have to change. fc32 (complex floats)
>> is a perfectly valid setting
>>
>> -josh
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
>

--
Muhammad Nazmul Islam

Graduate Student
Electrical & Computer Engineering
Wireless Information & Networking Laboratory
Rutgers, USA.

Re: [Discuss-gnuradio] Trying to use the complex int16 option of the UHD blocks

On 07/26/2012 05:09 PM, Nazmul Islam wrote:
> Hi Josh,
>
> I am just wondering how the USRP performs the 8 bit mapping for I & Q
> samples. The ADC & DAC have 12 - 14 bit precision, I think. When I select
> the sc8 wire format, does the USRP divide the entire received signal range
> into 2^8 sectors and uses one number to represent each of those?
>

Technically, there is just a multiply and slice operation. You can
specify peak to optimize for the best use of t 8 bits of dynamic range.
See:
http://files.ettus.com/uhd_docs/doxygen/html/structuhd_1_1stream__args__t.html#a4463f2eec2cc7ee70f84baacbb26e1ef

-josh

> Thanks,
>
> Nazmul
>
> On Sun, Jul 22, 2012 at 4:22 PM, Josh Blum <josh@ettus.com> wrote:
>
>>
>>
>> On 07/22/2012 01:14 PM, Nazmul Islam wrote:
>>> Hello,
>>>
>>> I am trying to use the complex int16 option of the UHD (source/sink)
>>> blocks in my GRC generated python codes. I am doing wide band spectral
>>> analysis in my experiments. Therefore, 50 MS/s will be very helpful for
>> me.
>>>
>>
>> The host format and the wire format are totally independent options
>> here. Both of these properties also configurable properties in the GRC
>> USRP source/sink blocks.
>>
>> * You need to set the wire format to sc8 (thats 2 bytes per complex
>> sample) to achieve 50 Msps over gigabit ethernet.
>>
>> * The desired host format does not have to change. fc32 (complex floats)
>> is a perfectly valid setting
>>
>> -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] Trying to use the complex int16 option of the UHD blocks

Hi Josh,

I am just wondering how the USRP performs the 8 bit mapping for I & Q samples. The ADC & DAC have 12 - 14 bit precision, I think. When I select the sc8 wire format, does the USRP divide the entire received signal range into 2^8 sectors and uses one number to represent each of those?

Thanks,

Nazmul

On Sun, Jul 22, 2012 at 4:22 PM, Josh Blum <josh@ettus.com> wrote:

On 07/22/2012 01:14 PM, Nazmul Islam wrote:
> Hello,
>
>  I am trying to use the complex int16 option of the UHD (source/sink)
> blocks in my GRC generated python codes. I am doing wide band spectral
> analysis in my experiments. Therefore, 50 MS/s will be very helpful for me.
>

The host format and the wire format are totally independent options
here. Both of these properties also configurable properties in the GRC
USRP source/sink blocks.

* You need to set the wire format to sc8 (thats 2 bytes per complex
sample) to achieve 50 Msps over gigabit ethernet.

* The desired host format does not have to change. fc32 (complex floats)
is a perfectly valid setting

-josh

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

--
Muhammad Nazmul Islam

Graduate Student
Electrical & Computer Engineering
Wireless Information & Networking Laboratory
Rutgers, USA.

[Discuss-gnuradio] control FPGA new pin in N210

Dear all,

    I am using N210, I wan to bring "AA17" pin of FPGA to up 3.3v, and how can use UHD to do that?

    Josh replied me that make  a new settings register in u2plus_core.v and use set_user_register() to control it.

    but I read the u2plus_core.v code, and try to add the setting_reg to control "AA17" pin, but how can I know the "addr" that multi_usrp.cpp can control it? could someone can give me an example? thanks a lot.

Jack.

Re: [Discuss-gnuradio] Optimising performance of N210 + XCVR2450

Michael,

1) For 8 bit you change the wire format parameter of the UHD Source and Sink from "automatic" to "sc8". This is one of the options you get when double clicking the Source/Sink in GRC. Changing the output type of the block in GRC has no effect on the wire format. No modification to hardware or firmware necessary. Also, decimation would lower the bandwidth but, once again, all you have to do is change the option.

2) First off, the XCVR2450 is half duplex, so it can only transmit or receive at a time, not both. Maybe check out the SBX daughterboard if you want to do both (depends on your application, there are a few full duplex daughterboards in the ism band.) Also, remember that Ethernet has discrete TX and RX lines and each line is limited to roughly 50MSPS at 8bit, so you cant only transmit or only receive at 100MSPS.

3) It's always a good idea to terminate a transmitter as high power reflections could damage your amplifier. It's been a while since I used the XCVR and I can't remember exactly how it divided its ports. Not sure whether (since its half duplex) if it used the same port for both tx and rx by default or if they default to separate ports. You can definitely select the port when only transmitting or receiving. There is an antenna option in the usrp sink.source blocks. I've never used that option myself though so I'm not sure what type of input it expect. An integer would be my best guess so maybe start at 0 and see what you observe. If you wanted to transmit and receive on the same port you would have to stream tag the tx stream and set both blocks (sink and source) for the same port. The device defaults to receive and when it receives a tx_sob alongside the transmit signal it will switch to tx. When it receives a tx_eob, it will switch back to rx. Switching time for the xcvr is in the microsecond range. If the signals you are observing on J1 are very low power compared to those on J2, this could be poor isolation. The rf switch on the two output ports should provide 30dB of isolation. It's possible isolation on the board itself might cause some leakage too.

Good luck and I hope this helps!

-Dan
 
On 07/25/2012 05:30 AM, Michael Hill wrote:

I have a few queries regarding some of the options for improving the performance of the XCVR2450 + N210.

1) The N210 can offer 50MSPS with 8 bit I&Q samples or 25MSPS with 16bit 1&Q.
If using 16 bit I &Q samples, I'd just leave the UHD input block with "Complex int 16".
How do I implement 8 bit I&Q (e.g. what input type do I use? and if it is 16bit.. do I have to decimate my signal in half or something? I don't need to do anything to the hardware or firmware do I?)

2) After reading further, I see that the N210 can apparently offer 100MSPS total host bandwidth with 8bit!
These seems to imply that 50MSPS refers to both transmitting and receiving simulatneously
Does this mean that if i'm only transmitting that I can thus use 100MSPS some how?

3) How do I change/set ports on the XCVR2450 or check which i'm using:
From what I read with the instructions, one shouldn't transmit unless they have an antenna or 50ohm terminator attached or it will damage the device?
I'm transmitting out of port J2 and have a terminator on J1. When I swap.. I seem to get lower power signals out of port J1?
I haven't (as far as i'm aware, done anything to change the settings... or port preference)

Does this mean that it transmits out of both ports, and one of mine is damaged?
Is it true that port J1 is the default port? in which case why are my signals coming out of both?
Do both ports offer transmit and receive, or is one port set to one function and the other port the other..

Sorry for the basic question but i've found conflicting info on the net regarding this, and still very much in the learning phase.

Thanks again gnuradio discussion list!!

-Michael

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

Re: [Discuss-gnuradio] GSoC: Filter Design tool update

Adaptive filtering, whether FIR or IIR, will change the taps dynamically.

I love the design tool idea.

Bob

On Wednesday, July 25, 2012, sreeraj r wrote:

>I didnt mean to imply that there was some kind of formal discussion tool
>like a forum thread. I was just referring to these emails:
>
>https://lists.gnu.org/archive/html/discuss-gnuradio/2012-05/msg00142.html
>
>https://lists.gnu.org/archive/html/discuss-gnuradio/2012-05/msg00146.html

>I think that a new parameter tag would include an import statement and a
>function to call. Example:
>
><param>
>   <name>Taps</name>
>    <key>taps</key>
>    <value>[0]</value>
>    <type>float_vector</type>
>    <launcher>
>      <import>from gnuradio.filter import awesome</import>
>      <function>awesome.function_to_call</function>
>    </launcher>
></param>

>* I guess the idea would be that GRC adds a gui button the parameter
>that will invoke this launcher. It then calls
>awesome.function_to_call(current_param_setting) and when the function
>returns, the new value is set for the parameter.

>* Its not the only way to do this but that is one way to solve the
>problem in a generic fashion. I think the important part vs the idea you
>first purposed is that GRC does not have to know how to execute a
>program, it just calls a python function, which is something that it can
>easily do.

Ok. I will proceed as you mentioned.

>* Once such a launcher is possible, it would not only be nice to add
>this to blocks with parameters that take taps. But it would also be nice
>to add a new variable block to GRC that simultaneously allows the user
>to use this tool, but set its output to a GRC variable. Because I think
>that it will be more desirable in certain cases to set the result to a
>variable.

>* Another block idea, how-about a GRC block that instantiates a GUI
>element that also calls the filter generation tool and sets the taps in
>a callback like fashion. This would give you access to using this tool
>in a live/running flowgraph!

>Let me know what you think,
>-josh

Some users may just need  fixed taps and some would like change those during runtime. I haven't looked into the code for  flowgraph creation and execution  of GRC yet, still it seems to be reasonable to give access to the filter design tool while the flowgraph is running. I will discuss this with Martin during the next call (I am sure he will see this mail ) and will start GRC integration ASAP. Integrating the tool to GRC will help me to find more bugs in my code, as many users will actually try filter design tool. I will try to accomodate all the features that you suggested.

Thanks a lot for your comments and suggestions.

-Sreeraj

--
Bob McGwier

Facebook: N4HYBob

ARS: N4HY

Re: [Discuss-gnuradio] GSoC: Filter Design tool update

>I didnt mean to imply that there was some kind of formal discussion tool
>like a forum thread. I was just referring to these emails:
>
>https://lists.gnu.org/archive/html/discuss-gnuradio/2012-05/msg00142.html
>
>https://lists.gnu.org/archive/html/discuss-gnuradio/2012-05/msg00146.html

>I think that a new parameter tag would include an import statement and a
>function to call. Example:
>
><param>
>   <name>Taps</name>
>    <key>taps</key>
>    <value>[0]</value>
>    <type>float_vector</type>
>    <launcher>
>      <import>from gnuradio.filter import awesome</import>
>      <function>awesome.function_to_call</function>
>    </launcher>
></param>

>* I guess the idea would be that GRC adds a gui button the parameter
>that will invoke this launcher. It then calls
>awesome.function_to_call(current_param_setting) and when the function
>returns, the new value is set for the parameter.

>* Its not the only way to do this but that is one way to solve the
>problem in a generic fashion. I think the important part vs the idea you
>first purposed is that GRC does not have to know how to execute a
>program, it just calls a python function, which is something that it can
>easily do.

Ok. I will proceed as you mentioned.

>* Once such a launcher is possible, it would not only be nice to add
>this to blocks with parameters that take taps. But it would also be nice
>to add a new variable block to GRC that simultaneously allows the user
>to use this tool, but set its output to a GRC variable. Because I think
>that it will be more desirable in certain cases to set the result to a
>variable.

>* Another block idea, how-about a GRC block that instantiates a GUI
>element that also calls the filter generation tool and sets the taps in
>a callback like fashion. This would give you access to using this tool
>in a live/running flowgraph!

>Let me know what you think,
>-josh

Some users may just need  fixed taps and some would like change those during runtime. I haven't looked into the code for  flowgraph creation and execution  of GRC yet, still it seems to be reasonable to give access to the filter design tool while the flowgraph is running. I will discuss this with Martin during the next call (I am sure he will see this mail ) and will start GRC integration ASAP. Integrating the tool to GRC will help me to find more bugs in my code, as many users will actually try filter design tool. I will try to accomodate all the features that you suggested.

Thanks a lot for your comments and suggestions.

-Sreeraj

[Discuss-gnuradio] Ezcap DVB dongle and HF converter

Thank you for reading this.

I received my HF up converter (the companion for the Funcube dongle) in
the mail today but disappointingly I cannot hear anything but noise. The
spectrogram shows a lot of activity which I suspect is noise generated
by the laptop.

Has anyone had success with this combination? By the way, I'm using the
multimode SDR.

--
Regards,
Phil

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

[Discuss-gnuradio] Optimising performance of N210 + XCVR2450

I have a few queries regarding some of the options for improving the performance of the XCVR2450 + N210.

1) The N210 can offer 50MSPS with 8 bit I&Q samples or 25MSPS with 16bit 1&Q.
If using 16 bit I &Q samples, I'd just leave the UHD input block with "Complex int 16".
How do I implement 8 bit I&Q (e.g. what input type do I use? and if it is 16bit.. do I have to decimate my signal in half or something? I don't need to do anything to the hardware or firmware do I?)

2) After reading further, I see that the N210 can apparently offer 100MSPS total host bandwidth with 8bit!
These seems to imply that 50MSPS refers to both transmitting and receiving simulatneously
Does this mean that if i'm only transmitting that I can thus use 100MSPS some how?

3) How do I change/set ports on the XCVR2450 or check which i'm using:
From what I read with the instructions, one shouldn't transmit unless they have an antenna or 50ohm terminator attached or it will damage the device?
I'm transmitting out of port J2 and have a terminator on J1. When I swap.. I seem to get lower power signals out of port J1?
I haven't (as far as i'm aware, done anything to change the settings... or port preference)

Does this mean that it transmits out of both ports, and one of mine is damaged?
Is it true that port J1 is the default port? in which case why are my signals coming out of both?
Do both ports offer transmit and receive, or is one port set to one function and the other port the other..

Sorry for the basic question but i've found conflicting info on the net regarding this, and still very much in the learning phase.

Thanks again gnuradio discussion list!!

-Michael

Re: [Discuss-gnuradio] Trouble With UHD Tune Request

It occurred to me that I may have edited a file which could have caused the error in GRC. When I tried to compile my module, a class called Python_wrap, which appears to be related to swig, returned an error. As I intend to use this function only at the C++ level since it requires pointers to UHD Source/Sink objects, I assumed swig was unnecessary and removed all occurrences of the header for my block from /source/swig/(module name)swig.i . This allowed the module to compile with no issues but I'm wondering if it could have caused the error in GRC? While I find it unlikely as swig should not be needed in C++, could it have caused the error I observed in my C++ flowgraph? If this may be responsible for these errors, how can I handle this issue? Thanks!

-Dan

Context of this message

My Python_wrap error
Perhaps this error is because of my use of pointers?

[Discuss-gnuradio] Fwd: Any friends ever worked on noise variance estimation using the USRP?

Copy to usrp-users

---------- Forwarded message ----------
From: Alex Zhang <cingular.alex@gmail.com>
Date: Tue, Jul 24, 2012 at 4:08 PM
Subject: Any friends ever worked on noise variance estimation using the USRP?
To: gnuradio mailing list <discuss-gnuradio@gnu.org>


Hi gurus,

I am doing an experiment which need to estimate the noise variance of each USRP as receiver.

My question is that besides the sample variance method, is there any other method to achieve better accuracy? 

And for a single USRP, is the variance stable after the power on? And is the measurement related to working frequency?

--

Alex,

Dreams can come true – just believe.

--

Alex,

Dreams can come true – just believe.

[Discuss-gnuradio] Any friends ever worked on noise variance estimation using the USRP?

Hi gurus,

I am doing an experiment which need to estimate the noise variance of each USRP as receiver.

My question is that besides the sample variance method, is there any other method to achieve better accuracy? 

And for a single USRP, is the variance stable after the power on? And is the measurement related to working frequency?

--

Alex,

Dreams can come true – just believe.

Re: [Discuss-gnuradio] GSoC: Filter Design tool update

On 07/23/2012 10:15 PM, sreeraj r wrote:
>
>
>> In next few weeks I will be adding some special filters like
>> half-band filter to the design tool, then will proceed with
>> integration of gr_filter_design to GRC and will try to add QA
>> tests for filter design routines wherever they are missing.
>>
>
>> Need any help with the GRC integration? I know there was some talk
>> about creating modules to call into, etc so the hooks into GRC
>> would be simpler.
>
>> Let me know. Thanks! -josh
>
> Could you please share the discussion link if there is one. You and
> Martin already gave me various hints regarding this before. Still if
> there is a standard way of doing this, that info will be really
> helpful.
>

I didnt mean to imply that there was some kind of formal discussion tool
like a forum thread. I was just referring to these emails:

https://lists.gnu.org/archive/html/discuss-gnuradio/2012-05/msg00142.html

https://lists.gnu.org/archive/html/discuss-gnuradio/2012-05/msg00146.html

I think that a new parameter tag would include an import statement and a
function to call. Example:

<param>
<name>Taps</name>
<key>taps</key>
<value>[0]</value>
<type>float_vector</type>
<launcher>
<import>from gnuradio.filter import awesome</import>
<function>awesome.function_to_call</function>
</launcher>
</param>

* I guess the idea would be that GRC adds a gui button the parameter
that will invoke this launcher. It then calls
awesome.function_to_call(current_param_setting) and when the function
returns, the new value is set for the parameter.

* Its not the only way to do this but that is one way to solve the
problem in a generic fashion. I think the important part vs the idea you
first purposed is that GRC does not have to know how to execute a
program, it just calls a python function, which is something that it can
easily do.

* Once such a launcher is possible, it would not only be nice to add
this to blocks with parameters that take taps. But it would also be nice
to add a new variable block to GRC that simultaneously allows the user
to use this tool, but set its output to a GRC variable. Because I think
that it will be more desirable in certain cases to set the result to a
variable.

* Another block idea, how-about a GRC block that instantiates a GUI
element that also calls the filter generation tool and sets the taps in
a callback like fashion. This would give you access to using this tool
in a live/running flowgraph!

Let me know what you think,
-josh

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

Re: [Discuss-gnuradio] Transmit and Received Signals are Different

I figured out why the low pass filter was making the square wave look
like a sine wave. The square was represented by a Fourier series. In
other words, it was made up of many sine waves with different
frequencies. The Fourier Series for a square wave is: 4k/pi(sinx +
1/3*sin3x + 1/5*sin5x + ... ) When I applied the low pass filter with
a cutoff frequency of 1.1kHz to a 1kHz square wave, I was cutting off
the sine waves at the higher frequencies, (3kHz, 5kHz, etc.), so it
only showed the first sine wave in the series. If I set the cutoff
frequency of the low pass filter to 30 - 50 times the signal frequency
then I will get a fairly accurate square wave with some ripples on the
horizontal parts on the graph.

Here's the link to the pdf that shows this:
http://www.eecs.berkeley.edu/~boser/courses/40/labs/docs/UAF42%20square%20wave%20to%20sinusoid.pdf

As for the frequency offset, if I use the setup shown in the attached
flow graph ( this time with the taps being 1.0 + 0j ) and set the
frequency offset of the channel model block to 1m or less it looks
like a sine wave is being superimposed onto the square wave. I have
tried to filter out the low frequency sine wave, but that disrupts the
square wave. Is there a way to accommodate for the frequency offset
when transmitting and receiving between the USRPs?

Thanks,

Frederick

Re: [Discuss-gnuradio] MTU Size

Josh was correct; it was the network. Specifically, the network switch wasn't configured to save its settings after a reboot... Thank you both for the help!

-Alex

On Mon, Jul 23, 2012 at 1:11 PM, <mleech@ripnet.com> wrote:

On 23 Jul 2012 13:05, Josh Blum wrote:

On 07/23/2012 09:40 AM, Alexander Olihovik wrote:

More specifically, I've tried changing the device address with: device_addr="addr0=10.1.1.105, recv_frame_size=4096, send_frame_size=4096" but when running the program, both the recv_frame_size and send_frame_size are still 1472 bytes. I've also configured my network to be able to handle frames of size 4096, and have had this working with C++ code. However, the Python code doesn't work as I would expect. It seems not to make a difference whether I specify the frame size or not.

Its the same device args, so python/c++ it shouldnt make a difference.    The driver is however testing if it can handle that MTU by sending test  packets. Perhaps its still a network configuration issue?    Also, you should be able to    uhd_usrp_probe --args="addr0=10.1.1.105, recv_frame_size=4096,  send_frame_size=4096"    and still see the same issue.    -josh

Lots of network cards don't handle jumbograms, even if you configure them to do so.

 

 

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

--
Alex Olihovik
University of Virginia 2013
BS Electrical Engineering
BS Computer Engineering
ano9cn@virginia.edu

Re: [Discuss-gnuradio] Where can I write the Coding of C++ in the GNU radio

Anis,

 

The file you referenced contains no main function for execution: it is a header file that defines the functions contained in the multi_usrp class.  Additionally, I believe that code is used for multi_usrp.py (Python script, not C++).  I have never used the Python scripts: my recording needs are simple enough that I can get away with modifying "rx_samples_to_file.cpp"

 

The source code for the C++ examples is located in "uhd/host/examples" but the compiled executables are in "uhd/host/build/examples."  The following will show you a list of parameters that are available for "rx_samples_to_file":

 

./uhd/host/build/examples/rx_samples_to_file --help

 

-Ryan

 

On Tue, Jul 24, 2012 at 8:24 AM, Abdelrahman Anis <abdelrahman_anis@yahoo.com> wrote:

Hi Ryan & Nathan,

Thanks for the information supported. We will use four USRP210 in our antenna array. Each USRP will use Individual host, Because we need to receive 20 MS/s from each USRP.
Of Course, we have external unit to supply PPS and clock for USRPs.
How can I run the UHD examples in Ubuntu operating system? Like that one: http://files.ettus.com/uhd_docs/doxygen/html/multi__usrp_8hpp_source.html
Thanks in advance.



Anis



________________________________
From: Nathan West <nathan.west@okstate.edu>
To: Ryan Wolfarth <wolfarra@muohio.edu>
Cc: Abdelrahman Anis <abdelrahman_anis@yahoo.com>; "discuss-gnuradio@gnu.org" <discuss-gnuradio@gnu.org>
Sent: Monday, July 23, 2012 3:32 PM
Subject: Re: [Discuss-gnuradio] Where can I write the Coding of C++ in the GNU radio


Anis,

You may also find the tutorials useful. Specifically the "How to write a signal processing block". There are two of these that I know about.
Look at "extending gnu radio," http://gnuradio.org/redmine/projects/gnuradio/wiki/HowToUse#The-C-domain-Extending-GNU-Radio
Look at Asier Alonso's guides, http://gnuradio.org/redmine/projects/gnuradio/wiki/Tutorials

Hopefully the three links you have will get you going. If nothing else you've got hours of reading and example material :-)

-nathan


On Mon, Jul 23, 2012 at 9:20 AM, Ryan Wolfarth <wolfarra@muohio.edu> wrote:

Hi Anis,
> 
>I think a good starting would be to modify "rx_samples_to_file.cpp" or "tx_samples_to_file.cpp.".  The files are located in uhd/host/examples.
> 
>How many USRPs will you use?  Will they use the same host machine?  Time synchronization is possible using the PPS input on a USRP2 or N2xx.  My group uses the PPS and 10MHz oscillator output from a GPS receiver for time sync.  Check out the following for more information on synchronzing device time: http://files.ettus.com/uhd_docs/manual/html/sync.html
> 
>Hope this helps!Ryan
>
>
>On Mon, Jul 23, 2012 at 7:40 AM, Abdelrahman Anis <abdelrahman_anis@yahoo.com> wrote:
>
>Hi all,
>>
>>Sorry if this question is repeated, I am still a beginner in GNU radio, I couldn't find the answer after searching the Web.
>>
>>Where I can write the Coding of C++ in the GNU radio? and How can access these Installed C++ blocks in GNU radio ?
>>I want it to run a project of Parallel Processing using C++ to operate multiple USRPs with 20 MS/s each at the same time synchronized with each others.
>>I am using Ubuntu 10.04 LTS as operating system.
>>Thanks in advance.
>>
>>Anis 
>>
>>_______________________________________________
>>Discuss-gnuradio mailing list
>>Discuss-gnuradio@gnu.org
>>https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>_______________________________________________
>Discuss-gnuradio mailing list
>Discuss-gnuradio@gnu.org
>https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>

Re: [Discuss-gnuradio] GSoC: Filter Design tool update

Thank you.  It would be great to see this finished and not left in the state I had to leave it.

Thanks the great view of your project in your links.

Bob

On Sunday, July 22, 2012, sreeraj r wrote:

Hi all,

A brief update on the new features added to the filter design tool[1]

--IIR Filter Design (Scipy Based)

   -Butterworth

   -Elliptic

   -Chebyshev-1

   -Chebyshev-2

   -Bessel

--Pole-zero plot now supports addition, deletion of poles/zeros with conjugate support.

A small video showing some of the added features can be found here[2].

At first I started using Robert McGwier's existing code[3] and added features to that as suggested by Tom and Martin. Later finding that Scipy's filter design functions[4] are very much optimized and robust, I decided to use those. Martin also pointed out that it will just be a duplication of work and suggested me to use scipy for IIR design.

I did a basic integration of the code to gr-filter component of GNU Radio[5]. I haven't pushed icons yet to the branch. It would be really helpful if anyone can comment on the current integration, so that I can make suitable modifications.

In next few weeks I will be adding some special filters like half-band filter to the design tool, then will proceed with integration of gr_filter_design to GRC and will try to add QA tests for filter design routines wherever they are missing.

[1]https://github.com/zeroXzero/gr-filtdes

[2]GSOC: New features in GNU Radio filter design tool

[3]http://gnuradio.org/cgit/n4hy.git/log/?h=n4hy_iir

[4]http://docs.scipy.org/doc/scipy/reference/signal.html

[5]https://github.com/zeroXzero/gnuradio-sreeraj Branch: filtdes_gui

 

---
Regards
Sreeraj Rajendran
http://home.iitb.ac.in/~rsreeraj

--
Bob McGwier

Facebook: N4HYBob

ARS: N4HY

Re: [Discuss-gnuradio] GSoC: Filter Design tool update

> In next few weeks I will be adding some special filters like
> half-band filter to the design tool, then will proceed with
> integration of gr_filter_design to GRC and will try to add QA tests
> for filter design routines wherever they are missing.
>

>Need any help with the GRC integration? I know there was some talk about
>creating modules to call into, etc so the hooks into GRC would be simpler.

>Let me know.
>Thanks!
>-josh

Could you please share the discussion link if there is one. You and Martin already gave me various hints regarding this before. Still if there is a standard way of doing this, that info will be really helpful.

regards
Sreeraj

Re: [Discuss-gnuradio] GSoC: Filter Design tool update

On Mon, Jul 23, 2012 at 2:24 PM, Josh Blum <josh@ettus.com> wrote:

 

> In next few weeks I will be adding some special filters like
> half-band filter to the design tool, then will proceed with
> integration of gr_filter_design to GRC and will try to add QA tests
> for filter design routines wherever they are missing.
>

Need any help with the GRC integration? I know there was some talk about
creating modules to call into, etc so the hooks into GRC would be simpler.

This would be great.

Johnathan

Re: [Discuss-gnuradio] GSoC: Filter Design tool update

> In next few weeks I will be adding some special filters like
> half-band filter to the design tool, then will proceed with
> integration of gr_filter_design to GRC and will try to add QA tests
> for filter design routines wherever they are missing.
>

Need any help with the GRC integration? I know there was some talk about
creating modules to call into, etc so the hooks into GRC would be simpler.

Let me know.
Thanks!
-josh

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

[Discuss-gnuradio] Tutorial on using Funcube Dongle with GNU Radio

Hi All,

I have just started a blog and I'm planning to use it to host a few tutorials on SDR application, specially on subjects related to GNU Radio. I've started with a tutorial on using Funcube Dongle with GNU Radio which you can find here: http://www.vbehzadan.com/2012/07/23/using-funcube-dongle-with-gnu-radio/ . I would greatly appreciate your feedback on this tutorial to know how to improve my future tutorials.

Also, if you have any specific subjects in mind which you think are worth writing a tutorial for, don't hesitate to contact me.

Best Regards,

 

Vahid Behzadan
SDRWare

Re: [Discuss-gnuradio] System overrun after short time

On 07/23/2012 03:08 AM, Luong Tan Phong wrote:
> Hi Lists,
>
> I wrote a program in C + + use gnuradio library to demodulate some signals. The
> program works well with the low data rate signal (below 20
> Ksymbols/s). With higher
> data rate signal: 200 Ksymbols/s, the program works well for a few minutes
> then the console window will appear the letters 'O' continuously and data
> after demodulation was wrong. With 1 Msymbols/s signal, the system can
> operate well over 1 minute.
>
> Could you help me to solve the problem, please?
>

It sounds like you found the tripping point where the rate of data
flowing into the buffers exceeds the rate of data being removed.

http://files.ettus.com/uhd_docs/manual/html/general.html#overflow-underflow-notes

I admit, that is a rather low rate. Perhaps you have a filter with an
unexpectedly large number of taps? Or you max consider benchmarking the
performance of your demodulator code, or try to isolate which processing
block is slow, etc

-josh

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

Re: [Discuss-gnuradio] MTU Size

On 23 Jul 2012 13:05, Josh Blum wrote:

On 07/23/2012 09:40 AM, Alexander Olihovik wrote:

More specifically, I've tried changing the device address with: device_addr="addr0=10.1.1.105, recv_frame_size=4096, send_frame_size=4096" but when running the program, both the recv_frame_size and send_frame_size are still 1472 bytes. I've also configured my network to be able to handle frames of size 4096, and have had this working with C++ code. However, the Python code doesn't work as I would expect. It seems not to make a difference whether I specify the frame size or not.

Its the same device args, so python/c++ it shouldnt make a difference.    The driver is however testing if it can handle that MTU by sending test  packets. Perhaps its still a network configuration issue?    Also, you should be able to    uhd_usrp_probe --args="addr0=10.1.1.105, recv_frame_size=4096,  send_frame_size=4096"    and still see the same issue.    -josh

Lots of network cards don't handle jumbograms, even if you configure them to do so.

 

 

Re: [Discuss-gnuradio] MTU Size

On 07/23/2012 09:40 AM, Alexander Olihovik wrote:
> More specifically, I've tried changing the device address with:
> device_addr="addr0=10.1.1.105, recv_frame_size=4096, send_frame_size=4096"
> but when running the program, both the recv_frame_size and send_frame_size
> are still 1472 bytes.
> I've also configured my network to be able to handle frames of size 4096,
> and have had this working with C++ code. However, the Python code doesn't
> work as I would expect. It seems not to make a difference whether I specify
> the frame size or not.
>

Its the same device args, so python/c++ it shouldnt make a difference.

The driver is however testing if it can handle that MTU by sending test
packets. Perhaps its still a network configuration issue?

Also, you should be able to

uhd_usrp_probe --args="addr0=10.1.1.105, recv_frame_size=4096,
send_frame_size=4096"

and still see the same issue.

-josh

> On Mon, Jul 23, 2012 at 11:56 AM, Alexander Olihovik <ano9cn@virginia.edu>wrote:
>
>> Hi all,
>> I'm currently getting overflow errors that I believe could be remedied by
>> increasing the MTU size.
>> Is there a way to change the recv_frame_size and send_frame_size in Python?
>>
>> I've read the Transport Application Notes and some old emails to this
>> list, but I still can't figure out how to pass these parameters to the USRP
>> objects. Any help is greatly appreciated!
>>
>> -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] Discuss-gnuradio Digest, Vol 116, Issue 24

On 07/23/2012 09:31 AM, Kinal, George V. wrote:
> Interested in your advice: * You need to set the wire format to sc8
> (thats 2 bytes per complex sample) to achieve 50 Msps over gigabit
> ethernet.
>
> Where is this documented ?
>

It might be worth looking at the python code generated when using a USRP
source/sink in GRC.

Here is the new factory function. The old one you are calling into has
less options:
http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/include/gr_uhd_usrp_sink.h#n112

And here is quite a bit of info about stream args:
http://files.ettus.com/uhd_docs/doxygen/html/structuhd_1_1stream__args__t.html

>
>
> The observed RF output appears to be irregular, as if some samples
> have been skipped or the sample file is incomplete or ? Could we
> have an incorrect wire format or some other related problem ? There
> are no buffer underrun problems except when the focus is removed from
> the terminal window, when we get the stream of L's effect, now well
> known :-) .
>

I dont think you can have the wire format wrong, thats kind of hidden
from user access. You could be interpreting a binary file wrong when
passing the buffers to UHD for example.

It might be worth using an app like uhd_siggen to spit out some test
tones and prove that the overall system is working as expected.

-josh

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

Re: [Discuss-gnuradio] MTU Size

More specifically, I've tried changing the device address with:
device_addr="addr0=10.1.1.105, recv_frame_size=4096, send_frame_size=4096"
but when running the program, both the recv_frame_size and send_frame_size are still 1472 bytes.
I've also configured my network to be able to handle frames of size 4096, and have had this working with C++ code. However, the Python code doesn't work as I would expect. It seems not to make a difference whether I specify the frame size or not.

On Mon, Jul 23, 2012 at 11:56 AM, Alexander Olihovik <ano9cn@virginia.edu> wrote:

Hi all,
I'm currently getting overflow errors that I believe could be remedied by increasing the MTU size.
Is there a way to change the recv_frame_size and send_frame_size in Python?

I've read the Transport Application Notes and some old emails to this list, but I still can't figure out how to pass these parameters to the USRP objects. Any help is greatly appreciated!

-Alex

--
Alex Olihovik
University of Virginia 2013
BS Electrical Engineering
BS Computer Engineering
ano9cn@virginia.edu

Re: [Discuss-gnuradio] Discuss-gnuradio Digest, Vol 116, Issue 24

Interested in your advice:
* You need to set the wire format to sc8 (thats 2 bytes per complex
sample) to achieve 50 Msps over gigabit ethernet.

Where is this documented ?

We have an application using N210 and a sampling rate of 16.667 MHz. Some code fragments in Python include:

1. self._u = uhd.usrp_sink3(device_addr=options.address, io_type=uhd.io_type.COMPLEX_FLOAT32, 1)

2. def set_vector(self):
{ some stuff that opens an IQ file, text format, converts to complex using v=[ ( x[i] + 1j*x[i+1]) for I in range(0,len(x),2) ] }

3. tb.set_vector()


The observed RF output appears to be irregular, as if some samples have been skipped or the sample file is incomplete or ? Could we have an incorrect wire format or some other related problem ? There are no buffer underrun problems except when the focus is removed from the terminal window, when we get the stream of L's effect, now well known :-) .


George Kinal
Lead Engineer
MITRE E531 Signal Processing and Communications Analysis



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

Re: [Discuss-gnuradio] Transmit and Received Signals are Different

Perhaps you are seeing a small frequency offset between RX and TX. I
recommend experimenting a little more in simulation:

* What happens you pass the same square wave through that low pass
filter you mentioned. Whats it look like?

 When I pass the square wave through the low pass filter it does become a sine wave, so that means it's normal. Does the low pass filter implement a Fourier transform? If it does, that could explain why if ends up looking like a sine. In the comments in the fr_firdes.cc file, it says "// a little algebra gets this into the more familiar sin(x)/x form". This looks like the Fourier transform of the rect(t) function, but I can't really tell what is happening from the code.

* What happens when you apply a small frequency shift to the square
wave? I recommend using the channel model block for this.

It took a while to figure what the channel block was used for because I never seen it while looking through the blocks in grc. The taps parameter was used for a filter it seems, but I don't really understand the taps very well. I left it at the default 1.0 + 1.0j hope that is ok for this purpose. When I changed the frequency shift parameter in the channel model block, the signal on the scope sink became "shaky". If I increase the shift a little more, the signal changes to something similar to the picture I attached in the previous post. I think I get a different signal when I shift frequencies because the signal hovers around 50u whenever I'm not near the the source's frequency. I would like to know what units are used in the channel model block's frequency shift parameter because when I use 150m the Fourier transform sink shows something like a 30kHz shift. I also realized that the low pass filter should be set to have a cutoff frequency greater than 1kHz.

If I am observing a fluctuation in the RX and TX frequency offset, then is there a way to accommodate for this. Since the offset changes at random intervals, I don't see a way to shift in the opposite direction by the correct amount. Now that I know the low pass filter makes a signal look like a sine wave, is it possible to revert the signal back to the original form?

Thanks,
Frederick

[Discuss-gnuradio] MTU Size

Hi all,
I'm currently getting overflow errors that I believe could be remedied by increasing the MTU size.
Is there a way to change the recv_frame_size and send_frame_size in Python?

I've read the Transport Application Notes and some old emails to this list, but I still can't figure out how to pass these parameters to the USRP objects. Any help is greatly appreciated!

-Alex

Re: [Discuss-gnuradio] Where can I write the Coding of C++ in the GNU radio

Hi Anis,

 

I think a good starting would be to modify "rx_samples_to_file.cpp" or "tx_samples_to_file.cpp.".  The files are located in uhd/host/examples.

 

How many USRPs will you use?  Will they use the same host machine?  Time synchronization is possible using the PPS input on a USRP2 or N2xx.  My group uses the PPS and 10MHz oscillator output from a GPS receiver for time sync.  Check out the following for more information on synchronzing device time: http://files.ettus.com/uhd_docs/manual/html/sync.html

 

Hope this helps!

Ryan

On Mon, Jul 23, 2012 at 7:40 AM, Abdelrahman Anis <abdelrahman_anis@yahoo.com> wrote:

Hi all,

Sorry if this question is repeated, I am still a beginner in GNU radio, I couldn't find the answer after searching the Web.

Where I can write the Coding of C++ in the GNU radio? and How can access these Installed C++ blocks in GNU radio ?
I want it to run a project of Parallel Processing using C++ to operate multiple USRPs with 20 MS/s each at the same time synchronized with each others.
I am using Ubuntu 10.04 LTS as operating system.
Thanks in advance.

Anis 

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

[Discuss-gnuradio] Where can I write the Coding of C++ in the GNU radio

Hi all,

Sorry if this question is repeated, I am still a beginner in GNU radio, I couldn't find the answer after searching the Web.

Where I can write the Coding of C++ in the GNU radio? and How can access these Installed C++ blocks in GNU radio ?
I want it to run a project of Parallel Processing using C++ to operate multiple USRPs with 20 MS/s each at the same time synchronized with each others.
I am using Ubuntu 10.04 LTS as operating system.
Thanks in advance.

Anis 

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

[Discuss-gnuradio] System overrun after short time

Hi Lists,

I wrote a program in C + + use gnuradio library to demodulate some signals. The program works well with the low data rate signal (below 20 Ksymbols/s). With higher data rate signal: 200 Ksymbols/s, the program works well for a few minutes then the console window will appear the letters 'O' continuously and data after demodulation was wrong. With 1 Msymbols/s signal, the system can operate well over 1 minute.

Could you help me to solve the problem, please?

Thank you.

Best regards,

Phong.

[Discuss-gnuradio] siggen.py transmission Error

i m trying to transmit simple sin wave to check my usrp transmission
reception .
when i run usrp_siggen.py -f 900M --> " Using TX d'board A: <none> " is
displayed on terminal.
when i run usrp_fft.py -f 900M --> Failed to set RF initial frequency is
displayed in " FFT GUI "+ " u0u0u0u0..... " is displayed in terminal.

i m using gnu radio 3.2.2
USRP1
D.Boards Flex900.
fujitsu core i7 (as i have read that u0u0u0u0 is due to low performance P.C
)
Need Your Help plz.

Regards
Bilal Nasir.



--
View this message in context: http://old.nabble.com/siggen.py-transmission-Error-tp34199166p34199166.html
Sent from the GnuRadio mailing list archive at Nabble.com.


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

Re: [Discuss-gnuradio] Empty Device Address - EzTV 668

On 22/07/12 10:54 PM, David Brush wrote:

Hello,

I am trying to get GNU Radio up and running, I am am experiencing an error that I haven't been able to fix. It seems that uhd cannot find my EzTV 668 usb dongle. rtl_test, however, lists it correctly. When I try to run uhd_fft, I get a traceback and an error that says "No device found for ----> Empty device address." I used the most recent version of build-gnuradio to install all of the components, and have an up to date Ubuntu 12.04 x86_64 distribution. I have also made sure that udev was configured per http://files.ettus.com/uhd_docs/manual/html/transport.html#usb-transport-libusb. I have attached the outputs I get from lsusb, rtl_test, uhd_fft, and uhd_find_devices. Please help!

I can provide additional info as needed.

Thank you!

-David

$ lsusb

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Bus 001 Device 003: ID 0bda:0158 Realtek Semiconductor Corp. USB 2.0 multicard reader

Bus 001 Device 004: ID 05ca:180a Ricoh Co., Ltd 

Bus 003 Device 007: ID 413c:8160 Dell Computer Corp. Wireless 365 Bluetooth

Bus 003 Device 002: ID 0a5c:4500 Broadcom Corp. BCM2046B1 USB 2.0 Hub (part of BCM2046 Bluetooth)

Bus 003 Device 003: ID 413c:8161 Dell Computer Corp. Integrated Keyboard

Bus 003 Device 004: ID 413c:8162 Dell Computer Corp. Integrated Touchpad [Synaptics]

Bus 002 Device 008: ID 0bda:2838 Realtek Semiconductor Corp. 

$ 

$ 

$ 

$ rtl_test

Found 1 device(s):

  0:  ezcap USB 2.0 DVB-T/DAB/FM dongle

Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle

Found Elonics E4000 tuner

Supported gain values (18): -1.0 1.5 4.0 6.5 9.0 11.5 14.0 16.5 19.0 21.5 24.0 29.0 34.0 42.0 43.0 45.0 47.0 49.0 

Reading samples in async mode...

^CSignal caught, exiting!

User cancel, exiting...

$ uhd_find_devices

linux; GNU C++ version 4.6.3; Boost_104601; UHD_003.004.002-181-g25649781

No UHD Devices Found

$ uhd_fft

linux; GNU C++ version 4.6.3; Boost_104601; UHD_003.004.002-181-g25649781

Traceback (most recent call last):

  File "/usr/local/bin/uhd_fft", line 337, in <module>

    main ()

  File "/usr/local/bin/uhd_fft", line 333, in main

    app = stdgui2.stdapp(app_top_block, "UHD FFT", nstatus=1)

  File "/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py", line 38, in __init__

    wx.App.__init__ (self, redirect=False)

  File "/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py", line 7981, in __init__

    self._BootstrapApp()

  File "/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py", line 7555, in _BootstrapApp

    return _core_.PyApp__BootstrapApp(*args, **kwargs)

  File "/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py", line 42, in OnInit

    self._max_noutput_items)

  File "/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py", line 64, in __init__

    self.panel = stdpanel (self, self, top_block_maker, max_nouts)

  File "/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py", line 86, in __init__

    self.top_block = top_block_maker (frame, self, vbox, sys.argv)

  File "/usr/local/bin/uhd_fft", line 91, in __init__

    otw_format=options.wire_format, args=options.stream_args))

  File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py", line 116, in constructor_interceptor

    return old_constructor(*args)

  File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py", line 2726, in usrp_source

    return _uhd_swig.usrp_source(*args)

RuntimeError: LookupError: KeyError: No devices found for ----->

Empty Device Address

$ 

Thanks again!

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

UHD devices are those manufactured by Ettus Research (the USRP family), and have *nothing* to do with
  RTLSDR dongles at all.

build-gnuradio installs both gr-osmosdr, and rtl-sdr components, and I think they include a simple test app,
 other than rtl_test--osmosdr_source_1rtl.grc  appears to be a simple test app for gr-osmosdr-type devices,
  including RTLSDR devices.

Now, confusingly enough, the gr-osmosdr *source* object for Gnu Radio acts a kind of quasi-universal
  abstraction layer for SDR-like hardware, so you can use that source for RTLSDR, OSMOSDR, FunCube, and
  UHD-type devices.  Until the (very recent) advent of gr-osmosdr, there wasn't any hardware-independant
  device abstraction for Gnu Radio, although UHD provides a universal abstraction for USRP devices, there
  was nothing that was cross-manufacturer.  With gr-osmosdr, you can write an RX flow-graph that doesn't
  really "know" very much about the hardware involved.

--   Principal Investigator  Shirleys Bay Radio Astronomy Consortium  http://www.sbrac.org

[Discuss-gnuradio] Empty Device Address - EzTV 668

Hello,

I am trying to get GNU Radio up and running, I am am experiencing an error that I haven't been able to fix. It seems that uhd cannot find my EzTV 668 usb dongle. rtl_test, however, lists it correctly. When I try to run uhd_fft, I get a traceback and an error that says "No device found for ----> Empty device address." I used the most recent version of build-gnuradio to install all of the components, and have an up to date Ubuntu 12.04 x86_64 distribution. I have also made sure that udev was configured per http://files.ettus.com/uhd_docs/manual/html/transport.html#usb-transport-libusb. I have attached the outputs I get from lsusb, rtl_test, uhd_fft, and uhd_find_devices. Please help!

I can provide additional info as needed.

Thank you!

-David

$ lsusb

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Bus 001 Device 003: ID 0bda:0158 Realtek Semiconductor Corp. USB 2.0 multicard reader

Bus 001 Device 004: ID 05ca:180a Ricoh Co., Ltd 

Bus 003 Device 007: ID 413c:8160 Dell Computer Corp. Wireless 365 Bluetooth

Bus 003 Device 002: ID 0a5c:4500 Broadcom Corp. BCM2046B1 USB 2.0 Hub (part of BCM2046 Bluetooth)

Bus 003 Device 003: ID 413c:8161 Dell Computer Corp. Integrated Keyboard

Bus 003 Device 004: ID 413c:8162 Dell Computer Corp. Integrated Touchpad [Synaptics]

Bus 002 Device 008: ID 0bda:2838 Realtek Semiconductor Corp. 

$ 

$ 

$ 

$ rtl_test

Found 1 device(s):

  0:  ezcap USB 2.0 DVB-T/DAB/FM dongle

Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle

Found Elonics E4000 tuner

Supported gain values (18): -1.0 1.5 4.0 6.5 9.0 11.5 14.0 16.5 19.0 21.5 24.0 29.0 34.0 42.0 43.0 45.0 47.0 49.0 

Reading samples in async mode...

^CSignal caught, exiting!

User cancel, exiting...

$ uhd_find_devices

linux; GNU C++ version 4.6.3; Boost_104601; UHD_003.004.002-181-g25649781

No UHD Devices Found

$ uhd_fft

linux; GNU C++ version 4.6.3; Boost_104601; UHD_003.004.002-181-g25649781

Traceback (most recent call last):

  File "/usr/local/bin/uhd_fft", line 337, in <module>

    main ()

  File "/usr/local/bin/uhd_fft", line 333, in main

    app = stdgui2.stdapp(app_top_block, "UHD FFT", nstatus=1)

  File "/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py", line 38, in __init__

    wx.App.__init__ (self, redirect=False)

  File "/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py", line 7981, in __init__

    self._BootstrapApp()

  File "/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py", line 7555, in _BootstrapApp

    return _core_.PyApp__BootstrapApp(*args, **kwargs)

  File "/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py", line 42, in OnInit

    self._max_noutput_items)

  File "/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py", line 64, in __init__

    self.panel = stdpanel (self, self, top_block_maker, max_nouts)

  File "/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py", line 86, in __init__

    self.top_block = top_block_maker (frame, self, vbox, sys.argv)

  File "/usr/local/bin/uhd_fft", line 91, in __init__

    otw_format=options.wire_format, args=options.stream_args))

  File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py", line 116, in constructor_interceptor

    return old_constructor(*args)

  File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py", line 2726, in usrp_source

    return _uhd_swig.usrp_source(*args)

RuntimeError: LookupError: KeyError: No devices found for ----->

Empty Device Address

$ 

Thanks again!

Re: [Discuss-gnuradio] Trying to use the complex int16 option of the UHD blocks

On 07/22/2012 01:14 PM, Nazmul Islam wrote:
> Hello,
>
> I am trying to use the complex int16 option of the UHD (source/sink)
> blocks in my GRC generated python codes. I am doing wide band spectral
> analysis in my experiments. Therefore, 50 MS/s will be very helpful for me.
>

The host format and the wire format are totally independent options
here. Both of these properties also configurable properties in the GRC
USRP source/sink blocks.

* You need to set the wire format to sc8 (thats 2 bytes per complex
sample) to achieve 50 Msps over gigabit ethernet.

* The desired host format does not have to change. fc32 (complex floats)
is a perfectly valid setting

-josh

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

[Discuss-gnuradio] Trying to use the complex int16 option of the UHD blocks

Hello,

 I am trying to use the complex int16 option of the UHD (source/sink) blocks in my GRC generated python codes. I am doing wide band spectral analysis in my experiments. Therefore, 50 MS/s will be very helpful for me.

I currently have a working transmitter and receiver that use the complex float32 option of the UHD blocks. I am getting 25 MS/s rate at this point. The images of the transmitter and the receiver flow graphs are attached as "Original_Float_32_transmitter.png" and "Original_Float_32_receiver.png". I used the "Reconstructed_int16_transmitter.png" and "Reconstructed_int16_receiver.png" as the new transmitter and the receiver with the complex int16 option. However, I am finding difficulty to connect the signal processing blocks with the UHD (complex int16) block at this point. I have the following issues:

1. In my original transmitter flow-graph, the real part of the complex input to UHD is coming from a GLFSR->RRC float source. The imaginary part is coming from a null source. I don't see any int option in the RRC block and an int->complex block in GRC. Therefore, I am not sure how I can transmit GLFSR as the real part & null as the imaginary part with the Complex Int16 option.

2. In my original receiver, the complex float32 output is going through a polyphase clock synchronizer that provides a complex -> complex conversion. However, when I use complex int16 in the transmitter, I have to use float->float in polyphase clock sync to ensure type matching in GRC window. Firstly, I don't know if the polyphase synchronization is working on the real & imaginary part in the desired manner at this point. Secondly, when I run this receiver, I get the following error:

TypeError: pfb_clock_sync_fff() takes at most 6 arguments (7 given)


Overall, I want to use the complex int16 option in my original transmitter + receiver flow graph so that I can achieve 50 MS/s rate. Any suggestion will be appreciated.


Thanks,

Nazmul





--
Muhammad Nazmul Islam

Graduate Student
Electrical & Computer Engineering
Wireless Information & Networking Laboratory
Rutgers, USA.

[Discuss-gnuradio] GSoC: Filter Design tool update

Hi all,

A brief update on the new features added to the filter design tool[1]

--IIR Filter Design (Scipy Based)

   -Butterworth

   -Elliptic

   -Chebyshev-1

   -Chebyshev-2

   -Bessel

--Pole-zero plot now supports addition, deletion of poles/zeros with conjugate support.

A small video showing some of the added features can be found here[2].

At first I started using Robert McGwier's existing code[3] and added features to that as suggested by Tom and Martin. Later finding that Scipy's filter design functions[4] are very much optimized and robust, I decided to use those. Martin also pointed out that it will just be a duplication of work and suggested me to use scipy for IIR design.

I did a basic integration of the code to gr-filter component of GNU Radio[5]. I haven't pushed icons yet to the branch. It would be really helpful if anyone can comment on the current integration, so that I can make suitable modifications.

In next few weeks I will be adding some special filters like half-band filter to the design tool, then will proceed with integration of gr_filter_design to GRC and will try to add QA tests for filter design routines wherever they are missing.

[1]https://github.com/zeroXzero/gr-filtdes

[2]http://www.youtube.com/watch?v=20ZrfUZjUUA

[3]http://gnuradio.org/cgit/n4hy.git/log/?h=n4hy_iir

[4]http://docs.scipy.org/doc/scipy/reference/signal.html

[5]https://github.com/zeroXzero/gnuradio-sreeraj Branch: filtdes_gui

 

---
Regards
Sreeraj Rajendran
http://home.iitb.ac.in/~rsreeraj

Re: [Discuss-gnuradio] pmt_t type argument for custom block in grc

On 07/20/2012 03:36 PM, Zing Yu wrote:
> Hi All,
>
> I have a little question for you. I have a custom block which accepts a pmt::pmt_t type arguement/parameter among others. I have written an xml file for my custom block so as to use it inside gnuradio-companion but I see the following error message:
> Param - value(value):
> Type "pmt::pmt_t" is not a possible type.
>
> Param - value(value):
> Type "pmt::pmt_t" not handled
>
>
> So I just want to double check, the pmt_t types can't be inputted to a block as parameter?
>

There isnt a type checker implement. If you make the <type>raw</type>
then GRC will let you pass it just fine.

-josh

> Thanks,
> Yu.
>
>
>
> _______________________________________________
> 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] pmt_t type argument for custom block in grc

Hi All,

I have a little question for you. I have a custom block which accepts a pmt::pmt_t type arguement/parameter among others. I have written an xml file for my custom block so as to use it inside gnuradio-companion but I see the following error message:

Param - value(value):
    Type "pmt::pmt_t" is not a possible type.

Param - value(value):
    Type "pmt::pmt_t" not handled

So I just want to double check, the pmt_t types can't be inputted to a block as parameter?

Thanks,

Yu.

Re: [Discuss-gnuradio] Problem compiling on "Raspbian wheezy".

Hi Nick,

Philip Balister pointed me at this patch:

http://lists.gnu.org/archive/html/patch-gnuradio/2012-07/msg00007.html

I applied this and then ran cmake with:

cmake -Dhave_mfpu_neon=0 -DCMAKE_CXX_FLAGS:STRING="-march=armv6
-mfpu=vfp -mfloat-abi=hard" -DCMAKE_C_FLAGS:STRING="-march=armv6
-mfpu=vfp -mfloat-abi=hard" ../

And the build was successful. Many thanks to all who have helped!

Is there an easy way to tell if this will now be using hardware floating point?

Regards,

Andrew

On 20 July 2012 15:46, Nick Foster <nick@ettus.com> wrote:
> It's still detecting and attempting to compile NEON vector instructions in
> gr-filter; there are NEON assembly routines in there intended to speed up
> E100 filter operations. I don't know what string CMake should be checking
> for there, but "arm" is inappropriate, since it makes no attempt to
> determine if the ARM has NEON support or not. We should probably write a
> "FindNeon.cmake" to set this more appropriately.
>
> In the meantime, you can cut out that entire section of filter stuff
> starting at gnuradio-core/src/lib/filter/CMakeLists.txt line 212.
>
> --n
>
>
> On Thu, Jul 19, 2012 at 10:36 PM, Andrew Back <andrew@carrierdetect.com>
> wrote:
>>
>> On 19 July 2012 18:06, Nick Foster <nick@ettus.com> wrote:
>> > The --mfpu=neon flag is inappropriate for Raspberry Pi, which lacks
>> > NEON. I
>> > suspect Gnuradio's build system is detecting ARM and assuming NEON
>> > exists. I
>> > know gr-filter is doing this (see
>> > gnuradio/gnuradio-core/src/lib/filter/CMakeLists.txt line 212).
>> >
>> > Some rudimentary checking for NEON is probably appropriate. Volk is
>> > already
>> > doing this, although its checks are at runtime so they look a little
>> > different than a CMake script would.
>>
>> So I found [1] what appears to be the correct flags and set these:
>>
>> cmake -DCMAKE_CXX_FLAGS:STRING="-march=armv6 -mfpu=vfp
>> -mfloat-abi=hard" -DCMAKE_C_FLAGS:STRING="-march=armv6 -mfpu=vfp
>> -mfloat-abi=hard" ../
>>
>> But now the build fails even earlier with gnuradio-core:
>>
>> [ 17%] Building CXX object
>>
>> gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/gr_fir_fff_armv7_a.cc.o
>> [ 17%] Building C object
>>
>> gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/dotprod_fff_armv7_a.c.o
>> /tmp/ccHDAfuu.s: Assembler messages:
>> /tmp/ccHDAfuu.s:26: Error: selected FPU does not support instruction
>> -- `vmov.f32 q8,#0.0'
>> /tmp/ccHDAfuu.s:27: Error: selected FPU does not support instruction
>> -- `vmov.f32 q9,#0.0'
>> /tmp/ccHDAfuu.s:30: Error: selected processor does not support ARM
>> mode `vld1.32 {d0,d1,d2,d3},[r0]!'
>> /tmp/ccHDAfuu.s:31: Error: selected processor does not support ARM
>> mode `vld1.32 {d4,d5,d6,d7},[r1]!'
>> /tmp/ccHDAfuu.s:32: Error: selected FPU does not support instruction
>> -- `vmla.f32 q8,q0,q2'
>> /tmp/ccHDAfuu.s:33: Error: selected FPU does not support instruction
>> -- `vmla.f32 q9,q1,q3'
>> /tmp/ccHDAfuu.s:35: Error: selected FPU does not support instruction
>> -- `vadd.f32 q8,q8,q9'
>> /tmp/ccHDAfuu.s:36: Error: selected processor does not support ARM
>> mode `vpadd.f32 d0,d16,d17'
>> make[2]: ***
>> [gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/dotprod_fff_armv7_a.c.o]
>> Error 1
>> make[1]: *** [gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/all]
>> Error 2
>> make: *** [all] Error 2
>>
>> Which IIRC is around where it was failing when I did not set any flags
>> at all with Cmake.
>>
>> Regards,
>>
>> Andrew
>>
>> [1]
>> http://www.raspbian.org/RaspbianFAQ#What_compilation_options_should_be_set_Raspbian_code.3F
>>
>> --
>> Andrew Back
>> http://carrierdetect.com
>
>



--
Andrew Back
http://carrierdetect.com

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