Standard Horizon HX851E

The Standard Horizon HX851E is a marine VHF radio sold to operate on the maritime 2-metre band between 156 MHz to 163 MHz. It has a large physical volume compared to its mass, which allows it float to when dropped in the water: the exact opposite to the HX370 SAS! The handheld has a built-in GPS receiver, and modem for DSC/ ATIS digital messages. You need to turn the GPS unit off to get decent away-from-charger battery life. On the whole it is a very satisfying unit and although not stated, is programmable to amateur 2-metre band aswell, and probably even the whole of ~137 MHz to 174 MHz based on what similar radios, such as the HX370E, are advertised as doing.

The marine VHF channel names are customisable and so I have several set to useful local names such as VTS London, SAR Trent, Limehouse as a mental aid. I'm an Ubuntu/Debian user and primarily wanted a backup of those custom channel name settings which I could keep somewhere safe. The normal Swiss-Army knife for this on Linux is Chirp, which supports a bunch of other Yaesu/ Standard Vertex radios, but doesn't (yet) have support for the HX851 family.

Physical form

The base of the HX851 contains a pair of data pins on either side, which are used for three purposes:

1. NMEA 0183 GPS send ^{4800 band}
2. NMEA 0183 GPS receive ^{4800 band}
3. Submersion detection (flashing Hazard LED activation when dropped) ^{S-O-S in Morse}
4. PC programming ^{19200+57600 band}

Submersion detection is mutually incompatible with NMEA GPS receive because these utilise the same external pins. When the radio is dropped, the two data pins are shorted by the impurities in the water; and this interrupt is then used to activate the bright white LED. Serial receive would want to use the same incoming signal and would be shorted out. So you have a choice, and the choice can be altered with: CALL ENT^{[2 sec]} → Radio Setup → LED Setup → Water Hazard → LED → On/Off.

Pins

The electrical communication pins are designed to be used via the supplied CD-38 docking station which contains the intelligent charger gumbins, but for the serials pins are passed through. The supplied rolled-up (unterminated) three-wire serial cable, is linked in the docking cradle to three pins on the transceiver itself:

• Green: Serial ground (GND-) ^{[back left, battery negative contact]}
• Brown: Serial out (TX+) ^{[front left, RS-422 data connector]}
• Blue: Serial in (RX+) ^{[front right, RS-422 data connector]}

External PC Programming is performed through these serial pins exposed via the docking station. Note that other Yaesu/ Standard Horizon portable transceivers are generally programmed via the microphone jack, but this is not the case with the HX850/HX851.

For the RS-232 PC serial connection, I crimped a 6P6C 'RJ11' onto the exposed cable, and linked up an RJ45 jack socket to a USB serial adaptor. The small modular plug can be rolled up and shoved back inside the dock with the tiny cable, although I might exchange it for a narrower 4P4C "headset" jack plug if I can find a suitable socket to plug it into. Do not get stressed if it does not work first-time, the voltage levels are finicky and there's a reasonable chance the first adaptor will not work! This is because it is trying to be balanced RS-422, but without the balanced wires, and instead using power-supply ground for both TX- and RX-.

The access sequence to place the HX851 in programming mode to is power off; then to press and hold DISTRESS^[hold]+CLASS ENT^[hold] + POWER. The display will show "PC CONTROL WAITING", and the present firmware version is displayed just below as "-Ver 2.13-". Afterwards it will state "AUTOMATIC CONTROL CP MODE".

Channels

There are five/six channel banks; USA^{Group 1}/INTL^{Group 2}/CAN^{Group 3}, Weather, and EXP. The UK (European) HX851E model comes switched to Group 2 by default, plus the first two entries in Expansion group pre-populated with M1^{157.850 MHz, Ch 37} and M2^{161.425 MHz}. Bank switching is performed with 16/9^[hold]+CLR. I suspect there is a sixth hardcoded ATIS channel group with RAINWAT transmit/power restrictions ATIS, but also kneecaps the radio on the basis of a (presumably well-intended, but ultimately misguided) reading of the RAINWAT requirements applying to large vessels over 20 metres.

Main channel bank

Channel bank Groups 1–3 have arrays of hardcoded frequencies, but binary toggles for Enable, TX Enable, Low Power and "Power Up", Duplex, Scan Memory and a ten-character freeform customisable Channel Name. Seemingly, the TX enable and power level bits together combine for the firmware-coded level of Off/1W/2.5W/5W/6W power setting. I'm unclear as to whether the Duplex flag causes a forced 4.6 Mhz offset, or whether it unmasks the hardcoded Transmit frequency already recorded in the firmware. "Power UP" is "User Power", ie that the user may manually boost the power level from the radio even if that channel defaults to 1W.

Programming Channel Names on the transceiver itself has a ten-character limit, but twelve is seemingly allowed, but not displayable in all default screen modes.

Weather bank

