OsmoSDR status update
It has been two months since I first was able to play with the OsmoSDR hardware prototypes. Back at
that time, there was no FPGA code yet, and some hardware bugs still had
to be resolved. Nonetheless, the e4k tuner driver could already be
implemented and tuning was confirmed by looking at the analog i/q
Meanwhile, the hardware has been re-worked by SR-Systems and FPGA VHDL
code written by maintech.de. Ever since that, they dropped the ball
again with me as I had been careless enough to volunteer for writing
And that's what I did or at least tried to do for quite some time during
the last two weeks. The main problem was that I didn't have much time.
The second problem was that I never was able to get the SSC (synchronous
serial controller) receive DMA working.
This was a really odd experience, as I've worked a lot with that very
same SSC peripheral before, while writing firmware for the OpenPICC
some 6 years ago. However, this was in an at91sam7s, where the SSC is
interfaced with the PDC (Peripheral DMA Controller). In the at91sam3u
of OsmoSDR, it interfaces with a more modern DMAC/HDMA controller,
capable of scatter-gather DMA and other fancy stuff.
Atmel has provided reference code that uses the SSC DMA in transmit mode
(for a USB audio device playing back music via the Wolfson codec on the
SAM3U-EK board). After thoroughly studying the DMAC/HDMA documentation I
set out to write code for DMA-based SSC receiver. And it never worked.
I actually wrote two independent implementations, one from scratch and
the other based on Atmel reference code. Neither of them worked. It
seemed to be a problem with the hardware hand-shaking between SSC and
DMAC. The SSC was successfully receiving data, and that data could be
read out from the CPU using a polling or IRQ based driver. But if
you're running at something like 32 Mbps and don't have a FIFO, you
desperately want to use DMA. When the DMA handshaking was turned off,
the DMA code worked, but of course it read the same received word
several thousand times before the next data arrived on the SSC.
In the end, I was actually convinced it must be a silicon bug. Until I
thought well, maybe they just connected the flow controller to a
different ID in Rx and Tx direction. Since there are only 16 such
identifiers, it was relatively easy to brute-force all of them and see
if it worked. And voila - using the identifier 4, it worked!
So what had happened? The Atmel-provided reference code contained a
and that was wrong. 3 is valid for SSC TX but not for SSC RX.
Unfortunately I never found any of those magic numbers in the SAM3U
manual either. They are not documented in the chapter of the SSC, and
they are not documented in the chapter about HDMA/DMAC either. And they
are not identical with the Peripheral Identifiers that are used all over
the chip for the built-in peripherals.
In case anyone else is interested, a patch can be found at my
at91lib git repository.
I filed a ticket with Atmel support, and they pointed out in fact there
was a table with those identifiers somewhere in the early introductory
chapters where you can see a brief summary of the features of each
integrated peripheral. Unfortunately they use slightly different naming
in that chapter and in the DMAC, so a full-text search also didn't find
them. Neither is that table visible in the PDF index.
So about four man-days later it was finally working. Another day was
spent on integrating it with the USB DMA for sending high-speed
isochronous transfers over the bus into the PC. And ever since I'm
happily receiving something like 500,000 or 1,000,000 samples / second
from an alsa device, using snd-usb-audio. Luckily, unlike MacOS or
Windows, the Linux audio drivers don't make arbitrary restrictions in
the sample rate. According to the USB Audio spec, the sample rate can
be any 24bit number. So audio devices with 16.7 Ms/s are very much
within the spec. I hope some of the other OS driver writers would take
that to their heart.
One of the first captures can be found at this
link, containing a bzip2ed wave file in S16LE format Stereo (I/Q).
It contains a FM audio signal transmitted using a small pocket-sized FM
There is no I/Q DC offset calibration yet, but once that is done we're
probably able to finally put the design into production.
Syndicated 2012-03-02 01:00:00 from Harald Welte's blog