Hello,
When I use heatmap.py with output from rtl_power I get regularly spaced
vertical lines that do not appear to be related to any signal. They
look they like repeat at the dongle bandwidth (2048000Hz in this case).
The crop option for rtl_power reduces the presence but I am not sure f
that is intended by that option. Even at -c of 70% they are still there
(see attachment).
Is this because of small bin width? If I use a larger bin (32k) they
are still there. In this case there is no frequency legend along top so
can't compare if they happen more often.
Are these lines to be expected?
John
Hi there,
In debian, sdrangelove is having some build issues on mipsel [0].
At first, there was an issue regarding the '-msse2' switch.
If I delete the switch, then another build error happens:
======== 8< ========
[...]
[ 21%] Building CXX object CMakeFiles/sdrbase.dir/sdrbase/dsp/interpolator.cpp.o
/usr/bin/c++ -DQT_CORE_LIB -DQT_GUI_LIB -DQT_MULTIMEDIA_LIB
-DQT_NETWORK_LIB -DQT_NO_DEBUG -DQT_OPENGL_LIB -DQT_WIDGETS_LIB
-DUSE_FFTW -Dsdrangelove_EXPORTS -g -O2 -fstack-protector-strong
-Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -O3 -DNDEBUG
-fPIC -isystem /usr/include/mipsel-linux-gnu/qt5 -isystem
/usr/include/mipsel-linux-gnu/qt5/QtCore -isystem
/usr/lib/mipsel-linux-gnu/qt5/mkspecs/linux-g++ -isystem
/usr/include/mipsel-linux-gnu/qt5/QtWidgets -isystem
/usr/include/mipsel-linux-gnu/qt5/QtGui -isystem
/usr/include/mipsel-linux-gnu/qt5/QtOpenGL -isystem
/usr/include/mipsel-linux-gnu/qt5/QtMultimedia -isystem
/usr/include/mipsel-linux-gnu/qt5/QtNetwork
-I/tmp/buildd/sdrangelove-0.0.1.20140824/obj-mipsel-linux-gnu
-I/tmp/buildd/sdrangelove-0.0.1.20140824/include
-I/tmp/buildd/sdrangelove-0.0.1.20140824/include-gpl -fPIC -o
CMakeFiles/sdrbase.dir/sdrbase/dsp/interpolator.cpp.o -c
/tmp/buildd/sdrangelove-0.0.1.20140824/sdrbase/dsp/interpolator.cpp
In file included from
/tmp/buildd/sdrangelove-0.0.1.20140824/sdrbase/dsp/interpolator.cpp:4:0:
/tmp/buildd/sdrangelove-0.0.1.20140824/include-gpl/dsp/interpolator.h:4:23:
fatal error: immintrin.h: No such file or directory
#include <immintrin.h>
^
compilation terminated.
[...]
======== 8< ========
Do you have any hint for this?
Thanks, best regards.
PS: Please keep me in CC, i'm not subscribed.
[0] https://buildd.debian.org/status/fetch.php?pkg=sdrangelove&arch=mipsel&ver=…
--
Arturo Borrero González
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.
This patch implements zero-copy overhead for buffers used for sample
transfer. This improves a bit performance for applications where low
overhead is required and can save a bit of memory.
Two changes are made:
* add return value for callback function
* add function for buffer release when it is free for reuse
This change breaks ABI (callback returns int instead of void), but I
cannot find way not to do so. Proper change of library version in
CMaleList.txt would be required.
Please comment on it and let my now if it is interesting enough to be
merged upstream.
JP
Checking if variable is not NULL before calling free() is not effective,
because free() already does this.
- waste instruction and/or compiler time
- more lines of code than necessary
This patch removes those checks.
Hey list,
I recently put together SoapyRemote, which is a plugin and server app
for SoapySDR that lets any supported hardware operate as a network
device over a local link: https://github.com/pothosware/SoapyRemote/wiki
GrOsmoSDR users should be able to use the Osmo source and sink blocks to
work transparently with a remote device. Just make sure that GrOsmoSDR
was configured with the support for SoapySDR. I have documented how the
device args should be set to use a remote device:
https://github.com/pothosware/SoapyRemote/wiki#grosmosdr-remote-devices
Extra note: Everything works better with large socket buffers. On linux,
users will want to run the sysctl commands here:
https://github.com/pothosware/SoapyRemote/wiki#remote-window
I had a lot of fun making SoapyRemote, and we have already seen that
working with embedded devices has been a big use case. I hope that
GrOsmoSDR users will find utility with SoapyRemote as well.
Thanks, and happy hacking!
-josh
Hello Dimitri,
I've put together two simple gr-osmosdr blocks for the Red Pitaya SDR
transceiver. They are based on the file block with some pieces borrowed
from the rtl_tcp block. Would it be possible to add these blocks to the
gr-osmosdr code repository?
The patch is in the attachment.
Some information about the Red Pitaya SDR transceiver can be found at:
http://pavel-demin.github.io/red-pitaya-notes/sdr-transceiver
Best regards,
Pavel
