Feature request: listen to two or more frequencies/receivers simultaneously (Android app)

[Gesiima]

Hi, and thanks for VibeSDR – it works great with my setup!

Setup:

• Raspberry Pi with two RTL-SDR dongles
• Connecting via the Android app

Feature request:
I'd love to be able to listen to two or more connections/frequencies at the same time, e.g. one audio stream per dongle, or multiple connections to different receivers running in parallel.

Use case:
Monitoring two frequencies at once (e.g. a calling frequency and a second channel) without having to switch back and forth.

Happy to test any builds and provide feedback. Thanks!

[Stuey3D]

I’ll have a think about how I can make something like that work whilst still maintaining ease of use.

2 frequencies in the same sample rate window should be easy, but 2 dongles together might be harder, I’d have to come up with some sort of tabbing interface.

I’m not ruling it out, but I need to think about how it will work.

[Stuey3D]

The other thing is working out how to handle performance, right now VibeSDR and VibeServer is heavily optimised to run on super low end hardware, so I want to preserve that too.

[Stuey3D]

Right in the first instance I have just designed a simple A/B VFO system which will allow you to listen to 2 frequencies at once. It will also work in stereo by default and can be switched back to mono in the audio menu, Lower Frequency VFO will be left ear, higher frequency will be right ear so the VFO position on the screen always matches what you are hearing.

Multiple radios together will need a bit of extra design work to make sure it is easy to use and performs well.

[Stuey3D]

It’s very early in testing but 2 VFO’s on the same radio is working with the stereo also putting one in the left and the other in the right ear.

[Gesiima]

Just wanted to say: the A/B VFO switching works really great! 🙌 Switching between
the two frequencies feels quick and natural.

And the stereo idea (lower frequency on the left ear, higher on the right) is
brilliant. It makes it so easy to tell which of the two frequencies is active, and
I can follow both at the same time without looking at the screen.

Thanks a lot for the great work! 🙏

[Gesiima]

A thought that came to mind, I haven't been able to test two servers yet: if I use
A/B VFOs on both servers, I'd have four channels but only two ears. 🙂 What if the
left/right assignment followed the same logic as the A/B VFOs: the server (or VFO)
with the lower frequency range goes to the left ear, the other one to the right? That
way the position always matches what's on screen. Just an idea, I'm sure you'll find
a good solution, and I'm happy to test whichever way you choose!

[Stuey3D]

There will only be 2 channels at a time, either A/B on one server or Server 1 and Server 2, otherwise this gets far too complex for a little touchscreen to navigate let alone a game controller or TV remote.

If you've not tried it yet, on the web client (the Android app you have doesn't have it yet) pair up a games controller and you can use it to operate the web client including a full onscreen keyboard too.

[Gesiima]

Quick question about the two-server listening: my setup is one VibeServer instance on
a Raspberry Pi with two RTL-SDR dongles (two radios on the same server). Will
"Listen to a 2nd server" also work for two radios on the same VibeServer, or is that
something that could be added later? Happy to test whenever it makes sense. 😊

[Stuey3D]

Yup they are treated as separate instances.

[Stuey3D]

Way ahead of you 🤣

And yes for linux simply go into the admin page and next to the updates there is an opt into beta updates and you will see V12 in there with ADSB, ISM, Full Band Digital Spots including JTTY, Background decoding and all sorts of other goodies.

The new features will only work on the webclient for now the main app will get an update when it is ready.

[Stuey3D]

Currently the button to trigger the A/B VFO's is in the wrong spot its in the step rate menu, it is being moved to the frequency input menu where it makes most sense for it as I type this so depending on when you update will depend on where the button is located for you.

[Gesiima]

Update to the beta went smoothly, and two VFOs at the same time work great. Thanks! 🙏

An idea for the multi-SDR case: it would be nice to place the second SDR's waterfall
next to the first one, so both waterfalls are visible side by side in a single view.
The two VFOs could then be placed freely on either waterfall.

