em-trak R100 AIS Dual Channel Receiver

VHF Marine Band radios, protocol, radio communication theory, practical advice; AIS; DSC; MMSI; EPIRB.
jimh
Posts: 13367
Joined: Fri Oct 09, 2015 12:25 pm
Location: Michigan, Lower Peninsula
Contact:

em-trak R100 AIS Dual Channel Receiver

Postby jimh » Thu Nov 05, 2026 11:59 am

[Note: I have edited and updated this article several times since the initial posting, adding more illustrations and information.]

About 15-year ago in 2011, I was very interested in the new marine service of the Automatic Information System or AIS. At the time there were very few AIS receivers available, but a relatively new product from em-trak was the $220 R100 AIS receiver. The R100 supported the dual-channel AIS transmission protocol. em-track is the house brand for SRT Marine Technology, which was then and is now the very well established leader in AIS technology.

I used the em-track AIS R100 receiver as part of my mobile AIS receiving station, and wrote about my adventures in initial reception of AIS signals, which at that time were primarily being sent from larger commercial ships. My house was too far from navigable water with ship traffic, so I had to create a mobile AIS receiver, GPS receiver, computer, and chat plotter. A December 2011 article explained the details. See


At that time I was using the micro-USB port on the R100 to connect the data output of the receiver to my MacOS laptop computer. The "road warrior" setting put must have put too much strain on the micro-USB connector, and eventually mechanical problems with the connector caused intermittent connections.

Over time, manufacturers of VHF Marine Band DSC radios began to offer models that included an internal AIS receiver, which for shipboard use was clearly a better option than using the R100. The advantage of the DSC radio with AIS receiver was a separate antenna for the AIS receiver (as needed for the R100) was not necessary; the integrated AIS receiver would just share the DSC radio antenna.

Just recently, I dug out my R100 AIS receiver with the damaged USB-micro port and experimented with using its PWR/DATA port to get to the NMEA-0183 AIS data output. Herein I will give some details about using the NMEA-0183 wired signal from the R100 to interface with a computer. The computer in this case is the Apple Mac Mini M4 model, and the chart plotter application that will display the AIS data is OpenCPN.

R100 PWR/DATA Cable and Connectors

The R100 has a 12-pole connector and mating 12-conductor cable assembly that allows use without needing the micro-USB output. The engineers must have had some other features in mind, as six of the twelve conductors in the cable are designated "not used." As typical, the cable terminated in loose individual conductors, all with unique wire insulation colors. The active circuits are as follows:

    RED   = Power in +
    BLACK = Power in -

    BROWN = Transmit + (TALKER A)
    BLUE = Transmit - (TALKER B)
    GREEN = Receive - (LISTENER B)
    WHITE = Receive + (LISTENER A)

Note that the wire color coding from the R100 is NOT the recommended wire color code for NMEA-1083. This often occurs as manufacturers may not be able to source the particular wire colors recommended or designed their product before the NMEA organization published their standard wire colors. The now standard NMEA wire color coding is show below.

TALKER A = WHITE
TALKER B = BROWN
LISTENER B = GREEN
LISTENER A = YELLOW

Also somewhat ironically the R100 apparently does not respond to any input commands via the NMEA-0183 interface. I was hoping that perhaps the receiver provided some ability to accept input commands and produce some status output, such as the signal strength of the received AIS signals or an ability to set the baud rate. I suspect there might be such commands and corresponding output signals, but em-trak has not disclosed any. As a result, there is no purpose to having the R100 include LISTENER A and LISTENER B signals.

To terminate all of these loose wires into connectors, I relied on two standard conventions. For the 12-Volt power I used Anderson Power Pole connectors in red and black bodies with 15-Ampere contacts. However, these can be assembled in several ways, but I settled on a de facto standard in the Amateur Radio community, known as the Orange County RACES Power Pole standard.

