Yaesu FT-857D Crashes (reboot loop) after programming a 4 character channel label with CHiRP

I found a small latent problem in the Yaesu FT-857D firmware which could cause the radio to crash and go into a reboot loop when a 4 character or less label was created using the free CHiRP radio programming software. I isolated the problem, the Yaesu FT-8[59]7 driver in CHiRP now works around the problem starting with daily builds around June 27th, 2013.

This blog post just archives the info in case someone else stumbles across the problem either by using an outdated version of CHiRP or writing their own software for manipulating the Yaesu FT-8[59]7 memory. This probably applies to the FT-897(d) as well.

The problem has to do with how the 8 character memory label is padded.  The older versions of CHiRP were padding unused characters with 0xFF.  An unused memory label defaults to eight bytes of 0xFF on the radio.   When a label is created for a memory (channel) on the radio, it is set to 'CH-NNN  '.  There is no way that I found, from the radio to create a memory label that wasn't space padded.  Padding with 0xFF for labels that are 5 characters or more doesn't seem to cause any issues. The corrected version of CHiRP now space pads the label out to 8 characters.  I believe G4HFQ's FTbasicMMO, only space pads as well.

Marco Filippi, IZ3GME the primary author of the FT-8[59]7 driver made the change within hours of me reporting the problem.  The very next CHiRP build had the fixed version of the driver.  The current release of CHiRP, 0.3.1 from April 2013, has the old driver.  Until a version later than 0.3.1 is released, you need to download a daily release.

I believe I'm justified in calling this a small bug in the Yaesu firmware, because when the radio accesses the memory with the 0xFF padded label, it goes into a continual reboot cycle with lots of clicking of relays and a beep each time it restarts.  From the radio itself, the only way to resolve this is to force a reset which will clear some of the settings and/or memory entries depending upon which reset is used.  My opinion is the radio's firmware should be a little more forgiving than this.

Note: if your Yaesu FT-857/897 ever does get stuck in a crash/reboot loop, you can still get into clone mode, and save a copy of the whole set of radio settings and memories before you reset it. 

Another thing I learned about the FT-857/FT-897 firmware during all of this is that it is nearly impossible to get a pristine memory image from the radio.  The radio has three different types of resets which will clear all memories, some settings, and a "full microprocessor reset" which is supposed to return the radio to all factory settings.  However, the way this is implemented, the eeprom isn't really reset to a known default, just select bits are cleared marking all of the memory entries unused.  Most of the previous memory channel settings, including the label are still there, which makes things confusing if you were looking for clear, reproduceable state.

(Note: There probably is a way to completely clean the EEPROM to a known, reproduceable state, but you don't want to use it.   For some reason, Yaesu's firmware writers included a CAT command which would completely reset the radio including the specific calibration settings that are written into EEPROM for each radio.   Unforatunely, it's not that improbable to accidentally trigger this when using the CAT interface a lot, possibly with a baud rate setting mismatch.  Every FT-8[59]7 owner should use the service menu to record all of the calibration settings in case they are ever lost.  This has been documented on the FT-857 and FT-897 Yahoo group's.   There is also a few pieces of software, including a PERL script from 0xdecafbad.com for reading out the calibration settings over the CAT interface using the undocumented CAT peek command.

Hopefully I'll get around to posting and documenting more of the things I've learned about the FT-857d.  All of the information is out there, but not necessarily organized to make it easy to find.

References

• CHiRP Issue 937 (bug report for FT-857 crash
• 0xdecafbad's FT-8[59]7 Calibration Dumper - ft897calibration.pl PERL script
• 0xdecafbad.com Blog Post about the calibration dumper

Understanding the Arduino platform (You don't need a separate Arduino board for everything you build)

From time to time, I've heard some objections about using the Arduino platform to build things because of the costs. Arduino prices have come down, but it's also worth understanding you don't need an Arduino board for every project.
The Arduino is essentially a board that has an Atmel AVR ATmega328p microcontroller chip on it with a USB interface, power supply, clock crystal, and a lot of sockets for the pins in a (now) well known form factor that allows stacking additional board/modules called shields for additional functionality.
The older units had an FTDI USB serial interface chip on it which added significantly to the cost, but had some interesting alternative uses. Newer Arduinos use another Atmel AVR chip that has USB support built in, which winds up being less expensive than the FTDI chip.
The form factor (size of the board with pin sockets) makes it easy to get started and prototype but also adds to the cost.
The Arduino software environment also makes it significantly easier to get started with microcontroller programming.  There is an small, development environment for Windows/Mac/Linux which completely wraps the C/C++ compiler and chip programmer making it a simple push button operation to compile your sketch and program the chip.
The AVR microcontroller is essentially a full system on a chip, with an 8 bit CPU, a small amount of RAM, 32K of flash memory, a small EEPROM, and a TTL level serial interface.  There is even an internal oscillator so you don't have to use a separate crystal, or resonator, if you have an application where you don't need the timing stability offered by an external crystal.
Bare ATmega328P chips cost $2-4 in single quantities.  They come without any programming, so you need hardware to program the chip.
The Arduino gets around the need for having hardware to program the microcontroller chip by preloading a bit of firmware, a boot loader, that allows the chip to receive code over the USB/Serial interface and write it to the 32K flash to program itself.
An Arduino can be used to program bare AVR chips, so you can use one Arduino to create more Arduinos.
So the moral of the story, once you've built something using an Arduino, you don't have to dedicate a whole Arduino board to each device.  You can easily build your project with a bare AVR chip and only the supporting components you need for your projects.  Typically this can be done for less than $5.

Note: This post is another reply that I had sent to a mailing list that I thought would be worth preserving and sharing as a blog post.