[Hackrf-dev] <DKIM> Re: <DKIM> Re: HackRF with Raspberry Pi 2 Overruns
rgk
rgkenders at hotmail.com
Thu Mar 5 11:34:28 EST 2015
It would seem that any hi-bandwidth use of USB regardless of whether its on a pi or on a PC is going to be the same. A typical laptop has a chip in it that handles USB IO and contains a USB hub. The HackRF works OK there. This in my opinion is not the issue. It has to be the CPU...can it handle the work load or not.
Date: Wed, 4 Mar 2015 08:25:30 +0100
From: emmanuel.fuste at laposte.net
To: hackrf-dev at greatscottgadgets.com
Subject: Re: [Hackrf-dev] <DKIM> Re: <DKIM> Re: HackRF with Raspberry Pi 2 Overruns
The main deficiency is the USB core of
the Broadcom SOC.
The external use of the USB of the Rpi, even if not optimal, is
not whose than in any other computer.
Depending of the context, you could not expect mode than 1/10 to
1/3 of the total USB bandwidth.
Emmanuel.
Le 03/03/2015 22:19, Paul Connolly a écrit :
> 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
_______________________________________________
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/20150305/c1e1d2bb/attachment.html>
More information about the HackRF-dev
mailing list