- osmocom-sdr - lists.osmocom.org

PATCH: Silence warning about int/socklen_t signedness

by Christian Vogel

There's only one warning for me when compiling rtl-sdr, which is about the signedness of the third (size) argument in accept(). On linux it's socklen_t* and I *think* (google...) that windows does not have socklen_t at all. In accept it uses int. ftp://ftp.microsoft.com/bussys/winsock/winsock2/winsock2.h WINSOCK_API_LINKAGE SOCKET WSAAPI accept( IN SOCKET s, OUT struct sockaddr FAR * addr, IN OUT int FAR * addrlen ); Can someone please check if it compiles on windows with the attached patch?

11 years, 11 months

1
0
0 0

[PATCH] Silence warning about socklen_t/int sign.

by Christian Vogel

rtl_tcp.c:457:57: warning: pointer types point to integer types with different sign passing 'int *', expected 'socklen_t *' [-Wpointer-sign] --- src/rtl_tcp.c | 9 +++++++-- 1 files changed, 7 insertions(+), 2 deletions(-) diff --git a/src/rtl_tcp.c b/src/rtl_tcp.c index 8b2cf44..849192b 100644 --- a/src/rtl_tcp.c +++ b/src/rtl_tcp.c @@ -42,6 +42,9 @@ #ifdef _WIN32 #pragma comment(lib, "ws2_32.lib") + +typedef int socklen_t; + #else #define closesocket close #define SOCKADDR struct sockaddr @@ -453,8 +456,10 @@ int main(int argc, char **argv) if(do_exit) { goto out; } else if(r) { - r=sizeof(remote); - s = accept(listensocket,(struct sockaddr *)&remote, &r); + socklen_t rlen; + + rlen=sizeof(remote); + s = accept(listensocket,(struct sockaddr *)&remote, &rlen); break; } } -- 1.7.0.4 --Nq2Wo0NMKNjxTN9z--

11 years, 11 months

1
0
0 0

[PATCH] FC0012 doc and fixes

by Michael Karcher

