Mixed Conventional and P25 Calls Node

[Enforcer52]

Setup a Conventional Calls Node that has a mixture of 7 conventional and P25 channels. Setup SDRTrunk to login to the node, no problems logging in.

Setup alias list for the 7 channels.

I am only receiving 1 of the channels, San Jac EMS, but it is showing up as Polk SO which is one of the other channels in the alias list. In my node manager it lists all 7 of the channels I setup. Here is my channel list:

154.7850 Polk Co SO P25
154.8450 San Jacinto Co SO P25
155.7825 San Jacinto Co FD NBFM
155.8125 Livingston FD NBFM
155.9325 Onalaska PD P25
155.9775 San Jacinto Co EMS NBFM
156.2175 Onalaska FD NBFM

I'm evidently not doing something right and need help.

 

[Enforcer52]

The NBFM channels are coming thru, but still showing up as Polk SO P25. Pulling my hair out on this one.

 

[blantonl]

See No Freq Table for calls upload

 

[Enforcer52]

Where do I create that? Thought that was the freqs I put in when I signed up.

 

[Enforcer52]

Thanks when I figured out there was a link in your post, I was able to get the 4 NBFM channels working. Now trying to figure out the 3 P25 channels in the list.

 

[Enforcer52]

Here is what I figure out my problem with the P25 are. I should have set the Freqs list as follows:

ID
1 155.9325 Onalaska PD 1 - P25
2 155.7825 San Jac Fire - NBFM
3 155.8125 Livngstn FD1 - NBFM
4 155.9775 San Jac EMS - NBFM
5 156.2175 Onalaska FD 1 - NBFM
8001 154.7850 Polk SO P25 - P25
12801 154.8450 San Jac SO 1 - P25

I don't know if this is even possible at this point with the talkgroups for Polk Co SO and San Jac SO 1 being so high and if it's possible to skip ID numbers.

At least the NBFM channels are working right at this point.

 

[Enforcer52]

Can anyone answer if the frequency list can be updated after a calls node is setup????

 

[blantonl]

Here is what I figure out my problem with the P25 are. I should have set the Freqs list as follows:

ID
1 155.9325 Onalaska PD 1 - P25
2 155.7825 San Jac Fire - NBFM
3 155.8125 Livngstn FD1 - NBFM
4 155.9775 San Jac EMS - NBFM
5 156.2175 Onalaska FD 1 - NBFM
8001 154.7850 Polk SO P25 - P25
12801 154.8450 San Jac SO 1 - P25

I don't know if this is even possible at this point with the talkgroups for Polk Co SO and San Jac SO 1 being so high and if it's possible to skip ID numbers.

At least the NBFM channels are working right at this point.

Where did you get the 8001 and 12801 IDs from?

 

[blantonl]

Your IDs should be setup as the following

1 c-279409 154.78500 Sheriff/Police Dispatch P25 [Polk SO P25] 1739486110 108
2 c-43036 154.84500 Sheriff Dispatch [San Jac SO 1] 0 0
3 c-104224 155.78250 Fire Dispatch [San Jac Fire] 1739503241 19
4 c-189913 155.81250 Fire Dispatch [Livngstn FD1] 1739540674 25
5 c-393234 155.93250 Police Dispatch [Onalaska PD 1] 0 0
6 c-189507 155.97750 EMS Dispatch (Allegiance Ambulance) [San Jac EMS] 1739543756 176
7 c-75356 156.21750 Fire Dispatch [Onalaska VFD Dis] 1739486699 1

 

[Enforcer52]

SDRTrunk will only recognize the talkgroup number used by a P25 system. Discovered this while trying to figure out my problem with the P25 sites yesterday.

Onalaska PD uses talkgroup identifier 1 on their system, so I received them on ID 1 and it showed Polk SO P25 as the origin. Tried adding identifier 5 in the alias, but it still came over as Polk SO P25, even with both identifiers in the alias. Polk Co uses 8001 as their identifier and San Jac used 12801 as theirs.

Added identifier 2 to San Jac SO, identifier 1 to Polk So P25, and identifier 5 to Onalaska PD. Still would not receiver San Jac or Polk, and Onalaska continued to come over on the Polk So P25 ID.

Can find no way to get SDRTrunk to send to calls without the embedded identifier being used, since SDRT doesn't recognize "psuedo intenfiers" in P25. So this was the only thing I could think of that would work.

