Monday, February 28, 2011

Re: [Discuss-gnuradio] Re: UHD Announcement - February 25rd 2011

diff --git a/gr-uhd/lib/gr_uhd_usrp_sink.cc b/gr-uhd/lib/gr_uhd_usrp_sink.cc
index 4598e54..b8b99a4 100644
--- a/gr-uhd/lib/gr_uhd_usrp_sink.cc
+++ b/gr-uhd/lib/gr_uhd_usrp_sink.cc
@@ -45,7 +45,8 @@ public:
num_channels, num_channels, io_type.size
)),
_type(io_type),
- _nchan(num_channels)
+ _nchan(num_channels),
+ _has_time_spec(_nchan > 1)
{
_dev = uhd::usrp::multi_usrp::make(device_addr);
}
@@ -172,7 +173,7 @@ public:
//send a mid-burst packet with time spec
_metadata.start_of_burst = false;
_metadata.end_of_burst = false;
- _metadata.has_time_spec = true;
+ _metadata.has_time_spec = _has_time_spec;

size_t num_sent = _dev->get_device()->send(
input_items, noutput_items, _metadata,
@@ -189,7 +190,7 @@ public:
bool start(void){
_metadata.start_of_burst = true;
_metadata.end_of_burst = false;
- _metadata.has_time_spec = true;
+ _metadata.has_time_spec = _has_time_spec;
_metadata.time_spec = get_time_now() + uhd::time_spec_t(0.01);

_dev->get_device()->send(
@@ -217,6 +218,7 @@ protected:
uhd::usrp::multi_usrp::sptr _dev;
const uhd::io_type_t _type;
size_t _nchan;
+ bool _has_time_spec;
uhd::tx_metadata_t _metadata;
double _sample_rate;
};
On 02/28/2011 08:21 AM, Feng Andrew Ge wrote:
> Josh,
>
> Thanks for sharing the information and your changes sound quite reasonable.
>
> However, it seems that your changes have introduced some bugs at the
> transmitter side. I updated my system using your new code (following
> your instructions in your Feb. 24's email titled "Re: GRC + N210 +
> RFX2200 + UHD not working"); then I ran python-based benchmark_tx.py. I
> tested two cases: in the first case, I sent packets continuously and it
> worked well; in the second case, I sent packets every second and the
> transmitter side could send only about 10~12 packets, then stopped
> sending data into USRP2 (based on observation from wireshark results).
> Both cases used 1500B for each packet and the send-buff-size was 100kB.
>

I think this is a problem in gr-uhd:
http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/lib/gr_uhd_usrp_sink.cc?h=next#n183

I am putting a time stamp into the packet. This is helpful for a
multi-channel continuous transmission, but not single channel
non-continuous.

Can you apply the diff attached and let me know if that fixes the problem?

Thanks,
-Josh

Re: [Discuss-gnuradio] Inconsistency clock + uhd

On Mon, Feb 28, 2011 at 11:18 AM, Julián David Vásquez Gutiérrez
<juvasquez88@gmail.com> wrote:
> Hello: I need to use a external clock for the openBTS project and I found an
> inconsistency. I don't know if the changes are for the UDH driver.
>
> In gnuradio:
> http://gnuradio.org/redmine/wiki/gnuradio/OpenBTSClockModifications
>
> In ettus:
> http://www.ettus.com/uhd_docs/manual/html/usrp1.html#linux-setup-udev
>
> The inconsistency is:
>
> gnuradio:
>  Move C925 to C926.
>  Move R2029 to R2030. This disables the onboard clock. R2029/R2030 is a
> 0-ohm resistor.
>
> ettus:
>  Move 0.01uF 0603 capacitor C929 to C926.
>  Move 0 ohm 0603 resistor R2029 to R2930
>

It was a typo in the Ettus/UHD documentation, answered previously here:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2011-February/000765.html

and now updated:
http://www.ettus.com/uhd_docs/manual/html/usrp1.html#external-clock-modification

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

[Discuss-gnuradio] Inconsistency clock + uhd

Hello: I need to use a external clock for the openBTS project and I found an inconsistency. I don't know if the changes are for the UDH driver.

In gnuradio: http://gnuradio.org/redmine/wiki/gnuradio/OpenBTSClockModifications

In ettus: http://www.ettus.com/uhd_docs/manual/html/usrp1.html#linux-setup-udev

The inconsistency is:

gnuradio:
 Move C925 to C926.
 Move R2029 to R2030. This disables the onboard clock. R2029/R2030 is a 0-ohm resistor.

ettus:
 Move 0.01uF 0603 capacitor C929 to C926.
 Move 0 ohm 0603 resistor R2029 to R2930

thanks. Best regards.

--
Julián David Vásquez Gutiérrez
Estudiante De Ingeniería Electrónica
UPB-Medellín

Re: [Discuss-gnuradio] How history() works in GR

On Mon, Feb 28, 2011 at 02:24:29PM +0100, Alberto Trentadue wrote:
> Hello
>
> I am trying to define a customised block and I would like to understand better how the history works.
>
> I have opened the source of gr_moving_average_XX and I saw the following statement in the constructor:
>
> @NAME@::@NAME@ (int length, @O_TYPE@ scale, int max_iter)
> : gr_sync_block ("@BASE_NAME@",
> gr_make_io_signature (1, 1, sizeof (@I_TYPE@)),
> gr_make_io_signature (1, 1, sizeof (@O_TYPE@))),
> d_length(length),
> d_scale(scale),
> d_max_iter(max_iter),
> d_new_length(length),
> d_new_scale(scale),
> d_updated(false)
> {
> set_history(length);
> }
>
> So it seems to me that GR allocates a history buffer with "length" size.
> But, later in the gr_moving_average_XX code I see the following cycle:
>
> for (int i = 0; i &lt; num_iter; i++) {
> sum += in[i+d_length-1];
> out[i] = sum * d_scale;
> sum -= in[i];
> }
>
> ...which seems to show that there is at least a buffering of "length + num_iter" input items somewhere, and num_iter
> is &gt;0 for sure.
> This has confused me a bit on how history is implemented.

Hi Alberto,

ignore the max_iter variable--it is for numerical stability and has
nothing to do with the history. Perhaps you should check other blocks
for examples.

If you set the history to 'N', this means you always have the last (N-1)
input values kept in your buffer. Take an FIR filter as example: Say it
has order N. Then you need the current sample plus the previous (N-1)
samples to calculate your output sample. So, you set history to N.

Some more notes on history():
- The first N-1 input values are set to zero
- The buffer input_items points to the oldest sample. Thus, if you have
M input_items, the total buffer length (i.e. the max index) is N+M-1.

Hope this helps...
Cheers
MB


>
> Thanks for any explanation.
>
> Alberto
>
>
> Supera i limiti: raddoppia la velocità da 10 a 20 Mega! Risparmia con Tutto Incluso: telefono + adsl 20 mega a soli 29,95 € al mese per due anni!SCONTO DI 240 EURO!http://abbonati.tiscali.it/telefono-adsl/prodotti/tc/tuttoincluso/?WT.mc_id=01fw
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

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

[Discuss-gnuradio] Re: Next Developer's Call RFC

schrieb Tom Rondeau am 2011-02-26 17:57:
> We are currently thinking 6 PM
> for central Europe, but we would like to hear back from those of you who
> are interested in joining this call to let us know your time
> availability/preferences.

This would be very fine for me in CET, not too early to get home from
work and not too late to get some sleep for next day's work ;-)

I just have to tame my headset ...

Regards

Patrick
--
Engineers motto: cheap, good, fast: choose any two
Patrick Strasser <patrick dot strasser at student dot tugraz dot at>
Student of Telemati_cs_, Techn. University Graz, Austria


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

[Discuss-gnuradio] Re: [USRP-users] UHD Announcement - February 25rd 2011

On 02/28/2011 10:02 AM, Thomas Tsou wrote:
> On Fri, Feb 25, 2011 at 8:32 PM, Josh Blum <josh@ettus.com> wrote:
>> -----------------------------------------------------------------------
>> -- re-clocking support
>> -----------------------------------------------------------------------
>> Re-clocking support has been added to the API:
>> http://www.ettus.com/uhd_docs/doxygen/html/classuhd_1_1usrp_1_1multi__usrp.html#a99254abfa5259b70a020e667eee619b9
>>
>> On a USRP1 board, you can specify usrp->set_master_clock_rate(52e6) so
>> that the driver knows to use 52MHz in its calculations. Note that this
>> does not really modify the clock rate, it just informs the driver of the
>> hardware changes.
>>
>> In contrast, when setting the clock rate on the usrp-e100, the driver
>> will dynamically reprogram the registers on the clock generator to
>> obtain the desired rate. See application notes:
>> http://www.ettus.com/uhd_docs/manual/html/usrp_e1xx.html#changing-the-master-clock-rate
>
> I've been getting the following error during make since I
> changed the clock rate. Did I brick the FPGA? I can't seem to
> find the special pass-through image anywhere.
>
> USRP-E100 clock control: VCO calibration timeout
>

If you can talk to it, then its still fine. Can you talk?

I think my wait for lock() is messed up since my 52Mhz is dead on and
its still printing that.

-josh

> Vitals:
>
> GNU C++ version 4.5.2 20101204 (prerelease); Boost_104100; UHD_003.20110226000831.77641c6
>
> Linux version 2.6.35 (balister@astro) (gcc version 4.5.2 20101026 (prerelease) (GCC) ) #1 PREEMPT Fri Nov 5 08:56:09 PDT 2010
>
> usrp_e100_fpga_compat3_feb_25.bin
>
> Thomas

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

[Discuss-gnuradio] Re: [USRP-users] UHD Announcement - February 25rd 2011

On Fri, Feb 25, 2011 at 8:32 PM, Josh Blum <josh@ettus.com> wrote:
> -----------------------------------------------------------------------
> -- re-clocking support
> -----------------------------------------------------------------------
> Re-clocking support has been added to the API:
> http://www.ettus.com/uhd_docs/doxygen/html/classuhd_1_1usrp_1_1multi__usrp.html#a99254abfa5259b70a020e667eee619b9
>
> On a USRP1 board, you can specify usrp->set_master_clock_rate(52e6) so
> that the driver knows to use 52MHz in its calculations. Note that this
> does not really modify the clock rate, it just informs the driver of the
> hardware changes.
>
> In contrast, when setting the clock rate on the usrp-e100, the driver
> will dynamically reprogram the registers on the clock generator to
> obtain the desired rate. See application notes:
> http://www.ettus.com/uhd_docs/manual/html/usrp_e1xx.html#changing-the-master-clock-rate

I've been getting the following error during make since I
changed the clock rate. Did I brick the FPGA? I can't seem to
find the special pass-through image anywhere.

USRP-E100 clock control: VCO calibration timeout

Vitals:

GNU C++ version 4.5.2 20101204 (prerelease); Boost_104100; UHD_003.20110226000831.77641c6

Linux version 2.6.35 (balister@astro) (gcc version 4.5.2 20101026 (prerelease) (GCC) ) #1 PREEMPT Fri Nov 5 08:56:09 PDT 2010

usrp_e100_fpga_compat3_feb_25.bin

Thomas

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

[Discuss-gnuradio] Re: UHD Announcement - February 25rd 2011

Further, I found that at the packet size of 1500B, the interval between
two packet transmissions must be less than about 20ms (on an intel
i5-M20 processor); otherwise, the received side couldn't not receive any
packets. This interval decreases as the packet size decreases.

Andrew

On 02/28/2011 11:21 AM, Feng Andrew Ge wrote:
> Josh,
>
> Thanks for sharing the information and your changes sound quite
> reasonable.
>
> However, it seems that your changes have introduced some bugs at the
> transmitter side. I updated my system using your new code (following
> your instructions in your Feb. 24's email titled "Re: GRC + N210 +
> RFX2200 + UHD not working"); then I ran python-based benchmark_tx.py.
> I tested two cases: in the first case, I sent packets continuously and
> it worked well; in the second case, I sent packets every second and
> the transmitter side could send only about 10~12 packets, then stopped
> sending data into USRP2 (based on observation from wireshark results).
> Both cases used 1500B for each packet and the send-buff-size was 100kB.
>
> Would you please take a look at this?
>
> Andrew
>
> ----------
>
> Message: 3
> Date: Sat, 26 Feb 2011 16:19:06 -0500
> From: Feng Andrew Ge<gefengflorry@gmail.com>
> Subject: [Discuss-gnuradio] Re: UHD Announcement - February 25rd 2011
> To:discuss-gnuradio@gnu.org
> Message-ID:<4D696E4A.9050404@gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Josh,
>
> When you say "2x" performance increase, do you mean CPU performance or
> send()/recv() latency? Do you mind saying a few words on what changes
> you have made?
>
> Andrew
>
> ---------------
>
> Much of the performance gains involved removing things out of the
> fast-path that only needed to be called once at initialization (forgoing
> code simplicity for performance). Example: a vector of pointers, a bound
> callable object; many of which had calls to malloc and free which incurs
> quite a lot of unnecessary overhead.
>
> Less cpu cycles/less time are spent in the send()/recv() calls. This
> roughly worked out to about half the CPU usage when looking at oprofile.
> Because of this, the overall latency is reduced. We measured about 250us
> RTT from device to host and back to device with the latency measurement
> app in uhd examples.
>
> -josh
>
>


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

[Discuss-gnuradio] Re: [USRP-users] Synchronizing multiple USRPs

On 02/27/2011 11:48 PM, Khalid Jamil wrote:
> Hello,
>
> I have eight (08) USRP N210s that has been synchronized using 10MHZ and
> 1PPS reference. I am receiving data from them using a gigabit ethernet
> switch to my computer.
>
> My question is when I will receive packets from all of them through a
> single switch, how will I know the time reference for each sample?

The packets are all time stamped, and the UHD takes care of
synchronizing everything, so you don't need to do anything special.

In the future, you don't need to post to both gnuradio and usrp-users.
Please choose the one which fits your question better.

Thanks,
Matt

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

[Discuss-gnuradio] Re: UHD Announcement - February 25rd 2011

Josh,

Thanks for sharing the information and your changes sound quite reasonable.

However, it seems that your changes have introduced some bugs at the
transmitter side. I updated my system using your new code (following
your instructions in your Feb. 24's email titled "Re: GRC + N210 +
RFX2200 + UHD not working"); then I ran python-based benchmark_tx.py. I
tested two cases: in the first case, I sent packets continuously and it
worked well; in the second case, I sent packets every second and the
transmitter side could send only about 10~12 packets, then stopped
sending data into USRP2 (based on observation from wireshark results).
Both cases used 1500B for each packet and the send-buff-size was 100kB.

Would you please take a look at this?

Andrew

----------

Message: 3
Date: Sat, 26 Feb 2011 16:19:06 -0500
From: Feng Andrew Ge<gefengflorry@gmail.com>
Subject: [Discuss-gnuradio] Re: UHD Announcement - February 25rd 2011
To:discuss-gnuradio@gnu.org
Message-ID:<4D696E4A.9050404@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Josh,

When you say "2x" performance increase, do you mean CPU performance or
send()/recv() latency? Do you mind saying a few words on what changes
you have made?

Andrew

---------------

Much of the performance gains involved removing things out of the
fast-path that only needed to be called once at initialization (forgoing
code simplicity for performance). Example: a vector of pointers, a bound
callable object; many of which had calls to malloc and free which incurs
quite a lot of unnecessary overhead.

Less cpu cycles/less time are spent in the send()/recv() calls. This
roughly worked out to about half the CPU usage when looking at oprofile.
Because of this, the overall latency is reduced. We measured about 250us
RTT from device to host and back to device with the latency measurement
app in uhd examples.

-josh

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

[Discuss-gnuradio] Any approach can reconfigure parameters for top_block while it's running

begin:vcard
n:;
adr:;;;;;;
version:2.1
end:vcard
begin:vcard
n:;
adr:;;;;;;
version:2.1
end:vcard
Dear all,

I'm wondering is there any approach can reconfigure the parameters for top_block while it is running. I've seen a video on Youtube that implemented the tuning frequency hopping, which is named "A program written for the GNU Radio that changes the TX frequency of the USRP". This video shows the parameters of the top_block are reconfigurable while it is running, and I really desire to know how to reconfigure these parameters passed through the main() to top_block while the top_block has already start working. Your help will be fairly high weighed for me, since this is the last step of my project. Really appreciate!

Thanks,
Yan

[Discuss-gnuradio] Any approach can reconfigure parameters for top_block while it's running

begin:vcard
n:;
adr:;;;;;;
version:2.1
end:vcard
Dear all,

I'm wondering is there any approach can reconfigure the parameters for top_block while it is running. I've seen a video on Youtube that implemented the tuning frequency hopping, which is named "A program written for the GNU Radio that changes the TX frequency of the USRP". This video shows the parameters of the top_block are reconfigurable while it is running, and I really desire to know how to reconfigure these parameters passed through the main() to top_block while the top_block has already start working. Your help will be fairly high weighed for me, since this is the last step of my project. Really appreciate!

Thanks,
Yan

Re: [Discuss-gnuradio] Doubt about FPGA code and firmware

I have to do almost the same thing.  But me, I have to bypass the data from the ADC by the mictor connector to a board from Xilinx, a ML401.  All the filter for equalizers or other types should be done in this one and the data go back in the usrp2 by the mictor connector again.
 
Gabriel
----- Original Message -----
Sent: Monday, February 28, 2011 10:10 AM
Subject: Re: [Discuss-gnuradio] Doubt about FPGA code and firmware

Hello,

Sorry for answering so late.

@Gabriel Morel

For my Master Thesis I had to implement a kind of test bench for different versions of a particular block. Nothing really complex, multiplexers, filters, etc. The point is I must use the USRP2 board.

@Matthias Wilhelm

Could I ask why you recommend me the use of the UHD code instead of the GNU Radio code?

Thanks!

Eduardo.

2011/2/14 Matt Ettus <matt@ettus.com>
On 02/14/2011 06:09 AM, Eduardo Lloret Fuentes wrote:
> Hello,
>
> @Nick Foster
>
>     If your FPGA design doesn't include a Microblaze processor to do
>     something useful with the firmware image, you won't need to load the
>     firmware.
>
>
> My FPGA design doesn't include a Microblaze processor so I also think
> that I don't need it. My doubt comes from the boot sequence that I read
> in the USRP2GenFAQ section:
> http://gnuradio.org/redmine/wiki/gnuradio/USRP2GenFAQ#How-does-the-USRP2-boot-How-is-the-FPGA-firmware-loaded
>
> If I don't have a processor, the second step is not necessary but I
> don't know if the first (loading of FPGA design) is accomplished
> properly. What do you think?

The first step will work fine without the microblaze.  You will need to
make sure you keep triggering the watchdog timer to make sure nothing is
reset.  See the config page of the schematics to see how this works.

Matt


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

Re: [Discuss-gnuradio] Doubt about FPGA code and firmware

Hello,

Sorry for answering so late.

@Gabriel Morel

For my Master Thesis I had to implement a kind of test bench for different versions of a particular block. Nothing really complex, multiplexers, filters, etc. The point is I must use the USRP2 board.

@Matthias Wilhelm

Could I ask why you recommend me the use of the UHD code instead of the GNU Radio code?

Thanks!

Eduardo.

2011/2/14 Matt Ettus <matt@ettus.com>
On 02/14/2011 06:09 AM, Eduardo Lloret Fuentes wrote:
> Hello,
>
> @Nick Foster
>
>     If your FPGA design doesn't include a Microblaze processor to do
>     something useful with the firmware image, you won't need to load the
>     firmware.
>
>
> My FPGA design doesn't include a Microblaze processor so I also think
> that I don't need it. My doubt comes from the boot sequence that I read
> in the USRP2GenFAQ section:
> http://gnuradio.org/redmine/wiki/gnuradio/USRP2GenFAQ#How-does-the-USRP2-boot-How-is-the-FPGA-firmware-loaded
>
> If I don't have a processor, the second step is not necessary but I
> don't know if the first (loading of FPGA design) is accomplished
> properly. What do you think?

The first step will work fine without the microblaze.  You will need to
make sure you keep triggering the watchdog timer to make sure nothing is
reset.  See the config page of the schematics to see how this works.

Matt

Re: [Discuss-gnuradio] python versions

OK. I'll only test stuff down to 2.5 then.

On Mon, Feb 28, 2011 at 5:14 AM, Tom Rondeau <trondeau1122@gmail.com> wrote:
> On Mon, Feb 28, 2011 at 3:37 AM, Josh Blum <josh@joshknows.com> wrote:
>>
>> FYI, grc only works with 2.5 and up. Ive only tested up to 2.7
>>
>> -Josh
>
> Yes, Josh is right, I just looked to refresh my memory. GRC makes a check
> for Python >= 2.5. The rest of GNU Radio doesn't check for a specific
> version, just that certain properties are met and modules are available (ala
> config/gr_python.m4).
> Tom
>
>>
>> On 02/27/2011 09:43 PM, Ben Reynwar wrote:
>> > I just tested the next branch with 2.4 and the only incompatibility
>> > was  a "with" statement in gr_xmlrunner.py.
>> > The "with" statement was introduced in 2.5.
>> >
>> > Once that was removed the "make check" ran fine.
>> >
>> > The replacement for the "with" statement was:
>> >
>> > fss = _fake_std_streams()
>> > fss.__enter__()
>> > try:
>> >     test(result)
>> >     try:
>> >         out_s = sys.stdout.getvalue()
>> >     except AttributeError:
>> >         out_s = ""
>> >     try:
>> >         err_s = sys.stderr.getvalue()
>> >     except AttributeError:
>> >         err_s = ""
>> > finally:
>> >     fss.__exit__(None, None, None)
>> >
>> > On Wed, Feb 23, 2011 at 6:20 PM, Tom Rondeau <trondeau1122@gmail.com>
>> > wrote:
>> >> On Wed, Feb 23, 2011 at 1:28 PM, Ben Reynwar <ben@reynwar.net> wrote:
>> >>> What are the oldest and newest versions of python that gnuradio should
>> >>> work with?
>> >>>
>> >>> That way I can test stuff using those two versions.
>> >>
>> >>
>> >> Python 2.4 is the oldest that I _know_ will work (and I don't think,
>> >> but haven't tried, 2.3), and I've used it with 2.7. It will not work
>> >> with 3.+.
>> >>
>> >> 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 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] gr_remez insufficient extremals

Hello,

Until last week I was using the Gnu Radio 3.2.2 (which is ready for use in ubuntu), then I decided to try the latest version (v3.3.1git-147-g5a23954a). The flowgraph was working perfectly. It's for "in" GRC simulation only. I know it's very simple and the 38kHz recovery (at the receiver) is not the recommended way.


The messages that are now shown are:

Showing: "/home/mula/Dropbox/Public/FMstereotxrx2.grc"

Generating: "/home/mula/Dropbox/Public/top_block.py"

Executing: "/home/mula/Dropbox/Public/top_block.py"

gr_remez: insufficient extremals -- cannot continue
Traceback (most recent call last):
  File "/home/mula/Dropbox/Public/top_block.py", line 361, in <module>
    tb = top_block()
  File "/home/mula/Dropbox/Public/top_block.py", line 193, in __init__
    tau=tau,
  File "/usr/local/lib/python2.6/dist-packages/gnuradio/blks2impl/fm_demod.py", line 65, in __init__
    60)   # Stopband attenuation
  File "/usr/local/lib/python2.6/dist-packages/gnuradio/optfir.py", line 53, in low_pass
    taps = gr.remez (n + nextra_taps, fo, ao, w, "bandpass")
  File "/usr/local/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_swig_py_general.py", line 432, in remez
    return _gnuradio_swig_py_general.remez(*args, **kwargs)
RuntimeError: gr_remez: insufficient extremals -- cannot continue

>>> Done

Thanks!

Regards,
Bernardo

[Discuss-gnuradio] How history() works in GR

Hello

I am trying to define a customised block and I would like to understand better how the history works.

I have opened the source of gr_moving_average_XX and I saw the following statement in the constructor:

@NAME@::@NAME@ (int length, @O_TYPE@ scale, int max_iter)
: gr_sync_block ("@BASE_NAME@",
gr_make_io_signature (1, 1, sizeof (@I_TYPE@)),
gr_make_io_signature (1, 1, sizeof (@O_TYPE@))),
d_length(length),
d_scale(scale),
d_max_iter(max_iter),
d_new_length(length),
d_new_scale(scale),
d_updated(false)
{
set_history(length);
}

So it seems to me that GR allocates a history buffer with "length" size.
But, later in the gr_moving_average_XX code I see the following cycle:

for (int i = 0; i &lt; num_iter; i++) {
sum += in[i+d_length-1];
out[i] = sum * d_scale;
sum -= in[i];
}

...which seems to show that there is at least a buffering of "length + num_iter" input items somewhere, and num_iter
is &gt;0 for sure.
This has confused me a bit on how history is implemented.

Thanks for any explanation.

Alberto


Supera i limiti: raddoppia la velocità da 10 a 20 Mega! Risparmia con Tutto Incluso: telefono + adsl 20 mega a soli 29,95 € al mese per due anni!SCONTO DI 240 EURO!http://abbonati.tiscali.it/telefono-adsl/prodotti/tc/tuttoincluso/?WT.mc_id=01fw

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

Re: [Discuss-gnuradio] python versions

On Mon, Feb 28, 2011 at 3:37 AM, Josh Blum <josh@joshknows.com> wrote:
FYI, grc only works with 2.5 and up. Ive only tested up to 2.7

-Josh


Yes, Josh is right, I just looked to refresh my memory. GRC makes a check for Python >= 2.5. The rest of GNU Radio doesn't check for a specific version, just that certain properties are met and modules are available (ala config/gr_python.m4).

Tom

 
On 02/27/2011 09:43 PM, Ben Reynwar wrote:
> I just tested the next branch with 2.4 and the only incompatibility
> was  a "with" statement in gr_xmlrunner.py.
> The "with" statement was introduced in 2.5.
>
> Once that was removed the "make check" ran fine.
>
> The replacement for the "with" statement was:
>
> fss = _fake_std_streams()
> fss.__enter__()
> try:
>     test(result)
>     try:
>         out_s = sys.stdout.getvalue()
>     except AttributeError:
>         out_s = ""
>     try:
>         err_s = sys.stderr.getvalue()
>     except AttributeError:
>         err_s = ""
> finally:
>     fss.__exit__(None, None, None)
>
> On Wed, Feb 23, 2011 at 6:20 PM, Tom Rondeau <trondeau1122@gmail.com> wrote:
>> On Wed, Feb 23, 2011 at 1:28 PM, Ben Reynwar <ben@reynwar.net> wrote:
>>> What are the oldest and newest versions of python that gnuradio should
>>> work with?
>>>
>>> That way I can test stuff using those two versions.
>>
>>
>> Python 2.4 is the oldest that I _know_ will work (and I don't think,
>> but haven't tried, 2.3), and I've used it with 2.7. It will not work
>> with 3.+.
>>
>> 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] Gnu Radio and Andoid?

Hi
I wonder if anyone used Gnu Radio on an Android based netbook? I have a Toshiba AC100 and wonder if it can run GR?
http://www.engadget.com/2010/06/21/toshibas-ac100-8-hour-smartbook-runs-android-2-1-on-a-1ghz-tegr/

I know it is not fast enough, 1Ghz processor is not enough for any advanced processing, but it will be great to be able to install it and use it to run development of sub-modules while I am trveling.

Thanks in advance,
Farhad

Re: [Discuss-gnuradio] python versions

FYI, grc only works with 2.5 and up. Ive only tested up to 2.7

-Josh

On 02/27/2011 09:43 PM, Ben Reynwar wrote:
> I just tested the next branch with 2.4 and the only incompatibility
> was a "with" statement in gr_xmlrunner.py.
> The "with" statement was introduced in 2.5.
>
> Once that was removed the "make check" ran fine.
>
> The replacement for the "with" statement was:
>
> fss = _fake_std_streams()
> fss.__enter__()
> try:
> test(result)
> try:
> out_s = sys.stdout.getvalue()
> except AttributeError:
> out_s = ""
> try:
> err_s = sys.stderr.getvalue()
> except AttributeError:
> err_s = ""
> finally:
> fss.__exit__(None, None, None)
>
> On Wed, Feb 23, 2011 at 6:20 PM, Tom Rondeau <trondeau1122@gmail.com> wrote:
>> On Wed, Feb 23, 2011 at 1:28 PM, Ben Reynwar <ben@reynwar.net> wrote:
>>> What are the oldest and newest versions of python that gnuradio should
>>> work with?
>>>
>>> That way I can test stuff using those two versions.
>>
>>
>> Python 2.4 is the oldest that I _know_ will work (and I don't think,
>> but haven't tried, 2.3), and I've used it with 2.7. It will not work
>> with 3.+.
>>
>> 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

Re: [Discuss-gnuradio] About the -ve represenation on FFT graph.

On 02/27/2011 10:21 PM, Howard Wong wrote:
> Thanks for your kindly reply.
>
> Can you explain more that, both sides from the center frequency of the
> input frequency has been cut by a low pass filter.
>

If you want to filter around 0 to f, then use the complex bandpass
filter. Its the same FIR filer with different filter taps.

> Doesn't a low pass filter allow the lower frequency to pass?
>

Correct. For a complex baseband signal, this is all frequencies between
+/- cutoff_freq

-josh

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

Sunday, February 27, 2011

Re: [Discuss-gnuradio] Synchronizing multiple USRPs

On 02/27/2011 11:48 PM, Khalid Jamil wrote:
> Hello,
>
> I have eight (08) USRP N210s that has been synchronized using 10MHZ and 1PPS
> reference. I am receiving data from them using a gigabit ethernet switch to
> my computer.
>
> My question is when I will receive packets from all of them through a single
> switch, how will I know the time reference for each sample?
>

A time stamp can be found in the metadata, representing the time of the
first sample in the packet. See the docs for the recv() call:
http://www.ettus.com/uhd_docs/doxygen/html/classuhd_1_1device.html#a3e7e55ed84ca59310c4396a18a5e36d5

-josh

> Thanks,
>
> Khalid.
>
>
>
>
> _______________________________________________
> 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] Synchronizing multiple USRPs

Hello,

I have eight (08) USRP N210s that has been synchronized using 10MHZ and 1PPS reference. I am receiving data from them using a gigabit ethernet switch to my computer. 

My question is when I will receive packets from all of them through a single switch, how will I know the time reference for each sample? 

Thanks,

Khalid.


[Discuss-gnuradio] Re: High CPU usage

Hello Tom,


Here is how I collect the data:


I am using the example rx_streaming_samples.cc to collect data. I disabled the function copy_u2_16sc_to_host_16sc() in the example.


I think the program keeps calling bool ok = rx_nop_handler::operator()(items, nitems, metadata) to return the pointer of the received meta data array.


There is a background thread usrp2::impl::bg_loop() running in real time. This function calls "d_eth_buf->rx_frames(this, 100); " to get the data out from the ethernet buffer. That is basically what this program does.


Do you think the CPU usage is normal? I also notice that the block timeout is 100ms. Is there a reason for doing this?



--- On Sun, 2/27/11, Tom Rondeau <trondeau1122@gmail.com> wrote:

From: Tom Rondeau <trondeau1122@gmail.com>
Subject: Re: High CPU usage
To: "peng senl" <pengsenl@yahoo.com.cn>
Cc: discuss-gnuradio@gnu.org
Date: Sunday, February 27, 2011, 4:37 PM

On Fri, Feb 25, 2011 at 3:47 PM, peng senl <pengsenl@yahoo.com.cn> wrote:


> The legacy driver or UHD? Are you using 32-bit complex
> floats or
> 16-bit complex shorts for you data?

In my case, I am using GNU Radio with USRP2 in C++.
The CPU usage for 5MHz is 30% with 3.2 G duo core CPU and around 70% for 20MHz sample frequency.

> I'd be very interested to hear your benchmarking of the
> different
> types here. That is UHD/32fc vs. USRP2/32fc and UHD/16sc
> vs.
> USRP2/16sc. Also, UHD/32fc vs. UHD/16sc.

I just read data coming over the Ethernet. I did not even convert from big to little endian or convert data to other format. So I try to minimize the operations. But I still get such a high CPU usage. I wondering is it possible to simplify the data receive operations.

Ok, that didn't answer my question at all. HOW are you reading them from the Ethernet port? Which function are you calling in the USRP2 library to do this? Or which GNU Radio usrp2_source_XXX are you using (usrp2_source_32fc or usrp2_soruce_16sc)?

Tom



Re: [Discuss-gnuradio] About the -ve represenation on FFT graph.

Thanks for your kindly reply.

Can you explain more that, both sides from the center frequency of the
input frequency has been cut by a low pass filter.

Doesn't a low pass filter allow the lower frequency to pass?

Thanks,
Rono


On 28/02/11 12:22, Josh Blum wrote:
>
> On 02/27/2011 07:57 PM, rono wrote:
>> Sorry if the question was re-posted.
>>
>>
>> Can anyone reply this entry level question?
>>
>>
>> In complex data representation such as the attached image by grc,
>> the LPF cut the frequency in both direction(+/- freq)
>> which the center frequency is 0Hz
>>
>> http://www.fungkai.com/~howie/sdr/complex_1_basefreq0.gif
>>
>> When I set the base frequency to a large positive value such as 10MHz,
>> the cutoff shows on both side apart from the center frequency too.
>>
> The baseband frequency parameter only changes the value printed on the x
> axis. For example: If you had a usrp source tuned to frequency X, you
> would also set the baseband frequency to X -> for display purposes.
>
> -josh
>
> _______________________________________________
> 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] UHD Driver in E100/Beagleboard

On Sun, Feb 27, 2011 at 11:39 PM, Almohanad Fayez <alfayez@aol.com> wrote:
> I think I made some progress in diagnosing the UHD/Beagleboard USRP1 issue.
> I've tried bitbaking Philip's GNU Radio 3.2.1 recipe and the compilation
> fails because of the libusb-0.1.12 link, more specifically the
> "libusb-gnur.a" library.  For some reason GCC is expecting the library to
> have the "-fPIC" flag passed when building the library which doesn't make
> sense since it's trying to link against a static library and not a shared
> librar ... it was complaining about an ARM_MOV or something like that
> assembly command.  To my understanding the libtool included in the libusb
> should make sure that such confusion doesn't happen which in using GCC 4.3
> was not an issue but with the GCC 4.5 included in the new tree is an issue.

UHD uses libusb-1.0 and does not support libusb-0.1. Despite some
similarities in the API, version 1.0 is a complete rewrite there is no
compatibility or relation between versions. In that sense, the
gnuradio 3.2 recipe is completely unrelated to UHD.

> I also tried incorporating the libusb fix against the GNU Radio GIT recipe
> but the configure stage fails because gnuradio can't find the
> "USB_BULK_WRITE" function in the libusb library from libusb-0.1.12 which
> when I looked is actually there.  When I bypass the configure check for
> USB_BULK_WRITE the gnuradio compilation fails at the same stage as gnuradio
> 3.2.1.  I feel like the libusb-0.1.12 static library is corrupt for some
> reason more specifically I think libtool might be the culprit.

If you are using libusb-0.1 and the gnuradio driver, you generally
_don't_ want to be using the mentioned libusb calls, which are
synchronous (slow). Normally, with libusb-0.1, the control and setup
functions go through libusb, while data flows through a separate OS
specific implementation - usbdevfs in the case of Linux. The only time
you should be seeing usb_bulk_write is when configure falls back to
the synchronous calls in the absence of any "fast" version. Now the
Linux implementation does have some evil bits, so perhaps this isn't
surprising.

> I assume that USB_BULK_WRITE is used in the USRP sink UHD block which might
> explain why I can receive but I can't write using the UHD driver.  The
> libusb-0.1.12 fix included in the UHD driver, did it use GCC 4.5? did it use
> libusb-0.1.12? an older or newer version maybe?  did it use a different
> libtool?

Again, usb_bulk_write and libusb-0.1.12 have no relation to UHD.

> I need to find a way to pass the -fPIC flag to the configure stage of
> libusb-0.1.12 unfortunately I can't seem to find an easy way to do it and
> I'm about to head out of town for a few days.  Other than that doese anyone
> have any suggestion?

In UHD with libusb-1.0, sends and receives are treated similarly (USB
is host driven) where pre-allocated buffers are submitted and
retrieved from the device. The difference is mainly in flags and
endpoint settings; the problem, IMO, is unlikely to be build related.
Of course, that doesn't provide any insight into why this is only
coming up on the Beagle.

I'd like to recreate this issue on my newly setup E100, but, at the
moment, I'm not seeing any USB devices, and I think I just bricked my
FPGA. So I need to get a little bit more settled until I can try out
additional things. Perhaps later this week...

Thomas

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

Re: [Discuss-gnuradio] python versions

I just tested the next branch with 2.4 and the only incompatibility
was a "with" statement in gr_xmlrunner.py.
The "with" statement was introduced in 2.5.

Once that was removed the "make check" ran fine.

The replacement for the "with" statement was:

fss = _fake_std_streams()
fss.__enter__()
try:
test(result)
try:
out_s = sys.stdout.getvalue()
except AttributeError:
out_s = ""
try:
err_s = sys.stderr.getvalue()
except AttributeError:
err_s = ""
finally:
fss.__exit__(None, None, None)

On Wed, Feb 23, 2011 at 6:20 PM, Tom Rondeau <trondeau1122@gmail.com> wrote:
> On Wed, Feb 23, 2011 at 1:28 PM, Ben Reynwar <ben@reynwar.net> wrote:
>> What are the oldest and newest versions of python that gnuradio should
>> work with?
>>
>> That way I can test stuff using those two versions.
>
>
> Python 2.4 is the oldest that I _know_ will work (and I don't think,
> but haven't tried, 2.3), and I've used it with 2.7. It will not work
> with 3.+.
>
> Tom
>

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

Re: [Discuss-gnuradio] Constant output message source

Cool thanks for the reply.

The reason I am doing this is because I am trying to transmit signals at
different times... and testing shows the interleave block acts like the sync
type blocks you mention. I am guessing the same idea can be applied and make
a new interleave block and inherits from the gr_block.

Though I am just wondering that this has to be a common problem with the
dual usrp TX usage, I was wondering if anyone else has done similar work
already or has an more "standard" solution using the tools already built
into GNU radio. As I am not too familiar with the build toolchain and the
C++ backbones behind the python, however I will be reading up on it now.


Tom Rondeau wrote:
>
> On Sat, Feb 19, 2011 at 4:52 AM, ichigo.san <ichigo.san@gmail.com> wrote:
>
>>
>> Hi,
>>
>> I was wondering if there is a method to have a source block constantly
>> sending out "0" and once it recieves a message from python, e.g a packet,
>> it
>> will then stream the message and switch back to sending "0" when done.
>>
>> I've tried:
>> Message Source ----------------------------> (Add, 0)
>> Constant Source/Vector Source with 0 -----> (Add, 1) ---> output
>>
>> However, the add block (and all blocks in gnuradio) waits for stream
>> items
>> from both inputs to be ready (i.e no interpolation) before making a
>> output
>> stream item. This effectively nullifies the const source in the above
>> example.
>>
>> I was wondering if there is any possible way to solve this problem?
>>
>> The reason I am asking this is I am using a dual TX setup on a single
>> USRP
>> which interleaves output signals. I have I output signal that is
>> constantly
>> sending (beacon) and one that is only sending sometimes, however the
>> interleaving of output signals means that both streams needs to be
>> constantly sending.
>>
>
> Right, the add block needs to see items from both streams so that it can
> add
> them together. If there is no data on one stream, there is nothing to add
> and it does not assume zeros.
>
> My advice is to make a new block. The easiest would probably to make a new
> add block that inherits from gr_block instead of gr_sync_block. In this
> block, you tests the length of both inputs and add which items together
> that
> you want, substituting zeros when there is no more data on the incoming
> message stream. It will be pretty specific to your needs, and be careful
> with your consume() and return item numbers to account for what you've
> done
> with both streams.
>
> Tom
>
> _______________________________________________
> 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/Constant-output-message-source-tp30964604p31029150.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

[Discuss-gnuradio] USRP output power

Does anybody know about output power of a USRP antenna, in voltage and ampere ?

I'm trying to make a circuit connected with a USRP antenna port.
And, in the future, the human body will replace the circuit

Of course, it's a kind of experimental.

So, If I send a sinusoidal signal with magnitude 35536 which is a maximum value allowed by USRP,
what voltage and ampere value does the antenna output?

Thank you for all in advance.

Re: [Discuss-gnuradio] UHD Driver in E100/Beagleboard

I think I made some progress in diagnosing the UHD/Beagleboard USRP1 issue.  I've tried bitbaking Philip's GNU Radio 3.2.1 recipe and the compilation fails because of the libusb-0.1.12 link, more specifically the "libusb-gnur.a" library.  For some reason GCC is expecting the library to have the "-fPIC" flag passed when building the library which doesn't make sense since it's trying to link against a static library and not a shared librar ... it was complaining about an ARM_MOV or something like that assembly command.  To my understanding the libtool included in the libusb should make sure that such confusion doesn't happen which in using GCC 4.3 was not an issue but with the GCC 4.5 included in the new tree is an issue.
 
I also tried incorporating the libusb fix against the GNU Radio GIT recipe but the configure stage fails because gnuradio can't find the "USB_BULK_WRITE" function in the libusb library from libusb-0.1.12 which when I looked is actually there.  When I bypass the configure check for USB_BULK_WRITE the gnuradio compilation fails at the same stage as gnuradio 3.2.1.  I feel like the libusb-0.1.12 static library is corrupt for some reason more specifically I think libtool might be the culprit.
 
I assume that USB_BULK_WRITE is used in the USRP sink UHD block which might explain why I can receive but I can't write using the UHD driver.  The libusb-0.1.12 fix included in the UHD driver, did it use GCC 4.5? did it use libusb-0.1.12? an older or newer version maybe?  did it use a different libtool? 
I need to find a way to pass the -fPIC flag to the configure stage of libusb-0.1.12 unfortunately I can't seem to find an easy way to do it and I'm about to head out of town for a few days.  Other than that doese anyone have any suggestion? 
 
Josh or Philip :)

al fayez


-----Original Message-----
From: Almohanad Fayez <alfayez@aol.com>
To: philip <philip@balister.org>
Cc: discuss-gnuradio <discuss-gnuradio@gnu.org>
Sent: Thu, Feb 24, 2011 6:42 pm
Subject: Re: [Discuss-gnuradio] UHD Driver in E100/Beagleboard

1- I'm using the host USB not the OTG
2- I'm using the 2.6.37 kernel with Angstrom 2010
3- The following is the dmesg output which looks ok ... at least to me :)

[  108.369293] usb 1-2.3.1: USB disconnect, address 4
[  108.770874] usb 1-2.3.1: new high speed USB device using ehci-omap and address 6
[  108.889404] usb 1-2.3.1: New USB device found, idVendor=fffe, idProduct=0002
[  108.889434] usb 1-2.3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=6
[  108.889465] usb 1-2.3.1: Product: USRP Rev 4
[  108.889465] usb 1-2.3.1: Manufacturer: Free Software Folks
[  108.889495] usb 1-2.3.1: SerialNumber: 4bd1d69b


I think I'll try to attempt to redo your libusb hack by copying it from the older gnuradio recipes and attempt to use the original USRP USB driver if the problem ends up being too major ... unless you want to do that as a favor to me and push the recipe into the openembedded tree !!!   pretty please :)


al fayez


-----Original Message-----
From: Philip Balister <philip@balister.org>
To: Almohanad Fayez <alfayez@aol.com>
Cc: discuss-gnuradio <discuss-gnuradio@gnu.org>
Sent: Thu, Feb 24, 2011 2:20 pm
Subject: Re: [Discuss-gnuradio] UHD Driver in E100/Beagleboard

On 02/23/2011 11:25 PM, Almohanad Fayez wrote:
> I was wondering about people's experience with the UHD driver on the E100 or
the Beagleboard. I am able to use it to receive IQ data from the USRP but I
can't seem to transmit anything from it ... if I take the same flowgraph to a
laptop I'm able to transmit IQ using the same USRP/daughterboard and the UHD
driver however when I try to run the same transmitter on the Beagleboard and I
check my spectrum analyzer I don't see anything
>
> I already did a signal capture before sending to the USRP and made sure that
there is data getting pushed through ... is there a problem with UHD/USRP
sinking on the E100 and the Beagleboard ??? I also made sure that I'm using the
latest UHD firmware on the beagleboard.
>
>
> The following is the version info printed when I run the flowgraph:
> linux; GNU C++ version 4.5.3 20110214 (prerelease); Boost_104500;
UHD_0001.20110224034946.1

Al,

Which USB port are you using to connect the USRP1? What kernel version?

Can you run dmesg and see if there are any usb related messages at the end?

Philip

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

Re: [Discuss-gnuradio] About the -ve represenation on FFT graph.

On 02/27/2011 07:57 PM, rono wrote:
> Sorry if the question was re-posted.
>
>
> Can anyone reply this entry level question?
>
>
> In complex data representation such as the attached image by grc,
> the LPF cut the frequency in both direction(+/- freq)
> which the center frequency is 0Hz
>
> http://www.fungkai.com/~howie/sdr/complex_1_basefreq0.gif
>
> When I set the base frequency to a large positive value such as 10MHz,
> the cutoff shows on both side apart from the center frequency too.
>

The baseband frequency parameter only changes the value printed on the x
axis. For example: If you had a usrp source tuned to frequency X, you
would also set the baseband frequency to X -> for display purposes.

-josh

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

[Discuss-gnuradio] About the -ve represenation on FFT graph.

Sorry if the question was re-posted.


Can anyone reply this entry level question?


In complex data representation such as the attached image by grc,
the LPF cut the frequency in both direction(+/- freq)
which the center frequency is 0Hz

http://www.fungkai.com/~howie/sdr/complex_1_basefreq0.gif

When I set the base frequency to a large positive value such as 10MHz,
the cutoff shows on both side apart from the center frequency too.


http://www.fungkai.com/~howie/sdr/complex_1_basefreq10.gif

What's the frequency lower then the center frequency represent?


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

Re: [Discuss-gnuradio] multiple tabs

The graphical widgets all take a notebook parameter which is
notebook_id, tab_index. See the documentation in the various blocks.

-josh

On 02/26/2011 07:46 AM, ranjini ram wrote:
> hi
>
> can anybody help me out in creating multiple tabs in a single output
> window.eg.one tab indicating RF spectrum second IF spectrum and so on..
>
> Thanks in advance
>
>
>
>
> _______________________________________________
> 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] Re: UHD Announcement - February 25rd 2011

> When you say "2x" performance increase, do you mean CPU performance or
> send()/recv() latency? Do you mind saying a few words on what changes
> you have made?
>

Much of the performance gains involved removing things out of the
fast-path that only needed to be called once at initialization (forgoing
code simplicity for performance). Example: a vector of pointers, a bound
callable object; many of which had calls to malloc and free which incurs
quite a lot of unnecessary overhead.

Less cpu cycles/less time are spent in the send()/recv() calls. This
roughly worked out to about half the CPU usage when looking at oprofile.
Because of this, the overall latency is reduced. We measured about 250us
RTT from device to host and back to device with the latency measurement
app in uhd examples.

-josh

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

Re: [Discuss-gnuradio] Real-only direct-conversion

On 02/27/2011 06:41 PM, Moeller wrote:
> A real valued zero-IF "universal" (modulation independent) receiver does not exist.
> I think you have the a demodulating receiver in mind that relies on
> symmetry in the baseband spectrum, like for AM. In this concept, "baseband"
> is the real valued audio baseband. For digital modulations it doesn't make sense.
> The real valued representation with IF at half of the one-sided signal bandwidth
> can be called "real baseband", in contrast to the "complex baseband".
> Same data size, same content, same bandwidth, just shifted in spectrum.
>
Yup, that's pretty much what I said in my initial post on the subject.
The 1940s-era direct-conversion
receivers were designed specifically for things like AM, where the
+/- frequency ambiguity didn't
matter.

Yup, placing the IF at Fs/4 makes sense in that you can later do a
Hilbert transform and convert to complex.
But if the IF is at zero, you lose.


--
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] Real-only direct-conversion

