DSDPlus Fastlane errors

[Red_Ice]

I don't know if all of us who use this magnificent decoding tool have realized some errors that have been made when analyzing networks and sites.

The first of them is related to the naming of area.site, I think they have tried to correct this failure, the ETSI tells us that depending on the type of network a total of 10 bits will be used for the Huge model, 8 bits for the Large model , 5 bits for the Small model and 3 bits for the Tiny model for the site naming. On the contrary, the DSD+ and DSD+ Fastlane use a certain number of bits for the area, leaving the last three for the site in the first three models and 2 bits for the Tiny model.

What was expressed in the previous paragraph seems that they have tried to solve it since in my events window the sites named as indicated in the ETSI appear, however, they have made other types of errors that I did not see previously.

To explain it I will use these three examples:

If I take the first example as a basis, I note that the SysCode is 11.00.0001111100, this means that I am looking at a Huge type network model:



11.00.0001111100

Network Huge Type: 11 -> H

Network ID: 00 -> 0 + 1 = 1

Site: 0001111100 -> 174 or according to DSD+ 15 + 1 (16) for the area and 4 + 1 (5) for the site

In this case I think it is correct to add 1 to both the id and the area and the site, so what is indicated by the ETSI should also be added 1, since no one starts counting at zero, even if it is used in programming to indicate the first value or the first character or the first record…

In the second example we already found these contradictions or errors, we will look at a SysCode with the same network model, specifically 11.01.0000001101, in the image you can see that they use the ETSI nomenclature:



11.01.0000001101

Network Huge Type: 11 -> H

Network ID: 01 -> 1, if the usage rule of the previous example is applied it would be 1 + 1 = 2

Site: 0000001101 -> 13, if the usage rule from the previous example is applied it would be 13 + 1 = 14

In the third example, a network has been presented again according to the DSD+ nomenclature, it is a Large network model with a SysCode equal to 10.0000.00011111:



10.0000.00011111

Large network type: 10 -> L

Network ID: 0000 -> 0 + 1 = 1

Site: 00011111 -> 31 or according to DSD+ 3 + 1 (4) for the area and 7 + 1 (8) for the site

My intention is not to criticize this tool or those who have created it, but to clarify or ask that a single model be developed for the naming of networks and sites, as I have always said, I don't care if they call me by my nickname or by my name as long as when they do it they know that it is me who they are calling, but in the case at hand, it would be good if we all spoke a single language, that we named these networks and sites in a single way so that we can understand each other among all, thank you all.

 

[mtindor]

I don't know if all of us who use this magnificent decoding tool have realized some errors that have been made when analyzing networks and sites.

The first of them is related to the naming of area.site, I think they have tried to correct this failure, the ETSI tells us that depending on the type of network a total of 10 bits will be used for the Huge model, 8 bits for the Large model , 5 bits for the Small model and 3 bits for the Tiny model for the site naming. On the contrary, the DSD+ and DSD+ Fastlane use a certain number of bits for the area, leaving the last three for the site in the first three models and 2 bits for the Tiny model.

What was expressed in the previous paragraph seems that they have tried to solve it since in my events window the sites named as indicated in the ETSI appear, however, they have made other types of errors that I did not see previously.

To explain it I will use these three examples:

If I take the first example as a basis, I note that the SysCode is 11.00.0001111100, this means that I am looking at a Huge type network model:

View attachment 152355

11.00.0001111100

Network Huge Type: 11 -> H

Network ID: 00 -> 0 + 1 = 1

Site: 0001111100 -> 174 or according to DSD+ 15 + 1 (16) for the area and 4 + 1 (5) for the site

In this case I think it is correct to add 1 to both the id and the area and the site, so what is indicated by the ETSI should also be added 1, since no one starts counting at zero, even if it is used in programming to indicate the first value or the first character or the first record…

In the second example we already found these contradictions or errors, we will look at a SysCode with the same network model, specifically 11.01.0000001101, in the image you can see that they use the ETSI nomenclature:

View attachment 152356

11.01.0000001101

Network Huge Type: 11 -> H

Network ID: 01 -> 1, if the usage rule of the previous example is applied it would be 1 + 1 = 2

Site: 0000001101 -> 13, if the usage rule from the previous example is applied it would be 13 + 1 = 14

In the third example, a network has been presented again according to the DSD+ nomenclature, it is a Large network model with a SysCode equal to 10.0000.00011111:

View attachment 152357

10.0000.00011111

Large network type: 10 -> L

Network ID: 0000 -> 0 + 1 = 1

Site: 00011111 -> 31 or according to DSD+ 3 + 1 (4) for the area and 7 + 1 (8) for the site

My intention is not to criticize this tool or those who have created it, but to clarify or ask that a single model be developed for the naming of networks and sites, as I have always said, I don't care if they call me by my nickname or by my name as long as when they do it they know that it is me who they are calling, but in the case at hand, it would be good if we all spoke a single language, that we named these networks and sites in a single way so that we can understand each other among all, thank you all.

Aren't TIII systems fun? You forgot to mention the tricky LA (area length), that seemingly is not transmitted over the air or contained in the SysCode, but very significant for determining proper Area.Site information.

And my understanding, which may be flawed since I have no access to CPS and am not a programmer, is that TIII MOT (Motorola Capacity Max) systems do not use an Area ID. And it is my understanding that they do not require the +1 action because the SysCode information makes sense (and doesn't result in Areas or Sites with a 0 if you do not add +1). If DSDPlus realizes that the system is a CAPMAX system, it handles it differently.

Aside from CAPMAX systems, I think DSDPlus handles most if not all other TIII systems by assuming AreaID + Site ID exist and that +1 is needed for those values contained in the Syscode.

Of course, as mentioned before, the apparent lack of the LA being transmitted over the air means that you can't get the AreaID + SiteID correct 100% of the time. You can do some educated guessing, and sometimes it can be absolutely clear what those values are, but other times you might have a choice of 4 or 5 different AreaID+SiteID combinations based upon the transmitted SysCode.

Then, throw in a system like Selex / Leonardo ( search here for: Goosetown Tier III ). It is not a CAPMAX system, but it does not use an Area ID and does not require +1'ing the bits in the Syscode. Unfortunately, there is no OTA information sent that allows DSDPlus to distinguish that it is a Selex system, so DSDPlus presumes its a DMR TIII Standard system and shows AreaID+SiteID and +1's the bits.

I agree, after a few years of seeing TIII systems now, that it would be better to never present the AreaID+SiteID information for a system -- and instead they should be presented as just a model, network ID, and SIte ID. But, I have a feeling DSDPlus would require a significant revamp to do this, and would then require everyone to change how they present aspects of a TIII system in the DSDPlus.* files.

But let's assume that miraculously every piece of software was on the same page using Network Model, Network ID, Site ID. There is still the issue of any software knowing precisely when a SysCode is not presenting "the facts", for every TIII system variant, and thus needing to be +1'd.

I don't think any software developer is every going to get DMR TIII (including all variants -- standards compliant, Capmax, Selex, etc) 100% all the time because we do in fact know that in the DMR TIII standards there is actually an Area ID and a Site ID, and that there is a very important variable (LA -- length of Area) that is not sent over the control channel / not sent in the SysCode information -- there making it impossible to get the Area ID + Site ID combination correct 100% of the time.

M

 

[Red_Ice]

Aren't TIII systems fun? You forgot to mention the tricky LA (area length), that seemingly is not transmitted over the air or contained in the SysCode, but very significant for determining proper Area.Site information.

And my understanding, which may be flawed since I have no access to CPS and am not a programmer, is that TIII MOT (Motorola Capacity Max) systems do not use an Area ID. And it is my understanding that they do not require the +1 action because the SysCode information makes sense (and doesn't result in Areas or Sites with a 0 if you do not add +1). If DSDPlus realizes that the system is a CAPMAX system, it handles it differently.

Aside from CAPMAX systems, I think DSDPlus handles most if not all other TIII systems by assuming AreaID + Site ID exist and that +1 is needed for those values contained in the Syscode.

Of course, as mentioned before, the apparent lack of the LA being transmitted over the air means that you can't get the AreaID + SiteID correct 100% of the time. You can do some educated guessing, and sometimes it can be absolutely clear what those values are, but other times you might have a choice of 4 or 5 different AreaID+SiteID combinations based upon the transmitted SysCode.

Then, throw in a system like Selex / Leonardo ( search here for: Goosetown Tier III ). It is not a CAPMAX system, but it does not use an Area ID and does not require +1'ing the bits in the Syscode. Unfortunately, there is no OTA information sent that allows DSDPlus to distinguish that it is a Selex system, so DSDPlus presumes its a DMR TIII Standard system and shows AreaID+SiteID and +1's the bits.

I agree, after a few years of seeing TIII systems now, that it would be better to never present the AreaID+SiteID information for a system -- and instead they should be presented as just a model, network ID, and SIte ID. But, I have a feeling DSDPlus would require a significant revamp to do this, and would then require everyone to change how they present aspects of a TIII system in the DSDPlus.* files.

But let's assume that miraculously every piece of software was on the same page using Network Model, Network ID, Site ID. There is still the issue of any software knowing precisely when a SysCode is not presenting "the facts", for every TIII system variant, and thus needing to be +1'd.

I don't think any software developer is every going to get DMR TIII (including all variants -- standards compliant, Capmax, Selex, etc) 100% all the time because we do in fact know that in the DMR TIII standards there is actually an Area ID and a Site ID, and that there is a very important variable (LA -- length of Area) that is not sent over the control channel / not sent in the SysCode information -- there making it impossible to get the Area ID + Site ID combination correct 100% of the time.

M

I totally agree with your assessment, the main problem is that the DMRLA is not transmitted over the air and if we take into account that in a Huge network model we can set up up to a total of 1024 sites, it is difficult for these sites to be repeated in our relatively close area, this is not my case, in my area there are two Huge networks and this is where the problem appears, one with an id 00 and another with an id 01 and both are shown to me as H1, with respect to the area it is important to know What system are we capturing since, in fact, it is not always a CAPMAX system.

I think that even though it is difficult due to the variety of systems that exist, the Fastlane developers should try to unify as much as possible when naming these networks/sites.

 

[mtindor]

I think that even though it is difficult due to the variety of systems that exist, the Fastlane developers should try to unify as much as possible when naming these networks/sites.

I think there is some validity to what you'd like to see done. However, I'm not sure if it would ever be done. It may just take way too much massaging of code / revamping of the users' DSDPlus.* files, and may result in a huge support nightmare for the author(s) if they were to do that.

To be fair about this (in case others do not realize it), the author(s) of DSDPlus have gone out of their way to attempt to more accurately portrait the various DMR TIII systems out there. GRE/Whistler scanners can't tell the difference and don't truly trunk track and maybe can't even handle TIII. Uniden scanners can't tell the difference between 100% standards compliant TIII systems and variants like CapMax and Selex. Uniden treats them all the same. SDRTrunk appears to treat them all the same (taking in no account for Area ID+Site ID or +1'ing), but I may be wrong about that -- there may be circumstances where SDRTrunk does +1'ing . I do not use it enough to know. And for anything else handling TIII, I'm pretty sure they aren't attempting to display AreaID+SiteID. So in my mind, personally, I think DSDPlus has gone above and beyond to "try" and get it right. Unfortunately, given the fact that some systems actually do have an AreaID and SiteID but we are not privy to the DMRLA, this can't be a 100% correct determination every time. Plus, not every system sends a proper MFID nor does every system send something only characteristic to that specific vendor OTA so that the various software can differentiate.

The question is, how does one put the cat back in the bag? How does one justify the development cost (time / effort / money) of doing so? How does one justify the likely need for users to then turn around and change how they've set these sites up in there DSDPlus.* files. I don't write the software and thus certainly can't "lay that burden" on the hands of the author(s). Would it be nice if there were more consistency -- yep. But I don't know if there ever will be. And if there never is, I'll still continue to use whatever application suits my need at the time and adjust for the differences. I use DSDPlus for sleuthing 100% of the time, monitoring for much of the time. But I also love SDRTrunk and use it as well.

I'm glad you raised the issue though. I mean I'm not sure the general public realizes that there are differences in the various vendor implementations themselves that really cause all of this grief to begin with.

 

[Red_Ice]

Yes, what you propose is totally logical and normal, as you indicate, each of us uses the means that we find at our disposal, although I have raised this problem, I have it solved for my area with small apps that feed on the Fastlane log to show it to me according to my needs.

 

[DaveNF2G]

A utility could be written to do the conversion of the support file contents into any required new formats. I'm not saying it would be easy, but plenty of data format converters already exist, so the task is not impossible.

 

[Red_Ice]

As mtindor indicates, it is a difficult task because you have to change not only the structure, but also the DSDPlus.networks and DSDPlus.sites files of the users of this tool; this task would lead to more than one person protesting.

With this thread I have suggested that for the next modifications we try, as far as possible, to unify the naming of the networks and sites, I am not saying area since it is not transmitted over the air and poses other types of problems.

It is true that many people, like me, adapt with small apps adapted to each person's needs, as is my case. Apps of this type, which, as I have expressed, are adapted and created according to needs and not as a general rule.

 

[slicerwizard]

in my area there are two Huge networks and this is where the problem appears, one with an id 00 and another with an id 01 and both are shown to me as H1

Because they both are using network ID 1. System installers have no imagination. Go figure!

it is important to know What system are we capturing

Then use the network prefix feature that DSD+ provides to disambiguate. Done and done.

 

[DaveNF2G]

As mtindor indicates, it is a difficult task because you have to change not only the structure, but also the DSDPlus.networks and DSDPlus.sites files of the users of this tool; this task would lead to more than one person protesting.

With this thread I have suggested that for the next modifications we try, as far as possible, to unify the naming of the networks and sites, I am not saying area since it is not transmitted over the air and poses other types of problems.

It is true that many people, like me, adapt with small apps adapted to each person's needs, as is my case. Apps of this type, which, as I have expressed, are adapted and created according to needs and not as a general rule.

View attachment 152361

Google cannot find this program.

 

[Red_Ice]

Google cannot find this program.

It is logical that you cannot find it, it is a tool that is under development and is personalized, for example, in the US thousands are separated with a comma and decimals with a point, while in Europe it is the other way around, these types of conditions They must be taken into account for localization, if it is done through Google the American system will have to be followed even if it is in Europe, on the other hand, if the Google dll is used for apps in Europe the European system will have to be followed. It also influences, in this case, what information and how you want to receive, as I said, it is a personalized tool and therefore not available on Google.

 

[DaveNF2G]

Most of what you said seems irrelevant to my comment. The answer to that appears to be that Channel Extractor Pro is not publicly available. Is that what you meant to convey?

 

[Red_Ice]

As I said, it is in development and at the moment it will not be public