Fix selection of VCO band (needed for example to get to 166 MHz) for the FC0012 tuner, and add a lot of register descriptions. Signed-Off-by: Michael Karcher <osmosdr(a)mkarcher.dialup.fu-berlin.de> --- src/tuner_fc0012.c | 49 +++++++++++++++++++++++++++++++++---------------- 1 file changed, 33 insertions(+), 16 deletions(-) diff --git a/src/tuner_fc0012.c b/src/tuner_fc0012.c index 104a4f7..2d66f3c 100644 --- a/src/tuner_fc0012.c +++ b/src/tuner_fc0012.c @@ -20,21 +20,35 @@ /* Incomplete list of register settings: * * Name Reg Bits Desc + * CHIP_ID 0x00 0-7 Chip ID (constant 0xA1) + * RF_A 0x01 0-3 Number of count-to-9 cycles in RF + * divider (suggested: 2..9) + * RF_M 0x02 0-7 Total number of cycles (to-8 and to-9) + * in RF divider + * RF_K_HIGH 0x03 0-6 Bits 8..14 of fractional divider + * RF_K_LOW 0x04 0-7 Bits 0..7 of fractional RF divider + * RF_OUTDIV_A 0x05 3-7 Power of two required? * LNA_POWER_DOWN 0x06 0 Set to 1 to switch off low noise amp - * VCO_SPEED 0x06 3 Set the speed of the VCO. example - * driver hardcodes to 1 for some reason + * RF_OUTDIV_B 0x06 1 Set to select 3 instead of 2 for the + * RF output divider + * VCO_SPEED 0x06 3 Select tuning range of VCO: + * 0 = Low range, (ca. 1.1 - 1.5GHz) + * 1 = High range (ca. 1.4 - 1.8GHz) * BANDWIDTH 0x06 6-7 Set bandwidth. 6MHz = 0x80, 7MHz=0x40 * 8MHz=0x00 * XTAL_SPEED 0x07 5 Set to 1 for 28.8MHz Crystal input * or 0 for 36MHz + * <agc params> 0x08 0-7 * EN_CAL_RSSI 0x09 4 Enable calibrate RSSI * (Receive Signal Strength Indicator) * LNA_FORCE 0x0d 0 * AGC_FORCE 0x0d ? - * LNA_GAIN 0x13 0-4 Low noise amp gain + * LNA_GAIN 0x13 3-4 Low noise amp gain * LNA_COMPS 0x15 3 ? * VCO_CALIB 0x0e 7 Set high then low to calibrate VCO - * + * (fast lock?) + * VCO_VOLTAGE 0x0e 0-6 Read Control voltage of VCO + * (big value -> low freq) */ /* glue functions to rtl-sdr code */ @@ -99,12 +113,11 @@ void FC0012_Dump_Registers() DEBUGF("LNA Force:\t%s\n", (regBuf & 0x1) ? "Forced" : "Not Forced"); FC0012_Read(pTuner, 0x13, &regBuf); DEBUGF("LNA Gain:\t"); - switch (regBuf) { - case (0x10): DEBUGF("19.7dB\n"); break; - case (0x17): DEBUGF("17.9dB\n"); break; - case (0x08): DEBUGF("7.1dB\n"); break; - case (0x02): DEBUGF("-9.9dB\n"); break; - default: DEBUGF("unknown gain value 0x02x\n"); + switch (regBuf & 0x18) { + case (0x00): DEBUGF("Low\n"); break; + case (0x08): DEBUGF("Middle\n"); break; + case (0x10): DEBUGF("High\n"); break; + default: DEBUGF("unknown gain value 0x18\n"); } #endif } @@ -173,7 +186,7 @@ void FC0012_Frequency_Control(unsigned int Frequency, unsigned short Bandwidth) int FC0012_SetFrequency(void *pTuner, unsigned long Frequency, unsigned short Bandwidth) { - int VCO1 = 0; + int VCO_band = 0; unsigned long doubleVCO; unsigned short xin, xdiv; unsigned char reg[21], am, pm, multi; @@ -230,7 +243,7 @@ int FC0012_SetFrequency(void *pTuner, unsigned long Frequency, unsigned short Ba doubleVCO = Frequency * multi; reg[6] = reg[6] | 0x08; - VCO1 = 1; + VCO_band = 1; xdiv = (unsigned short)(doubleVCO / (CrystalFreqKhz / 2)); if( (doubleVCO - xdiv * (CrystalFreqKhz / 2)) >= (CrystalFreqKhz / 4) ) xdiv = xdiv + 1; @@ -269,7 +282,6 @@ int FC0012_SetFrequency(void *pTuner, unsigned long Frequency, unsigned short Ba if (FC0012_Write(pTuner, 0x03, reg[3])) return -1; if (FC0012_Write(pTuner, 0x04, reg[4])) return -1; //reg[5] = reg[5] | 0x07; // This is really not cool. Why is it there? - // Same with hardcoding VCO=1 if (FC0012_Write(pTuner, 0x05, reg[5])) return -1; if (FC0012_Write(pTuner, 0x06, reg[6])) return -1; @@ -277,16 +289,19 @@ int FC0012_SetFrequency(void *pTuner, unsigned long Frequency, unsigned short Ba if (FC0012_Write(pTuner, 0x0E, 0x80)) return -1; if (FC0012_Write(pTuner, 0x0E, 0x00)) return -1; - // VCO Re-Calibration if needed + // Read resulting VCO control voltage if (FC0012_Write(pTuner, 0x0E, 0x00)) return -1; if (FC0012_Read(pTuner, 0x0E, &read_byte)) return -1; reg[14] = 0x3F & read_byte; - if (VCO1) + // Adjust VCO range if control voltage is at the limit + if (VCO_band) { + // high-band VCO hitting low frequency bound if (reg[14] > 0x3C) { - reg[6] = 0x08 | reg[6]; + // select low-band VCO + reg[6] = ~0x08 & reg[6]; if (FC0012_Write(pTuner, 0x06, reg[6])) return -1; if (FC0012_Write(pTuner, 0x0E, 0x80)) return -1; @@ -295,7 +310,9 @@ int FC0012_SetFrequency(void *pTuner, unsigned long Frequency, unsigned short Ba } else { + // low-band VCO hitting high frequency bound if (reg[14] < 0x02) { + // select high-band VCO reg[6] = 0x08 | reg[6]; if (FC0012_Write(pTuner, 0x06, reg[6])) return -1; -- 1.7.10

11 years, 11 months

2
1
0 0

RTL-SDR Help

by Erick Schumacher

Hello group I need help getting an EZCAP USB deviceusing rtl_sdr running under Windoz7. This is probably the same bug reported on ticket 9 at http://sdr.osmocom.org/trac/query My EZCAP USB device self installs the drivers in Win7 and is recognized by the DVBDream program. Leads me to believe my system and hardware is OK. Below is a screen shot of what happens I try to load RTL-SDR.. I am an RF guy and a serious newby to software so can't contribute much. Help! Eric

11 years, 11 months

2
1
0 0

[PATCH] Add support for PROlectrix dongle

by David J. Fiddes

Hi, This adds support for another RTL2832U based device. I've been able to receive FM broadcasts using GNU Radio and rtl-sdr with this device. Dave Subject: [PATCH] Add support for PROlectrix dongle Incorporate support for the PROlectrix DV107669 which appears to be another variant of G-Tek RTL2832U device. This has a FC0012 tuner. Signed-off-by: David J. Fiddes <D.J(a)fiddes.net> --- rtl-sdr.rules | 3 +++ src/librtlsdr.c | 1 + 2 files changed, 4 insertions(+) diff --git a/rtl-sdr.rules b/rtl-sdr.rules index d5e812f..b775916 100644 --- a/rtl-sdr.rules +++ b/rtl-sdr.rules @@ -51,6 +51,9 @@ SUBSYSTEMS=="usb", ATTRS{idVendor}=="1f4d", ATTRS{idProduct}=="b803", MODE:="066 # Lifeview LV5TDeluxe (FC0012) SUBSYSTEMS=="usb", ATTRS{idVendor}=="1f4d", ATTRS{idProduct}=="c803", MODE:="0666" +# PROlectrix DV107669 (FC0012) +SUBSYSTEMS=="usb", ATTRS{idVendor}=="1f4d", ATTRS{idProduct}=="d803", MODE:="0666" + # Twintech UT-40 (FC0013) SUBSYSTEMS=="usb", ATTRS{idVendor}=="1b80", ATTRS{idProduct}=="d3a4", MODE:="0666" diff --git a/src/librtlsdr.c b/src/librtlsdr.c index d961985..ba14942 100644 --- a/src/librtlsdr.c +++ b/src/librtlsdr.c @@ -210,6 +210,7 @@ static rtlsdr_dongle_t known_devices[] = { { 0x185b, 0x0680, "Compro Videomate U680F"}, { 0x1f4d, 0xb803, "GTek T803" }, { 0x1f4d, 0xc803, "Lifeview LV5TDeluxe" }, + { 0x1f4d, 0xd803, "PROlectrix DV107669" }, { 0x1b80, 0xd3a4, "Twintech UT-40" }, { 0x1d19, 0x1101, "Dexatek DK DVB-T Dongle (Logilink VG0002A)" }, { 0x1d19, 0x1102, "Dexatek DK DVB-T Dongle (MSI DigiVox mini II V3.0)" },

11 years, 11 months

1
0
0 0

[PATCH] librtlsdr: libusb detach kernel driver before claiming interface

by p.munoz＠alumnos.upm.es

From: Pablo Muñoz <p.munoz(a)alumnos.upm.es> rtl_sdr founds ezcap USB dongle but exits with usb_claim_interface error -6 Signed-off-by: Pablo Muñoz <p.munoz(a)alumnos.upm.es> --- src/librtlsdr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/librtlsdr.c b/src/librtlsdr.c index 7721c4a..0599722 100644 --- a/src/librtlsdr.c +++ b/src/librtlsdr.c @@ -865,7 +865,7 @@ int rtlsdr_open(rtlsdr_dev_t **out_dev, uint32_t index) } libusb_free_device_list(list, 1); - + libusb_detach_kernel_driver(dev->devh,0); r = libusb_claim_interface(dev->devh, 0); if (r < 0) { fprintf(stderr, "usb_claim_interface error %d\n", r); -- 1.7.10

11 years, 11 months

1
0
0 0

Fwd: Calculation of allowed vco frequency in osmocom sources

by Harald Welte

Hi all, with permission of its author, I'm forwarding this message to the list. 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)

11 years, 11 months

1
0
0 0

Sources for VHDL and FPGA flashing committed

by Christian Daniel -- maintech GmbH

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello everybody, I've committed the VHDL source code and the needed projects files for Lattice Diamond into the repository. With this everybody can build a FPGA image for the OsmoSDR. The most important feature in this new FPGA firmware version is, that we now have an integrated decimation filter, which can be configured in from 1:2 to 1:64. I have added a tool to convert the files, that Lattice Diamond produces to something we can upload via USB DFU and I also modified the DFU loader to include FPGA flashing support. Since the post office was already closed yesterday and today we had a holiday in Germany, the boards will find their way to the mail tomorrow. Best regards, 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/ iQEcBAEBAgAGBQJPtWY8AAoJEHkgzUIsAWrig/oH/2b9oummF4S/gDN/A6SlIIf4 ppmcg+j+gLCJ7n2Otpb/eq+Uk8BK8NgFu0qlaWVSJ9q2HtHXGsxzUFnkRGRNIjjv I8DIImuUiDpUXfiX/mQEe9kGNJwJIcCB4ulFHeU8EDo7NcbI/O8nHQQOtX46Uegl yzdkqw9KaPJxeABdsa9PzTKOvWDigMrWw6IEibJRqrMVkAOxHby2084NqFQPNLze +f/uSQ4FW64hlc0Gli5nyXGR10CaY8/SXTP7VTNtI3Gnjwvf4VcKkCFrFLR9/UZE +4HuIXu0JMX3jFTF72ttwKG+oGxk9G+IorTgW+VUzKJ2ni+D0Zy8zaCAjnNBYOg= =ykxM -----END PGP SIGNATURE-----

11 years, 11 months

1
0
0 0

PATCH: Remove pow() and math.h from rtl-sdr.

by Christian Vogel

Hi, apparently #include <math.h> is only needed for the declaration of pow(2,22) used in rtlsdr_set_sample_rate(). Now gcc is smart enough to convert pow(2,22) to a constant, but for example clang isn't, and it complains about the missing math library. Attached patches replace pow(2,22) by (float)1<<22 and remove the math headers. Chris [tort /home/chris/rtl-sdr (b345963947b451f6…)] $ make (...) ./.libs/librtlsdr.so: undefined reference to `exp2' collect2: ld returned 1 exit status clang: error: linker command failed with exit code 1 (use -v to see invocation) make[2]: *** [rtl_sdr] Error 1 make[2]: Leaving directory `/home/chris/rtl-sdr/src'

11 years, 11 months

2
1
0 0

OsmoSDR developer beta

by Harald Welte

Hi all! There are something like 16 units of OsmoSDR that we are able to sell in something like one week. Sale will happen via the https://shop.sysmocom.de/ webshop. However, as there are only 16 units right now, and as the firmware and host software is in an incomplete state, we would like to make sure that those 16 units get sold to people who actually have an interest (and time!) to fix and improve the current shortcomings. So if you want to be among the first 16, I suggest you reply to this message and give us a short description of who you are (if you are not a Osmocom regular) as well as some committment that you are actually going to work on improving the code. If you already know an area that you'd like to work on, please state that, too. The price will be 180 EUR incl. VAT (that's 151.26 EUR without), i.e. the same price as for the units that will later be sold openly. I have put together a wiki page with the current status at http://sdr.osmocom.org/trac/wiki/OsmoSDR/Status to make you aware where we are and what is missing. Thanks in advance for your willingness to be early users and help us to improve the codebase. 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)

11 years, 11 months

3
5
0 0

[PATCH 2/2] #include <math.h> was not needed.

by Christian Vogel

--- src/rtl-sdr.c | 1 - src/rtl_sdr.c | 1 - src/rtl_tcp.c | 1 - 3 files changed, 0 insertions(+), 3 deletions(-) diff --git a/src/rtl-sdr.c b/src/rtl-sdr.c index da79acb..b6f9163 100644 --- a/src/rtl-sdr.c +++ b/src/rtl-sdr.c @@ -22,7 +22,6 @@ #include <string.h> #include <stdio.h> #include <stdlib.h> -#include <math.h> #ifndef _WIN32 #include <unistd.h> #define min(a, b) (((a) < (b)) ? (a) : (b)) diff --git a/src/rtl_sdr.c b/src/rtl_sdr.c index fed0d30..98d5fc5 100644 --- a/src/rtl_sdr.c +++ b/src/rtl_sdr.c @@ -21,7 +21,6 @@ #include <string.h> #include <stdio.h> #include <stdlib.h> -#include <math.h> #ifndef _WIN32 #include <unistd.h> diff --git a/src/rtl_tcp.c b/src/rtl_tcp.c index 3cea790..7cfd524 100644 --- a/src/rtl_tcp.c +++ b/src/rtl_tcp.c @@ -22,7 +22,6 @@ #include <string.h> #include <stdio.h> #include <stdlib.h> -#include <math.h> #ifndef _WIN32 #include <unistd.h> -- 1.7.0.4 --dDRMvlgZJXvWKvBx--

11 years, 11 months

1
0
0 0

[PATCH] Using a #define for constant 2^22 (not pow())

by Christian Vogel

pow() might require the math library to be linked with rtl-sdl (e.g. when compiling with clang), even though it's actually constant. --- src/rtl-sdr.c | 7 +++++-- 1 files changed, 5 insertions(+), 2 deletions(-) diff --git a/src/rtl-sdr.c b/src/rtl-sdr.c index 6a9539b..da79acb 100644 --- a/src/rtl-sdr.c +++ b/src/rtl-sdr.c @@ -675,6 +675,9 @@ int rtlsdr_set_tuner_gain_mode(rtlsdr_dev_t *dev, int mode) return r; } +/* two raised to the power of n */ +#define TWO_POW(n) ((double)(1ULL<<(n))) + int rtlsdr_set_sample_rate(rtlsdr_dev_t *dev, uint32_t samp_rate) { uint16_t tmp; @@ -688,10 +691,10 @@ int rtlsdr_set_sample_rate(rtlsdr_dev_t *dev, uint32_t samp_rate) if (samp_rate > MAX_SAMP_RATE) samp_rate = MAX_SAMP_RATE; - rsamp_ratio = (dev->rtl_xtal * pow(2, 22)) / samp_rate; + rsamp_ratio = (dev->rtl_xtal * TWO_POW(22)) / samp_rate; rsamp_ratio &= ~3; - real_rate = (dev->rtl_xtal * pow(2, 22)) / rsamp_ratio; + real_rate = (dev->rtl_xtal * TWO_POW(22)) / rsamp_ratio; if ( ((double)samp_rate) != real_rate ) fprintf(stderr, "Exact sample rate is: %f Hz\n", real_rate); -- 1.7.0.4 --dDRMvlgZJXvWKvBx Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="0002-include-math.h-was-not-needed.patch"

11 years, 11 months

1
0
0 0

why Docs for the ELONICS E4000 are not published

by Jay Salsburg

Is the reason why Docs for the ELONICS E4000 are not published because it is Chinese? If anyone has the Datasheets for the ELONICS E4000 and REALTECH RTL2832, please share them to osmocom-sdr(a)lists.osmocom.org or post them to http://sdr.osmocom.org/trac/wiki/Hardware Thanks

11 years, 11 months

3
4
0 0

Recent librtlsdr and example program don't work

by Andrea Montefusco

After about a month, I refreshed the local git sandbox but I was not anymore able to receive any sample, even with the test program. I am using a Terratec NOXON DAB/DAB+ USB dongle (rev 1) on Ubuntu 11.10 x86_64 . ./rtl_sdr - Found 1 device(s): 0: Terratec NOXON DAB/DAB+ USB dongle (rev 1) Using device 0: Terratec NOXON DAB/DAB+ USB dongle (rev 1) Found Fitipower FC0013 tuner Tuned to 100000000 Hz. Tuner gain set to -1.000000 dB. Reading samples in async mode... but I can get no output. *am* --------------------------------------------------------- Andrea Montefusco iw0hdv http://www.montefusco.com tel: +393356992791 fax: +390623318709 ---------------------------------------------------------

11 years, 12 months

3
7
0 0

Re: OT: usb hub power switching (Re: Recent librtlsdr and example program don't work)

by Dieter Spaar

Hello Peter, On Tue, 8 May 2012 23:47:33 +0200, "Peter Stuge" <peter(a)stuge.se> wrote: > > Yes, I haven't seen it available in any userspace API on any system. :\ > > It may be possible to send the request to the hub from userspace, but > I haven't tried it. Older Windows Version (before Vista) had IOCTL_USB_HUB_CYCLE_PORT to perform a power cycle. I think there is still a way in newer version too, If I am not wrong the WHQL driver testings tools do perform USB power cycles frequently when testing USB devices. Of course the above is only relevant if you care about Windows ;-) Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

11 years, 12 months

1
0
0 0

RTL2832 questions

by Jeff Gustafson

Hi all, First of all, props to the person that found out how to put the RTL chip into a SDR compatible mode! I've been wanting to play around with SDR and, specifically, P25 for a while now. Finally an inexpensive way to get my feet wet. My question is probably a bit of a noob question. I have successfully received a broadcast FM radio station with the RTL dongle. The problem is that I can't seem to decode anything else. I tried to receive some ham radio (NFM) transmissions from my radio and I didn't get any sound. The white noise blanked out, the scope in gnuradio spiked up, but no real demodulation. Would someone be willing to share a .grc file they know will decode NFM with the gr-osmosdr/rtl-sdr driver? I tried taking some files that used the USRP driver and swapping out the USRP driver with the osmosdr/rtl driver, but no go. Could it be that I don't have all the sampling rates and decimation rates set correctly? ...Jeff

11 years, 12 months

1
1
0 0

Patch for Compro U680F support.

by Marek Kroemeke

Hi guys, Unclear in what format you require patches - but I bought Compro U680F 2 days ago, it has the E4000 chipset and it only required adding usb id in, so as requested in docs - sending a small "patch" that makes it work :-) regards, Marek Kroemeke