On 28.02.2011 00:22, Marcus D. Leech wrote:
> But for a zero-IF, direct-conversion, with only a single baseband output
> (single mixer), I don't see how you
> can make it work.

A real valued zero-IF "universal" (modulation independent) receiver does not exist.
I think you have the a demodulating receiver in mind that relies on
symmetry in the baseband spectrum, like for AM. In this concept, "baseband"
is the real valued audio baseband. For digital modulations it doesn't make sense.
The real valued representation with IF at half of the one-sided signal bandwidth
can be called "real baseband", in contrast to the "complex baseband".
Same data size, same content, same bandwidth, just shifted in spectrum.

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

Re: [Discuss-gnuradio] Real-only direct-conversion

On 02/27/2011 06:16 PM, Moeller wrote:
>
> As long as you receive the complete signal bandwidth, you can create the I/Q form later.
> Of course you need the double sample rate, if there's only the real "baseband"
> representation. I call it baseband, but you can also call it IF with the lowest
> possible IF frequency. Strictly speaking it's not a "direct-conversion" receiver,
> since there is a fixed IF in the middle of the baseband spectrum.
> The "data rate" is the same for both, one has double sample rate but only
> half the sample size (real vs. complex numbers).
>
> Complex baseband (I/Q) reconstruction:
> - Hilbert transform eleminates the (symmetric) negative frequencies
> - Frequency shifting the IF frequency to zero by multiplying a complex exp(-j*2*pi*f_IF*t)
>
> This is standard in digital down converters (DDC).
> The TVRX-Board is working this way. According to the schematic,
> only the bipolar A channel is connected to the tuner chip, a real input.
> Other Dboards use both A/B inputs for separate I/Q channels.
>
> I think both variants have their advantages and disadvantages.
>
Right, for a non-zero IF, it's easy to see how to do the Hilbert
transform and convert to I+Q, provided the
sample rates are correct.

