Reverse engineering the Puxing PX888K programming format (2: Making sense of the data)

I have found out that the reverse engineering was the easy part. It should however come as no surprise, since if communications protocol and data format are simple, and they are, the whole thing becomes a iterative process of changing a single setting to a new value, and diff the old communications dump against the new, to see what bits have changed.

Using jpnevulator to listen in on the data transfer between the stock software and the radio, the program can listen to multiple serial ports at the same time, and neatly display which port sends what when. This way the back and forth between the stock software and the radio can be easily viewed and the protocol is quickly figured out. There is a short initial handshake in the beginning, followed by either reading or writing the whole image in chunks of 64 bytes.

The protocol, but just as much an image to break the text

The next step was to implement a few scripts that could play the part of the radio, but dump the memory written to an image file, instead of writing to the radio each time, and reverse engineer from the snooped data which contains the communications commands which, we are no longer interested in. The script can also read from an image file, making it possible to poke at the bits and see what changes in the stock software. Functions for reading and writing to the radio are also implemented, which is useful since the stock software does not cover all settings available on the radio. The scripts are available on github.

After a data communications failure, it also became apparent that there are features not available in the stock software I had, as well as the radio: Something went wrong and I found myself with a radio with a locked keypad. It turns out that this is a feature rather than a bug, and a newer version of the stock software includes the possibility of changing this setting. The new software version also makes the feature Relay without disable tail available, which I have no idea what it does, and I can't find it documented anywhere. The closest thing I have found when searching is that it may enable or disable Squelch tail elimination, but I don't have the equipment to test this feature currently.

Another setting that is poorly documented is Wait time which can be set to 0.3, 0.5 or any integer in the range 1-12. I do not know what it is waiting for. It does not seem to be any of backlight timeout, keypad lock timeout, or any delay regarding when PTT ID or other data signals are sent. Possibly it could have something to do with when the battery save functionality sets in, but I don't know how to test this reliably. A bit of keyword searching lead me to a French forum which hinted at, and is corroborated with my own following tests, that it is how long it waits in before it resumes scanning, when using carrier based scanning.

A bigger challenge, the "but" continuation of the "easy" in the beginning of this text is writing a CHIRP plugin. It would be easy enough to pour data between a csv file tailored for this radio, and this radio only, and the binary image would be easy. It is a different matter entirely to fit this into a system that also needs to cover how other radios work, and what their features are. But the point of doing this is to make it possible to copy settings between radios that would otherwise be each programmed by their own software platform, all incompatible with each other. I can certainly get behind that kind of endeavor. Another part is that doing this project with the goal of writing a CHIRP plugin is probably the best way to have it reach other users of this particular model and have them benefit.