[Discuss-gnuradio] Error in building minimal GNU radio

Hi everyone,      I am trying to build a minimal GNU radio system and today  i am able to successfully execute the configure command. But now I am facing another error when I typed the $make command. I checked out the gnuradio archives,but couldn't find much help :(.   when I type $ make I get the following errors: make [3] : error 1 make [3]: leaving directory cygdrive/f/gnuradio-3.2.2/gnuradio-3.2.2/gruel/src/lib Can anybody please help me how to remove this error? Thank you for all your help. Regards, Reena

Re: [Discuss-gnuradio] Happy Holi

Wishing you all a very very happy and colorful Holi
------Original Message------
From: Jason
Sender: discuss-gnuradio-bounces+smzerocool=gmail.com@gnu.org
To: Marcus D. Leech
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] SBCs with GiGE
Sent: Mar 1, 2010 6:34 AM

Marcus D. Leech wrote:
> Are there any SBCs (Single Board 'Pooters) out there that are:
>
> o compact
> o cheap-ish
> o Have 1 GiGE on them "for real"?
>

SheevaPlug [1] ?

- Marvell Kirkwood 1.2GHz Processor
- USB 2.0 host
- 1x GigE
- 512MB RAM
- 512MB Flash
- < 5W
- $99US

hth,

Jason.

[1] http://en.wikipedia.org/wiki/SheevaPlug


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


Sent on my BlackBerry® from Vodafone

Re: [Discuss-gnuradio] SBCs with GiGE

On 02/28/2010 08:04 PM, Jason wrote:
> Marcus D. Leech wrote:
>> Are there any SBCs (Single Board 'Pooters) out there that are:
>>
>> o compact
>> o cheap-ish
>> o Have 1 GiGE on them "for real"?
>>
>
> SheevaPlug [1] ?
>
> - Marvell Kirkwood 1.2GHz Processor
> - USB 2.0 host
> - 1x GigE
> - 512MB RAM
> - 512MB Flash
> - < 5W
> - $99US

No floating point though. I really should see if I can attach a USRP to
one just for fun.

Philip

>
> hth,
>
> Jason.
>
> [1] http://en.wikipedia.org/wiki/SheevaPlug
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>

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

[Discuss-gnuradio] GNU Radio for TE320 Series Xilinx

2010/1/26 Johnathan Corgan <jcorgan@corganenterprises.com>

On Tue, Jan 19, 2010 at 17:16, Makmur Hidayat <makmurh@gmail.com> wrote:

> I want to use GNU Radio to process signal with TE320 Series Xilinx
> Spartan-3A DSP Industrial Micromodule.

This wouldn't be too difficult once you learn the GNU Radio C++ API.

 

Johnathan

 

Dear Johnathan,

 

Thank you for your information.

I inform you that now. I have already installed GNU Radio on ubuntu linux (Jaunthy) and I can run example successfully. I want to process signal from the DSP connected to a computer

 

Because I am new in C++, therefore to learn GNU Radio C++ API, therefore do I have to learn C++ first? What is the best way to learn GNU Radio C++ API?

 

Thank you very much for your suggestion.

 

Regards

Makmur

 

Re: [Discuss-gnuradio] SBCs with GiGE

Marcus D. Leech wrote:
> Are there any SBCs (Single Board 'Pooters) out there that are:
>
> o compact
> o cheap-ish
> o Have 1 GiGE on them "for real"?
>

SheevaPlug [1] ?

- Marvell Kirkwood 1.2GHz Processor
- USB 2.0 host
- 1x GigE
- 512MB RAM
- 512MB Flash
- < 5W
- $99US

hth,

Jason.

[1] http://en.wikipedia.org/wiki/SheevaPlug

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

[Discuss-gnuradio] SBCs with GiGE

Are there any SBCs (Single Board 'Pooters) out there that are:

o compact
o cheap-ish
o Have 1 GiGE on them "for real"?

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

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

[Discuss-gnuradio] Matt Ettus in Zurich on March 2nd

I'll be in Zurich on March 1st and 2nd for the NI Days event. If anyone
is in the area and would like to get together to talk software radio let
me know. After that, it's off to Karlsruhe for WSR 2010 where I'm
looking forward to meeting a bunch of people from this list.

Matt

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

Re: [Discuss-gnuradio] USRP2 rx copy handlers

On Sun, Feb 28, 2010 at 02:57:45PM +0000, Tim Pearce wrote:
> Hi,
>
> I've been having a look at usrp2/host/lib/copiers.cc and the schematics to
> try and work out if the units mean anything.
>
> As far as I can tell the LTC2284 ADC is set up to use the +-1V input range
> and output 14bits as a twos complement.
>
> From the datasheet/the maths I think the ADC is thus giving possible outputs
> of -8192 to 8191 (i.e ~ +- 2^13) where -8192 represents -1V and 8191
> represents 1V-0.000122V.
>
> Where I'm confused is with copy_u2_16sc_to_host_32fc the integers are scaled
> to produce floats where -32768 and 32768 (i.e using the full 16bits of the
> storage variable) are mapped to -1.0 and 1.0 respectively. Is there a reason
> for this? I haven't tried to look at what the FPGA is doing with this data
> yet..

The output from the ADC is run through a digital downconverter in the
FPGA. In general, the output of that process is between -32768 to
32767.

If you're looking for "volts", you'll need to calibrate the entire
signal path. That will depend on the daughterboard, it's gain,
temperature, etc.

A bit of searching of the list archives will turn up quite a bit of
discussion on this topic.

Eric

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

[Discuss-gnuradio] USRP2 rx copy handlers

Hi,

I've been having a look at usrp2/host/lib/copiers.cc and the schematics to try and work out if the units mean anything.

As far as I can tell the LTC2284 ADC is set up to use the +-1V input range and output 14bits as a twos complement.

From the datasheet/the maths I think the ADC is thus giving possible outputs of -8192 to 8191 (i.e ~ +- 2^13) where -8192 represents -1V and 8191 represents 1V-0.000122V.

Where I'm confused is with copy_u2_16sc_to_host_32fc the integers are scaled to produce floats where -32768 and 32768 (i.e using the full 16bits of the storage variable) are mapped to -1.0 and 1.0 respectively. Is there a reason for this? I haven't tried to look at what the FPGA is doing with this data yet..

Can I change this to -8192 and 8192 to map the real/imaginary magnitudes to voltages. I think by doing this I should be able to use usrp2_fft.py -S -f xx and see the same sort of values as I see on a scope?

Thanks,

Tim

[Discuss-gnuradio] garbage signal when TX is enabled

Hi all,

I am using two RFX2400 daughterboards on USRP1 to implement TX/RX on each daughterboard.
When I do ZigBee packet transmission, I found that there are always some trailing garbage signals after each packet. The trailing garbage has strong fixed I and Q values (slightly changing) which lasts about 80 microseconds. The cause was TX/RX switch time. When I do set_enable so that TX is always enabled, I see those garbage symbols throughput the gap between packets.

So, the question is whether there is a way to avoid this. Because I am doing a packetized transmissions, it is a pain to feed all zeros between packets.

Thanks,
Jung Il

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

Re: [Discuss-gnuradio] block that does simple tone detection

On Fri, Feb 26, 2010 at 14:49, Eric Blossom <eb@comsec.com> wrote:

> FWIW, you may want to look at the Goertzel algorithm for computing
> power at a single frequency.

...which is conveniently implemented in gr.goertzel_fc() :-)

Johnathan

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

Re: [Discuss-gnuradio] block that does simple tone detection

On Fri, Feb 26, 2010 at 02:26:53PM -0800, Affan Syed wrote:
> Hi all,
> I have been building a simple block that can detect energy at a
> particular frequency, i.e. a tone detection block. The signal
> processing seemed simple enough for me, so I directly coded it.
> Essentially my tone_sink takes in float point samples of the input
> signal (passed through a narrow bandpass filter), squares them and
> keeps a short term and long term average (I use an EWMA with
> different alpha's). I then generate a message if the short term avg
> is becomes much greater than the long term average. here is the .cc
> code

Assuming that you've subclassed gr_sync_block, you shouldn't be
calling consume_each.

FWIW, you may want to look at the Goertzel algorithm for computing
power at a single frequency.

Eric

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

Re: [Discuss-gnuradio] about the work function and memory

On Fri, Feb 26, 2010 at 14:05, Josh Blum <josh@joshknows.com> wrote:

> Here is a typical work function:
> int work(int noutput_items,
>                       gr_vector_const_void_star &input_items,
>                       gr_vector_void_star &output_items)
>
> output_items seems to be a pointer to a pointer into some pre-allocated
> memory. What is stopping me from managing my own memory, pointing the output
> items pointer into my memory, and returning an arbitrary noutput_items?
>
> Is it possible? What are the limitations?

Short answer: no.

Longer answer:

The memory pointed to by the output_items vector is a shared buffer
created by the GNU Radio runtime, which implements a thread-safe,
single writer, multi-reader shared ring buffer. The readers in this
case are the downstream blocks inputs that are set up when by calling
'connect'. See gr_buffer and related classes in the core runtime
directory. When your work function returns the number of items
produced, the runtime adjusts the buffer pointers and "knows" to
signal other connected block threads that input is available.
Likewise, when a work function calls consume, it is telling the
runtime to adjust the input reader pointer, and when all downstream
blocks have moved their reader pointers far enough, the runtime
"knows" to signal upstream block threads that their work function can
be called again. It's all a highly optimized dance.

Johnathan

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

[Discuss-gnuradio] block that does simple tone detection

Hi all,

I have been building a simple block that can detect energy at a particular frequency, i.e. a tone detection block. The signal processing seemed simple enough for me, so I directly coded it. Essentially my tone_sink  takes in float point samples of the input signal (passed through a narrow bandpass filter), squares them and keeps a short term and long term average (I use an EWMA with different alpha's). I then generate a message if the short term avg is becomes much greater than the long term average. here is the .cc code

int 

tone_sink::work (int noutput_items,

gr_vector_const_void_star &input_items,

gr_vector_void_star &output_items)

{

float *in = (float *) input_items[0];

    int count=0;

float sample_sqr;

 while (count < noutput_items){

 

//update both averages and observe the behavior over a period of time. 

 

sample_sqr=in[count]*in[count];//need to square to get energy of signal 

 

d_short_term_avg=d_alpha_short*sample_sqr+(1.0f - d_alpha_short)*d_short_term_avg;

 

d_long_term_avg=d_alpha_long*sample_sqr+(1.0f - d_alpha_long)*d_long_term_avg;

 

if ( (d_short_term_avg-d_long_term_avg) > THRESHOLD){

 

gr_message_sptr msg = gr_make_message(0, 0, 0, 1);//make a byte pkt to signal tone detection

d_target_queue->insert_tail(msg);       // send it

msg.reset();                // free it up

 

 

 }

 

 }

  // Tell runtime system how many input items we consumed on

  // each input stream.

  consume_each (noutput_items);

  // Tell runtime system how many output items we produced.

  return noutput_items;

}

However when I connect this sink on in a flow graph, my programs stalls. 

here is the python code 

class tone_graph(gr.top_block):

    def __init__(self):

        gr.top_block.__init__(self)

        audio_rate = AUDIO_RATE

        self.rcvd_pktq = gr.msg_queue()

         

        src = gr.wavfile_source("./tone.wav", False)

         

        bp_coeff = gr.firdes.band_pass(1,audio_rate,TONE_FREQ-500,TONE_FREQ+500,100)

        bpf = gr.fir_filter_fff(1,bp_coeff)

        

        

        #speaker = audio.sink(audio_rate);

         

                

        sink = tone.sink(self.rcvd_pktq,0.5,0.95)

        #raw_wave = gr.wavfile_sink("raw.wav", 1, audio_rate,16)

        filt_wave = gr.wavfile_sink("filtered.wav", 1, audio_rate, 16)

        

        self.connect(src,bpf,filt_wave)

        #self.connect(src,raw_wave)

        #self.connect(src, speaker)

        self.connect(bpf,sink)# link the output of band pass filter to my tone rx module

        

        self.watcher = _queue_watcher_thread(self.rcvd_pktq, message_callback)

def main():

    fg = tone_graph()

    fg.start()

        

    try:

        print "Hit Ctrl-D to exit NOW."

        while True:

            raw_input("")

    except EOFError:

        print "\nExiting."

    #    #fg.wait()

# Main python entry

Further debugging this I observed that my CPU saturated while running the code on my sink block (I verified this using the activity monitor on my PowerBook G4, yes quite old PPC). So now the question is, am I doing something *that* intensive that a simple multiplication and EWMA update per sample is asking too much OR is there something wrong that I am doing ? Other seemingly as intensive functions from the GNU core work on my system so I am little surprised with this result.

Since the tone is at 18Khz I have lowered my AUDIO_RATE upto 40K but still now enough. 

Thanks for your help

Affan.  

[Discuss-gnuradio] about the work function and memory

Here is a typical work function:
int work(int noutput_items,
gr_vector_const_void_star &input_items,
gr_vector_void_star &output_items)

output_items seems to be a pointer to a pointer into some pre-allocated
memory. What is stopping me from managing my own memory, pointing the
output items pointer into my memory, and returning an arbitrary
noutput_items?

Is it possible? What are the limitations?

Thanks,
-Josh

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

Re: [Discuss-gnuradio] Installing GNU Radio on cygwin

My boost version is 1.42,still it gives the same error. I am still at the ./configure stage. I think I should use sudo command after ./configure is successful,am I right? Thank you for all your help. Regards, Reena --- On Sat, 2/27/10, Ms reena vade <r_vade@yahoo.co.in> wrote: From: Ms reena vade <r_vade@yahoo.co.in> Subject: Re: [Discuss-gnuradio] Installing GNU Radio on cygwin To: smzerocool@gmail.com Date: Saturday, February 27, 2010, 2:11 AM --- On Sat, 2/27/10, smzerocool@gmail.com <smzerocool@gmail.com> wrote: From: smzerocool@gmail.com <smzerocool@gmail.com> Subject: Re: [Discuss-gnuradio] Installing GNU Radio on cygwin To: "Ms reena vade" <r_vade@yahoo.co.in> Date: Saturday, February 27, 2010, 1:55 AM Use sudo before running make command and check your boost version, it should be higher than 1.35 Sent on my BlackBerry® from Vodafone -----Original Message----- From: Ms reena vade <r_vade@yahoo.co.in> Date: Sat, 27 Feb 2010 01:19:12 To: <discuss-gnuradio@gnu.org> Subject: [Discuss-gnuradio] Installing GNU Radio on cygwin _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Installing GNU Radio on cygwin

Thank you everyone for your help to my previous query regarding the installation of GNU Radio on Cygwin. I have checked my fortran 77 compiler and it works fine now( thank you zerocool :)),but now I get some : "conftest.err : Permission denied "  and another error which says " your boost libraries seem too old." My question is : ( 1 ) Shall I ignore the conftest errors because  the conftest.dir, conftest.h and ccp are created while installing and they automatically are removed also? Thank you for all your help....I am really happy with the progress I achieved due to your suggestions! Regards, Reena

Re: [Discuss-gnuradio] RFX900 Failure

On 02/26/2010 10:05 AM, David Evans wrote:
> Hi,
>
> Thanks for the fast response. Yes the SAW filter is broken and putting a
> capacitor in as you suggested has brought the output power back up to
> normal. :-)

Great! If you can survive without the filtering, you're actually better
off now because you'll have 1.5 to 2 dB less loss.

>
> So, a couple of questions please,
>
> * Can the SAW be damaged by too much power from the PA? (I could
> find no info on the maximum power limits for this device, just the
> bandwidth and attenuation).

It can be. I had been told by Sawtek that the part was supposed to be
good to half a watt. While the RFX900 won't put out that much power,
some of them will come within 1-2 dB of that. The longer you operate
near any parts maximums, the shorter its life will be. This is only the
second time in many many boards and over 4 years that we've seen this
problem, so you just might be on the unlucky tail of the distribution.

> * Can the SAW be damaged by a mismatched load (i.e no load!). I've
> asked around about this and get differing opinions
> o Yes, because the reflected power will be additively doubled,
> and enhanced due to the high Q of the filter

Not enhanced by the Q, but a high SWR can result in higher peak voltage
which can stress a device.

> o No, because the filter is a passive device, and the power
> will just pass through.

Each time the power passes through it is subject to insertion loss which
is dissipated, so reflected power will add a little to the dissipation
if you have a really bad reflection.

> * Also, apparently, SAW filters can easily be damaged due to
> physical shock, damaging the piezo electric material, so maybe
> this was just a one-off. I'll have to replace the chip anyway

My best guess is that this is due to sustained high power over a long
period heating and aging the device.

Matt

>
> Thanks again guys,
> David
>
>
> Matt Ettus wrote:
>>
>> On 02/24/2010 09:42 AM, David Evans wrote:
>>> Hi all,
>>>
>>> Power output has significantly dropped, initially by 8dB, now much more.
>>>
>>> My first thoughts are that the PA has failed, so is it possible to break
>>> the transmitter...
>>> - by prolonged transmitting at high power (i.e. setting it to/near
>>> maximum)?
>>> - using a mismatched antenna?
>>> - mismatching resulting in VSWR effects? (err, without a load)?
>>>
>>> I'm obviously going to have to test now, where to start, any
>>> suggestions, like what voltage swing before and after the 3315 should I
>>> expect?
>>
>>
>> I have seen this once before with someone who was transmitting at max
>> power continuously. The problem may be in the SAW filter, which would
>> make it easy to fix. You can just put a cap of anywhere between 50 and
>> 1000 pF, size 0603 in the empty capacitor location which is in
>> parallel with the filter.
>>
>> In order to tell if that really is the problem, you would probably
>> need to probe with an RF probe for your spectrum analyzer or vary fast
>> oscilloscope. You could probe at the antenna port and immediately
>> before the SAW filter, and if there is a big loss in the filter you
>> know that is bad.
>>
>> If you don't have the equipment to test this, it may be easier to just
>> put the cap in there and try it.
>>
>> Matt
>>
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
>
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

Re: [Discuss-gnuradio] RFX900 Failure

Hi,

Thanks for the fast response. Yes the SAW filter is broken and putting a
capacitor in as you suggested has brought the output power back up to
normal. :-)

So, a couple of questions please,

* Can the SAW be damaged by too much power from the PA? (I could
find no info on the maximum power limits for this device, just the
bandwidth and attenuation).
* Can the SAW be damaged by a mismatched load (i.e no load!). I've
asked around about this and get differing opinions
o Yes, because the reflected power will be additively doubled,
and enhanced due to the high Q of the filter
o No, because the filter is a passive device, and the power
will just pass through.
* Also, apparently, SAW filters can easily be damaged due to
physical shock, damaging the piezo electric material, so maybe
this was just a one-off. I'll have to replace the chip anyway

Thanks again guys,
David

Matt Ettus wrote:
>
> On 02/24/2010 09:42 AM, David Evans wrote:
>> Hi all,
>>
>> Power output has significantly dropped, initially by 8dB, now much more.
>>
>> My first thoughts are that the PA has failed, so is it possible to break
>> the transmitter...
>> - by prolonged transmitting at high power (i.e. setting it to/near
>> maximum)?
>> - using a mismatched antenna?
>> - mismatching resulting in VSWR effects? (err, without a load)?
>>
>> I'm obviously going to have to test now, where to start, any
>> suggestions, like what voltage swing before and after the 3315 should I
>> expect?
>
>
> I have seen this once before with someone who was transmitting at max
> power continuously. The problem may be in the SAW filter, which would
> make it easy to fix. You can just put a cap of anywhere between 50
> and 1000 pF, size 0603 in the empty capacitor location which is in
> parallel with the filter.
>
> In order to tell if that really is the problem, you would probably
> need to probe with an RF probe for your spectrum analyzer or vary fast
> oscilloscope. You could probe at the antenna port and immediately
> before the SAW filter, and if there is a big loss in the filter you
> know that is bad.
>
> If you don't have the equipment to test this, it may be easier to just
> put the cap in there and try it.
>
> Matt
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>

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

[Discuss-gnuradio] trellis.viterbi function_2part

Thanks Achilleas.
I read all the documentation concerning the trellis, and the final idea that
comes to me is to write a code like the following (to implement the
convolutional decoding 1/2, poly 91,121, constraint len 7):

input_length = 48
output_length = 24
src_data = [1.0 for index in range (input_length)]
src = gr.vector_source_f (src_data, False, input_length)
f = trellis.fsm (1,2,[91,121])
my_trellis_viterbi = trellis.viterbi_i (f,24,-1,-1)
dst = gr.vector_sink_i (output_length)
self.fg.connect (src, my_trellis_viterbi)
self.fg.connect (my_trellis_viterbi, dst)
self.fg.run ()
dec_temp = dst.data ()

why do you think it does not work? The error is always a mismatch of
dimensions between inputs and outpus.

Thx,
Simone.
--
View this message in context: http://old.nabble.com/trellis.viterbi-function_2part-tp27719893p27719893.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

Re: [Discuss-gnuradio] Installing GNURadio on Cygwin, Windows XP: URGENT!!!!!!!!!!!!!

Ms reena vade wrote:

> Hello everyone! I am new to GNURadio. I tried installing cygwin with all
> the utilities > and libraries as given on gnuradio.org. And then I
> unzipped gnuradio as well. I have
> the following doubts:
> ( 1 ) Shall I unzip GNURadio in the same drive where I have
> installed cygwin? For Eg : i have downloaded cygwin and installed it on my
> F :\
> drive. And on the same drive I have unzipped GNURadio-3.2.2. So my
> question is
> shall I unzip GNURadio inside cygwin or I am ok if it is installed on F :
> drive?

It shouldn't matter as long as there are no spaces in your path name.

> ( 2 ) If the answer of above question is that I let GNURadio remain on F
> drive,
> then when I try building the minimal GNURadio syatem by giving the
> ./configure
> command, i get error: unable to use python headers. How to solve this?

I assume you are following the instructions at
gnuradio.org/redmine/wiki/gnuradio/CygwinInstallMain. If not you may want
to look there first.

The config.log file tells you what it was doing when it ran into trouble.
Does the file /usr/include/python2.5/Python.h exist? It might help to tell
us what parameters you used on ./configure and the exact error message and
the lines that precede it in the output of ./configure.

-- Don W.

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

AW: [Discuss-gnuradio] Memory leak when creating several USRP 2objects in C

Hi Eric

Here some information for you:

C++ Code:
#include <usrp2/usrp2.h>
int main ()
{
usrp2::usrp2::sptr u2;
int count = 0;
while (count++< 3)
{
sleep(3);
u2.reset();
u2 = usrp2::usrp2::make("eth0","");
}
return 0;
}

Memory usage:
first iteration
$ pmap 11770
...
00007f0c6808b000 24412K rw-s- [ anon ]
...
total 57280K

second iteration
$ pmap 11770
...
00007f0c660b3000 24412K rw-s- [ anon ]
...
00007f0c6808b000 24412K rw-s- [ anon ]
...
total 81692K

third iteration
$ pmap 11770

...
00007f0c648dc000 24412K rw-s- [ anon ]
00007f0c660b3000 24412K rw-s- [ anon ]
...
00007f0c6808b000 24412K rw-s- [ anon ]
total 106104K

here you can see that every iteration uses 24412K Byte.

Sample with 23 iterations:
$ pmap 12492
...
00007f4cdcf22000 24412K rw-s- [ anon ]
00007f4cde6f9000 24412K rw-s- [ anon ]
00007f4cdfed0000 24412K rw-s- [ anon ]
00007f4ce16a7000 24412K rw-s- [ anon ]
00007f4ce2e7e000 24412K rw-s- [ anon ]
00007f4ce4655000 24412K rw-s- [ anon ]
00007f4ce5e2c000 24412K rw-s- [ anon ]
00007f4ce7603000 24412K rw-s- [ anon ]
00007f4ce8dda000 24412K rw-s- [ anon ]
00007f4cea5b1000 24412K rw-s- [ anon ]
00007f4cebd88000 24412K rw-s- [ anon ]
00007f4ced55f000 24412K rw-s- [ anon ]
00007f4ceed36000 24412K rw-s- [ anon ]
00007f4cf050d000 24412K rw-s- [ anon ]
00007f4cf1ce4000 24412K rw-s- [ anon ]
00007f4cf34bb000 24412K rw-s- [ anon ]
00007f4cf4c92000 24412K rw-s- [ anon ]
00007f4cf6469000 24412K rw-s- [ anon ]
00007f4cf7c40000 24412K rw-s- [ anon ]
00007f4cf9417000 24412K rw-s- [ anon ]
00007f4cfabee000 24412K rw-s- [ anon ]
00007f4cfc3c5000 24412K rw-s- [ anon ]
...
00007f4cfe39d000 24412K rw-s- [ anon ]
...
total 594344K

an plot of memory usage from 0 to 25 iterations is shown in figure1.png

Hope this information can help you

Best regards
Christian

-----Ursprüngliche Nachricht-----
Von:
discuss-gnuradio-bounces+christian.kisters=nts.uni-duisburg-essen.de@gnu.org
[mailto:discuss-gnuradio-bounces+christian.kisters=nts.uni-duisburg-essen.de
@gnu.org] Im Auftrag von Eric Blossom
Gesendet: Freitag, 26. Februar 2010 01:02
An: Christian Kisters
Cc: 'discuss-gnuradio'
Betreff: Re: [Discuss-gnuradio] Memory leak when creating several USRP
2objects in C

On Wed, Feb 24, 2010 at 10:53:49AM +0100, Christian Kisters wrote:
> Hi,
>
> Like in the old thread '[Discuss-gnuradio] memory leak when creating
several
> usrp2 objects' from
> 'Jakob Meineke Thu, 30 Jul 2009 09:52:20'
> http://www.mail-archive.com/discuss-gnuradio@gnu.org/msg20403.html
> the problem with the memory leak still exists.
>
>
> The memory usage increases while creating several USRP2s in C.
>
> usrp2::usrp2::sptr u2;
> for (int i=0;i<20;i++)
> {
> U2.reset();
> u2 = usrp2::usrp2::make("eth0","");
> }
>
> The used memory will be released only by closing the program. So it's
> expected that the memory runs out of its limits.
>
> Has someone an idea how to fix this problem?
>
> Best regards
> Chrisitan

Thanks Christian for pointing out the problem.

I'll take a look at this, but it may be a few days.
How much is it leaking per iteration?
How are you determining how much it's leaking?

Thanks!
Eric

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

RE: [Discuss-gnuradio] M-block integration status

Dear List,

We are heading to the end of February, what is the status of the message passing functionality between blocks? I've been looking around in the developers branches but haven't found anything yet...

Can someone update me, please?

Best regards,
Patrik Eliardsson

> -----Original Message-----
> From: Eric Blossom [mailto:eb@comsec.com]
> Sent: Thursday, January 07, 2010 8:30 PM
> To: Patrik Eliardsson
> Cc: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] M-block integration status
>
> On Mon, Jan 04, 2010 at 03:49:38PM +0100, Patrik Eliardsson wrote:
> > Hi Folks,
>
> > Now when the VRT implementation seems to be almost finished,
>
> We're getting there!
>
> > what is the status of the integration of m-block
> capabilities into the
> > gnu-radio? The functionalities described here
> >
> http://lists.gnu.org/archive/html/discuss-gnuradio/2009-03/msg00319.ht
> > ml are just what we are looking for. However, if we don't
> want to wait
> > too long, can this be achieved with m-blocks at the moment? What
> > functionality is missing in the m-blocks? Or has anyone
> solved this in
> > another way?
>
> m-blocks are deprecated, and no further development will be
> done on them.
>
> We have a two pronged approach to achieving similar (or
> related) functionality. In no particular order they are:
>
> (1) Designing and implementing a mechanism whereby blocks can
> embed isochronous metadata in a data stream, tied to specific
> sample indicies. The idea is that blocks can check or set
> key/value pairs over a range of sample indices. We expect
> the metadata for streams that originate from a VRT source to
> contain the VRT Timestamp at the appropriate sample index.
> The GR runtime will be extended such that existing blocks,
> which are naive about this feature, will transparently
> forward metadata from their inputs to their outputs.
>
> (2) Implement per-block message queues to asynchronously
> receive messages containing arbitrarily-typed payloads from
> other blocks, and process them. (The first phase of this is
> complete, but we haven't advertised the feature since we're
> lacking support in hier_blocks, a high-level way to wire
> everything together, and are missing documentation and
> examples). As part of this, GR block "work" methods can send
> asynchronous messages. When a block receives a message, its
> handle_msg(pmt::pmt_t msg) method is called. The runtime
> ensures that handle_msg is never called while the block is in
> "work" and vice-versa. That is, the runtime handles
> everything related to ensuring that this feature works
> reliably in a multi-threaded environment.
>
> Both of these are on my "short-list" of work to get done. I
> expect that both will be complete by the end of February.
>
> I want to make a couple of additional observations about
> async message passing (2). Async message passing allows for
> the creation of blocks which:
>
> * Have only streaming input and/or outputs (like today)
> * Have only async message passing (no streaming i/o)
> * Have both streaming input and/or outputs and have async
> message passing
>
> This gives us the possibility of easily bridging between the
> dataflow and message passing enviroments. We expect that
> many "MAC-like"
> features will be implemented using async message passing,
> while some PHY layer stuff will continue to be implemented
> using the data flow paradigm.
>
> Adding a msg_handler to existing blocks allows block
> parameters to be tweaked at runtime without fear of thread
> safety problems. We've been kicking around some ideas for a
> "middle layer" that supports getting and setting arbitrary
> attributes, in such a way that adding them to a block is as
> simple as filling in a small table.
>
> > Regards,
> > Patrik Eliardsson
>
> Thanks for your question, and if you've got more, please ask away!
>
> Eric
>

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

[Discuss-gnuradio] Installing GNURadio on Cygwin, Windows XP: URGENT!!!!!!!!!!!!!

Hello everyone!         I am new to GNURadio. I tried installing cygwin with all the utilities and libraries as given on gnuradio.org. And then I unzipped gnuradio as well. I have the following doubts: ( 1 ) Shall I unzip GNURadio in the same drive where I have installed cygwin? For Eg : i have downloaded cygwin and installed it on my F :\ drive. And on the same drive I have unzipped GNURadio-3.2.2. So my question is shall I unzip GNURadio inside cygwin or I am ok if it is installed on F : drive? ( 2 ) If the answer of above question is that I let GNURadio remain on F drive, then when I try building the minimal  GNURadio syatem by giving the ./configure command, i get error: unable to use python headers.How to solve this?      Can anyone please help me,I am trying to get my GNURadio working since last 3 weeks but no success :( Thank you for looking into my query. Regards, Reena

Re: [Discuss-gnuradio] Memory leak when creating several USRP 2 objects in C

On Wed, Feb 24, 2010 at 10:53:49AM +0100, Christian Kisters wrote:
> Hi,
>
> Like in the old thread '[Discuss-gnuradio] memory leak when creating several
> usrp2 objects' from
> 'Jakob Meineke Thu, 30 Jul 2009 09:52:20'
> http://www.mail-archive.com/discuss-gnuradio@gnu.org/msg20403.html
> the problem with the memory leak still exists.
>
>
> The memory usage increases while creating several USRP2s in C.
>
> usrp2::usrp2::sptr u2;
> for (int i=0;i<20;i++)
> {
> U2.reset();
> u2 = usrp2::usrp2::make("eth0","");
> }
>
> The used memory will be released only by closing the program. So it's
> expected that the memory runs out of its limits.
>
> Has someone an idea how to fix this problem?
>
> Best regards
> Chrisitan

Thanks Christian for pointing out the problem.

I'll take a look at this, but it may be a few days.
How much is it leaking per iteration?
How are you determining how much it's leaking?

Thanks!
Eric

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

Re: [Discuss-gnuradio] Question about inputs and outputs of a block

gr_make_io_signature2 and 3? Common mr gnuradio, with your fancy c++ and
your smart pointers and your swig. How-about replacing this with a
single gr_make_io_signature with some parameter defaults:

gr_make_io_signature(min, max, io_size0, io_size1=0, io_size2=0,
io_size2=0... io_size7=0)

-Josh

On 02/25/2010 06:57 AM, Tom Rondeau wrote:
> On Thu, Feb 25, 2010 at 9:26 AM, elettra.pisa@libero.it
> <elettra.pisa@libero.it> wrote:
>> Hi all,
>>
>> I'd like to know if it's possible to create a block with two inputs (or two
>> outputs) having different sizes.
>> For example, a block that takes a vector of N numbers on one of its two inputs
>> and a stream (a vector which has only one element) on the other input.
>> I already tried to create a block with these characteristics, but I failed.
>> Please tell me if this is possible.
>>
>> Best Regards,
>>
>> Elettra.
>
> Yes, this is possible (in C++ blocks). You will make the IO signature
> using "gr_make_io_signature2", which takes the standard (min inputs,
> max inputs) as the first two arguments and the next two arguments are
> the item sizes for the different inputs/outputs. You can also use
> "gr_make_io_signature3" or "gr_make_io_signaturev", which takes a
> vector for the signature to have different stream sizes for any number
> of ports.
>
> We used this extensively in the OFDM code. For example, in
> gr_ofdm_sampler, on the input, we take in a stream of complex values
> on input 0 and a stream of characters (that act as flags) on input 1.
> The IO signature looks like:
>
> gr_make_io_signature2 (2, 2, sizeof (gr_complex), sizeof(char))
>
>
> Tom
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[Discuss-gnuradio] Full Duplex and RFX900 USRP2

Hello,

 

I have an application that requires me to continuously recieve a signal, while

continuously transmitting a delayed version of that recieved signal.  As a result

I need full duplex. I have a USRP2 and the rfx900 daughter board.  My plan

is to use the TX/RX port to transmit while using the RX2 port to recieve.  However,

I can not seem to get anything to listen/recieve on port RX2.  For example when

I run usrp2_fft.py and insert

 

self.subdev.select_rx_antenna('RX2).

 

this gives the error shown below.  By searching this forum I see where someone

has suggested that I rebuild the firmware by making these changes (for the rfx_900),

.base.atr_txval=0  ------> .base.atr_txval=MIX_EN | ANT_SW

.base.atr_rxval= MIX_EN --------> base.atr_rxval= MIX_EN | ANT_SW

 

However, will this a) work, that is allow me to use the RX2 port to recieve and b)

will it fix the problem shown below when I insert the call to self.subdev.select_rx_antenna('RX2).

Any help would be greatly appreciated.

 

Traceback (most recent call last):

  File "./usrp2_fft.py", line 275, in <module>

    main ()

  File "./usrp2_fft.py", line 271, in main

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

  File "/usr/local/lib/python2.5/site-packages/gnuradio/wxgui/stdgui2.py", line 36, in __init__

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

  File "/usr/lib/python2.5/site-packages/wx-2.8-gtk2-unicode/wx/_core.py", line 7836, in __init__

    self._BootstrapApp()

  File "/usr/lib/python2.5/site-packages/wx-2.8-gtk2-unicode/wx/_core.py", line 7433, in _BootstrapApp

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

  File "/usr/local/lib/python2.5/site-packages/gnuradio/wxgui/stdgui2.py", line 39, in OnInit

    frame = stdframe (self.top_block_maker, self.title, self._nstatus)

  File "/usr/local/lib/python2.5/site-packages/gnuradio/wxgui/stdgui2.py", line 60, in __init__

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

  File "/usr/local/lib/python2.5/site-packages/gnuradio/wxgui/stdgui2.py", line 81, in __init__

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

  File "./usrp2_fft.py", line 112, in __init__

    self.subdev.select_rx_antenna('RX2')

  File "/usr/local/lib/python2.5/site-packages/gnuradio/gr/top_block.py", line 94, in __getattr__

    return getattr(self._tb, name)

AttributeError: 'gr_top_block_sptr' object has no attribute 'subdev'

Re: [Discuss-gnuradio] USRP2 LFTX maximum real baseband bandwidth?

On 02/25/2010 01:01 AM, TANGUY Philippe wrote:
> Hi all,
>
> I would like to send a real signal with a bandwith from DC to 25MHZ
> thanks to the USRP2 and the LFTX daughterboard.
>
> So, I generate a Real baseband signal and I use only the "I" channel.
> But, it seems that the minimun interpolation of USRP2 is 4 (USRP2faq)
> that's why I use interp=4. So, I have a bandwidth of 12.5 MHz because
> the sampling frequency is fs=25 MS/s ==> fs/2 = 12.5 MS/s. For me, it
> seems good.

If you want a 25 MHz wide signal (0 to 25 MHz), then you should generate
it at baseband (+/-12.5 MHz), and have the digital upconverter in the
FPGA upconvert to a center frequency of 12.5 MHz That will give you 0
to 25 MHz coverage.

>
> So, my first question is:
> Is it possible to use an interpolation of only 2 to have bandwidth=25 Mhz?

Using an interpolation of 4 gives you a bandwidth of 25 MHz. Using an
interpolation of 2 would give you 50 MHz, but would require 8 bit I and
Q samples.

>
> Secondly, I'm not sure but if we use interp=2 we have before the DUC a
> data rate = 50 MS/s * 32 (float32) = 1600 Mbits/s ==> > Gb/s.
> However, if we use interp=2 and "short" format, we have a data rate = 50
> MS/s * 16 (short) = 800 Mbits/s ==> < Gb/s.

We don't have an interp by 2 mode yet, but it could be done. However,
as I stated above, I don't think you need it to do what you want to do.

Matt

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

Re: [Discuss-gnuradio] USRP2 LFTX maximum real baseband bandwidth?

Per Zetterberg wrote:
> Quoting TANGUY Philippe <Philippe.Tanguy@insa-rennes.fr>:
>
>> Ulrika Uppman wrote:
>>> Hi,
>>> I believe the short format isn't implemented for the USRP2 yet, or
>>> has this been done recently?
>>>
>>> /Ulrika
>>>
>>
>> Hi,
>>
>> Indeed, the short format seems to be not implemented for the USRP2
>> yet. However, usrp2_sink_16sc can be used (I tried to send a cosine
>> with short format but with no success) but do not work.
>>
>> If we can used the short format and an interpolation = 2, do you think
>> that the data rate will be 50 MS/s * 16 (short) = 800 Mbits/s before
>> the Digital Up Converter?
>>
>> and
>>
>> Is it possible to have an interpolation = 2 ?
>>
>
> My understanding is that we need 32bits per sample, 16bits I and 16bits Q.
>
> BR/
> Per
>
>

Thanks for the response. Indeed, you are right.

In fact, I was confused between the GNUradio format representation and
the appropriate "on the wire" representation, depending on the current
USRP2 configuration which is apparently 16-bit I & Q. (see in
documentation here:
http://gnuradio.org/doc/doxygen/classusrp2_1_1usrp2.html).

Now, my problem is to know if it is possible to use an interpolation of
2 in order to have a data rate of 50 MS/s to transmit a real baseband
signal with a bandwidth of 25 MHz.

Regards,

Philippe.

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

Re: [Discuss-gnuradio] Question about inputs and outputs of a block

>----Messaggio originale----
>Da: trondeau1122@gmail.com
>Data: 25-feb-2010 15.57
>A: "elettra.pisa@libero.it"<elettra.pisa@libero.it>
>Cc: <discuss-gnuradio@gnu.org>
>Ogg: Re: [Discuss-gnuradio] Question about inputs and outputs of a block
>
>On Thu, Feb 25, 2010 at 9:26 AM, elettra.pisa@libero.it
><elettra.pisa@libero.it> wrote:
>> Hi all,
>>
>> I'd like to know if it's possible to create a block with two inputs (or two
>> outputs) having different sizes.
>> For example, a block that takes a vector of N numbers on one of its two
inputs
>> and a stream (a vector which has only one element) on the other input.
>> I already tried to create a block with these characteristics, but I failed.
>> Please tell me if this is possible.
>>
>> Best Regards,
>>
>> Elettra.
>
>Yes, this is possible (in C++ blocks). You will make the IO signature
>using "gr_make_io_signature2", which takes the standard (min inputs,
>max inputs) as the first two arguments and the next two arguments are
>the item sizes for the different inputs/outputs. You can also use
>"gr_make_io_signature3" or "gr_make_io_signaturev", which takes a
>vector for the signature to have different stream sizes for any number
>of ports.
>
>We used this extensively in the OFDM code. For example, in
>gr_ofdm_sampler, on the input, we take in a stream of complex values
>on input 0 and a stream of characters (that act as flags) on input 1.
>The IO signature looks like:
>
>gr_make_io_signature2 (2, 2, sizeof (gr_complex), sizeof(char))
>
>
>Tom
>

Thank you Tom, but probably I have not expressed correctly.
I'd like to create a block that takes as first input a vector of N float and
as second input only one float.
Is it possible?

Elettra

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

[Discuss-gnuradio] block for continuous production of samples

Good morning,
I need to implement a double 802.15.4-802.11b transmitter that transmits packets in asynchronous (or aperiodical) mode.
I realized a simple program where the output of the two trasmitters are added together to generate the output stream.
Unfortunately, when one of the two transmitters ends to generate a packet, also the other one stops. It happens ( i think! ) because there are no samples for the adder to combine with and the forecast() method stops the execution.
By the way, I found online a similar discussion:
http://www.mail-archive.com/discuss-gnuradio@gnu.org/msg08387.html
In order to have a countinuos output stream even when the two transmitters are inactive, could I implement a gnuradio c++ block with the following characteristics?
-performs a continuous production of null samples (when there are no input to the block)
-lets the samples unchanged if there are samples at his input.

Thanks a lot,
Bertussi Daniele - University of Brescia, Italy

Informativa sulla privacy: http://help.ing.unibs.it/privacy.php

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

[Discuss-gnuradio] what is the unit of transmitting amplitude in benchmark_ofdm_tx.py

Hi there,

I wonder what is the unit of the transmitting amplitude used in benchmark_ofdm_tx.py?

In transmit_path.py, it is recommended to try 8000, see below.

    def set_tx_amplitude(self, ampl):
        """
        Sets the transmit amplitude sent to the USRP
        @param: ampl 0 <= ampl < 32768.  Try 8000
        """
        self._tx_amplitude = max(0.0, min(ampl, 32767.0))
        self.amp.set_k(self._tx_

amplitude)


Thanks
Tianji

Re: [Discuss-gnuradio] Question about inputs and outputs of a block

On Thu, Feb 25, 2010 at 9:26 AM, elettra.pisa@libero.it
<elettra.pisa@libero.it> wrote:
> Hi all,
>
> I'd like to know if it's possible to create a block with two inputs (or two
> outputs) having different sizes.
> For example, a block that takes a vector of N numbers on one of its two inputs
> and a stream (a vector which has only one element) on the other input.
> I already tried to create a block with these characteristics, but I failed.
> Please tell me if this is possible.
>
> Best Regards,
>
> Elettra.

Yes, this is possible (in C++ blocks). You will make the IO signature
using "gr_make_io_signature2", which takes the standard (min inputs,
max inputs) as the first two arguments and the next two arguments are
the item sizes for the different inputs/outputs. You can also use
"gr_make_io_signature3" or "gr_make_io_signaturev", which takes a
vector for the signature to have different stream sizes for any number
of ports.

We used this extensively in the OFDM code. For example, in
gr_ofdm_sampler, on the input, we take in a stream of complex values
on input 0 and a stream of characters (that act as flags) on input 1.
The IO signature looks like:

gr_make_io_signature2 (2, 2, sizeof (gr_complex), sizeof(char))

Tom

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

Re: [Discuss-gnuradio] USRP2 LFTX maximum real baseband bandwidth?

Quoting TANGUY Philippe <Philippe.Tanguy@insa-rennes.fr>:

> Ulrika Uppman wrote:
>> Hi,
>> I believe the short format isn't implemented for the USRP2 yet, or
>> has this been done recently?
>>
>> /Ulrika
>>
>
> Hi,
>
> Indeed, the short format seems to be not implemented for the USRP2
> yet. However, usrp2_sink_16sc can be used (I tried to send a cosine
> with short format but with no success) but do not work.
>
> If we can used the short format and an interpolation = 2, do you
> think that the data rate will be 50 MS/s * 16 (short) = 800 Mbits/s
> before the Digital Up Converter?
>
> and
>
> Is it possible to have an interpolation = 2 ?
>

My understanding is that we need 32bits per sample, 16bits I and 16bits Q.

BR/
Per

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

[Discuss-gnuradio] Question about inputs and outputs of a block

Hi all,

I'd like to know if it's possible to create a block with two inputs (or two
outputs) having different sizes.
For example, a block that takes a vector of N numbers on one of its two inputs
and a stream (a vector which has only one element) on the other input.
I already tried to create a block with these characteristics, but I failed.
Please tell me if this is possible.

Best Regards,

Elettra.

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

Re: [Discuss-gnuradio] USRP2 LFTX maximum real baseband bandwidth?

Ulrika Uppman wrote:
> Hi,
> I believe the short format isn't implemented for the USRP2 yet, or has this been done recently?
>
> /Ulrika
>

Hi,

Indeed, the short format seems to be not implemented for the USRP2 yet.
However, usrp2_sink_16sc can be used (I tried to send a cosine with
short format but with no success) but do not work.

If we can used the short format and an interpolation = 2, do you think
that the data rate will be 50 MS/s * 16 (short) = 800 Mbits/s before the
Digital Up Converter?

and

Is it possible to have an interpolation = 2 ?

Philippe.

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

RE: [Discuss-gnuradio] RE: Timestamp value

Hello again,
Just want to clear this out for anyone else who bumps in to this:
The solution is simple. The reason that the timestamps behaved strange in the 3.2 version is because of the byte reverse order of the timestamp when they are fetched from the pkt->hdrs.fixed.timestamp (I can't believe I didn't see this sooner ;) ). Running the timestamp through the ntohx-function made the values much clearer! If I take the difference between two received packets and divide by the decimation rate this will now always result in 371 as expected.

Best regards,
Ulrika

> -----Original Message-----
> From: discuss-gnuradio-bounces+ulrika.uppman=foi.se@gnu.org
> [mailto:discuss-gnuradio-bounces+ulrika.uppman=foi.se@gnu.org]
> On Behalf Of Ulrika Uppman
> Sent: Tuesday, February 23, 2010 3:54 PM
> To: discuss-gnuradio@gnu.org
> Subject: RE: [Discuss-gnuradio] RE: Timestamp value
>
> I have now finally managed to get the vrt code, the problem
> was that I got the wrong address... Sorry :P
>
> So lets get back to the main issue:
>
> I now ran the vrt version and when I take the difference in
> ticks between the packets and divide by the decimation rate,
> the result is always 365. Seems more reasonable than the
> results by the other versions, but I would still expect the
> value to be 371 since samples_per_frame is set by default to
> this value in rx_samples. Where does the value 365 come from?
>
> This also brings me back to the question on the 3.2 stable
> release which is the version of gnuradio that I am currently
> using. In 3.2 the timestamps don't behave like the time ticks
> (fractional time part) in the vrt version. (The behavior in
> version 3.2 is described earlier in this thread
> http://lists.gnu.org/archive/html/discuss-gnuradio/2010-02/msg
00343.html ) What is the difference else than the size (32 vs 64 > bits)?
>
> What else could I do wrong to get such different behavior?
> I use the firmware and fpga image from
> http://gnuradio.org/releases/usrp2-bin/trunk/ and
> http://www.ettus.com/usrp2_vrt for the two versions, and the
> code is not touched except from the printouts.
>
> Thanks for any hints.
> Regards,
> Ulrika
>

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

RE: [Discuss-gnuradio] USRP2 LFTX maximum real baseband bandwidth?

Hi,
I believe the short format isn't implemented for the USRP2 yet, or has this been done recently?

/Ulrika

> -----Original Message-----
> From: discuss-gnuradio-bounces+ulrika.uppman=foi.se@gnu.org
> [mailto:discuss-gnuradio-bounces+ulrika.uppman=foi.se@gnu.org]
> On Behalf Of TANGUY Philippe
> Sent: Thursday, February 25, 2010 10:01 AM
> To: discuss-gnuradio@gnu.org
> Subject: [Discuss-gnuradio] USRP2 LFTX maximum real baseband
> bandwidth?
>
> Hi all,
>
> I would like to send a real signal with a bandwith from DC to
> 25MHZ thanks to the USRP2 and the LFTX daughterboard.
>
> So, I generate a Real baseband signal and I use only the "I" channel.
> But, it seems that the minimun interpolation of USRP2 is 4
> (USRP2faq) that's why I use interp=4. So, I have a bandwidth
> of 12.5 MHz because the sampling frequency is fs=25 MS/s ==>
> fs/2 = 12.5 MS/s. For me, it seems good.
>
> So, my first question is:
> Is it possible to use an interpolation of only 2 to have
> bandwidth=25 Mhz?
>
> Secondly, I'm not sure but if we use interp=2 we have before
> the DUC a data rate = 50 MS/s * 32 (float32) = 1600 Mbits/s
> ==> > Gb/s.
> However, if we use interp=2 and "short" format, we have a
> data rate = 50 MS/s * 16 (short) = 800 Mbits/s ==> < Gb/s.
>
> Is it correct?
>
> Thanks,
>
> Philippe.
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>

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

[Discuss-gnuradio] USRP2 LFTX maximum real baseband bandwidth?

Hi all,

I would like to send a real signal with a bandwith from DC to 25MHZ
thanks to the USRP2 and the LFTX daughterboard.

So, I generate a Real baseband signal and I use only the "I" channel.
But, it seems that the minimun interpolation of USRP2 is 4 (USRP2faq)
that's why I use interp=4. So, I have a bandwidth of 12.5 MHz because
the sampling frequency is fs=25 MS/s ==> fs/2 = 12.5 MS/s. For me, it
seems good.

So, my first question is:
Is it possible to use an interpolation of only 2 to have bandwidth=25 Mhz?

Secondly, I'm not sure but if we use interp=2 we have before the DUC a
data rate = 50 MS/s * 32 (float32) = 1600 Mbits/s ==> > Gb/s.
However, if we use interp=2 and "short" format, we have a data rate = 50
MS/s * 16 (short) = 800 Mbits/s ==> < Gb/s.

Is it correct?

Thanks,

Philippe.

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

Re: [Discuss-gnuradio] RFX900 Failure

On 02/24/2010 09:42 AM, David Evans wrote:
> Hi all,
>
> Power output has significantly dropped, initially by 8dB, now much more.
>
> My first thoughts are that the PA has failed, so is it possible to break
> the transmitter...
> - by prolonged transmitting at high power (i.e. setting it to/near
> maximum)?
> - using a mismatched antenna?
> - mismatching resulting in VSWR effects? (err, without a load)?
>
> I'm obviously going to have to test now, where to start, any
> suggestions, like what voltage swing before and after the 3315 should I
> expect?

I have seen this once before with someone who was transmitting at max
power continuously. The problem may be in the SAW filter, which would
make it easy to fix. You can just put a cap of anywhere between 50 and
1000 pF, size 0603 in the empty capacitor location which is in parallel
with the filter.

In order to tell if that really is the problem, you would probably need
to probe with an RF probe for your spectrum analyzer or vary fast
oscilloscope. You could probe at the antenna port and immediately
before the SAW filter, and if there is a big loss in the filter you know
that is bad.

If you don't have the equipment to test this, it may be easier to just
put the cap in there and try it.

Matt

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

Re: [Discuss-gnuradio] trellis.viterbi function

Simone,

please take a look at the extensive documentation in:

gnuradio_trunk/gr-trellis/doc/gr-trellis.html

You need to first create an FSM object that describes your finite state
machine (using the generator polynomials you have)
and then use this as an argument to the Viterbi decoder.

The reason for this is that the Viterbi decoder is not only used for
decoding convolutional codes, but for numerous other applications; thus
the need to relate it only to the underline finite state machine...

Please take a look at the numerous examples given and let me know if you
have any further questions.

Achilleas

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

Re: [Discuss-gnuradio] reconfiguring with usrp2 src present

Hi,

I upgraded to the latest trunk and, after brief testing, I thought
that the problem disappeared.
Unfortunately, I still see it every now and then. I'm modifying OFDM
receiver parameters, increasing modulation from "bpsk" to "qam256" and
changing the number of ofdm subcarriers after some time.

Occasionally I'd get
usrp2: channel 0 not receiving
usrp2::rx_samples() failed

And it seems that this does not depend on which
modulation/occupied-tones combination I try to use. It's just random.
Although, It's still better than with 3.2.2 where I used to get the
error every time.

Does anyone have an idea about how to go around this?

Thanks a lot,

Veljko

2010/2/16 Alexandru Csete <oz9aec@googlemail.com>:
> On 16 February 2010 23:32, Veljko Pejovic <veljko@cs.ucsb.edu> wrote:
>> Thanks a lot for the answer, Jonathan.
>>
>> Yes, I am using 3.2.2, I'll try with the latest trunk, although I
>> remember that in past I had problems with building gr-pager on Ubuntu
>> 9.10.
>
> I have successfully built gnuradio (including gr-pager) from git few
> weeks ago on Ubuntu 9.10 but I had to remove 3.2.2 from the linker
> path first, otherwise it will try to link against the libraries from
> 3.2.2 and that fails.
>
> Alex
>

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

Re: [Discuss-gnuradio] RFX900 Failure

On 02/24/2010 12:42 PM, David Evans wrote:
> Hi all,
>
> Power output has significantly dropped, initially by 8dB, now much more.
>
> My first thoughts are that the PA has failed, so is it possible to
> break the transmitter...
> - by prolonged transmitting at high power (i.e. setting it to/near
> maximum)?
Probably not
> - using a mismatched antenna?
> - mismatching resulting in VSWR effects? (err, without a load)?
>
RF amplifiers don't like transmitting into badly-mismatched loads. They
can definitely get damaged that
way. Anything below 2:1 VSWR will probably be OK, but beyond that,
you flirt with amplifier damage.

> I'm obviously going to have to test now, where to start, any
> suggestions, like what voltage swing before and after the 3315 should
> I expect?
>
> Many Thanks
> David
>
>
>
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>

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

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

[Discuss-gnuradio] RFX900 Failure

Hi all,

Power output has significantly dropped, initially by 8dB, now much more.

My first thoughts are that the PA has failed, so is it possible to break
the transmitter...
- by prolonged transmitting at high power (i.e. setting it to/near maximum)?
- using a mismatched antenna?
- mismatching resulting in VSWR effects? (err, without a load)?

I'm obviously going to have to test now, where to start, any
suggestions, like what voltage swing before and after the 3315 should I
expect?

Many Thanks
David

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

Re: [Discuss-gnuradio] Increase sine frequency every N samples

A few tips:

1) you dont have to lock the flow graph to change parameters (just to
disconnect and connect blocks)

2) you simplify this problem a bit by using the
gr_frequency_modulator_fc block. You can feed the frequency modulator a
step function that increases every N samples.

