Disclaimer
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).
Contents
- AT-D868UV - Tipps für deutsche Anwender
- Getting the D868UV to work, first impressions
- AT-D868UV - Searching for a suitable codeplug
- A codeplug for 'OWL' (Ostwestfalen-Lippe, Germany)
- Inside the AT-D868UV - photos
- AT-D868UV Firmware modifications ? (not yet..)
- AT-D868UV hardware details
- 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:
docs.google.com/document/d/15KhnLn9Oq9Xa7S_rYg19m3hghCm8huWldOg7beaHUog/edit
(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:
- 'Digital Monitor' allows monitoring any talkgroup, any colour code, any timeslot on the programmed channel (resembling the 'promiscuous mode' but highly
configurable without CPS
- A true VFO mode, for both analog and digital mode
- Simulatenous reception on VHF and UHF, or two different VHF channels, or two different UHF channels in any mode
- FM broadcast radio receiver with quite good audio quality
- Ad-hoc talkgroup entry (e.g. 'Contacts'..'Manual Dial'..press '#' to toggle between Private and Group ID. To begin a QSO on a new TG, use a Group-,
not Private call.)
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")
Reason:
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 www.amateurradio.digital/wizard.php?radio=d868uv. 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.)
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 !
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...
- The CPU obviously has unused Flash memory space
- But 96 kByte of RAM for an operating system with a rich GUI may turn out a bottleneck
- The firmware updater (and its USB protocol) is based on a library provided for the GD32Fxxx.
Even the USB driver is the same as provided in a 'development kit' for the processor.
- The CPU may have less to do here than in an MD380 / RT3 due to the Anytone's hardware AMBE codec
- Before digging deep into the existing firmware, wait until the existing firmware 'stabilizes'
- We need a circuit diagram, especially for the CPU's pin assignments to the LCD, keyboard, baseband chip,
synthesizer, backlight (most likely connected to a PWM output), audio control, etc.
- With that, we can start disassembling the firmware (using Radare2 to make a 'documented listing')
because the I/O port addresses, along with the interrupt service handlers are good points
to start reversing the thing 'from bottom to top'.
- On a first glance with Radare2, some of the ARM (Cortex-M) code looks pretty familiar,
obviously "borrowed" from libraries by ST Microelectronics (the GD32F303 is an 'improved clone'
from China, based on, or "compatible with", the STM32F303)
- We need to know the structure of the firmware update files (precisely, not just "it contains
ARM code here and there"), e.g. are there checksums, or similar patterns
that must be patched so the stock firmware update 'accepts' a modified file for downloading,
is it structured in sections or just a plain '1 : 1' image of the Flash memory.
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.
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.
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
DPMR
- Support DPMR Tier 1 (ETSI TS 102 490)
- Support DPMR Tier 2 (ETSI TS 102 658) Mode 1 and Mode 2
- Air interface physical layer (layer 1)
- Air interface data link layer (layer 2)
- Air interface call control layer (layer 3)
- Full Annex A support, with BCD addressing and automatic call match
DMR
- Support DMR Tier1 and Tier 2 (ETSI TS 102 361)
- Air interface physical layer (layer 1)
- Air interface data link layer (layer 2)
- Air interface call control layer (layer 3)
- Annex C (TS 102 361-2 Annex C) support, with BCD addressing and automatic call match
- Transmit in slotted or continuous mode
- Receive in slotted or continuous mode
- Support TDMA direct mode
4 FSK Modem
- 4800 bps data rate for DPMR and 9600 bps for DMR
- Automatic frame sync detection
- Programmable modulation index
- Support two point modulation, and I/Q modulation
- BER Test Mode complied with ITU O.153
Vocoder
- Build-in AMBE + 2 vocoder from DVSI
- Support other types of low bit rate vocoder with 3600 bps
- Support 1031 Hz Tone and Silence Test Mode
- Automatic vocoder switching at the receiver in DPMR mode
Analog Mode Support
- Support voice channel filters (LPF/HPF/Limiter), as well as pre-emphasis and de-emphasis filters.
- Support CTCSS/DCS generation and detection
- Support arbitrary CTCSS/DCS code, and blind detection
- Support the non-standard 55 Hz CTCSS tail tone
- Support compander
- Automatic analog/digital mode detection (analog/DPMR or analog/DMR) in receiver mode
Premium Features
- Voice Recording and Playing back for local and remote (!)
- 16 bit voice encryption
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.