DSD+ 2.522 Released Thursday, January 23, 2025

[mtindor]

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

DSD+ 2.522

Some stability improvements.

Note:
Users are reminded of the importance of backing up your DSD+ data files. No-one is immune
to developer coding errors, hardware failures, disk space exhaustion or stinky brain farts.

 

[maus92]

So I updated my logging computer to V 2.522 from V 2.509. When I started .522, it tuned to my local L3H public safety system as it is setup to do, but it immediately added four P25 talker aliases from the Excelon Power system. The Excelon system did pre-exisit exist in my DSDPlus.P25Data file. I'm curious what triggered this action. Below are the Event log entries showing the addition of the talker aliases:

2025/01/23 11:59:31 Freq=851.475000 Alias server returned talker alias "NSV 04715" for BEE00.1C7-64367
2025/01/23 11:59:32 Freq=851.475000 NAC=00A Alias server returned talker alias "NTS-LAKEY" for BEE00.1C7-68043
2025/01/23 11:59:33 Freq=851.475000 NAC=00A Alias server returned talker alias "ML POR4" for BEE00.1C7-68165
2025/01/23 11:59:34 Freq=851.475000 NAC=00A Alias server returned talker alias "2782" for BEE00.1C7-62036

(Note: these events occurred as DSD was starting up, but there were intermediate entries in the Events log - I omitted those)

851.4750 is the current control channel for the Worcester County L3H TRS; BEE00.1C7 is the Excelon Energy system; I'm assuming that the .1C7-6xxxx suffixes are RIDs. Question: how is the talker alias relationship to the Worcester system being derived? Is there actually a relationship, or did the program just grap talker aliases and download them based on the Excelon system's previous entry in my P25Data file? Or is somthing else going on? Is there an (undetected) ISSI connection between the two systems? Are the Excelon subscribers operating on the Worcester system at the time?


Adding, the 4 radios that received talker aliases update had existed previously in my DSDPlus.Radios file.

 

[Whiskey3JMC]

I'm assuming that the .1C7-6xxxx suffixes are RIDs.

Correct

 

[mtindor]

So I updated my logging computer to V 2.522 from V 2.509. When I started .522, it tuned to my local L3H public safety system as it is setup to do, but it immediately added four P25 talker aliases from the Excelon Power system. The Excelon system did pre-exisit exist in my DSDPlus.P25Data file. I'm curious what triggered this action. Below are the Event log entries showing the addition of the talker aliases:

2025/01/23 11:59:31 Freq=851.475000 Alias server returned talker alias "NSV 04715" for BEE00.1C7-64367
2025/01/23 11:59:32 Freq=851.475000 NAC=00A Alias server returned talker alias "NTS-LAKEY" for BEE00.1C7-68043
2025/01/23 11:59:33 Freq=851.475000 NAC=00A Alias server returned talker alias "ML POR4" for BEE00.1C7-68165
2025/01/23 11:59:34 Freq=851.475000 NAC=00A Alias server returned talker alias "2782" for BEE00.1C7-62036

(Note: these events occurred as DSD was starting up, but there were intermediate entries in the Events log - I omitted those)

851.4750 is the current control channel for the Worcester County L3H TRS; BEE00.1C7 is the Excelon Energy system; I'm assuming that the .1C7-6xxxx suffixes are RIDs. Question: how is the talker alias relationship to the Worcester system being derived? Is there actually a relationship, or did the program just grap talker aliases and download them based on the Excelon system's previous entry in my P25Data file? Or is somthing else going on? Is there an (undetected) ISSI connection between the two systems? Are the Excelon subscribers operating on the Worcester system at the time?

It likely went through your .radios file, saw entries for Excelon that did not have aliases, compared to them to aliases others have captured / sent to server / are stored on server, found a couple and sent them back to you.

So likely you did not have 2782, ML POR4, NTS-LAKEY and NSV 04715 before -- but you had the RIDs. Somebody else monitoring the same system sent their aliases to the server, which stored them. So when you came online you were able to benefit from getting those aliases even though you may not have copied them initially. What often happens is that you monitor radios that register/affiliate but do not key up. Thus you do not get an alias for that radio. But somebody else monitored the system, got the alias when the RID transmitted, and sent it to the server. Then you got it back from the server when (a) you had the RID in your file and (b) DSDPlus checked to see if the server had an alias for it.

 

[maus92]

It likely went through your .radios file, saw entries for Excelon that did not have aliases, compared to them to aliases others have captured / sent to server / are stored on server, found a couple and sent them back to you.

So likely you did not have 2782, ML POR4, NTS-LAKEY and NSV 04715 before -- but you had the RIDs. Somebody else monitoring the same system sent their aliases to the server, which stored them. So when you came online you were able to benefit from getting those aliases even though you may not have copied them initially. What often happens is that you monitor radios that register/affiliate but do not key up. Thus you do not get an alias for that radio. But somebody else monitored the system, got the alias when the RID transmitted, and sent it to the server. Then you got it back from the server when (a) you had the RID in your file and (b) DSDPlus checked to see if the server had an alias for it.

Understood - I did find that those radios existed previously in my .radios file. I guess my question is why does the event entry line include the control channel for an unrelated system? Is this simply DSD showing what current frequency is tuned, and unrelated to the talker alias data?

 

[mtindor]

Understood - I did find that those radios existed previously in my .radios file. I guess my question is why does the event entry line include the control channel for an unrelated system? Is this simply DSD showing what current frequency is tuned, and unrelated to the talker alias data?

You guys (maybe not you specifically) just recently melted down when that information was removed from the event log. It got added back in and now, well, you don't like it.

I understand, the frequency and NAC have nothing to do with the message. I guess ideally in that case, where it is spitting alias information into the log, it should only give a timestamp and the alias info, and not add on the currently monitored freq/NAC.

Sounds more like a bug or a "request' to make to the author. Does seem kind of strange to have the freq/nac info on the same line as alias reporting tasks that have nothing to do with the frequency that is being monitored.

mike

 

[inthesmoke]

Lots of updates coming through lately, thanks for all the work.

Can anyone point me to where I'd find 2 pieces of info?
1. What steps are required to cleanup .radios / .groups to remove erroneus data or systems not wanted? I've tried in the past and obviously done something silly as the data has reappeared. This comes because I moved state and started with an old file. (learned my lession when travelling recently and ran a separate instance.
2. A refresher on the date/time stamp and which TG a RID is listed against? First seen / last seen? I think it's first TG seen but last time Radio seen?

Thanks

 

[Reconrider]

1. What steps are required to cleanup .radios / .groups to remove erroneus data or systems not wanted? I've tried in the past and obviously done something silly as the data has reappeared. This comes because I moved state and started with an old file. (learned my lession when travelling recently and ran a separate instance.

Make sure dsdplus is shut down and then edit your file. Make a backup before editing and after editing in case it doesn't stick. After edited, start up dsd and the stuff you removed shouldn't repopulate. If it does, sometimes deleting the .bin file will fix that

2. A refresher on the date/time stamp and which TG a RID is listed against? First seen / last seen? I think it's first TG seen but last time Radio seen?

The time stamp on the RID and talkgroup files are the absolute last seen whether the radio was just turned on and registered on that TG or they actually keyed up

 

[cg]

Names and priority can be edited via the text file while running but as mentioned, to delete TGs or radios, it needs to be shut down. Edit it the way you want and save a copy, good time to make a backup.

 

[dave3825]

Every now and then I have data reappear after being deleted from groups and radios file. Always suspected it had something to do with the event file. Ever since I started deleting that before editing those files I have not seen any issues. I have not deleted the bin file in about 4 years.

 

[seagravebuff60]

You guys (maybe not you specifically) just recently melted down when that information was removed from the event log. It got added back in and now, well, you don't like it.

I guess my question is why does the event entry line include the control channel for an unrelated system? Is this simply DSD showing what current frequency is tuned, and unrelated to the talker alias data?

Yes, it was frustrating that it was abruptly removed from the event log, as the logs didn't display the proper information used for "hunting" radio systems and frequencies, which was previously very useful. I am glad it was added back quickly, so props to the author(s) for that. But I don't think that manus92 is complaining that they don't like it and is simply asking the question of "why?".

However, the alias server messages always contained unrelated info, such as the Frequency and Tone in the event log. Ive just always looked past it as it was not related to the alias server info itself but rather the system I was monitoring with that instance of DSD+. I do notice that if I have 2 Instances of DSD+ open, The alias server messages populate on both DSD+ windows (simultaneously) and, therefore, also show up in both event logs.

Here is a snippet of my event log from one of the first few days the feature was implemented:

2024/10/29 17:31:47 Freq=774.643750 NAC=B81 Alias server returned clear alias "60 Ctrl OP 5" for RID BEE00.A66-600005
2024/10/29 17:34:48 Freq=774.643750 NAC=B81 Alias server returned clear alias "Yonkers OP 2" for RID BEE00.A66-14
2024/10/29 17:34:49 Freq=774.643750 NAC=B81 Alias server returned clear alias "LLPS43" for RID BEE00.A66-20143
2024/10/29 17:34:50 Freq=774.643750 NAC=B81 Alias server returned clear alias "CAR4 P1" for RID BEE00.A66-50808

 

[inthesmoke]

Thanks for all the replies, thought it might be that simple, but might require the extra files steps.

The time stamp on the RID and talkgroup files are the absolute last seen whether the radio was just turned on and registered on that TG or they actually keyed up

Thanks. I should have articulated better. This clarifies the date/time. For which TGID the radio is shown against, does it change, or does it only get populated against the first TG that RID is seen on? And any steer on how the -2 and -1 TGs are affected in this regard as well? I understand they are for RIDs with either unknown TG or only private calls seen, not sure if they will then 'move' to another TG once they are seen there