you could probably generate the input to the modulator with a ramp
function (sig source), a sample and hold block, and the vector source to
control the sample and hold block

-Josh

On 02/24/2010 08:22 AM, Carlos Aviles wrote:
> Hi,
>
> I want to generate a sine wave that increases in some kHz its
> frequency every N samples it produces.
>
> I know I can change the frequency of the sine using the available
> setter method on the gr_sig_source block. My problem is how to perform
> that change exactly after N samples have been produced by the
> gr_sig_source block. I've come up with some ideas:
>
> - Make the top_block aware of the number of samples that the
> gr_sig_source has produced. When N samples are produced, the top_block
> could call Lock(), change the parameter, and then Unlock(). My problem
> here is how to make the top_block aware of that count. I could use a
> "listener block" just after the gr_sig_source and let it count the
> samples that pass through it. After N samples, it could trigger some
> signal to the top block. I don't like this approach because it seems
> too complex.
>
> - Extend the functionality of gr_sig_source to increase the frequency
> by itself. By directly extending the class that won't work because
> there is no public constructor for gr_sig_source. Is there any other
> way of doing that?
>
> - Save N samples of different sine waves into files and then generate
> a single one by concatenation. I could use then a file_source block to
> incorporate these sine waves into any flow graph. The problem is the
> size of the resulting file.
>
> I would appreciate very much any help on that.
>
> I'm using gnuradio-3.2.2 and I want to generate a 100% C++ application.
>
> Thanks,
> Carlos.
>
> PS: I haven't posted any code because I don't have any yet :)
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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