12 years

2
1
0 0

Detach kernel driver

by Michal Demin

Hello, Attached are 2 patches: 1 - Try to detach kernel driver from device, when kernel driver present. 2 - add rtl_tcp binary to gitignore. Michal Demin

12 years

2
5
0 0

RTL-SDR ghost signal at center frequency & hangs in GR spectrum view

by Benedikt Heinz

Hi everyone, can someone explain to me, what the origin of the ghost signal close to center frequency is? It can be seen at [1] and [2] - both are EzTV668 with no antenna connected. It seems to me, that the higher the frequency, the more one can see the "burst-like" nature of this signal. Is this some mixer artefact from the E4k tuner? The best workaround is probably tuning a bit off the actual target frequency and using frequency xlate? Also, in [3] (german) the blind spot at 0Hz due to the coupling capacitors between E4k & RTL is mentioned. Is it possible to replace the capacitors with 0-Ohm resistors to work around this issue, or will this cause other unwanted side-effects? Or does this make no sense at all since one should always tune a bit off and use xlate due to the ghost signal? I guess it should also be possible (w/ some hot glue & wires) to insert some jumpers (like OsmoSDR) instead, so one can use the ADCs directly for LF/MF with some extra analog stuff? Regarding the OsmoSDR source - I also gave the RTL-source from gr-baz a try and noticed, that with averaging enabled in the spectrum view in GR, the top-block GUI usually won't react to user input any longer when using OsmoSDR, but this doesn't happen with the gr-baz RTL source, although I used the same sample rate in both cases. Does anyone understand why it doesn't hang with the gr-baz source? Thanks for your answers! Regards, hunz [1] http://hackdaworld.org/~hunz/rtl-sdr/wo_ant_2m_osmo.png [2] http://hackdaworld.org/~hunz/rtl-sdr/wo_ant_70cm_osmo.png [3] http://www.mikrocontroller.net/topic/253371#2610540 -- Benedikt Heinz hunz(a)jabber.berlin.ccc.de

