Automating testing on different SDRs and Platforms

[robotastic]

Thanks to people sponsoring the project, I have funding to put help grow things. I was going to purchase some additional SDRs and setup automated testing. I have an RTL-SDR, HackRF, a Ettus B200 and a LimeSDR. What other SDRs are being widely used that I should be testing releases against?

For platforms, I was planning on testing against on Ubuntu 20.04 & 18.04 (using containers) and Raspberry Pi 3 & 4 (probably 32 & 64 bit). I will also test against MacOS using MacPorts.

I could test against a local SmartNet and P25 Phase 1 & 2 systems. If people send in some IQ captures, I could also test against those.

I will have to do some research on different testing frameworks to help with this. The big things I am initially looking to capture are if it compiles correctly and doesn't crash. From there we can look to see if it is correctly capturing audio using different SDRs. If IQ files are used, we can test to see if the expected .wav files are created and they are about the correct side.

[photounit]

How about BladeRF and SDRPlay? For streaming a digital trunked system a simple 8-bit dongle will work fine. But for me, I stream ~58 analog channels of various signal strengths and I need the dynamic range of a 12bit ADC as well as expanded bandwidth. I will be making a donation to help the cause....

[robotastic]

@photounit - cool, I was thinking of adding a BladeRF. Have you tried an AirSpy? I was thinking of getting that or the SDRPlay, or maybe both. Good point on the analog recording. I don't think there is too much analog near me, but I can always record the weather broadcasts.

[photounit]

@robotastic Luke, I have/ am using the AirSpy's particularly the mini's because I can do 3 Mhz sampling. The major problem with them is that the gain settings don't work as they do in SDR#. If you could straighten that out it would be great! As far as the BladerRF goes, I have the BladeRF 2.0 micro xA4 and it's a pain getting everything to work as far as installing the BladeRF libraries and then Soapy BladeRF. Once you do get things installed it's the same issue with getting things working in TR because the gain settings in BaldeRf have changed from what they were and no longer work. I have given up on the Blade for know...

[Dygear]

I think AirSpy would be a good addition. I've heard many good things about these devices. I might end up picking up one myself.

[shodan007]

Seems to be working with BladeRF xA4 despite compiling without MPIR. Had an issue with the autogain setting so removed
it from config and manually set the gain. Tried installing MPIR in /usr/ and /usr/local/ but still not found by cmake

uname -a
Linux shinobi 5.4.0-56-generic #62-Ubuntu SMP Mon Nov 23 19:20:19 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

lsb_release -a

Distributor ID: Ubuntu
Description: Ubuntu 20.04.1 LTS
Release: 20.04
Codename: focal

cmake ../

-- Build type not specified: defaulting to release.
-- Found CPPUNIT: /usr/lib/x86_64-linux-gnu/libcppunit.so;dl
-- Checking for module 'mpir >= 3.0'
-- No package 'mpir' found
-- Could NOT find MPIR (missing: MPIRXX_LIBRARY MPIR_INCLUDE_DIR)
-- Found Boost: /usr/lib/x86_64-linux-gnu/cmake/Boost-1.71.0/BoostConfig.cmake (found suitable version "1.71.0", minimum required is "1.71.0") found components: date_time program_options filesystem system regex thread unit_test_framework
CMake Warning (dev) at /usr/lib/x86_64-linux-gnu/cmake/gnuradio/GnuradioConfig.cmake:48 (if):
if given arguments:

"ON"

An argument named "ON" appears in a conditional statement. Policy CMP0012
is not set: if() recognizes numbers and boolean constants. Run "cmake
--help-policy CMP0012" for policy details. Use the cmake_policy command to
set the policy and suppress this warning.
Call Stack (most recent call first):
CMakeLists.txt:85 (find_package)
This warning is for project developers. Use -Wno-dev to suppress it.

CMake Warning (dev) in /usr/lib/x86_64-linux-gnu/cmake/gnuradio/GnuradioConfig.cmake:
Policy CMP0011 is not set: Included scripts do automatic cmake_policy PUSH
and POP. Run "cmake --help-policy CMP0011" for policy details. Use the
cmake_policy command to set the policy and suppress this warning.

The included script

/usr/lib/x86_64-linux-gnu/cmake/gnuradio/GnuradioConfig.cmake

affects policy settings. CMake is implying the NO_POLICY_SCOPE option for
compatibility, so the effects are applied to the including context.
Call Stack (most recent call first):
CMakeLists.txt:85 (find_package)
This warning is for project developers. Use -Wno-dev to suppress it.

-- Found CPPUNIT: /usr/lib/x86_64-linux-gnu/libcppunit.so;dl;dl
-- GnuRadio Version: 198657
-- Found gnuradio-uhd: /usr/include, /usr/lib/x86_64-linux-gnu/libgnuradio-uhd.so
-- Pkg: , ,
-- Vars: /usr/include, /usr/lib/x86_64-linux-gnu/libgnuradio-osmosdr.so
-- Configuring Boost C++ Libraries...
-- Found Boost: /usr/lib/x86_64-linux-gnu/cmake/Boost-1.71.0/BoostConfig.cmake (found version "1.71.0") found components: thread system program_options filesystem log_setup log regex random
-- All libraries:
-- Configuring done
-- Generating done
-- Build files have been written to: /home/shinobi/tr/build

cat config.json

{
"ver": 2,
"sources": [{
"center": "856000000",
"rate": "12500000",
"ppm": "0",
"gain": "71",
"digitalRecorders": "20",
"analogRecorders": "20",
"modulation": "qpsk",
"driver": "osmosdr",
"device": "bladerf=0"
}],
"systems": [{
"control_channels": [858112500,858362500,858612500],
"type": "p25",
"talkgroupsFile": "COS.csv",
"shortName": "COS",
"callLog": "true",
"recordUnknown": "true"

}],

"captureDir": "/home/shinobi/trunkrecorder/audio_files",
"defaultMode": "digital",
"callTimeout": "3",
"logFile": "1",
"frequencyFormat": "mhz"

[jodfie]

what about a NooElec Nano 3?

[jodfie]

@robotastic have you also made any progress on 32bit RasPi 4?

[rpdale]

I’m running a variety of RTLs on 4 different 32-bit RPI4 systems feeding the Calls platform using the existing full install.

[jodfie]

I’m running a variety of RTLs on 4 different 32-bit RPI4 systems feeding the Calls platform using the existing full install.

@rpdale could I send you a PM? it's not letting me via docker I get the same error as #410

[rpdale]

Oh - sorry, no Docker for RPI is still broken. I gave up on that :) Compiling from scratch only takes about 15 minutes anyways on the 4's.

[jodfie]

Oh - sorry, no Docker for RPI is still broken. I gave up on that :) Compiling from scratch only takes about 15 minutes anyways on the 4's.

@rpdale I’ll do that then. Any problems with updating?

_{Sent with GitHawk}

[Dygear]

I've never used Docker and I wrote the documentation on compiling from source for the Raspberry Pi on the Wiki. I've never had any of the issues that have been described by those using Docker on the Raspberry Pi (32bit or 64bit). While it might be quicker in some cases, the compile from source route always works.

[robbiet480]

Working on getting Docker working on 32-bit armv7 OSes in #445