Friday, April 30, 2010

Re: [Discuss-gnuradio] "Failed to set frequency to ..." message in Spectrum scan

On 04/30/2010 09:59 PM, Rahman Doost wrote:
Again the same, works for some time, then crashes!

On Fri, Apr 30, 2010 at 8:34 PM, Marcus D. Leech <mleech@ripnet.com> wrote:
On 04/30/2010 08:17 PM, Rahman Doost wrote:
> Well, the modification is for changing the code in such a way that it
> works on USRP2 since the original version is written for USRP. The
> rest is the same. Also it does't seem this is a programming bug since,
> it works for some time and then it crashes.
>
> Rahman
>
> O
What happens when you exit the program, and then go back in, does it
recover?

--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
I suspect that some resource, perhaps file descriptors, are "leaking" on each iteration of the
  scan.  Possibly because the device is being re-instantiated on every iteration?




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

Re: [Discuss-gnuradio] "Failed to set frequency to ..." message in Spectrum scan

Again the same, works for some time, then crashes!

On Fri, Apr 30, 2010 at 8:34 PM, Marcus D. Leech <mleech@ripnet.com> wrote:
On 04/30/2010 08:17 PM, Rahman Doost wrote:
> Well, the modification is for changing the code in such a way that it
> works on USRP2 since the original version is written for USRP. The
> rest is the same. Also it does't seem this is a programming bug since,
> it works for some time and then it crashes.
>
> Rahman
>
> O
What happens when you exit the program, and then go back in, does it
recover?

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

Re: [Discuss-gnuradio] thread safety of gr_wavfile_sink::close()

On Fri, Apr 30, 2010 at 08:48:48PM -0400, Don Ward wrote:
>
> ----- Original Message ----- From: "Eric Blossom" <eb@comsec.com>
> To: "Don Ward" <don2387ward@sprynet.com>
> Cc: "gnuradio mailing list" <discuss-gnuradio@gnu.org>
> Sent: Friday, April 30, 2010 8:25 PM
> Subject: Re: [Discuss-gnuradio] thread safety of gr_wavfile_sink::close()
>
>
> >On Fri, Apr 30, 2010 at 07:42:32PM -0400, Don Ward wrote:
> >>I have a question about the thread safety of
> >>gr_wavfile_sink::close(). The description says it is thread safe
> >>and it uses d_mutex, but what is to stop the work() function from
> >>writing the file at the same time that close() (via close_wav()) is
> >>writing and closing the file? gr_wavfile_sink::work() does not lock
> >>d_mutex (except when d_updated is set). Is there something going on
> >>behind the scenes to prevent the threads from mangling the output
> >>file, or is this a problem with the code?
> >>
> >>The reason I am interested is because I would like to do something
> >>similar with gr_udp_sink, allowing one socket to be closed and a new
> >>one to be created when one client finishes and another client starts
> >>up.
> >>
> >>Thanks,
> >>
> >>-- Don W.
> >
> >It looks fairly hosed up. One fundamental design/documentation
> >problem is that the header file does not document which variables must
> >be protected by the mutex. Also, proper use of the mutex (including
> >in work) would eliminate all of the code related to d_updated.
>
> So, it is ok to use the mutex across the work function?

Yes, as long as nobody who's holding it ever blocks.

> >While I'm at it, set_bits_per_sample quietly fails for any value not
> >equal to 8 or 16.
> >
> >gr_udp_sink has similar problems.
>
> Ok. Let me work on gr_udp_sink, then you can tell me how close I
> came to getting it right.
>
> -- Don W.

Thanks!
Eric


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

Re: [Discuss-gnuradio] How to compute square root?

On Fri, Apr 30, 2010 at 04:07:00AM -0700, JAS DEO wrote:
>
> Hi,
> I am doing linc transmitter by using gnu radio.In which i want to separate
> OFDM signal in two constant envelope(software part) and then power amplify
> it seprately, finally combine two signal(hardware part).I have done the
> software part in Matlab and here is the code for that.
> r=abs(normal_data);
> theta=angle(normal_data);
> %normal_data=r.*exp(i*theta);
> rmax=max(r);
> e1=j.*normal_data.*sqrt((rmax^2)./(r.^2)-1);
> s1=normal_data+e1;
> plot(s1,'b*')
> s2=normal_data-e1;
> plot(s2,'r*')
>
> Here s1 and s2 are two signals with constant envelope.As i am new to GRC, is
> it possible to compute square root, which block should i use.
> Thanks
> Regards


There is no square root block, but there are:

gr.complex_to_mag:
computes sqrt(re^2 + im^2)

gr.complex_to_mag_squared:
computes re^2 + im^2


Eric


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

Re: [Discuss-gnuradio] thread safety of gr_wavfile_sink::close()

----- Original Message -----
From: "Eric Blossom" <eb@comsec.com>
To: "Don Ward" <don2387ward@sprynet.com>
Cc: "gnuradio mailing list" <discuss-gnuradio@gnu.org>
Sent: Friday, April 30, 2010 8:25 PM
Subject: Re: [Discuss-gnuradio] thread safety of gr_wavfile_sink::close()


> On Fri, Apr 30, 2010 at 07:42:32PM -0400, Don Ward wrote:
>> I have a question about the thread safety of
>> gr_wavfile_sink::close(). The description says it is thread safe
>> and it uses d_mutex, but what is to stop the work() function from
>> writing the file at the same time that close() (via close_wav()) is
>> writing and closing the file? gr_wavfile_sink::work() does not lock
>> d_mutex (except when d_updated is set). Is there something going on
>> behind the scenes to prevent the threads from mangling the output
>> file, or is this a problem with the code?
>>
>> The reason I am interested is because I would like to do something
>> similar with gr_udp_sink, allowing one socket to be closed and a new
>> one to be created when one client finishes and another client starts
>> up.
>>
>> Thanks,
>>
>> -- Don W.
>
> It looks fairly hosed up. One fundamental design/documentation
> problem is that the header file does not document which variables must
> be protected by the mutex. Also, proper use of the mutex (including
> in work) would eliminate all of the code related to d_updated.

So, it is ok to use the mutex across the work function?

> While I'm at it, set_bits_per_sample quietly fails for any value not
> equal to 8 or 16.
>
> gr_udp_sink has similar problems.

Ok. Let me work on gr_udp_sink, then you can tell me how close I came to
getting it right.

-- Don W.

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

Re: [Discuss-gnuradio] "Failed to set frequency to ..." message in Spectrum scan

On 04/30/2010 08:17 PM, Rahman Doost wrote:
> Well, the modification is for changing the code in such a way that it
> works on USRP2 since the original version is written for USRP. The
> rest is the same. Also it does't seem this is a programming bug since,
> it works for some time and then it crashes.
>
> Rahman
>
> O
What happens when you exit the program, and then go back in, does it
recover?

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

Re: [Discuss-gnuradio] thread safety of gr_wavfile_sink::close()

On Fri, Apr 30, 2010 at 07:42:32PM -0400, Don Ward wrote:
> I have a question about the thread safety of
> gr_wavfile_sink::close(). The description says it is thread safe
> and it uses d_mutex, but what is to stop the work() function from
> writing the file at the same time that close() (via close_wav()) is
> writing and closing the file? gr_wavfile_sink::work() does not lock
> d_mutex (except when d_updated is set). Is there something going on
> behind the scenes to prevent the threads from mangling the output
> file, or is this a problem with the code?
>
> The reason I am interested is because I would like to do something
> similar with gr_udp_sink, allowing one socket to be closed and a new
> one to be created when one client finishes and another client starts
> up.
>
> Thanks,
>
> -- Don W.

It looks fairly hosed up. One fundamental design/documentation
problem is that the header file does not document which variables must
be protected by the mutex. Also, proper use of the mutex (including
in work) would eliminate all of the code related to d_updated.

While I'm at it, set_bits_per_sample quietly fails for any value not
equal to 8 or 16.

gr_udp_sink has similar problems.

Eric


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

Re: [Discuss-gnuradio] "Failed to set frequency to ..." message in Spectrum scan

Well, the modification is for changing the code in such a way that it works on USRP2 since the original version is written for USRP. The rest is the same. Also it does't seem this is a programming bug since, it works for some time and then it crashes.

Rahman

On Fri, Apr 30, 2010 at 8:06 PM, Marcus D. Leech <mleech@ripnet.com> wrote:
On 04/30/2010 08:02 PM, Rahman Doost wrote:
hello everyone,

