Implement settings extension for AnyTone devices

[hmatuschek]

These are a huge amount of settings to be implemented:

• [x] Implement AnytoneSettingsExtension
  • [x] Implement common settings (for all AnyTone and derived devices)
  • [x] Implement settings for AT-D868UV
  • [x] Implement settings for AT-D878UV
  • [x] Implement settings for AT-D578UV
  • [x] Implement settings for BTECH DMR-6X2UV
  • [x] Implement auto-repeater settings, including offset table.
• [x] Update manual

[allesand]

Oh, cool, will test and report. Thanks for your effort!

[hmatuschek]

A few things are already implemented in the anytone-settings-extension branch.

[allesand]

Branch compiled and runs fine, when clicking on the extensions I get

QMetaProperty::read: Unable to handle unregistered datatype 'VFOScanType' for property 'AnytoneSettingsExtension::vfoScanType'

and

QMetaProperty::read: Unable to handle unregistered datatype 'PowerSave' for property 'AnytoneSettingsExtension::powerSave'

[hmatuschek]

Oops, should be fixed now.

[allesand]

Yup. One step further:

ERROR in src/extensionwrapper.cc@565: Cannot map value 51 to enum KeyFunction. Ignore attribute but this points to an incompatibility in some codeplug. Consider reporting it to https://github.com/hmatuschek/qdmr/issues.

That seems to be "funcKey2Long" which is set to "47 Aprs Send" , Menu Item 47 in the list in the 878, between "45 Ch.Name","46 CDT Scan" and "48 Ana Aprs Info","49 GPS Roaming". 49 is the last entry.

I tried some other values, "CDT Scan" is read correctly and the next three are missing, so in "enum class KeyFunction {}", there must be more items after "BSTSend = 0x2e, Bluetooth = 0x2f, GPS = 0x30, ChannelName = 0x31, CDTScan = 0x32" like "AprsSend = 0x33, AnaAprsInfo = 0x34, GPSRoaming = 0x35"? I attached a diff, I am a little rusty in my programming skills but that seems to have worked?

But: in the 878, the list for "Key PF2 Short" holds 54 items while the list for "Key PF2 Long" has only 50 items - for example you can't put "Monitor" on a "long keypress". Is that already covered or should I check which ones are not selectable? That also seems to vary between the different function keys?

Also: Power Save in the 878 is set to "Save Off" (other options: "Save 1:1" and "Save 2:1") but qdmr reports "Save 50" - that is the second item in the drop down list, should it not be "Off"?

878 UV II Plus with firmware 3.01 here

KeyFunction.diff.txt

*** anytone_extension.hh~   2023-02-01 17:37:44.000000000 +0100
--- anytone_extension.hh    2023-02-01 20:47:47.624059627 +0100
***************
*** 366,372 ****
      ChannelTypeSwitch = 0x22, Ranging = 0x23, Roaming = 0x24, ChannelRanging = 0x25,
      MaxVolume = 0x26, SlotSwitch = 0x27, APRSTypeSwitch = 0x28, ZoneSelect = 0x29,
      TimedRoamingSet = 0x2a, APRSSet = 0x2b, MuteTimeing = 0x2c, CtcssDcsSet = 0x2d,
!     TBSTSend = 0x2e, Bluetooth = 0x2f, GPS = 0x30, ChannelName = 0x31, CDTScan = 0x32
    };
    Q_ENUM(KeyFunction)

--- 366,373 ----
      ChannelTypeSwitch = 0x22, Ranging = 0x23, Roaming = 0x24, ChannelRanging = 0x25,
      MaxVolume = 0x26, SlotSwitch = 0x27, APRSTypeSwitch = 0x28, ZoneSelect = 0x29,
      TimedRoamingSet = 0x2a, APRSSet = 0x2b, MuteTimeing = 0x2c, CtcssDcsSet = 0x2d,
!     TBSTSend = 0x2e, Bluetooth = 0x2f, GPS = 0x30, ChannelName = 0x31, CDTScan = 0x32,
!     AprsSend = 0x33, AnaAprsInfo = 0x34, GPSRoaming = 0x35
    };
    Q_ENUM(KeyFunction)

[hmatuschek]

This could be some extension to the 868UV or 878UV, this enum is based on. I'll check it.

[allesand]

Regarding "Power Save": On all three settings in the 878, qdmr displays "Save50".

Reading the key settings works with above patch for the three additional options.

[hmatuschek]

Ok, fixed that and also added some more. I've regrouped some of the settings.

[allesand]

Good morning, did a "git pull" and tried to build:

