[Proposal] 80 Channels per zone

[VK3KYY]

Now that zone scanning is possible, the existing 16 channels per zone is obviously not idea

The optimum system would be to have dynamic length zones, but this would need a big change to the way the CPS works, which would be a lot of work.

However a more simple change to the CPS, which I can make fairly easily is to change the CPS Zone structure from 250 Zones each of 16 Channels to 68 Zones each of 80 Channels


The problem with any change like this is backwards compatibility and updating of existing codeplugs.

Radioddity made a similar change to this over a year ago, when they increased the number of Contacts per Rx Group, but reduced the total number of Rx Groups.
Radioddity did not provide a method to update the codeplug, but I was able to do a 1 way upgrade in the CPS if the CPS detected a possible old style codeplug was being loaded.


The firmware would also need to somehow detect that this is a new style codeplug, but I think this may be easier as the beginning of the codeeplug data seems to have the text

Code: Select all

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  4D 44 2D 37 36 30 50 FF FF FF FF FF FF FF FF FF  MD-760Pÿÿÿÿÿÿÿÿÿ

And it may be possible to use some of the byes after the MD-760 to indicate the version number.

e.g. Change the byte after the P to 0x00 to indicate GD-77 codeplug version 0

Of course new format codeplugs would confuse the official firmware but the most likely problem would be that you'd see a load of zones with nonsense names.

[VK3KYY]

I've now got 80 Channels per zone working in the CPS and the firmware, however this is currently 'hard coded', i.e the firmware only works if the zones have 80 channels

But I think it should be possible to modify the firmware so that it supports both 16 channels and 80 channels per zone , it will just take a bit more work.

With the CPS, it will not be practical to be able switch between 16 and 80 channel zones because of the way the CPS was originally written by Radioddity
So this would require a different version of the CPS for the new Zone structure.

But I should be able to do an automatic upgrade of codeplug to the new format.

While I'm changing the CPS, is it worth changing the Scan lists to hold more Channels per list or change the number of Contacts in each Rx Group (currently 32 TG's per Rx Group, which seems enough to me )

[footloosejava]

Scan lists are 64 lists * 32 channels.
Why not just make it the same,and add them as extra zones?

Say I'd like to say, maybe 25 lists of 80 channels.

Consider them all as Zones, for total ~93 zones roughly and 80 channels each.

Then ... maybe in the Channel, one zone is the 'Zone' and another Zone can be the Channel Specific Scan Zone (same as old).

And still a crazy idea, there are only 10 bits for each channel index. For each Zone index, the channel top 6 bits of each channel index could be flags so that the entire channel data doesn't need to be loaded on scan function for 'skip' status and any other data that can determine outcomes very quickly. Sorry, still on the 10 bit brainwave (and it can just be masked so that it remains forward/backwards compatibility).

I like the 80 channels per zone. That's really great.

[VK3KYY]

I don't know if there is much point doing anything complicated

The total number of channels that can be in Zones is currently 16 * 250 = 4000
Which is almost 4 times the number of Channels

I think 60+ zones is plenty

[KC7RBW]

If there's a way to indicate that the codeplug is either stock or some version of OpenGD77, the code could be organized to have load / save routines specific to each format. Then we could experiment with whatever data layout we'd like to try without breaking anyone. May even be able to do it in a way that will tell the stock firmware or stock CPS not to try to load the data it won't understand.

Something like that will be important when we get into fancy things like compressing names anyway.

[VK3KYY]

I don’t know if there is a version number , of the codeplug format, in the codeplug.

But I think there is likely to be somewhere which the official version leaves as initialised bytes and stay at 0xFF hexadecimal which we may be able to use as a codeplug version number