Please add support for AT-D878UV2

[g0hww]

It would be great if you could add support for the newish Anytone AT-D878UV2. D878UV2 is the name of the unsupported device displayed by qdmr when I attempt to connect to the radio with qdmr v0.7.3. This is also known as the AT-D878UVII.

[hmatuschek]

This is likely an easy task: I am able to emulate this radio and can trick the CPS to happily write codeplugs into the emulation. All I needed was the ID, the radio "D878UV2" sends to the CPS. With this I'll verify and extend the D878UV codeplug to match the D878UVII codeplug.

Could you do me a favor? Could you compare the handbooks of the D878UVII and D878UV regarding the features of these radios. I've already found the increase of call-sign DB to 500k entries and the additional APRS-RX option.

I've created a branch called "d878uv2" where I will develop the support. Once complete, I'll merge it into the master branch. If you want to test it you can checkout the d878uv2 branch.

[g0hww]

Actually, it seemed that there was a non-printable character in the displayed string after the "D878UV2x" (where I put the "x" in that example). The character was rendered as an empty square. That may be significant.

[hmatuschek]

This is a tiny bug. This char encodes which frequency bands are enabled on the radio and it should not be displayed.

[g0hww]

OK, cool. I will compare the manuals over the next day or so. Thanks.

[g0hww]

Hmm. It seems that the pdf file named "Manual AT-D878UVII PLUS_A7-210316.pdf" claims to be the manual for the "AT-D878UV", the "AT-D878UV PLUS", the "AT-D878UVII" and the "AT-D878UVII PLUS".

I will carefully read though it (obviously I have not RTFM yet) and note anything that pertains specifically to the model 2.

[g0hww]

Out of curiosity, I have already tried your new branch! It detects and reads the code-plug from the radio (created with the original CPS in a Win10 VM) and the result looks OK at a quick glance. I haven't tried anything else yet, but then I have only got as far reading the CP out of my OpenGD77 rig too.

[hmatuschek]

Was there an issue with the OpenGD77 radio?

I would not be surprised if qdmr is already able to write a working codeplug. However, at lest some setting would be lost for sure. Qdmr tries to be a model independent CPS. Hence, I only support the most basic settings. Everything else is kept as it is. When qdmr writes a codeplug, it first downloads the current one, updates it and then writes the updated codeplug back to the device. This way I do not need to implement every tiny setting for each radio.

[hmatuschek]

I've found 4 memory regions that I do not know. The rest remains the same.

[g0hww]

I did not experience any issues with the GD77 running OpenGD77 and qdmr. I had no need to edit and upload the codeplug when I tried qdmr for the first time, which was during the OpenGD77 project's recent turbulent period, now fortunately resolved. I am more likely to update the firmware in that radio than to edit the codeplug, and I haven't really looked into using linux native tools for handling that yet.

The manual PDF that I am looking at now seems to have deltas in the text highlighted in red with the rest of the text in black so most insertions are easy to spot. Other than the sections that document additional menu options the main reference to physical changes in the new model is a feature table

Model Name D868UV D878UV D878UV PLUS D878UVII D878UVII PLUS
Included GPS GPS GPS & BT GPS GPS & BT
Top P3 button Red Blue Blue Green Green
Analog APRS TX No Yes Yes Yes Yes
Analog APRS RX No No No No Yes
Digital APRS TX Yes Yes Yes Yes Yes
Digital APRS RX No Yes Yes Yes Yes
Air band RX No No No No No
Memory IC capacity 0.5G 1G 1G 2G 2G
Digital Contact 200000 200000 200000 500000 500000
Firmware/CPS D868UV D878UV D878UV D878UVII D878UVII

followed by the note:

D878UVII / D878UVII PLUS has bigger Memory IC capacity with 500K digital contact, the firmware/CPS is NOT compatible with D878UV.

I shall summarise the marked deltas in the manual in a subsequent comment.

[g0hww]

4.2 Programmed Key

ARPS Send Manually transmit the APRS at the current channel.

