DSDPlus DSD+ 2.509 Fastlane Released, Small Update

[CanesFan95]

Change Log
----------

DSD+ 2.509

Additional tweaks and bug fixes.

Added menu entry to limit number of per-radio Alias Priority OTA alias data acquisition attempts.
Useful for systems that have a mix of radios with and without alias data broadcasts present.



Default is 50:

 

[CanesFan95]

I see messages saying alias acquired, but not seeing the 2nd message about it going to the server and AliasStats.txt isn't updating.

 

[slicerwizard]

Saw the same thing here. Seems to be working normally now.

 

[Spitfire8520]

I see messages saying alias acquired, but not seeing the 2nd message about it going to the server and AliasStats.txt isn't updating.

View attachment 172610

It looks like DSDPlus does not track if it fails to send the OTA alias data to the alias server and will not retry sending the OTA alias data. Reacquisition does not work to fix this because the raw OTA alias data has not changed.

You can identify if you are affected by taking MotOTA - MotClr to figure out how many aliases you have pending locally and then check to see if it is greater than the "Pending Aliases" on the Alias Server Stats.

The interim solution is to manually go through the .radios file and delete any OTA alias data that has not returned a clear alias (anything with a ~ or blank) to force DSDPlus perform a new initial OTA alias data acquisition and alias server update. It is probably best to wait until you get a bulk return of aliases from the server to limit the damage.

 

[slicerwizard]

DSD+ fails to send OTA data to the server any time I'm mobile without an Internet connection. When I remember to tether my laptop to my phone, DSD+ starts sending that data, although there's usually a short delay before it starts.

When OTA data seems to be truly stuck, I set the reacquisition time to one day and it hunts down the alias data again and inevitably says that it has "*changed*" and sends off the new data. That typically gets a clear alias being kicked back immediately, so these stuck aliases look to be some sort of bad decodes?

Shutting down DSD+ and manually removing any OTA data that doesn't have a matching clear alias also works, but that's labor that I don't really care to be doing going forward.

 

[RaleighGuy]

So, can I assume here that there are some radios without aliases, or that are not set to do OTA? While I know the VIPER primary radios do not decode, I'm seeing a lot of county radios repeatedly that the RID alias is never caught in DSD+.

 

[mtindor]

So, can I assume here that there are some radios without aliases, or that are not set to do OTA? While I know the VIPER primary radios do not decode, I'm seeing a lot of county radios repeatedly that the RID alias is never caught in DSD+.

View attachment 172623

Yes, you can assume that, OR it simply could be that they never transmitted. If they just registered/affiliated, you'll never get OTAAliases from them. They must transmit.

On both systems I monitor I have plenty of RIDs that register/affiliate every day but never key up. So I don't get their OTAAliases.

 

[Reconrider]

Yes, you can assume that, OR it simply could be that they never transmitted. If they just registered/affiliated, you'll never get OTAAliases from them. They must transmit.

On both systems I monitor I have plenty of RIDs that register/affiliate every day but never key up. So I don't get their OTAAliases.

I have this issue often. Some radios are just for sitting on a desk and listening but never communication which sucks because then it's not updated

 

[RaleighGuy]

I have this issue often. Some radios are just for sitting on a desk and listening but never communication which sucks because then it's not updated

In my case they are transmitting, but alias is not being caught. This said I will add the overwhelming (3600) number of them have been caught

 

[Reconrider]

In my case they are transmitting, but alias is not being caught. This said I will add the overwhelming (3600) number of them have been caught

Yikes. If it helps you can use notepad++ and ctrl f. Search for quote space space(" ) and it will go to only the lines with an alias. If you know regex you could use Linux and remove items per line without deleting the whole line

 

[slicerwizard]

In my case they are transmitting, but alias is not being caught. This said I will add the overwhelming (3600) number of them have been caught

You can look at the console log to see if any alias data is being transmitted during those calls.

 

[RaleighGuy]

You can look at the console log to see if any alias data is being transmitted during those calls.

It is not, from what I saw.

 

[CanesFan95]

There's times with a weak signal I'll see voice call RIDs in the CC Event Log / Channel Activity but those RIDs don't show in VC, just the TGID. So those RIDs end up not making it to the server.

 

[RaleighGuy]

My statewide system, VIPER, does decode, however it seems that few users are using this feature and decodes for those that do are hit and miss.

I have a good signal on a tower less than 2 miles away from me, I am only seeing decodes from some SHP units and a few others every now and then. Not sure why some decode and others don't, maybe it is just how DSD+ grabs/locks on to the signal.

 

[mtindor]

My statewide system, VIPER, does decode, however it seems that few users are using this feature and decodes for those that do are hit and miss.

I have a good signal on a tower less than 2 miles away from me, I am only seeing decodes from some SHP units and a few others every now and then. Not sure why some decode and others don't, maybe it is just how DSD+ grabs/locks on to the signal.

You can actually see if a radio is sending an OTAalias. Just watch the command line window where all the decoding of a phase I or phase II voice call is happening. It's all going to look like gibberish. But near the end of each conversation (or multiple times if a particular voice channel is used to carry the full conversation between multiple radio IDs) you'll see references to "Radio Alias" and "Radio Alias Header". It's just highly likely that not every one of the talkgroups on the system has a radio alias. It's my understanding that the feature added in each radio to enable to even send OTA Aliases is something like $100-120 bucks. Multiply that by the number of radios on a system and you can see one reason why not everyone might have that enabled in their radio. There various reasons why an entity wouldn't.

If you have a good decode, DSDPlus grabs the OTA pretty quickly and typically doesn't need a second try at grabbing it from a particular RID.

Mike

 

[CanesFan95]

I wish there was a way to set the re-acquisition rate to NEVER. I only want to acquire each OTA alias once and stop there.

 

[mtindor]

I wish there was a way to set the re-acquisition rate to NEVER. I only want to acquire each OTA alias once and stop there.

You have got some "odd" needs. The default is 30 days. Presumably if you monitor a particular site on a system for 30 days, you will have gathered just about everything there is to gather. Then just turn off the feature completely.

Aliases can and do change in radios. I'm sure some haven't changed for years. But how would you know if you didn't check periodically.

 

[CanesFan95]

Well, I don't think it's "odd". I know the default is 30 days. But I doubt aliases would somehow change that often.

 

[mtindor]

Well, I don't think it's "odd". I know the default is 30 days. But I doubt aliases would somehow change that often.

I've seen at least two people on the forums indicate seeing apparently new radios with generic aliases -- and then subsequently, days later, those aliases were updated to reflect a more specific use / new radio user. Aliases may change, like it or not. Maybe you are monitoring a system will not a single alias will ever change again, but you can't assume all are like that. Just turn off the capturing of aliases and move on with life -- pretending that you never heard of OTA aliases. Seems like an easy fix.

 

[RaleighGuy]

Well, I don't think it's "odd". I know the default is 30 days. But I doubt aliases would somehow change that often.

In just the few days we have had this feature I've seen the message that RID alias was being updated, it may have changed or it may have been a bad decode. I've also seen the message that the data for a RID was stale, whatever that means, and was resampled. Leaving it on is a good idea in my opinion to catch that radio seldomly used, or new radios added for a new hire.

The amount of resources it takes is so small you won't even notice, and if the messages bother you turn them off and let it run in the background only alerting you if a new decode is added.