osmocom-sdr

osmocom-sdr@lists.osmocom.org

1 participants
904 discussions

by Leif Asbrink

Hi All, The rtl-sdr library from Osmocom uses R820T with an IF filter bandwidth of 5 MHz. This means that the peak amplitude of all the signals within this bandwidth has to be below the point of saturation for tha ADC. To accomplish that on a crowded FM band it is necessary to turn down the gain which means that weak stations can not be heard because of the degraded NF. It is possible to do much better. The IF filter which actually is a low pass filter and a high pass filter can be set for a bandwidth of 300 kHz. Dynamic range increases by something like 30 dB for the second next channel 400 kHz away. It is also possible to get some more improvement by changing the gain distribution. Sampling should remain at 2.4 MHz because the stop band attenuation is not very high and if sampling at 300 kHz one would get aliases from signals outside the filter if they are strong. Here is a video showing the difference between the Osmocom library and a modified library: https://www.youtube.com/watch?v=btDiWHuI730 Amusing that the cheap dongle has lower phase noise than the low noise synthetized generator from Hewlet Packard. An oldfashioned vacuumtube generator is needed to find the performance of the dongle... The modified library can be obtained like this: git clone https://github.com/dl8aau/librtlsdr A dll for Windows is available here: https://drive.google.com/file/d/0B9m6SAaGpewQeWtyS0lzdW1xVmM/view?usp=shari… Linrad-04.04 will soon become available here: http://www.sm5bsz.com/linuxdsp/linrad.htm Regards Leif

10 years, 4 months

add new Hardware ID (VID / PID) of already supported device - no listet yet

by Martin Hochdekker

Hello, I want to inform you about a new hardware ID that is currently not yet listet in sourcecode, but does work out of the box once the VID / PID is added to the list in "librtlsdr.c". https://github.com/steve-m/librtlsdr/blob/master/src/librtlsdr.c#L316 Hardware ID: *15f4:0133* VID: 15f4 PID: 0133 Manufacturer: HanfTek We already tried it out successfully under Linux by adding a new line with these specifications to "librtlsdr.c" and compiled. We successfully ran rtl_test, rtl_tcp and rtl_fm. I want to run it with SDR# Windows and was told to get in contact with the developers of the driver, in order to get it working. ------------------------- I don't know how long it takes the maintainer / developer to add the line, compile and provide the binaries officially... But I tried on my own like 20 times to compile steven-m's rtl-sdr from github under *Windows* 7 with my modified librtlsdr.c with no success. Although I dont have any experience in compiling stuff on Windows. So I'm wondering, maybe is there someone who does know how to compile - please please would you compile a modified version and send me the specific binarys for testing? :D I can't compile them on my own - it's just horrible. If u know how to compile it: just clone the sourcecode from https://github.com/steve-m/librtlsdr. Then open the* file "librtlsdr.c"* and *add a new line after line 316:{ 0x15f4, 0x0133, "HanfTek DVB-T" },* *Anyone can do this for Windows 7? Pleaz* Sincerely, Martin

10 years, 4 months

add new Hardware ID (VID / PID) of already supported device - no listet yet

by Martin Hochdekker

10 years, 4 months

compiling rtl-sdr on cygwin

by Simon Eigeldinger

hi all, has someone compiled rtl-sdr on cygwin? can someone tell me how to do that? because the normal way of doing it seems to not work. greetings, simon -- Simon Eigeldinger Follow me on Twitter: http://www.twitter.com/domasofan/ E-Mail: simon.eigeldinger(a)vol.at MSN: simon_eigeldinger(a)hotmail.com ICQ: 121823966 Jabber: domasofan(a)andrelouis.com --- Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. http://www.avast.com

10 years, 5 months

gr-osmosdr v0.0.2-76-gc7cb045f (0.0.3git) bug

by Itsuugo

Hi, I'm using gnuradio 3.6 and gr-osmosdr branch gr36. When I try to run some script like osmocom_fft or using a block the osmosdr source in gnuradio-companion it throws this message: File "/usr/local/lib/python2.7/dist-packages/osmosdr/osmosdr_swig.py", line 22, in swig_import_helper _mod = imp.load_module('_osmosdr_swig', fp, pathname, description) ImportError: /usr/local/lib/libgnuradio-osmosdr-0.0.3git.so.0.0.0: undefined symbol: _ZN3uhd6device4findERKNS_13device_addr_tENS0_15device_filter_tE It works well if compiling the gr-osmosdr without UHD support cmake -DENABLE_UHD=OFF ../ Hope this helps

10 years, 5 months

Segfaults in libusb / rtlsdr_close

by Oliver Jowett

