Re: [Discuss-gnuradio] UHD + USRP2 + WBX doubt

[skcruser]

thanks josh

Josh Blum-3 wrote:
> 
> 
> 
> On 09/08/2011 11:15 PM, skcruser wrote:
>> 
>> I am using the WBX daughterboard with USRP2 interfaced using the UHD
>> Driver.
>> 
>> The LED boot sequence is as follows
>> 1. F turns on
>> 2. E, C, A turn on and then blink and turn off
>> 3. D turns on
>> 
>> is the above sequence correct? (B never turns on)
>> 
>> also when I run uhd_fft.py, led C turns ON. is it normal or shud i be
>> worried?
>> 
>> PS - what is the significance of each LED??
> 
> http://files.ettus.com/uhd_docs/manual/html/usrp2.html#front-panel-leds
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 

-- 
View this message in context: 
http://old.nabble.com/UHD-%2B-USRP2-%2B-WBX-doubt-tp32428919p32429281.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] UHD + USRP2 + WBX doubt

[sumitstop]

http://www.youtube.com/watch?v=REDK7M-83WQ

uhd_fft.py receives the signal from the specified range and shows its
spectrum... hence led C turns on which that indicates usrp2 is receiving.



skcruser wrote:
> 
> I am using the WBX daughterboard with USRP2 interfaced using the UHD
> Driver.
> 
> The LED boot sequence is as follows
> 1. F turns on
> 2. E, C, A turn on and then blink and turn off
> 3. D turns on
> 
> is the above sequence correct? (B never turns on)
> 
> also when I run uhd_fft.py, led C turns ON. is it normal or shud i be
> worried?
> 
> PS - what is the significance of each LED??
> 


-
Sumit Kr.
Research Assistant
Communication Research center
IIIT Hyderabad
India
-- 
View this message in context: 
http://old.nabble.com/UHD-%2B-USRP2-%2B-WBX-doubt-tp32428919p32429230.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] UHD + USRP2 + WBX doubt

[sumitstop]

http://www.youtube.com/watch?v=REDK7M-83WQ


skcruser wrote:
> 
> I am using the WBX daughterboard with USRP2 interfaced using the UHD
> Driver.
> 
> The LED boot sequence is as follows
> 1. F turns on
> 2. E, C, A turn on and then blink and turn off
> 3. D turns on
> 
> is the above sequence correct? (B never turns on)
> 
> also when I run uhd_fft.py, led C turns ON. is it normal or shud i be
> worried?
> 
> PS - what is the significance of each LED??
> 


-
Sumit Kr.
Research Assistant
Communication Research center
IIIT Hyderabad
India
-- 
View this message in context: 
http://old.nabble.com/UHD-%2B-USRP2-%2B-WBX-doubt-tp32428919p32429214.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] OFDM Implementation

[sumitstop]

http://pwnhome.files.wordpress.com/2011/04/simple_transceiver1.png
see carefully... it has a gmsk modulator in the bottom.u can make the
bottom modulator part in another pc

benchmark programs are quite good to start with...
u can type benchmark_ofdm.py -h to see all the parameters u can play with.


waqasme wrote:
> 
> And sorry to mention in the last mail that i will be suing USRP 1 .
> 
> waqasme wrote:
>> 
>> Hi Sumit,
>> Thank you so much for your quick response. yah i understand what your
>> saying and i am trying to understand this document but it doesnot help
>> much . As you mentioned use the same Tranceiver setup and only replace
>> OFDM blocks with that. My question is in this basic tranciver diagram the
>> used two UHD's source and sink and in the middle they use GMSK
>> Demodulator right. but they didnot use any modulator any where in the
>> design. Now i am confused what blocks i have to replace with OFDM
>> blocks??? Please try to explain in bit detail so i can design it properly
>> . 
>> OR you mentioned other option that use benchmark_OFDM.py file . Somebody
>> already told me about this benchmark file. but its just C++ code . i am
>> quite new to GNU radio and dont know much about the functions how it
>> works. 
>> Please let me know how to use that benchmark_OFDM.py file in order to
>> make the simulation design? do i have to download the file or what? how
>> it works ?? let me know if you know about the process how to compile and
>> run that code in GNU radio.
>> 
>> Thanks for ur help and support really appriciate that...
>> 
>> Regards,
>> 
>> Waqas.
>> 
>> 
>> sumitstop wrote:
>>> 
>>> Try to understand these 
>>> 
>>> http://pwnhome.wordpress.com/2011/04/26/intro-to-gnuradio-and-the-usrp-part-5-simple-transceiver/
>>> 
>>> here u need to put those ofdm blocks .. thats it also go through
>>> some modifications as written in umit,
>>> 
>>> 
>>> http://pwnhome.wordpress.com/2011/04/19/intro-to-gnuradio-and-the-usrp-part-4/
>>> 
>>> or else work with benchmark_ofdm.py  its very easy.. :)
>>> 
>>> may i know what daughter boards do you have... 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> waqasme wrote:
 
 
 Hello sumit,
 Thanks for your help i went through that document that you refered to,
 and i tried to implement that OFDM transmitter part. This document only
 explain about OFDM flow graph or transmitter. Is there any other
 document or information related to OFDM modulator and demodulator
 (Transceiver)? i haver to implement OFDM transmission and reception via
 USRP. i will really appriciate if you can help me that or someone else
 who knows how to implement by using GNU radio companion.
 Thanks in advance.
 Regards,
 Waq.
 
 
>>> 
>>> 
>> 
>> 
> 
> 


-
Sumit Kr.
Research Assistant
Communication Research center
IIIT Hyderabad
India
-- 
View this message in context: 
http://old.nabble.com/OFDM-Implementation-tp32380874p32429184.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] UHD + USRP2 + WBX doubt

[Josh Blum]

On 09/08/2011 11:15 PM, skcruser wrote:
> 
> I am using the WBX daughterboard with USRP2 interfaced using the UHD
> Driver.
> 
> The LED boot sequence is as follows
> 1. F turns on
> 2. E, C, A turn on and then blink and turn off
> 3. D turns on
> 
> is the above sequence correct? (B never turns on)
> 
> also when I run uhd_fft.py, led C turns ON. is it normal or shud i be
> worried?
> 
> PS - what is the significance of each LED??

http://files.ettus.com/uhd_docs/manual/html/usrp2.html#front-panel-leds

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

[Discuss-gnuradio] UHD + USRP2 + WBX doubt

[skcruser]

I am using the WBX daughterboard with USRP2 interfaced using the UHD
Driver.

The LED boot sequence is as follows
1. F turns on
2. E, C, A turn on and then blink and turn off
3. D turns on

is the above sequence correct? (B never turns on)

also when I run uhd_fft.py, led C turns ON. is it normal or shud i be
worried?

PS - what is the significance of each LED??
-- 
View this message in context: 
http://old.nabble.com/UHD-%2B-USRP2-%2B-WBX-doubt-tp32428919p32428919.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] Cognitive Radio Implementation with XML

[Songsong Gee]

Hello,

I'm now trying to make congitive radio with help of a following article.
Configurable SDR Operation for Cognitive Radio Applications using GNU Radio
and the Universal Software Radio Peripheral, *
http://scholar.lib.vt.edu/theses/available/etd-05182007.../01thesis_whole5.pdf
*
**

This article proposed XML files for defining SDR and its behaviors. And it
said that SDR can use these XML files with XML parser.
However, I have a difficulties on using the parser. The mentioned article
doesn't show the part that implementing XML parser.

Is it impossible to use the parser in GRC? Only for a .py file typed
manually?

-- 
Seokseong Jeon (aka Songsong Gee)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OSX Audio Problem - AudioUnitRender kAudioUnitErr_CanNotDoInCurrentContext

[Kunal Kandekar]

