[Hackrf-dev] <DKIM> Re: HackRF with Raspberry Pi 2 Overruns
Paul Connolly
eeipcy at gmail.com
Tue Mar 3 16:19:23 EST 2015
> Is this a problem with the RP B/B+ or the RP 2B or all of the above?
Short answer:
All of the above.
Longer answer:
The real way to resolve a USB performance issue in the RPi hardware design is to either wait for Broadcom to release a version of the CPU/board with non-hub USB 2.0 port(s) (maybe the RPi 2 A), or simply do not use the RPi for any task that requires the movement of large amounts of data about fast. Its USB performance is broken by design, price was the primary design goal, and a lot of non-optimal design decisions were made, to achieve the price point.
For software defined radio it is currently a bad choice of hardware
except for maybe the Funcube Pro/+ at 9600Hz/19200Hz bandwidth.
RPi Model A and Model A+
--------------------------------------
It has a single dedicated USB 2.0 port, so maybe the throughput
performance issue may not be there. But even if you could read the data
in there is nowhere to send it. And the CPU only has equivalent
performance 300 MHz Pentium II of 1997-1999, so it can not process the
data in real time. And there is nowhere to buffer it to so unless you
are only processing a few seconds of data in non-realtime, this is no good.
RPi Model B
--------------------
It has a single USB 2.0 port, with a 3 port hub provided by the
Microchip LAN9512 (one of the ports has a 10/100 ethernet connected at
all times). But even if you could read the data in there is nowhere to
send it (if you sent it to another USB device the throughput would be
halved straight away). And again the CPU only has equivalent performance
300 MHz Pentium II of 1997-1999, so it can not process the data in real
time.
RPI Model B+
----------------------
It has a single USB 2.0 port, with a 5 port hub provided by the
Microchip LAN9514 (one of the ports has a 10/100 ethernet connected at
all times). But even if you could read the data in there is nowhere to
send it (if you sent it to another USB device the throughput would be
halved straight away). And again the CPU only has equivalent performance
300 MHz Pentium II of 1997-1999, so it can not process the data in real
time.
RPi Generation 2 Model B
------------------------------------
It has a single USB 2.0 port, with a 5 port hub provided by the
Microchip LAN9514 (one of the ports has a 10/100 ethernet connected at
all times). But even if you could read the data in there is nowhere to
send it (if you sent it to another USB device the throughput would be
halved straight away). Ok the CPU's in total are about 6x the
performance of the original RPi so it could be very roughly equivalent
in performance, if the application is multi-threaded, to a 1200 MHz
Pentium III chip from 2001-2002.
On 03/03/2015 19:06, rgk wrote:
> Is this a problem with the RP B/B+ or the RP 2B or all of the above? All the RP's have the same IO chip, but the Pi 2B has a totally different CPU and that new chip on the bottom of the board. If I sound non-specific it's because I just got a Pi 2B and have had little time to research its new features and capabilities. I think if the IO chip is the problem (just not enough throughput) then what can be done to minimize the over run issues?
>
>
> Date: Tue, 3 Mar 2015 08:45:01 +0100
> From: emmanuel.fuste at laposte.net
> To: hackrf-dev at greatscottgadgets.com
> Subject: Re: [Hackrf-dev] <DKIM> Re: HackRF with Raspberry Pi 2 Overruns
>
>
>
>
>
>
> It is a congenital deficiency of the
> RPi. It needs near realtime response and an awfull amount of CPU
> to not drop usb transactions.
>
> Search Rpi usb split transaction on google.
>
>
>
> Emmanuel.
>
> Le 03/03/2015 04:36, Silverfox a écrit :
>
>
>
>
>
>
>
>
> I
> don't think it is unreasonable for the PI to cause overruns
> but others may prove me wrong. It takes considerable
> horsepower to process the data without overruns. However,
> if you aren't doing heavy processing in the flowchart. FFT
> is probably the biggest consumer of cycles.
> 73,
> Alan
> - W6ARH
>
>
> From:
> HackRF-dev
> [mailto:hackrf-dev-bounces at greatscottgadgets.com] On
> Behalf Of Derek Murphy
>
> Sent: Monday, March 2, 2015 6:41 PM
>
> Cc: hackrf-dev at greatscottgadgets.com
>
> Subject: Re: [Hackrf-dev] HackRF with Raspberry Pi
> 2 Overruns
>
>
>
> Donald, I changed the sample to 2e6 and
> then up to 4e6, both way the Overrun indicator starts to
> appear faster and then fills the terminal window faster.
>
>
>
>
> I am not sure if I have something wrong
> with the driver or kernel config. It's a stock kernel from
> the raspbian distro. I tried a couple of different USB
> ports on the pi with no change.
>
>
>
>
>
> On Mon, Mar 2, 2015 at 2:22 PM, rgk
> <rgkenders at hotmail.com>
> wrote:
>
>
>
>
> I am currently building a completely portable pi 2
> setup that runs off of LIPOs. This is my intended
> purpose...IE my hackRF on my pi. I'm very interested
> in what others have done similar to this.
>
>
>
> From: cyrus104 at gmail.com
>
> Date: Mon, 2 Mar 2015 08:00:50 -0500
>
> To: hackrf-dev at greatscottgadgets.com
>
> Subject: [Hackrf-dev] HackRF with Raspberry Pi 2
> Overruns
>
>
>
>
> I wanted to see if anyone
> has had similar experience with the Raspberry
> Pi / Pi 2 with regards to the HackRF.
>
>
>
>
> The USB port bandwidth
> was was around 18MB when I ran the transfer
> test.
>
>
>
>
>
> When I get into GNU, I
> have a very simple example that show the
> standard fft on coming from the hackrf
> source. I have the sample rate set to 1.0e6
> but also run into similar issues when I run
> at 64k. I get the OOOOOO being posted and
> not just when I start the application.
>
>
>
>
>
> Thanks
>
>
>
>
>
> _______________________________________________
> HackRF-dev mailing list HackRF-dev at greatscottgadgets.com
> https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
>
>
>
>
>
>
>
>
> No
> virus found in this message.
>
> Checked by AVG - www.avg.com
>
> Version: 2015.0.5751 / Virus Database: 4299/9207 - Release
> Date: 03/01/15
>
>
>
>
>
>
> _______________________________________________
> HackRF-dev mailing list
> HackRF-dev at greatscottgadgets.com
> https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
>
>
>
>
>
>
>
> _______________________________________________
> HackRF-dev mailing list
> HackRF-dev at greatscottgadgets.com
> https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
>
>
> _______________________________________________
> HackRF-dev mailing list
> HackRF-dev at greatscottgadgets.com
> https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist9.pair.net/pipermail/hackrf-dev/attachments/20150303/0ffaf17b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 834 bytes
Desc: OpenPGP digital signature
URL: <https://pairlist9.pair.net/pipermail/hackrf-dev/attachments/20150303/0ffaf17b/attachment.pgp>
More information about the HackRF-dev
mailing list