I'm seeing crashes in libusb when calling rtlsdr_close, typically like this: cancel_async cancel_async done pthread_join read_async returned lock mutex signal cond unlock mutex thread finishing pthread_join done closing device rtlsdr_demod_write_reg failed with -1 rtlsdr_demod_read_reg failed with -1 r82xx_write: i2c wr failed=-1 reg=06 len=1 rtlsdr_demod_write_reg failed with -1 rtlsdr_demod_read_reg failed with -1 rtlsdr_write_reg failed with -1 [Thread 0xb6cd5470 (LWP 3232) exited] Program received signal SIGSEGV, Segmentation fault. 0xb6ef6c28 in libusb_submit_transfer () from /lib/arm-linux-gnueabihf/libusb-1.0.so.0 (gdb) bt #0 0xb6ef6c28 in libusb_submit_transfer () from /lib/arm-linux-gnueabihf/libusb-1.0.so.0 #1 0xb6ef83cc in libusb_control_transfer () from /lib/arm-linux-gnueabihf/libusb-1.0.so.0 #2 0xb6f0bfa4 in ?? () from /usr/lib/arm-linux-gnueabihf/librtlsdr.so.0 Cannot access memory at address 0x2ebd8a8 (Yeah, the stack's not very useful, but the eventual caller is definitely rtlsdr_close) There's a thread blocked in rtlsdr_read_async(), but I call rtlsdr_cancel_async() and wait for rtlsdr_read_async() to return (and the thread to terminate) before trying to close the device. This is with the current github version of librtlsdr on a Raspberry Pi with libusb 1.0.11 from the standard Raspbian package (2:1.0.11-1) Anyone seen this before? Oliver

10 years, 5 months

USRP overrun with B210

by altaf sk

Helo I am working with the LTE_FDD_DL_SCAN application which is running with a USRP B210 connected via USB3. The application works with flowgraph and connected to USRP source through gr-osmosdr. Running with a Sampling rate: 15.36MS/s Master clock rate: 15.36MS/s using gnuradio 3.7.3 and uhd 3.7.1 causes the overrun 'o' printed on stdout every 3-4 seconds. This problem is not seen when running over sampling rates less than 8MS/s. The signal processing function on the host has heavy computing and I do not want to change the decimation factor. I tried running the application with high priority but no success. Is it possible to solve with recv_buff_size parameter.? Does gr-osmosdr have any function (implemented) that can increase the buffer size. Can you suggest other ways to boost the speed and control overruns. Cheers Altaf

10 years, 5 months

Eagle CAD .brd

by Brian Compton

Does anyone have the .brd file, it can be sent to OSHPark and fabricated for pretty cheap Brian

10 years, 5 months

Info about Gigabyte GT-U7300

by Tibor Zenis

Hello, this device has the USB ID 1b80:d3a8, Fitipower FC0013 tuner. The frequency range is out of specification on page http://sdr.osmocom.org/trac/wiki/rtl-sdr . It is 13.5 - 1897.2 Mhz with a hole 948.6 - 996.6 MHz. This device has xtal_freq_div_2 = 14400000. For the hole, there is no valid PLL using multi = 4 and non-stable operation using multi = 2 (see the recorded samples for signal f + 50 kHz: GT-U7300_samples_996.43.png). The frequencies in the hole can be covered using multi = 3. I'm not sure if it is possible to set an odd number of the multi. I tested a response of this device using a "software driven generator" with output frequencies in the range 34.375 Mhz - 4.4 GHz. This generator doesn't have calibrated output power. Some waves in the frequency response can be created by both the generator also the tuner. I found a sharp steps in the response at 300 and 862 MHz. Band filters are changed at this frequencies: VHF for f < 300 MHz, UHF for 300 MHz < f < 862 MHz, GPS for f > 862 MHz. I modified the tuner_fc0013.c file to force the filter selection. The GPS filter is useless at all, VHF is usable up to 300 MHz, UHF is the best one for f > 250 MHz with no disadvantage for f > 35 MHz (lower frequencies not tested). This device using the UHF filter is usable up to 1.7-1.9 GHz. Could you insert this device to the list of supported devices? It should be fine to have a possibility to select the filters by software. I can make the modification of the file tuner_fc0013.c (and higher level files). Concerning the file tuner_fc0013.c, function fc0013_set_params(). There is a 64-bit variable f_vco, but a 32 value (f_vco = freq * multi) is assigned to it. The 32-bit value is enough for my device. I don't see any reason for using the 64-bit variable. Cheers, Tibor -- ,..,.,..,.,..,.,..,.,..,.,.., ; Tibor Zenis ; : zenis @ fmph . uniba . sk : '``'`'``'`'``'`'``'`'``'`'``'

10 years, 5 months

How to cross-correlate two I/Q streams of same radio-station?

by Andreas Hornig

Hi everyone and merry Christmas! :) I want to find the same snippet of I/Q data of a radio station in another I/Q recording of the same station but recorded with another dongle. Of course both with rtl-sdr dongles. I did this here http://filebin.net/8nevid3yk3 and played around with a python script and numpy math-lib to find this "needle" in the "haystack" and the timeshift. But it didn't work. That's why I am here to ask you how to do that. First of all, I would like to ask you if you could somehow check if both streams are actually containing the "same" I/Q data. Perhaps you can do that with one other software if you can find it. What I did was to use the numpy correlate function and added there some lines to have it normalized to have the results between -1 and 1 as explained here http://en.wikipedia.org/wiki/Cross-correlation#Normalized_cross-correlation But it couldn't find a needle sequence of 1000 samples that could be refound in the haystack (about 2000000 samples) when the starting of the needle samples were shifted a bit with some new 1000 samples. I guess that the analogue radio channel on this carrier and thus the I/Q doesn't form the I/Q enough to use each sample on that 2MHz sample rate, but much less in the KHz range. But I am not fully sure if this is true. This is why I am also here to ask about the influences on a cross correlation and how to set it up. So, any answer is very welcome. I hope it will work out in the end :). Best regards, Andreas

10 years, 6 months

← Newer
1
...
48
49
50
51
52
53
54
...
91
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

osmocom-sdr