7.7 Settings

(8) TOT (Transmitter Out Timer) Predict With the "TOT Predict" function activated (On), 5 seconds before the TOT expiring, a beep sound is preventing that soon the transmitting mode will be interrupted.

(9) TxPow ALC (Automatic Level Control) With the“TxPow ALC” function activated (On), while receiving extremely strong signal, the TX power will automatically reduce the level of the TX Power proportionally to the strength of the RX signal.

(18) CH Color A Set color for the band A channel display. (19) CH Color B Set color for the band B channel display. (20) Zone Color A Set color for the band A zone display. (21) Zone Color B Set color for the band B zone display.

(34) Fix Time Mute With the “Fix Time Mute” function activated (On) it is possible to mute the loud speaker for awished time segment. The duration of the “Mute Time” may be set by the CPS->Optional Setting->Other->Mute Timing.

(52) Weather Alarm (only US version) Turn On or Off the Weather Alarm function.

(54) CTC TE (Squelch Tail Eliminate) In case of active CTCSS, the STE functionwill blank the background noise ofclicking interferences at the break of the transmitter. (55) No-Signal TE Normal Squelch Tail Eliminate(STE) setting will be monitored (nosignaling). (57) Time Display Set On to show the date/time on display. Set Off to hide the date/time display.

7.7.2 Chan Set

(22) SMS Forbid Set On to prohibit the radio receive SMS. (23) DataAck Forbid Set On to ignore the repeater data service request. The radio will not reply to repeater when it receives the call confirmation/SMS confirmation request, etc..

(24) 5Tone BOT Set ON to send the 5Tone encode ID when press the [PTT] key. (25) 5Tone EOT Set ON to send the 5Tone encode ID when release the [PTT] key. (27) APRS Receive(optional with installed BT+APRS board) Turn on this function to enable the radio receiving the analog APRS information in current channel. Make sure your channel setting Frequency, CTCSS/DCS match to the transmit radio's setting. The radio will display the callsign, coordinates,direction,distance, digipeater paths, etc., when receive the analog APRS from the other radios. Radio Menu-> APRS -> Ana APRS Info, allows to check the receive analog APRS logs. CPS -> Public->APRS ->Analog APRS -> Receive Allow set to "On", and input the Callsign and SSID you want to receive. The radio will only receive and display the analog APRS.

7.10 APRS Location Reporting(Supported by GPS)

(3) Ana APRS Info The received analog APRS information will be saved in radio for look back use. Click on "Ana APRS Info" will show the received APRS information. Click on "Delete All" will clear the information.

-- That's the full set of what appear to be the highlighted changes. This is the version of the operating manual that came with the latest 2.02N firmware version.

[hmatuschek]

Thanks for the information. That helps a lot. The address of the call-sign db may have changed (as well as the size). This may cause the incompatibility between the D878UV and D878UVII CPSs.

[hmatuschek]

So, happy testing. It should work now. One thing is missing: The "APRS RX" flag for channels. As I do not have any representation of that flag, I have to "infer" it.

[g0hww]

OK, testing now, though my testing will be slow due to unfamiliarity with qdmr.

First, a question about the inference you make regarding "APRS RX". I interpret your statement to mean that the is no UI element to turn this on or off for a channel, so that you have to infer from some other data in that channel, perhaps the frequency, as to whether or not to enable the "APRS RX" capability, typically if the user is creating such a channel from scratch in qdmr. I do have a channel established in my radio's CP for analog APRS on the usual 144.800MHz frequency and "APRS RX" is enabled. I can imagine wanting to turn this on and off at will directly on the radio, as it isn't of much use in the current firmware. I suspect that it isn't really important to elaborate the UI to allow this to be explicitly set in qdmr. I also assume that if an analog APRS channel is imported from the radio, that qmdr respects the configured state of that feature even though it is not presented to the user.

