Re: [Discuss-gnuradio] Funcube dongle issues and a solution

[Alexandru Csete]

On Wed, May 30, 2012 at 8:51 AM, Gasper Zejn  wrote:
> 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.

Hi Gasper,

Sounds to me like you are having some interference on the frequency
you are trying to use. Or maybe your are using the center of the
passband where we have a strong DC peak. I'm only guessing since you
don't give any details about your setup, e.g. what modulation are your
using, and how do you determine that your signal is corrupted.

The FCD source block in the master branch appears to work correctly
and I have no issues demodulating narrow band FM. I have no setup to
try digital modes. The commits you refer to are necessary for correct
setup and tuning of the FCD. If you revert them the FCD may not have
the correct initial setup or may have the settings from the last time
you were using it.

As said, I suspect you have some noise or interference in your filter
passband. Please provide more details about your setup, flowgraph,
etc. I found that plugging the FCD directly into the PC is a bad idea
causing strong interference. Always use an extension cable and
preferably also a USB hub between PC and FCD.

Alex

___
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 Wed, May 30, 2012 at 4:23 AM, J Mc  wrote:
>
>
>> Date: Tue, 29 May 2012 22:15:43 -0400
>> Subject: Re: [Discuss-gnuradio] Real-time fading simulation?
>> From: bpadal...@gmail.com
>> To: columbo_the_leg...@hotmail.com
>> CC: discuss-gnuradio@gnu.org
>
>>
>> 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
>
> I may be missing something however anyway I try construct this design on
> paper (which is variations on what I've been considering) the following
> issues seem to occur;
>
> -Many Daughterboards only have 1 Tx channel, which both the nodes must
> connect to, how at transmissions "addressed" i.e. the circulator won't be
> able to avoid this
> -Because WiFi and other standards that use TDD share a single antenna, they
> must near-simultaneously transmit and receiver. If a USRP Transmission is
> heard by the original node, it will create a feedback loop

That is why you need either 2 USRPN210's or 1 USRP1.  The USRP1 can
have 2 daughterboards which allows you to have 2 independent RX/TX
ports.  The circulators handle the rest for you.

You're correct that using a single TX on a single daughterboard isn't
good enough.

> For the fading I was thinking of just using gnuradio without any FPGA
> alterations, (theres a fading model/noise sources/notch filters), my only
> uncertainty is the ability to receiver and transmit to the same USRP on
> different antenna ports.

I believe there are latency requirements in 802.11 that may be
difficult/impossible to achieve if you're shipping samples back and
forth.  If latency isn't a concern, I think that the above setup
should be valid.

Do you agree?

Brian

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

Hi Almohanad ,
thanks for this information, can you provide more detail or is there any doc?

On 5/30/12, Almohanad Fayez  wrote:
> 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
>>> >>>
>>> >>>
>>> >>
>>> >
>>> 
>>> >>>
>>> >>>

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

[Almohanad Fayez]

I don't believe there's a document for this it's more of an exercise left
for the motivated user.
On May 30, 2012 6:27 AM, "Page Jack"  wrote:

> Hi Almohanad ,
> thanks for this information, can you provide more detail or is there any
> doc?
>
> On 5/30/12, Almohanad Fayez  wrote:
> > 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 <
> ben.hilb...@ettus.com>
> >>> >>> 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 <
> jack.page...@gmail.com>
> >>>  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:
> >>> >>

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

[Ryan Wolfarth]

Hi Josh,

Thanks for your quick reply!  We are actually using rx_samples_to_file as a
first attempt at benchmarking the systems data transfer speed.  We give a
proper crtl+c whenever we terminate the program, but the problem persists.
We tried rx_timed_samples per your recommendation and found that the port
and USRP terminated properly.  The program doesn't seem to be modified from
previous releases, so my first blind guess is that there could be an issue
with the interface on one side of our network card (Intel 82576 Gigabit
controller).

Due to the simplicity of our data collection scheme, we will probably
modify rx_samples_to_file to respond to an external trigger.  So if we
could get the example working properly that would be a great starting
point.  Do you have any more ideas?

Thanks again,
Ryan

On Tue, May 29, 2012 at 11:09 PM, Josh Blum  wrote:

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

[Darren Long]

I've noticed that when stopping a GRC sketch and starting another, I get 
unknown stream ID reports from my B100, requiring a restart of the USRP to 
recover. This used to happen a while back, but was fixed. Perhaps the fix has 
been broken or the issue is similar.

Darren

Sent from my iPhone

On 30 May 2012, at 16:23, Ryan Wolfarth  wrote:

> Hi Josh,
> 
> Thanks for your quick reply!  We are actually using rx_samples_to_file as a 
> first attempt at benchmarking the systems data transfer speed.  We give a 
> proper crtl+c whenever we terminate the program, but the problem persists.  
> We tried rx_timed_samples per your recommendation and found that the port and 
> USRP terminated properly.  The program doesn't seem to be modified from 
> previous releases, so my first blind guess is that there could be an issue 
> with the interface on one side of our network card (Intel 82576 Gigabit 
> controller).  
> 
> Due to the simplicity of our data collection scheme, we will probably modify 
> rx_samples_to_file to respond to an external trigger.  So if we could get the 
> example working properly that would be a great starting point.  Do you have 
> any more ideas?
> 
> Thanks again,
> Ryan
> 
> On Tue, May 29, 2012 at 11:09 PM, Josh Blum  wrote:
> 
> 
> 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
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[Ian Buckley]

There is a mictor connector (J301 on both USRP2 and N2x0) that has 32 signal 
and 2 clock pins all free to be used in the FPGA. Searching for "mictor" in the 
archive of this forum will find other posts about this.

However I do want to drive home the point  that you are unlikely to find an ARM 
processor currently that is capable of doing anything useful directly with RF 
data at bandwidths greater than which the E100 is capable or indeed one with a 
flexible physical interface that can support 60MB/syou're clearly in the 
realm of high-end DSP processors at those rates.


On May 30, 2012, at 8:02 AM, Almohanad Fayez wrote:

> I don't believe there's a document for this it's more of an exercise left for 
> the motivated user.
> 
> On May 30, 2012 6:27 AM, "Page Jack"  wrote:
> Hi Almohanad ,
> thanks for this information, can you provide more detail or is there any doc?
> 
> On 5/30/12, Almohanad Fayez  wrote:
> > 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 betwee

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

[Ryan Wolfarth]

Problem solved!  rx_samples_to_file doesn't include a stream_cmd_stop!
Here's our fix:

Add the following after line 93 (outfile.close()):

if(!num_requested_samples){
uhd::stream_cmd_t
stream_cmd_stop(uhd::stream_cmd_t::STREAM_MODE_STOP_CONTINUOUS);
usrp->issue_stream_cmd(stream_cmd_stop);
}

This seems to do the trick.  The C debug light is off as is the Ethernet
link activity light!

-Ryan

On Wed, May 30, 2012 at 11:35 AM, Darren Long  wrote:

> I've noticed that when stopping a GRC sketch and starting another, I get
> unknown stream ID reports from my B100, requiring a restart of the USRP to
> recover. This used to happen a while back, but was fixed. Perhaps the fix
> has been broken or the issue is similar.
>
> Darren
>
> Sent from my iPhone
>
> On 30 May 2012, at 16:23, Ryan Wolfarth  wrote:
>
> Hi Josh,
>
> Thanks for your quick reply!  We are actually using rx_samples_to_file as
> a first attempt at benchmarking the systems data transfer speed.  We give a
> proper crtl+c whenever we terminate the program, but the problem persists.
> We tried rx_timed_samples per your recommendation and found that the port
> and USRP terminated properly.  The program doesn't seem to be modified from
> previous releases, so my first blind guess is that there could be an issue
> with the interface on one side of our network card (Intel 82576 Gigabit
> controller).
>
> Due to the simplicity of our data collection scheme, we will probably
> modify rx_samples_to_file to respond to an external trigger.  So if we
> could get the example working properly that would be a great starting
> point.  Do you have any more ideas?
>
> Thanks again,
> Ryan
>
> On Tue, May 29, 2012 at 11:09 PM, Josh Blum  wrote:
>
>>
>>
>> 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
>>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[Marcus D. Leech]

There is a mictor connector (J301 on both USRP2 and N2x0) that has 32 
signal and 2 clock pins all free to be used in the FPGA. Searching for 
"mictor" in the archive of this forum will find other posts about this.


However I do want to drive home the point  that you are unlikely to 
find an ARM processor currently that is capable of doing anything 
useful directly with RF data at bandwidths greater than which the E100 
is capable or indeed one with a flexible physical interface that can 
support 60MB/syou're clearly in the realm of high-end DSP 
processors at those rates.


Well, keep in mind that if the goal is really 60MB/s, rather than 
60Msps, that's only about a factor of 5 beyond what an ARM can resonably

  do for lightweight processing.




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



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

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

[Philip Balister]

On 05/30/2012 11:46 AM, Ian Buckley wrote:
> There is a mictor connector (J301 on both USRP2 and N2x0) that has 32 signal 
> and 2 clock pins all free to be used in the FPGA. Searching for "mictor" in 
> the archive of this forum will find other posts about this.
> 
> However I do want to drive home the point  that you are unlikely to find an 
> ARM processor currently that is capable of doing anything useful directly 
> with RF data at bandwidths greater than which the E100 is capable or indeed 
> one with a flexible physical interface that can support 60MB/syou're 
> clearly in the realm of high-end DSP processors at those rates.

If you need to do the processing on an ARM, you should research this
company:

http://www.calxeda.com/products/energycards/quadnode

Philip

> 
> 
> On May 30, 2012, at 8:02 AM, Almohanad Fayez wrote:
> 
>> I don't believe there's a document for this it's more of an exercise left 
>> for the motivated user.
>>
>> On May 30, 2012 6:27 AM, "Page Jack"  wrote:
>> Hi Almohanad ,
>> thanks for this information, can you provide more detail or is there any doc?
>>
>> On 5/30/12, Almohanad Fayez  wrote:
>>> 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
>>> 

[Discuss-gnuradio] File sink file size mismatch problem.

[Josh Stevens]

Hello All,

  A couple of days ago i had installed a GNURadio digital image
processing block that makes an image source and sink block available as
displayed in the image below.
 *Resource* : https://github.com/a-w-s/GNURadio-DIP
 *Flowgraph* : http://i.imgur.com/1lJzD.png

The output of the image source and the input to the image sink are "floats"
only and nothing else. I tried to collect pixel information into a file
sink and i am successful at that but the problem comes in when the size of
the input file size is not the same as the size of the file sink output.

The image is a basic black and white test image called lena.bmp whose file
size is 65.0 KB. The link to which is also provided below ,
*Resource to Image :*
https://www.google.com/search?q=lena+256+x+256&hl=en&prmd=imvns&source=lnms&tbm=isch&ei=_G7GT7vkC4rs8wSG99SaBg&sa=X&oi=mode_link&ct=mode&cd=2&sqi=2&ved=0CD8Q_AUoAQ&biw=1280&bih=827

The file size of the received file (file sink) is 76.0 KB.

The reason why I pay more attention to this is because i intend to
calculate BER / Pixel Error Rate which would take into account a reference
stream which in this case would be the file with the extra bits , and Image
sink output ( or the demodulated output) .

Please feel free to ask me any questions that one might have .

Thanks and regards,
Josh.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] QAM Mod and QAM Demod block in GRC

[jiajue ou]

Hi all, 

 

I'm working on an experiment which needs to modify qam modulation block in
gnuradio. But I cannot find the source C++ file the qam blocks use. e.g.,
OFDM demod block uses digital_ofdm_frame_sink in
gnuradiobuild/gnuradio/gr-digital/lib. What about qam blocks? 

Thank you for your help!

 

Best,

jia

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