- osmocom-sdr - lists.osmocom.org

compiling rtl-sdr on cygwin
by Simon Eigeldinger 21 Jan '15

21 Jan '15

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

1 0

gr-osmosdr v0.0.2-76-gc7cb045f (0.0.3git) bug
by Itsuugo 20 Jan '15

20 Jan '15

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

1 0

Segfaults in libusb / rtlsdr_close
by Oliver Jowett 17 Jan '15

17 Jan '15

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

1 0

USRP overrun with B210
by altaf sk 14 Jan '15

14 Jan '15

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

1 0

Eagle CAD .brd
by Brian Compton 10 Jan '15

10 Jan '15

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

1 0

Info about Gigabyte GT-U7300
by Tibor Zenis 03 Jan '15

03 Jan '15

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 : '``'`'``'`'``'`'``'`'``'`'``'

1 0

How to cross-correlate two I/Q streams of same radio-station?
by Andreas Hornig 25 Dec '14

25 Dec '14

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

1 0

rtl_sdr for Yocto?
by Petter Gustad 18 Dec '14

18 Dec '14

Is there a meta layer or other method to include rtl_sdr in Yocto? Thanks! //Petter

1 0

Question about rtlsdr read_sync()
by Allen Welkie 24 Nov '14

24 Nov '14

Just trying to figure out how to use the rtlsdr_read_sync() function, and I'm not understanding just by reading the source. Am I supposed to call this function continuously in a loop in a thread separate from the sample processing, or can I do some processing in between calls to rtlsdr_read_sync()? In other words, are the samples being buffered on the rtlsdr device in between calls? If so, what's the size of that buffer? Also, what functions need to be called before I can use the read_sync or read_async functions? I'm calling rtlsdr_open, rtlsdr_set_center_freq, and rtlsdr_set_sample_rate before calling rtlsdr_read_sync, but I'm not getting any samples (and subsequent calls to rtlsdr_read_sync or read_async fail, e.g. from running the rtlsdr_fm program). Thanks, Allen

1 0

Segmentation Fault on OsmoSDR-Source
by staufenbiel 19 Nov '14

19 Nov '14

Hi, I'm running a RTL-SDR over a Raspberry Pi. On my old machine everthing worked fine. But now I had to move to another machine and I'm getting this output everytime I start my programm: linux; GNU C++ version 4.7.2; Boost_104900; UHD_003.007.002-0-unknown Warning: failed to XInitThreads() Gtk-Message: Failed to load module "canberra-gtk-module" Using Volk machine: avx_64_mmx_orc gr-osmosdr 0.1.3 (0.1.3) gnuradio 3.7.5 built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf rfspace airspy Segmentation fault I have installed GNU Radio with the build-gnuradio script. So everthing should be installed correctly. Thank you for your help! Björn

1 0