Conventional Analog Calls Node

[Forts]

Hi all,

Quick question to the group before I go too far down the troubleshooting rabbit hole. I currently have SDRTrunk streaming 2 analog fire channels from my county to RDIO Scanner for a private setup. I'm also using another dongle and ScannerCast to provide a feed here of the same channels. It occurred to me today that I can use SDRTrunk to supply a calls node of these two channels at the same time and I'd be able to eliminate my current feed, so I applied for a node and was approved. I've set everything up, but it's only essentially half working. My calls node consists of a dispatch channel and a fireground channel. The dispatch channel is coming thru just fine, but I'm not seeing any activity at all on the fireground side of things. After a bunch of reading I'm now confused if this setup even works with analog? I've seen some posts that say only P25 conventional from SDRTrunk. But if that's the case, why does the dispatch channel work?

Any tips or pointers much appreciated!

 

[DSheirer]

Your channel config for the analog channels should allow you to assign a pseudo-talkgroup value to any call audio that gets generated. This allows you to alias that pseudo-talkgroup and to also designate it to stream. I'm guessing you've already figured this out since you're having luck with at least one of the CALLS streams.

On the fireground config, verify that the pseudo talkgroup is aliasing correctly and that the alias is also configured to stream to the CALLS node. You can also check your calls node and see if any of the calls are being rejected for either time skew or for duplicate calls.

 

[Forts]

Hi Denny,

Thanks for the tips. Yes both channels have a group # assigned to them, and it all passes thru just great to RDIO. For the calls node I setup Broadcastify Call in the Playlist editor under the streaming tab and selected the two aliases I want (in my case TAC1 and TAC3). There is a call in progress at the moment and the traffic on TAC1 is showing up, but nothing at all from 3.

 

[DSheirer]

Can you temporarily disable calls streaming for TAC1 so that just TAC3 is configured to stream to CALLS. Then, turn on the streaming statistics panel from the View menu and watch the statistics for your CALLS node to see if the TAC3 calls are being queued for streaming (ie count increases) and if the calls then show as either streamed or error after they enter the queue and get processed.

 

[Forts]

Sure, I'll give that a try. I also just made new individual alias lists for each group and tried assigning things that way. And now, as always... nobody is talking lol

 

[DSheirer]

Also, make sure you're not using the same System name value in both channel configs and that you're not using the same pseudo-talkgroup values. The duplicate call detection code could possibly be kicking in and flagging the TAC3 calls as duplicate to the TAC1 calls if the system name is the same. You can easily test this by turning off duplicate call detection in the User Preferences dialog.

 

[Forts]

Oh! The system name value is indeed the same for both (it's the county name). Talkgroup values are definitely different however.

I turned on the streaming stats and the Upload Error is at 63... so that's not good.

 

[Forts]

So ideally I'd like to keep the system name the same for both channels (they are part of the same system, and this keeps the channels grouped together in the RDIO talkgroup list). If I disable duplicate call detection will that possibly get around it?

Thanks very much for the replies by the way... much appreciated!

 

[DSheirer]

If you're getting streaming errors, that's the more likely reason. You can keep system name the same

 

[Forts]

So another call is on the go right now. I only have TAC 3 selected, Duplicate Calls turned off and I'm getting "Temporary Broadcast Error".... I'm totally puzzled.

Edit: Same issue with duplicate calls enabled.
Edit2: This is what I'm seeing in the SDRTrunk console window..

2024-08-28 18:10:36.303 ERROR i.g.d.a.b.b.BroadcastifyCallBroadcaster - Broadcastify calls API upload URL request failed [1 No-Freq-Table-Entry-For-Upload] [289MB/692MB 41%]

 

[DSheirer]

That may be a configuration issue that needs to be resolved on the broadcastify calls side of things: 1 No-Freq-Table-Entry-For-Upload

 

[Forts]

For anyone else that might stumble upon this.... The issue was with the virtual TGids I had assigned in SDRTrunk. Conventional channels on the Broadcastify end are aligned in numerical order and are numbered 1,2,3 etc... I was using TG's 1 & 3. Once I switched 3 to 2 everything started working.