Hi!
I've pushed quite a bit of firmware related work to osmo-sdr.git,
specifically the USB DFU bootloader and an example project that can be
linked to the application partiiton and installed using dfu-util.
There's a README file in osmo-sdr/firmware/usb-dfu-project/ which should
give some basic instructions.
I'm right now again seriously overworked, so no time for more
explanations at this point, sorry.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
FYI, this mail from Frederic just arrived.
I'll make sure to also send it Stefan for further analysis.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi all!
I've just put http://sdr.osmocom.org/ online, the usual trac
installation for the new OsmoSDR project. The wiki mostly contains
information on the Hardware (including a block diagram):
http://sdr.osmocom.org/trac/wiki/Hardware
The git repository can be cloned from git://git.osmocom.org/osmo-sdr
and browsed via http://cgit.osmocom.org/cgit/osmo-sdr/
Hardware verification at 28C3 was making great progress. Basically all
the components / interfaces have been verified. However, there is a bug
in signal level incompatibility between the Si570 output and the FPGA
clock input requiring a hardware re-work of the prototypes as well as a
hardware fix in the next generation of boards.
The firmware and FPGA image are far from begin complete, but the code we
have so far was sufficient in order to validate the design. I don't
have an ETA, but I would guess some point in Februray 2012 might be
realistic.
We'll keep the osmocom-sdr(a)lists.osmocom.org list up-to-date about any
new developments. You can also subscribe to the RSS feed at
http://sdr.osmocom.org/trac/blog?format=rss or follow
http://planet.osmocom.org/ for news from all of the Osmocom
sub-projects.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi all,
after some discussion with Dieter and Christian, the following strategy
has been selected for USB driver/protocol development:
0) Implement a composite USB Audio and CDC-ACM (serial) device to the
OS, where USB audio is used for complex xamples in S16_LE format,
and CDC-ACM is used for control of the device (tuning, etc.)
1) use USB audio with 1Ms/s, maybe even 2Ms/s for Linux.
2) offer the highest possible sample rate that windows supports as
alternative sample rate in the descriptor (96 or 128 kHz)
* implement a factor 10 decimation and low-pass inside the FPGA
to avoid folding of the spectrum, as the E4000 has a minimum filter
width of 1 MHz
3) implement a libusb-win32 (libusb-0.1) driver for windows for the
higher baud rates. To make sure this driver can bind to the device
(and not the standard windows usb audi driver), we can implement a
control command sent over the serial port, which causes the device to
re-enumerate and no longer identify itself as a 'usb audio class'.
The next steps in the direction of the firmware will be:
* creating the dual sample rate USB audio descriptors and verify they
are accepted by Linux and Windows (with dieters help)
* creating the descriptors for the composite device, validating them on
Linux and Windows, as well as operation of the virtual serial port
* experiments with the NuttX port for sam3u (might be nice, but I doubt
we will need it, given the single-purpose nature of the device)
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
