Some suggestions

[jayant4001]

1. Is it feasible to add a udp input method as well, by implementing a virtual device of some kind which takes a network input instead of a tuner input? I'm wondering if that would work to combine 2 instances of rtl_airband.

2. The new squelch_snr_threshold option works very well for channels where lowering the SNR threshold slightly is useful to catch a weak station. Can this also be implemented as a global option affecting all channels? My intension is to use this to lower the default 9.5 dB value used to open the squelch - not sure if it will do what I'm visualising.

[charlie-foxtrot]

1. Is it feasible to add a udp input method as well, by implementing a virtual device of some kind which takes a network input instead of a tuner input? I'm wondering if that would work to combine 2 instances of rtl_airband.

Not sure I follow. Is the ask to have an input device that is coming from something like rtl_tcp running on a remote machine? So the raw I/Q samples are coming over the network instead of from a local USB device?

2. The new squelch_snr_threshold option works very well for channels where lowering the SNR threshold slightly is useful to catch a weak station. Can this also be implemented as a global option affecting all channels? My intension is to use this to lower the default 9.5dB value used to open the squelch - not sure if it will do what I'm visualizing.

The thinking was that if someone wanted to play around with tweaking the SNR threshold that would need to be done on a per-channel basis, so it was more important to configure per-channel than globally. There is nothing stopping a global config being added, but setting the value per-channel will get you the same result.

[jayant4001]

Thanks @charlie-foxtrot. The ask was to see if it is feasible to use the uncompressed UTP output to feed a corresponding input on another Pi and combine the streams, possibly in a mixer. See the use-case In my other response. I'm not at all sure if the coding effort would be worth it, or even if a completely different signal mixer application would be easier to do, it's just an idea I had. I'm also not sure of the two (or more) sources would be time-aligned, so traffic from the same channel received on 2 different Pis would stay in sync. MP3 probably wouldn't, uncompressed audio might.

[charlie-foxtrot]

What may work better is to put a receiver on each antenna, run rtl_airband with split_on_transmission = true, then use some post-processing script to pick the "best" audio in cases when a transmission is picked up by multiple receivers

[szpajder]

1. Is it feasible to add a udp input method as well, by implementing a virtual device of some kind which takes a network input instead of a tuner input? I'm wondering if that would work to combine 2 instances of rtl_airband.

Can you please describe your use case in detail? Please convince us that this feature might be useful to more than one person and that it's absolutely impossible to achieve this goal in any other way.

2)The new squelch_snr_threshold option works very well for channels where lowering the SNR threshold slightly is useful to catch a weak station. Can this also be implemented as a global option affecting all channels?

Not necessary. Copy&paste feature in your text editor will do the job equally well.

[jayant4001]

Thanks for the response, Tomasz. My use case is a location in a condo where roof access is not permitted to install an antenna, so VHF reception is only possible in one direction with the antenna outside a window. The building structure blocks the other directions. Not sure if others have a similar situation.

The solution I figured was to use multiple antennas on 3 sides of an apartment. This was implemented in RF by combining the antenna signals using a splitter in reverse, and then again splitting the combined RF signal into multiple tuners, but this causes a mess with impedance and signal loss. I was thinking it may be better to put a receiver on each antenna and them route the signals to a master Pi, though this would be an expensive solution if multiple dongles were needed on each Pi. There may be other ways to combine multiple uncompressed audios from each channel into master streams, but I can't think of one offhand.

One the second one, I agree a copy-paste in each channel works fine and allows more flexibility with individually setting the threshold for each channel.