There are ten hardcoded receive-only Weather channels, all of which have corresponding Enable and Scan boolean flags, plus a customisable free-form alphanumeric name. The weather bank is reached by holding CLR^{[2 sec]}.

Expansion bank

The Expansion group is the only one that is fully programmable. Each of the 40 slots has RX Frequency, TX Frequency, Visible/Enable, TX Enable, Low Power and "Power Up", Duplex and Scan Memory; plus the customisable Channel Name.

ATIS

Automatic Transmitter Identification System (ATIS) digitally transmits the identity of the radio after each voice broadcast, as soon as the push-to-talk button is released, using FSK and the same transmission format as DSC. The ATIS-mode post-transmit messages "squawk sequences" can be enabled or disabled for each of the USA/INTL/CAN/EXP groups. Though doing so seems to apply the additional RAINWAT mandated restrictions disabling dual-watch, disabling scan.

There is also a bitmask enabling or disabling the ATIS Killer (ATIS squelch) on each of the channel banks, and this is done with the same FM FSK detection as for DSC on Channel 70.

The manual states that in ATIS mode, transmission is restricted to Channel 15 and Channel 17, for on-board hand-held communications use only. This requirement only applies in some countries covered by RAINWAT, and only to vessels over 20 metres in length. On previous Standard Horizon radios the tendancy was to reprogram the Group 3 bank to a much more limited power and channel set.

Serial Protocol

The main communication protocol for the radio is NMEA 0183-ish: it is ASCII text based, line-buffered, with lines ending '\r\n' and it runs over the same pins as the NMEA 0183 GPS data. Differences are that commands start with '#' (instead of NMEA 0183's '$'), that tabs ('\t') are used as the separator (instead of NMEA 0183's ',' commas) and the conversation takes places at 57600 baud. Commands are acknowledged by either end with #CMDOK, and then any data requested as a subsequent message. CM is also the NMEA talker ID for "Computer Memory Data", I don't know whether this is a conincidence.

Knock sequence

The user must place the radio in control mode using the special power sequence. Communication in the first simple mode takes place at 19200 baud, and starts with exchanging pings with the transceiver, using the single byte character 'P'. If the speed and mode match, the radio will reply with a pong message, also consisting of a single 'P'. This is repeated until the current speed of the radio is confirmed after which it can be switched into AUTOMATIC CONTROL MODE, by sending ACMD:002, and waiting for the radio to respond with OK.

Automatic Control mode

Data is ASCII-Hex encoded: 0xff is transmitted as the string literal "FF". Messages with data have a NEMA 0183-ish checksum at the end, which is also ASCII-Hex encoded, and is the result of XORing together the command string starting from the hash character ('#') and proceeding until the final tab ('\t') separator. In Python: hex(reduce(xor, map(ord, s[0:-2])))[2:].upper() This checksum appears to be checked, but with no provision/attempt for retry.

Useful EEPROM data seems to be populated between 0x0002–0x1870 (~6.5kB), with the rest of the 16kB filled with 0xff except for the last two bytes 0x3ffe–0x3fff, which match the first two bytes and collectively act as a sanity check: both contain the decimal model number (851) stored as a 16-bit integer (0x0353).

Memory image

A few hundred #CEPRD calls later and we our 16kB offline backup of the raw EEPROM settings contents.

Easy to spot locations are:

0x0300: Expansion channels flags. 0x80 Lower Power | 0x10 User Power Up |

Chipset

The Service Manual claims that the EEPROM for the settings and channel banks is a I²C serial EEPROM, listed as an ROHM BR24L64-W 8kB (64kbit), but as can be seen here, it would appear to be a 16kB (128kbit) part. Perhaps the HX850 was 8kB, and the HX851 is 16kB, but otherwise the systems are the same; AFAICT the only difference is ATIS support, and it's the same FM decode that does DSC and ATIS (both are the same underlaying ITU-R Recommendation 493 protocol/message format).

The heart of the transceiver is a 100-pin NEC µPD78F1167GC 16-bit system-on-a-chip, 78K/0R CPU, with 384 kB of flash, 24 kB of RAM and running at 10MHz. There is seemingly a self-programming mode in the chip; but there are also ICE/JTAG FLMD0/TOOL0/TOOL1 pins.

Firmware

The UK-model I got has "CPU" firmware version 2.13. References to other firmware versions on the web include version 2.10 and version 2.06.

Alignment data

Haven't found this yet; it might in the firmware flash rather than the EEPROM. I'd really like to fix the overly-large squelch and volume steps, and battery voltage gauge that seems to go from 100% full to 100% empty in hardly any time.

Other radios

The GX2100/GX2100E/GX2000/GX2000E (seemingly product ID 'AM044N') uses exactly the same programming protocol, although the layout of the memory map is different, and it has a 32kB EEPROM. Same for GX1600 (ID 'AM048N'?) which is a 32kB EEPROM, but starting at offset 128 (0x80). Seemingly alot of the radios utilise the same EEPROM read/write protocol.