[ 63%] Building CXX object cli/CMakeFiles/dmrconf.dir/autodetect.cc.o [ 63%] Linking CXX executable dmrconf /usr/bin/ld: ../lib/libdmrconf.so.0.11.2: undefined reference to AnytoneSettingsExtension::subChannelEnabled() const' /usr/bin/ld: ../lib/libdmrconf.so.0.11.2: undefined reference toAnytoneSettingsExtension::enableSubChannel(bool)' collect2: error: ld returned 1 exit status make[2]: [cli/CMakeFiles/dmrconf.dir/build.make:298: cli/dmrconf] Fehler 1 make[1]: [CMakeFiles/Makefile2:196: cli/CMakeFiles/dmrconf.dir/all] Fehler 2 make: *** [Makefile:156: all] Fehler 2

Did my local changes break something? I removed my anytone_extension.hh before the "git pull"

[allesand]

Compiles fine now! Output while running:

QMetaProperty::read: Unable to handle unregistered datatype 'VFO' for property 'AnytoneSettingsExtension::selectedVFO'

"selectedVFO" property thus stays empty.

powerSave is read back correctly now. Hm. "Back Light" can be set in my 878 in five steps between 1 and 5, that is "brightness" in qdmr. "Back Light 2" is shown correctly as "brightness" "2". "Back Light 1" is read as "brightness" "0", though? Oh, "Backlight 3" as "brightness" "5", and 4 -> 7 and 5 -> 10. Ok. I see a pattern here..

Since "10" is max. valid value, should there be a limit on the possible input range in qdmr?

[hmatuschek]

Yes, I try to map everything to [1,10] or [0,10] if the latter makes sense. Limiting the input is difficult, as I use the Qt Property runtime object introspection mechanism to handle all extensions. This mechanism does not allow to specify value limits. However, I could (and should) limit the value in the extension and codeplug.

[allesand]

"timeZone" seems to be one hour ahead of the value in the handset: 878 is set to "UTC+01:00" but qdmr displays "UTC+02" - hopefully they did not change the index between firmware-versions? Or a "0 is 1" issue like with the "brightness" value?

[hmatuschek]

"timeZone" seems to be one hour ahead of the value in the handset: 878 is set to "UTC+01:00" but qdmr displays "UTC+02" - hopefully they did not change the index between firmware-versions? Or a "0 is 1" issue like with the "brightness" value?

Ok, I have to check this. With the old firmware, it worked correctly for my AnyTone D878UV. I'll update mine today. BTW, I've added a lot more settings to test. Including the VFO auto-repeater offsets. Some settings, that are more device-specific, are still missing. There is still a lot to do.

[allesand]

Thanks for your effort! I tested the current git sources: I acquired a 868, getting the configuration from the device gives a segfault with the anytone-extension-branch (running firmware 2.40) (-deleted- had my DMR id):

Debug in lib/usbdevice.cc@247: Check if serial port ttyACM3 still exisist and has VID:PID 28e9:18a. Debug in lib/radio.cc@56: Try to detect radio at Serial interface 'ttyACM3'. Debug in lib/usbserial.cc@90: Try to open Serial interface 'ttyACM3'. Debug in lib/usbserial.cc@124: Opened serial port ttyACM3 with 115200baud. Debug in lib/anytone_interface.cc@307: Anytone: In program-mode now. Debug in lib/anytone_interface.cc@336: Found radio 'D868UVE', version 'V102'. Debug in lib/anytone_radio.cc@192: Download of 13 bitmaps. Debug in lib/anytone_interface.cc@356: Anytone: Left program-mode. Debug in lib/usbserial.cc@155: Serial port will close now. Debug in lib/d868uv_codeplug.cc@1161: Store id -deleted- at idx 0. Speicherzugriffsfehler (Speicherabzug geschrieben)

How can I give you more information where the segfault is happening?

Oh? Same for the 878:

Debug in lib/usbdevice.cc@247: Check if serial port ttyACM3 still exisist and has VID:PID 28e9:18a. Debug in lib/radio.cc@56: Try to detect radio at Serial interface 'ttyACM3'. Debug in lib/usbserial.cc@90: Try to open Serial interface 'ttyACM3'. Debug in lib/usbserial.cc@124: Opened serial port ttyACM3 with 115200baud. Debug in lib/anytone_interface.cc@307: Anytone: In program-mode now. Debug in lib/anytone_interface.cc@336: Found radio 'D878UV2', version 'V100'. Debug in lib/anytone_radio.cc@192: Download of 15 bitmaps. Debug in lib/d878uv_codeplug.cc@2533: Allocate roaming zone at 1043000 Debug in lib/d878uv_codeplug.cc@2533: Allocate roaming zone at 1043080 Debug in lib/d878uv_codeplug.cc@2533: Allocate roaming zone at 1043100 Debug in lib/d878uv_codeplug.cc@2533: Allocate roaming zone at 1043180 Debug in lib/anytone_interface.cc@356: Anytone: Left program-mode. Debug in lib/usbserial.cc@155: Serial port will close now. Debug in lib/d868uv_codeplug.cc@1161: Store id -deleted- at idx 0. Speicherzugriffsfehler (Speicherabzug geschrieben)

