osmocom-sdr

osmocom-sdr@lists.osmocom.org

1 participants
910 discussions

Re: Beginner question about rtlsdr (Jared Clements)
by James Peroulas 25 Oct '12

25 Oct '12

> There is another way, and that's find a known RF signal that we can use for > synchronization. GPS would be ideal, because there's explicit solutions for > time offsets/drift that's referenced to atomic clocks. We could record 5 > minutes or so on the L1 band before an observation, then mid-capture tune > to our frequency of interest...assuming we can shift the e4k chip without > interupting the RTL2832 in it's capture sequence. > I'm not very familiar with your application, but you may also have to do sub-sample time offset estimation and compensation. Even though all of the dongles are running at exactly the same sampling *rate*, their sampling * instants* will likely be different. This is despite the fact that you used the same length of cable to feed the clock to all the dongles. For example, if you want a 2.88MHz sampling rate, this will involve dividing the 28.8MHz input by a factor of 10. One dongle might use edge numbers 0, 10, 20, 30, ... of the source clock to produce the 2.88 MHz clock and another might used edge numbers 3, 13, 23, 33, .... Their sampling frequencies will be exactly the same, but the sampling instant will be different. > Does anyone here know if this is possible? Shift the tuner without > interupting the capture? > I can confirm that you can do this since this is what I did in my LTE cell scanner to improve search speed. I configured the A/D rate once, and then I just kept changing the LO frequency. The thing is that once you change the LO frequency, the phase rotation of the received signal will change randomly for all the dongles. So, during the calibration phase, you might find that dongle 1 needs a time correction of t1 and phase correction of p1 to get its signal to align with the signal from dongle 2. After you change the LO, dongle 1 will still need the same time correction (t1), but you wont know what phase to use. Perhaps phase alignment isn't necessary for your application? BR, James -- *Integrity is a binary state - **either you have it or you don’t.* - John Doerr

1 0

Beginner question about rtlsdr
by Michel Pelletier 22 Oct '12

22 Oct '12

Hello everyone, I hope this is an appropriate forum for a beginner question about using an E4000 dongle. I'm an amateur astronomer, and lately I've been wanting to get into amateur radio astronomy. The rtlsdr seems like a really cheap way to get involved. It can tune many interesting frequencies, in particular channel 37 around 608-614 Mhz. I am a Python programmer by trade so I am using roger-'s amazing pyrtlsdr library which is great, I can read samples from the device and they get returned as numpy arrays. The scipy.signal package allows me to correctly decimate the signal and I am working on a simple graphing program to graph signal levels in realtime, by hour, by day, and by week. I hope to basically reproduce the Jansky experiment that started the entire science of radio astronomy: http://en.wikipedia.org/wiki/Karl_Guthe_Jansky I have a question though about how to use the dongle that I can't quite figure out. roger-'s demo_waterfall program, for example, sets the default sample_rate to 1.4e6, but then on each scan only calls read_samples(2**16). The demo displays the entire megahertz of bandwidth, so I'm a bit confused as to how the 64K samples map onto the 1M samples of the device. It doesn't seem to make sense taht the device only returns the first 64K samples. Can anyone clue in a total beginner on the sample rate and reading samples from the device correlate? Thank you! -Michel

4 12

RTL-SDR with MSI DIGIVOX Micro HD suppot
by Höss Lajos 22 Oct '12

22 Oct '12

Hi, I have USB DVB-T stick. Possibly add suport for rtl-sdr? Name: MSI DIGIVOX Micro HD (Dexatek clone?, i see black diamond design, same as Dexatek, and i found 1d19 = Dexatek) USB ID (from linux and windows): 1d19:1104 Working (very old) driver for linux rtl2832u, my linux very old, i cannot complile the current rtl-sdr because libusb, etc. too old. I will ugrade to new linux, but requies long time. I not know how to identify the tuner, but from dmesg i think this device use rtl2832 chipset + FC2580 tuner I try with nightly build sdl-sharp, and the latest http://sdr.osmocom.org/trac/attachment/wiki/rtl-sdr/RelWithDebInfo.zip on windows, no succes. mngc

