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.

In 2005 I replaced the M700 with an ICOM M802 SSB.  This is a more robust radio with many features that make it easier to use while underway.  See below for pictures of the initial and later installation of the M802.

The picture above 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.

The main problem with the bridge deck location is that with any crew in the cockpit someone is always standing or sitting in front of one of the instruments and blocking the view of the helmsman.  I ran Sarah aground in the West River in the first mile of operation under my ownership because I couldn't see the old Signet depth sounder (the real reason was following some "local advice", but I could have avoided the grounding if I had a view of the depth sounder).

The alternative locations are on the main bulkhead at the aft end of the cabin trunk or on the Edson pedestal. 

The bulkhead mount is only slightly less vulnerable to being obscured by crew in the cockpit.  Also the backsides of the instruments would have to covered and I would like to use that space for a couple of opening ports to get more light and air into the aft cabin as well as provide a means for communication between the cabin and the cockpit during inclement weather (never happened).

The problem with the pedestal mount (besides the fact I would have to buy a new pedestal guard to hold all of the instruments) is that they would be visible only from behind the wheel.  Crew members would not be able to see the instruments from sail trimming or watch keeping positions in the cockpit.   Further, I sail Sarah almost always under autopilot, and even when I am single-handing I spend little time behind the wheel.

So it pretty much has to be the bridge deck. 

Previously, 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.

My friend, Dick Juppenlatz, of Cruising Services and Supplies re-sells refurbished IBM ThinkPads at reasonable prices.  I purchased a really old one from him at a very low price as my initial navigation computer.  This turned out to be less than adequate as the office suite on that computer was not compatible with the Visual Basic-based spreadsheet applications I have developed for navigation and other purposes.  Also Fugawi and SOB  are not compatible with the OS on this computer, Windows 95.  This computer does work fine as a HF or WIFI email client.

It was clear I needed a more modern computer for the navigation station.  While Dick does offer late model ThinkPads, at the time I was partial to Dells so I went to the Dell Auction site and purchased two refurbished Dell Latitude notebook computers.  These appear to be computers that were leased from Dell and have been returned after the lease expired.  Dell refurbishes the computers and offers them for auction with only the OS installed (Windows 2000 Professional) and a 60-day warranty.  These are 1.2 GHz processors with 256 MB of memory and 30 - 40 GB hard drive and a CD-ROM drive.  I was able to acquire these two computers in 2005 for less than $450 each.  Dell typically has several dozen of these computers up for auction at all times.  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.

The old ThinkPad is no longer onboard.  My personal computer (HP zd8000) will never experience operation on the navigation station.

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 - now all of my computers use 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 have 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'll probably sell or give away the single working C600. 

My solution was to build a small computer desk/shelf that mounts on the door of the wet locker immediately adjacent to the navigation desk (see picture top, right).  I built the shelf out of 3/4" shelf material from Lowe's.  The mounting hardware is a pair of ABI stainless steel table braces from West Marine.  I screwed some Ash cleat stock I had in storage onto the shelf to provide a fiddle to hold the computer in place (along with shock cord).

Since the shelf brackets just slip together and are not secured, I used a 1/4" piece of shock cord to hold the shelf into the bracket (picture above, left).  Another, thinner piece of shock cord holds the computer on the shelf (picture on right).  This later shock cord prevents the computer from being closed completely while on the shelf, but I don't consider that a significant issue.  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 and my Mediterranean cruise in 2006.  I'm sure it will continue to function adequately for my return to the U.S. in 2007.

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.

Three years later (2008) this prototype computer desk is still in use, but will have to be modified slightly for the newer D600 notebook computers.  The newer computers are thinner and the DVD/CD drive does not clear the fiddle as the C600 did.

For this purpose I purchased and installed the Brookhouse NMEA 183 Multiplexer shown in the picture on the right, above.  I did not do an exhaustive search for alternatives to the Brookhouse unit, but it appears to be fairly robust.  I chose the Brookhouse because it has a SeaTalk input connection.  This initially simplified the wiring a little bit, in that I did not have to connect another cable to the autopilot or C120, but instead could use a SeaTalk junction terminal I had purchased earlier.  The SeaTalk junction is the black device below and to the right of the multiplexer.  In this picture I have connected the autopilot Course Computer to the Mux (red and black wires on Chn 2 Input terminals) in addition to SeaTalk (the black cable on the right side of the Mux).  The grey cable on the bottom, left side of the Mux goes to a DB9 connector that plugs into the COM port on my laptop computer (bottom picture on the right).  The dual bus bar on the left of the Mux provides NMEA "listener" connections for other devices such as the VHF radio, or a NAVTEX receiver (should I resolve the NMEA problems with my Furuno NAVTEX).

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.  Unfortunately the NOAA ENC charts cover only the US territorial waters, and don't provide complete coverage as yet (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.  I much prefer working with vector charts, similar to the Navionics charts I use on the Raymarine C120 display (subsequently Maptech acquired SoftChart).  SOB on the other hand was freeware (not anymore), but supports only the very pricey C-MAP vector charts.  So I have three different chart plotting capabilities (Raymarine/Navionics, SOB/C-MAP, and Fugawi/Maptech/SoftChart/ENC none of which support a common chart format.  I think they planned it this way.