RACES is an acronym for the Radio Amateur Civil Emergency Service. Apparently Orange County, California was the trend setter, and their configuration of the Powerpole connector became the standard.

For the NMEA-0183 connector, I used my own standard, nylon 0.100-inch header connector. (More details on the connector below).

The stock em-trak Power/Data cable with connectors added is seen in Figure 1 below:

Image
Fig. 1. The Power/Data cable for the em-trak R100 AIS receiver with connectors added for my application. The power conductors in the Power/Data cable are extended by a length of gray cable with red-black conductors to the Anderson Power Pole plug assembly for connection to a 12-Volt power supply.

Details of the wiring of the five-position nylon header connector
The five-position header connector is Molex nylon 0.100-spacing friction-fit header connector which will mate with five-pin headers on the "universal" NMEA-1083 interface motherboard header cross-connection system that I designed. The standard connector layout is thus:

    TALKER A
    TALKER B
    POWER COMMON
    LISTENER B
    LISTENER A

The connector body does not have position identifiers, but my standard is for the connector body to be oriented with the top and bottom edge extensions oriented to the right with the body oriented vertically and viewed from the back of the connector. All my NMEA-018 devices are wired in this way, no matter if they are balanced or unbalanced signals. When two NMEA-0183 devices using my standard connector and signal layout are connected to my motherboard with pin headers, the cross connecting of TALKER to LISTENER occurs via the wiring of backplane of the motherboard. On the motherboard with the header pins, the polarization of the headers is flipped for each pair set, so when the pins are wired straight across via the motherboard, the orientation of the connector flips, which creates the necessary cross connection of the signals.

The header connector details are as follows:
Connector Body
  • Molex 22-01-3057;
  • Headers & Wire Housings KK 254 Crimp Housing, Friction Ramp w/ Polarizing Ribs, 5 Pos., Natural
Connector Terminals
  • Molex 08-55-0102
  • Headers & Wire Housings KK 254 Crimp Terminal, Female, 30-22 AWG, 0.38 m Selective Gold (Au) Mating Pltg, Nickel Term. Pltg, Brass, Bag

The wiring of the R100 to the five-pole connector for the Universal NMEA backplane crossover is shown in Figure 2 below:
NMEAbalancedWiring.jpeg
Fig. 2. Wiring R100 to NMEA interface five-pole connector according to my own standard, as explained above.
NMEAbalancedWiring.jpeg (86.78 KiB) Viewed 677 times


The NMEA-0183 Cross-connect Motherboard
Figure 2 below shows my design for the NMEA-0183 cross-connect motherboard. The five-position pin headers are mounted in pairs, with the connector friction retainer orientation swapped on opposing sides. The header pin assembly detail is as follows:
  • Molex 22-11-2052;
  • Headers & Wire Housings KK 254 Solid Header, Vert., w/ Friction Lock, 5 Pos., 0.51 m Gold (Au) Pltg, 3.56mm Tail Lg., Bag

The circuit board that was used to construct the motherboard as seen in Figure 2 was from Radio Shack. In 2026 that particular circuit board is no longer available. I am looking for a substitute circuit board from currently available stock printed circuit breadboards that is particularly suited for making the cross-connect motherboard for NMEA-0183.

As seen in Figure 2, the connected device on the right is a NMEA-0183 balanced signal from the R100. On the left side is an RS-232 circuit from a USB-to-RS232 Serial Adaptor. The wiring of the cable also provides a circuit from the expected LISTENER B to the Power Common (middle conductor).
NMEA-0183Motherboard.jpg
Fig. 3. A universal NMEA-0183 motherboard or backplane with paired 5-pole connectors. The R100 is providing (A/B) balanced NMEA-0183 TALKER and LISTENER signals on the left side, and on the right side a special interface cable is carrying the signals to an RS-232 to USB serial adaptor via DB9 connectors.
NMEA-0183Motherboard.jpg (51.87 KiB) Viewed 1262 times