2 1

Mis-detected E4000 instead of FC0013 tuner when using NOXON DAB Stick on Raspberry Pi
by Christoph Gommel 18 Oct '12

18 Oct '12

Hello Guys, First of all: I am amazed by your project - many ideas come up in my head what can be done with this tiny cheap SDR. I have tested rtl_sdr with a linux-vm on my Mac successfully but wanted to run it on my raspberry pi. Unfortunately and thithout an explainable reason to me the tools detect an E4000 instead of the soldered FC0013 on my stick - but only on the PI. To fix this issue I have changed the detection order in librtlsdr.c: diff --git a/src/librtlsdr.c b/src/librtlsdr.c index 3a67b53..cb34f1d 100644 --- a/src/librtlsdr.c +++ b/src/librtlsdr.c @@ -1073,13 +1073,6 @@ int rtlsdr_open(rtlsdr_dev_t **out_dev, uint32_t index) /* Probe tuners */ rtlsdr_set_i2c_repeater(dev, 1); - reg = rtlsdr_i2c_read_reg(dev, E4K_I2C_ADDR, E4K_CHECK_ADDR); - if (reg == E4K_CHECK_VAL) { - fprintf(stderr, "Found Elonics E4000 tuner\n"); - dev->tuner_type = RTLSDR_TUNER_E4000; - goto found; - } - reg = rtlsdr_i2c_read_reg(dev, FC0013_I2C_ADDR, FC0013_CHECK_ADDR); if (reg == FC0013_CHECK_VAL) { fprintf(stderr, "Found Fitipower FC0013 tuner\n"); @@ -1088,6 +1081,13 @@ int rtlsdr_open(rtlsdr_dev_t **out_dev, uint32_t index) goto found; } + reg = rtlsdr_i2c_read_reg(dev, E4K_I2C_ADDR, E4K_CHECK_ADDR); + if (reg == E4K_CHECK_VAL) { + fprintf(stderr, "Found Elonics E4000 tuner\n"); + dev->tuner_type = RTLSDR_TUNER_E4000; + goto found; + } + /* initialise GPIOs */ rtlsdr_set_gpio_output(dev, 5); After compiling the lib the FC0013 is detected and the sticks works great on my Pi. Of course this is not a perfect solution and I will figure out later in depth WHY the E4K_CHECK_VAL comes out of the FC0013. Anybody else who has or had the same problems? the Hardware used is: Bus 001 Device 004: ID 0ccd:00b3 TerraTec Electronic GmbH NOXON DAB/DAB+ Stick regards Christoph

5 4

bug and parameters for rtl_fm
by Alain Prignet 18 Oct '12

18 Oct '12