Please disregard the nearly empty wine glass on the navigation desk.  I was navigating dockside that day, not underway.

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 Harbortown 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.

I was working with Brookhouse support on the problem, my departure was coming up and the Mux is not essential to the navigation of Sarah.  It is primarily a network control box allowing me to activate and de-activate data using the filtering scripts from the PC.  So I wired around it and continued preparations for departure.  I figured it would either get resolved through remote support from Brookhouse over the next few weeks or it would be going back to the factory for repair.

The next thing to go wrong (among a number of others that do not involve the onboard electronics) was the autopilot.  It started to fail on us within the first 4 hours after departure and by the time we arrived in Sines it was no longer usable.

Because of the near simultaneous failure of both the Mux and the Course Computer, I believe the failures are related and may have been caused by my original SSB installation.  Prior to moving and re-installing the SSB the power and antenna cables for the SSB were routed within a foot of both components.  My guess is the constant exposure to power surges and RF during the voyage across the Atlantic may have weaken some components to the point of subsequent failure.  Hopefully with the relocation of the SSB and its cabling that is no longer an issue (no further problems through 2008).

The final result of these problems was the replacement of the original Type 300 autopilot course computer with a type S-3 (grey box in the picture above) and a factory repair and upgrade of the NMEA multiplexer.  Now I had a different autopilot providing SeaTalk and NMEA input and a different multiplexer with a lot more capability than the original.  So I had to do a little more than just plug the new components together. 

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.
 

The output on this channel is also connected to a set of bus bars that allow me to connect multiple NMEA listeners (ICOM radios, Furuno NAVTEX, etc.) to the output of the Mux.

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.

First I verified the pin outs on the female DB-9 end of the Garmin-supplied data cable.  These are shown in the drawing on the right.  These pins are compatible with the pin out shown above for the NMEA cable that connects the Mux to my PC COM1 port.  That is the Signal Ground (SG) is the same.  the Data-In (DI) pin on the Garmin cable conforms to the Transmit-Data (TD) pin on the computer cable (i.e., data transmitted by the PC is input data to the Garmin).  The Data-Out (DO) pin on the Garmin cable conforms to the Receive-Data (RD) pin on the computer cable.  So it didn't look like the Garmin cable was causing a problem.

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). 

This new cable runs from behind the electrical panel to a hook next to the companion way (picture on the right).  I can then connect the Garmin cable to this cable and place the Garmin unit on the cabin top so it can "see" the satellites through the clear vinyl in the dodger.  I may come up with a more secure mounting in the future.

Still if I had to fall back to the hand held Garmin as my primary GPS I wanted the option to power it off the main boat batteries.  A few days after I completed the RS232 cable set up I discovered a Garmin data cable with a power connector in one of my parts bins.  I had completely forgotten I had this cable.  It is intended to connect the Garmin to a chart plotter.  There are four leads in the cable, +Battery Power, -Battery Power, Data In and Data Out.  Rummaging around in my electrical parts bins I found an unused Aqua Signal deck plug with 5 connectors I was in business. 

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 2000 network, which currently feeds both my navigation PC (via COM5), 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 currently 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.

The first problem the ICOM presented was its NMEA interface is a female RCA phono receptacle.  I assumed a standard audio cable would allow me to cut off one end and connect the two wires to my NMEA bus.  However, audio cables are coax, which does not provide a convenient way to tie the cable into my bus bars.  So it was off to Radio Shack for parts.  I bought a 6' RCA male to RCA male audio cable, several RCA female receptacles, and a small plastic project box.  I mounted one RCA female receptacle on the box cover, soldered a pigtail of 18 gauge duplex wire to the receptacle terminals (red for NMEA + on the center conductor) and then mounted the box next to the NMEA bus behind the electrical panel (picture top, right).  I attached the duplex pigtail wires to the NMEA bus and plugged one end of the audio cable into the receptacle on the project box (labeled DSC in the bottom picture) and the other end into the receptacle on the ICOM radio.

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. 

