The picture on the left is a thumbnail of the schematic of the electronics on board Sarah.  Double click on the thumbnail to download the full-sized graphic.

The rest of this page contains descriptions and pictures of the individual electronic devices installed on Sarah plus a little history of my efforts to integrate these devices as depicted in the schematic.

In 2001 I acquired a used ICOM M700 SSB from Dick Juppenlatz (Cruising Services and Supplies) for the Bermuda trip.   It was also modified by Dick to allow the connection of a PACTOR Modem.

The picture on the right shows the nav station as it was for our 2001 trip to Bermuda.

Although not shown in this picture I put a couple of webbing and Velcro cable ties on the mast below the instrument.  I coil the excess cable for each instrument and secure the coils in these ties.  The ties are intended to secure a shore power cable to a dock, but they work great for this application as well.

When I installed the Raytheon autopilot I elected to put the main control in the Navigation station and put only the remote control in the cockpit - mounted on the aft side of the mizzen mast.  The autopilot remote has an LCD display, which now thanks to the installation of all Raymarine instruments can display the information from any of those units.  See the picture on the right of the remote displaying the current information from the wind instrument.  The LCD is a little small for my weak old eyes, but I can always pick it up and bring it close to my face.

So this is my compromise on instrument placement.  The main displays on the bridge deck so they can be visible from anywhere in the cockpit with the autopilot remote providing all of the displays directly to the helmsperson.

By hanging in there, bidding only to the price I was willing to pay, I was able to acquire the computers at what I consider a good price.  For each computer I had to bid on 3 or 4 auctions in a row until I was finally not out bid at my target price.  For 3 years these computers performed very well for all intended applications.  I set them up as mirror images of each other with the same software.  If one fails I can switch to the other with minimal setup time.  The only real drawback to acquiring computers from the Dell Auction is that Dell does not load all of the required drivers (video, touchpad, sound, etc.).  You really get a basic computer!  However the Dell Support web-site provides all of the necessary drivers and will analyze the computer and identify the drivers required.  If you are reasonably computer literate, this is not a big deal - it just takes an hour or so (depending on your internet bandwidth) on-line to the Dell site.  If your only internet access is via HF radio, these computers are probably not for you.

Dell typically has several dozen of these computers up for auction at all times.  Similar computers at similar prices can be purchased through eBay.

In 2008 I replaced the two Dell C600 notebook computers with Dell D600 computers, again from the Dell Auction site.  These also are nearly identical computers - 1.6-1.7 GHz, 1024 MB RAM, 50-60 GB Disk.  These computers run under WinXP rather than Win2K - for awhile all of my computers used the same OS. 

I replaced the C600s because the hard drive on one computer crashed hard and several keys on the other are missing from the keyboard.  I combined these two computers to make one working computer with all of the keys on the keyboard.  However that did not provide an identical backup.  I eventually gave away the single working C600. 

The shelf is a little wobbly as it is only a cantilever arrangement and there is some play in the brackets, but I believe it is secure and will not easily come loose.  I also do not believe the computer will come loose from the shelf.  Maybe a pitch poll will destroy this arrangement, but then the computer will be the least of my concerns.  This installation worked fine for the Atlantic crossing in 2005, my Mediterranean cruise in 2006, the return to the USA in 2007 and has continued to serve this purpose in 2015. 

It only takes a few seconds to remove this shelf from the wet locker door for access to the locker; however, my plan is to keep foul weather gear in the shower stall while off-shore.  So access to the wet locker should not be a frequent requirement.  Actually the wet locker can be opened with the shelf and the computer in place, but the shelf will wipe anything on the navigation desk into the far aft corner.

I admit the shelf construction is pretty rude and crude.  It was intended only as a prototype.  I am not a cabinet maker (not even a carpenter) and I planned to either use this prototype as the model for a final build, possibly by a more skilled person than myself.  The inspiration for this approach was a brief conversation with Hal Sutphen when he describe the modification he made to the navigation station on Sea Duty.  He went for a much greater modification to the station and used a professional cabinet maker to perform the modification.  Hopefully my crude implementation will be as successful for my needs as Hal's, although clearly not as elegant.