I 'm trying to collect some samples from my spectrum sensing code running on USRP2, which is a slightly revised version of 'usrp_spectrum_sense.py'. My problem is that after some time during the scan of some band, this message appears: "Failed to set frequency to ...". For instance I let the board to sweep my band 1000 times but after 100 or more scans (it's really variable) it stops its normal operation and can't lock on a frequency anymore.
I tested this with both WBX and XCVR front-ends in 400M and 2.4G. But the problem persists. Since I need to let the USRP2 work and collect samples for quite a long period, I really need to come up with a solution. I was wondering if someone has already encountered this problem and has solved it.

Rahman
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Does the non-slightly-revised version do the same thing?



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


Re: [Discuss-gnuradio] "Failed to set frequency to ..." message in Spectrum scan

On 04/30/2010 08:02 PM, Rahman Doost wrote:
hello everyone,

I 'm trying to collect some samples from my spectrum sensing code running on USRP2, which is a slightly revised version of 'usrp_spectrum_sense.py'. My problem is that after some time during the scan of some band, this message appears: "Failed to set frequency to ...". For instance I let the board to sweep my band 1000 times but after 100 or more scans (it's really variable) it stops its normal operation and can't lock on a frequency anymore.
I tested this with both WBX and XCVR front-ends in 400M and 2.4G. But the problem persists. Since I need to let the USRP2 work and collect samples for quite a long period, I really need to come up with a solution. I was wondering if someone has already encountered this problem and has solved it.

Rahman
 
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Does the non-slightly-revised version do the same thing?



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

[Discuss-gnuradio] "Failed to set frequency to ..." message in Spectrum scan

hello everyone,

I 'm trying to collect some samples from my spectrum sensing code running on USRP2, which is a slightly revised version of 'usrp_spectrum_sense.py'. My problem is that after some time during the scan of some band, this message appears: "Failed to set frequency to ...". For instance I let the board to sweep my band 1000 times but after 100 or more scans (it's really variable) it stops its normal operation and can't lock on a frequency anymore.
I tested this with both WBX and XCVR front-ends in 400M and 2.4G. But the problem persists. Since I need to let the USRP2 work and collect samples for quite a long period, I really need to come up with a solution. I was wondering if someone has already encountered this problem and has solved it.

Rahman

[Discuss-gnuradio] thread safety of gr_wavfile_sink::close()

I have a question about the thread safety of gr_wavfile_sink::close(). The
description says it is thread safe and it uses d_mutex, but what is to stop
the work() function from writing the file at the same time that close() (via
close_wav()) is writing and closing the file? gr_wavfile_sink::work() does
not lock d_mutex (except when d_updated is set). Is there something going
on behind the scenes to prevent the threads from mangling the output file,
or is this a problem with the code?

The reason I am interested is because I would like to do something similar
with gr_udp_sink, allowing one socket to be closed and a new one to be
created when one client finishes and another client starts up.

Thanks,

-- Don W.

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

[Discuss-gnuradio] Resource busy Error

My program: usrp_wbfm_receive.grc was working fine. Now there seems to be a problem with Ubuntu L

 

When I now run usrp_wbfm_receive.grc, I get the following error:

 

Audio_alsa_sink[hw0:0]: Device or resource busy

 

How do I find out what software is using the resource ??

 

Bill

Re: [Discuss-gnuradio] Resource busy Error

On 30 April 2010 23:28, William Pretty Security Inc
<bill.pretty@xplornet.com> wrote:
> My program: usrp_wbfm_receive.grc was working fine. Now there seems to be a
> problem with Ubuntu L
>
> When I now run usrp_wbfm_receive.grc, I get the following error:
>
> Audio_alsa_sink[hw0:0]: Device or resource busy
>
> How do I find out what software is using the resource ??

In Ubuntu you can click on the volume control icon in the notification
area, select Sound Preferences, then the Applications tab.
Alternatively you can type "lsof /dev/snd/pcmC* " in the terminal

Alex


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

[Discuss-gnuradio] [ANN] Bitshark USRP RX daughterboards now available

Epiq Solutions is pleased to announce that the first production of the Bitshark
USRP RX (BURX) daughterboard has been completed. The BURX daughterboard is a
broadband RF receiver that is capable of tuning from 300 MHz to 4 GHz,
providing up to 50 MHz of RF bandwidth. It plugs into either the USRP
or the USRP2, just like any other daughterboard. Additional details
of this board (and other members of the Bitshark family) can be found
here:

http://www.epiq-solutions.com/products_overview.php

We are now accepting credit card orders for the BURX board through our
website, and expect to start shipping boards by 5/7. To place an
order, follow the "Add to Cart" link on the BURX product page:

http://www.epiq-solutions.com/product_detail.php?line=Bitshark&product=Bitshark%20USRP

Initial quantities of this board are limited. For all the folks that
placed a pre-order with us, we will hold your boards for 15
days (until 5/14), after which they'll be released into the publicly
available pool of boards.

The GPL version of the BURX driver for both the USRP and the USRP2 is
expected to be
part of the GNU Radio 3.3 official release, but until then, we've set
up a git repository at github with driver support for the BURX board
added in. This repo can be cloned with the following command:

git clone git://github.com/JohnOrlando/gnuradio-bitshark.git

Then perform the standard bootstrap/configure/make/sudo make install, and you
should be all set.

Additional documentation for the BURX board will be made available in
the coming weeks on
the BURX product page, so stay tuned.

--
Regards,
John Orlando
CEO/System Architect
Epiq Solutions
www.epiq-solutions.com


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

Re: [Discuss-gnuradio] How to set up MP-Benchmark Test PowerPC Processors (using Altivec)

On Fri, Apr 30, 2010 at 09:08:59AM +0200, matty wrote:
> I want to set up several Benchmark Tests for PowerPC Processors using
> Altivec.
> The MP-Scheduler Benchmark works for Core2 Duo and on PS3 (without Altivec)
> fine.
>
> But how can i set up the Benchmark for PowerPC Processors (e.g. Cell BE)
> using the Altivec Extensions?
> There are no options given to use Altivec, or is there a special
> benchmark-code?

I'm pretty sure that it uses Altivec by default on PPC. (The only
hand coded Altivec code is in the gr_fir_fff filter.)

Do your results look like this:

http://gnuradio.org/images/perf-data-images/ps3-altivec.png

or like this:

http://gnuradio.org/images/perf-data-images/ps3.png

The PPC on the Cell is seriously lame, as you have no doubt found out
by now...

Eric

The relevant wiki page (needs some formatting cleanup)
http://gnuradio.org/redmine/wiki/gnuradio/MPSchedulerPerformance


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

Re: [Discuss-gnuradio] Re: UHD: uhd_find_devices

Thanks for bringing that up, i should have sent the link as well:

http://www.ettus.com/uhd_docs/manual/html/usrp2.html#setup-networking

-Josh


> How does the USRP2 get its IP address, how do you deal with multiple
> USRP2 on the same
> host? With IP routing, you'll generally need to have each USRP2/Host
> combination have its
> own (probably very small) subnet, but you *do* have to get the routing
> correct!
>
> When you throw an IP packet "into the stack", the IP routing machinery
> in the stack figures out
> which interface to send the packet on, based on the subnet mask
> assigned to an interface.
> So you need to make sure that your USRP2 has a distinct subnet
> assigned, so that it
> can be routed to appropriately.
>

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

Re: [Discuss-gnuradio] Re: UHD: uhd_find_devices

On 04/30/2010 11:07 AM, Josh Blum wrote:
>
>
> I know you got me off-list, but I would like to share the answer
> because people tend to google these things and get list postings:
>
> The solution was to set a static IP address on the network interface.
> Its not like the raw ethernet communication where sometimes you needed
> a static ip to make a particular interface work. You always need the
> static IP address to send and receive the UDP packets.
>
> Also, you should not need the sudo. uhd_find_devices works fine as
> normal user.
>
> And a little trivia for today: The "F" LED on the USRP2 is actually
> light (faintly).
>
> -Josh
>
>
How does the USRP2 get its IP address, how do you deal with multiple
USRP2 on the same
host? With IP routing, you'll generally need to have each USRP2/Host
combination have its
own (probably very small) subnet, but you *do* have to get the routing
correct!

When you throw an IP packet "into the stack", the IP routing machinery
in the stack figures out
which interface to send the packet on, based on the subnet mask
assigned to an interface.
So you need to make sure that your USRP2 has a distinct subnet
assigned, so that it
can be routed to appropriately.

--
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] Re: UHD: uhd_find_devices