12 years

3
2
0 0

OsmoSDR - they're on final approach

by Christian Daniel -- maintech GmbH

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi everybody, just as a short heads up: The new boards have arrived and the first batch of 20 is assembled. Since we did changes to the layout we will verify them before we do the other 80. This should take no more than a few days. Stay tuned! BTW: The new pre-amp/lnb really does add 18dB :) Best regards, 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/ iQEcBAEBAgAGBQJPkBrEAAoJEHkgzUIsAWritBgH/RqDZuLRLQ/22msTdvZ+EIqk 6Y98xDBrDcXSkTSsFBQvLwdKANUxxi3dVvTjknBw3lnrWzT8fo2uVMg97c/R6Eov fGOvALbXckgrmvz0n/IZdROu8x38zs/ro0uweN0oxb14+U/2CW5VVeJusqcQoBL6 Ug4XAtzXpyR04pmjjq6jzxtsmsXuv42KToG7R9UvkiNz8WXhxlaaUmA+ccJGM+8+ FCITzYY9ZMfFo2IekXDGkZNsKwux37B8cQxYIlcSlPxlSrPzusFyyqEq2AmM1iIn SbuRnmjzeUQbsgGVINmVP1B3EDOczeYWyeKC/5myXbr+Ogpp9/PD9K9aJG/sKYM= =KY1W -----END PGP SIGNATURE-----

