Re: [Discuss-gnuradio] Qt app with GNURadio

[Pol Henarejos]

Hi Josh,

It seems you are right. Even though all libraries were in release mode,
my app was in debug. I recompiled it in release and everything goes
fine. I recompiled boost, uhd, qt, gnuradio and my app in debug and it
does not work. Do you know why?

Thanks.


Pol Henarejos
Research Engineer, MSc
pol.henare...@cttc.es

Centre Tecnològic de Telecomunicacions de Catalunya (CTTC)
Engineering Unit
Parc Mediterrani de la Tecnologia
Av. Carl Friedrich Gauss, 7
08860 Castelldefels, Barcelona (Spain)
Tel: +34 93 396 71 70  Ext: 2177
Fax. +34 93 645 29 01
www.cttc.es

El 29/05/2012 8:47, Pol Henarejos escribió:
> Hi Josh,
> 
> Yes, gnuradio, boost, qt and uhd are in release mode. I enabled /debug
> and /Zi in gnuradio once to debug. I also tried without these flags.
> 
> Thanks.
> 
> 
>> Could you provide me some hint? I am using the latest git version of
>> gnuradio compiled with Boost 1.44 and MSVC10 using CMake 2.8.5. The Qt
>> version is 4.8.1. All libraries are compiled with MSVC10 and x64 on
>> Windows 7 x64.
>>
> 
> Any chance there there is a mismatch between client app and gnuradio
> dlls? Like release mode set for one and debug mode set for another?
> 
> -josh
> 



signature.asc
Description: OpenPGP digital signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] query on USRP MIMO synchronization using GPSDO

[bharadwaj desikan]

Dear all,

I am planning to purchase a gpsdo kit from ettus research to set up a 2X2
mimo system using 4 usrp2s. I need your help in answering a few questions
that i have.

is the gpsdo kit only meant fro the usrpN series devices only? or can they
be used with usrp2 also?

in order to sync 2 Tx and 2 Rx receivers, can the clock out and pps out be
split to feed these  usrps?

thanks in advance


Thanks
Regards

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

Re: [Discuss-gnuradio] query on USRP MIMO synchronization using GPSDO

[mleech]

 

On 29 May 2012 09:27, bharadwaj desikan wrote: 

> Dear all,
> 
> I
am planning to purchase a gpsdo kit from ettus research to set up a 2X2
mimo system using 4 usrp2s. I need your help in answering a few
questions that i have.
> 
> is the gpsdo kit only meant fro the usrpN
series devices only? or can they be used with usrp2 also?
> 
> in order
to sync 2 Tx and 2 Rx receivers, can the clock out and pps out be split
to feed these usrps?
> 
> thanks in advance
> 
> Thanks
> Regards
> 
>
Bharadwaj D

The GPSDO Ettus supplies is really intended to be used "in
skin" in N2XX or E1XX-series devices. 

However, if you supply proper
power to it via an external power supply it could be used stand-alone,
and the outputs split to multiple devices, although you may need to use
an active splitter. 

-Marcus 

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

[Discuss-gnuradio] My app waits undefinedly after an O printf

[Pol Henarejos]

Dear list,

I am using gr_uhd_source as the source of my app. At some moment, there
is an overflow, an O is printf'ed and the scheduler stops. The program
is still running but there is no flow of samples between blocks. They
are waiting for something. I added the following lines in the work() of
gr_uhd_source

printf("no = %d\n", noutput_items);
if (_metadata.error_code != uhd::rx_metadata_t::ERROR_CODE_NONE)
printf("Error %d\n",_metadata.error_code);

and the output, after some time, is

no = 4094
no = 4096
no = 4094
[...]
no = 4096
no = 4094
no = 4096
no = 4096
Ono = 4094
no = 2133
Error 8
no = 2133
Error 1

and here waits for some thing and no more printf take place. Be aware
that this happens when the O appears.

Anybody is expecting the same? Could you provide me some hint?

Thanks.

-- 

Pol Henarejos
Research Engineer, MSc
pol.henare...@cttc.es

Centre Tecnològic de Telecomunicacions de Catalunya (CTTC)
Engineering Unit
Parc Mediterrani de la Tecnologia
Av. Carl Friedrich Gauss, 7
08860 Castelldefels, Barcelona (Spain)
Tel: +34 93 396 71 70  Ext: 2177
Fax. +34 93 645 29 01
www.cttc.es



