osmocom-sdr

osmocom-sdr@lists.osmocom.org

904 discussions

rtl-sdr line to support Asus U3100 MINI_PLUS_V2
by daniel . 11 Jun '13

11 Jun '13

Hello The Asus U3100MINI_PLUS_V2 rtp_eeprom output is: $ rtl_eeprom Found 1 device(s): 0: Afatech Using device 0: Afatech Found Fitipower FC0013 tuner Current configuration: ______________________________ ____________ Vendor ID: 0x1b80 Product ID: 0xd3a8 Manufacturer: Realtek Product: Rtl2832UDVB Serial number: Serial number enabled: no IR endpoint enabled: no Remote wakeup enabled: yes the line to add support to this is in librtlsdr.c - known_devices { 0x1b80, 0xd3a8, "Afatech" }, thanks.

1 0

rtl-tcp-server running on avm-fritzbox
by df8oe＠gmx.de 10 Jun '13

10 Jun '13

I want to use a rtl-dvb-stick connected to a fritz-box-dsl-router via tcp. Software running on the fritzbox is freetz (www.freetz.org) and cpu-architecture is mips. So I created a makefile and compiled the software without errors. But when I start the software (usb-dongle connected) it throws a usb_claim_interface error -5. rtl_test recognizes the type of stick correctly but throws identical error message. So I started rtl_test with strace - here you can find the output: http://www.df8oe.de/output.txt Any tipps for solving the problem are welcome ;) Best regards df8oe

4 13

Need source for rtlsdr.dll !!
by Fritz Meier 06 Jun '13

06 Jun '13

Hello, i would like to work in ARM-Cpu environment with the RTL2832 dongle therefor i need the Arm-WinCE .dll or Arm-Linux .o . Where i can download the C, or C++ or Pascal source ? Thanks for your help Fritz

4 3

(no subject)
by Jeff Allen 06 Jun '13

06 Jun '13

Please remove me from your email list, thanks

1 0

[rtl-sdr] store frequency correction in eeprom?
by Benedikt Heinz 30 May '13

30 May '13