Working with Brookhouse I was able to use the Filtering/Editing capability of the Mux to convert the Raymarine generated GLL sentence to a GGA sentence.  Unfortunately this did not satisfy the ICOM M402.  The Filtering/Editing capability produced a GGA sentence with the GPS position data, but the other fields in the sentence are blank, and the four fields at the end of the GGA sentence are missing.  It appears the M402 either requires some of the missing fields to be present or does not like some of the blank fields (e.g., time) or all of the above.  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 network.

The result of connecting the C-120 NMEA output to the NMEA bus is that finally the ICOM M402 radio recognizes and displays the GPS position data (see picture on left).  I'm still not happy with ICOM for making me do all of this wiring.  That said, the C-120 generates many more NMEA sentences than the ST6000+, so I probably should have connected it to the NMEA network initially.  I thought the SeaTalk interface would take care of those sentences, but apparently not entirely so.

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 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 I recently 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.  Actually this picture is of my first attempt to put this connector together (remember I bought two).  In soldering the ground wire I did not put my needle nose pliers between the solder point and the connector.  The heat partially melted the dialectic in the connector and it would not fit on the jack on the M802 transceiver.  Given my problems with these ICOM NMEA interfaces I immediately thought ICOM used a non-standard BNC jack.  I stopped swearing in Japanese once I saw that my un-soldered BNC connector fit perfectly. 

Although the used ICOM M700 that I purchased from Dick Juppenlatz has worked flawlessly since he installed it for me prior to our Bermuda sail, the limitations of this radio motivated me to break down and purchase that latest and greatest from ICOM, the M802 (shown in picture below, obviously I have some work to do in the cable management area).  The limitations of the M700:

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:

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.

The Furuno NAVTEX receiver also accepts NMEA input.  It uses the GPS position data to filter out stations that are distant to to the vessel.  Unlike ICOM, Furuno provided a 2-wire NMEA interface.  It took me only seconds to connect it up to the NMEA bus.  So it is not a Japanese cultural thing to make it difficult to connect to NMEA, it is just an ICOM thing.

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 .  I've 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 has a use for the CD changer. 

You can see in the picture on the right I had to saw off the left end of the fiddle on the shelf above the navigation desk to mount the M802 there.  Anything I put in this portion of the shelf will have to be secured.  There must be another piece of essential electronics that I can add to Sarah and mount in this location.

Below on the left is a clearer picture of the equipment location.

When I started the original installation of the M802 I considered putting it in this location, but the ICOM manual was adamant that you should not install the unit overhead.  So I put it in the same location as the M700 it replaced (see M802 Install).  After nearly a year of living with that compromised installation I realized that the ICOM manual overstated the issues with an overhead mounting and didn't really address my intentions.  I believe the warning in the manual was concerned with installations like that on the bridge deck of power boat where height of the installation above the waterline could produce excessive forces on the mounts when the boat motion became violent.  I also believe they just wanted to avoid any responsibility for owners who might attempt such an installation using self-tapping screws into an overhead lining.  The chassis bracket for my M802 is through-bolted to the bottom of the navigation desk.  This location is barely above Sarah's waterline.  If the M802 should experience motion violent enough to rip it out of the bottom of the desk I don't think the radio will be my primary concern.

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.

The large hole in the bulkhead is where the battery selector switch used to be located.  I replaced it with three switches to isolate or combine the two batteries on Sarah.  I expect to move the AC power source selector switch (Shore or Generator) to this location and remove a lot of AC wiring from behind the main electrical panel above the navigation desk.

While it is useful in general to be able to monitor the electrical load of the SSB, the current draw of the unit is also used by the Airmail software in setting up some of the parameters that control transmissions from the radio.  I happened to have a spare 100A ammeter in my parts supply onboard, so I added it to the panel (just below the 12VDC Voltmeter on the upper right corner of the panel in the picture on the left.

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.

Once I found an alternative way to feed the data previously provided by the C120 to the other instruments I was able to disconnect the C120 output from the NMEA multiplexer and connect the C120 NMEA input to the AIS Engine.  At this time I also disconnected the Autopilot NMEA input.  The Autopilot still provides NMEA output to the multiplexer, but I really didn't need input.  The only possible use for this input would be if I wanted to have the PC-based navigation software send route commands to the Autopilot.  I do not use that feature on either the PC or the C120, so it's one less thing for the Autopilot computer to have to process.  Better to use all of its cycles for steering the boat.

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.

My Brother Label Maker died last winter.  I used it to make labels for each electronic device on this panel.  Have to get another if I keep adding components.