signature.asc
Description: OpenPGP digital signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Hardware information page

[mleech]

 

The hardware information page here:


http://gnuradio.org/redmine/projects/gnuradio/wiki/Hardware#RTL2832-TV-tuners


Refers to the gr-baz RTL-SDR driver, which, IMHO isn't as good as the
gr-osmosdr drivers, here: 

http://sdr.osmocom.org/trac/wiki/rtl-sdr


AMONG OTHER THINGS THE GR-OSMOSDR DRIVERS USE A BETTER (LESS BUGGY)
E4000 TUNER IMPLEMENTATION, AND ALSO SUPPORT MULTIPLE DEVICE CLASSES IN
A UNIVERSAL WRAPPER:

FCD, RTL-SDR, UHD, OSMOSDR, and their own
remote-tcp implementation are all supported for their "source" class.


-Marcus 

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

Re: [Discuss-gnuradio] My app waits undefinedly after an O printf

[Josh Blum]

On 05/29/2012 07:29 AM, Pol Henarejos wrote:
> Dear list,
> 
> I am using gr_uhd_source as the source of my app. At some moment, there
> is an overflow, an O is printf'ed and the scheduler stops. The program
> is still running but there is no flow of samples between blocks. They
> are waiting for something. I added the following lines in the work() of
> gr_uhd_source
> 
> printf("no = %d\n", noutput_items);
> if (_metadata.error_code != uhd::rx_metadata_t::ERROR_CODE_NONE)
>   printf("Error %d\n",_metadata.error_code);
> 
> and the output, after some time, is
> 
> no = 4094
> no = 4096
> no = 4094
> [...]
> no = 4096
> no = 4094
> no = 4096
> no = 4096
> Ono = 4094
> no = 2133
> Error 8
> no = 2133
> Error 1
> 
> and here waits for some thing and no more printf take place. Be aware
> that this happens when the O appears.
> 
> Anybody is expecting the same? Could you provide me some hint?
> 

Whats the hardware? Sample rate? And I suppose UHD version as well.

It looks to me like there is an overflow (code 8), and then a timeout
(code 1). I bet the scheduler then prints "block returned 0 marking it
done" something like that...

So it looks to me that the overflow condition is shutting off the
streaming, and UHD is not automatically tuning streaming back on.
Hmm thats not right.

So let me know the hardware and I will try to replicate the fix the issue.

-josh

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

Re: [Discuss-gnuradio] Qt app with GNURadio

[Josh Blum]

On 05/29/2012 01:22 AM, Pol Henarejos wrote:
> Hi Josh,
> 
> It seems you are right. Even though all libraries were in release mode,

Im glad its working for you!

> my app was in debug. I recompiled it in release and everything goes
> fine. I recompiled boost, uhd, qt, gnuradio and my app in debug and it
> does not work. Do you know why?
> 

Are you seeing segfault type of behaviour?

I think there is at least one lib or dll thats ABI mismatched (you know
debug vs release). It only takes one to be incorrect. Gnuradio has quite
a few dependencies as well like FFTW, GSL

Maybe try to narrow down which library is the problem by building a
non-gui application for example (uhd + gnuradio, no qt).

-josh

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

Re: [Discuss-gnuradio] [USRP-users] what is the largest data transfer rate between fpga and overo in e100

[Philip Balister]

On 05/25/2012 09:18 PM, Page Jack wrote:
> Hi Philip,
> How does the conclusion be made that ARM can not swallow the current
> max data transfer rate? I need to build a project that need to process
> 60MB/s data, so any way to achieve my goal. Use a more powerful CPU or
> use dsp on the omap?

60 MB/s is far more data than the OMAP3 can transfer from the FPGA. We
have worked hard on configuring the GPMC interface and this figure is
basically an order of magnitude more then the hardware will support.

You need to look at the N series with Gig-E, or do the high rate
processing in the FPGA.

Philip