Ten years later (2015) this prototype computer desk is still in use.

The connection from the Mux output to the computer not only allows me to feed ship data (position, wind data, depth, speed, etc.) to navigation programs running on the computer, but it also feeds position information to the AirMail client for HF email via Winlink and SailMail, over my SSB radio.  The AirMail software will automatically capture position data and include it in the position reports I send periodically.  Currently (2005) I am experimenting with two navigational software packages, Fugawi and Software On Board (SOB) (shown on the PC monitor).  Fugawi is a low priced ($200) package that supports raster charts from Maptech and SoftChart as well as the NOAA ENC vector charts.  At that time the NOAA raster charts were not free and had to be purchased from either Maptech or SoftChart.  Unfortunately the NOAA ENC charts cover only the US territorial waters, and did provide complete coverage in 2005.  SoftChart provides only small scale planning charts for areas outside of the U.S. territorial waters.  Maptech does provide world wide coverage, but their charts are very pricey and they are raster charts.  At the time I much prefered working with vector charts, similar to the Navionics charts I use on the Raymarine C120 display (subsequently Maptech acquired SoftChart and killed it).  SOB on the other hand was freeware (not anymore), but supports only the very pricey C-MAP vector charts.  So I had three different chart plotting capabilities (Raymarine/Navionics, SOB/C-MAP, and Fugawi/Maptech/SoftChart/ENC none of which supported a common chart format.  I think they planned it this way.

In summary, I recommend purchasing the SeaTalk interface on the Brookhouse Mux only if none of your Autohelm/Raytheon/Raymarine instruments have a NMEA output (seems self-evident now).  I do recommend the Brookhouse Mux very highly as it has provided a testing and configuring capability that was very beneficial to trouble shooting and correcting a lot of problems encountered integrating my equipment.

Upon further testing I've found having the SeaTalk interface does have value in my implementation.  I also learned that the C-120 output is not sufficient to get all available data to my PC.  The C-120 does provide all the necessary navigation information, but it does not provide any data from the wind instruments.  That data is available on the ST6000+ NMEA output.  So I've unsuppressed that data from the autopilot.  Now I'm using a combination of ST6000+ and C-120 NMEA data.  However, if I turn off the C-120 I lose all of the navigation information.  Not all of that data is available from the ST6000+ NMEA output.  That data is available from the SeaTalk interface.  So now I've put together two filter scripts.

1. C-120/AP Data:  This allows all C-120 data and limited ST6000+ data to flow to the computer.
2. AP/ST Data:  This allows all ST6000+ data and limited SeaTalk data to flow to the computer.

All of this configuring as been done mostly from experimentation with the data that has been generated on the three interfaces.  During this time Sarah has been tied to the dock in Ft. Pierce  and not underway.  Therefore I have not done any filtering of active navigation data (e.g., cross-track error, waypoint data, etc.) that is only available when the vessel is underway with a route active.  So there will probably have to be some more filtering required at a later time. 

This exercise has also pointed out the value of a NMEA multiplexer, even when all of the data is coming from an integrated set of instruments such as the Raymarine SeaTalk devices.  In my Raymarine configuration there is not a single NMEA source for all of the data available on the network.

At the same time I wanted to implement a 38,400 Baud NMEA network to distribute the AIS data to my Raymarine C120 display as well as the PC.

Next I connected the Garmin GPS60 input cable to Channel 3.  This allows me to use the Garmin GPS as a backup to the Raymarine GPS on the SeaTalk network.  That worked fine.

Finally I connected the C120 NMEA output to Channel 2 on the Mux.  This has been my primary data source and I normally suppress all other input (except wind data from the SeaTalk channel).  Now I discovered that sometime between when I initially installed the Mux and the latest firmware I've installed on the C120 (3.16) they added the wind NMEA outputs to the C120.  So I no longer need the autopilot NMEA output. 

I've still got to work out a new set of scripts to manage this network for various possible re-configurations.

So unless I can come up with some other solution or I've overlooked something I have the choice of supplying AIS data to the C120 or GPS position data to the radios, but I cannot do both.

Providing NMEA data to these devices is a good, not essential thing.  For the ICOM radios it provides GPS position data should I have to initiate an emergency broadcast via DSC.  The Furuno NAVTEX uses GPS data to filter the NAVTEX messages to eliminate those that do not affect the area in which I am sailor.  None of these functions is essential.  So if I have to I will sacrifice them to get AIS data to the C120 display.

$GPGGA,083637.79,3641.807,N,00247.463,W,1,09,1.0,0.40,M,4.90,M,0.00,*59
$GPGGA,092530,3641.80,N,00247.46,W,1,,,,,,,,A*38
$IIRMC,092530,A,3641.80,N,00247.46,W,0.0,0.0,,2.0,W,A*05

The first line is the GGA sentence generated by the C120 NMEA output.  The ICOM radios always liked this sentence and it would turn on the "GPS" indicator on the M402 radio display and actual position data on the M802 display.  Below this line is the GGA sentence I was able to generate from the SeaTalk-derived RMC sentence.  For the fields after the "W" for west longitude I have created blank fields (just the comma separators).  The last field is a checksum that most listeners required.  The Brookhouse firmware generates this checksum.  The bottom line is the RMC sentence that I edited to produce the GGA sentence on the second line.  I cleared all of the fields after the "W" and inserted 3 blank fields before the checksum.  Below is the script I used to perform this edit.

*W,2,?????
*S,1,IIRMC,GPGGA
*R,1,IIRMC,2
*I,1,IIRMC,7,1,
*D,1,IIRMC,7
*D,1,IIRMC,8
*D,1,IIRMC,9
*D,1,IIRMC,10
*D,1,IIRMC,11
*I,1,IIRMC,12,,
*I,1,IIRMC,12,,
*E

The first line (*W) suppresses all input on the channel with the C120 NMEA data.  This insures that the original GGA sentence from the C120 does not get into the output of the Mux.  After I configured the NMEA interface on the C120 for 38,400 Baud for AIS data I had to disconnect the NMEA output to the Mux from the C120 and this wipe command is no longer necessary.

The second line (*S) changes the sentence ID of the IIRMC sentence received on Channel 1 (SeaTalk) to the GPGGA ID.

The third line (*R) removes the second field in the RMC sentence, which in the example above contains the value "A".  In the GGA sentence there is no field between the time (1st field) and the latitude (2nd field).  This edit aligns the RMC sentence latitude and longitude values with the same fields in the GGA sentence.

Line 4 (*I) inserts a value of "1" after the longitude hemisphere ("W" or "E") field.  This indicates that the CGA fix is a valid GPS fix.

Lines 5 through 9 (*D) deletes or clears the values in the next 5 fields of the RMC sentence.  The corresponding fields in the GGA sentence contain different data.  With the editing filter I cannot generate correct data for these fields so I have just left them blank.  Previously it looked like this was a problem for the ICOM radios, but that was actually not the problem.

Lines 9 and 10 (*I) insert blank fields before the checksum field in the RMC sentence to insure that the resultant GGA sentence has the same number of fields as the GGA sentence received from the C120.

The final line (*E) terminates the script.
 

Not all DB-9 COM cables are the same.  I took a spare COM cable to connect to the open port on the Mux and provide a male DB-9 connector to pair up with the female DB-9 connector on Garmin-supplied data cable.  I reasoned that the pin-out and color codes I had documented for the first COM cable, above, would be the same for this cable and all I had to do was make a mirror copy of the diagram above to produce the pinouts for the male connector and the wires to connect to the Mux port (SG and RD).  Therefore I cut off the female end of the cable and exposed the wires, then connected brown (RD) wire to the +IN and the screen wire (SG) to the -IN terminals on Channel 4 of the Mux.  I then started the HyperTerminal on the PC and waited for GPS traffic from the Garmin, ... and waited, ... and waited.  After verifying that the Garmin was sending data by connecting it directly to the COM1 port on my computer, I knew there had to be something wrong with my cable connection.

Next I used a multi-meter to verify the pin outs on the cable I connected to Channel 4 on the mux.  Here things were greatly different from the cable I used as the RS232 input/output between the mux and the PC.  This pin outs are shown in the drawing on the right.  Since this is a male connector I have labeled the pin functions as a mirror image of the female computer cable shown above.  Here I found the wire colors were not a mirror image of that cable.  It was then I discovered that there were 10 wires in this cable not 9.  First I discovered that the screen wire (no insulation) was not connected to any pin, just the frame of the connector.  The wire connected to the SG pin was green.  The RD pin wire was red, not brown as on the computer cable.  and the TD pin was orange not red.

So the lesson I've learned is that I will have to verify the pin outs on any cable I use in this manner (without factory installed connectors on each end). 

Now how to integrate this GPS source with my ever expanding NMEA network to provide another level of flexibility and resilience.   I have no more input ports on the Brookhouse Mux and I didn't want to run this into another PC COM port as that would preclude feeding the GPS data to my Raymarine C120 Display.  Then I remembered the GPS input on the NASA AIS engine.

The NASA engine has a single wire connection to feed NMEA 183 GPS data into the engine.  The engine then combines the GPS data with the AIS traffic on the NMEA 2000 output at 38,400 Baud.  That will provide an alternate path for GPS data into my navigation PC and Raymarine display. 

1. The Raymarine GPS on the SeaTalk network.  This data is distributed to my other electronics via SeaTalk, the NMEA 183 network and the Brookhouse Mux
2. Should the Raymarine GPS malfunction, I can connect the Garmin Hand Held GPS to the NASA AIS Engine via the deck plug.  This puts the GPS data on the NMEA 183HS (i.e., AIS) network at 38,400 Baud, which currently feeds both my navigation PC (via COM port), and the Raymarine C120 display via its NMEA input.  My other NMEA 183 listeners (e.g., ICOM radios) will no longer get GPS position data unless I use software in the PC to re-send the data on the 183 network.
3. Should the NASA Engine malfunction, I can connect the Garmin GPS to the Brookhouse MUX via the RS232 cable.  This will require the Garmin to run off the internal AA batteries, but it keeps the GPS data on the NMEA 183 network.  The Raymarine C120 is not connected to the NMEA 183 4800 Baud network.  I will have to re-connect it to the Brookhouse MUX and reconfigure it for 4800 Baud in order for the C120 to receive GPS data from this configuration.
4. Should the Brookhouse MUX malfunction, I can connect the Garmin GPS directly to my navigation computer via the Garmin RS232 cable.  Again this will require running the Garmin on the AA batteries.  With another Raymarine cable I could also connect the Garmin GPS to the Raymarine C120 display.  With this type of connection the Garmin can either talk to the PC or the Raymarine, but not both concurrently.  The only other option is to use another software package to re-send GPS data from the PC to the NMEA 183 network.  I have not researched that capability as yet, though I believe it can be done.

As usual, once an installation is nearly complete I see a better way to do it.  I should have mounted the RCA receptacle on the side of the project box, not on the cover.  If I had put it on the side, the cable to the radio would have been parallel to the bulkhead, which would have allowed better strain relief and security for the cable.  Instead the cable stands proud of the box (see picture below, right) allowing less in the way of strain relief or security.

Now everything should be working, right, and I should be able to see position data on the radio display - WRONG!  I've double checked everything I can think of.

• There is no short on the receptacle where I soldered the pigtail (I am a sloppy solderer)
• I get the right polarity on the output receptacle on the DSC box (+ voltage on the center conductor)
• I see the voltage going up and down with what I assume are the data signals.
• I switched the polarity just incase I got something reversed that I couldn't see.
• I swapped out the audio cable.
• My computer, which is hooked to the same bus, is receiving continuous NMEA sentences including the GLL sentence that I though the ICOM is supposed to look for.

With all of this checking and switching, the result is the same a blank position field on the radio display.

Looks like it will require an email to ICOM to get me on the right track.

The response from ICOM is that they are looking for only the GGA sentence.  Neither the Raymarine ST6000+ autopilot nor the Brookhouse MUX SeaTalk port are producing the GGA sentence. The Raymarine NMEA output produces the GLL sentence and the Brookhouse Mux produces the RMC sentence, both have position data from the GPS, but the ICOM is nor recognizing either sentence. 

I think ICOM designed their NMEA capability around the data produced by a Garmin GPS.  If nothing further can be done with the data my system is generating, I may have to add a Garmin GPS to the network just to satisfy ICOM. 

ICOM confirmed that they demand all of the fields in the GGA sentence to be present and filled with valid data.  I told them I believe their inflexible design is a product deficiency.  I can understand that they may be concerned if their product generates a distress message which launches a SAR for an unreliable position.  However, I don't believe their design does anything to insure the accuracy of the position data.  Thanks again, ICOM!

Looks like I am in the market for Garmin GPS as a backup to the Raymarine, but also to satisfy the ICOM.

One good thing to come out of this exercise is I now have a much greater knowledge and appreciation of the Brookhouse Mux.  The editing/filtering capability is worth the purchase price even if I never hook up more than one talker.  Although I initially didn't solve the problem with the ICOM (subsequently I was able to generate a GGA sentence that both radios liked), the Mux is an invaluable tool for interfacing and trouble shooting devices from disparate manufacturers.

I discussed this GGA sentence issue with the Raymarine tech reps at the Miami Boat Show on Feb 17.  They showed me on the C-120 display System Integration menu that the GGA sentence can be turned on and off.  Unfortunately their display units were all in simulation mode and they couldn't show me the GGA sentence being generated.  I confirmed on my C-120 display that the GGA sentence is turned on.  So now it looks like the problem may be that I selected the ST6000+ autopilot NMEA output rather than the C-120 output.  I forgot to ask the tech reps if they are different, but it makes sense they could be - especially since the ST6000+ is 4 years older than the C-120.  I had the ST6000+ firmware upgraded to the latest level this past summer (2004) when I had to send the unit in for repair, so it isn't a software version issue.  Now I have to tie the C-120 into the NMEA bus.  I used the ST6000+ because it is behind the electrical panel directly above the Navigation Desk and close to the NMEA Mux.  The C-120 is on the opposite side of the aft cabin.  Just a matter of running a couple of cables across the cabin.  Still wish that ICOM wasn't so fussy.

To run NMEA In/Out cables from the C-120 display I connected the Raymarine NMEA cable (5 wires) to a terminal strip under the bridge deck.  Only four (4) of the wires are used, the fifth (screen) is just there because the cable and connector chosen by Raymarine had 5 wires.  From the terminal strip I ran two (2) sets of duplex wires back to the electrical panel.  One set of duplex wires was connected to the Brookhouse multiplexer as a third NMEA talker.  The second set of duplex wires was connected to the NMEA bus as another listener.  Now the C-120 display can both talk and listen to the NMEA 183 network.

Of course now the SeaTalk and NMEA output from the ST6000+ autopilot to the Brookhouse multiplexer are redundant.  All three talkers (ST6000+ SeaTalk, ST6000+ NMEA and C-120 NMEA) are sending the same data to the network (although some of the data is in slightly different formats).  This creates a lot of extra processing for all of the listeners on the network.  Fortunately the Brookhouse multiplexer filter/edit capability allowed me to suppress the NMEA output from the Autopilot.  With this capability I can leave all of the talkers physically connected to the mux, and if I ever need to activate one of the suppressed sentences I only need to upload a new filter file to the multiplexer to make that change.  Brookhouse seems to be developing additional capabilities into their edit/filter.  At a convenient time I will have to send my mux back to Brookhouse (New Zealand) to have the microcode updated with the latest edit/filter features.

At least now the ICOM M402 displays and can transmit GPS position information.

I subsequently learned that I could edit the RMC sentence from the Brookhouse SeaTalk channel to produce a the required GGA sentence.  This became necessary in 2006 when I implemented AIS on the C120 display, which required the NMEA input/output on that device to operate at 38,400 baud and could no longer be received by the ICOM radios.  Saved once again by the Brookhouse Mux.

I guess I don't learn lessons very well, because later in 2005 I purchased and installed an ICOM M802 SSB radio to replace the old M700 that has been on board for 4 years.  Once again ICOM bit me with an off-beat NMEA interface and it's not the same as that used on the M402.  With the M802 the interface is a BNC jack rack rather than a RCA Phono jack.  So I was off to Radio Shack once more.  Again I was dealing with a connector designed for coax cable and trying to adapt it to a 2-wire network.  At radio shack I purchased a female BNC connector (actually two).  This connector was designed for a solderless connection to RG58 coax cable.  Instead I soldered one lead (black) from a duplex cable to the cable lug for the NMEA signal ground (see picture on right).  I then put a small ring connector on the other lead (red) and secured it with the small machine screw for the center conductor on the connector.  This provides the NMEA positive signal voltage. 

1. Only 48 pre-programmed channels.

2. Not rated for continuous duty at maximum power.  Sending and receiving email via Airmail and the Pactor modem requires the full 150 watt output of the radio for extended periods of time.  The M700 was built for voice communications, which does not place this kind of demand on the radio.  However, we used this radio extensively for email on the Bermuda sail, and I have been using it daily in preparation for the Atlantic Circle departure with no problems.  Still the SSB will be one of the most important pieces of electronics for the trip and I don't want it to break down and have to be replaced underway.

3. Cumbersome process to set transmit and receive frequencies.  You have to remove a face plate over the frequency display and use tiny little buttons to serially set the frequency.  Make one mistake and you have to clear the entry and start over.  Given the limited number of pre-programmed channels, this is more of an irritant than it otherwise would be.

4. One big, heavy box.

5. Ear phone jack in the back panel.  I have to leave the ear phones plugged in at all times because it is impossible to plug them in without removing the entire unit form its mounting bracket.

In addition to overcoming these limitations of the M700, the M802 has a number of distinct advantages:

NAVTEX Display and SSB Control Head

1. Remote control of the radio.  Among other things this allows the Airmail application to set the radio frequencies for email and FAX traffic.  This is particularly useful for FAX reception and I can provide a FAX schedule and Airmail will automatically put the Pactor modem in FAX mode and tune the radio to the proper frequency for each FAX on the schedule without my intervention.

2. Remote control head (picture on left) which allows me to position the user interface in a better position than was possible with the M700.  The control head is shown in the picture immediately to the left of the PC.

4. DSC capability similar to the M402 VHF radio.

5. Other capabilities I haven't gotten to yet.

On the negative side the M802 suffers from another screwed up approach to providing an interface to the onboard NMEA network (see above).

At the same time I purchased and installed a Furuno paperless NAVTEX receiver (picture on right), which is located to the left of the M802 control head.  This radio receives and displays plain text weather bulletins.  It will be particularly useful in Europe where there are more broadcast stations (and fewer FAX broadcasts) than here in the USA.

Well maybe it is a Japanese thing with NMEA.  Shortly after I connected the NAVTEX to the NMEA network I started to receive garbled NMEA input at the PC.  I disconnected the NAVTEX from the NMEA network and the garble goes away.  The NAVTEX is supposed to be just a NMEA listener not a talker, but the Furuno appears to be applying some voltage to one of the two connections (Signal Data and Signal Ground) to the network.  I've left the NAVTEX disconnected from NMEA network since then .  The NAVTEX works without the NMEA interface, but there is no position filtering of the messages.  Consequently I received a lot of messages for the Canadian Maritimes while I was sailing from the Azores to Portugal.

I sent three technical support messages over a period of 2 years to Furuno for an explanation/help with no response.

Pretty damn inscrutable, if you ask me.

One of my projects over the winter or 2005/2006 while berthed in Cascais, Portugal was to clean up this installation.

I have mounted the radio main chassis below the navigation desk.  This was the previous location of my CD changer, part of the previous stereo system on Sarah.  I removed virtually all of the music CDs from Sarah when I transferred all of my music to an Ipod prior to departing Florida and therefore I no longer had a use for the CD changer. 

The significant compromise on this installation is the location of the SWR meter (grey case to right of the black M802 chassis in the picture above left).  Although not clear in that picture above, I can view this meter between the edge of the navigation desk and the edge of the computer desk.  It's not a great view (picture on right), but sufficient to verify a good SWR reading on my transmissions.

The advantages of this new location include the following:

1. Consolidated and cleaned up the cable mess once and for all (I hope).
2. Used space previously wasted on a non-functional CD changer
3. Freed up the entire shelf above the navigation desk for other purposes.
4. Allowed the radio chassis to be positioned with access to the front panel.
5. Removal of the main chassis for service to the connections on the back panel is much easier than before.
6. Moved the radio chassis and antenna cables as far from the autopilot as practical.

It took me several days to complete this re-location and re-wiring of the SSB.  During this task I attempted to remove as much of the excess wiring in the harnesses going to the electrical panel as possible.  This removal task actually took more time than the SSB re-location.  I still have more wiring tasks to perform in this area (move the AC power source switch from the panel to the hole left by the old battery switch under the navigation desk), but I did remove all of the wiring that was no longer functional and freed up enough space in the harness for the addition of other circuits.

After all this work I was a little apprehensive to use the SSB.  It had taken a lot of learning and tweaking to finally get the SSB to work reliably with Winlink and SailMail.  I was afraid after all of these changes I would have to start over on the tweaking.  Happily the SWR showed an excellent power ratio (almost no reflected power indicated) and I connected to the Winklink site in the Canaries on my first try.  On this day (Feb 4, 2006) I sent my first position report of the year for Sarah.

On the last night of our crossing from the Azores to Portugal we ran a gauntlet of freighters and tankers moving north and south along the coast of Portugal.  This spring (2006) I intend to enter the Mediterranean Sea via the Straits of Gibraltar.  The traffic I will encounter there will make that off the coast of Portugal seem insignificant.

For Sarah I only need an AIS receive capability, and all of my chart plotters (Raymarine, Fugawi and SOB) have the capability to plot the received information on the chart display.  Actually for the Raymarine C120 plotter that capability is not currently (Feb, 2006) available, but Raymarine has promised it will be available via a free Internet download before the end of the month.  For Fugawi the capability is available in version 4.0.  For SOB the capability is available in V90.

Since I already have the display capability, I only need a piece of electronics to receive the AIS signals then format and transmit the data in standard NMEA sentences on my NMEA buss.  This is generally referred to as an AIS engine.  On of the earliest and least expensive of the AIS engines available in the marine market is the one produced by the U.K. electronics company, NASA.

While attending the London Boat Show in Jan, 2006 I purchased a NASA AIS engine at the MailSpeed booth.  MailSpeed is a marine retail outlet in the U.K., the closest you get to discount marine equipment in this part of the world.  NASA is a low-end electronics provider and I would normally avoid such products, but the price was right and there isn't much else available.

The AIS engine receives the signals via a standard marine VHF antenna.  The AIS manual states that this must be a dedicated antenna and the engine cannot share the antenna with the VHF radio.  I'm sure this not really the case.  I believe a quality antenna splitter that protects the AIS engine from the transmission energy of the VHF radio will allow both to coexist on the same antenna.  The VHF radio likely will block the receipt of AIS data when the radio is transmitting, but I don't believe that is a significant issue.  That said, I still intend to mount a dedicated antenna for the AIS engine on the mizzen masthead.  However, while testing and interfacing this unit to my various plotters I had planned to use the existing VHF antenna, by disconnecting the cable from the ICOM M402 radio and connecting it to the AIS engine.  Once I had purchase the NASA AIS Engine and opened the box I discovered that it required a BNC connector not the PL259 connector on my existing VHF antenna.

So I went ahead and purchased another VHF antenna with 20 meters of coax cable and put a BNC connector on the radio end of the cable.  I hadn't decided where to mount the AIS antenna, but for testing I just laid it on top of the dodger and connected it to the NASA box.

I then connected the NASA-supplied serial cable to my Dell Latitude Laptop, fired up the HyperTerminal software and waited for traffic to appear .... and waited ... and waited.  I swapped out the NASA serial cable with one I knew worked ... and waited.  The problem I had was there was no way to isolate the working parts of this system (antenna, coax cable , engine, serial cable, COM port, computer).  I couldn't even tell if the engine was powered up.  I could see there was > 12 VDC on the power cable, but there is not even a LED on the NASA box to say it is up and running (did I say NASA is a low-end electronics provider?).  After watching a blank terminal screen for most of a day I decided I needed NASA technical support and hauled my PC to the local internet cafe to contact NASA.  That day their website was not available, but the next day I got in and sent a request for technical support.  Since I was at their site I went to the product page on the AIS engine.  There I found the information that the NASA engine is NMEA 2000 not NMEA 183.  I had used the same COM port on my computer for the AIS engine that I normally use for the NMEA 183 traffic.  The only information the NASA web site provided on NMEA 2000 is that the port must be set to 38400 Baud.  NMEA 183 requires 4800 Baud.

So I went directly back to the boat, reconfigured the COM port to 38400 Baud and viola data started appearing in the HyperTerminal screen.  I killed the HyperTerminal and started Fugawi.  After a few minutes Fugawi began to display little icons for ships.  I killed Fugawi, started SOB and I also got ship icons on the chart display.  Success!

I went back to the one page installation document supplied with the NASA engine, and there obscurely in the first paragraph it mentions that the engine sends the AIS data at 38,400 Baud.

Brookhouse, the maker of my NMEA 183 Multiplexer, does provide an option for AIS input at 38400 Baud.  However it requires sending my unit back to NZ for an upgrade and all of the outputs from the mux will have to be at 38400.  This would likely create even more integration problems than I currently have so the mux will remain strictly NMEA 183 and 4800 Baud, for now.

That means my plan for a single NMEA source (the Mux) is not possible for now.

I can and have connected the AIS engine to a separate COM port on my laptop computer.  Both Fugawi and SOB can accept AIS data on a separate COM port from other data.  However that leaves the data dedicated to the computer and not available to the C120 plotter (if it ever provides AIS support).

So it looks like I have 3 options to integrate the AIS engine into my onboard electronics.

1. Create a separate 38,400 Baud NMEA network on the boat with the AIS engine as the only talker.  Without a mux this will provide 38400 Baud input to the PC (as I am doing now) plus provide the capability to connect the AIS data to the Raymarine C-120 if and when it is ready for that data.
2. Leave the AIS engine connected directly to the laptop computer and figure out a way to have SOB or Fugawi re-transmit the AIS data onto the NMEA 183 network.  SOB appears to have this capability (there are check boxes for it in a setup screen), but there is nothing in the documentation on this capability. 
3. Forget about AIS data on the both the computer and the C120 plotter

Initially I went with option 3, and planned to implement option 1 when AIS is available on my C120 display.  Option 2, even if it works, is probably not advisable as the AIS data volume can be very large and might saturate the 4800 Baud NMEA 183 network.  See AIS Data Network, below, for the final solution.  In the meantime I started looking at my computer products to determine if this effort was worthwhile in general and specifically which product provides the best AIS support.  I have set up a separate page to document my use of the AIS data and my evaluation of the products that process and display this data.  Use the Electronics menu at the top left of this page and click on the AIS item in the menu or just click here.

AIS Data Network

This is the other end of the cable that connects the terminal strip to the PC using the female end of the cable.  The special NASA supplied cable with one pin on the engine end used to input GPS data is connected to the short DB9 cable (two connectors mated together on the left side of the picture.  This arrangement allowed me to use the NASA-supplied cable without having to cut the cable to connect it to the terminal strip.  I wanted to keep the NASA-supplied cable intact as a known good cable for trouble-shooting this admittedly complicated and messy wiring arrangement.

Now that I've completed the re-wiring of the AIS NMEA network I am finally receiving AIS traffic at the C120.  With the initial connection this did not work, but after I upgraded the C-120 firmware from level 3.16 to 3.18 I started to receive data at the C-120 from the AIS engine.  The first thing I noticed was that the C-120 did not recognize the NASA proprietary status sentences generated by the engine.  This is of no consequence as those status sentences do not affect the receipt of target data from the engine.

Now that I've got AIS data to the C-120 I will start to document my experience with that AIS display on my AIS webpage.