@ Skip,
? The more I think it thru, the more I think making a look up table for all standard PLs and DPLs is overall a better plan anyway.
Initially it will be labor intensive to builds them. Giving each item a static location, and uniformly referencing them via byte 7 in the mode byteset is a more reliable and untimately probably going to be easier to implement codewise.
It also solves the problem of shuffling and orphaned data the RSS insists on leaving behind.
I still have one idea on how to keep PL/MPL from untimately colliding, but I havent run any tests yet.
I didnt take the byte 7 pointer values testing all the way to FFh, but I dont see why it wouldnt continue to work beyond what I did test.
If 64 modes are to be allocated in a 2k codeplug, there is only enough room left for 64 unique PL/DPL byte sets. If so this method will require an 8k configuration to create a table with all standard (ATM, I dont know how many there are)PL/DPL values.
Another advantage is the PL calc algo can be used to alter the mode one/FPP function, and write non standard frequencies if desired to the static MPL locations for operator use across all modes.
To keep from unintentionally overwriting PL data, using the OEM MPL setting limits it to 16 non standard frequency based selections, but how many custom PL frequencies does one really need?
I also have an idea on how to dynamicly link/daisychain user generated scanlists or in scanner speak, banks. Doable, but the Pico coding and UI to do it is definately next gen and beyond where we are trying to get to ATM.