> 
> On 5/25/12, Philip Balister  wrote:
>> On 05/24/2012 09:46 PM, Page Jack wrote:
>>> Thanks Ben,
>>> does e100 use EMIF to transfer sample data between FPGA and ARM? If so
>>> the
>>> data rate should be able to improved.
>>> Anyone have tried to improve the data rate?
>>
>> EMIF is basically identical to GPMC. The interface uses DMA to move data
>> in 2K chunks between the FPGA and memory. This is the largest transfer
>> possible due to how we connected the address and data lines
>>
>> My impression of the current limiting factor is interrupt response time.
>> There is probably some room for small improvements, but as Ben notes, we
>> are already collecting data faster than the ARM can swallow it.
>>
>> Philip
>>
>>>
>>> Regards
>>>
>>> On Thu, May 24, 2012 at 9:01 AM, Ben Hilburn 
>>> wrote:
>>>
 The CPU sets up the initial DMA parameters, but from then on, it's pure
 DMA.  No CPU is required.

 Cheers,
 Ben
 
 Ben Hilburn  @ Ettus Research,
 LLC



 On Wed, May 23, 2012 at 5:55 PM, Page Jack 
 wrote:

> Thanks, does the ARM memory bus use DMA or it eat cpu?
>
>
> On Thu, May 24, 2012 at 5:06 AM, Ben Hilburn
> wrote:
>
>> Page -
>>
>> The memory bus to the ARM provides 40 MBytes / second.  This is used
>> for
>> streaming samples, as controlled via software.  Currently, UHD supports
>> 16
>> bit and 8 bit samples for TX & RX.  The GPMC can only going to talk to
>> one
>> slave at a time; the possible slaves are TX, RX, and ethernet.  So you
>> can
>> only be sending TX samples, receiving RX samples, or communicating via
>> ethernet.
>>
>> Thus, doing the math with the numbers above, you can stream:
>> 16 bit I, 16 bit Q -- Total: 32-bit samples -- @ 10 MSps
>> 8 bit I, 8 bit Q -- Total: 16-bit samples -- @ 20 MSps
>>
>> What you choose to do with this data is obviously up to you. It is
>> very
>> easy to try to do more processing than the ARM can handle, in which
>> case
>> samples will start getting thrown out by UHD.  Thus, you can typically
>> process between 4 and 8 MHz of baseband bandwidth, depending on your
>> application.  If you are willing to dig deep into the code to make NEON
>> and
>> C64 optimizations, you can improve the performance dramatically.
>>
>> Cheers,
>> Ben
>> 
>> Ben Hilburn  @ Ettus Research,
>> LLC
>>
>>
>>
>> On Tue, May 22, 2012 at 7:47 PM, Page Jack
>> wrote:
>>
>>> Hi,
>>> I want to know the overo model used in e100 and the largest data
>>> transfer rate between fpga  and overo in e100.
>>>
>>> Regards!
>>>
>>> ___
>>> USRP-users mailing list
>>> usrp-us...@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>
>

>>>
>>>
>>>
>>> ___
>>> USRP-users mailing list
>>> usrp-us...@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
> 
> ___
> USRP-users mailing list
> usrp-us...@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 

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

[Discuss-gnuradio] Multiple USRP N210s: LEDs and Ethernet lights on after program termination

[Ryan Wolfarth]

Hi list,

We've setup 4 USRP N210 rev4s with a Dell PowerEdge R510 server to collect
RF data for GPS related experiments.  The server works great and we seem to
be able to write 20 Msps from each device simultaneously to a RAID array
with no overflows.  However, after each collection program is terminated,
the Ethernet and debugging LEDs (C, D, blinking E, and F) remain on.  We
tested this with a single device with the same result.  Does anybody know
the cause of this and if we should be worried?  We're running UHD 3.4.2
(downloaded 2 days ago).  All N210s were updated with the firmware/image
downloaded from the same version and compiled from source using GNU ZPU
Tools and Xilinx ISE 13.1 respectively.  The server is running 64-bit
Ubuntu 12.04.  Any help is appreciated!

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

Re: [Discuss-gnuradio] [USRP-users] what is the largest data transfer rate between fpga and overo in e100

[Page Jack]

I don't want to using a ethernet wire to connect N series to an ARM board.
anyone have tried
build N series with ARM or DSP in one board which means the ethernet line
between N and
the processor is on PCB.

On Wed, May 30, 2012 at 6:24 AM, Philip Balister wrote:

> On 05/25/2012 09:18 PM, Page Jack wrote:
> > Hi Philip,
> > How does the conclusion be made that ARM can not swallow the current
> > max data transfer rate? I need to build a project that need to process
> > 60MB/s data, so any way to achieve my goal. Use a more powerful CPU or
> > use dsp on the omap?
>
> 60 MB/s is far more data than the OMAP3 can transfer from the FPGA. We
> have worked hard on configuring the GPMC interface and this figure is
> basically an order of magnitude more then the hardware will support.
>
> You need to look at the N series with Gig-E, or do the high rate
> processing in the FPGA.
>
> Philip
>
>
> >
> > On 5/25/12, Philip Balister  wrote:
> >> On 05/24/2012 09:46 PM, Page Jack wrote:
> >>> Thanks Ben,
> >>> does e100 use EMIF to transfer sample data between FPGA and ARM? If so
> >>> the
> >>> data rate should be able to improved.
> >>> Anyone have tried to improve the data rate?
> >>
> >> EMIF is basically identical to GPMC. The interface uses DMA to move data
> >> in 2K chunks between the FPGA and memory. This is the largest transfer
> >> possible due to how we connected the address and data lines
> >>
> >> My impression of the current limiting factor is interrupt response time.
> >> There is probably some room for small improvements, but as Ben notes, we
> >> are already collecting data faster than the ARM can swallow it.
> >>
> >> Philip
> >>
> >>>
> >>> Regards
> >>>
> >>> On Thu, May 24, 2012 at 9:01 AM, Ben Hilburn 
> >>> wrote:
> >>>
>  The CPU sets up the initial DMA parameters, but from then on, it's
> pure
>  DMA.  No CPU is required.
> 
>  Cheers,
>  Ben
>  
>  Ben Hilburn  @ Ettus Research,
>  LLC
> 
> 
> 
>  On Wed, May 23, 2012 at 5:55 PM, Page Jack 
>  wrote:
> 
> > Thanks, does the ARM memory bus use DMA or it eat cpu?
> >
> >
> > On Thu, May 24, 2012 at 5:06 AM, Ben Hilburn
> > wrote:
> >
> >> Page -
> >>
> >> The memory bus to the ARM provides 40 MBytes / second.  This is used
> >> for
> >> streaming samples, as controlled via software.  Currently, UHD
> supports
> >> 16
> >> bit and 8 bit samples for TX & RX.  The GPMC can only going to talk
> to
> >> one
> >> slave at a time; the possible slaves are TX, RX, and ethernet.  So
> you
> >> can
> >> only be sending TX samples, receiving RX samples, or communicating
> via
> >> ethernet.
> >>
> >> Thus, doing the math with the numbers above, you can stream:
> >> 16 bit I, 16 bit Q -- Total: 32-bit samples -- @ 10 MSps
> >> 8 bit I, 8 bit Q -- Total: 16-bit samples -- @ 20 MSps
> >>
> >> What you choose to do with this data is obviously up to you. It is
> >> very
> >> easy to try to do more processing than the ARM can handle, in which
> >> case
> >> samples will start getting thrown out by UHD.  Thus, you can
> typically
> >> process between 4 and 8 MHz of baseband bandwidth, depending on your
> >> application.  If you are willing to dig deep into the code to make
> NEON
> >> and
> >> C64 optimizations, you can improve the performance dramatically.
> >>
> >> Cheers,
> >> Ben
> >> 
> >> Ben Hilburn  @ Ettus Research,
> >> LLC
> >>
> >>
> >>
> >> On Tue, May 22, 2012 at 7:47 PM, Page Jack
> >> wrote:
> >>
> >>> Hi,
> >>> I want to know the overo model used in e100 and the largest data
> >>> transfer rate between fpga  and overo in e100.
> >>>
> >>> Regards!
> >>>
> >>> ___
> >>> USRP-users mailing list
> >>> usrp-us...@lists.ettus.com
> >>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >>>
> >>>
> >>
> >
> 
> >>>
> >>>
> >>>
> >>> ___
> >>> USRP-users mailing list
> >>> usrp-us...@lists.ettus.com
> >>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >>
> >
> > ___
> > USRP-users mailing list
> > usrp-us...@lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Real-time fading simulation?

[J Mc]

I have been considering using GnuRadio with the USRPN210 as a realtime fading 
simulator for radio hardware testing, however any approaches I've considered in 
doing this seem to fall down fundamentally if I limit to using a single USRP. 
I'm still relatively sure it could be done, was wondering if anyone had any 
advice/input.