One observation: when "VFO centre locked" is enabled, the SDR's centre frequency
seems to be set to exactly the listening frequency (at least that's how it looks to me).
From OpenWebRX I'm used to keeping the centre frequency slightly offset from the
signal, because RTL-SDR dongles can have a DC spike at the centre of the spectrum
that may disturb reception right on it. Tuning slightly off-centre avoids that.

Would it be possible to add an optional offset for the locked centre mode (or to
suppress the DC spike), or is this already handled internally?

[Stuey3D]

Thats the beauty of VibeSDR offset tuning is the default and you never know it. There is a 15KHz offset already baked in so you avoid the DC spike.

[Gesiima]

Thanks, that makes sense for the default mode. But when I set VFO Centre to FREE, the 15 kHz offset doesn’t seem to be applied: the frequency I tune stays at the centre of the spectrum, so I get the DC spike there. Is that expected in FREE mode?

[Stuey3D]

In FREE mode the RF centre stays where it was and only moves when it has to, so the VFO can roam the whole capture. The 15 kHz offset is between the RF centre and the tuner, so on a USB RTL dongle the DC spike sits 15 kHz from the centre and the VFO only lands on it if you tune right onto it. Which radio and connection are you using? If it's rtl_tcp, the offset isn't applied there at the moment, which would explain the spike at the centre. I'll look at that.

[Gesiima]

Thanks for the explanation, that clears it up! 👍 I've never seen the DC spike on my
setup, so the offset is clearly doing its job.

Just out of curiosity: as you can see in the screenshot, "RF CENTRE" and "LISTEN" show
the same value (94.300M), so the 15 kHz offset isn't visible in the UI. I just wanted
to understand what's really going on technically. Is the offset described somewhere
(docs, admin page), or would it make sense to show the actual tuner frequency
somewhere, e.g. in a tooltip? Just an idea, no rush!

Thanks again for the quick help! 🙏

[Stuey3D]

The offset is invisible it was just something that has always been there, there is also one for HackRF too. If you are on beta 24 there seems to be a bug where the RF centre is following the VFO which is being rectified now. I believe its because after our earlier conversation I came up with a way that would mean you'd never hit the DC spike at all.

Basically you enable free mode the RF centre stays put the VFO moves but when you get close to the DC spike the RF centre simply moves slightly so you dont land on it, but that appears to have gone wrong at the moment so looking into it now.

[Stuey3D]

Also I'd rather not do 2 waterfalls together on the same screen as that will get real cramped real fast, the iPhone SE is already extremely cramped. I may do something with the server chip and put a quick switch there or something almost like switching between 2 open servers on the web client with 2 tabs open.

[Stuey3D]

Yes it should do as it will simply treat both servers as backgrounded.

[Gesiima]

That sounds perfect, exactly what I was hoping for. 🙏 Left ear for server 1 and right
ear for server 2 is a great idea, and the pop-out card is a nice way to keep it compact.
It fits my use case well, since I listen in the background with the screen off. I'm
curious whether the audio of server 1 keeps running with the screen off while I'm on
server 2, but I'm happy to find out when I test it in the V12 beta. Thanks a lot!

One small thing I noticed in the beta: whenever the RF centre moves (e.g. when I shift
the frequency in LOCKED mode), the waterfall gets torn apart. The vertical signal trails
are skewed diagonally, because the old lines stay where they were while the new lines
use the new centre. When the centre stays put (e.g. I just click to set VFO A or B),
the waterfall is fine.

Would it be possible to shift the existing waterfall lines along with the centre
frequency, so the history stays aligned with the frequency scale? If that's complicated
or doesn't fit the design, no problem at all, I'm perfectly fine with it as it is. I
just wanted to share what I noticed. 😊

Thanks again for the great work, and I'm happy to test anything you'd like me to try!

[Stuey3D]

The waterfall did use to work that way, so I will look into it.

[Gesiima]

One more question about the waterfall, in case it's feasible:

1. Is it possible to slow the waterfall down, i.e. a lower scroll speed? A slower speed
   would make it easier for me to follow short transmissions and see where exactly I'm
   tuned.
2. When I zoom (and, if possible, also when I pan the view), the existing waterfall
   history doesn't move with it. It would be great if the old lines stayed aligned with
   the frequency scale, so the history remains usable after zooming or panning. This
   is similar to the point about the centre frequency moving.

If either is complicated or doesn't fit the design, no problem at all, I'm perfectly
fine with it as it is. Just sharing what I noticed. Thanks again for the great work! 🙏

[Stuey3D]

So the history thing is a bug and being repaired as we speak, to slow the waterfall down look in the display settings. Sharp drops it back to the incoming data rate, default smooths it to either 15 FPS (for 5 FPS low end servers) or 30FPS and smooth boosts it to either 30FPS (5fps servers) or 60

[Stuey3D]

See the zooming in and out pulls the signals to you centre point with the history, that is how it always worked previously, recent work with the IF filter being zoom based broke it.

[Stuey3D]

Panning works the same too