January 2015 - osmocom-sdr - lists.osmocom.org

HackRF powered antenna support (pleeeeease :)
by Brad Hein 15 May '15

15 May '15

I would like to humbly request support for hackrf antenna power in gr-osmosdr. At runtime preferably, or at least an init string flag to control it (hackrf=0,antenna_power=1 for example). The function call seems to be hackrf_set_antenna_enable() but it's not exposed in gr-osmosdr as far as I can tell. I have some dev experience (but not in C) but I'm falling short trying to understand the code and add the feature myself. If someone wants to provide some "ELI5" guidance I'll be happy to give it another go. Having this feature would open up the powered antenna feature to users of gr-osmosdr such as gnuradio, gqrx, and the list goes on (big win!) Reference: https://www.mail-archive.com/hackrf-dev@greatscottgadgets.com/msg00423.html Thanks! Brad

1 1

add new Hardware ID (VID / PID) of already supported device - no listet yet
by Martin Hochdekker 01 Feb '15

01 Feb '15

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

1 0

add new Hardware ID (VID / PID) of already supported device - no listet yet
by Martin Hochdekker 31 Jan '15

31 Jan '15

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. Sincerely, Martin

1 0

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