TM-D710 bug – corupt MENU, resetting

Problem (probably) solved!

After many hours of testing, examining, evaluating data from other owners affected by this problem, I came to the following:
I have three news, one good and two bad ones.

Good news: I have found the problem at my station and it works just fine.
Bad news # 1: This problem is likely to sooner or later affects everyone who uses the APRS TM-D710
Bad news # 2: it is quite clear that even after the corrections (see description below) the state will be repeated after some time.


Problem description:


APRS data and MSG shall be kept in the memory of U2 (AT25256A10TU27). The same memory stores user settings and APRs (the menu 6xx). This is the standard serial EEPROM and the data sheet says that the lifetime of it is one million transcripts. Firmware in the panel is likely to be written so badly that this value will be exceed and destroys memory, respectively it will fail or malfunction. I do not know how FW is constructed, but if we count that one received frame = one rewrite, the following occurs: 10 packets per minute * 60 minutes = 600 / hour * 24 = 14,400 per day. The station would therefore have to survive unharmed 70 days of continuous operation. Real life is not exactly one million cycles, but it varies from piece to piece. Therefore it will be different time when the problem begins to occur.

At first, the stations which have turned on APRS and are always in a place with very dense APRS traffic will be affected. Furthermore, it depends on luck how quality memory is in the transceiver. Since I do not have the source code of the firmware, it is possible that the data is held directly in the CPU and the EEPROM will be overwritten once (the last 100 records) when you switch off the station.

It is obvious that the last 100 beacons are stored in the EEPROM, but that the S-RAM (IC13) records the Real Time Clock and configuration values for the TNC. Removing the rechargeable battery backup APRS list and APRS MSG will not be deleted. (This paragraph is only an estimation of the possible mechanism of the problem, without firmware source code it is not possible to make a certain and clear conclusion.)

How to fix the problem:
Memory U2 is about the middle of PCBs and is easily accessible. With quality equipment a replacement is a matter of minutes. Unfortunately, housing is very tiny and I recommend repairs to those who have experience with SMD soldering.

Unfortunately, until the Kenwood does not make new firmware, which will correct handling of memory and will continue to use the EEPROM as RAM, or if address field is not cycled to avoid entries in one place, the situation will probably appear again.

I think that I will make adapter flex PCBs, which are soldered instead of the original memory and the other end will be placed on a standard DIL socket memory.

The DIP8 25256A is much more accessible and the further replacement will not damage the PCB. The price of such an adapter would be very small, but the preparation for production is expensive. I’ll see if there is a demand for it. To spread one-time costs I would need to have made at least 20pc.
Regards Milan OK1MX

p.s. So far, I just checked it out on my TMD-710th Please send me feedback if my conclusions are correct.







My temporary test implementation: 🙂