multichannel improvements?

[charlie-foxtrot]

Scanning is currently achieved by putting a device in scan mode then creating a single channel with multiple frequencies. Frequencies are stepped through in order, waiting for each to go idle for a fixed period of time before moving to the next.

This approach does not leverage the possibility that multiple frequencies may be within the same bandwidth range and could be processed in parallel. The current code does check if the next frequency is in the current bandwidth to skip the re-tune, but does not process frequencies in parallel.

Take for example wanting to scan 3 frequencies between 151.0 MHz - 152.0 MHz and an additional 2 frequencies between 158.0 MHz - 159.0 MHz using a device with a 2 MHz bandwidth. The current approach would treat all 5 frequencies the same and check them in sequence. A more efficient approach would be to group the 3 channels in the 151 block and process them a the same time, then once they are all idle, re-tune and process the 2 frequencies in the 158 block at the same time, then repeat.

This could be achieved by leaving the current scan mode config as-is then putting logic in the configuration code to break down the set of frequencies to be scanned into multiple virtual channels, each channel having a calculated center frequency the covers some sub-set of the frequencies to be scanned. The scanning code would then check that all frequencies in the current virtual channel are idle, re-tune the SDR, and connect the output to the next virtual channel.

A disadvantage to doing this with the current scan mode config is there isnt a way to have different outputs per frequency, so if there are multiple active frequencies in one virtual channel they will step on each other.

Another option would be to model functionality on the multichannel mode config and create virtual devices. Under this approach virtual devices would have their own centerfreq, bandwidth, and set of channels and the scanning code would be responsible for re-tuning / connecting the physical device to the next virtual device once all the channels are idle.

Going down the real vs virtual device path, one could go so far has have multiple physical devices that are stepping through providing input to multiple virtual devices.

@szpajder let me know your thoughts and any concerns / issues with either of these approaches. If this is something worth doing I'll take a crack at it over the next few weeks.

[szpajder]

The current code does check if the next frequency is in the current bandwidth to skip the re-tune

It actually doesn't. The SDR is always retuned to a frequency which is 20 FFT bins higher than the current frequency on the freq list. I assume this is the thing that you want to improve to gain some scanning speed, correct?

Take for example wanting to scan 3 frequencies between 151.0 MHz - 152.0 MHz and an additional 2 frequencies between 158.0 MHz - 159.0 MHz using a device with a 2 MHz bandwidth. The current approach would treat all 5 frequencies the same and check them in sequence. A more efficient approach would be to group the 3 channels in the 151 block and process them a the same time, then once they are all idle, re-tune and process the 2 frequencies in the 158 block at the same time, then repeat.

Obviously this sounds fine, however the devil is in the details.

This could be achieved by leaving the current scan mode config as-is then putting logic in the configuration code to break down the set of frequencies to be scanned into multiple virtual channels, each channel having a calculated center frequency the covers some sub-set of the frequencies to be scanned. The scanning code would then check that all frequencies in the current virtual channel are idle, re-tune the SDR, and connect the output to the next virtual channel.

In order for the scanning tode to be able to find out whether all frequencies in the current virtual channel are idle, there has to be a code which actually computes noise levels and signal levels for each frequency in the virtual channel. So first we need to rethink what a channel actually is. Right now it is a fixed spot in the spectrum (ie. a specific FFT bin) from where a single audio stream is produced and routed to a set of outputs. What it should be is a set of bins rather than a single bin.

A disadvantage to doing this with the current scan mode config is there isnt a way to have different outputs per frequency, so if there are multiple active frequencies in one virtual channel they will step on each other.

But you don't want different outputs per frequency, you want a single output for everything. It's a scanner, after all. Many frequencies (at most one at a time) -> common output.

So the given set of bins shall result in a single stream containing audio from at most one active bin - let's say there would be a loop over a set of bins and the first one that has_signal() would put samples into waveout, while all the other bins wouldn't. There would be an extra step needed in case when all bins are idle - waveout would then be be filled with zeros (however I wonder how we would handle fade-ins and fade-outs in this case...)

Obviously the bin set for every stepped centerfreq would be different, so the scanner controller thread would need to switch both centerfreq and bin set for the channel, so that the demodulating thread would pick the signal from correct bins.

Another option would be to model functionality on the multichannel mode config and create virtual devices. Under this approach virtual devices would have their own centerfreq, bandwidth, and set of channels and the scanning code would be responsible for re-tuning / connecting the physical device to the next virtual device once all the channels are idle.

I see some pitfalls in this approach. Would virtual devices be handled by the demodulate thread in the same way as real ones (ie in the same loop)? If yes, then extra care would be needed in case when multithreaded demodulation is enabled - all the virtual devices associated with a common real device would need to be handled by a common thread. Another issue is that the demodulation thread couldn't simply iterate over the whole set of virtual devices and do its work on each of them. It would need to pick the exact one that corresponds to the centerfreq to which the SDR is currently tuned. And what's more, all channels from all virtual devices would need to produce audio to a common output - an approach which is completely opposite to the current design, where every channel has its own set of outputs that are not shared between channels (unless they happen to be mixers). All in all, this approach looks excessively complicated.

[charlie-foxtrot]

I think I made some assumptions on why someone would use scan mode that may not be accurate . . . . let me take a step back.