But for a zero-IF, direct-conversion, with only a single baseband output
(single mixer), I don't see how you
can make it work.


--
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] build-gnuradio script

#!/bin/sh
#
# Build script for UHD+GnuRadio on Fedora and Ubuntu
#
SUDOASKED=n
function prereqs {
sudocheck
echo Installing pre-prequisites
#
# Check whether we're on a Fedora or Ubuntu system, and "do the right thing"
# for either system
#
# It's a Fedora system
#
if [ -f /etc/fedora-release ]
then
case `cat /etc/fedora-release` in
*12*|*13*|*14*|*15*)
sudo yum -y groupinstall "Engineering and Scientific" "Development Tools"
sudo yum -y install fftw-devel cppunit-devel wxPython-devel libusb-devel \
guile boost-devel alsa-lib-devel numpy gsl-devel python-devel pygsl \
python-cheetah python-lxml guile-devel PyOpenGL \
PyQt4-devel qwt-devel qwtplot3d-qt4-devel libusb libusb-devel \
libusb1 libusb1-devel cmake git wget sdcc
;;
*)
echo Your Fedora system release must be at least 12 to proceed
exit
;;
esac

#
# It's a Ubuntu system
#
elif [ -f /etc/lsb-release ]
then
case `grep DISTRIB_RELEASE /etc/lsb-release` in
*10.04*|*10.10*)
sudo apt-get -y install libfontconfig1-dev libxrender-dev libpulse-dev swig g++ \
automake autoconf libtool python-dev libfftw3-dev \
libcppunit-dev libboost-all-dev libusb-dev fort77 sdcc sdcc-libraries \
libsdl1.2-dev python-wxgtk2.8 git-core guile-1.8-dev \
libqt4-dev python-numpy ccache python-opengl libgsl0-dev \
python-cheetah python-lxml doxygen qt4-dev-tools libusb-1.0-0-dev \
libqwt5-qt4-dev libqwtplot3d-qt4-dev pyqt4-dev-tools \
cmake git wget sdcc
;;

