-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello everybody,
following up on Harald's great progress I wrote some tool to verify the
RF purity of our design. This is the last step before we can order the
final PCBs and start production.
Sadly from my current results we have some room for improvements. Right
now I'm reviewing the E4000 driver as I suspect the visible steps in the
attached spectrum to be switching points in the E4000. Perhaps something
can be improved here...
Stefan told me that without any antenna the output levels of the E4000
should be below the LSB limit of the ADC - clearly we have a lot of
noise on the signal. But we also don't have any I/Q calibration and I
can see significant offsets on these lines...
I'll keep you posted!
Cheerio,
Christian
- --
- ---------------------------------------------------
| maintech # Dipl. Inf (FH) Christian Daniel |
| GmbH ### Otto-Hahn-Str. 15 · D-97204 Höchberg |
- ---------------------------------------------------
| AG Würzburg, HRB 8790 Tax-ID DE242279645 |
- ---------------------------------------------------
| http://www.maintech.de cd(a)maintech.de |
- ---------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJPTzeFAAoJEHkgzUIsAWrilLMH/1s45+iDzv0+YqNpql5sZSs0
88uWFZbbpd22HVY4tifMpe5n4E1bJJBK2Sfuq9t4HDIV/Tka9KijCDT7a3BVbzzQ
TqQ3iimSdS7/+UYiNI9OPhdpFaBE1tuCcvWg4lBXct125mynOM/VajLMsXDd/4E6
UVtwUqFxWFXhWXi7/jT/P8+2dhUHZ0sLTsWNp7FS8+SCn7/Uu9QvEc0ZIr8ufaiK
NwWTM8O16mUEn0iFMme8WdBhTsi7TTiK23Wd7RZGkZfZeMEr93jPtpvlvkDRlwiF
RJC158eAZASsXfyRAw1wr59GVsJF4S7HV88LkKVFS4FOU2t09b/DKZplWnfp0IQ=
=5KOA
-----END PGP SIGNATURE-----
Hi all,
after long struggles with a wrong #define in the atmel provided header
file, I've finally made the SSC DMA handshaking working. After some
more struggles, the samples are now arriving on the host PC and I can
record data with arecord.
I will be claning up things later today/tonight and should be able to
publish some sample capture files as well as some documentation on the
current state of the firwmare.
Maintech/SR-Systems will then be doing some measurements on the captured
spectrum, after which we hopefully can go into production. I would love
to get the first production batch in time for OsmoDevCon2012.
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!
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)