Hello, I have found what I think is a bug in rtl_fm.c : on line 171 there is if (fm->prev_index < (fm->downsample)) { but fm->prev_index start at -1 so to get an undersampling of factor fm->downsample, one should have if (fm->prev_index < (fm->downsample-1)) { Without this correction, I get underruns, with this one, there is no underrun. Moreover, I have tried the idea of http://www.embedded.com/design/embedded/4212086/DSP-Tricks--Frequency-demod… to avoid atan : +int polar_discriminant2(int ar, int aj, int br, int bj) +{ + int cr, cj; + double angle; + angle = (double)(ar * (aj - bj) - aj * (ar - br)) / (double)(ar*ar + aj*aj); + return (int)(angle*(1<<12)); +} Finally, to get good results, I use these parameters : DEFAULT_BUF_LENGTH (32 * 16384) capture_rate = 2304000 fm->downsample = 12 fm->post_downsample=8 sample_rate = 24000 Best regards, Alain Prignet

1 0

Sweex USB dongle with rtl_sdr
by Andrew Harrison 05 Oct '12

05 Oct '12

Hi There I have been working with a Sweex USB dongle that has the RTL3282u - FC0012 chipset. Its id is "1f4d:a803 G-Tek Electronics Group" I have been able to get it working with rtl_sdr and rtl_fm. Can you add its id to the source code for others to use. Andrew Harrison.

2 1

Issues with rtl_tcp
by Scott Cutler 02 Oct '12

02 Oct '12

I've ported my app to use rtl_tcp.exe instead of the native rtlsdr libs, and while it is partly working (samples reading correctly, no dropped samples, etc.), I have run into two issues. First--when I start reading samples too quickly after setting the sample rate, I get this error: C:\Users\Scott Cutler\Projects\p4\0\projects\sdr\SeeDeR\SeeDeR\rtl-sdr-release\x32>rtl_tcp.exe -f 100000000 -s 2048000 Found 1 device(s). Found Elonics E4000 tuner Using Generic RTL2832U (e.g. hama nano) Tuned to 100000000 Hz. listening... Use the device argument 'rtl_tcp=127.0.0.1:1234' in OsmoSDR (gr-osmosdr) source to receive samples in GRC and control rtl_tcp parameters (frequency, gain, ...). client accepted! set freq 105000000 set sample rate 1920000 worker cond timeout Signal caught, exiting! comm recv socket error Signal caught, exiting! all threads dead.. listening... Use the device argument 'rtl_tcp=127.0.0.1:1234' in OsmoSDR (gr-osmosdr) source to receive samples in GRC and control rtl_tcp parameters (frequency, gain, ...). If I instead wait about two seconds after setting the sample rate, there is no problem. There is also no problem if I immediately read samples after connecting, where I set the sample rate on the command line. The other issue is that tuning is very slow--about one second per call to rtlsdr_set_center_freq. I had a similar problem with the rtlsdr.dll library, and I found that tuning was very slow if performed from the main thread, but fairly quick (maybe 10-20 hz) if done from the async proc thread that rtlsdr_read_async launches. That seemed a bit odd to me but it worked. I suspect that rtl_tcp.exe is doing the same thing; calling rtlsdr_set_center_freq from the main thread. Ideas, anyone? Thanks! -Scott PS: I'm running Win7-64, in case it matters. Also using the latest version here: http://sdr.osmocom.org/trac/attachment/wiki/rtl-sdr/RelWithDebInfo.zip

6 12

Pricing and Availability
by Alan Campbell 29 Sep '12

29 Sep '12

There's been a couple of messages now, asking when you intend to release actual product. I suspect that, provided you warn people about the "rough around the edges" code, the actual HARDWARE is good enough to sell. The repair of code, relating to debugging, will improve when more people have the hardware - and can send fault reports. You may want your code to be as perfect as the Sistine Chapel - but even Michaelangelo had to let the chapel be used while he painted. -- Alan

2 1

OsmoSDR
by Simon G4ELI/HB9DRV 28 Sep '12

28 Sep '12

Hi All, I stumbled across the OsmoSDR on http://sdr.osmocom.org/trac/ - does this supply 16-bit or maybe even higher samples? It looks great J , I'm sure a high quality SDR with this frequency range will be very popular. Simon G4ELI/HB9DRV http://dit-dit-dit.com

2 1

Licensing issues
by Scott Cutler 26 Sep '12

26 Sep '12

Greetings, all! I've recently been bitten by the rtlsdr bug and have since developed some software around it. It's Windows-based and currently decodes (mono) WFM, NFM, POCSAG, FLEX 1600/6400, and (very limited) AX.25 frames. I would like to make a semi-limited release but have some concerns about the licensing of the rtlsdr library after what SDR# went through (or seemed to go through--I'm not sure what the whole story was). I do plan on open-sourcing the whole thing eventually, but in the short term I'll probably have a limited read-only license. Simply put, am I in the clear if I: - only access rtlsdr.dll through my own reimplementation of rtl-sdr.h and rtl-sdr_export.h - do not distribute the binary rtlsdr.dll, but instead link to the Osmocom binaries Thanks for the help! - Scott

6 13

← Newer
1
...
79
80
81
82
83
84
85
...
91
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

osmocom-sdr