Adding a new radio

[grahammpg]

What are the high level steps for adding a radio ? I'm interested in my Yaesu FTM-300D and my Baofeng UV-5RA.

[hmatuschek]

These both are pure FM radios. Chirp might be the better option.

[grahammpg]

This is at odds with the general goal of the qdmr project: "to have a tool that works for a wide spectrum of radios". But I see a problem in that. The code contains modules for individual radios. As the number of radios grow, the size of the code base will grow in proportion.
I think that revising the architecture to be data driven where there is a text file that guides the code to work for each individual radio. This makes it possible to cover more radios with a smaller code base.
I hope to do a code analysis where I can suggest how the architecture can be changed and reuse significant parts of the current base. If you and the other developers think that this approach has merit, I may be able to assist. I'm retired now, but in the past worked on trading software for a major exchange. I learned techniques that allow fast switching through multiple code paths in C++ and Java.
The code I see looks very good, very well structured. I see that a lot of work has gone into building this project.
Mike G.

[hmatuschek]

I agree, I would be great to have a kind of code-plug description language and some transformation rules that translate some abstract configuration to the binary formats. In fact, for simple fields I already did this. There is a codeplug documentation tool that uses an XML file to describe the pattern in each codeplug (https://github.com/dmr-tools/codeplugs, see also generated docs at https://dmr-tools.github.io/codeplugs) and there is a tool do edit these files, emulate radios via the serial port and decode the codeplugs based on this description.

Concerning the trivial configuration of FM radios, this is all that is needed. Encoding a flat table of strings, frequencies, numbers and flags. Unfortunately, the DMR codeplugs are way more complicated. They are not a simple flat table. They are more or less relational databases even including weird indices some times. Of cause, some underpayed Chinese embedded systems engineer wrote the firmware. So expect every best-practice of software engineering to be ignored and a lot of inconsistencies within a single codeplug. I also want to provide a common abstract codeplug structure for all devices. This way you can transfer (at least the majority of) the codeplug of one device to another device. So I need a full fledged compiler with intermediate representations and every device is basically a different target platform for that device.

To achieve this, a simple description language is not sufficient. I need something Turing complete. On option might be to design a domain specific programming language to implement these transformations. This would be the most compact solution. I can have a purely descriptive part for simple flags and fields (names, frequencies) and a programming part for assembly, linking relations and implementing indices. Designing and implementing this language is tricky and a huge undertaking.

What I basically did: C++ provides the latter part easily. However, it is a bit verbose, when it comes to the descriptive part. I tried to exploit the language as much as possible to turn it into a codeplug field description language. There are still a ton of boiler plate code needed though.

[grahammpg]

Thank you for your reply. I'm new here and lack knowledge about radio transfer protocols.
Do you have a calling tree document for qdmr? If not I'll construct one on my own.

[hmatuschek]

There is no calling-tree in the API documentation https://static.dm3mat.de/qdmr/libdmrconf/. However, you can generate it yourself using doxygen. You may need to alter the build flags to get a calling-tree. see doc/CMakeLists.txt.