From zenis at fmph.uniba.sk Sat Jan 3 10:40:35 2015 From: zenis at fmph.uniba.sk (Tibor Zenis) Date: Sat, 3 Jan 2015 11:40:35 +0100 Subject: Info about Gigabyte GT-U7300 Message-ID: <20150103104035.GA811@melkor.dnp.fmph.uniba.sk> 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 : '``'`'``'`'``'`'``'`'``'`'``' -------------- next part -------------- A non-text attachment was scrubbed... Name: GT-U7300_filters_log.png Type: image/png Size: 8750 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: GT-U7300_filters.png Type: image/png Size: 7122 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: GT-U7300_samples_996.43.png Type: image/png Size: 6443 bytes Desc: not available URL: From warhawk-avg at comcast.net Sat Jan 10 00:29:32 2015 From: warhawk-avg at comcast.net (Brian Compton) Date: Sat, 10 Jan 2015 00:29:32 +0000 (UTC) Subject: Eagle CAD .brd Message-ID: <743533860.304545.1420849772972.JavaMail.zimbra@comcast.net> Does anyone have the .brd file, it can be sent to OSHPark and fabricated for pretty cheap Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From altaf329 at gmail.com Wed Jan 14 11:29:38 2015 From: altaf329 at gmail.com (altaf sk) Date: Wed, 14 Jan 2015 12:29:38 +0100 Subject: USRP overrun with B210 Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From oliver.jowett at gmail.com Sat Jan 17 18:21:47 2015 From: oliver.jowett at gmail.com (Oliver Jowett) Date: Sat, 17 Jan 2015 18:21:47 +0000 Subject: Segfaults in libusb / rtlsdr_close Message-ID: 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 From itsuugo at gmail.com Tue Jan 20 22:22:07 2015 From: itsuugo at gmail.com (Itsuugo) Date: Tue, 20 Jan 2015 23:22:07 +0100 Subject: gr-osmosdr v0.0.2-76-gc7cb045f (0.0.3git) bug Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.eigeldinger at vol.at Wed Jan 21 20:34:11 2015 From: simon.eigeldinger at vol.at (Simon Eigeldinger) Date: Wed, 21 Jan 2015 21:34:11 +0100 Subject: compiling rtl-sdr on cygwin Message-ID: <54C00D43.60607@vol.at> 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 at vol.at MSN: simon_eigeldinger at hotmail.com ICQ: 121823966 Jabber: domasofan at andrelouis.com --- Diese E-Mail wurde von Avast Antivirus-Software auf Viren gepr?ft. http://www.avast.com From k1gto at comcast.net Thu Jan 22 17:03:57 2015 From: k1gto at comcast.net (Brad Hein) Date: Thu, 22 Jan 2015 17:03:57 +0000 (UTC) Subject: HackRF powered antenna support (pleeeeease :) In-Reply-To: <96851798.8610188.1421945881433.JavaMail.zimbra@comcast.net> Message-ID: <1830181702.8619591.1421946237131.JavaMail.zimbra@comcast.net> 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 at greatscottgadgets.com/msg00423.html Thanks! Brad -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.hochdekker at gmail.com Sat Jan 31 23:44:33 2015 From: martin.hochdekker at gmail.com (Martin Hochdekker) Date: Sun, 1 Feb 2015 00:44:33 +0100 Subject: add new Hardware ID (VID / PID) of already supported device - no listet yet Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.hochdekker at gmail.com Sat Jan 31 19:11:50 2015 From: martin.hochdekker at gmail.com (Martin Hochdekker) Date: Sat, 31 Jan 2015 20:11:50 +0100 Subject: add new Hardware ID (VID / PID) of already supported device - no listet yet Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: