Standard Horizon HX870 / HX870E

The HX870 is the successor to the Standard Horizon HX851 marine VHF radio. This page was inspired by a collection of information about the HX851 by Paul Sladen. I originally created this page for my own use, then decided it might also be of use to others.

By now the HX870 has a successor as well. Please see the HX890 page created by Robert Elsinga for its technical details.

I do not work for Standard Horizon / Yaesu, nor do I have first-hand “inside” knowledge about any of their products. The information on this page was gathered by playing around some with HX870 and HX870E radios and the YCE15 software that goes with it. Several radio users contributed information to this page; Norm Perron and Christiane Rütten were particularly helpful.

Disclaimer: Modifying the memory image directly using a hex editor is likely not a supported function of the device or its accompanying software. As such, it might void your warranty or brick the radio or even put it into a state where it transmits or receives on frequencies forbidden by international Radio Regulations, local regulations (FCC / BNetzA / …) or local law. Using the radio in such a state might disrupt vital safety-of-life services. Many jurisdictions impose a fine or criminal penalty on it. You should not mess around with any of this stuff unless you know what you’re doing! And, to finally state the obvious: Whatever you do, I cannot be held responsible for it.

Serial protocol

Please refer to the documentation of the HX870 Python tools.

Memory image

32kB EEPROM, stored by Standard Horizon’s YCE15 software as a *.dat file

You can read and write the radio’s EEPROM using the amazing SHsync Web application. Unfortunately, it requires the Web Serial API, which is currently only natively available on Chrome and Chromium-based browsers.

If you own 010 Editor, you may find the binary template included with the HX870 Python tools most useful. The Python tools also allow reading and writing the radio’s EEPROM on operating systems that can’t run YCE15, such as macOS.

The significance of memory locations marked with a yellow background has not been discovered.
Memory locations marked with a green background appear to have constant values (padding etc.) and can probably safely be ignored.

0xff is used as a generic unused/disabled/padding value for many fields.

Characters are coded as fixed-length ASCII strings (permissible chars include: A-Za-z0-9 &'*,-.:/[]) with 0xff padding, but apparently many strings cannot be used to their full length due to UI limitations.

DSC addresses presently consist of the nine-digit MMSI and a tenth digit, reserved for future use. They are coded with the full ten digits. The last digit is always zero as per Rec. ITU-R M.1080.

There is a bug in the YCE15 software versions 2.0.0.4 and 2.0.1.0 that can cause corruption of the DSC individual directory (likely also other directories) when opening a memory image file containing directory entries that are not alphabetically sorted. However, the bug is only triggered when the “Individual Directory” item is chosen in YCE15. If instead the memory image is directly programmed into the device without first viewing the directory in YCE15, the result is just fine.

Apparently the firmware “knows” whether the radio model is a HX870 or a HX870E independent of the accessible memory content. Non-E models don’t get the region selection menu. However, it would seem logical for this to be defined in software rather than hardware. How does that work? Does perhaps the Windows firmware update software silently modify the firmware based on whether or not an E model is detected before the update (possibly using byte 0x010f)?

An issue seems to sometimes prevent reading values of certain fields from the radio’s memory. This affects memory locations 0x0006, 0x000b–0x000d, 0x0110–0x011f amongst many others. Instead of the true values of those fields, default or padding values appear to be returned. However, locations 0x0010–0x013 and 0x0060 are not affected. While it is not yet clear whether this is an issue with the firmware or YCE15, reading the memory using pyhx870 appears to often yield the true values.

The “activation per channel group” for RG and EXP doesn’t seem to work as I think it should. This ought to be solvable, as the region modes UK and SW contain RG channels that use these activation bits.

Channel Index

The “channel index” is used to specify individual channels in the memory image. This is simply the position of the respective channel in the channel list of the respective channel group, starting with 1. For example, the “USA” channel group begins with channel 01A, so the number 1 would refer to that channel; number 2 would refer to the next-higher channel, which in “USA” mode is channel 03A; and so on.

Note that none of the default channel lists are fully consecutive. Many have extra channels inserted (for example, Canadian channel 25B is inserted between channels 25 and 26), and for historical reasons, the international channel plan has a big gap before channel 60. Therefore the only way to determine or to resolve channel references is to get a list of all your channels (for example in YCE15 or in the radio itself) and count down from the top, starting with 1 for your first channel. An easy way to do this might be to list all your channels in a spreadsheet application.

“RG” regional and “EXP” expansion channels are appended at the end of the channel list in that order (perhaps “WX” weather channels, too – not sure about these).

I’m not 100 % sure the count matches my data here. The issue appears to be in the upper channels. Does channel 70 maybe not count in the index? How about other "transmission forbidden" channels? Or am I simply counting wrong after all?

The status byte can be used in the preset lists to signal whether that preset is enabled. For other uses of the channel index, it is usually zero.

Sometimes the status byte duplicates the channel byte's value rather than being zero. Different values have also been observed. The significance of this is unclear.

There is some sort of bug in the YCE15 software version 2.0.0.4 that can result in unusable Presets. For example, when setting an “EXP” channel as a preset (possibly also when simply setting a preset to “none”), byte values in the range of 0x81–0xff are set. This results in channels with unusual numbers like “00” or “43” in the radio that give off funny noises when they’re selected.

Internal Position Format

Setup 1

GPS Time Setup

0x80 = 1xxxxxxx = local time (0 = UTC)
0x40 = x1xxxxxx = 24 hour clock (0 = AM/PM)
0x20 = xx1xxxxx = time offset has positive sign (0 = negative sign)
0x1f = xxx11111 = time offset in half hours

Examples:
0x60 = 01100000 = UTC
0xe2 = 11100010 = British Summer Time (UTC +01:00)
0xe4 = 11100100 = Central European Summer Time (UTC +02:00)
0x9e = 10001110 = Pacific Daylight Time AM/PM (UTC -07:00)

GPS Output Sentences

0xc0 = 11xxxxxx - unused
0x20 = xx1xxxxx = DSC/DSE
0x10 = xxx1xxxx = RMC
0x08 = xxxx1xxx = GSV
0x04 = xxxxx1xx = GSA
0x02 = xxxxxx1x = GGA
0x01 = xxxxxxx1 = GLL

Setup 2

DSC Call Categories

0x80 = 1xxxxxxx = Distress
0x40 = x1xxxxxx = Urgency
0x20 = xx1xxxxx = Safety
0x10 = xxx1xxxx = Routine
0x0f = xxxx1111 - Hi/Low Tx power on channel 70 by category?

Note: The DSC call categories (priorities) are prescribed by Rec. ITU-R M.493. The HX870 by default correctly implements the category options for class D radios, except that the HX870 additionally allows position request and polling calls.

DSC Individual Call Reply

0x80 = 1xxxxxxx = automatic reply
0x40 = x1xxxxxx = reply 'able'
other bits: unknown

Values seen:
0x38 = 00111000 = automatic 'unable' reply disabled
0x78 = 01111000 = automatic 'able' reply disabled
0xb8 = 10111000 = automatic 'unable' reply enabled
0xf8 = 11111000 = automatic 'able' reply enabled

DSC Beep Settings

0x80 = 1xxxxxxx = Individual
0x40 = x1xxxxxx = All Ships
0x20 = xx1xxxxx = Group
0x10 = xxx1xxxx = Position Request
0x08 = xxxx1xxx = Position Report
0x04 = xxxxx1xx = Geographic
0x02 = xxxxxx1x = Polling
0x01 = xxxxxxx1 = Test Call

Default value:
0xec = 11101100 = always, except for POS requests, polling, and test calls

Region Selection

HX870E radios are usually distributed with a leaflet in the packaging explaining how to set a region. The HX870 model (non-E) is apparently hard-coded to only support Canada as a region.

The region can be selected by holding down MENU and 16/S while turning on the HX870E. The menu described in the leaflet will then appear. Selecting a region will primarily affect channel group 3 and the regional (RG) channels, resetting channel flags and names to whatever the factory settings are for the selected region. The following group 3 regional modes are available for the HX870E:

Some of the region names Standard Horizon use in the menu are confusing to say the least. For example, a vessel sailing the German Baltic coast would need an international channel plan. It might seem logical to select “INTERNATIONAL” or “GERMANY” as regional mode, but neither one of those would yield an international channel plan in group 3. Instead, you would want to either use the “INTL” channel group 2, which isn’t affected by the regional mode setting at all, or “SWEDEN” mode for channel group 3, which has the benefit of enabling the Danish leisure channels.

Notably, “NETHERLAND” mode provides an international channel plan even though the extra channels are mostly useful in Dutch inland waterways, where RAINWAT applies. This looks like a firmware bug.

Channel Group Definition

Only the first three channel groups are in fact available for use. YCE15 uses the “ATIS enabled” field of the fourth channel group definition (memory location 0x00a2) to decide whether or not to display the ATIS setup (0x00=no, 0x01=yes).

Call History Entry

The entries are listed in descending order of age (oldest first).

The presumed “call type” or “priority” field is usually 0x03 for individual/group calls and 0x02 for position request/report calls. Polling and test call histories appear to either share the same memory area; it’s not yet clear whether they are differentiated by the “call type”/“priority” field, or whether there are columns in this area (left column polling, right column test).

It is not known why the channel is recorded in the history in addition to the log.

Marine Channel Flags

0x8000 = 1xxxxxxx xxxxxxxx = frq shift Rx only
0x4000 = x1xxxxxx xxxxxxxx = frq shift Rx and Tx
0x2000 = xx1xxxxx xxxxxxxx = high power allowed
0x1000 = xxx1xxxx xxxxxxxx = Tx allowed
0x0800 = xxxx1xxx xxxxxxxx = high power allowed, but low power is default
0x0400 = xxxxx1xx xxxxxxxx - unused?
0x0200 = xxxxxx1x xxxxxxxx = channel suffix: "B"
0x0100 = xxxxxxx1 xxxxxxxx = channel suffix: "A"
0x0080 = xxxxxxxx 1xxxxxxx = DSC ship/ship channel
0x007f = xxxxxxxx x1111111 = channel prefix: 0x7f=none, other=numeric

Frequent combinations:
0x30ff = 00110000 11111111 = ship/ship channel
0x10ff = 00010000 11111111 = ship/ship channel, limited to 1W
0x18ff = 00011000 11111111 = ship/ship channel, defaults to 1W
0x307f = 00110000 01111111 = simplex channel
0x107f = 00010000 01111111 = simplex channel, limited to 1W
0x300a = 00110000 00001010 = simplex "10" channel
0x7014 = 01110000 00010100 = simplex "20" channel
0x317f = 00110001 01111111 = USA "A" channel
0x827f = 10000010 01111111 = CAN "B" channel
0xb07f = 10110000 01111111 = duplex channel
0x907f = 10010000 01111111 = duplex channel, limited to 1W
0x007f = 00000000 01111111 = Tx forbidden

Some other useful combinations:
0x807f = 10000000 01111111 = duplex channel, Tx forbidden
0x987f = 10011000 01111111 = duplex channel, defaults to 1W
0x187f = 00011000 01111111 = simplex channel, defaults to 1W
0x197f = 00011001 01111111 = simplex "A" channel, defaults to 1W
0x5a7f = 01011010 01111111 = simplex "B" channel, defaults to 1W
0x180a = 00011000 00001010 = simplex "10" channel, defaults to 1W
0x5814 = 01011000 00010100 = simplex "20" channel, defaults to 1W
0x4014 = 01000000 00010100 = simplex "20" channel, Tx forbidden

DSC ship/ship channels (also known as “ship to ship” or “intership” channels) are those channels that the radio offers to choose from e. g. when initiating a DSC individual call. Any channel can be added or removed from that list simply by setting or clearing its “ship/ship” flag in the bitmask described above. An arbitrary channel can also be chosen for a DSC call after pressing the “manual” soft key, but customizing the list of ship/ship channels may be useful to streamline routine operation.

Firmware 2.03 appears to have a bug in the “GRMN” (RAINWAT) channel group: Channel 20 doesn't have the “high power allowed” bit set although high power is allowed. This is easily fixable by modifying memory location 0x0955 in the memory image from 0x90 to 0xb0.

Firmware 2.03 also appears to set the “suffix A” bit for channel 88, but not for 87 for the USA channel group. Given that both channels were redefined at the same time for the introduction of AIS, it’s clear that either both or none should have the “A”. According to the manual, both should have the suffix, but according to the Coast Guard, neither should have it.

Firmware 2.03 appears to have an additional bug in the “INTL” channel group (possibly others as well): Channels 15 and 17 are no longer a guard band for channel 16 as per ITU RR (App. 18) and Rec. M.1084. Transmitting with full power is allowed on these channels unless they’re used for internal on-board communication. It would appear to make sense to at least code these as “low power default” if not “unrestricted power”.

Private Channel Definition

0x08 = xxxx1xxx = low power
0x04 = xxxxx1xx - ?
0x02 = xxxxxx1x - ?
0x01 = xxxxxxx1 = user power up

Frequent combinations:
0x00 = xxxx0000 = standard
0x08 = xxxx1000 = limited to 1W
0x09 = xxxx1001 = defaults to 1W
0x06 = xxxx0110 = ?

Illegal combinations:
0x0a = xxxx1010
0x0b = xxxx1011
0x0c = xxxx1100
0x0d = xxxx1101
0x0e = xxxx1110

Group Monitor Definition

Waypoint Definition

Waypoints created on the device from any source other than a DSC position report have the usual 0xff… placeholder in the MMSI field, except that the last nibble is 0x0. This looks like a firmware bug.

Call Log Entry

DSC Call Type

0x0112 = Distress
0x0114 = Group
0x0116 = All ships
0x0120 = Individual

DSC Category

0x0100 = Routine
0x0108 = Safety
0x0110 = Urgency
0x0112 = Distress

DSC Message 1

For calls of type “Distress”: Nature of distress
0x0100 = Fire, explosion
0x0101 = Flooding
0x0102 = Collision
0x0103 = Grounding
0x0104 = Listing, in danger of capsizing
0x0105 = Sinking
0x0106 = Disabled and adrift
0x0107 = Undesignated distress [default value]
0x0108 = Abandoning ship
0x0109 = Piracy / armed robbery attack
0x0110 = Man overboard
0x0112 = VHF EPIRB Emission

For other call types: First telecommand
0x0100 = F3E/G3E all modes telephony
0x0101 = F3E/G3E duplex telephony
0x0103 = Polling
0x0104 = Unable to comply
0x0110 = Distress acknowledgement
0x0112 = Distress alert relay
0x0118 = Test
0x0121 = Ship position or location registration updating
0x0126 = No information [default value]

DSC Message 2

For calls of type “Distress”: Subsequent communication mode
0x0100 = F3E/G3E all modes telephony [default value]

For other call types: Second telecommand
0x0100 = No reason given
0x0126 = No information [default value]

DSC Frequency or Channel Information

0x90____ = last four nibbles represent the VHF channel, coded as BCD
0xffffff = no information

DSC End Of Sequence

0x0117 = individual call requiring acknowledgement
0x0122 = answer to call that required acknowledgement
0x0127 = other call

Reference: Rec. ITU-R M.493, section 8 “Messages” and table A1-3 “Use of symbol Nos. 100 to 127”