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

 

[DaveNF2G]

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:

Are you running both instances in the same directory?

 

[seagravebuff60]

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

Every RID (radio) entry is sorted by TGs (groups) in the .radios file. It is sorted by the last group the radio was "seen" on. The RID record will also move according to the last TG (group) it was "seen" on. So, if RID 8675309 shows up on TGs 1 and 2, the RID record for 8675309 will switch in the radio files between TG 1 and 2, according to the last TG (group) it was "seen" on.

The -1 is only for private calls, and the -2 is for group unknown; this is for little data checks or affiliations of the RID onto the system that hasn't yet shown up on a group. I think both the -1 and -2 values should fluctuate as well, just like any other RID Entry.

Are you running both instances in the same directory?

Yes. I run all instances on a single computer from one directory

 

[inthesmoke]

Thanks, that will help me with following what's happening with all the new radios that are being deployed at the moment.

 

[VA3ADP]

I will have to install this new update and report back. However, I am not a fan of how they Have laid out the talker ID's with both found and custom entered. The Checksum is also pretty annoying but who knows, It could be to prove to be helpful in the future.

However, This may seem like a stupid question. Since the last couple of updates, I have noticed that there is no line to show what new DSD+ talker ID have been found. Is there anyway to reenable this or it just stuck like that now?

 

[maus92]

I noticed that there is a line for when new talker IDs are found in the event log - see post #2 above.

 

[mtindor]

I will have to install this new update and report back. However, I am not a fan of how they Have laid out the talker ID's with both found and custom entered. The Checksum is also pretty annoying but who knows, It could be to prove to be helpful in the future.

However, This may seem like a stupid question. Since the last couple of updates, I have noticed that there is no line to show what new DSD+ talker ID have been found. Is there anyway to reenable this or it just stuck like that now?

What's with the fascination / paranoia over the checksum? It could do a million different things. One thing I know it does it help ensure that people don't just type in their own version of an alias and have it uploaded to the server. It's primary intent is to make sure the aliases that are on the server are actually aliases from the system and not something made up by the user.

And user aliases and OTA Aliases have been beside each other ever since OTA aliases have started to be collected (starting with Harris systems I believe, before 2.5).

For the last question, I don't know what you mean. You mean a line in the Event Window / Event Log? I see notifications. They are worded differently but should be there. Ever since the decoding of OTAliases for Moto systems has been switched to being doing 100% within DSDPlus, the wording of the lines in the Event Log / Event Window are different. No lines to keep track of MotoClr, MotoPart, etc. since there is no longer such thing as a partial decode.

 

[DaveNF2G]

Yes. I run all instances on a single computer from one directory

I think that is how data can be corrupted between systems, especially on initial startup, or when scoping out new systems.

I have a directory for each established system and test directories for new discoveries.

 

[mtindor]

I think that is how data can be corrupted between systems, especially on initial startup, or when scoping out new systems.

I have a directory for each established system and test directories for new discoveries.

This is definitely true, unless one uses the particular switches required to run multiple versions from one directory. I've never done it myself.

DSD+ 2.176

Added single receiver monitoring mode. In this mode, single copies of DSD+ and
FMP24/FMPA/FMPP switch between control/rest channel monitoring and voice/data call monitoring.

Use -r1 on the DSD+ command line to enable single receiver mode.
Tune FMPx to a trunk control or rest channel to begin system monitoring.
Press C in DSD+ to switch between CC/Rest channel only monitoring (no voice/data monitoring)
and normal mode (CC/Rest/voice/data monitoring)

When -r1 is used, all communication between DSD+ and FMPx is done via TCP link;
nothing is communicated through the file system. This means that DSD+ and FMPx can be
running on separate computers on a local network or anywhere on the Internet.

In -r1 mode, multiple copies of DSD+ and FMPx can run in the same folder and share the
DSD+ data files. Each DSD+/FMPx pair can monitor different sites or systems.
Use the -F<num> file name modifier on the DSD+ command line for each additional copy of
DSD+ to avoid file naming conflicts.

Note: In single receiver mode, some extraneous entries may appear in the event and channel windows.

Note: Due to changes made to the DSD+/FMPx TCP linking protocol to support single receiver mode,
DSD+ 2.176 can only be TCP linked to updated copies of FMP24, FMPA and FMPP.