AnyTone D868UV - personal first impressions

by Wolfgang "Wolf" Büscher, DL4YHF
Last updated 2019-10-24

Main website:
This page: /Anytone_D868UV/index.html


Proceed at your own risk ! The modifications on this page may not work with your radio, and the findings described here may only apply to a single unit. The author won't be liable for anything at all, blah, blah.. (consider this as the usual disclaimer. It also applies to the description of codeplug patches, and to any link you may find on this webpage).


  1. AT-D868UV - Tipps für deutsche Anwender
  2. Getting the D868UV to work, first impressions
    1. AT-D868UV - Searching for a suitable codeplug
    2. A codeplug for 'OWL' (Ostwestfalen-Lippe, Germany)
  3. Inside the AT-D868UV - photos
  4. AT-D868UV Firmware modifications ? (not yet..)
  5. AT-D868UV hardware details
    1. baseband processor : SCT3258TD with AMBE voice codec

1. AT-D868UV - Tipps für deutsche Anwender

Auch beim AT-D868UV müssen einige Parameter (z.B. der eigene DMR-Identifier) per CPS eingegeben werden. Im Gegensatz zur 'experimentellen' Firmware für MD380 & Co war dies im Mai 2018 noch nicht am Gerät machbar.
In einem weiter unten folgenden Abschnitt findet man einen Codeplug für Ostwestfalen-Lippe. Was man als deutscher Anwender nicht verpassen sollte, ist das von Funkamateuren laufend erweiterte 'inoffizielle' Handbuch bei Google Documents: (wie zu erwarten war, funktioniert dieser Link nicht mehr - bei DG9VH gibt's mehr).

2. Getting the AT-D868UV to work, first impressions

The AnyTone D868UV is a duoband handheld transceiver for DMR (digital voice) and analog FM. Compared with older chinese DMR radios I had used in the past (Retevis RT-3, RT-8) it's a nice step forward, not only concerning the hardware, but also the firmware (for which, as of 2018, new upgrades are available from the manufacturer very frequently).

MD380/RT3 and AnyTone D868UV side by side - brothers or rivals ?

You will find details about the radio, and its large memory for channels, zones, user database, etc etc on the manufacturer's or distributor's websites so I won't duplicate that.
The AT-DV868UV emits far less 'digital noise' when updating the LCD than the old MD380/RT3 did, but you can still hear a bit in FM when the squelch is open and the received signal is weak.

On the backside of the battery - "let it glow", hot contacts, no protection diode. History repeating ?

Being curious about the 'inner values' (especially CPU and baseband chip / codec), I carefully opened the radio (which is quite similar as opening an MD380 / RT3). See chapter photos, with details of the CPU board and the CPU itself (which, in contrast to MD380/RT3, isn't an STM32Fxxx but a compatible clone, GD32F303VGT6. There are some nice goodies in the AT-D868UV firmware which didn't even exist in the 'experimental' MD380 firmware. To name just a few: The programming software (CPS) isn't too spectacular, but there's one goodie that helps a lot since their rdt file format seems to differ from others (causing programs like Contact Manager to fail loading codeplugs from CPS, and the CPS failing to load codeplugs saved by Contact Manager):
Almost anything can be exported as CSV, and re-imported from CVS. So anything you be missing in the CPS can be done in a spreadsheet program (e.g. Libre Office 'Calc'), including 'Find and Replace'. But who wants to create a new codeplug from scratch ? Most of us will have more interesting things to do, which seamlessly leads to the topic of the next chapter.

2.1 Searching for a suitable codeplug

As ususal with a DMR radio, the first thing to look for is a suitable codeplug. Even though a lot (!) of settings can be adjusted directly on the radio, some parameters cannot. Also, the choice of how channels (with or without many different talkgroups), zones, and the user interface (programmable functions keys) is a matter of taste.
Some prefer programming the same DMR frequency more than twice (not just one for timestlot 1 and another timeslot 2). Some perfer a continent- or even worldwide channel list, others prefer channels only for the repeaters in range from the home QTH. Some use DMRplus where you don't need dozens of different talkgroups (because DMRplus makes efficient use of reflectors), others use Brandmeister where reflectors are available but rarely used - in favour of many talkgroups.
In the old days of MD380 / RT3 / etc, you were forced to have a 'VFO-like' codeplug (channel list) to use the radio anywhere. Fortunately, the AT-D868UV has a quite user friendly 'VFO' mode besides the usual 'memory channel' mode so (with a few exceptions) it's unnecessary to occupy hundreds of channel memories with a "VFO-like codeplug". But enough of that, let's start with a codeplug.
I found one at Wimo (a german distributor) but the programming software refused to load it into the radio ("Band Error"). Ah, that's a nice start.
None of them could be downloaded into the radio via USB - any attempt ended with a 'Band Error' message:

Error message when trying to write codeplug written for
a radio with other 'Frequency Range' (e.g. "Band 4" instead of "Band 1")

At offset 0x0011 (hexadecimal) in the rdt file, the codeplug contains the 'Model Information', which is a single byte indicating the allowed frequency ranges ("Frequencys" in the CPS):
  0 : "Band 1", UHF 400 - 480 MHz, VHF 136 - 174 MHz (US models)
  3 : "Band 4", UHF 430 - 440 MHz, VHF 144 - 146 MHz (European models)
Unfortunately, if you modify the 'Model Information' / 'Frequencys' in the CPS (Customer programming software, here "D868UVE Version 1.27"), it will erase the entire channel list ( -> "Frequency data will be cleared") which isn't too helpful.
You can either turn your European model into a US model by holding certain keys pressed during power-on (PTT+'1', "TEST MODE", change MODE:00003 -> 00000 via rotary knob), but I'd prefer to not allowing the radio to transmit outside the amateur radio frequency range. On this occasion, the 'TEST MODE' values seem to be the same zero-based indices for the frequency ranges found at address 0x0011 in the *.rdt file.
I used wxHexEditor (available for Linux and Windows) to patch the Model Information / Frequency Range at offset 0x0011 in the rdt file (change the value at address 0x0011 from 00 to 03. The "0x" prefix means hexadecimal. Some hex editors use 'h' as a postfix instead, which may be confusing but means the same.)

After loading the patched codeplug into the CPS, the window title changed to the 'European' frequency range:

Window title of the Anytone CPS with EU frequency ranges

On this occasion: Before 'recycling' someone else's codeplug for your radio, never forget to replace his callsign and DMR-ID by yours. In the 'D868UVE' programming software, this is in the tree view on the left side of the window:
  Digital .. 'Radio ID List' .. 'Radio-ID' (double-click into the cell in the table),
  set 'Radio ID' to your personal DMR registration ID,   set 'Radio ID Name' to your amateur radio callsign.
The AT-DV868UV supports entering multiple DMR-ID / Callsign combinations, but usually we only need one (entered in the first line, "No. 1", of the 'Radio ID List'.
A few screenshots from the author's initial codeplug (see further below).. click on any image to magnify:
Note the problematic "auto repeater" offsets for UHF: 7.6 MHz only applies to FM repeaters. Many DMR repeaters use 9.4 MHz, and at the time of this writing it wasn't sure if the firmware is smart enough to pick the right one (which you can define on the 'Auto Repeater Offset Frequencys' tab, it's not hard-coded anywhere).

2.2 A codeplug for 'OWL' (Ostwestfalen-Lippe, Germany)

This one is stitched together from parts found all other the place (using the CSV-import and -export feature of CPS V1.27). This is certainly not the best way to write a codeplug, but there you are. I didn't want to spend a lot of time for this. The 'other' settings (hold times, etc) are based on a codeplug by Stefan, HB9GFX. His codeplug also contained the large worldwide DMR user database in the right format. It can be 'refreshed' if necessary using the CPSes CSV import function (field 'Digital Contact List'), with an up-to-date DMR user database downloaded from Cities and surnames of European users have disappeared from the database, which imho isn't a big loss. If (one fine day) the AT-D868UV displays the Talker Alias (TA, received along with the voice data), there's no need to maintain a database in the radio itself.. at least not for the Brandmeister network which automatically adds the TA to the data packets.

AnyTone_D868UV_FwVers2_27_Codeplug_OWL_DL4YHFv006.rdt (zipped)
        |____| |________|                    |___|
          |       |                            |__ CP version number
          |       |_______________________________ Firmware version
          |_______________________________________ Radio model

Again, please replace the callsign and DMR-ID with your own before writing any codeplug to your radio ! (in the tree view: "Digital".."Radio ID List")

The normal programmable keys have the default functions as explained in the radio's user manual. Pressing the programmable keys for a bit longer invokes the functions shown in the screenshot from the CPS:

Hotkey settings in the DL4YHF 'OWL' codeplug.
Note the keys for repeater, reverse, power, scan.
'PF3' is the tiny orange button near the antenna.

I will possibly boil this down to a much smaller codeplug, and add more channels for analog repeaters requiring sub-audio tones when time permits, and when DMR Contact Manager is compatible with the Anytone CPS again.
(At the time of this writing, 2018-05-13, the CPS 'D868UVE' Version 2.27 RDT file was not compatible with N0GSG's DMR Contact Manager, and the CPS could only export DCF ("data conversion files", a file which unfortunately is as 'binary' as all the rest) but not import them.)

3. Inside the AT-D868UV - a few photos

Note: The photos below were scaled down from a much higher resolution for the website.
When opening the radio, it's important to remove the screws under the pot/encoder knobs, and the ring around the SMA connector. Then, carefully lift the metal part from the plastic enclosure. There are two short flat cables inside (see 2nd photo). Don't lift the metal part higher than shown here - you don't want to rip off those flimsy cables. You also don't want to remove and re-install those cables, because every time you do, their contacts get worse.

Before any attempt to lift the metal backside, remove the knobs
and screw out the ring nuts from pot, encoder, and SMA connector.
The 'cogwheel-like' rubber grommets may fall out later. Note their positions.

Lifting the metal backside - beware of the flexible flat cables (FFC)

Phew, brass shielding for parts of the RF circuit !
Note the second (white) FFC, don't rip it out...

CPU (main processor) and closeup of shielded RF circuitry

Baseband processor in the foreground,
CPU under the display cable in the background

Closeup of the CPU (main processor),
GD32F303VGT6 with 1 MByte Flash + 96 kByte internal RAM.

Speaker and microphone are glued into the front panel.

Board labelled "LCD+GPS". I didn't remove the cardboard cover
to find out which kind of GPS (chipset) is actually used.
But a glance into the firmware revealed a parser for NMEA strings,
so it should be easy to process GPS data in an alternative firmware.

The baseband processor is an SCT3258TD by CELETRA DMR,
with a hardware AMBE+2 voice codec inside. That's nice !

4. AT-D868UV Firmware modifications ? (not yet.. but not completely impossible)

It would be nice if we had something like the 'md380tools' for this AnyTone radio (even if the D868UV ships with a much better firmware than the MD380/RT3/etc). But as far as I could see in 2018-05, no-one has attempted to decrypt and disassemble / document the device firmware yet. Also, as long as there's a new firmware (and dedicated new CPS) from the manufacturer every few weeks, it makes little sense of trying to patch it since this is a time-consuming effort (finding out the addresses of functions in the original firmware, trying to hook into them to let them do anything useful).

If the Anytone manufacturer / developer (Quixiang Electron Science & Technology Co) published an API (Application Interface, a list of functions and variables with their addresses in memory), or at least a map file with function prototypes for their firmware would be great. That would allow radio amateurs to make their own additions to the firmware much easier than what has already been added to the experimental MD380 / Retevis firmware (MD380Tools pioneered by Travis Goodspeed). For example, the Morse output for visiually impaired hams, remote control via USB, screenshots via USB, audio interface via USB, Network Monitor, etc... but without knowing the details, and (if there's no documented programming API) without an awful lot of software reverse engineering, that's a lot of effort.
At least, the firmware wasn't encrypted (in May 2018, V2.27) so if you have a lot of time to spend and are familiar with tools like Radare2, start disassembling and try to document and share your findings, possibly on a yet-to-be created "D868Tools" repository on Github. Below a few musings from the author... Maybe, if the AT-D868UV gains the same popularity as the MD380 / Retevis RT3, the MD380Tools developers jump on the train. For a single person's spare time (at least mine), the effort appeared too large, considering how well the radio works 'as is' (with the stock firmware) compared to MD380 / RT3 / etc.

5. AT-D868UV hardware details

The following descriptions are based on the ICs found inside the radio (see "photos), when in 2018-05 no service manuals, circuit diagrams, etc etc could be found anywhere in the internet. By the time you read this chapter, the situation may have improved.

5.1 The baseband processor

Looking at the D868UV's main board, the baseband processor is the 2nd largest IC (besides the CPU). It can be seen here (same image as in the 'photos' chapter.
According to the SMD marking, the chip is an SCT3258TD made by by Chinese company CELETRA DMR. One of its most intriguing properties is the integrated hardware AMBE+2 voice codec. That's nice because with an AMBE codec in the baseband chip, the CPU has much less workload than for example in the MD380, where the CPU had to to the tedious work of compressing voice into AMBE packets on transmit, and extracting voice from AMBE packets on receive. Not so in the AT-D868UV !
Second, there's a datasheet available for the SCT3258TD, application notes about its packet interface, analog setup, almost anything that you would need to write your own firmware for it ;o)

The lack of a 'software' AMBE voice codec in the microcontroller firmware may explain why the firmware is relatively small. There's hope that some of the GD32F303VGT6's 1024 kByte internal Flash is unused (since 'codeplug' data are stored in another, external Flash), so there may be enough room left for future extensions.

If you are curious about the baseband chip and its integrated AMBE vocoder, check out the CELETRA DMR website.
In May 2018, all relevant documents (datasheet and application notes) could be downloaded from a single page (Products .. DMR Baseband Processor). There also was a document titled 'Datasheet of Universal RF Transceiver SCT3700' marked 'For Internal Use Only', so this may have leaked out into the internet by accident. Something similar as the SCT3700 may be in use in the AT-D868UV too. Quite likely the 'RF Transceiver' is hidden under one of the brass metal shields which for good reasons I did not want to de-solder, just to make a photo. With an SCT3700-alike 'RF Transceiver' chip, this block diagram would be similar to what's inside the Anytone (ignoring the fact that the AT-D868UV is a duo-band radio):

Block diagram of a radio based on the SCT3258 baseband chip.

The baseband chip's list of features (quoted from the datasheet) is interesting:

Chapter 2 : Features


4 FSK Modem
Analog Mode Support

Premium Features
So record/playback isn't a feature of the main processor firmware, but the baseband processor can do this 'on its own'. That's one of the reasons why the SCT3258[TD] has its own Flash memory interface. Guesswork: It can only record/replay digital voice (but not analog FM) because it "simply" stores AMBE packets in Flash, or reads them back on request of the main CPU.