12 years

1
0
0 0

Real-time DRM+ receiver chain using the NOXON stick

by Feilen, Michael

Dear Osmocon-SDR People, Thank you so much for providing the information on the RTL-SDR USB sticks on your webpage! I've used the stick to get a DRM+ receiver implementation running and the stick seems to work quite well: http://www.youtube.com/watch?v=zeGs7CQlvRg I've had to twiddle around with the tuner parameters of the FC0013 to get it running stable. However, I've never reached more than 25 dB SNR for the in-band OFDM signal (which has a bw of 100 kHz and I'm resampling from 1 MS/s to 120 kS/s). I wonder if the tuner is the limiting factor or the RTL chip. With a resolution of 8 bit, I would have expected more. Hmm, maybe it's the phase noise of the tuner or the IQ correction routines of the RTL chip? Has anybody of you guys a meaningful measure for the quality of the different tuners for the RTL stick? I know that the E4000 supports a higher bandwidth but does it provide a better IQ signal with less distortion? Cheers, Michael

12 years

1
0
0 0

rtl-sdr with Compro Videomate U620F

by Simeon Miteff

Hi All The Compro Videomate U620F has the magic RTL2832+E4000 combination. rtl-sdr recognises it with the patch: https://gist.github.com/2362895 Regards, Simeon.

12 years

2
1
0 0

Buffer length in rtlsdr_wait_async

by Andrea Montefusco

Hi all, together with Oliver DL6KBG (that really provides me with all the hardware needed, thanks !), we are attempting to write a server suitable for use with ghpsdr3-alex SDR software. A first attempt using the a home built code was quite successfully, albeit some defect is yet there. Now we are trying to use the librtlsdr: first off, many thanks to developers. We are stucked into rtlsdr_wait_async that is using a fixed quite large buffer, as per #define BUF_LENGTH (16 * 16384) now that is quite inconvenient in ghpsdr3-alex, because, at low sample rate (250000) we use, we are unable to cope with the large delay that this large buffer introduces. So, just as crude workaround, we simply patched the value into the lib. What would be ideal is an additional parameter in rtlsdr_wait_async that allow us to reduce the buffer to a more suitable size for our needs. Thanks in advance *am* --------------------------------------------------------- Andrea Montefusco iw0hdv http://www.montefusco.com tel: +393356992791 fax: +390623318709 ---------------------------------------------------------

12 years

2
1
0 0

Tuner performance for rtl-sdr

by Mathias Coinchon

Hi, Does anybody have some hints, experiences on the performance difference (filtering, sensitivity, IQ imbalance, DC offset,..) between fc0012, fc0013 and e4000 tuners ? I could not get my hands on an e4000 yet but just fc0012 and fc0013. On FM band I see quite a number of mirror images from strong signals. Mathias

12 years

1
0
0 0

Re: rtl-sdr with airprobe

by schwandre＠gmx.net

> I'd like to know what was the reasoning behind that statement ? > To me it shows a deep lack of understanding on how that script works ... the reason for this statement was, that i read somewhere, that the example-file was recorded with 1,8 MS/s and decimation of 174. yes, you are right, i don't know how that script works, i read the sources and understood maybe 5% of it, because this is all really new for me, as i am not a professional and my last programm i wrote, was for the 6510 about 20 years ago.... now i did some more readings and found, that to have needed bandwith of 200 khz with 1,8 MS/s is a decimation rate of 9 ? decimation=MS/bw ? guess i have to read a lot more, thanks for your info! -- NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone! Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a

12 years, 1 month

1
0
0 0

[PATCH] Fix FC0012 tuner filters for librtlsdr

by David Basden

Thanks to Steve for finding the bug in my GPIO code. This patch should have the FC0012 using it's VHF/UHF filters correctly. The difference in the UHF band is pretty stunning: http://imgur.com/a/gEutK Cheers, David David Basden (1): Correctly switch UHF and VHF filters for FC0012 include/tuner_fc0012.h | 3 +++ src/rtl-sdr.c | 8 +++++++- 2 files changed, 10 insertions(+), 1 deletion(-) -- 1.7.9.5

12 years, 1 month

2
2
0 0

librtlsdr - Terratec Cinergy T Stick Black (rev 1) works

by Oliver Goldenstein