The main issue I've had is trying to understand how to do this with single 
antennas systems, if I take something like 2 cheap WiFi nodes both attached to 
a common Tx and Rx port is there any way to prevent the transmitting node's 
signal feedback when it hits the receiving node's antenna. If anyone has looked 
at this question, opinions would be appreciated...  
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Real-time fading simulation?

[Brian Padalino]

On Tue, May 29, 2012 at 9:47 PM, J Mc  wrote:
> I have been considering using GnuRadio with the USRPN210 as a realtime
> fading simulator for radio hardware testing, however any approaches I've
> considered in doing this seem to fall down fundamentally if I limit to using
> a single USRP. I'm still relatively sure it could be done, was wondering if
> anyone had any advice/input.
>
> The main issue I've had is trying to understand how to do this with single
> antennas systems, if I take something like 2 cheap WiFi nodes both attached
> to a common Tx and Rx port is there any way to prevent the transmitting
> node's signal feedback when it hits the receiving node's antenna. If anyone
> has looked at this question, opinions would be appreciated...

I think you can do it with an one USRP1, or two USRPN210s using some
circulators and a special FPGA load.

Circulators move in a clockwise motion:

[WiFi] <-> [ Circulator ] <-> [USRP Rx/Tx]
 ^
 |
 v
   [ Circulator ] <-> [WiFi]
 ^
 |
 v
[USRP Rx/Tx]

I think that diagram shows the WiFi card transmitting to the USRP
Rx/Tx port, the Tx from the USRP goes to the other circulator, and
into WiFi card.

The second WiFi card transmits into the circulator then into the USRP
Rx/Tx port, and the Tx from the USRP goes to the original circulator,
and into the original WiFi card.

FPGA load would essentially be programmable with your noise/fading
profile, and with little host intervention create noise on the
baseband then retransmit.

Does that work?

Brian

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

Re: [Discuss-gnuradio] Multiple USRP N210s: LEDs and Ethernet lights on after program termination

[Josh Blum]

On 05/29/2012 05:36 PM, Ryan Wolfarth wrote:
> Hi list,
> 
> We've setup 4 USRP N210 rev4s with a Dell PowerEdge R510 server to collect
> RF data for GPS related experiments.  The server works great and we seem to
> be able to write 20 Msps from each device simultaneously to a RAID array
> with no overflows.  However, after each collection program is terminated,
> the Ethernet and debugging LEDs (C, D, blinking E, and F) remain on.  We
> tested this with a single device with the same result.  Does anybody know
> the cause of this and if we should be worried?  We're running UHD 3.4.2
> (downloaded 2 days ago).  All N210s were updated with the firmware/image
> downloaded from the same version and compiled from source using GNU ZPU
> Tools and Xilinx ISE 13.1 respectively.  The server is running 64-bit
> Ubuntu 12.04.  Any help is appreciated!
> 

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

I would only really be worried about C which means the device is still
sending samples out of the ethernet port. This can happen if the
streaming isnt properly shutoff like ctrl+c or destructors not being called.

Additionally, (if it is still streaming) the USRP isnt getting an ICMP
destination unreachable from the host when the socket on the host
closes. Its possible that due to your network setup that this packet
doesnt get generated and/or delivered.

If it is the deconstructor issue, sometimes its useful in gr python apps
to set the top block object to None to help python garbage collect it.

tb.stop()
tb = None

I would also see if things shutoff as expected when your run one of the
included examples such as rx_timed_samples

Hope that helps!
-josh

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

Re: [Discuss-gnuradio] [USRP-users] what is the largest data transfer rate between fpga and overo in e100

[Almohanad Fayez]

If memory serves correctly the n200 or the usrp 2 has an fpga expansion
interface to some xilinx development platform which you might be able to
use to create a custom solution to serve your needs.

Al
On May 29, 2012 6:17 PM, "Page Jack"  wrote:

> I don't want to using a ethernet wire to connect N series to an ARM board.
> anyone have tried
> build N series with ARM or DSP in one board which means the ethernet line
> between N and
> the processor is on PCB.
>
> On Wed, May 30, 2012 at 6:24 AM, Philip Balister wrote:
>
>> On 05/25/2012 09:18 PM, Page Jack wrote:
>> > Hi Philip,
>> > How does the conclusion be made that ARM can not swallow the current
>> > max data transfer rate? I need to build a project that need to process
>> > 60MB/s data, so any way to achieve my goal. Use a more powerful CPU or
>> > use dsp on the omap?
>>
>> 60 MB/s is far more data than the OMAP3 can transfer from the FPGA. We
>> have worked hard on configuring the GPMC interface and this figure is
>> basically an order of magnitude more then the hardware will support.
>>
>> You need to look at the N series with Gig-E, or do the high rate
>> processing in the FPGA.
>>
>> Philip
>>
>>
>> >
>> > On 5/25/12, Philip Balister  wrote:
>> >> On 05/24/2012 09:46 PM, Page Jack wrote:
>> >>> Thanks Ben,
>> >>> does e100 use EMIF to transfer sample data between FPGA and ARM? If so
>> >>> the
>> >>> data rate should be able to improved.
>> >>> Anyone have tried to improve the data rate?
>> >>
>> >> EMIF is basically identical to GPMC. The interface uses DMA to move
>> data
>> >> in 2K chunks between the FPGA and memory. This is the largest transfer
>> >> possible due to how we connected the address and data lines
>> >>
>> >> My impression of the current limiting factor is interrupt response
>> time.
>> >> There is probably some room for small improvements, but as Ben notes,
>> we
>> >> are already collecting data faster than the ARM can swallow it.
>> >>
>> >> Philip
>> >>
>> >>>
>> >>> Regards
>> >>>
>> >>> On Thu, May 24, 2012 at 9:01 AM, Ben Hilburn 
>> >>> wrote:
>> >>>
>>  The CPU sets up the initial DMA parameters, but from then on, it's
>> pure
>>  DMA.  No CPU is required.
>> 
>>  Cheers,
>>  Ben
>>  
>>  Ben Hilburn  @ Ettus Research,
>>  LLC
>> 
>> 
>> 
>>  On Wed, May 23, 2012 at 5:55 PM, Page Jack 
>>  wrote:
>> 
>> > Thanks, does the ARM memory bus use DMA or it eat cpu?
>> >
>> >
>> > On Thu, May 24, 2012 at 5:06 AM, Ben Hilburn
>> > wrote:
>> >
>> >> Page -
>> >>
>> >> The memory bus to the ARM provides 40 MBytes / second.  This is
>> used
>> >> for
>> >> streaming samples, as controlled via software.  Currently, UHD
>> supports
>> >> 16
>> >> bit and 8 bit samples for TX & RX.  The GPMC can only going to
>> talk to
>> >> one
>> >> slave at a time; the possible slaves are TX, RX, and ethernet.  So
>> you
>> >> can
>> >> only be sending TX samples, receiving RX samples, or communicating
>> via
>> >> ethernet.
>> >>
>> >> Thus, doing the math with the numbers above, you can stream:
>> >> 16 bit I, 16 bit Q -- Total: 32-bit samples -- @ 10 MSps
>> >> 8 bit I, 8 bit Q -- Total: 16-bit samples -- @ 20 MSps
>> >>
>> >> What you choose to do with this data is obviously up to you. It is
>> >> very
>> >> easy to try to do more processing than the ARM can handle, in which
>> >> case
>> >> samples will start getting thrown out by UHD.  Thus, you can
>> typically
>> >> process between 4 and 8 MHz of baseband bandwidth, depending on
>> your
>> >> application.  If you are willing to dig deep into the code to make
>> NEON
>> >> and
>> >> C64 optimizations, you can improve the performance dramatically.
>> >>
>> >> Cheers,
>> >> Ben
>> >> 
>> >> Ben Hilburn  @ Ettus Research,
>> >> LLC
>> >>
>> >>
>> >>
>> >> On Tue, May 22, 2012 at 7:47 PM, Page Jack
>> >> wrote:
>> >>
>> >>> Hi,
>> >>> I want to know the overo model used in e100 and the largest data
>> >>> transfer rate between fpga  and overo in e100.
>> >>>
>> >>> Regards!
>> >>>
>> >>> ___
>> >>> USRP-users mailing list
>> >>> usrp-us...@lists.ettus.com
>> >>>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> >>>
>> >>>
>> >>
>> >
>> 
>> >>>
>> >>>
>> >>>
>> >>> ___
>> >>> USRP-users mailing list
>> >>> usrp-us...@lists.ettus.com
>> >>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> >>
>> >
>> > ___
>> > USRP-users mailing list
>> > usrp-us...@lists.ettus.com
>> > http://lists.ettus.com/m