On 04/30/2010 06:53 AM, Per Zetterberg wrote:
> Hi,
>
> I have finally compiled the uhd library. When I do "sudo
> ./uhd_find_devices" I get "No UHD Devices Found". I have turned off the
> firewall. I have loaded the firmware unto the SD card. When I turn on
> the power of the USRP2 first all leds on the front are lit and then only
> "D" is on.

I know you got me off-list, but I would like to share the answer because
people tend to google these things and get list postings:

The solution was to set a static IP address on the network interface.
Its not like the raw ethernet communication where sometimes you needed a
static ip to make a particular interface work. You always need the
static IP address to send and receive the UDP packets.

Also, you should not need the sudo. uhd_find_devices works fine as
normal user.

And a little trivia for today: The "F" LED on the USRP2 is actually
light (faintly).

-Josh


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

[Discuss-gnuradio] UHD: uhd_find_devices

Hi,

I have finally compiled the uhd library. When I do "sudo
./uhd_find_devices" I get "No UHD Devices Found". I have turned off the
firewall. I have loaded the firmware unto the SD card. When I turn on
the power of the USRP2 first all leds on the front are lit and then
only "D" is on.

I have no idea what to do.

BR/
Per

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

[Discuss-gnuradio] How to compute square root?

Hi,
I am doing linc transmitter by using gnu radio.In which i want to separate
OFDM signal in two constant envelope(software part) and then power amplify
it seprately, finally combine two signal(hardware part).I have done the
software part in Matlab and here is the code for that.
r=abs(normal_data);
theta=angle(normal_data);
%normal_data=r.*exp(i*theta);
rmax=max(r);
e1=j.*normal_data.*sqrt((rmax^2)./(r.^2)-1);
s1=normal_data+e1;
plot(s1,'b*')
s2=normal_data-e1;
plot(s2,'r*')

Here s1 and s2 are two signals with constant envelope.As i am new to GRC, is
it possible to compute square root, which block should i use.
Thanks
Regards

--
View this message in context: http://old.nabble.com/How-to-compute-square-root--tp28384288p28384288.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] How to synchronize feedback between blocks?

i remember the gr-fsk4 demodulator uses the message queue to send frequency correction info to a pre-demod freq-xlating filter.
Check out the code here maybe it will help http://7120804464424340617-a-1802744773732722657-s-sites.googlegroups.com/site/radiorausch/GnuradioFourLevelFSK.html

Sent from my iPhone

On Apr 30, 2010, at 3:35 AM, Martin Braun <martin.braun@kit.edu> wrote:

Thanks Matt, and Michael, for your input.

To clarify: I was thinking about a frequency offset detection at a later
stage in the demodulation process, which feeds back the frequency offset
to an initial xlating FIR filter (I do realise feeding back individual
samples is kind of ridiculous from a scheduling POV).

Another question: will the message interface be able to send messages
"backwards" in the flow graph?

Thanks
MB


On Thu, Apr 29, 2010 at 09:07:27AM -0700, Matt Ettus wrote:
y(n) = x(n) + x(n-2)

This is easy and already supported in GNU Radio, since it is not
feedback. Perhaps you meant:

y(n) = x(n) + y(n-1)

Which would be feedback, and is not currently supported. You can,
of course, do it *within* a block, like our IIR filter blocks.


My question is: can GNU Radio be modified to accept this? It's a
perfectly valid flow graph (similar to ones you find in DSP textbooks),
and thanks to the history of the delays, one that should work. I'd be
very interested to hear some comments on this.

Cheers
MB


Assuming you meant the feedback version I mentioned above, the
current GNU Radio scheduler does not allow this. The changes to
support it would be significant, but not impossible. Eric would be
better positioned to explain it, but here is my take on it.

First, you would need to be able to communicate the amount of delay
to the scheduler, so it could insert leading zeros for time when it
does not have feedback values. This is because the adder would not
have its own previous output in order to produce its first input.

Second, you would need to check for deadlock. If you were to put
variable rate blocks in the loop, you could end up with deadlock.

Third, blocks in GNU Radio usually take large blocks of input and
produce large blocks of output. If you were to do your block like
above, you could only produce 1 output per call, which would result
in very high overhead and poor performance.

--
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-3790
Fax: +49 721 608-6071
www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
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] How to synchronize feedback between blocks?

Thanks Matt, and Michael, for your input.

To clarify: I was thinking about a frequency offset detection at a later
stage in the demodulation process, which feeds back the frequency offset
to an initial xlating FIR filter (I do realise feeding back individual
samples is kind of ridiculous from a scheduling POV).

Another question: will the message interface be able to send messages
"backwards" in the flow graph?

Thanks
MB


On Thu, Apr 29, 2010 at 09:07:27AM -0700, Matt Ettus wrote:
> >y(n) = x(n) + x(n-2)
>
> This is easy and already supported in GNU Radio, since it is not
> feedback. Perhaps you meant:
>
> y(n) = x(n) + y(n-1)
>
> Which would be feedback, and is not currently supported. You can,
> of course, do it *within* a block, like our IIR filter blocks.
>
> >
> >My question is: can GNU Radio be modified to accept this? It's a
> >perfectly valid flow graph (similar to ones you find in DSP textbooks),
> >and thanks to the history of the delays, one that should work. I'd be
> >very interested to hear some comments on this.
> >
> >Cheers
> >MB
>
>
> Assuming you meant the feedback version I mentioned above, the
> current GNU Radio scheduler does not allow this. The changes to
> support it would be significant, but not impossible. Eric would be
> better positioned to explain it, but here is my take on it.
>
> First, you would need to be able to communicate the amount of delay
> to the scheduler, so it could insert leading zeros for time when it
> does not have feedback values. This is because the adder would not
> have its own previous output in order to produce its first input.
>
> Second, you would need to check for deadlock. If you were to put
> variable rate blocks in the loop, you could end up with deadlock.
>
> Third, blocks in GNU Radio usually take large blocks of input and
> produce large blocks of output. If you were to do your block like
> above, you could only produce 1 output per call, which would result
> in very high overhead and poor performance.

--
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-3790
Fax: +49 721 608-6071
www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

[Discuss-gnuradio] How to set up MP-Benchmark Test PowerPC Processors (using Altivec)

I want to set up several Benchmark Tests for PowerPC Processors using Altivec.
The MP-Scheduler Benchmark works for Core2 Duo and on PS3 (without Altivec) fine.

But how can i set up the Benchmark for PowerPC Processors (e.g. Cell BE) using the Altivec Extensions?
There are no options given to use Altivec, or is there a special benchmark-code?

Best regards
Matthias

Thursday, April 29, 2010

[Discuss-gnuradio] removal of mblock and inband code

I noticed this in a recent commit:

> commit ac2b84b93cad94f9a8830eeb5e62dace997c9a47
> Author: Johnathan Corgan <jcorgan@corganenterprises.com>
> Date: Mon Apr 26 22:41:19 2010 -0700
>
> Remove mblock library. We hardly knew 'ye.


This commit removes all mblock and inband code.

Is a new message passing interface usable with usrp-1 in place yet?

I was just working on getting the inband code working again to be able
to do timestamped rx and tx on usrp-1?

Martin


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

Re: [Discuss-gnuradio] USRP1 Inband rework, request for features and comments

On Tue, 2010-02-16 at 15:43 -0700, Eric Schneider wrote:
> Hi George, no worries, I know perfectly well how it is to have too many
> ambitions and too little time... :-)
>
> I can confirm that the timestamps are correct. I have been using it for
> some time.
>
> The compiled RBF is not in my developer branch. I haven't even moved my
> recent work to git... :-/

I am trying to find a working version of the inband code.

Where can we find your work.
The last I could find is at:
http://nyquist.gnuradio.org/svn/gnuradio/branches/developers/ets/inband/

But that shows no activity for a long long time.

I also tried to checkout your personal git and get the inband branch:

git clone http://gnuradio.org/git/ets.git
git checkout --track -b inband origin/inband
git fetch

But that has the inband example C++ apps and libs code moved to
usrp/limbo (in other words, disabled, nonfunctional)


>
> There are some older (but should be functional) versions at:
> http://www.schneider-group.com/gnuradio/
Those are only the rbfs

Thanks,

Martin

