- osmocom-sdr - lists.osmocom.org

[PATCH] clear warnings about compare signed-unsigned values
by P 10 Jan '16

10 Jan '16

This just removes few annoying warnings. About the conversion of string to signed int. - dev_index = boost::lexical_cast< unsigned int >( hackrf_serial ); + dev_index = boost::lexical_cast< int >( hackrf_serial ); hackrf_device_list_open checks if value of dev_index is out of range (eg negative) and returns proper error. In future negative value can be used for something so this check is not necessary nor wanted. P

2 1

gr-osmosdr setting value in destructor
by P 10 Jan '16

10 Jan '16

Hi, there is in gr-osmosdr a lot of code like: hackrf_source_c::~hackrf_source_c () { ... free(_buf); _buf = NULL; } } Setting value in destructor have sense in two case: - they are used in some way in destructor of parent class - You set then to something like 0xDEADBEEF and when pointer from already destroyed class is used it will cause segfault. Setting value to NULL is contraproductive because there is a lot of checks if value is not NULL, this actually can hide some troubles of calling something using already freed pointer. I'm suggesting to remove this kind of code. I will prepare patch but now I'm waiting if those two pending patches I have send before would be accepter or not. Is there any opinion which oppose previous claim? With best regards, JP.

2 1

gr-osmosdr broken on OSX due to MSG_NOSIGNAL
by Elliot Saba 10 Jan '16

10 Jan '16

It looks like the block to redefine MSG_NOSIGNAL as SO_NOSIGPIPE inside of redpitaya_common.cc needs to be copied into redpitaya_sinc_c.cc as well. -E

4 3

osmocom_fft won't tune BladeRF lower than 300MHz
by Ben Z en de rest 29 Dec '15

29 Dec '15

Hi. Today I installed latest gr-osmosdr. I want to run osmocom_fft and view the recorded file in "inspectrum". Osmocom_fft starts, runs, knows there is a BladeRF available and does work. only thing is that it does not allow tuning lower then 300 MHz as if the transverterboard is unknown to the osmocom_fft. I tried to start osmocom_fft with -a balderf but that does not help. If I set it to for example 145M it gives this message: Failed to set out of bound frequency: 1.45e+08 libbladerf is updated last weekend. Any ideas on this ? Thanks, Ben

1 0

Cmd structure for rtl_tcp
by jmaurin＠jonis.com.br 29 Dec '15

29 Dec '15

Hi List! I'm new here, so I hope I'm asking for help in the right place. I'm trying to build and application that read I/Q data from rtl_tcp using Delphi. For beginning, I'm trying to set some params for rtl_tcp using my remote app. I found the source code of rtl_tcp and I could identify some information about what is each command, like 0x01 (hex) is to set frequency, 0x02 to set sample, etc.... What I don't undertand is the structure of parameters. Each parameter is one byte? If not, how parameters are sent? Do I need to send char to end command, like end of line or carrier return? Is not, what's the correct structure for sending commands? For example: For setting gain, send one byte with 0x04 and another byte indicating the gain index. Tks! Jonis Maurin Ceará

1 0

gr-osmosdr fixes for soapy support, and msvc
by Josh Blum 07 Dec '15

07 Dec '15

Hey list, It looks like due to some GRC changes, the throw in set_iq_balance_mode() is no longer caught. Its causing a problem for GRC users and I would like upstream the fix. See soapy_support: http://cgit.osmocom.org/gr-osmosdr/log/?h=soapy_support I am building GNURadio and gr-osmosdr as part of my PothosSDR installer: https://github.com/pothosware/PothosSDR/wiki/GNURadio There were a few minor fixes to make for the MSVC compiler. The commits have explanatory messages, and I made sure that they were non-breaking. I would also like to upstream these fixes as well. See msvc_fixes: http://cgit.osmocom.org/gr-osmosdr/log/?h=msvc_fixes Thanks for your consideration, -josh

2 1

[PATCH] save gain only when set_gain is successful
by Joseph Poirier 29 Nov '15

29 Nov '15

Signed-off-by: Joseph Poirier <jdpoirier(a)gmail.com> --- src/librtlsdr.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/src/librtlsdr.c b/src/librtlsdr.c index cdf1ca9..fd435b7 100644 --- a/src/librtlsdr.c +++ b/src/librtlsdr.c @@ -1038,13 +1038,10 @@ int rtlsdr_set_tuner_gain(rtlsdr_dev_t *dev, int gain) rtlsdr_set_i2c_repeater(dev, 1); r = dev->tuner->set_gain((void *)dev, gain); rtlsdr_set_i2c_repeater(dev, 0); + if (!r) + dev->gain = gain; } - if (!r) - dev->gain = gain; - else - dev->gain = 0; - return r; } -- 2.5.0

1 0

Hackrf signed issue on gr-osmosdr for ARM
by Del Spangler 25 Nov '15

25 Nov '15

It looks like I'm not the first person to have notices this, because after I submitted a PR to the github project, I noticed another pull request dating from May that has yet to make it into master. Essentially what it boils down to is that char on arm systems, in my case the raspberry pi, are treated as unsigned characters. So right now we have a fix for the hackrf firmware update that only works on x86 systems. A simple change to the source and sink typecasting from char to explicit int8_t on the lookup table on the source.cc should fix this issue for all platforms. In addition, I believe a typecast in the convert function for the sink.cc would do it as well but I have not tested it and I don't believe my current PR reflects that either.

1 0

[PATCH] rtl_fm null squelch
by Wilson Waters 13 Nov '15

13 Nov '15

Hi all, I've created a simple little change for rtl_fm which outputs values of 0 (instead of nothing) when the output is squelched. Use the command option "-E nullsquelch" to enable. This is useful when live streaming output to icecast or similar which requires a constant stream of data (such as http://rtl-sdr.com/forum/viewtopic.php?f=7&t=141 or http://www.windytan.com/2013/07/squelch-it-out.html) Hopefully someone can merge this into the git repo, otherwise just patch and build yourself. Cheers, Wilson -- *Wilson Waters* | Software Engineer *Alintech* e: wilson.waters(a)alintech.com.au w: www.alintech.com.au

1 0

Changing Configuration Parameters Dynamically - OpenBSC
by Amber and Sarosh 04 Nov '15

04 Nov '15

Hi,Can someone inform us if the VTY configuration commands to change parameters e.g. cell id, location area code, MS power etc. that are run on OpenBSC VTY telnet interface take effect on next restart of the OpenBSC session or during the same session? If former is the case, is there any way to dynamically change Cell ID, LAC, MS TX power etc i.e. without restarting the OpenBSC session? Regards, Amber & Sarosh

1 0