I have a single SDR with a 2.4 MHz bandwidth and I want to monitor a total of 5 frequencies, 3 frequencies between 151.0 MHz - 152.0 MHz and 2 frequencies between 158.0 MHz - 159.0 MHz. Today I can achieve this using scan mode, and although this works, it does not maximize the amount of audio I'm able to capture.

In my situation two of the frequencies in the lower band are often active at the same time, and while scan mode is able to pick up one of them, the second is lost despite the bandwidth being sufficient to have picked up both.

So my problem statement is this: "How can I maximize the amount of captured audio across multiple frequencies when those frequencies span more than a single device's bandwidth?"

Based on the comments above it sounds like scan mode as it is today should not be changed, so lets ignore I mentioned that ;)

What I am proposing then is some new mode where one can define multiple channels with frequencies that can span more than a device's bandwidth. This new mode would behave as follows:

• If all the frequencies are within a device's bandwidth this will behave as multichannel does today
• If all the frequencies are spaced more than a device's bandwidth apart this will behave the same as scan does today except each channel goes to its own output(s)
• If some set of frequencies are within a device's bandwidth than those channels will be demodulated at the same time using the same samples from the same device

To accomplish this I was thinking at configuration time to step through all the channel frequencies and find some minimal set of groupings such that each channel is in one and only one group, and all frequencies in that group are within bandwidth of each other. Each channel grouping could then be called a "virtual device" that has its own fixed centerfreq. This centerfreq would then be used for the FFT bin calculation for the channels in this device as is done today.

Going back to my example I would end up with one device with a bandwidth of 2.4 MHz, then two virtual devices, both with a bandwidth of 2.4 MHz, one with a centerfreq of ~151.5 MHz and three channels, the other with a centerfreq of ~158.5 MHz and two channels.

With this (hopefully better) description I'll try to address the points / concerns:

I see some pitfalls in this approach. Would virtual devices be handled by the demodulate thread in the same way as real ones (ie in the same loop)?

Yes. Virtual devices would be included in devices[] and simply have no samples unless they are connected to a real device at the time. The demodulate() thread already checks for available samples before processing, so virtual devices would end up sleeping more than other devices.

If yes, then extra care would be needed in case when multithreaded demodulation is enabled - all the virtual devices associated with a common real device would need to be handled by a common thread.

Fair. I don't see this as a hard requirement, but would make it easier to coordinate when to switch a physical device to the next virtual device.

Another issue is that the demodulation thread couldn't simply iterate over the whole set of virtual devices and do its work on each of them. It would need to pick the exact one that corresponds to the centerfreq to which the SDR is currently tuned.

I was actually thinking of moving that business logic up. Similar to how the re-tuning happens in scan mode, there would be some logic that is responsible for managing the the physical device and corresponding virtual device(s). This would be responsible for tracking the one (and only one) virtual device that is currently receiving output from the physical device, re-tuning the physical device to the center frequency of the next virtual device, and throwing away some number of samples after the re-tune.

Under this approach the demodulate thread doesn't really need to know anything about if a device is physical or virtual, it just operates on devices that have samples available and skips devices that do not.

And what's more, all channels from all virtual devices would need to produce audio to a common output - an approach which is completely opposite to the current design, where every channel has its own set of outputs that are not shared between channels (unless they happen to be mixers).

This is not my intent / desire, and I think is confused by me calling it a scanner mode 😄. I actually want each channel to have its own outputs.

[szpajder]

OK, it makes sense now. And indeed it's quite different to the current scan mode, which should stay as it is, because it addresses another valid use case - aggregating audio from several low-traffic channels that do not deserve their separate audio streams.

The mode that you are describing is in fact a generalization of the multichannel mode and can be implemented as such. If the device is configured to work in multichannel mode and:

• channel frequencies fit in the SDR bandwidth - it's just standard multichannel mode, so the controller thread may just not be started at all or may terminate (like it currently does when doing scan mode with one frequency).
• channel frequencies do not fit in the SDR bandwidth and centerfreq has not been specified - frequency hopping is activated and center frequencies are computed automatically[1]. Output a warning that frequency hopping is enabled due to too large channel frequency span which may cause some transmissions to be missed.
• channel frequencies do not fit in the SDR bandwidth and centerfreq has been specified - enable standard multichannel mode, set the receiver to the configured centerfreq and output a warning that one or more channels are out of band and won't work.

[1] I'm not sure if having full automation here is a good idea. It would be convenient and would probably work correctly most of the time, but could also fail miserably in corner cases. For example, if a particular channel group is clustered around 151.5 MHz and there is a strong blocker at, let's say, 152.5 MHz, I would prefer to manually tune the radio as low as possible to dodge it - for example, to 150.5 rather than 151.5. But dismissing such problems with "buy more dongles" explanation is also a valid solution :-)

Under this approach the demodulate thread doesn't really need to know anything about if a device is physical or virtual, it just operates on devices that have samples available and skips devices that do not.

OK, sounds good.

[charlie-foxtrot]

OK, cool, I'll find some time in the next few weeks to work on it.

I like the idea of not calling it a new mode, rather logic that is triggered if centerfreq is not set. In fact, I could support automatic calculation of virtual channel center frequencies if centerfreq is not set as well as manual setting of virtual channel center frequencies if centerfreq is set to a list.

[charlie-foxtrot]

(also changed the title of this thread from "scan improvements" to "multichannel improvements")