Please add: { 0x0ccd, 0x00a9, "Terratec Cinergy T Stick Black (rev 1)" }, just tested with gnuradio. lsusb shows this: Bus 002 Device 005: ID 0ccd:00a9 TerraTec Electronic GmbH RTL2838 DVB-T COFDM Demodulator [TerraTec Cinergy T Stick Black] Works good. Stick uses rtl2832u/fc0012 -- Oliver, DL6KBG, JO61UB Blog: http://dl6kbg.blogspot.com

12 years, 1 month

2
1
0 0

rtl-sdr with airprobe

by schwandre＠gmx.net

Hi! I tried to use the recorded capture.bin of several arfcn with aiprobe. Checked the arfcn before with cell-log of osmocom. I converted the capture.bin to the cfile format with the rtl2832-cfile gnuradio block. checked the converted recordings with fft-gui of gnuradio. Seems to be fine. Now i used gsm-receiver with the follwing option to decode the broadcast traffic that is in ts0: GSM/airprobe/gsm-receiver/src/python$ ./go_usrp2.sh capture.cfile 174 0b with the downloaded samplefile of srlabs it works fine, but with mine not. i also tried to change the dezimation rate, did not help. i recorded the bin file with 1.8MS/s also did some tests with 200kS/s. How do i calculate the dezimation rate for the different MS/s ? I think it should work when i use 1.8MS/s and decimation rate of 174. What i am doing wrong? I am using the Hama Nano and the terratec noxon, both are working fine, tested it on radio-broadcast 88-108 MHz and 433 MHz ISM-Band. Will be thankful for any hint. Bye! -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

12 years, 1 month

2
1
0 0

Si5170 replaceable with SI514 ????

by Heikki Ylipiessa

Hi. I know that the Si570 is high precision oscilator ... And it mainly covers the frequencies quite well . But .. the 10MHz lower limit cuts the possibility of using it for 1.8MHz and 3.6Mhz and 7.0 MHz HAM radio bands ... The SI514 would possibly cover the need .. As I don't know how solidly the design has been made ... I'm asking if the Si570 can be replaced with SI514 and if so does the device firmware also need adjusting ??? -- Regards , Heikki Ylipiessa Home: heikki(a)ylipiessa.fi Work: heikki.ylipiessa(a)fi.ibm.com

12 years, 1 month

3
2
0 0

RTL-SDR: E4000 IF bandwidth

by Michał Rogala

Hi! I've just noticed one issue about E4000 driver that bothers me - IF bandwidth at the chip is set to 8 MHz, where maximum bandwidth of RTL2832U sampling is 3.2 MHz. Wouldn't reducing IF bandwidth at tuner chip improve overall sensitivity (and maybe noise level)? best regards Michal Rogala

12 years, 1 month

2
2
0 0

RTL2832 GNU Radio Source block now in gr-baz

by Balint Seeber

Hi folks, I've just added RTL2832 support to gr-baz <http://wiki.spench.net/wiki/Gr-baz> with support for both tuners (Elonics E4000 and Fitipower FC0013). I've taken rtl-sdr <http://sdr.osmocom.org/trac/wiki/rtl-sdr> and created a fully-featured GNU Radio Source block <http://wiki.spench.net/wiki/Gr-baz#rtl_source_c> 'baz.rtl_source_c' (with GRC block) that outputs complex values, and allows adjustment of frequency, sample rate and LNA gain. There is also an optional automatic tuner mode control for the E4000. The Source block performs internal multi-threaded buffering for smoother performance (this might be over-engineered, but it seemed to help with the ExtIO plugin <http://wiki.spench.net/wiki/USRP_Interfaces> I mentioned in my previous post here). You can get the source code from my SVN <http://svn.spench.net/main/gr-baz/> or github <https://github.com/balint256/gr-baz> (though please visit the info page <http://wiki.spench.net/wiki/Gr-baz#rtl_source_c> first for more info/pre-reqs - e.g. libusb-1.0, etc). It's experimental, and not the prettiest because I actually ported it back from the ExtIO plugin, but it works for me and if you want to help test/clean it up then that would be very much appreciated! To see it in action, have a peek here: http://youtu.be/FUQd9HOVTk8 Balint @spenchdotnet <http://twitter.com/spenchdotnet>

12 years, 1 month

2
2
0 0

RTL2832 SDR plugin for HDSDR/etc

by Balint Seeber

Hi folks, 'rtl-sdr' is a great development. Thank you to all involved! I'd like to throw in my bit: I've just released a beta version of my ExtIO plugin <http://wiki.spench.net/wiki/ExtIO_USRP> with support for RTL2832+E4000 (my one is called 'ezcap'). This means you can use the DVB-T USB stick with Winrad <http://www.winrad.org/> /HDSDR <http://www.hdsdr.de/> /WRplus, etc. http://spench.net/r/USRP_Interfaces I've done a fair bit of work <http://wiki.spench.net/wiki/RF> in GNU Radio, but I find having a simple/functional 'software specan' (i.e. those apps) is another great test tool. The ExtIO plugin also lets you stream the received baseband data from the app to GNU Radio over your LAN (just use the UDP Source block!). Apart from RTL2832, the plugin also supports all USRPs, the FUNcube Dongle, and functions as a network client if you choose to connect your SDR hardware to a separate computer and wish to stream the data & control the radio across your LAN (lossless, compared to having to use a long length of coax!). This protocol/implementation is called BorIP <http://wiki.spench.net/wiki/BorIP> , and is essentially a transparent network abstraction for the SDR receivers mentioned above (not really necessary if you have a LAN-enabled USRP, but great for USRP 1 & B100). The BorIP server is included with the plugin's installer. Additionally, I recently released many new blocks (in the gr-baz <http://wiki.spench.net/wiki/Gr-baz> module) and patches <http://wiki.spench.net/wiki/GNU_Radio_Patches> for GNU Radio too, part of which enables native BorIP reception support in GNU Radio (BorIP Source block, and BorIP protocol/packet support for UDP Source Block). The enhanced Source blocks are handy because they will notify you of hardware/buffer overruns at the server and network packet loss. Other new blocks help with automatic FEC decoding, and also include Variable Delay (great for blind signal analysis), a simple eye diagram sink (originally from OP25 <http://op25.osmocom.org/> ) and a Fast Auto-correlation Sink <http://wiki.spench.net/wiki/Fast_Auto-correlation> (originally from 'Frank'). I'm probably going to add my own implementation of a native RTL2832 Source block to gr-baz tonight, so I may post again soon. Hope this is useful! Kind regards, Balint @spenchdotnet <http://twitter.com/spenchdotnet>