*9.10*)
sudo apt-get -y install swig g++ automake autoconf libtool python-dev libfftw3-dev \
libcppunit-dev libboost1.38-dev libusb-dev fort77 sdcc sdcc-libraries \
libsdl1.2-dev python-wxgtk2.8 git-core guile-1.8-dev \
libqt4-dev python-numpy ccache python-opengl libgsl0-dev \
python-cheetah python-lxml doxygen qt4-dev-tools libusb-1.0-0-dev \
libqwt5-qt4-dev libqwtplot3d-qt4-dev pyqt4-dev-tools \
cmake git wget sdcc
;;

*)
echo Your Ubuntu release must be at least 9.10 to proceed
exit
;;
esac
else
echo This script supports only Ubuntu and Fedora systems
echo Your Fedora system must be at least Fedora 13
echo Your Ubuntu system must be at least Ubuntu 9.10
exit
fi
}


function gitfetch {
cd $HOME
date=`date +%Y%m%d%H%M%S`

#
# Check for existing gnuradio directory
#
if [ -d $HOME/gnuradio ]
then
mv $HOME/gnuradio $HOME/gnuradio.$date
fi

#
# Check for existing UHD directory
#
if [ -d $HOME/uhd ]
then
mv $HOME/uhd $HOME/uhd.$date
fi

#
# GIT the gnu radio source tree
#
git clone http://gnuradio.org/git/gnuradio.git

if [ ! -d gnuradio/gnuradio-core ]
then
echo GIT checkout of Gnu Radio failed!
exit
fi

#
# GIT the UHD source tree
#
git clone git://code.ettus.com/ettus/uhd.git

if [ ! -d uhd/host ]
then
echo GIT checkout of UHD failed!
exit
fi
}