Some of you are probably using multiple dongles with alternating applications as well. Regarding the frequency correction, I put a sticker on each dongle and wrote the ppm value on it. However manually setting the value in each application is still annoying. So I used rtl_eeprom to write the value into the product-ID with the following format: "RTL%+dppm" resulting in sth. like this: RTL+87ppm I'm not sure if this is the best way to do it, but this approach works without changing librtlsdr. Another option might be storing the value in a non-used eeprom location and adding get/set functions to librtlsdr. Is it possible to write arbitrary values to unused eeprom locations without fucking up the realtek eeprom handling? Do you think this would be a better way? I'd like to hear your comments on this. It would be awesome if we could find a solution that many existing applications could incorporate. (Of course the ppm value still changes with temperature, but having a base value is still closer to the truth than 0ppm I'd say. I measured the offset directly after grabbing samples for 20 minutes at room-temperature and jitter is <1ppm.) Best regards, Hunz

4 3

[PATCH 0/2] Store frequency calibration in EEPROM
by Andreas Seltenreich 29 May '13

29 May '13

Hi, I modified my copy of rtl-sdr to be able to store frequency calibration on the sticks themselves. Maybe this change is generally useful? Thanks, andreas Andreas Seltenreich (2): rtl_eeprom: Add -x to store exact xtal frequency in Hz. lib: Try reading xtal calibration from EEPROM. src/librtlsdr.c | 21 +++++++++++++++++++-- src/rtl_eeprom.c | 17 ++++++++++++++++- 2 files changed, 35 insertions(+), 3 deletions(-) -- 1.7.10.4

1 0

[PATCH 2/2] lib: Try reading xtal calibration from EEPROM.
by Andreas Seltenreich 29 May '13

29 May '13

Interpret last four bytes of EEPROM as value in Hz using network byte order and use it as default if it is between MIN_RTL_XTAL_FREQ and MAX_RTL_XTAL_FREQ. --- src/librtlsdr.c | 21 +++++++++++++++++++-- 1 file changed, 19 insertions(+), 2 deletions(-) diff --git a/src/librtlsdr.c b/src/librtlsdr.c index 2f5d90a..c986018 100644 --- a/src/librtlsdr.c +++ b/src/librtlsdr.c @@ -25,6 +25,9 @@ #ifndef _WIN32 #include <unistd.h> #define min(a, b) (((a) < (b)) ? (a) : (b)) +#include <arpa/inet.h> +#else +#include <WinSock2.h> #endif #include <libusb.h> @@ -279,6 +282,7 @@ static rtlsdr_dongle_t known_devices[] = { #define BULK_TIMEOUT 0 #define EEPROM_ADDR 0xa0 +#define EEPROM_SIZE 256 enum usb_reg { USB_SYSCTL = 0x2000, @@ -1365,14 +1369,27 @@ int rtlsdr_open(rtlsdr_dev_t **out_dev, uint32_t index) goto err; } - dev->rtl_xtal = DEF_RTL_XTAL_FREQ; - /* perform a dummy write, if it fails, reset the device */ if (rtlsdr_write_reg(dev, USBB, USB_SYSCTL, 0x09, 1) < 0) { fprintf(stderr, "Resetting device...\n"); libusb_reset_device(dev->devh); } + dev->rtl_xtal = DEF_RTL_XTAL_FREQ; + + /* Allow for the last four bytes of the EEPROM to contain a + calibration frequency. */ + { + uint32_t rtl_freq; + + if (0 < rtlsdr_read_eeprom(dev, (void *)&rtl_freq, EEPROM_SIZE-4, 4)) + rtl_freq = ntohl(rtl_freq); + if (rtl_freq >= MIN_RTL_XTAL_FREQ && rtl_freq <= MAX_RTL_XTAL_FREQ) { + fprintf(stderr, "Found valid XTAL calibration in EEPROM: %u Hz\n", + dev->rtl_xtal = rtl_freq); + } + } + rtlsdr_init_baseband(dev); dev->dev_lost = 0; -- 1.7.10.4

1 0

[PATCH 1/2] rtl_eeprom: Add -x to store exact xtal frequency in Hz.
by Andreas Seltenreich 29 May '13

29 May '13

Stored in the last four bytes of the eeprom in network byte order. --- src/rtl_eeprom.c | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/src/rtl_eeprom.c b/src/rtl_eeprom.c index 35191de..51024d6 100644 --- a/src/rtl_eeprom.c +++ b/src/rtl_eeprom.c @@ -23,8 +23,10 @@ #ifndef _WIN32 #include <unistd.h> +#include <arpa/inet.h> #else #include <Windows.h> +#include <WinSock2.h> #include "getopt/getopt.h" #endif @@ -84,6 +86,7 @@ void usage(void) "\t[ terratec_plus\tTerratec T Stick+ (DVB-T/DAB)]\n" "\t[-w <filename> write dumped file to device]\n" "\t[-r <filename> dump EEPROM to file]\n" + "\t[-x <Hz> store calibrated XTAL frequency]\n" "\t[-h display this help text]\n" "\nUse on your own risk, especially -w!\n"); exit(1); @@ -262,9 +265,10 @@ int main(int argc, char **argv) int default_config = 0; int change = 0; int ir_endpoint = 0; + uint32_t xtal_freq = 0; char ch; - while ((opt = getopt(argc, argv, "d:m:p:s:i:g:w:r:h?")) != -1) { + while ((opt = getopt(argc, argv, "d:m:p:s:i:g:w:r:x:h?")) != -1) { switch (opt) { case 'd': dev_index = atoi(optarg); @@ -306,6 +310,9 @@ int main(int argc, char **argv) case 'r': filename = optarg; break; + case 'x': + xtal_freq = htonl(atol(optarg)); + break; default: usage(); break; @@ -347,6 +354,14 @@ int main(int argc, char **argv) if (r < 0) return -1; + if(xtal_freq) { + r = rtlsdr_write_eeprom(dev, (void*)&xtal_freq, EEPROM_SIZE-4, 4); + if (r < 0) + fprintf(stderr, "Error while writing XTAL frequency to EEPROM: %i\n", r); + else + fprintf(stderr, "XTAL frequency successfully written.\n"); + } + fprintf(stderr, "Current configuration:\n"); parse_eeprom_to_conf(&conf, buf); dump_config(&conf); -- 1.7.10.4

1 0

Updated gr-osmosdr for GNU Radio 3.7
by Tom Rondeau 25 May '13

25 May '13

Not sure if anyone else had worked on this, but I couldn't find anything. I updated gr-osmosdr to work with GNU Radio 3.7 (currently the next branch). You can find it here: https://github.com/trondeau/gr-osmosdr I didn't redo the code to be in the 3.7 API style, just made sure that it could build off gnuradio and run properly. Tom

1 0

Regarding offset tuning in rtl_fm.c - the math
by Aaron Rossetto 25 May '13

25 May '13

Hi all, I recently got a Raspberry Pi and an RTL2832 USB card and have been successful in compiling rtl-sdr and running the associated examples, piping the data up into LabVIEW for analysis with their Demodulation Toolkit. I'm a little weak on the signal processing math knowledge here, so I was wondering if someone could explain the math behind the offset tuning code in rtl_fm's optimal_settings() function. It looks like the function takes the desired center tuning frequency and calculates an integer decimation ratio based on a "capture rate" near 1 MHz and the desired final sampling rate. Then the center frequency is offset by a quarter of the capture rate, and this and the capture rate are used to program the radio. Then in the receive callback, the I/Q data is shifted 90 degrees in rotate_90(). At this point, the I/Q data represents (I presume!) the spectrum around the original desired center frequency and at the original sample rate. How do I get, mathematically speaking, from the oversampled I/Q data centered at the offset frequency to *my* desired center frequency and sample rate? I'm especially curious as to the effect of the frequency offset using that particular value (capture rate/4) and what role the rotation plays in the transformation. Thanks, Aaron

1 0

← Newer
1
...
65
66
67
68
69
70
71
...
91
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

osmocom-sdr