12 years, 1 month

2
1
0 0

Call for participation LSM/RMLL

by Mathias Coinchon

Dear Osmocom-SDR community, This email to inform you that the call for participation for the next Libre Software Meeting (LSM or RMLL: Rencontres Mondiales du Logiciel Libre) ends on 31st March: http://2012.rmll.info/en/participate/call-for-papers This edition will take place in Geneva from 7th to 12th July 2012 (7-8 general public days, 9-12 theme focused, professional). Personally, I'm co-coordinator of the media/TV/Radio/Graphics theme where we will have different projects for media and broadcasters presenting cases. There will be for example a presentation and demonstration of a high power transmission digital radio transmission based on CRC tools, USRP on a power amplifier/mask filter. It would be of great interest for the communities to learn about the Osmocom SDR and RTL SDR (in a presentation) and possibly play with them (in a workshop). Applications would be interesting too. So please don't hesitate to directly submit. Don't hesitate also to contact me for more information. Mathias Coinchon

12 years, 1 month

1
0
0 0

Osmo SDR board - buy

by Alan Campbell

Any idea when the SDR boards will be available to buy? And the cost? I was planning an SDR myself when I first saw the Osmo design. There are enough similarities to make yours worth buying - namely, the same FPGA I was looking at. I'm debating whether to buy the Lattice XP Brevia FPGA development kit. All else being equal, I'd rather give YOU guys the money... Regards, -- Alan Campbell - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - My own design ? That uses a SINGLE 12-bit ADC, clocked at 48 MHz (same as USB clock, makes for simpler circuit). The "Zero IF Tuner" becomes a superhet design, with an IF output of 60 MHz. Undersampling & downsampling in the FPGA gives a 12MHz bandwidth (actually less, depends if IFstage bandwidth & degree of downsampling) 2-stage RF front end: 1-30MHz (si 570 is 61-90MHz) and VHF 140-150MHz (si 570 is 80-90MHz). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

12 years, 1 month

2
1
0 0

Contributing to rtl-sdr (fc0012)

by David Basden

Hi! I'm just wondering what the best way to be able to contribute code into the rtl-sdr project is? I've added support for the FC0012 tuner (based on the dvb driver and cleaned up some), and would much rather contribute directly rather than fork it just for the sake of the stuff I write. There's a diff here: https://gist.github.com/2171926 against rtl-sdr a few days back. I've got a couple of fixes that aren't in that patch still to upload (like setting GPIO6 to flip the V/U band filter. Oops.) Cheers, David

12 years, 1 month

4
4
0 0

Rtl-Sdr

by Peter Hoffmann

Hy, I just stumbled over the rtl-sdr without any prior knowledge about srd or the osmocom-project. I'm sorry if this hole project is just not for newbies but I wanted to at least ask for help. I planing to use the Noxon DVB USB Stick as an sdr to listen to our baby monitor and extend it's radius this way. My first step is to listen to a fm radio station by collecting some I/Q on the stations frequency. But neither the I/Q nor the cfile I created using the gnu-radio companion results in data I can listen to sending it to /dev/audio. I assume, I'm making some major mistakes so I want to ask for some hints or reading advice (some M to RTFM ;-) Thank you, Hoffmann P

12 years, 1 month

2
2
0 0

RTL-SDR software

by Michał Rogala

Hi! A have a question regarding current development status of RTL-SDR project - does someone develop any additional tools than those available on osmocom git? Actually I'm developing ExtIO DLL library to connect various SDR software (ie. Winrad, HDSDR, etc) with RTL-SDR dongles. I'm asking because I don't want to duplicate someone's else work. best regards Michal Rogala

12 years, 1 month

1
0
0 0

Status Update

by Christian Daniel -- maintech GmbH

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi everybody, after a few weeks of apparent silence I'm here to report the current status of the OsmoSDR stick. I know that a bit more reporting and general traffic on the list would be good for the project, but please be patient with us since this project runs in all our spare time - and there is not much of that... I have to admit that the advent of the rtl-sdr is bit a kick into the stomach, but I fear that the problem lies with us and our slow progress. However I can only stress that the OsmoSDR will be more flexible, powerful, programmable (even stand-alone operation is possible!) and sensitive. Many of you don't care much about sensitivity, but you will notice the difference when you see it... But now to the facts: - - the OsmoSDR revision 2 review is completed and the PCBs are ordered - - depending on the workload of the PCB shop, we have to wait ten to 15 working days for the PCBs to ship to Stefan Reimann (DG8FAC) - - he will assemble 20 boards immediately (machine time is booked) - - after that we will tests and checks that no fatal bug remains - - after that the rest are assembled - - we will have about 100 boards then (most probably a few will need some rework as soldering is not a 100% process) For the revision 2 we changed the following things: - - clock output of the Si570 was reworked the mitigate voltage level problems on the E4000 input - - a lowpass in to E4000 input was added to kill harmonics from the Si570 (the Si570 produces a square wave signal) - - a ~20dB LNA was added to increase sensitivity to -125dB @ 450 MHz (at least we hope so :) - - a lowpass at the antenna input was added to avoid driving 100mW into the E4000 when a WLAN near to the stick goes on TX - - serial wire debugging for the SAM3U was added - - a few lines at the FPGA were rerouted - - LEDs moved to the border of the board - - the board was shrunk 1mm to fit into a casing - - the expansion pins were moved to fit into the 2.54mm grid (a breadboard should fit neatly on top) During the sensitivity tests I did two weeks ago I saw that the RX spectrum is pretty clean and the RX filters in the E4000 are really good. So - even with a few weeks delay - we can finally look forward to get our hands at the OsmoSDR and we will have a really good receiver at our hands! Cherio! 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/ iQEcBAEBAgAGBQJPaLNtAAoJEHkgzUIsAWrihOMIAIunTXO47hk4fcUxLjaj/mB3 24vBjxqpbnHWGgG35bLAjTICkpg0sZEgxppl3w7nKR1vzyoCVl2qdXfuFhrml/WP mREjLTjtYZB2o1snDKmyoV7jnvHlXKql4AbMnNz2XAlQ0kgDw+BLJf1CNvHpTeNK 6c0WA7XzVEZVYHiCBI8hDWl1/WUK2JLRdmJ7sFrINO40kn5ka5trUDDfCaAr/fAR +0rD0Fhqm3R7tOHmC9e4PWwslY1pGYB2pbcCbICHgEWlQQRSGxdSCzkEL0/STcuI rHuLTpfSrHkbn/TtHaIuVvfraAq8fRARiVqoMooIK0+h8bxfFiHxbHznuh33moY= =zTDS -----END PGP SIGNATURE-----