Hmm, I haven't tried this with the line-in input, although I have previously
had problems using line-in on older versions of OS X and/or GNU Radio.

If it doesn't work, one option is to try the hack that I was trying -
capture audio in Java (or any other language) and pipe it to GNU Radio over
a socket. Attached is a modified version of the Java code that lets you
select an audio input line. Compile using "java AudioSource.java" as before,
and run using:
java AudioSource   [samplerate] [line] [bits/sample] [channels]

The [line] option is a number identifying the audio line you want to use.
Try numbers 0, 1, etc. (the code lists all available lines when you run it
regardless of the value of [line].) One of the available lines *should* be
the line-in. E.g. -
clear; java AudioScope localhost  44100 1 16 1

Also attached is a Python script implementing a GR hierarchical block that
starts a TCP server socket and accepts a connection from an external (Java)
process. You can then connect it to a flowgraph like any other GR source
block. E.g.

from server_src import server_src
...
audio_src = server_src(gr.sizeof_float, , 'localhost')
fg.connect(audio_src, other_blocks, ...) # fg is your flowgraph
...
audio_src.start()   # must call start to accept connection else script will
hang
fg.start()

Make sure you start the GR flowgraph before you start the Java process. It's
a awkward hack, but it's worked for me so far... Hope this helps.

Kunal


On Thu, Sep 8, 2011 at 8:03 PM, chris lirakis  wrote:

> Hi Kunal,
> Thanks for the info. I'll try this in a few minutes. I forgot to mention in
> my post that there is another oddity. The code works fine if I use the
> internal microphone but when I set the input source to line in the
> preferences panel is when I get the error. The error appears to be in the
> render function. Certainly when I compile the code there are deprecated
> references, but I don't think they are the source of the problem. It is
> curious that the line input has different functionality than the microphone.
> I hope your fix works cuz I'm showing this stuff off this weekend.
> Chris
>
>
> On Thu, Sep 8, 2011 at 4:03 PM, Kunal Kandekar wrote:
>
>> Hi,
>>
>> I've been having problems with the audio on OSX as well. Ever since 10.5,
>> really. I am not sure what the cause is... maybe the code in
>> audio_osx_source.cc is incompatible with changes in the OSX audio frameworks
>> that may have occurred under the hood.
>>
>> However, I currently have a really, really horrible hack that works for
>> some reason: I run a Java app that does nothing but open up an audio source
>> line, close it and shut down. After that I have no trouble with any of the
>> gr audio osx blocks. (I had some Java audio recording code lying around,
>> which I rewrote to pipe audio into GNU Radio over a socket as a quick
>> replacement for the gr audio_osx_source block, and I accidentally discovered
>> that the block started working after I ran the Java app.)
>>
>> I suspect there is something in CoreAudio (or AudioUnit?) that must be
>> initialized that audio_osx_source is not doing, but somehow the Java app
>> does it. I am at a loss to explain how this persists even after the Java app
>> terminates. The fix persists until you reboot the machine.
>>
>> In case you want to give it a shot, I've attached the Java source. Compile
>> it with "javac AudioSource.java" and run it with "java AudioSource localhost
>>  44100 mic 16 2". It will exit with an error saying it cannot connect to
>> a socket, but it should have worked its magic anyway. If it works, you
>> should be able to use audio_osx_source with no problems. It would be very
>> interesting to see if it works for you.
>>
>> I've been meaning to dig into the audio_osx_source code and OSX audio
>> internals to figure out the bug, but haven't had time. There are a few other
>> problems that need fixing as well (e.g. device_name is not properly used).
>>
>> Kunal
>>
>>
>> On Thu, Sep 8, 2011 at 7:48 AM, chris lirakis  wrote:
>>
>>> This appears to be an issue with OSX 10.6. This can be replicated by
>>> running the python audio_fft.py example.
>>>
>>> Searching the web for the error message I find the apple experts saying
>>> that this results from the expectation that a sample rate conversion will
>>> occur. Not being well versed in OSX audio internals I don't know exactly
>>> what that means. I assume that it means that the audio input and output
>>> rates are different.
>>>
>>> My first question is, has anyone else seen this and has it been fixed and
>>> I am not aware of it?
>>>
>>> So I'm slowly looking through gr_audio_osx/src/audio_osx_source.cc and
>>> trying to understand what is going on. Now my second question.
>>>
>>> I did the install using macports but I also have a copy the source of
>>> gnuradio-3.3.0 and have compiled it. I have tried putting some debugging
>>> info in the source and recompiling. I subtituted both the .la and .dyib
>>> libraries produced. 

Re: [Discuss-gnuradio] OSX Audio Problem - AudioUnitRender kAudioUnitErr_CanNotDoInCurrentContext

[chris lirakis]

Hi Kunal,
Thanks for the info. I'll try this in a few minutes. I forgot to mention in
my post that there is another oddity. The code works fine if I use the
internal microphone but when I set the input source to line in the
preferences panel is when I get the error. The error appears to be in the
render function. Certainly when I compile the code there are deprecated
references, but I don't think they are the source of the problem. It is
curious that the line input has different functionality than the microphone.
I hope your fix works cuz I'm showing this stuff off this weekend.
Chris

On Thu, Sep 8, 2011 at 4:03 PM, Kunal Kandekar wrote:

> Hi,
>
> I've been having problems with the audio on OSX as well. Ever since 10.5,
> really. I am not sure what the cause is... maybe the code in
> audio_osx_source.cc is incompatible with changes in the OSX audio frameworks
> that may have occurred under the hood.
>
> However, I currently have a really, really horrible hack that works for
> some reason: I run a Java app that does nothing but open up an audio source
> line, close it and shut down. After that I have no trouble with any of the
> gr audio osx blocks. (I had some Java audio recording code lying around,
> which I rewrote to pipe audio into GNU Radio over a socket as a quick
> replacement for the gr audio_osx_source block, and I accidentally discovered
> that the block started working after I ran the Java app.)
>
> I suspect there is something in CoreAudio (or AudioUnit?) that must be
> initialized that audio_osx_source is not doing, but somehow the Java app
> does it. I am at a loss to explain how this persists even after the Java app
> terminates. The fix persists until you reboot the machine.
>
> In case you want to give it a shot, I've attached the Java source. Compile
> it with "javac AudioSource.java" and run it with "java AudioSource localhost
>  44100 mic 16 2". It will exit with an error saying it cannot connect to
> a socket, but it should have worked its magic anyway. If it works, you
> should be able to use audio_osx_source with no problems. It would be very
> interesting to see if it works for you.
>
> I've been meaning to dig into the audio_osx_source code and OSX audio
> internals to figure out the bug, but haven't had time. There are a few other
> problems that need fixing as well (e.g. device_name is not properly used).
>
> Kunal
>
>
> On Thu, Sep 8, 2011 at 7:48 AM, chris lirakis  wrote:
>
>> This appears to be an issue with OSX 10.6. This can be replicated by
>> running the python audio_fft.py example.
>>
>> Searching the web for the error message I find the apple experts saying
>> that this results from the expectation that a sample rate conversion will
>> occur. Not being well versed in OSX audio internals I don't know exactly
>> what that means. I assume that it means that the audio input and output
>> rates are different.
>>
>> My first question is, has anyone else seen this and has it been fixed and
>> I am not aware of it?
>>
>> So I'm slowly looking through gr_audio_osx/src/audio_osx_source.cc and
>> trying to understand what is going on. Now my second question.
>>
>> I did the install using macports but I also have a copy the source of
>> gnuradio-3.3.0 and have compiled it. I have tried putting some debugging
>> info in the source and recompiling. I subtituted both the .la and .dyib
>> libraries produced. My print statements do not appear.
>>
>> I am assuming that the python audio interface is a dynamically linked
>> object and substitution of my library should work. Is this a false
>> assumption? Is there a better way I can debug this?
>> Regards,
>> Chris
>>
>> --
>> Chris Lirakis
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>


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