The TALKER A output of the R100 is on the brown conductor, which is then connected to the RS-232 RX-data input on the red conductor. The TALKER B output of the R100 is on the blue conductor and is not connected to anything, so it just floats.

The LISTENER A input of the R100 is on the white conductor (lower), which is then connected to the RS-232 TX-data output on the black conductor in the special cable.

The LISTENER B input of the R100 is on the green conductor, which is then connected via the wiring in backplane to the connector from the other device; that connector includes a jumper from the power common common of the other device to the pin where the TALKER B circuit is expected. In this way LISTENER B in the balanced device is connected to the power common in the unbalanced device actual wired connection that is provide in the special cable; this connection creates a path for the LISTENER B (which is from the other device which is assume to be using balanced NMEA-0183) to be connected to the common or ground (shield) of the RS-232 circuit (which in this case is the RS-232 port on the RS-232 to USB adaptor). This is another feature of my universal interface: one side can be a balanced NMEA device and the opposite side can be a single-ended NMEA-0183 device (or an RS-232 interface to a computer).


Special Cable RS-232 to NMEA-0183
The special cable for RS-232 on a DB9F connector to my standard 5-position header connect for NMEA-0183 is shown in Figure 2.

specialCableDB9Fto5PoleHeaderConnector.jpg
Fig. 4. Special cable assembly: RS-232 DB9F to 5-pole NMEA Crossconnect header.
specialCableDB9Fto5PoleHeaderConnector.jpg (78.1 KiB) Viewed 1768 times


The NMEA Cross-connect end of the special cable wiring is shown in Figure 4.

unBalancedNMEA-0183Con.jpg
Fig. 5. Detail of the wiring at the RS-232 connector.
unBalancedNMEA-0183Con.jpg (57.05 KiB) Viewed 1258 times


The other end of the special cable terminates in a DB9F connector, with the wiring as follows and illustrated in Figure 5:

DB9-F_Wiring.jpeg
Fig. 6. DB9F wiring detail.
DB9-F_Wiring.jpeg (59.22 KiB) Viewed 1768 times


PIN 1 DCD = Jumper to PIN 4 DTR
PIN 2 Rx Data = RED
PIN 3 Tx Data = BLACK
PIN 4 DTR = Jumper to PIN 1 DCD
PIN 5 GND = cable SHIELD conductor

As mentioned above, in the case of connecting the em-trak R100 AIS receiver, there is no particular need to allow the RS-232 device to send data to the R100 serial port input, but this was incorporated into the cable anyway. In this manner the cable is essentially a universal cable for connecting an RS-232 device to the NMEA-0183 cross-connect motherboard.

This completes the detailed explanation of the wiring and interface between the R100 wired NMEA-0183 output signals and the USB connection to the host computer that will be running the OpenCPN chartplotter application.

jimh
Posts: 13367
Joined: Fri Oct 09, 2015 12:25 pm
Location: Michigan, Lower Peninsula
Contact:

Re: em-trak R100 AIS Dual Channel Receiver

Postby jimh » Sun Nov 08, 2026 11:25 am

Here is a sketch showing the wiring of the entire circuit, beginning with the R100 output and ending with the RS-232 to USB convertor:

schematicNMEA-0183_Interconnection900.jpeg
Fig. 6. Schematic diagram of circuit for NMEA-018 connection.
schematicNMEA-0183_Interconnection900.jpeg (43.96 KiB) Viewed 1249 times


The special interface cable was designed so it can connect to the universal interface as an RS-232 device, and it does not know anything about the other device it is going to be connected to. The other device is assumed to be a NMEA-0183 device, but it could be either a balanced device (having both A and B signals) or an unbalanced device (have just the A signals). The cable wiring performs the following interconnections:
  • the RS-232 RXdata input is connected to the TALKER A output of the other device;
  • since RS-232 is single ended and has no differential input, the TALKER B signal from the other device is not connected and is left to float;
  • the RS-232 TXdata output is connected to the LISTENER A of the other device;
  • since the RS-232 is single ended, and has no differential output, the LISTENER B of the attached device is connected to the power common or ground of the RS-232 device;
  • the power common connects the power common circuit of the two devices.

