|I have added and integrated a large number of electronic devices on Sarah since I purchased her. Some of these electronics replaced devices that were installed on Sarah when I purchased her (e.g., Radar). Other devices were additions to the existing inventory (e.g., Chart Plotter). I have spent a great deal of time integrating these electronics using NMEA and Raymarine SeaTalk networks. Virtually all of the electronics share data with or receive data from the other devices on board.|
Schematic of Sarah's Electronics Network
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 September, 2006 I split the SeaTalk bus into two legs. One leg gets its power from the S3 autopilot course computer and includes the ST6000+ and ST6002 Control Heads and the transponder for the wireless SmartPilot remote controller. The other leg gets its power from a breaker on the additional breaker panel installed at the same time and includes the sailing instruments (Depth, Speed, Wind), the GPS and the ST600R Autopilot Remote Control.|
|I put the ST600R on the instrument bus because it is
used to display the data from the other instruments, in addition to
providing the autopilot control in the cockpit.
The ST600R has been funtionally replaced by the ST6002 mounted on the mizzen mast and the wireless remote controller. The ST600R is no longer supported by Raymarine and the LCD display backlight is no longer working. I expect it to fail completely in the near future.
A schematic of the two SeaTalk networks is shown on the right.
This arrangement provides some redundancy for the network and no longer requires me to power up the autopilot to turn on the sailing instruments or GPS.
Schematic of Sarah's SeaTalk Network
|In 2000 I replaced the Autohelm 3000 wheel pilot with a Raytheon (now Raymarine) ST6000+ direct drive (below decks) autopilot. The control unit is located on the upper center of the panel above the navigation desk. I use the ST600R remote control unit to control the autopilot from the cockpit. These control units serve as a backup controller to each other, but also as displays for the data from other instruments on the Raymarine SeaTalk bus.|
The picture on the right shows the nav station as it was for our 2001 trip to Bermuda.
Sarah's Nav Station in 2001
|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.|
ICOM M402 VHF Radio
|In 2003 I replaced the Apelco VHF radio with an ICOM M402. This installation includes the Remote Commander microphone, which I installed in the cockpit. The Remote Commander provides a full power handheld radio for the helmsman as well as an intercom with the navigation station.|
Because the engine cover on Sarah has minimal sound proofing it is difficult, if not impossible, to use the radio at the nav station when under power. I used headphones for the SSB (shown below the M700 in the picture above), but they were only marginally effective. Consequently, when under power, I used the cockpit Command Mic to talk on the VHF.
Command Mic will normally sit in a mike clip on the mizzen mast. I moved the
autopilot remote mount (see instruments,
below) up on the mast to make room for the Commander. I ran the
Commander cable through the cockpit sole at the base of the mast using a
Blue Seas Cable Clam as a seal. The original cable that came with the M402
radio was defective and had to be replaced (at my cost as the warranty had
expired). I love having to run a cable through the boat twice.
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.
Command Mic on Mizzen Mast
|Sarah came equiped with a cheap Seth Thomas Barometer and Clock set, both instruments mounted on the forward bulkhead in the main cabin. The barometer never worked. For passages I purchased a handheld electronic barometer, but it was barely adequate. I really wanted a recording barometer that could provide some clue on the pressure change trend.|
I finall broke down and purchased a Weems & Plath barometer and mounted it on the forward
bulkhead at the nav station. The instrument can display up 48 hours of
For the initial installation the barometer is running on 4 AA batteries, which are projected to last up to 5 months of continuous operation. Later I ran a 12 VDC power source to the barometer, as changing batteries on this instrument is somewhat of a pain.
When I purchased Sarah in 2000 she came with an old Autohelm
(Raytheon/Raymarine) autopilot, which was attached to the Edson pedestal and
controlled the boat heading via a cog belt to the wheel. This is the
type of autopilot you normally see on 30' sailboats. It was adequate
for Sarah when motoring in flat seas, but in virtually any other condition
it had neither the power nor the speed to keep Sarah on course.
Therefore the first significant upgrade I made to Sarah was the installation of a below-decks autopilot, the Raymarine 6000+
On the left is a picture of the drive unit.
|On the right is a picture of the tiller arm attached to the rudder post and and acuator arm of the drive unit.|
drive unit is attached to a large wooden block that was glassed to the hull
in the starboard locker.
Notice that the drive unit can articulate in both the horizontal and vertical planes. This minimizes the need for a precise alignment of the actuator arm and the rudder post tiller. You can see in the picture above that the arm is slightly inclined downward. This has not affected the operation of the autopilot.
course computer was installed behind the main electrical panel, shown on the
right. This was initially a poor choice as I had led the power and
output cables from my SSB radio in the same area. Eventually this may
caused a failure of the course computer and it had to be replaced.
Before that I
the SSB radio to avoid another failure.
I installed the control head for the autopilot on the electrical panel above the navigation desk. I do not operate the autopilot from this location. This unit is used primarily to display data from the other Raymarine instruments. In this picture the depth finder data is displayed.
normally operate the autopilot with the ST600R remote control, shown on the
left. I have mounted this control unit on the mizzen mast in front of
the helm position. This makes it very easy to set, change, release the
autopilot. I can also remove the unit from the bracket and operate the
autopilot from elsewhere on the boat.
Notice I also use this controller to display data from other instruments, in this case the wind speed.
Unfortunately Raymarine ceased manufacture of this remote control and will no longer provide repair service should it fail. Currently the backlight on the display is non-functional.
have installed a backup remote control, which is wireless. The
control is shown on the right where it is mounted when not in use.
This is the only remote control that Raymarine currently supports for my
autopilot. For my use it is a marginal replacement for the ST600R as
it is slower to change course and it runs off an internal battery that has
to be re-charged after about 36 hours of use.
The ST600R is still working, but it occasionally is unreliable. In 2012 I finally replaced the ST600R with a ST6002 control head mounted on a fabricated instrument box on the mizzen mast.
|On the left is the S3 Course Computer that replaced the T300 computer that came with the autopilot.|
added all new Raymarine (Raytheon, Autohelm) sailing instruments in 2003. I
do not particularly like the location of the main displays for depth, wind
and speed on the base of the bridge deck (see picture on right), but
the other alternatives also had problems.
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).
Instruments on Bridge Deck
|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).||
Raymarine ST60 Depth Sounder
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.
Raymaarine ST60 Wind and Speed Instruments
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.
Raymarine ST600R Autopilot Remote Control
|This autopilot arrangement worked flawlessly for over 4 years. In the spring of 2006 as I literally was leaving Cascais, PT for the Mediterranean Sea the ST600R remote suddenly failed. When I plugged it in it produced a SEATLK FAIL message in the display and the SeaTalk network was down. When I unplugged the remote the SeaTalk network came back. Now I realized the impact of my reliance on this remote. Without the remote the only way I could control the autopilot was from the navigation station in the cabin. This might be OK for an ocean passage, but not for the coastal cruising I had planned for 2006.|
Raymarine Wireless Autopilot Remote Control
|Fortunately I had 2 quality crew mates for the initial leg of the cruise from Cascais to Gibraltar. Once in Gib I purchased a new remote controller, this one wireless. The controller in its recharging bracket is shown in the picture on the left.|
on the right is of the base transponder, which I fitted behind the C120 chart
Initially I installed the wireless remote controller on the mizzen mast in the same place I previously kept the wired remote control. This appeared to work fine for the first few hours of operation, but on occasion the remote started to beep and report "No Pilot" as in the picture abovet (in this case the autopilot is actually turned off and it is not a problem).
Base Transponder for the Wireless Remote
|I finally relocated the remote bracket to the side of the companionway and the problem went away. Apparently the mizzen mast provided just enough interference with the signal from the transmitter to cause the remote controller to lose contact.|
Subsequently I had the ST600R repaired by Raymarine and it was again
operational. Now I have two remote controls for the autopilot.
The ST600R was once again my primary autopilot control in the cockpit.
The wireless remote control is used when I have to leave the cockpit, but
still need control of the helm (e.g., when getting ready to drop the
So the two remote controls back each other up, but also each have unique capabilities.
|In 2011 the ST600R showed signs of eventual failure. The back light for the LCD display is not working and the unit sometimes disconnects from the SeaTalk network. Raymarine no longer provides a repair service for the ST600R.|
It was time to replace this remote. Since the wireless remote is not a
functional replacement for the ST600R as a primary Autopilot control, I
needed use another Raymarine controller in the cockpit.
I purchased a used ST6002 on eBay, but then I needed a housing for the controller if it was to be used in the cockpit to replace the ST600R. I've started another page on building an instrument pod for the ST6002.
The finished installationof the ST6002 on the mizzen mast is shown in the picture on the right.
ST6002 Mounted in a Radio Shack Project Box on the Mizzen Mast
|About the same time as the remote controller failed I started to experience problems with the autopilot operation itself. Periodically while underway the autopilot would drop out of "AUTO" mode into "STANDBY" mode. This means the autopilot stopped steering the boat and it would veer off course. This was an inconvenience on the trip from Cascais to Gibraltar because I had Chris and Martin along as crew. Once I got to Gib I would be single-handing for a couple of months and I needed a reliable autopilot. The normal cause of this problem is a defective drive motor that is drawing too much current. The other possible source is loose or corroded wiring and RF interference from another piece of onboard electronics. While underway we experimented by turning off other equipment to see if the problem went away. Eventually we had every piece of electronics on the boat turned off except the autopilot and the Seatalk instruments that are connected to it, and the autopilot continued to malfunction. While in Lagos and later in Gib I had local electronics experts go over my wiring and we could find nothing wrong. So everything pointed to the drive motor, which was replaced in Gib. I then motored Sarah from Gibraltar to Sotogrande (about 15 nm), then from Sotogrande to Benalmadena (about 43 nm). On the later trip the autopilot did drop into standby once toward the end of the trip, but I was not sure I didn't do it accidentally myself so I discounted that. A few days later I motored from Benalmadena to La Mona and the problem came back to the extent I hand steered the last three hours to the Marina del Este at La Mona. Clearly something was still wrong and I did not have a reliable autopilot. I had discussed this possibility with the electronics guy in Gib, and he said it was possible all of the over current problems with the drive motor may have damaged the computer. So I stayed put in the Marina del Este for over a week and ordered a new S3 course computer to replace the Type 300 course computer I had onboard. The new computer was installed in a few hours.|
New Course Computer for Autopilot
|In the picture on the left the computer is mounted behind the electrical panel and cabled to the fluxgate compass, rudder sensor, drive motor, Seatalk network, NMEA network, and power. I still have to relocate and secure several terminal strips because the footprint of the new computer is about twice that of the old. That work will wait until I get my Brookhouse NMEA Multiplexer back from being repaired. That unit also failed around the same time.|
While installing the new computer I discovered that
this purchase may not have been necessary. While connecting the wiring
I discovered that one of the cables to the drive motor was not tightly
secured in a terminal strip. These connections had been checked
repeatedly and I did not check them when the autopilot problem came back.
It is possible with all of the tugging on the connections we loosened this
wire just a bit. That could have caused the problems on the trip to La
Mona. Well the new computer is installed and the old one will be a
backup. I may send it back to Raymarine (with the ST600R remote
controller) to see if there is a problem with the computer. Now I need
to perform the sea trial calibration of the autopilot and get underway to
Almerimar, Spain. At the end of that 45 nm trip I hope to have
restored my confidence in the autopilot even if I may have wasted a lot of
money on the replacement computer.
The autopilot performed flawlessly for remainder of my summer cruise, and on the cruise back to the states in 2007.
In August, 2012, about six months after installing the ST6002 in cockpit, the ST6000+ display at the navigation station displayed "STLK FAIL" as shown on the right. This normally means a wiring problem in the SeaTalk network or one of the devices has failed and is blocking the network or corrupting data. The other devices on segment of the network with the ST6000+ are:
STLK FAIL on the ST6000+ Display
Used ST6001+ Purchased on eBay
|The easiest of the devices to isolate from the network is the ST6000+. When I jumpered around this device the STLK FAIL went away. I verified that the autopilot was operational with the ST6002 in the cockpit. I reconnected the ST6000+ and reseated the cables and the STLK FAIL came back. So there must have been in internal failure in the ST6000+. Raymarine does not provide a repaire service for this device as it is more than 10 years old. Even if they did the repair fee would likely be more than the $300 I paid for the cockpit ST6002 on eBay. So I a bid on and won a ST6001+, which is shown on the left.|
While I was still bidding (and losing) on a replacement for the ST6001 AP
controller, I noticed that my wind display was blank and not sending any
wind data to the other instruments. My guess it failed at the same
time as the AP controller when I powered up the SeaTalk network. So I
started shopping for a replacement display on eBay while still shopping for
the AP control.
I ended up with the winning bid on a used ST60+ wind display as shown on the right.
With the installation of this display the only instrument from my original upgarde in 2002-3 is the depth sounder. Guess I should start checking for a replacement depth sounder display on eBay.
As of September, 2012 the transducers for the wind, depth and speed displays are all still originals.
Used ST60+ Wind Display Purchased on eBay
|Radar and Electronic Chart Plotter|
When I purchased Sarah she was equipped with a Sitex T-100 radar. This was
a 10 - 12 year old CRT-based radar. It drew a lot of current and had a
small (7") screen with green & white display. For its time it was a very
good unit and while it was still functional I made good use of it.
Unfortunately within 2 years the CRT failed. I contacted Sitex to ask about
parts or a repair service and was told in no uncertain terms to go away. I
found a couple of electronics shops that were willing to work on it, but
with no guarantee what it would cost and whether or not the repair would be
successful. So I finally removed the radar display and antenna from Sarah
and planned for a replacement.
During this time I also started to consider electronic charting. Although I have always been of the opinion that electronic charts should only be considered a complement to paper charts and not a replacement, I began to realize that an electronic chart plotter could be of great advantage under a number of circumstances. In particular I realized that being able to see your position plotted in real-time on a chart when entering an unfamiliar harbor could be of significant value (see Bermuda Lessons Learned). Consequently I purchased a copy of the Fugawi Electronic Chart System (ECS) to start experimenting with electronic charts. I chose Fugawi because that software supported the NOAA ENC vector charts, which can be downloaded from the NOAA web site free of charge. The first thing I determined is that I do not want to use my primary personal computer as a navigation tool. This computer contains all of my financial and personal information as well as this web site, video editing software, and many other files and software that I would not want to risk. This computer will be stowed away securely while Sarah is underway.
Therefore I would have to purchase one or more cheap laptops if I was to use a computer as part of the navigation station. I secondly determined that a laptop is totally unsuitable for use in the cockpit. A laptop will generally die if you spill a single drop of water on the keyboard and the screen is un-viewable in sunlight. Therefore the laptop would have to be restricted to the navigation station and the helmsman would have to leave the cockpit to view the display. This somewhat defeats the primary advantage of the chart plotting system, at least it does for my needs. So my thinking evolved toward a dedicated chart plotter with sufficient weather resistance and brightness of display for it to be used in the cockpit.
I have decided to use a couple of cheap, used and or refurbished, laptop PCs for the navigation station. These PCs will be used primarily for SSB email and electronic logs while underway. I currently have an old IBM Thinkpad running Windows 95 for this purpose. I cannot run Fugawi on that PC as Fugawi requires Windows XP or 2000. Therefore any PC I purchase for that software will have to be much more recent and expensive. See below for my solution for navigation computer(s).
Subsequently I installed the Software On Board (SOB) chart plotting package on the navigation PCs. This was initially freeware, but now requires a very nominal charge for the software license.
Raymarine C120 MFD
|About this time a new generation of LCD-based radar and chart plotter displays started to come on the market. Since I had already invested in Raymarine (Raytheon) instruments and autopilot I primarily looked at the Raymarine radars and chart plotters. This year (2004) Raymarine introduced their C-Series of integrated radar, chart and fish finder displays. I purchased and installed the C-120 Multi-Function Display (MFD), which has a 10"x7" screen.|
added the Raymarine 120 GPS (picture on right) to my existing SeaTalk bus
and a Raymarine Pathfinder 24" Radome
Scanner (picture below). The system uses Navionics vector charts on flash
cards. These are not as rich in detail as the NOAA ENC charts I use with
Fugawi, but they are sufficient my navigational needs.
Raymarine RayStar 120 GPS
|Over the years since this original install Raymarine has issued free upgrades to the C-series display firmware. These upgrades fixed problems in the previous versions, but also added new features Some of these features included capabilities built into the Navionics Charts, but not implemented in the previous Raymarin firmware. Today I much prefer the Navionics charts to the NOAA ENCs from which they are derived. Of course I still prefer the NOAA price (free).|
Raymarine 24" Radome
|Now I have a fully integrated set of electronics, which allows me display information on multiple instruments as well as combine the data to produce additional information.|
|I mounted the display on a swing arm just inside the aft companionway. This allows me to position the unit so it is viewable from the navigation station or from the cockpit (picture on right). Notice that although the sun is shining on half of the screen it is still viewable. The swing mount allows the display to be pushed out of the way when entering or leaving the cabin. Actually we found in most conditions it was easy to move past the display without moving it.||
C120 Viewed from the Cockpit
C120 Radar Display Viewed From Nav Station
|The screen is large enough to be useful even when viewed from behind the helm (about 6' away). However to view chart detail or work radar and navigation tools I must be within arm's reach of the display. This is not normally a problem as I normally steer Sarah either under autopilot or windvane. While underway I normally sit next to the companionway under the protection of the dodger, so this is not really a problem. The swing arm installation is the best compromise to make the unit viewable from both the navigation station and the cockpit short of the cost of two displays.|
|The three pictures (above, on right and below) show some of the display options available with this unit. In descending order the displays show just the radar image, a split screen between the chart plotter and the radar, and further split screen to add a course deviation screen. I expect the normal mode of operation will be that shown in the picture at the very top of this section, which overlays the chart display with the radar image.||
C120 Split Display of Chart Plotter and Radar
C120 Split Display of Chart Plotter, Radar and Curse Deviation
|Notice that in each of the displays there is a customizable "Databar" that can be used to display information from any of the Raymarine instruments. I normally place this databar on the side of the display rather than at the top as shown in these pictures.|
|Having integrated all of these electronics I've discovered I may want to re-position the fluxgate compass that is part of the autopilot. That compass is currently located under the cabin sole, just forward of the V-Drive. This was the most convenient place to put the compass when I first installed the autopilot, however all of the metal near the compass produces a lot of deviation. This was not of concern for the autopilot operation as I never set the autopilot to a specific compass heading, rather I always steer the boat onto the intended course and activate the autopilot to steer that course. It never mattered to me that the autopilot displayed a course that was as much as 10 degrees off from the steering compass. Now that deviation produces a minor problem for the display of the chart overlaid by the radar image. Because the display uses the compass heading to orient the two displays on top of each other, the chart and the radar image are miss-oriented by the amount of deviation in the fluxgate compass. If you click on the C120 Chart Display with Radar Overlay picture (first picture in this section) to get the high resolution image you can see the effect of the deviation. You can see that the overlay radar image (purple) of the Thomas Johnson bridge as it crosses Town Creek is skewed about 10 degrees off from the bridge depicted on the chart. This was a minor issue that I mostly ignored for several years.|
C120 Radar Overlay, Properly Aligned with Chart
2006, after replacing the autopilot Course Computer and calibrating the
compass with that computer, I found that the deviation is now very small on
all headings and the radar and chart displays are very closely aligned.
I don't know if the new computer has improved firmware to calibrate the
compass and compensate for deviation, or I just did a better job of steering
the boat in a steady circle during the calibration.
In the picture on the left you can see that now (2008) the radar and chart display of the Thomas Johnson Bridge are very closely aligned.
is the rare cruising sailboat today that doesn't have a laptop computer in the
Navigation Station. Computers have become as common place on cruising
sailboats as GPS receivers (or as Sextants have become rare). Sarah is not
the rare sailboat in at least this category, although I do carry a sextant.
I have my personal computer which I use for finance management (Quicken),
Internet access (WIFI and dial-up), email (Outlook, GMail), video editing
(Avid Liquid ), digital photo editing (Adobe PhotoShop), drawing
(FastCAD 32 and Visio), word processing and spreadsheets (MS Office XP),
music collection management (iTunes), and of course maintaining this web
site (ExpressionWeb). This computer is very critical to my personal life,
and I am not willing to risk it on the navigation desk while underway. So
it gets stored in a heavily padded case when Sarah is underway. Still I
want to have a computer at the navigation station while at sea to handle HF
email, WX FAX processing, log keeping, and navigation software (Fugawi and
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 Latitude C600 at Nav Station
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 comuters 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 first real problem I experienced with a navigation computer is that it takes up all the space on the navigation desk. I can either use the computer or I can use the desk for paper chart navigation and log keeping but not both. Since the paper chart work and log keeping take precedence over computer operation I had to find a different place for the computer, but still keep it as an integral part of the navigation station.|
|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 (picture on 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).||
Computer Desk Mounted on the Hanging Locker Door
Computer Desk Secured to Brackets 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 on 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.
|One of the reasons I standardized my instruments on
Raymarine products is their proprietary network, called SeaTalk. All of
these instruments are interconnected and broadcast their data on the SeaTalk
bus. Other manufacturers (e.g., Furuno) also have proprietary networks to
interconnect their equipment. I settled on Raymarine because I had their
instruments and autopilot on my previous boat and I was happy with that
choice. I could have just left everything on the SeaTalk bus and limited my
self to the Raymarine line, but there are a number of other devices I would
like to connect with the Raymarine equipment that do not work with SeaTalk.
The non-proprietary interface to accomplish this is NMEA 183. Using NMEA
183 I can add non-Raymarine devices to the network. For example, my ICOM
M402 VHF radio has a NMEA 183 input to capture GPS position information that
would be included in a DSC distress call originated from this radio. Although the
chart plotter function on the Raymarine C120 is excellent, I would also like
to use a PC-based chart plotter as a backup and alternative to the Raymarine
plotter. To accomplish this I would need to connect the NMEA 183 output
port on either the autopilot or the C120 to a pair of bus bars, and then
connect all the devices I want to receive the Raymarine data to those bus
NMEA 183 is a 2-wire interface, data and ground. With this configuration there is a single NMEA "Talker", the Raymarine interface, with multiple NMEA "listeners", the devices connected to the bus bars. However, I want to have potentially several "Talkers" on the network. For example, I want to have a backup GPS to the Raymarine 120 on the SeaTalk bus. Should the Raymarine GPS fail, I want to be able to activate my Garmin handheld GPS and have it "Talk" to all my other electronics, especially the C120. Further, if the C120 were to fail I would want to have my PC-based navigation software "Talk" to the network as well. In order to have multiple NMEA 183 "Talkers" on a single network I need a NMEA 183 Multiplexer (Mux).
|For this purpose I purchased and installed the Brookhouse NMEA 183 Multiplexer shown in the picture on the right. 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).||
Brookhouse NMEA Multiplexer
|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 (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).||
Laptop Computer as Chart Plotter
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.After several weeks of using the NMEA Mux and testing it with various other devices (see VHF Radio, below) I have come to the conclusion that the SeaTalk interface on the Brookhouse Mux is of little value in my setup and may have actually introduced problems. First I discovered that there were some errors in the generation a few of the NMEA sentences from SeaTalk data in the Mux. Working with the Brookhouse technical support I was able to suppress these errors using their editing/filter capability from my PC via the HyperTerminal. To get the correct data I connected the NMEA output from the autopilot computer to the Mux. Now I was duplicating a lot of the sentences between the two sources, so I suppressed most of the autopilot NMEA output in the Mux. Then I discovered that the NMEA sentence required by the ICOM M402 VHF radio (see below) was not generated by either the Mux nor the autopilot. I had to run another set of NMEA connections from the C-120 display on the other side of the aft cabin to the Mux. Now I had three sources of the same data. After a bit I discovered that once more I was getting erroneous data, this time from the C-120. For some reason the magnetic variation value (reported in the RMC sentence) was going bonkers. At times it was zero, other times 6 degrees East, and sometimes 60 degrees East. The correct value was about 5.7 degrees West. I could change the value manually in the C-120 system setup menu, but that meant I would have to re-set it whenever I moved into an area with a different variation. Every time I put it back on automatic the value would be wrong. I guessed that the multiple sources of NMEA data being fed back into the C-120 might be causing a problem, so I disconnected the data input from SeaTalk to the Mux (the Mux still gets power from SeaTalk). Now the only input to the Mux is that from the C-120 and the magnetic variation appears to be reported and processed correctly. I still have the autopilot output connected to the Mux, but suppressed by the mux filter commands. I will leave it this way. Right now there is no navigation data available if the C-120 is off. There may be a time when I will want to turn off the display to save power or the display may be malfunctioning. If that happens there will be no navigation data to any of the devices connected to the NMEA Mux, however it only takes a few seconds to upload a command to the Mux to remove the suppression of the autopilot NMEA data and navigation information will start to flow again without my having to change any wiring.
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.
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.
|The configuration described above worked fine for over a year, including the sail from Florida to Portugal. However about the time I was getting ready to leave Portugal and head for the Mediterranean Sea things started to go south. Several weeks before departure the Brookhouse Multiplexer started to lock up and stop transmitting. Thinking there might be something wrong with one of the inputs I started disconnecting the input channels. First I disconnected the SeaTalk input (yellow wire only, power still from the Autopilot) and it appeared to start working. After a few days it started to lock up again. I provided power from another source than the autopilot and still it would lock up. Eventually the Mux stopped working altogether|
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 on the right) 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.||
New Course Computer for Autopilot
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.
Brookhouse Mux Re-Installed
|When I re-installed the Brookhouse Mux initially I just connected the SeaTalk input and power. Then I connected the serial data cable to my PC and tried to verify that the SeaTalk data was outputting NMEA data to the PC. I got nothing but garbage in the HyperTerminal window. I knew with the upgraded firmware in the Mux that it was now capable of outputting at different Baud rates, so I changed the Baud rate on the HyperTerminal with no better results.|
|Finally I decided to activate the upload capability of the Mux (Power off Mux, hold down ESC on PC keyboard, Power up Mux) and I got a menu of functions that did not exist on the previous version of the firmware. One of the options was to set the Baud rate to 4800, which I did and good data started to appear on the HyperTerminal screen. I guess I should have down loaded the latest documentation before starting this re-install.|
|Next I connected the NMEA output of the autopilot computer to Channel 4
on the multiplexer. Using the filter capability I turned off ("Wiped") the
SeaTalk input so I could see only the Autopilot NMEA data. This input
provides a great deal more sentences than the old course computer. All of
the navigation data required by my PC programs (chartplotters and Airmail)
is there, but it does not produce the the GGA sentence that my ICOM radios
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.
|Now that the basic NMEA data network has been restored, my next project
is to share the AIS data between the PC and the C120 display. Currently
that data is going only to the PC on a separate (COM5) port. The problem it
presents is that I must set the NMEA baud rate on the C120 to 38400 to input
the AIS data. That change affects not only the NMEA input to the C120, but
also the NMEA output from the C120, which currently provides most of the
data used by the non-Raymarine electronics on board. Of those only my PC
can be configured for 38400. My two ICOM radios and the Furuno NAVTEX
receiver use the GPS data provided by the C120. None of these have the
capability of accepting NMEA input at anything other than 4800 Baud.
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.
|After a little experimentation with the new firmware in the Brookhouse
Mux I discovered I can now generate the $GPGGA sentence that the ICOM radios
demand from the NMEA stream generated by the Mux from the SeaTalk input.
Using a filter script I was able to convert the $IIRMC sentence from the
SeaTalk port into a $GPGGA sentence that the ICOM radios would accept. When
I tried this with the previous firmware the ICOM radios would not accept the
resultant sentence. At that time I was told by ICOM that there must be
valid data in each of the fields of the GGA sentence. Since the RMC
sentence does not provide all of the data in the GGA sentence that seemed to
be an impasse. However with the updated Mux I generated the GGA sentence
with empty fields where the additional data is supposed to go and the radios
like it just fine. I think the difference is that previously the Mux
generated the RMC sentence without a time value, and that appears to have
changed with the latest version. Below are the sentences in question:
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.
|Now I can connect the C120 NMEA channels to the AIS network at 38,400 Baud.|
|Things continue to evolve with my NMEA network, so I have set up a separate page to cover the constant state of change in this network. Go to the NMEA Multiplexer page.|
As of Jan, 2007 here are my multiplexer channel assignments:
|1, SeaTalk||SeaTalk. There is a separate SeaTalk terminal set, but SeaTalk uses channel 1. So you have the option of connecting SeaTalk to the Mux or connecting a NMEA input to channel 1, but not both. SeaTalk provides power to the Mux. That power comes from the "Instruments" breaker on the auxiliary electrical panel.|
|2||OPEN. This was formerly connected to the NMEA output from the C120 display, but to connect the C120 to the AIS engine required changing the Baud rate to 38400 and it could not longer be connected to the 4800 NMEA network.|
|3||Garmin hand held input. This allows me to enter GPS position data from an external GPS unit onto the NMEA network. See description of this connection below.|
|4||Raymarine ST6000+ Autopilot NMEA output.|
|RS232 Channel||This is the input/output channel and is connected to the PC via the COM
below. This directs all the data filtered by the mux to the COM1 port
on my computer. It also allows the computer to send data to the Mux and the
NMEA network. I have used this PC output capability only to perform the Mux
filtering described above. I do not generate any NMEA data (e.g., autopilot
commands) from the PC.
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.
|DB-9 Cable Connection to the NMEA Multiplexer|
|The standard interface between a GPS and a computer is via the COM port. On my Dells (and most other computers) this is a DB-9 male receptacle. To connect that port to the terminal strip on the multiplexer I took a standard computer cable and cut off the male DB-9 terminal on one end leaving the female DB-9 terminal on the other end to plug into the computer. Since I did not have a pin out for the cable identifying which color wire went with each pin, I had to test each one with a multi-meter to identify which wires needed to be connected to the terminal strip.|
|I documented that pin out in the diagram on the right (looking at the pin side of the DB9 female connector on the cable).||
DB9 Female Terminal Pinout
Initially I used only the SG (Signal Ground), TD (Transmit Data), and RD (Receive Data) wires. That is all the mux and initially the computer required. I was able to effectively transmit and receive NMEA data at the computer using just these wires. At a later date I moved the NMEA input to a EdgePort USB port converter. The EdgePort converts between a DB-9 communications cable and a USB 2.0 cable and allows me to connect the NMEA mux to a USB port on my computer. That way I can have multiple COM port connections to the computer, which I need to connect both my SSB radio and the NMEA mux. Port converters are tricky little boxes and I was having trouble getting everything working through the EdgePort that previously worked using the standard COM port. So I eventually put jumpers on some of the unused wires in the DB-9 cable to create a null modem cable. This didn't solve any problems, but I've left the cable in that mode. The jumpers added were:
I never got the NMEA output from the Brookhouse Mux to work through the EdgePort converter. So I moved the NMEA data back to the COM1 port on my computer. Later I replaced the ICOM M700 SSB radio with an ICOM M802. The M802 has a remote control port that uses a COM cable. I connected that cable to the EdgePort adapter. Now both the Pactor modem TNC and the M802 remote control go through the EdgePort. I've had no problems using the EdgePort for these connections.
|DB-9 Cable Connection for Garmin Hand Held GPS|
kept hand held GPS units on board for several years as backups to the
Raymarine SeaTalk GPS. If something were to happen to the rail mounted
Raymarine GPS or to the SeaTalk bus I would lose GPS position data for all
of my chart plotters. In that case I would be back to plotting the course
on Universal Plotting Sheets or paper charts as I did for the Bermuda Ocean
Cruise back in 2001. This is a very workable situation, but seems a little
old fashioned after putting all these electronics on Sarah. Since I had a
spare port on the Brookhouse NMEA Mux it would be simple to connect a data
cable from my Garmin GPS60 hand held to the Mux and have the Garmin data
integrated with my other electronics. It was simple, almost.
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.||
Garmin Data Cable Pinout
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.
COM Cable Male Terminal Pinouts
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 I was able to re-install the new cable and connect to channel 4 on the mux, connecting the green wire to the -IN terminal and the orange wire to the +IN terminal as shown in the picture on the right. The cable is connected to the small terminal strip just to the right of the mux. Then I connected the SG and TD terminals to the mux as described. Should I ever want to send data to the Garmin I will run a wire from the RD terminal (red wire) to the common NMEA bus to the left of the mux. I used the other two terminals on the strip to clamp the DCD, DTR, and DSR wires together and the RTS and CTS wire together. I don't believe that is really necessary, but it doesn't seem to hurt anything, and you never know ....||
Garmin GPS Connected to NMEA Mux
|Now when I start the HyperTerminal I see the Garmin sentences ($GP) flowing with the other NMEA data from the mux to the computer. I would not normally want GPS input on the network from more than on device. So I have modified the existing filter scripts for GPS data from either the autopilot or the SeaTalk channels to suppress all input from Channel 3 (Garmin). Then I created a new script for when the Garmin is connected to suppress all GPS data from both the autopilot and SeaTalk.|
|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.||
Cable to Connect GPS to Mux
|The only drawback to this cabling is that no power is supplied to the Garmin and it must run on the internal AA battery pair. This appears to provide around 24 hours of continuous running. I navigated Sarah to Bermuda and back with a hand held Garmin GPS in 2001. Every morning we had to replace the batteries. It took a lot of batteries for that trip, but AAs are fairly inexpensive and don't take up much space.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.
for now I will have four levels of resiliency in providing GPS data to my
onboard electronic devices.
|GPS Data to DSC Function in VHF Radio|
|The ICOM M402 VHF radio, like nearly all marine VHF radios in production
today, supports Digital Selective Calling (DSC) as an automated means to
initiate a distress call. The ICOM radio has a NMEA 183 input so that it
can pick up the time and position data from a GPS and include that
information in any DSC broadcast. Since I had just put together a NMEA bus
to allow multiple "Listeners" to receive the output from the Brookhouse NMEA
multiplexer, I thought the ICOM radio would be a good first customer for the
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.||
Radio Shack Project Box to Adapt Coas to Wire Pair
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.
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.||
Connecting ICOM M402 VHF to NMEA Buss
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.
GPS Display on ICOM M402 VHF
|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.||
Soldering BNC Terminal
|You can see in the picture on the right how the heat deformed the dialectic and shrunk the inside diameter so that it would not fit (connector on the left). The connector on the right is the second BNC connector I purchased at Radio Shack. This time I was careful to use the pliers as a heat sink to protect the connector. I also did a little neater job of soldering on this one. In any case the cable works and now both ICOM radios receive position data from my NMEA network.||
Deformed BNC Terminal
|ICOM M802 SSB Radio, Furuno NAVTEX Receiver|
|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).||
Nav Station with NAVTEX and SSB Installed
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.
NAVTEX Display and SSB Control Head
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.
|Re-Locating the ICOM M802 SSB Radio|
Relocated SSB Radio
did actually clean up most of the cabling mess apparent in the pictures
above before we
departed Florida for Portugal. However it was never a particularly clean
installation with lots of excess cable coiled or stuffed onto the shelf
above the navigation desk. The SSB radio and the associated equipment
(Pactor Modem, Line Isolator, COM to USB port converter, etc.) used up all
of the space on this shelf, that otherwise could be used to support
One of my projects over the winter or 2005/2006 while berthed in Cascais, Portugal was to clean up this installation.
on the left and on the right below are two pictures of the relocated radio
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.||
Relocated SSB Radio
Relocated SSB Radio
|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).
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.
|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.
View of SWR Meter
The advantages of this new location include the following:
|As part of this re-location, I ran the power cord for the M802 through the bulkhead beneath the nav desk and connected it directly to the battery switch for the house battery (see Battery Switch Replacement). This meant that the current draw of the M802 would no longer be measured by the 12VDC Ammeter on the main electrical panel above the navigation desk.|
Ammeter for SSB Radio
|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.
|The Automated Identification System (AIS) is an onboard system to
transmit the name, characteristics, course and speed of commercial vessels
on the high seas on VHF radio frequencies. Similar to the ID system used by
aircraft, the purpose of AIS is to avoid collisions between large vessels.
Only the largest yachts (like those owned by Paul Allen and Larry Ellison)
are required to participate in this system, but it provides a potentially
useful tool to the cruising sailor when transiting areas of high vessel
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.
|In Feb, 2006 I started the install of the NASA AIS engine on Sarah. In the picture on the right you can see my initial location of the unit on the edge of the shelf above the navigation desk. I chose this location because it provided an easy path to connect it to power and the NMEA buss. This position will also allow easy testing of the unit with my existing VHF antenna and allow direct connection of the unit to my navigation PC rather than going through the NMEA buss.||
NASA AIS Engine
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.
|I had success, but NMEA 2000 (I think the correct term is
NMEA 183-HS) presented a new problem for
me. Once I had the AIS Engine working and reporting data to my chart
plotting software on a dedicated COM port I had planned to interface the AIS
Engine to my Brookhouse NMEA multiplexer and
add that traffic to the existing NMEA data so I can receive all NMEA data on
one COM port on my computer. This would also allow me to send the AIS data
to my Raymarine C120 plotter. At that time the system did not support AIS
data, but Raymarine promised a free software upgrade in the very near
future to provide that support.
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.
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.
|The lack of any LED status lights on the NASA AIS Engine does make trouble shooting problems more difficult than it need be. It was not a big deal for me as I was using establish software (SOB, HyperTerminal, Fugawi, etc.) to talk to the box. However if I was writing my own program to talk to the NASA AIS Engine I would want some sort of status to indicate that the box was doing something. Here is a link to a page on the DigiBoat web site for a modification to the AIS engine to provide some level of status lights. I'm sure the SOB developers needed this to get their interface working.|
|AIS Data Network|
|After upgrading to a new autopilot course computer and having the Brookhouse NMEA Multiplexer refurbished I was finally able to reconfigure my NMEA data streams to allow the C120 NMEA output to be disconnected from the multiplexer. Up until then most of the NMEA data used by the PC and radios was supplied by the C120. Since Raymarine released the firmware upgrade for AIS display on the C-series I've been wanting to connect the C120 display to the NASA AIS Engine. To be of greatest value the AIS data should be displayed in the cockpit as one more tool in watch keeping. The C120 is the only chart display visible from the cockpit. However, to connect the C120 NMEA input to the AIS Engine I have to change the Baud rate on both the input and output from 4,800 to 38,400. That would make the NMEA output from the C120 incompatible with the radios that use the GPS position for a DSC broadcast.|
|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.||
AIS Data Network
|I have two listeners to the AIS data, the C120 and the PC. So a simple bus made up of a terminal strip has been used to share the output of the AIS Engine (including the backup Garmin GPS). The picture above, right shows the wiring behind the electrical panel with the AIS terminal strip in the center. The picture on the left is a close up of that terminal strip. I have connected the NMEA input cable for the C120 in conjunction with a serial data cable that goes to the PC. I have connected the AIS engine cable to this terminal strip using a short cable with a male DB9 connector.|
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 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.
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.