[Discuss-gnuradio] OFDM benchmark transmit signal bandwidth

[Guanbo Zheng]

Hi all

I am currently using OFDM benchmark to generate OFDM signal under the
setting of FFT len, CP length, occupied-tones and something.
But I can not find out what is the real bandwidth of signal it generated.
Because when I changed the Interpolation rate (sampling rate), the bandwidth
at RX changed as well.
Ideally we know that setting enough large sampling rate ( In USRP2, the max
fs = 25MHz), I should observe the constant signal with fixed BW.
It seems to me that BW of the generated signal is too large.

My question is: how to determine the BW of transmit signal in the codes?
where I can change it.
All I found is actual bit rate =  (converter_) / xrate / samples_per_symbol
= 100MHz/4/2. But this one seems not related to the BW of signal itself.

Thanks for any suggestions!
-- 
Regards,
Guanbo
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Thoughts on stream tag propagation

[Martin Braun]

On Thu, Sep 08, 2011 at 09:41:03AM -0700, Eugene Grayver wrote:
> Hello,
> I am starting to actively use stream tags and am finding them quite useful.  I
> have one suggestion:
> 
> Tags propagated through a block with a known delay (set_history) should be
> adjusted by that delay.  For example, an input to an FIR filter gets reflected
> in the output after a delay.  Since the GR executor has access to the delay
> info, there's no reason it should not use it.
> 
> Comments?

An FIR filter is a good example why this is not always a good idea: The
group delay (which would be a sensible delay for a tag, I guess) is half
the delay GNU Radio knows about. Can stream tags be delayed w/ respect
to the sample position? That would be more useful, I guess.

MB


> 
> On a separate note, I have observed a _rare_ case where tags get lost.  The
> scenario involves an output attached to two inputs.  The two inputs consume
> data in different (random) chunk blocks.  It appears that if one of the inputs
> consumes items with the tag well before the second input gets to the tagged
> item, the second input sometimes does not see the tag.  I have not debugged
> this enough to confirm that there's no bug in my code.
> 
> Eugene
> 
> Eugene Grayver, Ph.D.
> Aerospace Corp., Sr. Eng. Spec.
> Tel: 310.336.1274
> 

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


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



pgpGe6JAzIKeU.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Modify the Basic RX Daughterboard

[valentac]