> The only recent changes I have made were related to debugging
> dropped/late tx packets due to host latency (I echo the tag fields from
> tx to rx).
>
> I have had some inquiries regarding the ability of the tx chain to use
> lower clock rates ( <48M, the xfer rate to the FX2). Apparently others
> have had problems with that setup. I will investigate this sometime in
> the "near" future.
>
> I will also try to put together some tests to fully exercise the inband
> functionality. Please recommend any tests you would like to see.
>
> --Eric
>
> On Tue, 2010-02-16 at 14:42 -0500, George Nychis wrote:
> > Hi Eric,
> >
> > Sorry for the late response here, I've been wrapped up in so many
> > things.
> >
> > Is your latest compiled RBF in your developer branch? There are
> > several people I know (some that I CC'ed) that are interested in using
> > the inband code.
> >
> > Last I checked, the timestamp had an issue of "jumping" which I know
> > you tried to fix. Last time I tried your branch, I'm not sure it was
> > working yet. Have you confirmed that timestamps to the host are not
> > jumping in any manner when there is no overrun, and have you confirmed
> > that timestamps are being treated properly when trying to transmit?
> >
> > Thanks a bunch for updating this code.
> >
> > - George
> >
> >
> > On Tue, Jan 26, 2010 at 5:32 AM, Per Zetterberg
> > <per.zetterberg@ee.kth.se> wrote:
> >
> > Eric Schneider wrote:
> > Hi all, I'm looking to be doing some more rework of
> > the USRP1 inband
> > code, specifically to align with the USRP2 VRT work.
> >
> > For those not familiar, USRP1 inband allows for
> > timestamped rx/tx
> > samples (and commands), which is very useful for TDMA
> > type systems. It
> > is a separate FPGA configuration and host side
> > interface.
> > Has anyone besides me used the current inband FPGA?
> >
> > I'm not sure who on this list is interested in such a
> > thing, but if you
> > have specific needs you want addressed, speak up now!
> >
> > A few notes on my current thinking:
> >
> > 1. I do not intent to implement VRT over USB. Only to
> > implement a VRT
> > compatible interface on the host. The USB inband
> > protocol will simply
> > serve to make that possible in the most efficient way
> > possible.
> >
> > 2. I don't intend to keep the existing inband packet
> > structure. This is
> > one area where interested parties really need to
> > provide feedback as to
> > supported (or supportable) feature sets.
> >
> > It is my hope that the new inband Verilog modules can
> > be used by other
> > custom FPGA builds as a standard host interface.
> >
> > For example, it has just recently occurred to me that
> > the FPGA side
> > could be made more efficient by the use of trailer
> > metadata rather than
> > headers. Since the USB packets are fixed size, I
> > don't really see a
> > downside.
> >
> > There are also fields in the current inband packet
> > that are either
> > obsolete, or should be optional fields, IMO. RSSI,
> > for example.
> >
> > Do timestamps really need to be 32 bits? That allows
> > scheduling
> > transmission 33 seconds in advance on a 64MHz clock,
> > which seems
> > excessive to me.
> >
> > Is there a reason to send timestamps in every packet
> > if samples are
> > contiguous?
> >
> > I'm leaning towards a 16 or 32 bit trailer with
> > optional, per packet,
> > meta data. Less than 16 bit alignment of trailer/meta
> > would fragment
> > individual (16 bit) samples, and 32 bits would keep
> > I/Q interleaving
> > order constant between packets. I am open to
> > entertaining the idea of
> > tiny (8 bit?) trailers, so long as we can reliably
> > detect and recover
> > from buffer overruns and such.
> >
> > --ETS
> >
> >
> >
> >
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> > Sounds great!!
> >
> > It would also be nice to have a "pps" input to synchronize the
> > clocks of multiple units. General purpose pins could be used.
> >
> > One feature I have always wished for is "external triggering"
> > where a USRP transmits/receives when a pin goes high. But that
> > is maybe another project.
> >
> > Good luck!
> >
> > BR/
> > Per
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > 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] find_usrps "No USRP2 found."

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkvaE2wACgkQW7aAm65EWy70MQCgtCWzjGYsXpwtKDIi+b5gEri0
g1sAoNtjxLqaZF3gaMcN7YmO8oXb1sEU
=s8LC
-----END PGP SIGNATURE-----
Jeff Brower wrote:
> U12 is the PHY. PHYs tend to run somewhat hot, so likely what you're seeing is Ok. But, with the top off, you could
> try pointing a large fan at the chip, and see what happens again from cold start. If the fan reduces the chip surface
> temperature to the point where you can hold your finger there (at least for 30 sec or so) and you still have the
> connectivity issues, then you can rule out a chip/board/heat problem.
>

The power has been disconnected for about an hour and I removed the lid,
pointed the fan at the device and powered up. find_usrps fails to see
the device although the link is up and the packets are being sent to it.
I can hold my finger on the chip for no more than 4-5s. I concluded
we're in dodgy PHY chip territory but Matt has suggested I remove the
WBX daughterboard and see if the USRP2 responds. find_usrps worked for a
few minutes but eventually fails. The unit is now being returned.

[Discuss-gnuradio] Question about XCVR2450

Hi,

We are using the Ettus XCVR2450 boards for a research project and had
a question in this regard.

We are using the XCVR in receive mode. We would like to have 2
antennas connected to the board. Moreover, we would like to switch
between the 2 antennas using a control signal (from the PC).
Specifically, the control signal (possibly just 1 bit) selects either
antenna 1 or antenna 2, and the the corresponding received signal is
passed on to the receive processing chain. Is it possible to do this
using the circuitry on the XCVR? Otherwise, what would be the best
approach for doing this?

Thanks,
Prasanth


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

Re: [Discuss-gnuradio] gr.prefs

On Thu, Apr 29, 2010 at 09:12:33AM -0700, Josh Blum wrote:
> Seems boost has something c++ based; http://www.boost.org/doc/libs/1_42_0/doc/html/program_options/overview.html#id1419894

Thanks for the link!

Eric


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

Re: [Discuss-gnuradio] Bug in waterfall window "Time scale" GUI control

On 04/29/2010 12:07 PM, Eric Blossom wrote:
> On Wed, Apr 28, 2010 at 10:37:45PM -0400, Marcus D. Leech wrote:
>
>> On 04/28/2010 09:33 PM, Johnathan Corgan wrote:
>>
>>
>> I wonder how easy it would be to tweak the "prefs" module to support
>> app-specific preferences? Hmmm.
>>
> Not sure how to handle inheritance of attributes, but you can use any
> key you like. The prefs stuff uses the standard Python ConfigParser class.
>
> Eric
>
>
>
Yup, "prefs" doesn't care what keys you use, to be sure.

I think there's a large issue here that needs to be thought about
carefully. Much of the
controllable parameters in the wx-gui blocks in particular don't have
a programmatic
interface, so there's no convenient way to set the up "in advance", etc.

Using the "prefs" mechanism is only really a partial solution.

Much thinkage required.

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

Re: [Discuss-gnuradio] find_usrps "No USRP2 found."

Steve-

> Further to my problem trying to discover the USRP2. From a cold start
> (the USRP2 was left without power since my last posts) I configure the
> GigE port using ethtool and enable TX pause frames (this seems to be
> necessary magic on my PC). I then run this at the command line:
>
> while true; do clear; find_usrps; sleep 1; done
>
> and watch the output. For the first 30 seconds or so I get the device
> MAC address then "No USRP2 found." From a real cold start this takes a
> little longer so I got as far as running usrp2_fft.py -f 925M and that
> guarantees I lose connectivity. Have removed the power and lid on the
> USRP2 and see U12 which is a large-ish package and gingerly touch it. It
> is indeed quite hot. Once the device has stopped responding even
> removing the power for a few minutes is not enough to make it functional
> so a heat-related failure of the PHY chip seems plausible. Before I go
> about requesting a return authorization is there any other diagnostic I
> can perform?
>
> Many thanks to all (especially Marcus) for your help

U12 is the PHY. PHYs tend to run somewhat hot, so likely what you're seeing is Ok. But, with the top off, you could
try pointing a large fan at the chip, and see what happens again from cold start. If the fan reduces the chip surface
temperature to the point where you can hold your finger there (at least for 30 sec or so) and you still have the
connectivity issues, then you can rule out a chip/board/heat problem.

That's not saying something else hasn't gone wrong with your board, but it might help you to obtain consistent results
between "cold start" and "warm start" and make it easier to debug.

-Jeff

