It's already two weeks since my last post mentioning OsmoSDR only very
briefly. By now, OsmoSDR is fully public and you can read all about it
on the http://sdr.osmocom.org/
website.

Specifically, the website includes Schematics, and one of my colorful
block diagrams. I am a text guy and really hate to work with graphics,
but the block diagram of the Calypso has helped a lot in the context of
making people understand OsmocomBB, so I tried again for OsmoSDR:

So as you can see, it is a very simple, straight-forward design with a
chip tuner, direct I/Q down-conversion, ADC for differential I and Q
signals as well as a small FPGA for basic filtering and serial format
conversion, followed by a Atmel SAM3U microcontroller (Cortex-M3, high
speed USB).

And yes, it's receive only. However, it has a stacking connector for
later addition of a transmit daughter-board which may eventually follow
later in 2012.

So what is this OsmoSDR going to be used for? Well, for receiving any
kind of signals between 64 MHz and 1700 MHz (possibly up to 1800 MHz,
untested). We don't build it for a specific application, but we simply
thought that for many applications a member of the USRP family is
expensive overkill, and the FCDP has this arbitrary restriction at 96
kHz sampling frequency.

Please note that while I may be the only OsmoSDR developer that blogs
about this project, it is very much a team effort and I'm only a minor
part of that team. Apart from selecting the SAM3U, writing firmware and
drivers for it as well as some discussions early on in the project, I
didn't have any involvement in the Hardware design. Those credits go to
Christian Daniel and Stefan Reimann.

So where do we stand? There are 5 prototypes of the first generation,
they look like this:

There are some smaller hardware issues that were easy to work around,
but one bigger problem related to the fact that the Si570 programmable
oscillator output levels didn't match quite with what the FPGA clock
input requires.

There will be a second generation board fixing this and other problems,
and hopefully we'll see some progress in the weeks to come.

Firmware-wise, the code is currently scattered over a couple of
different repositories, but I'm going to consolidate that soon. If
you've worked with OpenPCD or SIMtrace, you will find some similarities:
We split the flash of the controller into two partitions: One for the
DFU bootloader, and one for the application code. You can then use the
USB DFU (Device Firmware Upgrade) standard to quickly update the actual
firmware of the device, without having to resort to jumpers or
un-plugging and re-plugging of the hardware.

This also meant that I had to re-implement the old sam7dfu code for the
SAM3U, which has considerable differences in the USB peripheral, cpu
core, board startup code, etc. So it's really a reimplementation than a
port. The good news is that I tried to make it as general as possible
and integrate it with at91lib, Atmels reference code. So it should be
easier to use it with other Atmel SoCs like the sam3s which I want to
use e.g. in SIMtrace v2.