jimh
Posts: 13367
Joined: Fri Oct 09, 2015 12:25 pm
Location: Michigan, Lower Peninsula
Contact:

Re: em-trak R100 AIS Dual Channel Receiver

Postby jimh » Sun Nov 08, 2026 11:30 am

Below is a sample of the AIS receiver data output in NMEA-0183 format. Most of the data in AIS Message 21 format.

    !AIVDM,1,1,,A,403Ow4QuLs>b2r3JNdH<Pc?02<0N,0*71
    !AIVDM,1,1,,A,403Ow4QuLs>e2r3JNNH<PWg020S:,0*2B
    !AIVDM,1,1,,B,ENk`t2<pp@@@@@@@@@@@@@@@@@@=1LCq;uCJ@00003vP000,2*0D
    !AIVDM,1,1,,B,ENkaSktpt@@@@@@@@@@@@@@@@@@=2NbL<8qKp00003vP000,2*6A
    !AIVDM,1,1,,A,403Ow4QuLs>gFr3JNTH<Pbw02H=;,0*75
    !AIVDM,1,1,,B,ENk`t5<t@@@@@@@@@@@@@@@@@@@=2EW9<88ch00003vP000,2*58
    !AIVDM,1,1,,A,ENk`t2<pp@@@@@@@@@@@@@@@@@@=1LCq;uCJ@00003vP000,2*0E
    !AIVDM,1,1,,A,403Ow4QuLs>hFr3JNfH<Pd?02D0N,0*72
    !AIVDM,1,1,,A,ENkaSmtKh@@@@@@@@@@@@@@@@@@=2ED;<8:J000003vP000,2*18
    !AIVDM,1,1,,A,403Ow4QuLs>l2r3JN6H<PbO025k@,0*00
    !AIVDM,1,1,,B,403Ow4QuLs>l<r3JN2H<Pa?025k@,0*7A
    !AIVDM,1,1,,A,403Ow4QuLs>mFr3JN<H<Pbg020S:,0*10
    !AIVDM,1,1,,A,403Ow4QuLs>n2r3JNHH<Pd?02L0M,0*25
    !AIVDM,1,1,,B,403Ow4QuLs>p<r3JNFH<PfO02D0N,0*41
    !AIVDM,1,1,,A,E>kaRkvVh@@@@@@@@@@@@@@@@@@=1`u1;v22800003vP100,2*5D
    !AIVDM,1,1,,A,403Ow4QuLs>r2r3JO>H<Pbw02<0N,0*73
    !AIVDM,1,1,,B,ENk`t1tHh@@@@@@@@@@@@@@@@@@=1Ulp;ulcp00003vP000,2*67
    !AIVDM,1,1,,A,ENkaSmdHqh@@@@@@@@@@@@@@@@@=2J0L<8So800003vP000,2*72
    !AIVDM,1,1,,B,ENk`t3Lps@@@@@@@@@@@@@@@@@@=1edI<18H@00003vP000,2*73
    !AIVDM,1,1,,A,ENk`t4dppr@@@@@@@@@@@@@@@@@=2;bd<7P@800003vP000,2*06
    !AIVDM,1,1,,B,403Ow4QuLs>rPr3JNfH<PcO02<0N,0*72
    !AIVDM,1,1,,B,ENkaSmdHqh@@@@@@@@@@@@@@@@@=2J0L<8So800003vP000,2*71
    !AIVDM,1,1,,B,403Ow4QuLs?<lr3JO2H<Pbw02D0O,0*14
    !AIVDM,1,1,,A,ENk`t3LpsA0@@@@@@@@@@E@@Ah4=7edI<18H@1@003vP000,2*2E
    !AIVDM,1,1,,A,403Ow4QuLs?S2r3JNhH<PWg02H1M,0*57
    !AIVDM,1,1,,A,ENk`t:LILh@@@@@@@@@@@@@@@@@=2e`P<:HJ@00003vP000,2*30
    !AIVDM,1,1,,A,403Ow4QuLs@;br3JOJH<P`g028Hq,0*31
    !AIVDM,1,1,,A,ENkaSmtKh@@@@@@@@@@@@@@@@@@=2ED;<8:J000003vP000,2*18
    !AIVDM,1,1,,B,ENk`t2<pp@@@@@@@@@@@@@@@@@@=1LCq;uCJ@00003vP000,2*0D
    !AIVDM,1,1,,B,403Ow4QuLs@<Pr3JO2H<PW?0260h,0*7F
    !AIVDM,1,1,,B,403Ow4QuLs@=lr3JO8H<PSw020S:,0*33
    !AIVDM,1,1,,A,403Ow4QuLs@B2r3JO8H<PVg02<0O,0*1E
    !AIVDM,1,1,,B,ENk`t:LILh@@@@@@@@@@@@@@@@@=2e`P<:HJ@00003vP000,2*33
    !AIVDM,1,1,,A,ENk`t4tq@@@@@@@@@@@@@@@@@@@=2@hJ<7fU@00003vP000,2*11
    !AIVDM,1,1,,B,403Ow4QuLs@P<r3JO0H<PbO02D0O,0*6D
    !AIVDM,1,1,,A,403Ow4QuLs@WFr3JO8H<PWg02H=;,0*73
    !AIVDM,1,1,,B,ENk`t5<t@@@@@@@@@@@@@@@@@@@=2EW9<88ch00003vP000,2*58
    !AIVDM,1,1,,B,403Ow4QuLs@dPr3JOfH<P`?0262h,0*46
    !AIVDM,1,1,,A,ENk`t:LILh@@@@@@@@@@@@@@@@@=2e`P<:HJ@00003vP000,2*30
    !AIVDM,1,1,,B,403Ow4QuLs@elr3JOpH<Pcg020S:,0*03
    !AIVDM,1,1,,A,ENk`t5<t@@@@@@@@@@@@@@@@@@@=2EW9<88ch00003vP000,2*5B
    !AIVDM,1,1,,B,403Ow4QuLs@glr3JO`H<Pa?02HNh,0*7C
    !AIVDM,1,1,,A,403Ow4QuLs@jFr3JO`H<P`?02<0O,0*74
    !AIVDM,1,1,,A,403Ow4QuLs@l2r3JO8H<Pc?0263@,0*5B
    !AIVDM,1,1,,B,ENk`t4dppr@@@@@@@@@@@@@@@@@=2;bd<7P@800003vP000,2*05
    !AIVDM,1,1,,B,403Ow4QuLs@nPr3JOjH<Pb?02L0O,0*1D
    !AIVDM,1,1,,B,ENk`t3Lps@@@@@@@@@@@@@@@@@@=1edI<18H@00003vP000,2*73
    !AIVDM,1,1,,B,ENk`t:LILh@@@@@@@@@@@@@@@@@=2e`P<:HJ@00003vP000,2*33
    !AIVDM,1,1,,B,ENk`t5Lqp@@@@@@@@@@@@@@@@@@=2eum<:Fdp00003vP000,2*28
    !AIVDM,1,1,,B,ENk`t3dIIh@@@@@@@@@@@@@@@@@=1e3@<1AD800003vP000,2*23
    !AIVDM,1,1,,A,403Ow4QuLsBIbr3JObH<PWg02@Hq,0*26
    !AIVDM,1,1,,A,403Ow4QuLsBJFr3JONH<P`g02<0O,0*20
    !AIVDM,1,1,,B,403Ow4QuLsBWPr3JOFH<PWO02HC2,0*45
    !AIVDM,1,1,,A,403Ow4QuLsBfbr3JO6H<PfO02L0O,0*0E