12 years, 1 month

4
5
0 0

FC0012 tuner

by Mathias Coinchon

Hi, The rtl-sdr is really great ! Congratulation and thank you for your work ! This really democratises the SDR to anyone with so low prices. I have an ezcap ez646 USB stick, based on rtl2832u but this one has a FC0012 tuner chip. I wondered if some of you had information or clues about this tuner as you have developped the driver for the FC0013. Then I could attempt to adapt the code for this stick. Regards Mathias Coinchon opendigitalradio.org

12 years, 1 month

3
4
0 0

Re: OsmoSDR sensitivity

by Dieter Spaar

Hello Christian, On Tue, 06 Mar 2012 17:49:02 +0100, "Christian Daniel -- maintech GmbH" <cd(a)maintech.de> wrote: > > The RX is not a sensitivity-wonder. Perhaps a preamp? I have to correct my previous posting, the Funcube has an LNA between antenna and the E4000 so the sensitivity numbers are not comparable. But maybe it is possible to use a similar circuit. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

12 years, 1 month

4
3
0 0

Re: OsmoSDR sensitivity

by Dieter Spaar

Hello Christian, On Tue, 06 Mar 2012 18:59:35 +0100, "Christian Daniel -- maintech GmbH" <cd(a)maintech.de> wrote: > > your package is still laying here... sorry... :((((((( (head -> desk) No problem, thats why I have looked for this USD 20 device ;-) Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

12 years, 1 month

1
0
0 0

Re: OsmoSDR sensitivity

by Dieter Spaar

Hello Christian, On Tue, 06 Mar 2012 17:49:02 +0100, "Christian Daniel -- maintech GmbH" <cd(a)maintech.de> wrote: > > The RX is not a sensitivity-wonder. Perhaps a preamp? According to the Funcube Technical FAQ: Each unit is tested for 0.15uV for 12dB SINAD NBFM at 145MHz and 435MHz I am not 100% sure how to compare this number with your results but this seems to be (much) better (if my quick calculation wasn't totally wrong). Also from my very short and quick experience with a DVB-T Stick based on an E4000 and RTL2832U, the sensitivity is quite good (I only tried DAB/FM/DVB-T so far with a very bad antenna inside a building). BTW, according to a newsgroup post this device also offers some sort of raw mode with around 2 MHz sample rate for 8-bit I/Q values. Not that bad for USD 20 including shipping ;-) Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

12 years, 1 month

1
0
0 0

OsmoSDR sensitivity

by Christian Daniel -- maintech GmbH

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi guys, I measured the sensitivity of our OsmoSDR. For that I did the following commands: tuner.init! tuner.freq=465000000 tuner.dc_calib! tuner.dc_table! tuner.gain=6,9,9,2,15,15 tuner.iqofs=43,27,0,0 I did the measurements on no-so-even frequencies to avoid any lines in the sprectrum. I increased the power from my signal generator until a SNR of 10dB as achieved. The RX was tuned 100kHz lower than the TX signal and the I/Q offset was calibrated before every measurement. 65.2MHz: -99dBm 145.2MHz: -102dBm 435.2MHz: -104dBm 945.2MHz: -85dBm 1300.2MHz: -89dBm 1500.2MHz: -89dBm 1800.2MHz: -84dBm Also please note that we have a hole at 1200 MHz - there are no valid PLL settings here. The RX is not a sensitivity-wonder. Perhaps a preamp? Best regards, 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/ iQEcBAEBAgAGBQJPVj/4AAoJEHkgzUIsAWripiAIAJ00dqh1/0MEehEdQrqtN4Ox dRHJrKSv1o+2I3HlAGLXCeAYXenaML1+hrmjZfoOCz9yYDabMD65/DVplU5lnvHT nkXEkJCdkdwOL2vieb1QD0aUmgRmjH1OugOS8DotjtmtGI4Wd/nqFn39gNVSb/hZ nC06jldOeTumgzH5dxv4VbBfbuCTpm5I8ShoA7+Ub4UNSWXLUJtQRwby0xXaR23S 6KWBZAMW8wJHW8Ish9NNEdZup32ZwhpbLGDVwspHNRyxYa5YUzYQK5medVJ2K+EL dO44kX/lHU+v5SxfOhjbqjJcJWt7WQWA+L1ROIpFV8DkRMT0EscR0v1No1ybQfA= =T3tF -----END PGP SIGNATURE-----

12 years, 1 month

1
0
0 0

OsmoSDR progress

by Christian Daniel -- maintech GmbH

-----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-----

12 years, 2 months

1
1
0 0

Status update OsmoSDR firmware

by Harald Welte

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)

12 years, 2 months

2
2
0 0

Updates to osmo-sdr.git / DFU loader + application example

by Harald Welte

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)

12 years, 3 months

1
0
0 0

[renet.f@gmail.com: Regarding the power supply for OsmoSDR]

by Harald Welte

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)

12 years, 3 months

1
0
0 0

Osmocom SDR update

by Harald Welte

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)

12 years, 4 months

2
1
0 0

USB driver / protocol strategy

by Harald Welte

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)

12 years, 4 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

osmocom-sdr