DSDPlus RFSS_STS_BCST showing different CC

[billy2047]

Hi all, I'm watching 1R DSD+ window and I've noticed my local P25 system is sending out a different control channel indicated by RFSS_STS_BCST status broadcast.

For example, the screenshot shows CC=853.8125. but in reality, the CC for the system is transmitting on 856.7125. When that happens, DSD+FL jumps to 853.8125 and then nothing.


There is nothing transmitting on 853.8125 and the frequency is not even part of the system.

Does anyone know why? Thanks

 

[dave3825]

Is that Volusia County?

 

[dave3825]

That was reported December 2024 and back then it was not happening to you. Now it is. Something changed somewhere.

I’m in the i4/95 area and was seeing site 71 856.7125 soon as I click that freq it goes to 853.8125. And there’s nothing there on the 853.8125. Has anyone see the 856.7125?

I'm decoding site 71.71 (856.7125) right now and it doesn't jump to 853.8125.

 

[mtindor]

Hi all, I'm watching 1R DSD+ window and I've noticed my local P25 system is sending out a different control channel indicated by RFSS_STS_BCST status broadcast.

For example, the screenshot shows CC=853.8125. but in reality, the CC for the system is transmitting on 856.7125. When that happens, DSD+FL jumps to 853.8125 and then nothing.
View attachment 196639

There is nothing transmitting on 853.8125 and the frequency is not even part of the system.

Does anyone know why? Thanks

What version of DSDPlus are you running? (you should always indicate that from the start)

 

[bravo14]

That was reported December 2024 and back then it was not happening to you. Now it is. Something changed somewhere.

I was running the newest version of DSD. I've tried different versions still happening on them. I don't know if there is a difference from 1r to dsdplus cc. I do use FMP24 CC when using 1r or dsdplus cc.

 

[mtindor]

I was running the newest version of DSD. I've tried different versions still happening on them. I don't know if there is a difference from 1r to dsdplus cc. I do use FMP24 CC when using 1r or dsdplus cc.