More information about AIS Message 21 is available from the USCG NavCenter:

https://navcen.uscg.gov/ais-aton-report

The AIS Message 21 is a rather complex method. I found a comment about the Message 21 design that suggested that the committee that came up with it must have been drunk when they wrote it.

jimh
Posts: 13367
Joined: Fri Oct 09, 2015 12:25 pm
Location: Michigan, Lower Peninsula
Contact:

Re: em-trak R100 AIS Dual Channel Receiver

Postby jimh » Tue Nov 10, 2026 2:45 pm

ASIDE: AIS Message 21 construction as criticized by AI:

AIS Message 21 (the Aids to Navigation / AtoN Report) is widely considered one of the clunkiest, most frustratingly formatted payloads in the entire maritime tracking standard.
Cf.: https://navcen.uscg.gov/ais-aton-report

If you are a developer struggling to parse it, you are definitely not alone. The committee that drafted it under ITU-R M.1371 definitely left the maritime community with an implementation nightmare.
CF.: [url]\https://www.itu.int/dms_pubrec/itu-r/rec/m/R-REC-M.1371-3-200706-S!!TOC-HTM-E.htm[/url]

The primary design quirks that make Message 21 feel like it was written after a few too many drinks include:

1. The Fragmented, Optional "Name Extension"

