Open OK2MOP opened 6 months ago
bricky149
commented
6 months ago Fantastic work!
IIRC, DualTachyon (User Person on Telegram) briefly had a repo public referring to the AR-2520. I am under the impression he is reverse-engineering the firmware ATM. If that assumption is right, and now knowing there are many similarities between this and the RT-890, then it sounds possible to port fixes/enhancements across.
OK2MOP
commented
6 months ago I have in the meantime found out that the missing function will probably be TMR1_OVF_TMR10_IRQn (there is also a potential issue with USART IRQ and MUX mapping which might have to be addressed), and the startup.S file will also have to be modified for AT32F415. But if he is working on it (together with my time limitations ATM), maybe it is best to leave it to somebody intimately familiar with the code...
OK2MOP
commented
6 months ago If anyone is interested, I have observed the serial data for TRX <-> MIKE communication (115 200 8N1 UART) EDIT: Communication is done over USART3 on radio (V1 firmware)
Commands are enclosed in [ and ] characters, probably to distinguish from NMEA data which can be sent over serial and serial CPS communication.
Commands are acknowledged from radio by 0x06 (ACK)
Following commands have been observed from microphone:
Following commands have been observed from radio:
[B,X]
i.e. 5B 42 2C XX 5D
XX value (X): 0x00 - OFF (\x00) 0x01 - ON (\x01)
[L,X]
i.e. 5B 4C 2C XX 5D
XX value (X): 0x10 - Blue LED (0b00010000) 0x20 - Red LED (0b00100000) 0x40 - Green LED (0b01000000) 0x00 - No LED (0b00000000)
Combinations permissible, white will be probably 0x70
[K,WWWW]
i.e. 5B 4B 2C WW WW WW WW 5D
All keys released: x: 0x00 0x00 0x00 0x00
1: 0x00 0x00 0x10 0x00 2: 0x00 0x00 0x01 0x00 3: 0x00 0x00 0x00 0x10 4: 0x00 0x00 0x20 0x00 5: 0x00 0x00 0x02 0x00 6: 0x00 0x00 0x00 0x20 7: 0x00 0x00 0x40 0x00 8: 0x00 0x00 0x04 0x00 9: 0x00 0x00 0x00 0x40 *: 0x00 0x00 0x80 0x00 0: 0x00 0x00 0x08 0x00
Menu: 0x00 0x00 0x00 0x01 Exit: 0x00 0x00 0x00 0x02 Up: 0x00 0x00 0x00 0x04 Down: 0x00 0x00 0x00 0x08 OK: 0x01 0x00 0x00 0x00
| B0 | B1 | B2 | B3 | |
|---|---|---|---|---|
| b0/1 | -O | 12 | 3M | |
| b1/2 | 45 | 6E | ||
| b2/4 | 78 | 9^ | ||
| b3/8 | *0 | #v |
Key press must be followed by key release, otherwise it is not recorded:
Low signal on PTT wire [\x06][\x06] aka 5B 06 5D 5B 06 5D is main PTT button
[P,\x02][\x06][\x06] aka 5B 50 2C 02 5D 5B 06 5D 5B 06 5D
Probably a FW BUG that the TX is always on bottom channel
[P,\x01][\x06][\x06] aka 5B 50 2C 01 5D 5B 06 5D 5B 06 5D
[P,\x00][\x06][\x06] aka 5B 50 2C 00 5D 5B 06 5D 5B 06 5D
Following commands have been extracted from V1 firmware protocol handler, they have not been observed in standard communication, but work and have been added here:
[CONN] - letting radio know of MIKE reconnection and power on
[O,\x00] aka 5B 4F 2C 00 5D
[O,\x01] aka 5B 4F 2C 01 5D
[F,X] aka 5B 46 2C XX 5D where X is \x00 (OFF) or \x01 (ON) (sets two variables to 0 or to 1)
BubbaKush4twenty
commented
3 months ago Is this the same for the ABBREE AR-2520 GPS?
OK2MOP
commented
3 months ago Yes, this is the protocol for both radios (V1/V2).
However it looks like they may have withdrawn radios from market, according to the real manufacturer (iRadio) they will never provide any firmware update for V2 radios, and plan to rework the radio from scratch (V3?). Abbree does not react at all.
Under these circumstances I warn all people against buying this radio, especially since there are reports of letting the radio turned on with GPS running has caused black screen persisting even after reboot with only the key lock icon displayed when keyboard is locked, and radio otherwise bricked (multiple reports).
So much potential has been wasted for this radio.
Hello, as I am lacking a stock V2 firmware and have only V1 board firmware downloaded, and I won't have much time in following 3 weeks to play with the decompiled V1.08 firmware, I wanted to let you know about my findings concerning this radio, which is built on similar hardware and same codebase as RT-890 and may be an interesting thing to hack next due to small size, higher power and hackability potential (unless they start producing multiple incompatible versions like with some other UV radios).
I have also tried to map RT-890 stock 1.35 firmware and many matches are found, but as I do not have access to the original RT-890 decompilation with function labels - although it should be available in some TG group - and my HW uses different firmware (hopefully V1-based radio has been ordered and is on the way) I am stuck right now (if anyone can, even privately, share the GH project file or at least the original firmware on which this OEFW is based with symbol file, it would be a big help).
AR-2520 has following components on board:
A separate RJ-45 connected microphone is connected, pinout has been already published by others, connector has UART RX an TX pins, audio, PTT, ground and its pinout is incompatible with other radios.
Microphone contains some PART ID sawed-off 20-pin MCU for processing button matrix, and controlling LEDs on it
The whole radio consists of three PCBs - microphone, front panel with GPS optional module and BT module socket
Two versions of the base board exist - the original "2347 - E350325" board (V1) with some unused chip sockets broken out - uses V1.06/V1.08 firmware - and UV2520 V1.3E 2023.12.9 with some interesting unused (SD card slot?) pads - uses V2.02(1.03E) firmware.
V1 board (courtesy of TechMinds video)
V2 board differences
Probably the SWD interfaces are broken out on boards for both AT32 and unknown microphone MCU with unsoldered pin holes on both variant of the board.
The firmware is built on the same codebase as RT-890 which I have already mentioned:
Codeplug format and basic serial communication (possibly also firmware flashing as upgrade .NET utility is built on same codebase) is the same, of course the serial protocol must also support button input from microphone MCU.
SPI Flash structure seems very similar (if not exactly the same as the RT-890)
Same bugs as RT-890 concerning squelch and CTCSS audio levels are present (on the first look the calibration data structure is the same)
Almost the same GUI is used - however allowances had to be made for FAN controls and V2 has the GPS screen, some extra options and menus have been added
Button pins from RT-890 have been probably probably freed and were recycled for other uses.
Well documented exchanging of AT32F421 and AT32F415 document exists which could be used opposite way (MG0017 - https://www.arterychip.com/download/MG/MG0017_Migrating_from_AT32F415_to_AT32F421_EN_V2.0.1.pdf).
There are several maybes which would make this suitable for future hacking: SD pins, non-working recording function which may indicate that audio might be connected to MCU for this feature, enough space for adding a slave board into MIC or MCU housing (but it could interfere with filters as they are not shielded from this part of radio)
I have tried to modify the code for use with AT32F415 SDK and I had to comment out the MUXing of TX/RX pins which is not present in this CPU (but I think it is set to default on RT-890). What is, however, missing in this SDK is the BRK_OVF_TRG_HALL_IRQn I am not sure what I should replace it with.
EDIT: Forgot to mention here that AT32F415 does not have TMR6, another timer must be used instead (I have tried TMR1 but the function above may not be available for it)
Minimal changes which would have to happen to present codebase: Button input over serial, cooling FAN control, Display FAN control indication, GPIO remapping Additional changes: GPS support (V2 firmware will be needed for that), daughter board communication/usage
Now the bad things: the radio is advertised as 25W, but with factory "calibration" 17-18W are achievable on VHF and 13 on UHF. This could be probably adjusted in calibration, but the question is if the transistor and harmonics would allow that (as far as I can tell with with NanoVNA the harmonics are within or close to the legislative limits, unlike the terrible harmonics of UV-17Pro /UV-18 Pro Max/UV-21 Pro/BF5H radios).