osmocom-sdr

osmocom-sdr@lists.osmocom.org

1 participants
910 discussions

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

21 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 18 Jan '15

18 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 19 Dec '14

19 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

sdriq on mac
by Alexander Tudor 18 Nov '14

18 Nov '14

Hi, I have tried to use gqrx with an RFSPACE sdriq using the gr-osmosdr. The experiment failed on both 10.7.5 and 10.9.5 despite following the ftdi site instructions for either OS. I have installed all s/w via mac ports. D2XX is installed in /usr/local/lib and, according to the suggestion of a person from Ettus, tried to set DYLD_INSERT_LIBRARIES=/usr/local/lib/libftd2xx.1.2.2.dylib gxrz. All to no avail. When I run gqrx I get: and if I edit the settings, I get: But there is not /dev/ttyUSB0 nor do I know why a device is required if there is direct access (I suppose via libusb?). System profiler clearly show the device: Could anybody tell me what is the prescribed way of achieving what I am trying, or a way of debugging what is wrong? Thank you, Alex

1 0

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

osmocom-sdr