Appunti su DSD con GQRX e RTL-FM in Linux

Sistemando il Thinkpad con Ubuntu Linux, dopo la prematura dipartita del Chromebook.

DSD, il software originale per la decodifica del DMR, ha bisogno di audio campionato a 48000 Hz. Su alcuni pc / schede audio che lavorano a 44100 l'esecuzione fallisce con questo messaggio:

Error message: Invalid sample rate

Il problema si può aggirare utilizzando padsp, un wrapper pensato per mantenere compatibilità con i device audio legacy di Linux che si occupa anche del necessario resampling.

>padsp dsd
Digital Speech Decoder 1.7.0-dev (build:v1.6.0-86-g7ee04e5)
mbelib version 1.3.0
Audio In/Out Device: /dev/audio

La tecnica funziona anche quando vogliamo alimentare DSD direttamente da GQRX o RTL_FM per l'impiego con la nostra SDR preferita.
Esempi:

=== con GQRX, dopo aver attivato lo stream UDP ===

socat stdout udp-listen:7355 | padsp dsd -i -

=== RTL-FM ===

rtl_fm -f 145.125M -M fm -g 100 -s 70K -r 48K -E dc| padsp dsd -fr -i –

Bonus track: quando non esiste il device /dev/audio e/o il sample rate non è compatibile, anche il flag -n per disattivare l'output sugli altoparlanti non viene riconosciuto, anche se la scheda audio non verrebbe impiegata in alcun modo.

>socat stdout udp-listen:7355 | dsd -i - -n
Digital Speech Decoder 1.7.0-dev (build:v1.6.0-86-g7ee04e5)
mbelib version 1.3.0
Disabling audio output to soundcard.
Error, couldn't open /dev/audio
2018/07/27 08:45:23 socat[3592] E read(1, 0x55ba6bcafbc0, 8192): Bad file descriptor

Per ovviare al problema basta, nello stile Unix, usare come output il device NULL:

socat stdout udp-listen:7355 | dsd -i - -o /dev/null

GenComm GC7105b Base Station Analyzer

Here's the new toy in the shack.

Less than 10 years ago (mine has a 2010 board revision) these instruments retailed for over $50k but these days you can get some nice reconditioned units for around $1k from Korea, where they are probably phased out in favour of new 5G capable tools.

And yet they can be extremely useful in the lab of a radio hacker.

Features packed in my unit, excluding all the mobile phone protocol analyzers:

• 100 kHz - 4 GHz spectrum analyzer
• 25 MHz - 4 GHz single port VNA
• 10 MHz - 4 GHz power meter
• "interference analyzer" software, allowing to signals in waterfall and map levels to GPS positions

The Signal Path has an episode on a conceptually similar Agilent instrument.

Other units worth considering were sold under the JDSU and VIAVI brands.

Maybe I'm wrong, but it appears that all units were created with the same hardware and the different functions are enable just by adding the proper software keycode. I enquired around to see if I could get a license to enable bias-T and 2 ports VNA measurements on my units but with no luck.

JDViewer software works when connected via USB. No luck with the others or via LAN.

Related thinkering: probing the instrument via LAN revealed it runs a 2.6 Linux o.s. and there's TELNET and FTP ports open. Unfortunately I didn't manage to brute force into them.

Yet the discovery opens up the possibility of backing up the disk and have a deeper inspection offline.

Cracking it open revealed that o.s. is stored on a 2Gb SD-card: making a backup (dd utility under Linux) is a good idea anyway, being one of the most likely points of failure. Pulling it out requires taking away a large number of screws from the control board and the SMA nuts on the outside. You don't need to take it off completely: just slide it enough to have clearance for the SD to come off.

Hopefully it'll still work this evening when I close it back.

O.s. image alone might not be enough for a restore, in case there's a link to the card serial number, but there may be ways around that.

Moreover, the following can be investigated:

• getting out the passwords, that may be the reason software doesn't work via LAN
• understanding the licensing mechanism