Where does it store the core dump?

[hmatuschek]

This is possible, I can currently only check for self-consistency. I can only test it with real codeplugs tomorrow evening (CET). However, the segfault happens during the decoding. If you like, you can send me the binary codeplugs via mail. You can read them using the command line tool

dmrconf read codeplug.dfu 

This will skip the decoding step, so I can debug the decoding.

[hmatuschek]

Ok, found it. Should be fixed now.

[allesand]

Yes, reading from the radios works now!

On the 868 (FW 2.40), time zone is read correctly, on the 878 with firmware 3.01 it's plus 1h (UTC+02), though both radios are set to "UTC+01:00". I read that in some firmware revision, more time zones were added. Did that change the index? Here more timezones are mentioned for firmware 1.25: https://theblackmoor.net/anytone-878-gets-firmware-upgrade/ : "12. Add timezone GMT+5:30(India), GMT+5:45 (Nepal), GMT+4:30(Afganistan), GMT+3:30(Iran) GMT-3:30 (Newfoundland, Canada), GMT+8:30 (Eucla)"

Since there is a matching CPS for every firmware release, they could change the timezone index and only when using the same software for both models/firmware releases like with qdmr one cloud notice that change? How does your 878 behave before and after the update?

868 FW 2.40, 878UV FW 1.25 and 878UV II FW 2.03 are all dated November 30, 2021 (http://www.wouxun.us/category.php?category_id=93) but I can confirm that with my 868 in Newfoundland I'd either be half an hour early or half an hour late since it lacks all xx:30-timezones - while the changlogs for the 878s mention the addition of those zones.

Minor note: Squelch is set to "1" in the radio, but the "Channel default value" displays "Squelch" "2" - ok, displayed in steps of 2, 4 -> 8, 5 -> 10. But: "Ana SQ OFF" is displayed as "Squelch" "2" in qdmr also?

[allesand]

Will try and report! In case you already updated your 878: callsign display is possible in multiple different colors now. I also liked the fact that the 868 has "black" as a possible display color on a black background - as expected that was actually white and possible is a leftover from the former blue background :-)

[hmatuschek]

Ok, yes I was also puzzled about it. I'll extend the enum and fix the color names. This may also consolidate some of the codeplugs across devices, which would save me some code.

allesand @.***> schrieb am Do., 9. Feb. 2023, 15:52:

Will try and report! In case you already updated your 878: callsign display is possible in multiple different colors now. I also liked the fact that the 868 has "black" as a possible display color on a black background

• as expected that was actually white and possible is a leftover from the former blue background :-)

— Reply to this email directly, view it on GitHub https://github.com/hmatuschek/qdmr/issues/298#issuecomment-1424313501, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACE6E3URK4FAT3BOGA4NY3WWUAB3ANCNFSM6AAAAAAUNWOCMM . You are receiving this because you authored the thread.Message ID: @.***>

[allesand]

Builds fine, but trying to write to my 868 gives:

Debug in lib/radio.cc@56: Try to detect radio at Serial interface 'ttyACM3'. Debug in lib/usbserial.cc@90: Try to open Serial interface 'ttyACM3'. Debug in lib/usbserial.cc@124: Opened serial port ttyACM3 with 115200baud. Debug in lib/anytone_interface.cc@307: Anytone: In program-mode now. Debug in lib/anytone_interface.cc@336: Found radio 'D868UVE', version 'V102'. FATAL in lib/dfufile.cc@653: Cannot resolve offset 2140000h. [...] FATAL in lib/dfufile.cc@653: Cannot resolve offset 2580000h. FATAL in lib/dfufile.cc@653: Cannot resolve offset 24c2000h. Speicherzugriffsfehler (Speicherabzug geschrieben)

[allesand]

With the 868, I still get

Debug in lib/radio.cc@56: Try to detect radio at Serial interface 'ttyACM3'. Debug in lib/usbserial.cc@90: Try to open Serial interface 'ttyACM3'. Debug in lib/usbserial.cc@124: Opened serial port ttyACM3 with 115200baud. Debug in lib/anytone_interface.cc@307: Anytone: In program-mode now. Debug in lib/anytone_interface.cc@336: Found radio 'D868UVE', version 'V102'. Debug in lib/anytone_radio.cc@192: Download of 13 bitmaps. FATAL in lib/dfufile.cc@653: Cannot resolve offset 2580000h. FATAL in lib/dfufile.cc@653: Cannot resolve offset 800000h. FATAL in lib/dfufile.cc@653: Cannot resolve offset 800040h. FATAL in lib/dfufile.cc@653: Cannot resolve offset 800080h. [...]

