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