Configuring which SDR to use when multiple connected to a Pi

[KiwiInNZ]

It is possible to connect multiple RTL-SDR to a single pi, so it should be possible to configure which one ionosphere uses. However in the config/config.yml there is no option to specify the serial number of the SDR to use.

Since ionosphere is using rtl_fm, this should be possible as this can take a parameter:

• [-d device_index (default: 0)]

As an example, I've two SDR:

$ rtl_test

Found 2 device(s):
  0:  Realtek, RTL2838UHIDIR, SN: 00000003
  1:  Realtek, RTL2832U, SN: 00001000

Since device 0 is the one I would like to use, whenever using rtl_fm I specify -d 0.

Could this functionality to be added to ionosphere?

[cceremuga]

Check out the additional-flags element under the rtl section of the config.yml, you should be able to add in -d 0 there and the app will pass it along to rtl_fm automatically. Can't say I've tested that aspect very thoroughly, but give it a shot and let me know!

[KiwiInNZ]

Thank you for the rapid response.

I can confirm that the use of the -d 0 is working in selecting the correct RTL-SDR.

However if I try -d 1, which will select an SDR already in use, Ionosphere exits silently with no reporting of the reason why either to the terminal window or to the log file, as below where I:

1. Edited the config file to have -d 1 (i.e. select the in use one)
2. Run Ionosphere
3. See it silently exit
4. View the log file where I only see two invalid packets (from the ISS, am still experimenting with the appropriate gain)

pi@weatherpi:~/ionosphere-raspberry-pi $ nano config/config.yml
pi@weatherpi:~/ionosphere-raspberry-pi $ ./ionosphere

   ____                        __
  /  _/__  ___  ___  ___ ___  / /  ___ _______
 _/ // _ \/ _ \/ _ \(_-</ _ \/ _ \/ -_) __/ -_)
/___/\___/_//_/\___/___/ .__/_//_/\__/_/  \__/
                      /_/

INFO[0000] Stdout handler initialized.
INFO[0000] APRS-IS handler inactive.
INFO[0000] RTL-SDR subprocess initialized.
INFO[0000] Multimon-ng subprocess initialized.
INFO[0000] Beacon inactive.
INFO[0000] Listening for packets.
pi@weatherpi:~/ionosphere-raspberry-pi $ more logs/ionosphere.log
time="2022-02-12T22:10:29+13:00" level=warning msg="aprs: invalid packet (FSK1200: fm ? to BP;?$]-5 QSO Nr 874 RR3v)"
time="2022-02-13T00:33:07+13:00" level=warning msg="aprs: invalid packet (FSK1200: fm ? to (=%:SY-9 QSO Nr 10785 I46^ pid=7D)"

Having just realised that with also having an LNA, I need to turn on the bias-tee to power it, which is done using the -T argument, e.g. the code below will turn on the bias-tee, select device zero, set the gain to 36.4, tune to 145.8MHz, set the address and port for the server to the values specified:

rtl_tcp -T -d 0 -g 36.4 -f 145.8M -a 192.168.1.4 -p 4567

So I edited the config/config.yml to include:

additional-flags: "-T -d 0"

When trying to run Ionosphere, the code exits silently, without any error messages sent to console or to the log file.

Since the unused SDR is being selected without the "-d 0", I thought I'd try to just turn on the bias-tee, so I edited the config/config.yml to include:

additional-flags: "-T"

When trying to run Ionosphere, the code works as expected (although I didn't go outside to check that the bias-tee was on as the remnants of cyclone Dovi are just passing through).

Looking at the code for "ionosphere/subprocesses/rtlsdr/rtlsdr.go", I suspect that the issue may be with lines 13-14 (note I've not used Go, but have used multiple other languages, so take what I'm suggesting as possibly being incorrect). As written it seems to be taking a pair of parameters, e.g. "-f", c.Frequency, which should result in the args including -f 123.456M (if that was what was set in the config file for the frequency.

But for the additional flags, you are trying to set multiple ones at once if multiple have been specified in the additional-flags field.

It looks to be behaving exactly like Popen in Python.

What I suspect you need to do to handle multiple flags being set in the additional-flags field is to parse out this field into the arg / value pairs (could split the string at each - (with validation, especially as not every arg needs a value), then either construct your args value dynamically (if Go lets you do that) or select one of multiple predefined combinations based on the number of separate flags in the additional-flags value.

Hope this helps improve the code.

[cceremuga]

Thanks for that, sorry for the slow replies. I'll get a second RTL-SDR hooked up to my test environment and see what I can work out.

[KiwiInNZ]

Let me know if you need anyone to beta test this.

[cceremuga]

@KiwiInNZ here's a beta build which should in theory resolve the issues with the additional args. https://github.com/cceremuga/ionosphere/releases/tag/v1.0.2beta

I admittedly didn't have a chance to hook up an additional device to test with, but was able to confirm that if I add multiple acceptable rtl_fm args to the single config line as in your original sample, it didn't crash.

Let me know if it resolves your issue!

[mathisono]

Dose the rtl driver support multi device access. last time i tried to access the second device while the first is in use. The second program errors out. Am i missing something?

…

On Sun, Nov 6, 2022, 7:32 AM Craig Ceremuga ***@***.***> wrote: @KiwiInNZ <https://github.com/KiwiInNZ> here's a beta build which should in theory resolve the issues with the additional args. https://github.com/cceremuga/ionosphere/releases/tag/v1.0.2beta I admittedly didn't have a chance to hook up an additional device to test with, but was able to confirm that if I add multiple acceptable rtl_fm args to the single config line as in your original sample, it didn't crash. Let me know if it resolves your issue! — Reply to this email directly, view it on GitHub <#18 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEW6LAHLW5PBYJDREXJJ7LWG66OJANCNFSM5OGDR73Q> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[cceremuga]

@mathisono at this time, you'd need ionosphere in two separate folders.

• in one config, the rtl additional-flags would be -d 0
• in the other ionosphere config, the rtl additional-flags would be -d 1

that said, it's almost certainly going to insta-crash unless you're running the 1.0.2 beta build

[KiwiInNZ]

I downloaded and installed from https://github.com/cceremuga/ionosphere/releases/tag/v1.0.2beta, with my config file having the line in the "rtl:" section:

additional-flags: "-d 0 -T"
Running this saw it kick off and run apparently fine (no crashes).
Running it with "-d 1 -T" saw an instant crash with no logs (would be great if logging were improved).
Will leave it running, hoping to pick up some APRS packets...

[cceremuga]

Dang, alright sorry about that. I'll actually get a second rtl-sdr hooked up to test with now, should have done it last time haha.

[cceremuga]

@KiwiInNZ Some (possibly) good news.

• Added additional stderr output from both rtl_fm, multimon-ng to more easily diagnose issues with those processes.
• After some cleanup, attached two RTL-SDR dongles and was able to get both running simultaneously.

The process which I'd recommend to try this out is as follows:

• Download the latest beta build for the platform of choice: v1.0.2beta2
• Untar it twice to two different directories i.e. ionosphere-1, ionosphere-2
• Configure ionosphere-1 to at least have the following rtl_fm flags: -d 0
• Configure ionosphere-2 to at least have the following rtl_fm flags: -d 1
• ./ionosphere-1/ionosphere
• ./ionosphere-2/ionosphere

That should (in theory) get you the desired functionality. I was able to get that working as expected with the correct behavior using two identical dongles on a single system.

Granted, my test environment is a virtual machine running Arch Linux, not a Raspberry Pi. It's entirely possible the behavior is different on a Pi, but with the new build, you should be able to capture better error output for additional troubleshooting.

[KiwiInNZ]

Doing some testing, using v1.0.2beta2:

Found 2 device(s):
  0:  Realtek, RTL2838UHIDIR, SN: 00000003 <-- SDR for ionosphere
  1:  Realtek, RTL2832U, SN: 00001000 <-- SDR for ADSB

Trying to use the wrong SDR:
additional-flags: "-d 1 -T"

	./ionosphere

	   ____                        __
	  /  _/__  ___  ___  ___ ___  / /  ___ _______
	 _/ // _ \/ _ \/ _ \(_-</ _ \/ _ \/ -_) __/ -_)
	/___/\___/_//_/\___/___/ .__/_//_/\__/_/  \__/
						  /_/

	INFO[0000] Stdout handler initialized.
	INFO[0000] APRS-IS handler inactive.
	INFO[0000] rtl_fm initialized.
	INFO[0000] multimon-ng initialized.
	INFO[0000] Beacon inactive.
	INFO[0000] Listening for packets.
	multimon-ng 1.1.7
	  (C) 1996/1997 by Tom Sailer HB9JNX/AE4WA
	  (C) 2012-2019 by Elias Oenal
	Available demodulators: POCSAG512 POCSAG1200 POCSAG2400 FLEX EAS UFSK1200 CLIPFSK FMSFSK AFSK1200 AFSK2400 AFSK2400_2 AFSK2400_3 HAPN4800 FSK9600 DTMF ZVEI1 ZVEI2 ZVEI3 DZVEI PZVEI EEA EIA CCIR MORSE_CW DUMPCSV X10 SCOPE
	Found 2 device(s):
	  0:  Realtek, RTL2838UHIDIR, SN: 00000003
	  1:  Realtek, RTL2832U, SN: 00001000

	Using device 1: Generic RTL2832U
	usb_claim_interface error -6
	Failed to open rtlsdr device #1.

Useful output to see that the wrong one was selected, which is unavilable as dump1090 is already running and using it.

Looking at the logfiles to see if there is useful info there too:

	ll logs/
	total 0
	-rw-r--r-- 1 pi pi 0 Nov 13 13:52 ionosphere.log
	-rw-r--r-- 1 pi pi 0 Nov 13 05:47 PLACEHOLDER

Nothing is being written to the logs. I'd normally want to run stuff like ionosphere as a background task, so having output go to a log file is ideal. Although it is easy enough to pipe console output to a file. From experience, I normally try to log enough to the logfile to make it as easy as possible to identify issues.

Is PLACEHOLDER meant to be there?

Trying to use the right SDR:
additional-flags: "-d 0 -T"

	./ionosphere

	   ____                        __
	  /  _/__  ___  ___  ___ ___  / /  ___ _______
	 _/ // _ \/ _ \/ _ \(_-</ _ \/ _ \/ -_) __/ -_)
	/___/\___/_//_/\___/___/ .__/_//_/\__/_/  \__/
						  /_/

	INFO[0000] Stdout handler initialized.
	INFO[0000] APRS-IS handler inactive.
	INFO[0000] rtl_fm initialized.
	INFO[0000] multimon-ng initialized.
	INFO[0000] Beacon inactive.
	INFO[0000] Listening for packets.
	multimon-ng 1.1.7
	  (C) 1996/1997 by Tom Sailer HB9JNX/AE4WA
	  (C) 2012-2019 by Elias Oenal
	Available demodulators: POCSAG512 POCSAG1200 POCSAG2400 FLEX EAS UFSK1200 CLIPFSK FMSFSK AFSK1200 AFSK2400 AFSK2400_2 AFSK2400_3 HAPN4800 FSK9600 DTMF ZVEI1 ZVEI2 ZVEI3 DZVEI PZVEI EEA EIA CCIR MORSE_CW DUMPCSV X10 SCOPE
	Found 2 device(s):
	  0:  Realtek, RTL2838UHIDIR, SN: 00000003
	  1:  Realtek, RTL2832U, SN: 00001000

	Using device 0: Generic RTL2832U OEM
	Found Rafael Micro R820T tuner
	Tuner gain set to 49.60 dB.
	activated bias-T on GPIO PIN 0
	Tuned to 144828575 Hz.
	oversampling input by: 46x.
	Oversampling output by: 1x.
	Buffer size: 8.08ms
	Exact sample rate is: 1014300.020041 Hz
	Create UDP thread
	Created UDP thread
	Main socket started! :-) Tuning enabled on UDP/6020
	Allocating 15 zero-copy buffers
	Sampling at 1014300 S/s.
	Output at 22050 Hz.
	INFO[0038] [PACKET] ZL4MDE -> APRS [Position] (-37.xxx, 174.xxxx)

Good, useful output from multimon-ng and rtl_fm.
Again, nothing being written to the log file(s).

Having validated that the "-d 0" or "-d 1" part is working as required, I've validated that the "-T" part is working to power on a Nooelec LNA.

All this was tested on a fully patched Raspberry Pi 3B.

[cceremuga]

Sweet, looks like we're on the right track, then. I'll push up another beta sometime soon that puts the additional debug info into the log file.

Right now it's piping stderr from both processes to the os stderr, I will redirect that to the log files with everything else.

Thanks again for the valuable feedback, it is very much appreciated.

[cceremuga]

@KiwiInNZ Here's a 3rd beta build which adds significantly more verbose logging to the log file including the startup sequences for rtl_fm and multimon-ng: https://github.com/cceremuga/ionosphere/releases/tag/v1.0.2beta3

So far, things are running smoothly in my local testing, but I'll let it run for a few days to make sure everything is stable.

[KiwiInNZ]

From a quick set of tests, based on the testing I did for beta2, other than I've not gone outside to validate that the -T option has turned on bias tee, everything is working exactly as expected. I like the more verbose logging going to the file.

logs/PLACEHOLDER - seems to be unused - is it needed?

Will leave it running and report back with any issues.

[cceremuga]

The placeholder is deliberate to keep the folder structure in place in binary releases. Without it, the directory isn't there when the tarball is uncompressed and leads to confusing startup errors. Just a cheap workaround I've not replaced yet.

At some point I'll look into pushing the logs into proper OS logs at which point it will go away.