function uhd_build {
#
# UHD build
#
sudocheck
cd $HOME
if [ ! -d uhd ]
then
echo you do not appear to have the \'uhd\' directory
echo you should probably use $0 gitfetch to fetch the appropriate
echo files using GIT
exit
fi
echo Building UHD first...
cd uhd/host
mkdir build
cd build
cmake ../
make
sudo make install
if [ ! -f /usr/local/bin/uhd_find_devices -o /usr/local/bin/uhd_find_devices -ot $HOME/uhd ]
then
echo UHD build/install apparently failed exiting $0
exit
fi
echo Done building UHD
}

function firmware {
sudocheck
#
# Firmware/FPGA images...
#
cd $HOME
echo Fetching FPGA/Firmware images via wget
mkdir wget-tmp
cd wget-tmp
wget -nd -r -np http://www.ettus.com/downloads/uhd_images/UHD-images-most-recent/
tar xf *-Linux.tar.gz
cd UHD*/share/uhd/images
if [ ! -d /usr/local/share/uhd/images ]
then
sudo mkdir -p /usr/local/share/uhd/images
fi
sudo cp * /usr/local/share/uhd/images
sudo chmod 644 /usr/local/share/uhd/images/*
cd $HOME
rm -rf wget-tmp
echo Done installing FPGA/Firmware images via wget
}

function gnuradio_build {
sudocheck
cd $HOME

if [ ! -d gnuradio ]
then
echo you do not appear to have the \'gnuradio\' directory
echo you should probably use $0 gitfetch to fetch the appropriate
echo files using GIT
exit
fi

#
# LD stuff
#
echo /usr/local/lib >tmp$$

if grep -q /usr/local/lib /etc/ld.so.conf.d/*
then
echo /usr/local/lib already in ld.so.conf.d
else
sudo cp tmp$$ /etc/ld.so.conf.d/local.conf
fi
rm -f tmp$$
sudo ldconfig

PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
export PKG_CONFIG_PATH

#
# Build Gnuradio
#
cd $HOME
echo Building Gnu Radio...
cd gnuradio
git status >foo$$
if grep -q "On branch next" foo$$
then
echo No need to change to branch \'next\' already done
else
git branch --track next origin/next
git checkout next
fi
rm foo$$
./bootstrap
./configure
make
sudo make install
if [ ! -f /usr/local/bin/gnuradio-companion -o /usr/local/bin/gnuradio-companion -ot $HOME/gnuradio/grc ]
then
echo Gnu Radio build/install apparently failed exiting $0
exit
fi
echo Done building Gnu Radio
}

function mod_groups {
sudocheck
#
# Post install stuff
#
# USRP rules for UDEV and USRP group
#
#
# Check for USRP group, and update if necessary
if grep -q usrp /etc/group
then
echo Group \'usrp\' already in /etc/group
else
sudo /usr/sbin/groupadd usrp
fi

#
# Check that our calling user is in the USRP group, update if necessary
#
if grep -q usrp.*${USER} /etc/group
then
echo User $USER already in group \'usrp\'
else
sudo /usr/sbin/usermod -a -G usrp $USER
fi
}

function mod_udev {
sudocheck
cd $HOME
#
# Check for UDEV rules file, update if necessary
#
if [ ! -f /etc/udev/rules.d/10-usrp.rules ]
then
cat >>tmp$$ <<"!EOF!"
# rule to grant read/write access on USRP to group named usrp.
# to use, install this file in /etc/udev/rules.d as 10-usrp.rules
ACTION=="add", BUS=="usb", SYSFS{idVendor}=="fffe", SYSFS{idProduct}=="0002", GROUP:="usrp", MODE:="0660"
!EOF!
chmod 644 tmp$$
sudo mv tmp$$ /etc/udev/rules.d/10-usrp.rules
sudo killall -HUP udevd
sudo udevadm control --reload_rules
rm -f tmp$$
else
echo USRP rules for UDEV already in place
fi
}

function mod_sysctl {
sudocheck
cd $HOME
#
# Modify sysctl.conf as necessary
#
cat >tmp$$ <<!EOF!
# Updates for Gnu Radio
net.core.rmem_max = 1000000
net.core.wmem_max = 1000000
kernel.shmmax = 2147483648
!EOF!


if grep -q 'Updates for Gnu Radio' /etc/sysctl.conf
then
echo Required updates to /etc/sysctl.conf already in place
else
echo Applying updates to /etc/sysctl.conf
cat /etc/sysctl.conf tmp$$ >tmp2$$
chmod 644 tmp2$$
sudo mv tmp2$$ /etc/sysctl.conf
fi

sudo sysctl -w net.core.rmem_max=1000000
sudo sysctl -w net.core.wmem_max=1000000
sudo sysctl -w kernel.shmmax=2147483648

rm -f tmp$$
rm -f tmp2$$
}

function all {
prereqs
touch -d "2 hours ago" touch$$
if [ -d $HOME/uhd -a -d $HOME/gnuradio ]
then
if [ $HOME/uhd -ot touch$$ -o $HOME/gnuradio -ot touch$$ ]
then
gitfetch
else
echo Skipping git fetch, since \'uhd\' and \'gnuradio\' are new enough
fi
else
gitfetch
fi
rm -f touch$$
uhd_build
firmware
gnuradio_build
mod_groups
mod_udev
mod_sysctl
}

function help {
echo available functions are: all prereqs gitfetch uhd_build firmware gnuradio_build mod_groups mod_udev mod_sysctl
}

cd $HOME
PATH=$PATH:/usr/libexec/sdcc
export PATH

function sudocheck {
#
# Check SUDO privileges
#
if [ $SUDOASKED = n ]
then
echo SUDO privileges are required
echo -n Do you have SUDO privileges'?'
read ans
case $ans in
y|yes|YES|Y)
echo Continuing with script
SUDOASKED=y
;;
*)
echo Exiting. Please ensure that you have SUDO privileges on this system!
exit
;;
esac
fi
}

case $# in
0)
all
exit
esac

for arg in $*
do
$arg
done
I've put together a script for building GnuRadio+UHD for both Ubuntu
recent and Fedora recent.

I've attached it.

This is outgrowth of a script I put together and distributed to a few
people several years ago, but it has
been updated quite a bit and supports both Ubuntu and Fedora.

Your mileage may vary. Void where prohibited. Some settling may have
occurred during transit. Batteries not
included. Only use while awake. Do not use in the bathtub.

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

Re: [Discuss-gnuradio] Real-only direct-conversion

On 27.02.2011 17:28, Marcus D. Leech wrote:
> I was on a call the other night with someone who asserted that you
> didn't need an I & Q representation
> for a direct-conversion receiver, and that I and Q could be
> synthesized later from a real-mode-only
> baseband signal.
...

> So, my feeling is that you *absolutely need* the I and Q "form" in order
> to disambiguate +/-
> frequencies when dealing with direct-conversion baseband signals.
> Who's right?

As long as you receive the complete signal bandwidth, you can create the I/Q form later.
Of course you need the double sample rate, if there's only the real "baseband"
representation. I call it baseband, but you can also call it IF with the lowest
possible IF frequency. Strictly speaking it's not a "direct-conversion" receiver,
since there is a fixed IF in the middle of the baseband spectrum.
The "data rate" is the same for both, one has double sample rate but only
half the sample size (real vs. complex numbers).

Complex baseband (I/Q) reconstruction:
- Hilbert transform eleminates the (symmetric) negative frequencies
- Frequency shifting the IF frequency to zero by multiplying a complex exp(-j*2*pi*f_IF*t)

This is standard in digital down converters (DDC).
The TVRX-Board is working this way. According to the schematic,
only the bipolar A channel is connected to the tuner chip, a real input.
Other Dboards use both A/B inputs for separate I/Q channels.

I think both variants have their advantages and disadvantages.

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

Re: [Discuss-gnuradio] Build error GNU Radio release v3.3.1git-971-ga02bb131

On Sun, Feb 27, 2011 at 6:51 AM, Arya Santini <arya.santini7@gmail.com> wrote:
Hi Jared, thanks for that suggestion.

Anyway, I realized that I was using GNU compiler gcc-4.6
(experimental) which apparently imposes stricter rules and allows
package builds to fail where previous versions used to succeed. So the
suggested fix for one typical "ptrdiff_t does not name a type" is
#include <cstddef.h>, which I did in the
/usrp/host/swig/python/usrp_prims.cc file, and the build completed to
success.

Arya

Thanks for bringing this up (and for the solution). The usrp_prims.cc file is actually generated by SWIG, so I've explicitly included stddef.h into the .i file, which is done for most of the other SWIG files already for other reasons. This really seems like a SWIG problem, so hopefully this will be fixed in future releases before the new GCC takes over. Hopefully, this fixes our last hole, anyways.

I'll be pushing changes to next and master soon.

Tom


 
On Sun, Feb 27, 2011 at 3:15 AM, Jared Harvey <mail@jaredharvey.com> wrote:
> Hello Arya,
>
> AS> I  was  trying  to  build  the gnuradio on yet
> AS> another  machine  running  Ubuntu  10.10. from
> AS> source  today  after  checking  out the latest
> AS> code from the dev trunk:
>
> I see Ubuntu 10.10 has native packages. Is there a
> reason why you need to compile it? Perhaps you are
> looking for the latest and greatest.
>
> You    may   have   dependency   problems.   These
> dependencies  may  be  resolved  by installing the
> native packages. Perhaps you can open Synaptic and
> install  the  native  gnuradio that way and see if
> that helps your compile process.
>
> Best regards.
>
> .. ..-. / -.-- --- ..- / .-. . .- -.. /  - .... .. ...
> .-.. . - ... / .... .- ...- . / .- / -... . . .-.
>
>  Jared Harvey                           Operator KB1GTT
>
> e-mail mail@jaredharvey.com
> Web page http://jaredharvey.com
>
>
> _______________________________________________
> 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] Multirate Blocks

On Sat, Feb 26, 2011 at 8:00 AM, Antoine Dedave <qlmqny_anti_rsca@hotmail.com> wrote:
Hi,

I'm implementing a 2-FSK modulator (I Know that a good one already exists but 
i have to do it myself for academic purpose). 

To do so, i produce a given (N) number of samples corresponding to the sampling of a complex exponnetial for each
 incoming bits.
 
The "sampling rate" (one bit => N samples) is increased  by N through the modulator, so i'm doing this
 
Constructor:
  
  set_relative_rate(N);
  set_output_multiple(N);
  
General_work:
  
  consume_each(noutput_items/N);
  
Is that correct? and is there anything else to do? 

Thanks in advance,

Antoine Dedave

First, what type of gr_block are you inheriting from? The fact that you are using noutput_items/N in your consume_each function makes it look almost like you are using a gr_sync_block, which would not be the right answer here.

In fact, you can use a gr_sync_interpolator since you know the direct relationship between input and output samples (1-to-N). Set the interpolation rate as N and you don't need to worry about any of the reset (setting the relative_rate or consume_each; the parent class knows what to do with them).

Look at the implementation of gr_sync_interpolator to see how it handles setting everything up for you to do the interpolation properly.

Tom

Re: [Discuss-gnuradio] Adding dual usrp sink block to benchmark_tx.py

On Sat, Feb 26, 2011 at 5:17 AM, Jay Gaona <imionhan@hotmail.com> wrote:
Hello everyone,

I've added a dual usrp sink block and duplicated the tx flow graphs in benchmark_tx.py example. However, I am unable to transmit packets when I set the following in the flow graph:

self.packet_transmitter = \
    blks2.mod_pkts(modulator,
                           access_code=None,
                           msgq_limit=4,
                           pad_for_usrp=True)
   
self.packet_transmitter_2 = \
    blks2.mod_pkts(modulator_2,
                           access_code=None,
                           msgq_limit=4,
                           pad_for_usrp=True)


self.connect(self.packet_transmitter,     self.amp,     (self, 0))
self.connect(self.packet_transmitter_2, self.amp_2, (self, 1))

I have tried the following 2 codes and were able to transmit packets from the first flow graph, and then the packets from the second flow graph:

self.connect(self.packet_transmitter,     self.amp,     (self, 0))
self.connect(self.null_source,                  self.amp_2, (self, 1))

self.connect(self.null_source,                 self.amp,     (self, 0))
self.connect(self.packet_transmitter_2, self.amp_2, (self, 1))

Any idea why I am unable to simultaneously transmit packets from both flow graphs? Thanks in advance!


Right now, no, sorry, no ideas. It seems like it should work.

I will suggest two things, though. First, remove the message sources from the graph. Replace your packet_transmitter_X and replace them with two gr.sig_source_c() with different frequencies and make sure that they transmit as expected from each output of the USRP.

Next, keep your packet transmitters, but replace the USRP dual sink with file sinks and make sure they are getting the proper signals from the source.

Between these two experiments, maybe you'll get enough information to fix your problem. Or let us know more about what's happening to be more help to you.

Tom

[Discuss-gnuradio] Re: High CPU usage

On Fri, Feb 25, 2011 at 3:47 PM, peng senl <pengsenl@yahoo.com.cn> wrote:


> The legacy driver or UHD? Are you using 32-bit complex
> floats or
> 16-bit complex shorts for you data?

In my case, I am using GNU Radio with USRP2 in C++.
The CPU usage for 5MHz is 30% with 3.2 G duo core CPU and around 70% for 20MHz sample frequency.

> I'd be very interested to hear your benchmarking of the
> different
> types here. That is UHD/32fc vs. USRP2/32fc and UHD/16sc
> vs.
> USRP2/16sc. Also, UHD/32fc vs. UHD/16sc.

I just read data coming over the Ethernet. I did not even convert from big to little endian or convert data to other format. So I try to minimize the operations. But I still get such a high CPU usage. I wondering is it possible to simplify the data receive operations.

Ok, that didn't answer my question at all. HOW are you reading them from the Ethernet port? Which function are you calling in the USRP2 library to do this? Or which GNU Radio usrp2_source_XXX are you using (usrp2_source_32fc or usrp2_soruce_16sc)?

Tom


Re: [Discuss-gnuradio] OFDM mod/demod test code

On Wed, Feb 23, 2011 at 5:41 PM, Tuan (Johnny) Ta <ta.tuanm@gmail.com> wrote:
A lot of people seem to have problem with the OFDM receiver in gnuradio. Since there's no confirmation of a working 2-way communication using OFDM yet, I've decided to dig into the OFDM receiver implementation. I want to test the performance of the OFDM synchronization block. To do that, first I want to isolate the ofdm_sync block and make sure the rest of the chain works.

I found that there is a test file for OFDM mod and demod, named ofdm_mod_demod_test.py, without invoking OFDM synchronization, FFT, preamble and cyclic. However, that code is outdated and not applicable for the current implementation.

I'm trying to generate similar test code for the current version of OFDM mod and demod but there seems to be no straight-forward way. It used to be that we can hook the ofdm_mapper straight into an ofdm_frame_sink. It's no long the case as the frame_sink now requires a 2nd input, which is a stream of bytes signaling the beginning of a symbol. This input is provided by ofdm_frame_acquisition, which in turn requires the signaling from the ofdm_sampler. The ofdm_sampler gets the signaling from the ofdm_sync x_x.

Long story short, I haven't found a way to test the system while bypassing the ofdm_sync block yet. Can anyone give me some suggestion?

Thanks a lot,

Johnny

Johnny,
Try using the "fixed" version of the ofdm_sync block found on line 96 of ofdm_receiver.py. This takes information about what you expect the timing and frequency offset to be and does nothing but use that to trigger the follow-on components. It was made for doing exactly the kind of things you are looking at doing.

Tom