7 digit Talkgroup resolving as user DMRID

[m0guy]

Hello,

when using a 7 digit Talkgroup the pi-star appears to be performing a lookup and presenting back the DMRID callsign..

Screenshot 2020-10-23 at 10.28.03.png (19.52 KiB) Viewed 2856 times

I keyed up a Group call on 5026001, which just also happens to be a match in the DMRID database for 9W2LHX.

As this is a group call I don't think Pi-star should be trying to perform this lookup. It should only lookup for private calls.

Thanks
--Guy

[AF6VN]

From https://wiki.brandmeister.network/index ... of_America

Creation of Talk Groups

Talk Groups are only labeled for 3, 4 and 5 Digit IDs. Due to the limited number of 5 Digit IDs available we are no longer labeling any new requests for 5 digit talk groups at this time. Please use your Radio ID (7-digit) or if you have a repeater your Repeater ID (6-digit) as your talk group. Although the 6 and 7 digit IDs will not be labeled they can be used immediately without Master Admin Approval. (in the new API, no release date at this time, repeater sysops will have the ability to label their 6-digit repeater ID in the repeater dashboard.)

So -- at least for BrandMeister, a 7 digit "talk group" is assumed to be using an individual's personal ID, and having such a call sign look-up makes sense. One can not just randomly plug in any 7 digit number and assume it won't interfere with an individual ID.

[G8SEZ]

The death of the 4xxx reflectors on BrandMeister is to free up additional talk groups but ultimately I don't know how they will cope with future expansion.

[M1DNS]

Hello,

when using a 7 digit Talkgroup the pi-star appears to be performing a lookup and presenting back the callsign

I keyed up a Group call on 5026001, which just also happens to be a match in the DMRID database for 9W2LHX.

Thanks
--Guy

As mentioned above, dont go pulling random 7digit ID's out the either. Each 7digit ID will be linked to a personal ham callsign.

If you require a tg for ur own 'group' use, use your own call ID.

Sent from my SM-G935F using Tapatalk

[m0guy]

Hello,

when using a 7 digit Talkgroup the pi-star appears to be performing a lookup and presenting back the callsign

I keyed up a Group call on 5026001, which just also happens to be a match in the DMRID database for 9W2LHX.

Thanks
--Guy

As mentioned above, dont go pulling random 7digit ID's out the either. Each 7digit ID will be linked to a personal ham callsign.

If you require a tg for ur own 'group' use, use your own call ID.

Sent from my SM-G935F using Tapatalk

I'm running a completely independent and private DMR service. I'm making no connection to Brandmeister or Phoenix or indeed anything else. I'm using the pi-star as the access points. I picked the high numbers to be clear of any Brandmeister Talkgroup.

I still do not see why pi-star is trying to lookup the talkgroup number and put a callsign to it. The number is the Talkgroup number and I believe shouldn't try and be matched against anything. Otherwise why doesn't 91 or 235 or anyother talkgroup number get rewritten to it's name? Doing it for some another others makes it inconsistent.

[KN2TOD]

I don't think Pi-Star is doing the lookup - it's the MMDVM firmware that's doing it. The firmware loads the DMRids file at startup and then uses it to format the messages as traffic comes in - Pi-Star merely scans those messages and displays what it finds in the dashboard.

Test: in addition to the 5026001 id you're using, try 5026000 and then check the logs: you should see the -6000 id but not the -6001 id midst all the messages.

[KN2TOD]

Its not "pi-star" that is doing the lookup, its the dashboard php code.

Can you cite the file and line number in the PHP code where this lookup is occurring? My testing shows the MMDVM is doing the lookup:

HS #5 dashboard 2.jpg (29.72 KiB) Viewed 2753 times

HS #5 log.jpg (86.14 KiB) Viewed 2753 times

[KN2TOD]

From what one can see, it's the MMDVM process (either the firmware or software interfacing with the firmware) that is creating the info written in the log files and includes a look up task utilizing pre-loaded data. In any case, none of the PHP code is doing such lookup's. Scrapping the logs, yes, but no lookups.

HS#5 MMDVM log.jpg (132.72 KiB) Viewed 2740 times

HS#5 MMDVM config.jpg (64.85 KiB) Viewed 2740 times

[m0guy]

Ok I've done some more digging..

The pi-star web page is getting the data from /var/log/pi-star/MMDVM-<DATE>.log file

This log file is written by the MMDVMHost process which is running on the pi-star.

This MMDVMHost process performs the lookup in the DMRSlot.cpp file:

std::string dst = m_lookup->find(dstId);

This is just being passed the Talkgroup number and checking to see if it's in the current copy of the DMRID.dat file.

I still do not think it should be looking up the destination, I don't really see that it makes sense.. In my dashboard I'll see the users call sign, but I'll then have to look the Talkgroup number up if I want to use it again later (If it's not programmed in the radio).

The target _is_ a number and should remain as such.

I would also point out that 99% of the time this lookup is not going to result in a positive response, so it's wasting CPU time performing a lookup which will likely fail. On a Pi-zero CPU time is at a premium.

[KN2TOD]

Great research, Guy!!!

I agree about the lookups: the Target field/column in the dashboard is a mixed bag/grab bag of info, depending on the mode involved and whether its a RX or TX entry. So maybe in certain situations, a lookup should not be done, the underlying data treated differently. The logic for the lookups was probably written a while ago and obviously things have changed (morphed) and/or been extended in various ways beyond what was originally intended.

So the question then is: can the code be modified to handle your situation? And who would/can review that process and make those changes? And ... would it require modification of the firmware that's spitting out the raw data in the first place? (Rhetorical questions, I know.)

Time will tell.

BTW, I'm assuming this is the "process" we're talking about, no?

HS #5 MMDVM process.jpg (38.29 KiB) Viewed 1780 times