>> Marcus D. Leech wrote:
>>
>>> There were a batch of bad PHY chips, and I wonder if yours is one of them.
>>>
>>> U12, a DP83865 is the Gigabit PHY. On "bad" versions of this chip,
>>> they run
>>> *really hot*. You could *gingerly* feel yours and see if it's really
>>> uncomfortably
>>> hot. If so, you likely have a bad PHY, in which case, it should be
>>> returned.
>>>
>>> They've been having occasional trouble with this PHY chip, and they pass
>>> the checks
>>> but fail sometime later.
>>>
>>>
>>
>> Although I did get find_usrps working briefly (by enabling TX pause) I
>> couldn't get any data into usrp2_fft.py.
>>
>> Repeating the steps I tried earlier just have it fail again. It is,
>> however, "forgetting" the tx pause flag - could that be a negotiation thing?
>>
>> I shall whip the cover off later and do as you suggest from a cold
>> start. If its a bad PHY then I shall make arrangements to return the USRP.
>>
>> Many thanks
>>
>> Steve
>>
>>
>>
>
> _______________________________________________
> 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] Odd situation when runnning usrp_benchmark_usb.py and usrp_probe

Hi all,

I have gnuradio 3.3 installed in my laptop hp pavilion dv7-1020us with ubuntu 9.10. I was trying to run the usrp_benchmark_usb.py with 2 RFX1800 installed and all I could get was RuntimeError: can't open usrp, so I tried to change the daughterboards to two basic TX and one basic RX and it worked ok. 

frsn@frsn-nb:~/Desktop/gnuradio/gnuradio-examples/python/usrp$ ./usrp_benchmark_usb.py 
Testing 2MB/sec... usb_throughput = 2M
ntotal    = 1000000
nright    = 998255
runlength = 998255
delta     = 1745
OK
Testing 4MB/sec... usb_throughput = 4M
ntotal    = 2000000
nright    = 1998065
runlength = 1998065
delta     = 1935
OK
Testing 8MB/sec... usb_throughput = 8M
ntotal    = 4000000
nright    = 3995207
runlength = 3995207
delta     = 4793
OK
Testing 16MB/sec... usb_throughput = 16M
ntotal    = 8000000
nright    = 7997570
runlength = 7997570
delta     = 2430
OK
Testing 32MB/sec... usb_throughput = 32M
ntotal    = 16000000
nright    = 15991890
runlength = 15991890
delta     = 8110
OK
Max USB/USRP throughput = 32MB/sec

Was I doing something wrong? The benchmark is meant to be run with the basics daughterboards or it can be run with any daughterboards? I do need to use the RFX1800 for the openBTS testing. 


I still got the same odd error. I don't know what's wrong. Now I'm trying to run usrp_probe to check the daughterboards and I got, I believe, the same error.
I have two RFX1800 daughterboards, when I plug them at the same time, none can be recognized by the usrp. I get this:

>>> Error
can't open usrp

If the USRP cannot be found, make sure that the USRP is plugged-in and restart this program. If the problem persists, there may be a problem with you gnuradio installation or USB 2.0.

But if I unplug any of them I can read the results normally:

>>> USRP Probe

Name:
Flex 1800 Rx MIMO B

Converter Rate:
64000000

Uses Quadrature:
True

Gain Range (min, max, step size):
0.0
90.0
0.0500000007451

Freq Range (min, max, step size):
1500000000.0
2100000000.0
1


Does anyone have a clue of what could cause this?


Thanks in advance for any answer,

Fernando Rodrigues

Re: [Discuss-gnuradio] gr.prefs

Seems boost has something c++ based;
http://www.boost.org/doc/libs/1_42_0/doc/html/program_options/overview.html#id1419894

On 04/29/2010 08:56 AM, Eric Blossom wrote:
> On Thu, Apr 29, 2010 at 03:01:51PM +0200, Martin DvH wrote:
>> On Wed, 2010-04-28 at 15:28 -0400, Marcus D. Leech wrote:
>>> Is there any kind of guide as to how gr.prefs is supposed to be used?
>>> Is this functionality going
>>> to be deprecated at any point, is there any kind of plan as to how it
>>> will be used?
>>>
>> There is not much documentation but I found out the hard way a few
>> thinks you should know.
>>
>> The format of the prefs configartion files:
>>
>> -Never ever put a comment on the same line as a setting.
>>
>> For example:
>> GOOD:
>> # default fft_rate=15
>> fft_rate=8
>>
>> BAD
>> fft_rate=8 # default fft_rate=15
>>
>> This results in a parse error for the line, and consequently the default
>> being used (in this case 15) in stead of your value (in this case 8).
>>
>> Comments should be on their own line, starting with a # with no
>> whitespace in front of the #.
>>
>> -Don't have backups of conf files (or other files) laying around in
>> (/usr/local)/etc/gnuradio/conf.d
>>
>> All files in (/usr/local)/etc/gnuradio/conf.d will be parsed.
>>
>> If you have gr-wxgui.conf and gr-wxgui.conf~ and gr-wxgui.conf.bak and
>> README.txt then all will be parsed in unknown order.
>> The last value parsed will be used.
>
> Martin, We could probably change that to only loading *.conf without
> breaking anything that matters. Feel free to fix it :-)
>
> Marcus, there's no plan to deprecate this. It's used in quite a few
> places such configuring the audio subsystem.
>
> One thing to know about it, is that it's currently dependent on python
> to implement the real functionality. Thus it won't work in C++ only
> apps (unless somebody recodes the python to C++). There's a pretty
> much empty C++ class with virtual methods that's overridden in python
> using SWIG director magic.
>
> Martin, the place to filter the list of files in
> gnuradio-core/src/python/gnuradio/gr/prefs.py, line 72.
>
>
> Eric
>
>
> _______________________________________________
> 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] How to synchronize feedback between blocks?

On 04/29/2010 08:23 AM, Martin Braun wrote:
> On Thu, Apr 29, 2010 at 12:00:33PM +0200, Martin Braun wrote:
>> However, I think there's no direct way to feed back data between blocks.
>> You need to create a feed-forward structure, i.e. have a synchronisation
>> block near the beginning that outputs the frequency offset to your
>> frequency correction.
>
> This has been bugging me for a while now, and since I sent that email, I
> just can't get it out of my head (sorry, Nick, for hijacking this
> thread).
>
> Imagine the following setup:
> http://img338.imageshack.us/img338/6418/diffequation.png
> (for those who don't want to follow the link: I connect a noise source
> to two connected delays such that they form the difference equation
>
> y(n) = x(n) + x(n-2)

This is easy and already supported in GNU Radio, since it is not
feedback. Perhaps you meant:

y(n) = x(n) + y(n-1)

Which would be feedback, and is not currently supported. You can, of
course, do it *within* a block, like our IIR filter blocks.

>
> My question is: can GNU Radio be modified to accept this? It's a
> perfectly valid flow graph (similar to ones you find in DSP textbooks),
> and thanks to the history of the delays, one that should work. I'd be
> very interested to hear some comments on this.
>
> Cheers
> MB


Assuming you meant the feedback version I mentioned above, the current
GNU Radio scheduler does not allow this. The changes to support it
would be significant, but not impossible. Eric would be better
positioned to explain it, but here is my take on it.

First, you would need to be able to communicate the amount of delay to
the scheduler, so it could insert leading zeros for time when it does
not have feedback values. This is because the adder would not have its
own previous output in order to produce its first input.

Second, you would need to check for deadlock. If you were to put
variable rate blocks in the loop, you could end up with deadlock.

Third, blocks in GNU Radio usually take large blocks of input and
produce large blocks of output. If you were to do your block like
above, you could only produce 1 output per call, which would result in
very high overhead and poor performance.


Matt


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

Re: [Discuss-gnuradio] Bug in waterfall window "Time scale" GUI control

On Wed, Apr 28, 2010 at 10:37:45PM -0400, Marcus D. Leech wrote:
> On 04/28/2010 09:33 PM, Johnathan Corgan wrote:
>
>
> I wonder how easy it would be to tweak the "prefs" module to support
> app-specific preferences? Hmmm.

Not sure how to handle inheritance of attributes, but you can use any
key you like. The prefs stuff uses the standard Python ConfigParser class.

Eric


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

Re: [Discuss-gnuradio] How to synchronize feedback between blocks?

Hi Martin -

On Apr 29, 2010, at 9:23 AM, Martin Braun wrote:
> y(n) = x(n) + x(n-2)
>
> My question is: can GNU Radio be modified to accept this? It's a
> perfectly valid flow graph (similar to ones you find in DSP
> textbooks),
> and thanks to the history of the delays, one that should work. I'd be
> very interested to hear some comments on this.

Shortest Answer: Yes, this could be done -- GNU Radio is open
source :). Go for it! I think you'll find that it's not trivial to
implement. Further: If you look at the radio of computation time
versus overhead time (one version of "computational intensity") of any
such loops -- when implemented in a data-flow block fashion such as
what GNU Radio does (and, all SDRs that I know of) -- it will be very
low compared with writing a specific block that internally handles the
feedback. So, low efficiency but allowing for feedback, or high
efficiency but no feedback ... hmm ... seems obvious which to choose
at least for the initial implementation. Maybe some future
implementation will deal with feedback loops in some special way.
Hope this helps! - MLD


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

