Designing a CPS data structure

posted in: DMR, Ham radio | 9

Work to develop a new CPS for DG4KLU’s open source GD-77 firmware is progressing rather slowly, because I’ve had other things to do, including fixing some bugs in the firmware.

 

But after discussing the requirements with a few people, I’ve designed this basic data structure.

I’m not sure if I’ve included all the necessary attributes of a channel, for use on both DMR and FM, but I think its probably good enough to perhaps start the CPS and firmware programming.

 

 

For those unfamiliar with database design, I’ve structure the data, each of the blocks in the diagram are called a Table.

 

The tables, which all DMR users will be familiar with are the Channel, Contact and the Scanlist.

I’ve renamed the Zone to be a channel group, because I think that the term Zone is not very applicable to Amateur Radio use, where we would be more likely to group channels by their frequency band, or their mode (DMR / FM) or some other criteria, rather than by geographical area.

However if this is a name change too far, I could easily rename the Channel Group back to Zone. Since the struture of the data would be the same regardless of the name given to groups of channels.

 

The other Table which I have renamed is the RxGroup, which I had to rename to TRxGroup, because this group will need to control both the Tx and Rx Talkgroup used by the radio.

 

I have retained the “Contact” for DMR channels, but I’ve renamed it to ChannelDMRTG, because I think this more accurately describes how Amateur Radio operators use the “Contact” field in the existing GD-77 CPS, where they normally transmit on a TalkGroup, rather than to an individual contract.

This does not rule out the DMR TG being set to a Contact which is a Private Call, so I’m still undecided about what name to give this.

 

So that the new CPS and firmware, is not constrained to a specific number of Channels per ChGroup (aka zone), I have added intermediate tables, like Channels2ChGroup.

Likewise for Channels2Scanlist, and Contacts2TRxGroup

 

The only limiting factor will be the total overall size of the database which will need to be uploaded to the radio, but since we will no longer need to duplicate the same DMR channel for every TG that is used on that channel, this drastically reduces the number of channels that are required.

So even though the GD-77 only has just over 1M byte of storage for both the codeplug and the DMR ID database, it limitation will only be on the number of DMR ID’s that can be stored.

 

Hopefully as time goes by and Talker Alias becomes better supported by other radios and networks, the need for the DMR ID database will reduce, so that the 1Mb memory in the GD-77 lo longer becomes a major limitation.

 

In fact, I’ve already started work on supporting Talker Alias display in Kai’s firmware.

 

Its possible that I have overlooked something which I need to store, so I’d appreciate any comments on both the structure, table names and also the individual items in each table.

9 Responses

  1. DetV
    |

    Roger, love your work and especially the channel/TG matrix approach here. I’m looking forward to building an All_AU codeplug for this one.

    One additional feature I would like is for a Channel Groups titled Favourites with a quick and easy method of dropping Channel/TG combinations into it.

  2. Roger Clark
    |

    Hi Det

    I forgot to mention, that in the firmware I will auto create a virtual channel group, called “All channels”, because I’ve several people have asked me for that feature.

    Re: Favourites
    I like the idea of favourites. I’ll need to get the CPS to auto create an empty group called Favourites, and add the ability in the firmware to be able to put channels into that group.
    It will just be a normal group, so that CPS will be able to put channels into (and out of that group)

    BTW.
    I’m still working out the best way to store the data on the PC’s hard disk.

    I’ve done some experiments using XML, using the DotNet built in List<> serialiser functions, and that seemed to work OK.
    But I’m now thinking that at least internally to the CPS, may be better off using SQLite, since the structure is obviously a database and DotNet seems to have built in support for SQLite.

    For upload to the radio, I’ll need to write my own custom converter / serialiser, rather than doing what the existing CPS does, which is just to send raw X86 memory blocks to the GD-77, which is a pain to handle on the firmware side, since the byte order is the wrong way around, and the firmware has to process every element of data before it can be used.

    Actually, just to add to the confusion the existing CPS uses Binary Coded Decimal (BCD) to store the data, so the conversion from CPS format to a usable number e.g. for the frequency, takes some processing.

    The correct way to do this is of course to make sure the CPS creates data in a firmware friendly format, so that the little CPU in the radio does not have to do any heavy lifting.

  3. ken
    |

    thank you for the update

  4. Anonymous
    |

    Hi, might you soon have a version that’ll work for USA amateurs??

  5. Roger Clark
    |

    It seems that every country, district and network seems to have different requirements

    For Brandmeister through my hotspot, or potentially through a repeater, I just need 1 channel and lots of different TG’s so I normally just manually enter the TG, into my GD-77 which is running the version of the official firmware which I modified to have TG entry

    For the local repeaters on DMR MARC, its pretty much the same, except since there is a small list of TG’s that they support, so TG entry isn’t essential, but I still tend to use it.

    But I’ve no idea what is needed elsewhere in the world.

  6. Guillaume
    |

    Hi Roger,
    I believe it would be interesting to add a “parent channel” table where you set the frequency(frequencies if RX/TX different), Colour Code, etc.
    Thereafter if you need to change the QRG/CC of a repeater/hotspot, you do it only once…
    This is because it would be quite common to create multiple channels in a zone, all using the same “parent channel” but with a different TG.
    Cheers,

    G

  7. Roger Clark
    |

    With the OpenGD77 firmware we have taken a different approach which seems to work equally well.

    The firmware uses the Rx Group as both a Rx and a Tx Group. So the repeater frequency only needs to be entered as 1 channel and all the TG’s used on that repeater are assigned to a Rx Group (aka TG Group), which is assigned to the channel.

    The firmware uses the right and left keypad keys to cycle through all the TG’s assigned to the frequency, and the up and down arrows to change channel (like normal)

  8. Anonymous
    |

    Sure thing. I do not own a GD77 and was just thinking databse. Of course, scrolling through a list of contacts/TGs when you are on a channel makes perfect sense as long as the listen RX list is long enough.
    Good continuation,

    Guillaume

  9. Roger Clark
    |

    Yes.

    I agree for normal radios the best way would be to have a separate Parent channel

    Or perhaps have some system, where the “channels” in the codeplug are auto generated from the Parent channel and the TG group

Leave a Reply