Is there anything I can do to debug what's going wrong here? Same for the 878:

Debug in lib/radio.cc@56: Try to detect radio at Serial interface 'ttyACM3'. Debug in lib/usbserial.cc@90: Try to open Serial interface 'ttyACM3'. Debug in lib/usbserial.cc@124: Opened serial port ttyACM3 with 115200baud. Debug in lib/anytone_interface.cc@307: Anytone: In program-mode now. Debug in lib/anytone_interface.cc@336: Found radio 'D878UV2', version 'V100'. Debug in lib/anytone_radio.cc@192: Download of 15 bitmaps. FATAL in lib/dfufile.cc@653: Cannot resolve offset 2580000h. FATAL in lib/dfufile.cc@653: Cannot resolve offset 800000h. FATAL in lib/dfufile.cc@653: Cannot resolve offset 802000h. FATAL in lib/dfufile.cc@653: Cannot resolve offset 800040h. FATAL in lib/dfufile.cc@653: Cannot resolve offset 802040h. [...]

[hmatuschek]

Can you get me a binary codeplug from that device? That is using the command line tool

dmrconf read d868uv_codeplug.dfu

[hmatuschek]

Oh wait, these are false-alarms. Should be fixed now for anytone devices.

[hmatuschek]

Fixed the GPS time-zones. The 868UV, 868UVE are using the "old" hour-wise steps, while the newer FW releases of the 878UV, 878UV II, 578UV and 578UV III are using the additional TZs. Updated the enums accordingly.

[allesand]

Fixed the GPS time-zones. The 868UV, 868UVE are using the "old" hour-wise steps, while the newer FW releases of the 878UV, 878UV II, 578UV and 578UV III are using the additional TZs. Updated the enums accordingly.

Yup. Both my 868 and my 878 agree to be in the same time zone now. Fixed!

[allesand]

User DB fix is working great!

Although writing the config is currently broken for me ( https://github.com/hmatuschek/qdmr/issues/328 ), the recent fixes for the user db work like a charm - consistent display for all entries. Very cool!

[allesand]

User DB fix is working great!

Although writing the config is currently broken for me ( #328 ), the recent fixes for the user db work like a charm - consistent display for all entries. Very cool!

For consistency: the current https://github.com/hmatuschek/qdmr/tree/anytone-settings-extension is both writing a vaild config and a complete user DB. Will test all the new configuration options in more detail, as of now: all good! Thanks!

[hmatuschek]

Ok, almost done. Missing some docs and then it can be merged into master.

[allesand]

Status report: user DB and config write ok on my 868.

[allesand]

In the extensions -> key setting, the keys are labelled 1-6 and A-D, I seem to recall that previously, the same identifiers "P1, P2, PF1, PF2 etc.) were used as in the Windows-CPS? With just numbers and letters it is hard to match keys and identifiers. Is that supposed to be this way?

With the current version, there is the following message in the log (878, FW 3.01): ERROR in src/extensionwrapper.cc@572: Cannot map value 1072693248 to enum KeyFunction. Ignore attribute but this points to an incompatibility in some codeplug. Consider reporting it to https://github.com/hmatuschek/qdmr/issues

[hmatuschek]

Yes, it is true, that the previous labels where those of the windows CPS. The problem is, that there are different labels for the 578.

I tried to unify those: The side keys and those on the hand mic (578) are now labelled A, B, C, D. On the handheld, they are A=PF1, B=PF2, C=PF3, D is not used on the handheld. The buttons next to the display are 1,..., 6, where the handheld has only two 1=P1 & 2=P2.

[hmatuschek]

Concerning the error message, I have to check it.

[hmatuschek]

In the extensions -> key setting, the keys are labelled 1-6 and A-D, I seem to recall that previously, the same identifiers "P1, P2, PF1, PF2 etc.) were used as in the Windows-CPS? With just numbers and letters it is hard to match keys and identifiers. Is that supposed to be this way?

With the current version, there is the following message in the log (878, FW 3.01): ERROR in src/extensionwrapper.cc@572: Cannot map value 1072693248 to enum KeyFunction. Ignore attribute but this points to an incompatibility in some codeplug. Consider reporting it to https://github.com/hmatuschek/qdmr/issues

Concerning this error message: This was just a false alarm. I forgot to initialize the D-key function property in the extension. As it was not set during the decoding (the D key is only present at D578UV) the value of the property was just a random integer.

[hmatuschek]

Ok, all settings and extended settings are implemented now. I'll update the manual and clean up the mess a bit before merging this monster (20k lines) into master.

This means, some names may change again, to unify the nomenclature and to clean up the chenglish, copied from the manufacturer CPSs.

[hmatuschek]

Merged into master, all bugs concerning the anytone extension are now normal bugs.

[allesand]

It's compiling right now. Big step! Will report any findings. Thanks for all your effort!