Re: [Discuss-gnuradio] gr.prefs

On Thu, Apr 29, 2010 at 03:01:51PM +0200, Martin DvH wrote:
> On Wed, 2010-04-28 at 15:28 -0400, Marcus D. Leech wrote:
> > Is there any kind of guide as to how gr.prefs is supposed to be used?
> > Is this functionality going
> > to be deprecated at any point, is there any kind of plan as to how it
> > will be used?
> >
> There is not much documentation but I found out the hard way a few
> thinks you should know.
>
> The format of the prefs configartion files:
>
> -Never ever put a comment on the same line as a setting.
>
> For example:
> GOOD:
> # default fft_rate=15
> fft_rate=8
>
> BAD
> fft_rate=8 # default fft_rate=15
>
> This results in a parse error for the line, and consequently the default
> being used (in this case 15) in stead of your value (in this case 8).
>
> Comments should be on their own line, starting with a # with no
> whitespace in front of the #.
>
> -Don't have backups of conf files (or other files) laying around in
> (/usr/local)/etc/gnuradio/conf.d
>
> All files in (/usr/local)/etc/gnuradio/conf.d will be parsed.
>
> If you have gr-wxgui.conf and gr-wxgui.conf~ and gr-wxgui.conf.bak and
> README.txt then all will be parsed in unknown order.
> The last value parsed will be used.

Martin, We could probably change that to only loading *.conf without
breaking anything that matters. Feel free to fix it :-)

Marcus, there's no plan to deprecate this. It's used in quite a few
places such configuring the audio subsystem.

One thing to know about it, is that it's currently dependent on python
to implement the real functionality. Thus it won't work in C++ only
apps (unless somebody recodes the python to C++). There's a pretty
much empty C++ class with virtual methods that's overridden in python
using SWIG director magic.

Martin, the place to filter the list of files in
gnuradio-core/src/python/gnuradio/gr/prefs.py, line 72.


Eric


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

Re: [Discuss-gnuradio] Firmware needs to be changed?

On 04/29/2010 01:31 AM, srinivas naga vutukuri wrote:
> Hi,
>
> I have changed on my USRP2's the RF cards from RFX1800 to RFX2400
> series, to use the frequency range of RFX2400. If so, am i have to
> change the firmware also, which i was using with the RFX1800 (which is
> come by default when i bought the USRP2 boards)?. please help me out.
>
>
> best regards,
> srinivas.


Srinivas,

The standard firmware on the SD card will work with all of the RFX
series, so you do not have to change it.

In your private email to me (sent under a different name...) you implied
that you "converted" your RFX1800 to an RFX2400. That is impossible.
The RFX2400 is a completely different product. The RFX1800 may be
converted to an RFX900 and vice versa, only.

Matt

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

Re: [Discuss-gnuradio] How to synchronize feedback between blocks?

On Thu, Apr 29, 2010 at 12:00:33PM +0200, Martin Braun wrote:
> However, I think there's no direct way to feed back data between blocks.
> You need to create a feed-forward structure, i.e. have a synchronisation
> block near the beginning that outputs the frequency offset to your
> frequency correction.

This has been bugging me for a while now, and since I sent that email, I
just can't get it out of my head (sorry, Nick, for hijacking this
thread).

Imagine the following setup:
http://img338.imageshack.us/img338/6418/diffequation.png
(for those who don't want to follow the link: I connect a noise source
to two connected delays such that they form the difference equation

y(n) = x(n) + x(n-2)

My question is: can GNU Radio be modified to accept this? It's a
perfectly valid flow graph (similar to ones you find in DSP textbooks),
and thanks to the history of the delays, one that should work. I'd be
very interested to hear some comments on this.

Cheers
MB

--
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-3790
Fax: +49 721 608-6071
www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

[Discuss-gnuradio] GMSK block, again

I'm playing with the GMSK demodulator block.

I have a signal at 24KHz, which I down-shift to DC, using a
freq_xlating_fir_filter. The signal is 200baud
MSK, so the filter bandwidth I set to 400Hz, then into the GMSK block,
arranging for there to
be two samples per symbol. This seems to be producing a nice stream
of 1s and 0s at 200bps.

Since the bits are encrypted coming from the source, I have no way of
knowing whether they're the
"right" bits or not, so I want to confirm that my setup is correct for
the GMSK block. I think it
needs basebanded data, with the input spectrum arranged around DC, and
by default, it uses
2 samples per symbol.

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

Re: [Discuss-gnuradio] Regarding gr_squelch_base_cc.cc

On 04/29/2010 04:55 AM, Mattias Kjellsson wrote:
>
> 61:
> 62: case ST_UNMUTED:
> 63: if (mute())
> 64: d_state = d_ramp ? ST_DECAY : ST_MUTED; // If not ramping,
> go straight to muted
> 65: break;
>
> It might be that I don't fully understand the "?"- construct, but if I
> try to translate line 64 into an if- statement, I would do it (with my
> understanding) to something like:
>
> if(d_state = d_ramp){
> d_state = ST_DECAY;
> }
> else{
> d_state = ST_MUTED;
> }
>
> But this can't be the way since this will always set d_state =
> ST_DECAY (?) Or it could be the way, but in that case... Why the crazy
> ?- construct?
>
> As I said earlier, I'm scared and confused, since the code does it's
> job but it looks very... Suspicious
>
> BR
> Mattias
>
>
>
Ah, conditional expressions.

Let's deal with line 64:

d_state = d_ramp ? ST_DECAY : ST_MUTED; // If not ramping, go
straight to muted

Translated into "conventional" conditionals:

if (d_ramp != 0)
{
d_state = ST_DECAY;
}
else
{
d_state = ST_MUTED;
}

In C, you can have a condition expression that just mentions the
variable name, without any explicit
comparision operator:

if (foo)
{
...
}

Which in another language would be:

if (foo not-equal 0)
{
}

So, the "?" operator isn't all that crazy after all:

(condition) ? (clause-to-execute-if-true) : (clause-to-execute-if-false)


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

Re: [Discuss-gnuradio] DQPSK Modulation/Demodulation issue

Jason Uher wrote:
>
> The code has no glaring errors that I can see, but if you suspect that
> it's the channel, what happens if you simply remove it? or replace it
> with a simulated one?
>

Yes, the graph works perfectly when i remove the channel/usrp.

i.e.

TX
Vector Source [180] > Packed To Unpacked > Mapper [Binary 2 Gray] >
Differential Encoder >
Chunks to Symbols

RX
Differential Phasor > Constellation Decoder > Mapper [Gray 2 Binary] >
Unpacked To Packed > Vector Sink

No problems here, my output is always 108.

Getting back to the USRP model, i can't seen to work out whether my
bitrates/sample rates are correct.
For instance, the interpolation of my USRP sink is set to 500, meaning it
should be accepting samples at a rate of of 256ks/s.

I've had a look at pick_bitrate.py in the examples, but here are a few more
questions:

1) Do my sample rates / interpolation / decimation look correct, according
to:
http://users.tpg.com.au/marcinw//qpskTest.py

2) Do i need to use the throttle block in my graph to control the bit rates?
, or does simply setting the interpolation on the usrp automatically control
this?

3) Would setting the interpolation of the usrp to 500, automatically set the
bit rate to 128kb/s if my graph looks like this:

Vector Source [180] > Packed To Unpacked > Mapper [Binary 2 Gray] >
Differential Encoder >
Chunks to Symbols > Interpolating FIR Filter (RRC) [samples/symbol = 2 ,
interpolation = 2 ] > USRP sink [ interp: 500]

4) Why do we even bother using an interpolating filter in the modulator
block. Why not just a RRC filter?

5) For the demodulator block, why is the decimation level on the decimating
FIR filter set to 1 and not to 2.

Regards,

Marcin

Jason Uher wrote:
>
> Ah, generated code would explain a lot.
>
> I like the 'outside in' approach when developing gnuradio graphs,
> especially for learning the system. For DQPSK I would start with just
> my vector source/sink pair and make sure the extraneous fluff worked,
> then add in the chunks-to-symbols and test, and so on. It takes about
> 20 minutes for simple graphs and you can debug single problems as they
> arise rather than all of them at once (O(n) vs O(n^2)).
>
> You can remove the USRP/channel from the equation as long as your
> samples per symbol line up for the transmitter and receiver you'll be
> fine, then you'll know.
>
>> p.s Your suggested input of [92d] actually produced the correct output
>>
>
> Interesting, what happens if you send longer than single byte vectors
> (I assume you are going to want to do that eventually anyway)
>
>
> Jason
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>

--
View this message in context: http://old.nabble.com/DQPSK-Modulation-Demodulation-issue-tp28288015p28400750.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] find_usrps "No USRP2 found."

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkvZjRUACgkQW7aAm65EWy7/hgCfQ9eEpJywUW+FLDs7IHvFa38G
7PsAn27VWF4qdkeKONeEFDdLRtvzT5Hc
=Nj7r
-----END PGP SIGNATURE-----
Hi,

Further to my problem trying to discover the USRP2. From a cold start
(the USRP2 was left without power since my last posts) I configure the
GigE port using ethtool and enable TX pause frames (this seems to be
necessary magic on my PC). I then run this at the command line:

while true; do clear; find_usrps; sleep 1; done

and watch the output. For the first 30 seconds or so I get the device
MAC address then "No USRP2 found." From a real cold start this takes a
little longer so I got as far as running usrp2_fft.py -f 925M and that
guarantees I lose connectivity. Have removed the power and lid on the
USRP2 and see U12 which is a large-ish package and gingerly touch it. It
is indeed quite hot. Once the device has stopped responding even
removing the power for a few minutes is not enough to make it functional
so a heat-related failure of the PHY chip seems plausible. Before I go
about requesting a return authorization is there any other diagnostic I
can perform?

Many thanks to all (especially Marcus) for your help

Steve


Steve Glass wrote:
> Marcus D. Leech wrote:
>
>> There were a batch of bad PHY chips, and I wonder if yours is one of them.
>>
>> U12, a DP83865 is the Gigabit PHY. On "bad" versions of this chip,
>> they run
>> *really hot*. You could *gingerly* feel yours and see if it's really
>> uncomfortably
>> hot. If so, you likely have a bad PHY, in which case, it should be
>> returned.
>>
>> They've been having occasional trouble with this PHY chip, and they pass
>> the checks
>> but fail sometime later.
>>
>>
>
> Although I did get find_usrps working briefly (by enabling TX pause) I
> couldn't get any data into usrp2_fft.py.
>
> Repeating the steps I tried earlier just have it fail again. It is,
> however, "forgetting" the tx pause flag - could that be a negotiation thing?
>
> I shall whip the cover off later and do as you suggest from a cold
> start. If its a bad PHY then I shall make arrangements to return the USRP.
>
> Many thanks
>
> Steve
>
>
>

Re: [Discuss-gnuradio] Spread Spectrum question in gnuradio

On Wed, 2010-04-28 at 11:23 -0700, Johnathan Corgan wrote:
> On Tue, Apr 27, 2010 at 21:19, John Andrews <gnu.fanz@gmail.com> wrote:
>
> > If I want to transmit a signal which is DSSS spread using BPSK. Is it
> > correct for me to first digitally spread the incoming data bits and then
> > apply BPSK before sending it to the USRP or should I first convert the
> > signal to BPSK and then multiply the output of the BPSK modulator with the
> > PN sequence although I don't know how to do it.
>
> Technically, these are equivalent. However, it is easier and uses
> less CPU to XOR your data sequence with your PN code, then send it to
> the modulator.
I think there is a difference, if you use a root raised cosine filter,
set for your datarate and roll-off factor.

I think the correct version should then be:
BPSKmod -> RRCfilter -> DSSS

Martin
>
> Johnathan
>
>
> _______________________________________________
> 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] gr.prefs

On Wed, 2010-04-28 at 15:28 -0400, Marcus D. Leech wrote:
> Is there any kind of guide as to how gr.prefs is supposed to be used?
> Is this functionality going
> to be deprecated at any point, is there any kind of plan as to how it
> will be used?
>
There is not much documentation but I found out the hard way a few
thinks you should know.

The format of the prefs configartion files:

-Never ever put a comment on the same line as a setting.

For example:
GOOD:
# default fft_rate=15
fft_rate=8

BAD
fft_rate=8 # default fft_rate=15

This results in a parse error for the line, and consequently the default
being used (in this case 15) in stead of your value (in this case 8).

Comments should be on their own line, starting with a # with no
whitespace in front of the #.

-Don't have backups of conf files (or other files) laying around in
(/usr/local)/etc/gnuradio/conf.d

All files in (/usr/local)/etc/gnuradio/conf.d will be parsed.

If you have gr-wxgui.conf and gr-wxgui.conf~ and gr-wxgui.conf.bak and
README.txt then all will be parsed in unknown order.
The last value parsed will be used.


The best way I found to find out which values are used from the prefs is
doing a grep on the whole gnuradio tree.
First find the files which use prefs

For C++ files:
grep -R "gr_prefs::singleton" *

For python files:
grep -R "gr\.prefs" *

Then look in those files for get_string, get_long, get_....

Maybe it is also possible to tweak doxygen to show all uses of gr_prefs,
I haven't tried.

To find out how to use it, just look at the current uses.
In short:
instantiate a gr_prefs singleton
in C++ gr_prefs::singleton()
in python gr.prefs()

And use one of the following methods to get your value:
get_xxxx('section_name', 'option_name', default_value_if_not_found)

Where get_xxxx is get_bool, get_double, get_long,get_string or
get_long

Martin

>

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

Re: [Discuss-gnuradio] Help Req running benchmark

On Thu, Apr 29, 2010 at 02:40, jack william <jackwilliam01@hotmail.com> wrote:

> After successfully installing gnuradio, i  ran example benchmark_ofdm.py .
> I didnt even plug the usrp's and i got:

The benchmark_ofdm.py script is a loopback test where the transmitter
is connected to a simulated channel, then to the receiver. Thus it
runs without USRPs, and is meant to see how the OFDM code operates
under various conditions of simulated frequency/timing offset and
AWGN.

> when i ran benchmark_ofdm_tx.py it said cant find usrp.

This is the actual transmitter script. It needs a USRP to run.
You'll need to run the receiver script benchmark_ofdm_rx.py with a 2nd
USRP, either on the same or a different machine, with appropriate
antennas, etc.

Johnathan


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

Re: [Discuss-gnuradio] Regarding gr_squelch_base_cc.cc

On Thu, Apr 29, 2010 at 01:55, Mattias Kjellsson <mkje@kth.se> wrote:

> 57: case ST_MUTED:
> 58: if (!mute())
> 58:    d_state = d_ramp ? ST_ATTACK : ST_UNMUTED; // If not ramping, go straight to unmuted
> 60: break;

The 'condition ? expr1 : expr2' construct is an expression that
evaluations to 'expr1' if 'condition' is true, otherwise it evaluates
to 'expr2'.

Here, 'condition' is d_ramp, 'expr1' is ST_ATTACK, and 'expr2' is ST_UNMUTED.

Thus, line 58 says:

"Assign to d_state the value of 'ST_ATTACK' if d_ramp is true,
otherwise assign to d_state the value of 'ST_UNMUTED'."

In other words, the variable d_state is the left side of an
assignment, and the right side of the assignment evaluates to either
ST_ATTACK or ST_UNMUTED, depending on whether d_ramp is true.

It may help to mentally parse line 58 with parenthesis just before
'd_ramp' and after 'ST_UNMUTED'.

Specifically, this is *not* a test of the value of d_state.

Hope this helps with your fear and confusion :-)

Johnathan


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

Re: [Discuss-gnuradio] How to synchronize feedback between blocks?

On Wed, Apr 28, 2010 at 11:29:16PM +0000, Nick Foster wrote:
> I'm struggling with what I hope isn't a naive problem regarding feedback between flowgraph blocks. I've written a simple frequency estimator for FSK signals based on the squared FFT method. Its input is an N-point FFT, created by an N-item stream-to-vector block feeding an N-bin FFT block. The output of the frequency estimator is a float value in Hz, and it is a sync_block. Therefore, the output produces samples at the original (pre-stream-to-vector) sample rate divided by N. So if my original raw sample rate is 50000, and I use a 4096-bin FFT, the output frequency estimate arrives at ~12.2 samples per second. That's fine.
>
> The problem is that I want to use the output of the frequency estimator to center the input data at baseband. With continuous streaming data, this is easy -- just use a frequency-xlating filter, and call set_center_freq() when data comes in from the frequency estimator. However, the packets I'm interested in are short, and I'd like the frequency correction to be applied at or near the start of the packet so the preamble can be detected appropriately. In order to do this, I have to be able to determine the delay it takes for feedback to come back, and that delay has to be constant. For this reason, I can't use a frequency-xlating filter, because the delay in calling set_center_freq() from the main Python loop could take any amount of time. I could write a version of the frequency-xlating filter that accepted a second stream of filter offset data at the input sample rate -- my thinking is that would make the delay a fixed number of samples. Is that assumption valid?
>
> Before I go reinventing the wheel, I'm wondering if there is a "usual" way of solving this feedback problem within the architecture of GNU Radio, or if I'm totally out in left field.