[Discuss-gnuradio] Funcube dongle issues and a solution

[Gasper Zejn]

Hi,

I was using Funcube dongle and found a strange bug. Whenever I used the FCD 
source in my flow graph and started the flow, the (demodulated) signal came 
out corrupted. However, if I then just started qthid, it would correct itself 
and could see bits in waveform perfectly well. This was happening with 
different firmware versions.

With a bit of experimenting in the earlier out of tree gr-fcd, I found out 
that reverting two commits[1][2] resulted in resolving the issue.

I've made changes to in-tree gr-fcd and recompiled and it's now working in a 
way, but issues remain. One is setting frequency at runtime (via a variable), 
where FCD flips back into spitting out corrupted waveform.

This is where the problem outgrows my knowledge.



Kind regards,
Gasper Zejn


[1] https://github.com/csete/gr-
fcd/commit/02a773ebf5ce01b8f527fb8f8b6f74e6b8191cab
[2] https://github.com/csete/gr-
fcd/commit/407b4281dbc9b3bc7b1eb58a5fb8acf500607fda

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

Re: [Discuss-gnuradio] My app waits undefinedly after an O printf

[Pol Henarejos]

Dear Josh,

The hardware is USRP2 at 10Msps with latest UHD version
UHD_003.004.001-165-unstable.

As you pointed, it seems that does not restart the streamer. I made a
rough patch that works continously. I still get overflows but it does
not stop.

diff --git a/gr-uhd/lib/gr_uhd_usrp_source.cc
b/gr-uhd/lib/gr_uhd_usrp_source.cc
index 8aa9654..75ae3d6 100644
--- a/gr-uhd/lib/gr_uhd_usrp_source.cc
+++ b/gr-uhd/lib/gr_uhd_usrp_source.cc
@@ -368,10 +368,12 @@ public:
 case uhd::rx_metadata_t::ERROR_CODE_TIMEOUT:
 //Assume that the user called stop() on the flow graph.
 //However, a timeout can occur under error conditions.
-return WORK_DONE;
+  //  return WORK_DONE;

 case uhd::rx_metadata_t::ERROR_CODE_OVERFLOW:
 _tag_now = true;
+stop();
+start();
 //ignore overflows and try work again
 return work(noutput_items, input_items, output_items);

Mainly I made stop/start when timeout or overflow occurs.

Thanks.


On 05/29/2012 07:29 AM, Pol Henarejos wrote:
> Dear list,
>
> I am using gr_uhd_source as the source of my app. At some moment, there
> is an overflow, an O is printf'ed and the scheduler stops. The program
> is still running but there is no flow of samples between blocks. They
> are waiting for something. I added the following lines in the work() of
> gr_uhd_source
>
> printf("no = %d\n", noutput_items);
> if (_metadata.error_code != uhd::rx_metadata_t::ERROR_CODE_NONE)
>   printf("Error %d\n",_metadata.error_code);
>
> and the output, after some time, is
>
> no = 4094
> no = 4096
> no = 4094
> [...]
> no = 4096
> no = 4094
> no = 4096
> no = 4096
> Ono = 4094
> no = 2133
> Error 8
> no = 2133
> Error 1
>
> and here waits for some thing and no more printf take place. Be aware
> that this happens when the O appears.
>
> Anybody is expecting the same? Could you provide me some hint?
>

Whats the hardware? Sample rate? And I suppose UHD version as well.

It looks to me like there is an overflow (code 8), and then a timeout
(code 1). I bet the scheduler then prints "block returned 0 marking it
done" something like that...

So it looks to me that the overflow condition is shutting off the
streaming, and UHD is not automatically tuning streaming back on.
Hmm thats not right.

So let me know the hardware and I will try to replicate the fix the issue.

-josh

-- 

Pol Henarejos
Research Engineer, MSc
pol.henare...@cttc.es

Centre Tecnològic de Telecomunicacions de Catalunya (CTTC)
Engineering Unit
Parc Mediterrani de la Tecnologia
Av. Carl Friedrich Gauss, 7
08860 Castelldefels, Barcelona (Spain)
Tel: +34 93 396 71 70  Ext: 2177
Fax. +34 93 645 29 01
www.cttc.es



signature.asc
Description: OpenPGP digital signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio