Bigger (or better) DMR ID Database
Posted: Sat Feb 19, 2022 5:25 am
Hi, Roger, Daniel and developers. I have an idea about how to give OpenGD77 a bigger DMR ID database. Forgive me if you have already thought of it or it's not feasible. I'm not a programmer myself, but maybe I know enough to be dangerous
In CPS, create a list of all unique first names in the desired subset of the full DMR database, and assign each name an integer. A two-byte unsigned integer can define 65,536 names, more than enough. Then in the radio, store the appropriate integer in each DMR database record, rather than the name. Also store a name lookup table in the radio. That way, we store each unique first name only once. The lookup table could be an array of fixed-length names with the integer as a pointer to the appropriate name. Or the names could be variable length, and the integer could tell the radio how many end-of-record characters to count to find the appropriate name. Which method to use is probably a speed/size tradeoff.
Another idea: Is it possible to download, somewhere, a CSV file that has "last heard" information in it? If CPS could handle that, we could set it to only load IDs to the radio that have been heard in the past n days--n being user-specified. We could then adjust n so the resulting list would fit in the radio.
These ideas might help those of us who don't have the necessary skills and equipment to transplant larger-capacity surface mount chips into a handheld. Meanwhile, we all should be pestering the powers-that-be, particularly the MOTO-TRBO people, to implement talker alias as a general DMR ID to callsign/name standard. Or something else that everyone can live with. Memory is finite, the DMR list keeps growing, and nothing can grow indefinitely without eventually hitting the ceiling. Eventually, "the network," whichever one we're on, is going to have to handle ID to callsign translation.
73,
--Peter, KD7MW
In CPS, create a list of all unique first names in the desired subset of the full DMR database, and assign each name an integer. A two-byte unsigned integer can define 65,536 names, more than enough. Then in the radio, store the appropriate integer in each DMR database record, rather than the name. Also store a name lookup table in the radio. That way, we store each unique first name only once. The lookup table could be an array of fixed-length names with the integer as a pointer to the appropriate name. Or the names could be variable length, and the integer could tell the radio how many end-of-record characters to count to find the appropriate name. Which method to use is probably a speed/size tradeoff.
Another idea: Is it possible to download, somewhere, a CSV file that has "last heard" information in it? If CPS could handle that, we could set it to only load IDs to the radio that have been heard in the past n days--n being user-specified. We could then adjust n so the resulting list would fit in the radio.
These ideas might help those of us who don't have the necessary skills and equipment to transplant larger-capacity surface mount chips into a handheld. Meanwhile, we all should be pestering the powers-that-be, particularly the MOTO-TRBO people, to implement talker alias as a general DMR ID to callsign/name standard. Or something else that everyone can live with. Memory is finite, the DMR list keeps growing, and nothing can grow indefinitely without eventually hitting the ceiling. Eventually, "the network," whichever one we're on, is going to have to handle ID to callsign translation.
73,
--Peter, KD7MW