SDRTrunk & SDR# not sharing

[N8RXX]

Hello,

I have SDRTrunk using two SDR dongles to feed my local 800 MHz system to a BCFY Calls node and it works well. I have SDR# using one SDR dongle to feed audio from a local 2-meter repeater to a traditional BCFY feed. This, too, works well except for one problem:

When I reboot my computer SDR# ends up grabbing one of the dongles that is supposed to be for 800 MHz. This dongle uses a small 800 MHz antenna that works well for that purpose since I'm a mile from the simulcast tower. SDR# is supposed to use the dongle that is connected to an external 2-meter antenna. Not surprisingly, the 2-meter repeater can't be heard with an 800 MHz antenna.

The only way I've found to "fix" this problem is to disconnect the 800 MHz dongles before starting SDR# so that it only has the correct dongle available. Then I can reconnect the other dongles and start SDRTrunk.

Is there a better way to be sure SDR# only uses the correct dongle? If I'm not home when my computer reboots the 2-meter feed will fail to work properly.

Thank you for your time!

 

[alphaacres]

Always Use SDRTrunk last it grabs all available SDRs and if SDRTrunk is running shut it down to start other SDR programs.

 

[GTR8000]

SDRTrunk has permitted the disabling of dongles for quite some time now.

Make sure you're running one of the latest releases of SDRTrunk (0.6.0 Final or 0.6.1 beta 1), disable the tuner that will be used for SDR#, then make sure going forward you start SDRTrunk first (not last as the other poster incorrectly suggested), then start SDR# second so it will access the last remaining dongle.

If the computer reboots on its own and you have the programs starting up automatically, you'll need to find a way to start SDRTrunk first, then waits before starting SDR#. Perhaps a script of some sort to delay the startup of SDR# by 20 seconds or so to ensure SDRTrunk is running.

 

[N8RXX]

SDRTrunk has permitted the disabling of dongles for quite some time now.

Make sure you're running one of the latest releases of SDRTrunk (0.6.0 Final or 0.6.1 beta 1), disable the tuner that will be used for SDR#, then make sure going forward you start SDRTrunk first (not last as the other poster incorrectly suggested), then start SDR# second so it will access the last remaining dongle.

If the computer reboots on its own and you have the programs starting up automatically, you'll need to find a way to start SDRTrunk first, then waits before starting SDR#. Perhaps a script of some sort to delay the startup of SDR# by 20 seconds or so to ensure SDRTrunk is running.

@GTR8000 - Thank you so much for your help! I will try this when I get home. If I don't have SDRTrunk starting automatically, and all three dongles are connected, will SDR# select the correct dongle when it starts? Or will it just select a random dongle?

Having an unattended reboot due to a power outage is unlikely because I have a UPS and a standby generator. However, Windows forces annoying reboots when it updates.

 

[N8RXX]

Always Use SDRTrunk last it grabs all available SDRs and if SDRTrunk is running shut it down to start other SDR programs.

These SDR programs sure are greedy when it comes to sharing dongles. 😉

 

[GTR8000]

Unless SDR# allows you to permanently disable/ignore dongles within that software, it's going to grab whichever dongle it decides to grab on startup. Denny added the ability to disable dongles (aka "tuners") in SDRTrunk to prevent the software from being greedy and locking up all dongles that are plugged in and not yet active (the feature was implemented July 2022 in 0.5.0 beta 4).

If you have SDRTrunk starting first and disable that VHF dongle, then start SDR# once SDRTrunk is running, you should be good to go.

 

[N8RXX]

Unless SDR# allows you to permanently disable/ignore dongles within that software, it's going to grab whichever dongle it decides to grab on startup. Denny added the ability to disable dongles (aka "tuners") in SDRTrunk to prevent the software from being greedy and locking up all dongles that are plugged in and not yet active (the feature was implemented July 2022 in 0.5.0 beta 4).

If you have SDRTrunk starting first and disable that VHF dongle, then start SDR# once SDRTrunk is running, you should be good to go.

View attachment 159009

I was afraid you'd say that because I don't think SDR# allows disabling dongles. So, I'll look for a way to keep it from starting before SDRTrunk starts. If I find a way, I'll post it here in case anyone needs it in the future.

I saw SDRTrunk's disable feature but didn't think it would work because all my dongles have the same serial number. How does it remember which dongle was disabled?

Thanks again!

 

[GTR8000]

Use rtl_eeprom to assign each dongle a unique serial #

 

[N8RXX]

Use rtl_eeprom to assign each dongle a unique serial #

Funny you should mention that. I was just searching for a way to change serial numbers. I'll give it a try when I'm more awake because some folks mention bricking their dongles. 😏

 

[N8RXX]

I had hoped to report back here with a way to keep SDR# from starting before SDRTrunk starts, however, I've been unsuccessful. I tried using Task Scheduler to start SDR# with a 30-second delay after a system reboot. I also tried a third-party app to do the same thing. Neither method worked properly because they started SDR# with the default frequency and mode settings in the FM broadcast band rather than the proper frequency in the 2-meter band. Also, the auto-play plugin doesn't function with either of these methods. It's odd because when I manually click on the same exe file, SDR# starts on the correct frequency and begins to play automatically after five seconds. Something about setting that exe file to autostart throws a monkey wrench into the works.

Other than that, I'm happy with my setup. I was able to tell SDRTrunk to disable the dongle used for 2-meters and, as long as SDR# is manually started last, I have no problem with it grabbing the wrong dongle. If a Windows update causes an unattended system reboot my BCFY feed will go down until I can be present to fix it. That's just the way it will have to be unless somebody reads this and offers a solution.

 

[GTR8000]

SDR# is a weird animal, never liked it all that much.

Couldn't you simply use the VHF dongle in SDRTrunk and have your SKYWARN feed originate from there, ditching SDR# altogether?

 

[N8RXX]

SDR# is a weird animal, never liked it all that much.

Couldn't you simply use the VHF dongle in SDRTrunk and have your SKYWARN feed originate from there, ditching SDR# altogether?

I didn't know that was possible! That would be a better solution but I thought SDRTrunk was specifically for monitoring trunked systems.

Looks like I need to do more research but I promised my wife I'd finish our taxes tomorrow. Hmmm 🤔

 

[GTR8000]

SDRTrunk is capable of NBFM. You can specific the channel bandwidth (7.5k, 12.5k, 25k), and SDRTrunk can send audio to traditional BCFY feeds as well. You'll need to stop your current feed software, then sign into SDRTrunk with your RR/BCFY credentials (on the Radio Reference tab), then go back to the Streaming tab to find your SKYWARN feed. There's a bit more to it than that as far as getting the NBFM channel setup, but it's pretty well documented at this point, so you should be fine.

The biggest issue is making sure SDRTrunk grabs the VHF dongle for that NBFM channel, so you'll want to set that to #1 auto-start and obviously make sure that tuner is preferred for that channel. Then the two 800 dongles are free for your Calls node, which should be set to auto-start #2.

 

[N8RXX]

SDRTrunk is capable of NBFM. You can specific the channel bandwidth (7.5k, 12.5k, 25k), and SDRTrunk can send audio to traditional BCFY feeds as well. You'll need to stop your current feed software, then sign into SDRTrunk with your RR/BCFY credentials (on the Radio Reference tab), then go back to the Streaming tab to find your SKYWARN feed. There's a bit more to it than that as far as getting the NBFM channel setup, but it's pretty well documented at this point, so you should be fine.

The biggest issue is making sure SDRTrunk grabs the VHF dongle for that NBFM channel, so you'll want to set that to #1 auto-start and obviously make sure that tuner is preferred for that channel. Then the two 800 dongles are free for your Calls node, which should be set to auto-start #2.

Good information! I will be working on this when I finish taxes. The politicians are busy wasting money so that has to be my priority. 🫤

 

[N8RXX]

SDRTrunk is capable of NBFM. You can specific the channel bandwidth (7.5k, 12.5k, 25k), and SDRTrunk can send audio to traditional BCFY feeds as well. You'll need to stop your current feed software, then sign into SDRTrunk with your RR/BCFY credentials (on the Radio Reference tab), then go back to the Streaming tab to find your SKYWARN feed. There's a bit more to it than that as far as getting the NBFM channel setup, but it's pretty well documented at this point, so you should be fine.

The biggest issue is making sure SDRTrunk grabs the VHF dongle for that NBFM channel, so you'll want to set that to #1 auto-start and obviously make sure that tuner is preferred for that channel. Then the two 800 dongles are free for your Calls node, which should be set to auto-start #2.

It took some trial and error and it seemed that SDRTrunk was going to work. However, it isn't quite there. I gave my dongles unique serial numbers and got SDRTrunk to grab the VHF dongle for my SKYWARN feed. Broadcastify says it's connected and playing via SDRTrunk, however, I tested and found that no audio is actually playing. I monitored the feed for a couple of hours but shut it down when I heard traffic from my BCFY Plays coming through on my SKYWARN feed. I have no idea how that could happen but figure it's a no go for several reasons.

Since we are entering severe weather season, I went back to providing my SKYWARN feed via SDR#. I either need to figure out why SDRTrunk is misbehaving or find an alternative SDR player that allows me to select a preferred dongle and/or allows delayed start for my SKYWARN feed. Worst case scenario, I stick with SDR#. It does work but isn't optimal.