Hi Nick,

I recommend tracing the flow graph of the OFDM system. That helped me a
lot understanding how to do synchronisation in GNU Radio.

However, I think there's no direct way to feed back data between blocks.
You need to create a feed-forward structure, i.e. have a synchronisation
block near the beginning that outputs the frequency offset to your
frequency correction.

g
mb

--
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-3790
Fax: +49 721 608-6071
www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

[Discuss-gnuradio] Spectrum issues with wavfile_sink

Hi

I'm working on a stanag 4285 transmitter. To validate my work, I'm trying
to "record" my transmitter output and play it in Sigmira (a SDR that
manage Stanag 4285).As I didn't get my USRP yet, I'm using a
wavfile_sink. See my code bellow.

About my code :
self.tx=Txpath_ss(self.taille,"s",1) is performing framing and channel coding
self.mod=modulateurStanag.stanag_mod(self.interpolation,0.2,False,False,False)
is the modulator. It is very similar to the d8psk modulator that can be
found in gnuradio project. Except there is no differential coding and the
mapping is weird


I'm facing two problems:
If I run several time my code, the fft plot and waterfall will show the
expected spectrum most of the times, but in some case they show only three
frequency lines at 1k,1k8, and 2k6.
If I play my generated wavfile with Sigmira, his spectrum analyse tools
always shows the expected spectrum and the three frequency line.

What is going wrong?

Axel

#!/usr/bin/env python
##################################################
# Gnuradio Python Flow Graph
# Title: Top Block
# Generated: Thu Apr 22 17:05:02 2010
##################################################

from gnuradio import blks2
from gnuradio import gr
from gnuradio.eng_option import eng_option
from gnuradio.wxgui import fftsink2
from gnuradio.wxgui import waterfallsink2
from grc_gnuradio import wxgui as grc_wxgui
from optparse import OptionParser
import numpy
import wx
from rxpath import Rxpath_ss
from txpath import Txpath_ss
from gnuradio import stanag
import modulateurStanag
from gnuradio.gr import firdes

class top_block(grc_wxgui.top_block_gui):

def __init__(self):
grc_wxgui.top_block_gui.__init__(self, title="Top Block")


self.src_data = (0,1,1,0.................)
self.in_data = gr.vector_source_s (self.src_data)
self.sample_rate=2401
self.interpolation=8
self.taille=len(self.src_data)
######################


#####interleaving && Codage ########
self.tx=Txpath_ss(self.taille,"s",1)##
self.mod=modulateurStanag.stanag_mod(self.interpolation,0.2,False,False,False)###
(root raised filter BW= 0.2)
self.scale = gr.multiply_const_cc (0.5)
###frequency mixing#####
self.convQ=gr.complex_to_real()
self.loQ=gr.sig_source_f(self.sample_rate*self.interpolation,
gr.GR_COS_WAVE,1800.0,0.5,0)
self.mixQ=gr.multiply_ff()

self.convI=gr.complex_to_imag()
self.loI=gr.sig_source_f(self.sample_rate*self.interpolation,
gr.GR_SIN_WAVE,1800.0,0.5,0)
self.mixI=gr.multiply_ff()

self.som=gr.add_ff()

####sinks####
self.wxgui_fftsink2_0 = fftsink2.fft_sink_f(
self.GetWin(),
baseband_freq=0,
y_per_div=10,
y_divs=10,
ref_level=50,
sample_rate=19208,
fft_size=1024,
fft_rate=60,
average=False,
avg_alpha=None,
title="FFT Plot",
peak_hold=False,
)
self.Add(self.wxgui_fftsink2_0.win)
self.wxgui_waterfallsink2_0 = waterfallsink2.waterfall_sink_f(
self.GetWin(),
baseband_freq=0,
y_per_div=10,
ref_level=50,
sample_rate=19208,
fft_size=1024,
fft_rate=60,
average=False,
avg_alpha=None,
title="waterfall",
)
self.Add(self.wxgui_waterfallsink2_0.win)
self.gr_wavfile_sink_0 = gr.wavfile_sink("StanagGnu2.wav", 1, 19208, 16)
self.gr_wavfile_sink_1 = gr.wavfile_sink("1k8.wav", 1, 19208, 16)
self.sink1= gr.vector_sink_f()
self.sink2= gr.vector_sink_f()

#############################

#######Connections#################
self.connect(self.in_data,self.tx,self.mod,self.scale)#,self.demod,self.rx,self.sink3)
self.connect(self.tx,self.sink1)

self.connect(self.scale,self.convQ)
self.connect(self.convQ,(self.mixQ,0))
self.connect(self.loQ,(self.mixQ,1))

self.connect(self.scale,self.convI)
self.connect(self.convI,(self.mixI,0))
self.connect(self.loI,(self.mixI,1))


self.connect(self.mixQ,(self.som,0))
self.connect(self.mixI,(self.som,1))
self.connect(self.som,self.gr_wavfile_sink_0)

#fft#


self.connect(self.convQ,self.sink2)
self.connect(self.som,self.wxgui_fftsink2_0)
self.connect(self.som,self.wxgui_waterfallsink2_0)

def print_out(self):
print "\n 3 :", len(self.sink2.data()),max(self.sink2.data())


if __name__ == '__main__':
parser = OptionParser(option_class=eng_option, usage="%prog: [options]")
(options, args) = parser.parse_args()
tb = top_block()
tb.Run(True)
tb.print_out()


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

[Discuss-gnuradio] Help Req running benchmark

Hi,
After successfully installing gnuradio, i  ran example benchmark_ofdm.py .
I didnt even plug the usrp's and i got:

^Cok: True      pktno: 11      n_rcvd: 12      n_right: 12
0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b
0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b
0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b
0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b
how did it run.
when i ran benchmark_ofdm_tx.py it said cant find usrp.
Please explain this.
Secondly, i made out that in example benchmark_ofdm.py we have a siso ofdm transceiver.
I want to test this example using usrp's what should i do?
Cheers.


Hotmail is redefining busy with tools for the New Busy. Get more from your inbox. See how.

[Discuss-gnuradio] Re: Vector Source_Sink and Flow Control

From invoking .cpp file i meant to open a C++ source code file (*.cpp) by using any function or block (or something else lke that).


Regards,
Umair Naeem
MSc Communication Engineering
Chalmers University ot Technology, Sweden.


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

[Discuss-gnuradio] Regarding gr_squelch_base_cc.cc

Hi list,
I was looking at the gr_pwr_squelch_cc- code, and there is a thing I
just want to check the meaning of. It is not as much that I don't
believe the code works correctly, it's just that some lines of code
confuse and scare me. ;)

The lines are 59 and 64,
57: case ST_MUTED:
58: if (!mute())
58: d_state = d_ramp ? ST_ATTACK : ST_UNMUTED; // If not ramping, go
straight to unmuted
60: break;
61:
62: case ST_UNMUTED:
63: if (mute())
64: d_state = d_ramp ? ST_DECAY : ST_MUTED; // If not ramping, go
straight to muted
65: break;

It might be that I don't fully understand the "?"- construct, but if I
try to translate line 64 into an if- statement, I would do it (with my
understanding) to something like:

if(d_state = d_ramp){
d_state = ST_DECAY;
}
else{
d_state = ST_MUTED;
}

But this can't be the way since this will always set d_state = ST_DECAY
(?) Or it could be the way, but in that case... Why the crazy ?- construct?

As I said earlier, I'm scared and confused, since the code does it's job
but it looks very... Suspicious

BR
Mattias


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

[Discuss-gnuradio] Firmware needs to be changed?

Hi,

I have changed on my USRP2's the RF cards from RFX1800 to RFX2400
series, to use the frequency range of RFX2400. If so, am i have to
change the firmware also, which i was using with the RFX1800 (which is
come by default when i bought the USRP2 boards)?. please help me out.


best regards,
srinivas.


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