My mistake, I am using the BasicRX with the transformer (I was looking at the
wrong datasheet). I could go ahead and get a new transformer, but I would
ideally like a higher impedance than is offered. I just tried to modify the
transformers in the schematic
(http://code.ettus.com/redmine/ettus/documents/2) by removing R3 and R9, and
then changing R6 and R7 to 1 MOhm, however, this didn't seem to give me a
large enough impedance.

Is there a better way to modify the transformer that is on the BasicRX to
give me a high impedance?



Marcus D. Leech wrote:
> 
> On 09/08/2011 01:08 PM, valentac wrote:
>> I have my own RF front end i'm using with the USRP, but it requires a
>> High
>> impedance load to operate correctly. Since the basic RX daughterboard has
>> a
>> 50 ohm impedance, I have to modify it or add a separate voltage buffer
>> before the input. However, since the basic RX daughter board in the USRP
>> has
>> an op-amp in its first stage, perhaps I could modify this.
>>
>> I've tried removing R3 and R9
>> (http://code.ettus.com/redmine/ettus/documents/4), but this did not seem
>> to
>> load the RF front end sufficiently. Would changing the 348 ohm resistors
>> to
>> a higher value help increase the input impedance into the basic RX
>> daughterboard? If so, how would this affect the output going into the A/D
>> (besides the obvious filtering effects).
> I'd say consult the data-sheet for the AD8132.  But just to clear things 
> up, you're discussing
>the *LF_RX* daughtercard, *NOT* the BASIC_RX, which has no op-amp on 
> it at all, just a
>transformer.
> 
> If your input impedance isn't insanely high, you could use a 
> transformer.  4:1 broadband impedance
>transformers are available fairly cheaply from Mini-circuits, etc.
> 
> 
> 
> 
> -- 
> 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
> 
> 

-- 
View this message in context: 
http://old.nabble.com/Modify-the-Basic-RX-Daughterboard-tp32425579p32426977.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] OSX Audio Problem - AudioUnitRender kAudioUnitErr_CanNotDoInCurrentContext

[Kunal Kandekar]

Hi,

I've been having problems with the audio on OSX as well. Ever since 10.5,
really. I am not sure what the cause is... maybe the code in
audio_osx_source.cc is incompatible with changes in the OSX audio frameworks
that may have occurred under the hood.

However, I currently have a really, really horrible hack that works for some
reason: I run a Java app that does nothing but open up an audio source line,
close it and shut down. After that I have no trouble with any of the gr
audio osx blocks. (I had some Java audio recording code lying around, which
I rewrote to pipe audio into GNU Radio over a socket as a quick
replacement for the gr audio_osx_source block, and I accidentally discovered
that the block started working after I ran the Java app.)

I suspect there is something in CoreAudio (or AudioUnit?) that must be
initialized that audio_osx_source is not doing, but somehow the Java app
does it. I am at a loss to explain how this persists even after the Java app
terminates. The fix persists until you reboot the machine.

In case you want to give it a shot, I've attached the Java source. Compile
it with "javac AudioSource.java" and run it with "java AudioSource localhost
 44100 mic 16 2". It will exit with an error saying it cannot connect to
a socket, but it should have worked its magic anyway. If it works, you
should be able to use audio_osx_source with no problems. It would be very
interesting to see if it works for you.

I've been meaning to dig into the audio_osx_source code and OSX audio
internals to figure out the bug, but haven't had time. There are a few other
problems that need fixing as well (e.g. device_name is not properly used).

Kunal


On Thu, Sep 8, 2011 at 7:48 AM, chris lirakis  wrote:

> This appears to be an issue with OSX 10.6. This can be replicated by
> running the python audio_fft.py example.
>
> Searching the web for the error message I find the apple experts saying
> that this results from the expectation that a sample rate conversion will
> occur. Not being well versed in OSX audio internals I don't know exactly
> what that means. I assume that it means that the audio input and output
> rates are different.
>
> My first question is, has anyone else seen this and has it been fixed and I
> am not aware of it?
>
> So I'm slowly looking through gr_audio_osx/src/audio_osx_source.cc and
> trying to understand what is going on. Now my second question.
>
> I did the install using macports but I also have a copy the source of
> gnuradio-3.3.0 and have compiled it. I have tried putting some debugging
> info in the source and recompiling. I subtituted both the .la and .dyib
> libraries produced. My print statements do not appear.
>
> I am assuming that the python audio interface is a dynamically linked
> object and substitution of my library should work. Is this a false
> assumption? Is there a better way I can debug this?
> Regards,
> Chris
>
> --
> Chris Lirakis
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


AudioSource.java
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Modify the Basic RX Daughterboard

[Marcus D. Leech]

On 09/08/2011 01:08 PM, valentac wrote:

I have my own RF front end i'm using with the USRP, but it requires a High
impedance load to operate correctly. Since the basic RX daughterboard has a
50 ohm impedance, I have to modify it or add a separate voltage buffer
before the input. However, since the basic RX daughter board in the USRP has
an op-amp in its first stage, perhaps I could modify this.

I've tried removing R3 and R9
(http://code.ettus.com/redmine/ettus/documents/4), but this did not seem to
load the RF front end sufficiently. Would changing the 348 ohm resistors to
a higher value help increase the input impedance into the basic RX
daughterboard? If so, how would this affect the output going into the A/D
(besides the obvious filtering effects).
I'd say consult the data-sheet for the AD8132.  But just to clear things 
up, you're discussing
  the *LF_RX* daughtercard, *NOT* the BASIC_RX, which has no op-amp on 
it at all, just a

  transformer.

If your input impedance isn't insanely high, you could use a 
transformer.  4:1 broadband impedance

  transformers are available fairly cheaply from Mini-circuits, etc.




--
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] Modify the Basic RX Daughterboard

[valentac]

I have my own RF front end i'm using with the USRP, but it requires a High
impedance load to operate correctly. Since the basic RX daughterboard has a
50 ohm impedance, I have to modify it or add a separate voltage buffer
before the input. However, since the basic RX daughter board in the USRP has
an op-amp in its first stage, perhaps I could modify this.

I've tried removing R3 and R9
(http://code.ettus.com/redmine/ettus/documents/4), but this did not seem to
load the RF front end sufficiently. Would changing the 348 ohm resistors to
a higher value help increase the input impedance into the basic RX
daughterboard? If so, how would this affect the output going into the A/D
(besides the obvious filtering effects).
-- 
View this message in context: 
http://old.nabble.com/Modify-the-Basic-RX-Daughterboard-tp32425579p32425579.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] Thoughts on stream tag propagation

[Eugene Grayver]

Hello,
I am starting to actively use stream tags and am finding them quite 
useful.  I have one suggestion:

Tags propagated through a block with a known delay (set_history) should be 
adjusted by that delay.  For example, an input to an FIR filter gets 
reflected in the output after a delay.  Since the GR executor has access 
to the delay info, there's no reason it should not use it.

Comments?

On a separate note, I have observed a _rare_ case where tags get lost. The 
scenario involves an output attached to two inputs.  The two inputs 
consume data in different (random) chunk blocks.  It appears that if one 
of the inputs consumes items with the tag well before the second input 
gets to the tagged item, the second input sometimes does not see the tag. 
I have not debugged this enough to confirm that there's no bug in my code.

Eugene

Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OFDM Implementation

[waqasme]

And sorry to mention in the last mail that i will be suing USRP 1 .

waqasme wrote:
> 
> Hi Sumit,
> Thank you so much for your quick response. yah i understand what your
> saying and i am trying to understand this document but it doesnot help
> much . As you mentioned use the same Tranceiver setup and only replace
> OFDM blocks with that. My question is in this basic tranciver diagram the
> used two UHD's source and sink and in the middle they use GMSK Demodulator
> right. but they didnot use any modulator any where in the design. Now i am
> confused what blocks i have to replace with OFDM blocks??? Please try to
> explain in bit detail so i can design it properly . 
> OR you mentioned other option that use benchmark_OFDM.py file . Somebody
> already told me about this benchmark file. but its just C++ code . i am
> quite new to GNU radio and dont know much about the functions how it
> works. 
> Please let me know how to use that benchmark_OFDM.py file in order to make
> the simulation design? do i have to download the file or what? how it
> works ?? let me know if you know about the process how to compile and run
> that code in GNU radio.
> 
> Thanks for ur help and support really appriciate that...
> 
> Regards,
> 
> Waqas.
> 
> 
> sumitstop wrote:
>> 
>> Try to understand these 
>> 
>> http://pwnhome.wordpress.com/2011/04/26/intro-to-gnuradio-and-the-usrp-part-5-simple-transceiver/
>> 
>> here u need to put those ofdm blocks .. thats it also go through some
>> modifications as written in umit,
>> 
>> 
>> http://pwnhome.wordpress.com/2011/04/19/intro-to-gnuradio-and-the-usrp-part-4/
>> 
>> or else work with benchmark_ofdm.py  its very easy.. :)
>> 
>> may i know what daughter boards do you have... 
>> 
>> 
>> 
>> 
>> 
>> waqasme wrote:
>>> 
>>> 
>>> Hello sumit,
>>> Thanks for your help i went through that document that you refered to,
>>> and i tried to implement that OFDM transmitter part. This document only
>>> explain about OFDM flow graph or transmitter. Is there any other
>>> document or information related to OFDM modulator and demodulator
>>> (Transceiver)? i haver to implement OFDM transmission and reception via
>>> USRP. i will really appriciate if you can help me that or someone else
>>> who knows how to implement by using GNU radio companion.
>>> Thanks in advance.
>>> Regards,
>>> Waq.
>>> 
>>> 
>> 
>> 
> 
> 

-- 
View this message in context: 
http://old.nabble.com/OFDM-Implementation-tp32380874p32424735.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] GPS L2C Implementation on E100 FPGA

[Wolfarth, Ryan]

Thanks for the input!  After studying the problem further we've decided that
this project will be too much for one person to complete in the given time
span.  I'll be moving to a post processing software implementation of L2C
and L5 signals instead.

Thanks again,
Ryan

On Thu, Sep 1, 2011 at 1:18 PM, Marcus D. Leech  wrote:

>  On 01/09/2011 1:08 PM, Nick Foster wrote:
>
> On Thu, Sep 1, 2011 at 8:42 AM, Wolfarth, Ryan wrote:
>
>> Hi all,
>>
>> I am generating my masters thesis proposal and I have a few questions
>> about the capabilities of the E100 and the feasibility of my project.  I
>> have read other posts to gather information, but correct me if anything I've
>> determined is wrong.  My goal is to implement an 8 channel GPS L2C receiver
>> on an FPGA.  I am interested in doing this with the E100 since I may be able
>> to take advantage of the ARM processor as well.  Can anyone with experience
>> in this area provide advice?
>>
>> I would like to use the RFX1200 to receive the L2C signal since it has
>> better performance characteristics than the DBSRX.  This would prevent me
>> from first acquiring L1 signals to aid in acquisition, so I propose using
>> preloaded almanac data to estimate SV position/Doppler frequency.  This
>> would reduce the number computations when acquiring L2 CM code.  The end
>> result only has to go as far as to decode the navigation bits: I will not
>> need a position solution.
>>
>> The root of my question is: does the FPGA on the E100 have enough space to
>> handle this project?
>>
>> Does it sound like I'm on the right track?
>>
>
>  Sounds like a very interesting project. I have two suggestions:
>
>  1. The SBX daughterboard has a better noise figure (5dB vs. 8dB typ.),
> with better linearity, and would be better suited for GPS work, especially
> if you aren't using front-end filters. SBX will also receive both the L1 and
> L2 frequencies.
>
> In the specific case of GPS, most active GPS antennas (which is what most
> people use) have GPS-optimized LNAs with very low noise figure,
>   and easily enough gain to swamp the noise figure of whatever receiving
> hardware is downstream, so the noise figure of the receiver
>   board is largely irrelevant in most cases with GPS active antennae.
>
> In my radio astronomy work (where Tsys is absolutely critical), as long as
> the downstream receiver has a noise figure below about 15dB or
>   so, I generally don't care what it is, since I use a tuned vLNA in front
> of it.  It's a very similar situation with GPS.
>
>
>
>
> ___
> 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] fft_filter_ccc adaption for different Bandwidths

[Tom Rondeau]

On Thu, Sep 8, 2011 at 10:31 AM,  wrote:

> Hi,
> thanks at first for the answer so far!
>
> In my code are the following lines:
>
> chan_coeffs = gr.firdes.low_pass(1.0,  # gain
>  sw_decim * self._samples_per_symbol, # sampling rate
> 1.0,  # midpoint of trans.
> band
> 0.5,  # width of trans.
> band
> gr.firdes.WIN_HANN)   # filter type
> self.channel_filter = gr.fft_filter_ccc(sw_decim, chan_coeffs)
>
> Now I can see that the channel coefficients fed to the fft_filter_ccc are
> computed at first using the gr.firdes.low_pass() function (Hence, it's a low
> pass filter :))
>
> Anyway, there's the fourth parameter given to gr.firdes.low_pass function,
> which is supposed to represent the width of our transmission band. I guess
> this is the parameter I need to change to have the low pass filter filtering
> the correct spectrum containing (only) my signal. But a value of 0.5 looks
> to me a little strange? Is there a translation to Hz or a realation to the
> center freqeuncy (here 1.0, also strange)?
>
> I guess I'm interpreting something wrong here... Can anyone help?
>
> best,
> B


