Hi,
I appreciate very much to receive your comments on the distinctions between
steve-m/libsrtlsdr and keenerd/rtl-sdr (forked from pinkavaj/rtl-sdr 129
commit ago and maintained).
Both have very similar structure, flies, purpose but the software is not
exactly same. There are something attractive for me in one of them while the
other one is also good.
İs it possible to create patch from one of them and apply to the other to
merge two repos together?? Why I am asking is, rtl-sdr has a new agc -
aggressive agc option which is useful for me but I prefer to stay on
librtlsdr; is there a solution?
Thanks in advance,
Murat.
I’ve been playing with a python application to scan, find and record strong signals.
I attached the code with the hope that someone would like to improve it … maybe
put it on sourceforge or github. I will not have time to do anything about it for a few
weeks.
Works at least with linux … haven’t tried OSX or win.
Needs: numpy, scipy, matplotlib, npyscreen (https://pypi.python.org/pypi/npyscreen/),
pyrtlsdr (https://github.com/roger-/pyrtlsdr/releases [use the old release, new code python 3 only])
start with:
python peekSDR.py -d (in one window to start database)
python peekSDR.py -vr (in one window to start radio scanning)
python peekSDR.py -g (in one window to start user interface)
[can be run on different computers as long as you have the same filesystem and stand in the same directory]
in the user interface “f” plots ffts of recorded signals. “1” starts gqrx with the recorded signal.
Best wishes - Magnus
Oops, forgot to CC the mailing list.
On 09/21/2015 12:47 PM, Nikolay Dimitrov wrote:
> Hi Dimitri,
>
> On 07/04/2015 03:42 PM, Nikolay Dimitrov wrote:
>> Add scanner progress, including signal and squelch levels.
>> Rename demod_state->conseq_squelch to demod_state->squelch_conseq.
>>
>> The scanner progress feature can be tested like this:
>>
>> ./rtl_fm -f 144.000M:146.000M:25k -M fm -s 48k -l 100 -t 5 | aplay \
>> -r 48k -f S16_LE -t raw -c 1
>>
>> Signed-off-by: Nikolay Dimitrov <picmaster(a)mail.bg>
>> ---
>> src/rtl_fm.c | 43 +++++++++++++++++++++++++++++--------------
>> 1 file changed, 29 insertions(+), 14 deletions(-)
>
> Can you please take a look at this patch and decide whether it's worthy
> of applying to the rtl-sdr tree?
>
> Thanks in advance. Regards,
> Nikolay
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
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.
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
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á
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