You should consider going to CTRL and setting it to CC-only. Then Record some raw audio (I'm guessing 30 seconds is reasonable because I imagine the RFSS_STS_BCST is being repeated so quickly / often that there would be a bunch of those in just a 30 second capture. Then post it here (so some of us curious people could see it for ourselves) and send it to dsdplusfastlane@gmail.com.

Have you ever tried any other trunking software (like SDRTrunk) on the same system? If so, does it exhibit the same behavior? Do you see the same RFSS_STS_BCST info being reported?

 

[dave3825]

@billy2047 As of Monday @seagravebuff60 listed 2 freqs and 853.8125 was not mentioned.

Site 71.71 has been up for a few weeks now. There seems to be only one active control channel, 856.7125, which isLCN 1 of site 20 on the EDACS System. And a Voice Channel of 857.2125, which is LCN 2 of site 20 on the EDACS System. From my logs, only a few TGs seem to be running through this P25 Site 71.71, Especialy the Speedway talkgroups recently for the Rolex 24 that was there a few weeks ago. Been pretty dead ever since

Perhaps download a fresh virgin copy of DSDPlus Full which would not contain any DSDPlus.P25data and see what that does. And as @mtindor asked, what does Unitrunker or SDRT show and or do on that site?

 

[RMason]

Does the system send the control channel frequency - or is it calculated from the channel number? ( in this case CC=0-217). Is it possible that there is an issue with the band plan stored in the P25data file?

You can try deleting the bandplan from the DSDPlus.P25data file for this system. This will force DSDPlus to repopulate the band plan from the control channel steam. I recommend backing up the P25data file before editing. You can then compare the files to see if the band plan changes.

 

[billy2047]

Is that Volusia County?

Yes, I'm only using Volusia for example. I have seen other Harris P25 systems (FPL, Dukedo) do this. I have not seeing it happens with motorola systems.

That was reported December 2024 and back then it was not happening to you. Now it is. Something changed somewhere.

Something's definitely changed on the system side

 

[billy2047]

What version of DSDPlus are you running? (you should always indicate that from the start)

Version 2.547

 

[billy2047]

You should consider going to CTRL and setting it to CC-only. Then Record some raw audio (I'm guessing 30 seconds is reasonable because I imagine the RFSS_STS_BCST is being repeated so quickly / often that there would be a bunch of those in just a 30 second capture. Then post it here (so some of us curious people could see it for ourselves) and send it to dsdplusfastlane@gmail.com.

I will try that. As soon as dsd+ decodes/sees CC=853.8125, it just jumps to that frequency and then nothing. It will not stay on the actual control channel which is 856.7125

Have you ever tried any other trunking software (like SDRTrunk) on the same system? If so, does it exhibit the same behavior? Do you see the same RFSS_STS_BCST info being reported?

Yes, SDRTrunk is working/decoding that system just fine, it does not jump to 853.8125, same RFSS_STS_BCST info being send out

 

[billy2047]

@billy2047 As of Monday @seagravebuff60 listed 2 freqs and 853.8125 was not mentioned.



Perhaps download a fresh virgin copy of DSDPlus Full which would not contain any DSDPlus.P25data and see what that does. And as @mtindor asked, what does Unitrunker or SDRT show and or do on that site?

Unitrunker ad SDRT work just fine, it will not jump to 853.8125

 

[billy2047]

Does the system send the control channel frequency - or is it calculated from the channel number? ( in this case CC=0-217). Is it possible that there is an issue with the band plan stored in the P25data file?

You can try deleting the bandplan from the DSDPlus.P25data file for this system. This will force DSDPlus to repopulate the band plan from the control channel steam. I recommend backing up the P25data file before editing. You can then compare the files to see if the band plan changes.

RFSS STS BCST CC=853.8125 info is sent out by the system. The actual control channel really is transmitting on 856.7125. I'm just not sure why the system would send out CC=853.8125(or any other random frequency for that matter)

 

[dave3825]

Unitrunker ad SDRT work just fine, it will not jump to 853.8125

Ok, and how about the other suggestion?

Perhaps download a fresh virgin copy of DSDPlus Full which would not contain any DSDPlus.P25data and see what that does.

 

[KevinC]

I would suspect a mismatch between the core and the local site controller. MSI used to allow this as well, but now Voyence should catch and correct it.

 

[billy2047]

Ok, and how about the other suggestion?

Still jumps with a fresh copy of DSDFL. I think the issue is on the system side, not DSD.

 

[dave3825]

Unitrunker ad SDRT work just fine, it will not jump to 853.8125

Still jumps with a fresh copy of DSDFL. I think the issue is on the system side, not DSD.

If its something on the system side, and UT and SDRT work fine, then it would seem its an issue with how DSDPlus handles the mismatch.

You could do as @mtindor suggested so that the DSDPlus creator could have a look and possibly come out with a fix.

You should consider going to CTRL and setting it to CC-only. Then Record some raw audio (I'm guessing 30 seconds is reasonable because I imagine the RFSS_STS_BCST is being repeated so quickly / often that there would be a bunch of those in just a 30 second capture. Then post it here (so some of us curious people could see it for ourselves) and send it to dsdplusfastlane@gmail.com.

 

[GTR8000]

There's definitely an issue with the system broadcasting the wrong LCN for the RFSS Status Broadcast message, however DSD+ really ought not to be interpreting that message in order to determine the active control channel to tune FMPx to. I get the temptation to do so, in theory it would provide FMPx/DSD+ with the ability to immediately re-tune to a new frequency if the control channel rolls. The trouble with that theory is that the carrier on that particular control channel would have already dropped by the time the RFSS Status Broadcast message starts to announce the newly active control channel, thus rendering that message useless for determining the active control channel frequency for tuning purposes.

Unitrunker and SDRTrunk (and almost all other software/hardware) rely on the carrier dropping, at which point they hunt for the newly active control channel. That's the most reliable way to handle control channel rolls.

tl;dr DSD+ author should really get rid of the software's processing of the RFSS Status Broadcast messages, as a mis-configured system like this one can cause issues with reliable decoding

 

[cg]

If you shut off Hunt for Lost Control Channel in the Control tab, does that prevent it from changing?

 

[billy2047]

Here is a short clip showing the issue.
Here, I use site 40.40 with actual control channel on 857.7625 for example, notice how as soon as 1R DSD+ sees

2026.02.08 20:05:43 Sync:+P25p1 NAC:028 TSDU RFSS_STS_BCST SysID= 00A LRA=40 RFSS=40 Site=40 CC=854.8625 SC=70

FMP24 just jumps to 854.8625.