If you put in the real sample rate (in samples/second) as the second
parameter, everything else will be in Hz. The filter only really cares about
normalized values, so the sampling rate is essentially a coefficient to
translate from there to what you want; in this case, Hz.

This filter should be specified at the sample rate that you see into the
filter; that is, before the sw_decim decimation is applied.

Also, the filter bandwidth is determined by the third parameter; so that's
really the filter width. The fourth parameter is the width of the transition
from the end of the pass band to the start of the stop band, so you might
want to play with both. The bandwidth gives you the passband and the
transition band will determine how many taps your filter has.

Tom




> Quoting "Tom Rondeau" :
>
>  On Thu, Sep 8, 2011 at 9:59 AM,  wrote:
>>
>>  Hi everyone...
>>>
>>> I'm currently working on/with the UCLA ZigBee Physical Layer
>>> implementation
>>> on GnuRadio. Now my sender and receiver will change their bandwidth all
>>> the
>>> time, hence I need to adjust the BandPassFilter at reception accordingly.
>>>
>>> Now I have seen that the signal goes through the C++ Signal Processing
>>> Block "fft_filter_ccc" which, as I assume, filters the signal as a
>>> Bandpass
>>> filter or low pass, not sure.
>>>
>>> Anyway, I need to adjust the parameters/coefficients of "fft_filter_ccc"
>>> and was wondering if anyone of you knows which parameter of this signal
>>> processing block responsible is for the width of the filter?
>>>
>>> best regards, and thank you all for answering...
>>> B
>>>
>>>
>> Hi B,
>> The fft_filter_ccc can be a bandpass, low pass, high pass, etc... it takes
>> as its arguments the decimation factor and the set of taps as a list of
>> complex numbers. Whatever taps you put into it, it will filter based on
>> that.
>>
>> It has a method called set_taps that also takes a list (or std::vector in
>> C++) of complex numbers that you can use to change the filter structure.
>> But
>> whether or not this is really useful to you depends on how fast you need
>> things to change. Using the set_taps function from Python gives you
>> no guarantee about when the taps will change compared to when the samples
>> are flowing through your flowgraph.
>>
>> What sort of information determines the filter structure that you need? If
>> there is something before the filter that knows that a new set of taps is
>> required starting at a particular sample, then the best bet would be to
>> use
>> the stream tagging interface. You could set the tag with the current
>> sample
>> number for when the new taps are required and also pass the set of taps in
>> the tag itself. You would then have to rewrite the gr_fft_filter_ccc to
>> look
>> at the tag stream, pick out the tags when they arrive, and use the taps
>> passed inside the tag to set up your new filter (keep in mind that if you
>> change the number of taps in your filter, the history is going to change,
>> too).
>>
>> Tom
>>
>>
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] fft_filter_ccc adaption for different Bandwidths

[bjoernm]

Hi,
thanks at first for the answer so far!

In my code are the following lines:

chan_coeffs = gr.firdes.low_pass(1.0,  # gain
  sw_decim * self._samples_per_symbol, # sampling rate
 1.0,  # midpoint of  
trans. band

 0.5,  # width of trans. band
 gr.firdes.WIN_HANN)   # filter type
self.channel_filter = gr.fft_filter_ccc(sw_decim, chan_coeffs)

