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