The basic payload includes a Name of Aids-to-Navigation field limited to 120 bits (exactly 20 characters in 6-bit ASCII). Because many lighthouses, buoys, and markers have names much longer than 20 characters, they had to create a way to extend it.

Cf.: https://navcen.uscg.gov/ais-aton-report

--Instead of just making a variable-length or clean secondary string, they appended a Name of Aid-to-Navigation Extension field at the very end of the message.

--This means you cannot reliably compute where the payload ends without dynamically calculating how many trailing bits were tacked on to finish a buoy's name.

Cf.: https://e-navigation.canada.ca/topics/aids/docs/message-21-en

2. Chaotic Bit Boundaries and Floating Spares

Because the name extension can be a variable length (0, 6, 12, ... up to 84 bits), it completely destroys byte alignment. To compensate for this, the specification introduces a variable number of Spare bits (0, 2, 4, or 6 bits) right at the tail end just to push the data back onto a byte boundary. Parsing it requires writing messy, dynamic shifting logic.

Cf.: https://e-navigation.canada.ca/topics/aids/docs/message-21-en

3. Slot-Guzzling Overhead

While standard ship position reports (Messages 1, 2, and 3) cleanly occupy a single 256-bit VHF data slot, Message 21 is a resource hog. It stretches across two full slots (up to 360 bits) to broadcast the static parameters of a physical or virtual object that literally isn't moving.

(Fun fact: The committee eventually realized this was a massive waste of bandwidth and introduced Message 28 in later revisions, which is a compressed, single-slot AtoN report—essentially admitting Message 21 was over-engineered).

Cf.: https://www.itu.int/dms_pubrec/itu-r/rec/m/R-REC-M.1371-6-202602-I!!PDF-E.pdf

4. Overlapping Virtual & Synthetic Flags

The way the payload differentiates between a physical buoy, a synthetic buoy (a real buoy but the message is broadcast from shore), and a virtual buoy (nothing exists in the water at all) requires evaluating a confusing mix of the Virtual AtoN flag and hijacking the Repeat Indicator field.

Cf.: https://navcen.uscg.gov/ais-aton-report


I found it curious that the AI comment refers to AIS Message 28, but that message is often not listed as an AIS message on web resources for AIS information. However, the definition for AIS Message 28 can indeed be found in the cited ITU recommendation included as a hyperlink above. For example, the USCG NavCen website lists AIS Message 28 and "Reserved or undefined." The NavCen listing is based on the ITU standard revision -5. AIS Message 28 is first defined in the ITU standard revision -6, as cited above.