Now I can see that the channel coefficients fed to the fft_filter_ccc  
are computed at first using the gr.firdes.low_pass() function (Hence,  
it's a low pass filter :))


Anyway, there's the fourth parameter given to gr.firdes.low_pass  
function, which is supposed to represent the width of our transmission  
band. I guess this is the parameter I need to change to have the low  
pass filter filtering the correct spectrum containing (only) my  
signal. But a value of 0.5 looks to me a little strange? Is there a  
translation to Hz or a realation to the center freqeuncy (here 1.0,  
also strange)?


I guess I'm interpreting something wrong here... Can anyone help?

best,
B

Quoting "Tom Rondeau" :


On Thu, Sep 8, 2011 at 9:59 AM,  wrote:


Hi everyone...

I'm currently working on/with the UCLA ZigBee Physical Layer implementation
on GnuRadio. Now my sender and receiver will change their bandwidth all the
time, hence I need to adjust the BandPassFilter at reception accordingly.

Now I have seen that the signal goes through the C++ Signal Processing
Block "fft_filter_ccc" which, as I assume, filters the signal as a Bandpass
filter or low pass, not sure.

Anyway, I need to adjust the parameters/coefficients of "fft_filter_ccc"
and was wondering if anyone of you knows which parameter of this signal
processing block responsible is for the width of the filter?

best regards, and thank you all for answering...
B



Hi B,
The fft_filter_ccc can be a bandpass, low pass, high pass, etc... it takes
as its arguments the decimation factor and the set of taps as a list of
complex numbers. Whatever taps you put into it, it will filter based on
that.

It has a method called set_taps that also takes a list (or std::vector in
C++) of complex numbers that you can use to change the filter structure. But
whether or not this is really useful to you depends on how fast you need
things to change. Using the set_taps function from Python gives you
no guarantee about when the taps will change compared to when the samples
are flowing through your flowgraph.

What sort of information determines the filter structure that you need? If
there is something before the filter that knows that a new set of taps is
required starting at a particular sample, then the best bet would be to use
the stream tagging interface. You could set the tag with the current sample
number for when the new taps are required and also pass the set of taps in
the tag itself. You would then have to rewrite the gr_fft_filter_ccc to look
at the tag stream, pick out the tags when they arrive, and use the taps
passed inside the tag to set up your new filter (keep in mind that if you
change the number of taps in your filter, the history is going to change,
too).

Tom






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

Re: [Discuss-gnuradio] SNR(Signal to Noise Ratio) Value in DQPSK Implementation

[waqasme]

Hi Tom,

Thanks for your reply. yah i did use noise block and i am changing the
amplitude in the noise block but it does not make any difference in the
output. You said calculate the SNR value i have to check signal power and
determine the noise power. i dont know how to calculate those values. iam
simply changing the amplitude in the noise block and try to see if it makes
any difference. And the link you have provided below is the C++ code that
does not explain anywhere how to calculate or change the SNR value. Can you
please explain in detail how it works. 
i really appriciate your help and support.

Thanks and Regards,

Waqas

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



-- 
View this message in context: 
http://old.nabble.com/SNR%28Signal-to-Noise-Ratio%29-Value-in-DQPSK-Implementation-tp32381155p32423923.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] GRC squelch block with separate control signal?

[Tom Rondeau]

On Wed, Sep 7, 2011 at 7:58 AM, John Ackermann N8UR  wrote:

>
>
> Tom Rondeau said the following on 09/06/2011 11:28 AM:
>
>> On Tue, Sep 6, 2011 at 10:22 AM, John Ackermann N8UR > > wrote:
>>
>>I want to implement the equivalent of a carrier-operated relay -- a
>>squelch block that provides an "on" signal at a threshold input
>>signal level, which then passes or blocks data at some point further
>>downstream rather than right at the point where the sensing is
>>happening.
>>
>>Are there GRC blocks that will allow this?
>>
>>Thanks,
>>
>>John
>>
>>
>>
>> John,
>> Yes, look in "Level Controls," there is a "Simple Squelch," "Standard
>> Squelch," and "Power Squelch" as well as a simple "Threshold." You'll
>> have to look closer into this blocks to find out how they work.
>>
>> Tom
>>
>
> Hi Tom --
>
> The challenge is that the three squelch blocks all sense and switch the
> data stream at the same point -- the input signal is passed or not based on
> its level.  What I need instead is to sense the stream at one point, and use
> that information to switch a different data stream.
>
> I could picture two blocks -- one that sets (and updates) a boolean
> variable based on the current signal level, and another that switches a
> separate sample stream based on whether that variable is true or false.
>  Does GRC support message passing between blocks in that fashion?
>
> The practical example is an FM repeater where the transmitted signal is
> turned on only when the received signal level exceeds a threshold.
>
> Thanks,
>
> John
>

You can use a message for this, or you can use the stream tagging interface
where a message is tagged specifically to a sample number. It's a way of
passing synchronous messages where the message passing interface doesn't.

The problem is, you really have to work inside of the C++ code to get to the
stream tags, so you won't be able to work in GRC for it.

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

Re: [Discuss-gnuradio] fft_filter_ccc adaption for different Bandwidths

[Tom Rondeau]

On Thu, Sep 8, 2011 at 9:59 AM,  wrote:

> Hi everyone...
>
> I'm currently working on/with the UCLA ZigBee Physical Layer implementation
> on GnuRadio. Now my sender and receiver will change their bandwidth all the
> time, hence I need to adjust the BandPassFilter at reception accordingly.
>
> Now I have seen that the signal goes through the C++ Signal Processing
> Block "fft_filter_ccc" which, as I assume, filters the signal as a Bandpass
> filter or low pass, not sure.
>
> Anyway, I need to adjust the parameters/coefficients of "fft_filter_ccc"
> and was wondering if anyone of you knows which parameter of this signal
> processing block responsible is for the width of the filter?
>
> best regards, and thank you all for answering...
> B
>

Hi B,
The fft_filter_ccc can be a bandpass, low pass, high pass, etc... it takes
as its arguments the decimation factor and the set of taps as a list of
complex numbers. Whatever taps you put into it, it will filter based on
that.

It has a method called set_taps that also takes a list (or std::vector in
C++) of complex numbers that you can use to change the filter structure. But
whether or not this is really useful to you depends on how fast you need
things to change. Using the set_taps function from Python gives you
no guarantee about when the taps will change compared to when the samples
are flowing through your flowgraph.

What sort of information determines the filter structure that you need? If
there is something before the filter that knows that a new set of taps is
required starting at a particular sample, then the best bet would be to use
the stream tagging interface. You could set the tag with the current sample
number for when the new taps are required and also pass the set of taps in
the tag itself. You would then have to rewrite the gr_fft_filter_ccc to look
at the tag stream, pick out the tags when they arrive, and use the taps
passed inside the tag to set up your new filter (keep in mind that if you
change the number of taps in your filter, the history is going to change,
too).

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

Re: [Discuss-gnuradio] OFDM Implementation

[waqasme]

Hi Sumit,
Thank you so much for your quick response. yah i understand what your saying
and i am trying to understand this document but it doesnot help much . As
you mentioned use the same Tranceiver setup and only replace OFDM blocks
with that. My question is in this basic tranciver diagram the used two UHD's
source and sink and in the middle they use GMSK Demodulator right. but they
didnot use any modulator any where in the design. Now i am confused what
blocks i have to replace with OFDM blocks??? Please try to explain in bit
detail so i can design it properly . 
OR you mentioned other option that use benchmark_OFDM.py file . Somebody
already told me about this benchmark file. but its just C++ code . i am
quite new to GNU radio and dont know much about the functions how it works. 
Please let me know how to use that benchmark_OFDM.py file in order to make
the simulation design? do i have to download the file or what? how it works
?? let me know if you know about the process how to compile and run that
code in GNU radio.

Thanks for ur help and support really appriciate that...

Regards,

Waqas.


sumitstop wrote:
> 
> Try to understand these 
> 
> http://pwnhome.wordpress.com/2011/04/26/intro-to-gnuradio-and-the-usrp-part-5-simple-transceiver/
> 
> here u need to put those ofdm blocks .. thats it also go through some
> modifications as written in umit,
> 
> 
> http://pwnhome.wordpress.com/2011/04/19/intro-to-gnuradio-and-the-usrp-part-4/
> 
> or else work with benchmark_ofdm.py  its very easy.. :)
> 
> may i know what daughter boards do you have... 
> 
> 
> 
> 
> 
> waqasme wrote:
>> 
>> 
>> Hello sumit,
>> Thanks for your help i went through that document that you refered to,
>> and i tried to implement that OFDM transmitter part. This document only
>> explain about OFDM flow graph or transmitter. Is there any other document
>> or information related to OFDM modulator and demodulator (Transceiver)? i
>> haver to implement OFDM transmission and reception via USRP. i will
>> really appriciate if you can help me that or someone else who knows how
>> to implement by using GNU radio companion.
>> Thanks in advance.
>> Regards,
>> Waq.
>> 
>> 
> 
> 

-- 
View this message in context: 
http://old.nabble.com/OFDM-Implementation-tp32380874p32423644.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] fft_filter_ccc adaption for different Bandwidths

[bjoernm]

Hi everyone...

I'm currently working on/with the UCLA ZigBee Physical Layer  
implementation on GnuRadio. Now my sender and receiver will change  
their bandwidth all the time, hence I need to adjust the  
BandPassFilter at reception accordingly.


Now I have seen that the signal goes through the C++ Signal Processing  
Block "fft_filter_ccc" which, as I assume, filters the signal as a  
Bandpass filter or low pass, not sure.


Anyway, I need to adjust the parameters/coefficients of  
"fft_filter_ccc" and was wondering if anyone of you knows which  
parameter of this signal processing block responsible is for the width  
of the filter?


best regards, and thank you all for answering...
B



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

[Discuss-gnuradio] OSX Audio Problem - AudioUnitRender kAudioUnitErr_CanNotDoInCurrentContext

[chris lirakis]

This appears to be an issue with OSX 10.6. This can be replicated by running
the python audio_fft.py example.

Searching the web for the error message I find the apple experts saying that
this results from the expectation that a sample rate conversion will occur.
Not being well versed in OSX audio internals I don't know exactly what that
means. I assume that it means that the audio input and output rates are
different.

My first question is, has anyone else seen this and has it been fixed and I
am not aware of it?

So I'm slowly looking through gr_audio_osx/src/audio_osx_source.cc and
trying to understand what is going on. Now my second question.

I did the install using macports but I also have a copy the source of
gnuradio-3.3.0 and have compiled it. I have tried putting some debugging
info in the source and recompiling. I subtituted both the .la and .dyib
libraries produced. My print statements do not appear.

I am assuming that the python audio interface is a dynamically linked object
and substitution of my library should work. Is this a false assumption? Is
there a better way I can debug this?
Regards,
Chris

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

Re: [Discuss-gnuradio] USRP1 + DBSRX2 board is not recognize from GNURadio

[Marcus D. Leech]