Maybe I'm wrong in some aspect of the setup with calls or SDRTrunk. Or maybe one is not able to mix and match Conventional and P25 in the same node. Stumped at this point.

 

[blantonl]

I think you need to setup an alias list for each conventional P25 channel

 

[Enforcer52]

I have tried that, I setup an alias list for each P25 with just the 1, 2, and 5 identifiers for Polk as 1, San Jac as 2, and Onalaska PD as 5. Polk and San Jac not recognized in SDRT and Onalaska came over calls as Polk SO. Without the embedded identifiers.

When I did this SDRT would not show the department name in it's own Alias column. Would hear the transmission, but SDRT works on the embedded identifier and not on a psuedo identifier on P25 channels. SDRT shows errors if the embedded identifier doesn't match the calls identifier.

I also tried with both the embedded identifier and the psuedo indentifier in the alias list and only Onalaska came over calls as Polk SO.

Also setup a separate alias list in SDRT for these three channels and tried all combinations, so no go at this time, unless the calls platform can accept freqs out of sequence and with the embedded identifier.

Think it is more a SDRT problem than a Calls problem.

 

[blantonl]

I think you need to setup an alias list for each P25 conventional channel that maps

For 154.825 you need to map 8001 to 1

and

For 154.845 you need to map 12081 to 2

and

For 153.9325 you need to map 1 to 5

 

[Enforcer52]

OK I'm dumb, how do I map them, searched SDRT info and can't find out how to get it to map say 8001 to 1. Brain dead after a day of trying to figure it out, sorry.

 

[blantonl]

I think the SDRTrunk developer @DSheirer may need to step in

 

[Enforcer52]

Me too, I have emailed him. Thanks for all your help.

 

[DSheirer]

If I understand correctly, you're trying to assign 'pseudo-talkgroup' values 1-7 to calls from your NBFM/Conventional channels and then consolidate (force-fit) those calls together with calls from a set of P25 channels. However, the P25 channels already have some of those talkgroup values assigned for P25 radios and now you're having collisions because, for example, NBFM pseudo-talkgroup 1 is colliding with P25 legitimate talkgroup 1 and the CALLS platform is assigning an alias that may or may not be correct. Does this describe the situation?

Since you're consolidating the output of two different technologies (P25 and Conventional), you need to ensure each call has a unique talkgroup identifier. You can't change the P25 talkgroups that are already in use. You can change the pseudo talkgroup values that you select to assign to the output from the conventional NBFM channels in sdrtrunk. You could possibly use higher-valued pseudo-talkgroups (e.g. 65001, 65002, 65003, etc,).

How is your feed configured on the CALLS platform end? Is it configured for a set of conventional channels where it's using the aliases listed in the frequency/channel table, or is it using a set of P25 talkgroup aliases from one of the P25 system views in radio reference?

Denny

 

[Enforcer52]

Somehow we are talking different uses of the term talkgroup I think, at no time am I referencing TGID's of a trunked P25 system.

Broadcastify's Conventional Calls Platform is for NBFM and P25 (single channel, no trunking) combined together. The NBFM side is easy, in SDRT just assign the Talkgroup Identifier to the Calls Platform ID# and it works with no issue because SDRT will show the psuedo identifier as the value displayed in the TO column.

In a P25 trunked system the TO column shows the TGID of the particular channel being used at the time. This is not what I am referring to, I am only referring to a P25 Conventional 1 channel system where the TO channel always shows the assigned Identifier because there are no other Identifiers for the system.

On the P25 conventional channels, In SDRT the TO channel displays the embedded value of the Talkgroup Identifier, and in the alias setup you would normally set the Identifier to this number, and it works for normal Broadcastify feeds.

In the Broadcastify NBFM/P25 Conventional Calls Platform the frequencies are setup in numerical order and are assigned an ID number starting with 1, numerically in order, for ever how many frequencies one submits. You also submit the name of the channel for each frequency which is translated to match the name in the RR database. So the 7 frequencies I submitted where setup by Broadcastify as follows:

1 c-279409 154.78500 Sheriff/Police Dispatch P25 [Polk SO P25] 1739486110 108
2 c-43036 154.84500 Sheriff Dispatch [San Jac SO 1] 0 0
3 c-104224 155.78250 Fire Dispatch [San Jac Fire] 1739503241 19
4 c-189913 155.81250 Fire Dispatch [Livngstn FD1] 1739540674 25
5 c-393234 155.93250 Police Dispatch [Onalaska PD 1] 0 0
6 c-189507 155.97750 EMS Dispatch (Allegiance Ambulance) [San Jac EMS] 1739543756 176
7 c-75356 156.21750 Fire Dispatch [Onalaska VFD Dis] 1739486699 1

As long as SDRT has San Jac Fire identifier set to 3, Livngstn FD 1 identifier set to 4, San Jac EMS identifier set to 6, and Onalaka VFD Dis identifier set to D7, Conv Calls Platform accepted them and broadcasts them to the feed.

Here is where the problem lays.

ID1, ID 2, and ID3 are P25 channels. Conventional Call Platform only uses the ID# to determine what frequency and channel name will be accepted and broadcast to a feed.

Polk CO P25 has an embedded identifier as 8001
San Jac SO has an embedded identifier as 12801
Onalaska PD 1 has an embedded identifier as 1

So Conv Calls Platform ignores Polk CO P25 and San Jac SO as they do not have an identifier in the ID# table.

It then sees Onalaska PD 1 has an identifier as 1, so calls broadcasts the feed as Polk SO P25, when it's actual ID# should be 5 so it shows Onalaska PD 1.

SDRT needs the ability to change the embedded identifier so it shows up in the TO column as what the ID# in conv calls platform is expecting for that particular frequency/channel name, as it does with the NBFM channels.

Currently, no matter what number you put in the identifier other than the expected ID# of a conv calls platform it is ignored, or in the case of my Onalaska PD1 channel, sent with the wrong channel name.

NONE of this applies to the P25 Trunked Broadcastify feeds, which are separate from the Conventional Broadcastify feeds.

I hope this explains the situation and maybe Blantonl and Denny can get together and figure it out. If not then I guess I learn to live with it.

Thanks to all for you time, maybe my local counties will get off their rears and all get fully on the TxWarn system then I wouldn't have this problem.

 

[blantonl]

Broadcastify Calls operates on the concepts of "slots" for conventional channels.

A slot, for conventional channels, maps a n+1 integer to a specific frequency (identified in the database by a unique "fid") in the RadioReference database for a node.

So, his node is currently defined on our end as the following:

slot    fid    frequency    description
-------------------------------------------------------------------------------
1     279409     154.78500     Sheriff/Police Dispatch P25 [Polk SO P25]
2     43036     154.84500     Sheriff Dispatch [San Jac SO 1]
3     104224     155.78250     Fire Dispatch [San Jac Fire]
4     189913     155.81250     Fire Dispatch [Livngstn FD1]
5     393234     155.93250     Police Dispatch [Onalaska PD 1]
6     189507     155.97750     EMS Dispatch (Allegiance Ambulance) [San Jac EMS]
7     75356     156.21750     Fire Dispatch [Onalaska VFD Dis]

SDRtrunk sends each call to that slot as a "talkgroup alias" - however for P25 Conventional channels, if the channel has a P25 conventional talkgroup ID (in these cases 1, 8001, and 12081) then that is sent as the slot instead of a defined alias.

Technically, we could actually get this up and running properly if we defined his system like this

slot    fid    frequency    description
-------------------------------------------------------------------------------
1     393234     155.93250     Police Dispatch [Onalaska PD 1]
2     104224     155.78250     Fire Dispatch [San Jac Fire]
3     189913     155.81250     Fire Dispatch [Livngstn FD1]
4     189507     155.97750     EMS Dispatch (Allegiance Ambulance) [San Jac EMS]
5     75356     156.21750     Fire Dispatch [Onalaska VFD Dis]
8001     279409     154.78500     Sheriff/Police Dispatch P25 [Polk SO P25]
12081     43036     154.84500     Sheriff Dispatch [San Jac SO 1]

This should work. However, if we ever had a situation where there were two P25 conventional channels on an individual node that had the common talkgroup ID of 1, then there would be a conflict.

Enforcer, do you want me to setup your node like the above?

 

[Enforcer52]

Enforcer, do you want me to setup your node like the above?

Yes that would be much appreciated. I luckily don't have any other P25 Conv systems that use 1 as the identifier, but from what I have read there are a lot of systems across the USA that use 1, so could be a problem in the future.