I did just manage to get a segfault in qdmr. I'm not exactly sure how I triggered the segfault, but it seems likely to me that it happened because I deleted a couple of contacts from the imported CP. I deleted them because they don't exist in the contact list I established with the native CPS and assumed that they were not needed. One was for PC 5057 (the legacy APRS gateway Id) and the other was a DTMF contact 12345. Neither of these showed up in the Contact/Talkgroup list in the native CPS, but PC 5057 was listed explicitly (not as a reference to a configured contact/tg) in all of the default Digital APRS channels. I have now tweaked the Digital APRS channels in the native CPS to explicitly set PC 234999 as the destination for the unused Digital APRS channels, and also have removed the analog DTMF contact in the native CPS and on import to qdmr, neither the PC 5057 or DTMF 12345 contacts show up in the list. I expect that this segfault is unrelated to the D878UV2 support feature.

[Update] I now suspect that I triggered the segfault by clicking on the GPS/APRS tab after deleting the implicitly defined contact for PC 5057 which would have been referenced by the default Digital APRS channels.

[g0hww]

So far so good. I have only spotted an anomaly in respect of the per-channel "Digital APRS PTT Mode". In my CP written by the native CPS, I have "Digital APRS PTT Mode" set to "On" for most DMR channels on each DMR repeater (but not for those bound to DISCON or ECHO contacts), but reading/writing with qdmr seems to have reset the "Digital APRS PTT Mode" option on all DMR channels back to "Off". This might also impact "Analog APRS PTT Mode" for the analog APRS channels, but I already had that set to "Off" in the native CPS, concluding that I could enable it on the radio on-demand if I wanted to manually send analog APRS beacons.

[g0hww]

The "APRS RX" option seemed to become set to "Off" for my single analog APRS channel. I don't think that this is really a bad thing, unless you expected the value read from the radio to be preserved. It had previously been set to "On(Mute", with the 3 available options in the radio's channel options menu being "Off", "On" or "On(Mute). These are managed in the native CPS with a pair of tick boxes for "APRS RX" and "Ana APRS Mute"

[g0hww]

Although I have switched back to a CP uploaded from the native CPS for now, to restore the per-channel Digital APRS configuration, this is looking very promising.

I have uploaded and am continuing to use the Contacts Database uploaded with qdmr, and that is working well so far. I have the radio configured to show the TA, so I can see the screen switching from the Contacts DB info to the TA info as it becomes available, and after an hour or so of monitoring BM TG91, all seems to be consistent.

It might be worth noting that the native CPS had started to take a fair bit longer to upload the CP after I added a bunch of additional channels a few days ago, but qdmr uploads the CP much quicker. Also qdmr seems to be considerably faster at uploading the Contacts DB.

I may do some checks in the native CPS to see if the number of Contacts it reads from the radio is similar to those it imports from the latest Anytone Contacts CSV if that is a useful check to perform.

[hmatuschek]

[Update] I now suspect that I triggered the segfault by clicking on the GPS/APRS tab after deleting the implicitly defined contact for PC 5057 which would have been referenced by the default Digital APRS channels.

Opps that was indeed a bug. Should be fixed with 2feeb387d1e94f5dc35c2a1c699da06ccd047852.

[hmatuschek]

The current problem is, that there is no internal representation of device specific settings. That is, something like APRS PTT, or APRS RX. Adding these features is quiet hard right now. The major issue is the file format: These text tables are not very extensible in particular when I want to maintain backward compatability. Maintaining device specific settings for channels etc would require their internal representation as well as within the codeplug file. Maintaining global settings is easy: They are just read from the device and updated.

Using APRS with qdmr requires to specify an transmit period within the positioning system and to associate a positioning system with the channel. This method is supported by all radios providing GPS. Transmitting on every PTT press is not supported by e.g. TyT and Retevis devices.

For now, the RX APRS option is enabled automatically, whenever there is a positioning system associated with the channel. PTT APRS transmission is not possible.

I'll work on a new YAML based file format that will allow to store device specific settings. I am no sure right now how this will be represented within the GUI, but I'll find a way.