On 08/09/11 05:27 AM, Miguel Angel Salinas Gancedo wrote:
> Hi,
>
> We just bought the USRP1 device and the daughterboard DBSRX2 to Ettus
> company. The software installation was done from Ubuntu 10.04 and
> Ubuntu 11.04 and the WARNING result was the same in both cases. I
> explain a little the process and tests:
>
> We have installed all the dependencies to install UHD driver
> (003,002,003) in the two versions of Ubuntu and Gnuradio (Gnuradio
> 3.2.2 on Ubuntu 10.04 and Gnuradio 3.3.0 on Ubuntu 11.04). The tests
> we have done in the two releases of Ubuntu are:
>
> 1) Execute the UHD: command *uhd_find_devices* with the result:
>
> Linux, GNU C + + version 4.5.2; Boost_104200; UHD_003.002.003-release
>
> --
> - UHD Device 0
> --
> Device Address:
> type: usrp1
> name:
> serial: 4e274809
>
>  2) Execute the UHD command: *uhd_usrp_probe* with the result:
>
> Linux, GNU C + + version 4.5.2; Boost_104200; UHD_003.002.003-release
>
> - Opening a device USRP1 ...
> - Loading FPGA image: / usr/share/uhd/images/usrp1_fpga.rbf ... done
> - Using FPGA clock rate of 64.00MHz ...
>   _
>  /
> | Device: Device USRP1
> | _
> | /
> | | Mboard: USRP1 (Classic)
> | | Serial: 4e274809
> | |
> | | Time sources: none
> | | Clock sources: internal
> | | Sensors:
> | | _
> | | /
> | | | RX DSP: 0
> | | | Freq range: -32,000 to 32,000 Mhz
> | | _
> | | /
> | | | RX DSP: 1
> | | | Freq range: -32,000 to 32,000 Mhz
> | | _
> | | /
> | | | RX Dboard: A
> | | | ID: DBSRX2 (0x0012)
> | | | _
> | | | /
> | | | | RX Subdev: 0
> | | | | Name: DBSRX2 (0x0012)
> | | | | Antennas: J3
> | | | | Sensors: lo_locked
> | | | | Freq range: 800,000 to 2400,000 Mhz
> | | | | GC1 Gain range: 0.0 to 73.0 step 0.1 dB
> | | | | BBG Gain range: 0.0 to 15.0 step 1.0 dB
> | | | | Connection Type: QI
> | | | | LO offset Uses: No
> | | | _
> | | | /
> | | | | RX Codec: A
> | | | | Name: ad9522
> | | | | PGA Gain Range: 0.0 to 20.0 step 1.0 dB
> | | _
> | | /
> | | | RX Dboard: B
> | | | _
> | | | /
> | | | | RX Subdev: 0
> | | | | Name: Unknown - Unknown (0x)
> | | | | Antennas:
> | | | | Sensors:
> | | | | Freq range:  to  Mhz
> | | | | Gain Elements: None
> | | | | Connection Type: IQ
> | | | | LO offset Uses: No
> | | | _
> | | | /
> | | | | RX Codec: B
> | | | | Name: ad9522
> | | | | PGA Gain Range: 0.0 to 20.0 step 1.0 dB
> | | _
> | | /
> | | | TX DSP: 0
> | | | Freq range: -44,000 to 44,000 Mhz
> | | _
> | | /
> | | | TX DSP: 1
> | | | Freq range: -44,000 to 44,000 Mhz
> | | _
> | | /
> | | | TX Dboard: A
> | | | _
> | | | /
> | | | | TX Subdev: 0
> | | | | Name: Unknown - Unknown (0x)
> | | | | Antennas:
> | | | | Sensors:
> | | | | Freq range:  to  Mhz
> | | | | Gain Elements: None
> | | | | Connection Type: IQ
> | | | | LO offset Uses: No
> | | | _
> | | | /
> | | | | TX Codec: A
> | | | | Name: ad9522
> | | | | PGA Gain Range: -20.0 to 0.0 step 0.1 dB
> | | _
> | | /
> | | | TX Dboard: B
> | | | _
> | | | /
> | | | | TX Subdev: 0
> | | | | Name: Unknown - Unknown (0x)
> | | | | Antennas:
> | | | | Sensors:
> | | | | Freq range:  to  Mhz
> | | | | Gain Elements: None
> | | | | Connection Type: IQ
> | | | | LO offset Uses: No
> | | | _
> | | | /
> | | | | TX Codec: B
> | | | | Name: ad9522
> | | | | PGA Gain Range: -20.0 to 0.0 step 0.1 dB
>
> It seems all right as because it detects the card DBSRX2 on RXA
> motherboard , isn't it?.
>
> 3) But when execute any Gnuradio exmple python script like :
> *usrp_benchmark_usb.py* the warning are:
>
> Testing 2MB/sec...
> *Warning: Treating daughterboard with invalid EEPROM contents as if it
> were a "Basic Rx."
> Warning: This is almost certainly wrong...  Use appropriate
> burn-*-eeprom utility.*
>
> uUuUuUuUuUuUuUusb_throughput = 2M
> ntotal= 100
> nright= 998049
> runlength = 998049
> delta = 1951
> OK
> Testing 4MB/sec...
> *Warning: Treating daughterboard with invalid EEPROM contents as if it
> were a "Basic Rx."
> Wa

[Discuss-gnuradio] USRP1 + DBSRX2 board is not recognize from GNURadio

[Miguel Angel Salinas Gancedo]

Hi,

We just bought the USRP1 device and the daughterboard DBSRX2 to Ettus
company. The software installation was done from Ubuntu 10.04 and Ubuntu
11.04 and the WARNING result was the same in both cases. I explain a little
the process and tests:

We have installed all the dependencies to install UHD driver (003,002,003)
in the two versions of Ubuntu and Gnuradio (Gnuradio 3.2.2 on Ubuntu 10.04
and Gnuradio 3.3.0 on Ubuntu 11.04). The tests we have done in the two
releases of Ubuntu are:

1) Execute the UHD: command *uhd_find_devices* with the result:

Linux, GNU C + + version 4.5.2; Boost_104200; UHD_003.002.003-release

--
- UHD Device 0
--
Device Address:
type: usrp1
name:
serial: 4e274809

 2) Execute the UHD command: *uhd_usrp_probe* with the result:

Linux, GNU C + + version 4.5.2; Boost_104200; UHD_003.002.003-release

- Opening a device USRP1 ...
- Loading FPGA image: / usr/share/uhd/images/usrp1_fpga.rbf ... done
- Using FPGA clock rate of 64.00MHz ...
  _
 /
| Device: Device USRP1
| _
| /
| | Mboard: USRP1 (Classic)
| | Serial: 4e274809
| |
| | Time sources: none
| | Clock sources: internal
| | Sensors:
| | _
| | /
| | | RX DSP: 0
| | | Freq range: -32,000 to 32,000 Mhz
| | _
| | /
| | | RX DSP: 1
| | | Freq range: -32,000 to 32,000 Mhz
| | _
| | /
| | | RX Dboard: A
| | | ID: DBSRX2 (0x0012)
| | | _
| | | /
| | | | RX Subdev: 0
| | | | Name: DBSRX2 (0x0012)
| | | | Antennas: J3
| | | | Sensors: lo_locked
| | | | Freq range: 800,000 to 2400,000 Mhz
| | | | GC1 Gain range: 0.0 to 73.0 step 0.1 dB
| | | | BBG Gain range: 0.0 to 15.0 step 1.0 dB
| | | | Connection Type: QI
| | | | LO offset Uses: No
| | | _
| | | /
| | | | RX Codec: A
| | | | Name: ad9522
| | | | PGA Gain Range: 0.0 to 20.0 step 1.0 dB
| | _
| | /
| | | RX Dboard: B
| | | _
| | | /
| | | | RX Subdev: 0
| | | | Name: Unknown - Unknown (0x)
| | | | Antennas:
| | | | Sensors:
| | | | Freq range:  to  Mhz
| | | | Gain Elements: None
| | | | Connection Type: IQ
| | | | LO offset Uses: No
| | | _
| | | /
| | | | RX Codec: B
| | | | Name: ad9522
| | | | PGA Gain Range: 0.0 to 20.0 step 1.0 dB
| | _
| | /
| | | TX DSP: 0
| | | Freq range: -44,000 to 44,000 Mhz
| | _
| | /
| | | TX DSP: 1
| | | Freq range: -44,000 to 44,000 Mhz
| | _
| | /
| | | TX Dboard: A
| | | _
| | | /
| | | | TX Subdev: 0
| | | | Name: Unknown - Unknown (0x)
| | | | Antennas:
| | | | Sensors:
| | | | Freq range:  to  Mhz
| | | | Gain Elements: None
| | | | Connection Type: IQ
| | | | LO offset Uses: No
| | | _
| | | /
| | | | TX Codec: A
| | | | Name: ad9522
| | | | PGA Gain Range: -20.0 to 0.0 step 0.1 dB
| | _
| | /
| | | TX Dboard: B
| | | _
| | | /
| | | | TX Subdev: 0
| | | | Name: Unknown - Unknown (0x)
| | | | Antennas:
| | | | Sensors:
| | | | Freq range:  to  Mhz
| | | | Gain Elements: None
| | | | Connection Type: IQ
| | | | LO offset Uses: No
| | | _
| | | /
| | | | TX Codec: B
| | | | Name: ad9522
| | | | PGA Gain Range: -20.0 to 0.0 step 0.1 dB

