> One example is for an AIS transceiver on a boat. By putting the > radio and decoder at the top of the mast, the backhaul can be a > cat-3 twisted pair cable, rather than a much heavier coax run from > the antenna at the top of the mast to the receiver below decks.
Yeah, I've been sending 3Mbit I/Q samples over ethernet to a more beefy computer. For non-technical crowds I described the rpi as a passable USB->ethernet gateway for SDR tasks in that bandwidth. But given the alternatives available back then, even the armv5 in the kirkwood, which was cheaper even before the rpi became popular, did the same job more stably, which is why i would never actually recommend the pi. And there are even more alternatives now. Even the rpi itself is proof that better alternatives exist (as they did even back then when the first one out), because the newer rpi revision (i think) has finally gained neon cpu extensions, which surprisingly have been supported by gnuradio long before this, and a reason why my bachelor thesis back then was an easy success :) In general all limits that occured to me on the rpi were due to stability (usb power and compatibility issues), but more concretely for our discussion: lack of cpu power, mainly for the FFT. There were no throughput, delay or memory copy bottlenecks for me. This was using linux, because my mouse didn't work on the old rpi plan9 image and sadly there was a time-limit... Are you doing the AIS demodulation on plan9 on rpi? It would be a great showcase. Wish I had been given the opportunity to find an excuse to build something like that on plan9 instead :)