It seems all right as because it detects the card DBSRX2 on RXA motherboard
, isn't it?.

3) But when execute any Gnuradio exmple python script like : *
usrp_benchmark_usb.py* the warning are:

Testing 2MB/sec...
*Warning: Treating daughterboard with invalid EEPROM contents as if it were
a "Basic Rx."
Warning: This is almost certainly wrong...  Use appropriate burn-*-eeprom
utility.*

uUuUuUuUuUuUuUusb_throughput = 2M
ntotal= 100
nright= 998049
runlength = 998049
delta = 1951
OK
Testing 4MB/sec...
*Warning: Treating daughterboard with invalid EEPROM contents as if it were
a "Basic Rx."
Warning: This is almost certainly wrong...  Use appropriate burn-*-eeprom
utility.*

uUuUuU


4) Also if execute the airprobe command: *dbusrp -f 93700*  the warnings
is the same

 |
 |.
 |..`` ``..
 |.``   `.
   

Re: [Discuss-gnuradio] How to reconfigure automatically the channel used to received data in USRPs

[Lebowski80]

Ok, thank you for your advice, I will try with interprocess communication.

Regards


Nick Foster-4 wrote:
> 
> Short answer: You cannot open a new USRP instance to reconfigure an
> already-running USRP instance. You must reconfigure the existing instance.
> 
> The best advice I can give is that only one flowgraph can be operational
> per
> USRP device. In your setup, USRP#1 will run a single flowgraph with a
> source
> and/or sink, USRP#2 will run a single flowgraph with a source and/or sink,
> and USRP#3 will run a single flowgraph with a source and/or sink. If you
> wish to change the parameters of USRP#2 while it is running, rather than
> try
> to open a new USRP device in your benchmark_rxr.py flowgraph, use any of
> the
> standard interprocess communication methods to talk to your
> already-running
> USRP#2 script and reconfigure it as necessary.
> 
> --n
> 
> On Wed, Sep 7, 2011 at 9:31 AM, Lebowski80 
> wrote:
> 
>>
>> Hello Nick,
>>
>> What do you mean? Actually I'm running RX and TX in two different
>> flowgraphs
>> on USRP1, the first one in usrp_spectrum_sense.py to look for a free
>> channel
>> (so the RX). In this script I also run benchmark_tx.py by the command p =
>> Popen('python benchmark_tx.py', shell =  True), then my second flowgrapgh
>> (the TX).
>>
>> My problem is that on USRP2 I want to reconfigure the RX channel by
>> python
>> (RX channel = 2484 MHz in the script benchmark_rx.py and RX channel =
>> channel received by USRP1 in the script benchamrk_rxr.py run by
>> benchmark_rx.py with the command p = Popen('python benchmark_rxr.py',
>> shell
>> =  True)).
>>
>> So I'm wondering if there exists the possibility to reconfigure the
>> parameters of a script in the same USRP (i.e. RX frequency channel) while
>> it
>> is running and if this is not possible what do people mean with "USRP
>> reconfigurability?"
>>
>> I really need an answer to understand the potentiality of my hardware,
>> thanks a lot!
>>
>> Regards
>>
>>
>>
>> Nick Foster-4 wrote:
>> >
>> > On Wed, Sep 7, 2011 at 3:27 AM, Lebowski80 
>> > wrote:
>> >
>> >>
>> >> Hello everyone,
>> >>
>> >> Before to explain my problem I give some technical information about
>> my
>> >> hardaware. I'm using USRPs v1 and the boards integrated are XCVR2450
>> >> Transceivers.
>> >>
>> >> I'm using the script usrp_spectrum_sense.py in a USRP (called USRP1)
>> to
>> >> make
>> >> sensing in the ISM band, after a few seconds it sends to another USRP
>> >> (Called USRP2) a free sensed channel on the central frequency 2484
>> MHz.
>> >> USRP2 listens to the channel 2484 MHz through the script
>> benchmark_rx.py
>> >> and
>> >> it can properly receive the free ISM channel sent by USRP1. Then, I
>> want
>> >> to
>> >> use the USRP2 to receive data from another USRP (called USRP3) that
>> uses
>> >> the
>> >> script benchmark_tx.py.
>> >>
>> >> In the script benchmark_rx.py (used by USRP2) that listens to channel
>> >> 2484
>> >> MHz I want to run another script that I called benchmark_rxr.py that
>> >> waits
>> >> for data sent by USRP3 to be received in the free ISM channel sent by
>> >> USRP1.
>> >>
>> >> Relevant line of the code in the script benchmark_rx.py is attached
>> >> below:
>> >>
>> >> p = Popen('python benchmark_rxr.py', shell =  True)
>> >>
>> >> While this is the error that I get:
>> >>
>> >> usrp_open_interface:usb_claim_interface: failed interface 2
>> >> could not claim interface 2: Device or resource busy
>> >> usrp_basic_rx: can't open rx interface
>> >> Traceback (most recent call last):
>> >>  File "benchmark_rxr.py", line 153, in 
>> >>main()
>> >>  File "benchmark_rxr.py", line 138, in main
>> >>tb = my_top_block(demods[options.modulation],
>> >> mods[options.modulation],
>> >> rx_callback, options)
>> >>  File "benchmark_rxr.py", line 46, in __init__
>> >>self.rxpath = usrp_receive_path.usrp_receive_path(demodulator,
>> >> rx_callback, options)
>> >>  File
>> "/opt/gnuradio/gnuradio-examples/python/usrp/usrp_receive_path.py",
>> >> line 65, in __init__
>> >>self._setup_usrp_source(options)
>> >>  File
>> "/opt/gnuradio/gnuradio-examples/python/usrp/usrp_receive_path.py",
>> >> line 78, in _setup_usrp_source
>> >>self.u = usrp_options.create_usrp_source(options)
>> >>  File
>> "/usr/local/lib/python2.6/dist-packages/gnuradio/usrp_options.py",
>> >> line 88, in create_usrp_source
>> >>gain=options.rx_gain,
>> >>  File
>> >>
>> >>
>> "/usr/local/lib/python2.6/dist-packages/gnuradio/blks2impl/generic_usrp.py",
>> >> line 138, in __init__
>> >>_generic_usrp_base.__init__(self, **kwargs)
>> >>  File
>> >>
>> >>
>> "/usr/local/lib/python2.6/dist-packages/gnuradio/blks2impl/generic_usrp.py",
>> >> line 63, in __init__
>> >>except: raise Exception, 'Failed to automatically setup a usrp
>> >> device.'
>> >> Exception: Failed to automatically setup a usrp device.
>> >>
>> >> I read different post with this problem such as "Full duplex and half
>> >> duplex
>> >> does not work" and "help: cannot sen