NMEA 2000 bridges #2, Jeremy’s experiments
I think you’re going to be amazed at how many NMEA 2000 sensors and displays Jeremy Anwyl has managed to install on his lovely sloop Tranquilidad, though probably not surprised that they haven’t all played together perfectly. In fact, when I wrote the first entry on N2K bridges I joked that Jeremy’s soon-to-come guest entry on the subject might be sub-titled “One brave man’s experiment with a CANbus bridge, and the issues that drove him to it!” The publishing delay is entirely the fault of your easily distracted editor, but the good news is that Tranquiladad did some cruising over the holidays and Jeremy has more testing results he can add to the comments that will no doubt follow his initial bridge experimentations…
Jeremy Anwyl:
I should admit upfront that I am a bit of a tinkerer. My wife and I purchased a Beneteau 57 sailboat back in 2005 and I have been messing with it ever since.
One of the more extreme projects three years ago was to replace the boat’s standard aluminum mast with a carbon mast from GMT. Pulling a mast affords a great opportunity to replace the devices at the masthead. Upgrading to a LED tricolor/anchor light/strobe from OMG for example. Another upgrade was an ultrasonic weather station from Maretron. Being a NMEA 2000 device, this was all the excuse I need to start down the path of installing a NMEA backbone. And, of course I would need a Maretron DSM200 to read all the data coming from the weather station.
Looking back, this all seems a very long time ago. I really bought into the ideals of NMEA 2000 — that devices from different manufacturers could all cohabitate. Sensor data from one manufacturer’s device could be shown on another’s display.
Reality, as I found, is a bit more complex. I don’t have to point out to readers of Panbo that being compliant with NMEA is no guarantee that a display will be understand every PGN (necessitating different displays for different data). Props to Maretron for their DSM 250, which is the most comprehensive display I have seen.
But reality didn’t stop tripping me up there. I have been learning through hard experience as I have added and upgraded all sorts of displays and sensors. Here’s a list of what is currently installed:
1 Airmar PB200 Weatherstation
3 Furuno FI 504 displays
1 Furuno FI 501 display
1 Raymarine ST70 speed pod (speed data from a Airmar CS4500 ultrasonic)
1 Raymarine ST70 depth pod
1 Actisence NMEA 2000/USB
1 Actisense NMEA 0183/NMEA 2000
1 Actisense QNB
1 Maretron USB 100
1 Simrad AT10 NMEA 2000/NMEA 0183 converter
1 Raymarine AIS 500
7 Raymarine ST70 Displays
1 Raymarine ST70 Pilot control head
2 Maretron DSM 250 Displays
4 Lowrance LMF 200 Displays
1 Lowrance LMF 400 Display
1 Lowrance EP 85 Storage Device
1 Maretron EMS 100 Engine
3 Maretron TLA 100 Fluid Level adapters (water and fuel)
1 Floscan FloNet fuel flow sensor
1 Raymarine E120 chartplotter
1 Maretron RIM 100
1 Maretron SIM 100
2 Maretron DCM 100s
2 Maretron ACM 100s
1 Maretron ALM 100
1 Maretron TMP 100
1 Raymarine SPX 30 Autopilot controller
I was very careful to follow best practices when installing the network. Even so, as the network expanded, I started experiencing weird behavior. The most troublesome was that various devices would randomly drop off the network. They would stop transmitting — for no reason I could discern.
This first occurred with my Floscan Flonet device. Later with my ST70 pods. Then my Lowrance EP-85. I also found that when connecting the Maretron ALM 100, bus errors would skyrocket. On top of all this, my ST70 displays would randomly lock up, or reboot–and often lose settings in the process.
I would check with each manufacturer’s tech support. I would get allusions to capacitance issues. Or impedance issues. Or timing issues. Or reflections.
None of which meant much to me.
Maretron’s tech support has been one of the best and is very responsive. Especially as I often call with questions about other manufacturer’s devices. They suggested upgrading my backbone from micro to mid cable. This would reduce any voltage losses and minimize impedance. They also suggested snaking the backbone through the boat to reduce drop cable lengths (to help with reflections). And finally, to try to use the same cable wherever possible.
This project was dutifully completed. And I did see my error count drop. It further dropped when Raymarine released software V 3.03 for their ST70s. (Version 3.03 is finally close to stable, so it is worth noting not all problems are related to cabling.)
But still I would have devices drop off the network (and continuing to add more devices made the problem worse).
Things really deteriorated when I installed an Airmar PB200 (after reading some glowing reports on Panbo). I received one of the first PB200s not to have the terminating resistor in the PB200. NMEA decided this was a bad idea and to comply with NMEA dictates, Airmar now offers the resistor as an option in the cable — not the device.
After installation, I found that when the PB200 was connected, the network error count would soar and devices would drop off the network. Disconnect the PB200 and the network would be much more stable. Finally, I tried the crazy idea of installing an inline resistor at the base of the mast. This actually worked — mostly.
What I am learning is that impedance and capacitance are real issues. Mixing cables, for instance, is known to create problems. (Hard to avoid when some devices come with a cable attached, or when devices use proprietary connectors.) Some devices use “ceramic” versus “crystal” oscillators, which apparently can cause timing mismatches.
Through all of this I have become what I would term as “subject matter dangerous.” I have learned the issues, but not enough to really know what to do about them.
One thing that occurred to me was the notion of breaking the network up into smaller components and finding some way to bridge them together. Smaller networks, my reasoning went, would help isolate problems and perhaps bring any capacitance and impedance issues within norms.
The problem was that I had never heard of a NMEA 2000 bridge device. I asked around and learned the idea wasn’t completely novel and that if I waited, perhaps next year, one or two might be introduced.
But wait a minute. Isn’t NMEA 2000 a set of specifications based on the CAN bus standard? CAN bus networks play in a much bigger arena that just the world of boating.
Digging around on Google, I quickly found CAN bus bridges do exist. One company, ICP DAS-USA was located here in Los Angeles and offers a whole host of CAN bus gizmos (That is gizmos with a small “g.”)
Taking a chance, I ordered their CAN bus bridge (the I 7532) which is priced around $350.
Installation only requires power and a connection to the CAN L and CAN H and shield of both buses. There is the option to power the device from the network, or to power the device and each network separately to manage any long voltage drops. This second option also allows one bus to be powered down without affecting the other.
So installation is simple, but does the bridge work?
For my boat, the idea was to create a small network for the troublesome Airmar PB200 and four Furuno displays on the mast. This would then bridge to the remaining primary network. I made the connections, powered everything up and…everything worked. (I use Maretron’s N2K Analyzer to see what is happening on the network and Maretron’s DSM 250, which can count system errors.)
Everything worked, that is initially. The Floscan and Lowrance EP 85 stayed up on the network. But I found the PB200 would still drop off several hours.
I then set the PB200 up on a network by itself. This seemed better, but still not quite right. I am really getting suspicious about the resistor that is inside the Airmar supplied cable. What is crazy about this NMEA requirement is that troubleshooting this is very difficult. To check the cable resistance, I need to disconnect the PB200. This would require going up the mast and trying to reach out to the end of a wand extending up and forward of the mast. Something I am not looking forward to doing. (I installed the PB200 when the mast was again out of the boat.)
Other than the PB200, the rest of the network is doing well. So my bridge idea was not completely crazy. I have continued to test and so far what works best is the PB200 on one end of the network and the bridge on the other with termination at the bridge enabled. I then connect the Furuno displays as a spur via a tee connector. It is a long drop cable length–probably over 12 feet but seems more stable than a network with the PB200 at one end and the displays at the other, connecting to the bridge via a tee. I have no idea why. After testing for a few days with setup means that the Floscan and EP-85 remain online. Progress!
So what have I learned? First, that I really like Furuno’s approach to terminating resistors. (With the FI series displays, they can be enabled or disabled via software. It would be a wonderful if I could to troubleshoot my PB200 using Airmar’s weathercaster software.) NMEA, are you listening?
Second, that even with a bridge, each network is not completely isolated from the other. If they were, why would the configuration of the PB200 on bus 1 affect the Floscan or Ep-85 on bus 2? Again, I am way over my head here…
Finally, I have learned that a network bridge is a useful solution. Not only can I (partially) isolate a troublesome device and troubleshoot without bring down the whole network. I can also set up a separate network for low priority devices. Battery monitors, switch monitors, tank level sensors, etc. These can then be bridged over to the primary network. (Something I am planning on trying next.)
Or I could set up a second network for devices used underway that could be shut down when at anchor to save power. And finally, bridges are a way to break the bounds of NMEA 2000 backbone lengths and limits on the number of devices.
There are NMEA 2000 bridges being introduced. Some will offer data filtering w
hereby you can control which PGNs get bridged from one network to the other.
But in the meantime, I would recommend CAN bus bridges to anyone who needs one now.
{How about a big Panbo hand to Jeremy for sharing his experience! Also, I’m pretty sure he’s willing to answer followup questions and also to catch us up on what he’s discovered since he wrote this in early December — Ben}
Well done Jeremy!
Jeremy, Some questions.
(1) Can you configure your PB200 across the bridge, e.g. with WeatherCaster on a 2nd network?
(2) I agree with the idea of having a second network to be able to easily power off things you only need underway vs. at anchor, covered in Panbo “Adventures in NMEA 2000 wiring, Part I” In your case, have you thought about a third network so you can turn off a majority of your displays with a single switch ?
(3) With all your tinkering, did you come up with a good way to dim the displays together manually or automatically in response to light conditions?
(4) Which display performs best in sunlight ?
Hi Dan.
1/ Yes. The PB200 is on network 1 and the Actisence device connected to the computer running Weathercaster is on network 2. I have noticed that configuring the PB200 takes a bit longer, but it works.
Incidentally, I recently found that the in cable terminating resistor used with the PB200 is missing or at least not functioning. This is obviously a problem. Airmar is making an old style PB200 with termination in the PB200 which I will test this weekend. Cudos to Airmar for taking this step.
In the meantime, an inline resistor at the foot of the mast has brought the impedance on network 1 to 61 ohms and settled the PB200 down.
2/ I like the third network idea. When anchored, I like to power down most devices to save power. I was also thinking of running a network for Raymarine, Simrad and Lowrance devices as their cables are much smaller than the Maretron cable is use when possible. (Apparently, cables mis-matches are a problem.) On the other hand, I have heard about bridges introducing system latency. Might be something to consider.
3/ Dimming displays is a challenge. The new St70 software does allow you to set up zones and manage each zone from any display within the zone. This helps. But I don’t think there is anyway to do this with other devices across the network.
4/ I put 4 Furuno FI displays on the mast. These are very visible and have the advantage of turning on a backlight automatically at night. (When sailing at night, I turn off most displays in the cockpit. The Furuno displays are visible, but dim enough to protect night vision. But they are “old” style and not graphical displays.)
The ST70+ is the brightest graphical instrument display I have found.
One other note. Brides may isolate impedance problems, but PGN conflicts cross the bridge just fine. In other words, bridges are not a cure-all.
One recent example: I found that Maretron’s N2K Analyzer was causing the PB200, Floscan, E140W and Lowrance ep-85 to go off-line. It also triggers ST70 reboots. Probably something to do with the software performing address claims and the bridge seems to have no effect.
It is easy enough not to run the software, but shows how strange this stuff can be.
Jeremy,
FloNet fuel sensors have other problems as well. In my installation the FloNet connection box gives off enormous pulsating interference, (RFI) on the single sideband radio. Disconnecting FloNet stops the RFI. I have confirmed this with others who have FloNet, SSB radio and N2K. After several months of correspondence with Floscan and shipping the unit back for their testing they have not been able to resolve this issue and concluded,
“since few boaters still use SSB radio it’s not really an issue”.
Well, it is to me and isolating the FloNet from the rest of the NMEA 2000 backbone by bridging may be my only solution. At least if it was isolated with a bridge I can shut off the FloNet side while underway and using the radio and still keep all the other N2K devices like GPS operational.
Thank you for the informative post – very helpful.
On our boat, we also have an extensive network. We installed 4 Actisense QNB-1 network blocks. Using these blocks allowed us to isolate backbone segments and to power up individual sections as needed. Its been up and running for over a year without issue. We started down this path when we installed the Airmar PB200 and were having too much fun with it (ours was an earlier version with the termination pin between the cable and the sensor)
Don
Richard:
I have noticed the same Floscan issue. It seems to be timed to the flashing of the LED. (Could it even be a noisy LED?)
Anyway, must be a power boater mindset at Floscan. (Sorry, Ben.) I can’t imagine going offshore without my SSB.
Regarding Floscan and N2K–I cant say the Floscan is the problem. It could be another device behaving badly. That is the had part part with all this: Discerning symptoms from root causes.
Don:
I have a QNB-1 as well and use it as the power tap. The power to each branch is isolated, so it seems a great idea to add switches.
What problems were you having with the PB200?
Thank you Jeremy. I find this most helpful and the timing is just right even including any publishing delay introduced by the editor. I have a number of practical questions and one philosophical:
1. What tools do you use for troubleshooting? Is there a alternative way (software) to see the error rate apart from a DSM 250? Which analysis/debugging software helped you more and which less (Airmar Weather Caster, Actisense NMEA Reader, Keversoft’s (Kees’) Packetlogger, others)? Do they all work with the Actisense NGT-1? Do you need a Maretron USB 100 in addition to the Actisense NGT-1 such as for configuring the PB200? How do you measure impedance?
2. Do you expect Airmar to offer the old style PB200 as an ordereable item? If not, should one not rather order an unterminated long cable with the PB200 and use an inline-terminator between it and the PB200? Or would this not fit the mount of the PB200? If not, could a very short pigtail be used between the PB200 and the inline terminator and then a long micro or mid cable down the mast? In short: if you were dismasted and had to do it all again, which way would you go? Would you go so far as to use the PB200’s NMEA0183 output down the mast, then convert it to N2K with an Actisense NGW-1 or other at the base of the mast?
3. Where do you get an inline terminator? There is none in the Maretron cabling catalog. Generally, where do you buy cabling?
4. Are you aware of any smart alternatives to the Raymarine ST70 speed pod in order to use the Airmar CS4500 (that would otherwise be the only Raymarine device on my boat)? I’m am looking at an Actisense DST-1.
5. Do you use any PC Navigation Software and if so, what is your experience regarding support for the Actisense NGT-1 or Maretron USB 100?
6. You recommend it but would you make it a hard rule to always isolate cable types? Even in minor cases where you would connect a single SimNet device to the DeviceNet backbone using a Simrad converter-spur-cable? Would you consider isolating manufacturers in addition to cable types?
And the philosophical question: Surely, your boat had instruments before N2K came on board. And your story sounds like at least 100 hours spent reconfiguring and troubleshooting – not counting the original installation time of each device. If that is leisure time well spent, like Sudoku only better, then that’s wonderful. But what if you become pressed for results or are at sea, needing your instruments? So what have you gained, what have you invested (in time, not money) and what have you lost by switching to N2K?
Jeremy,
The issue with the PB200 was that (1) it was 106′ up the mast somehow messing up timing, impedance etc. (2) more likely, it was the straw that broke the monkey’s back by pushing us over the network power limits. Anyway, we installed a QNB-1 at the base of the mast and network performance improved dramatically. As we kept adding to the network power limits again became an issue. Therefore we further broke up the backbone with additional QNB-1’s. Luckily instruments and sensors were already laid out in a manner that made putting switches on the power taps made sense.
We also sent our Raymarine ST70’s and pods back to have the firmware updated and noted a great improvement in performance. Our experience with Raymarine support in this regard was a real joy.
Don
Jeremy that is a lot of info to digest for sure…
I recently had my firms (Marine Services Division) re-fit my own Beneteau Oc-400 model… Vessel was hit by lightning and all the equipment failed… had a mix of brands on board at that time from Furuno radar to Northstar 6100i MFD/gps to Raymarine ST60’s and Simrad Autopilot…all not that old but all fried; and were all 0183 based data.
Now have virtually all Simrad – NSe8 all IS-20’s instrument displays (5) of them and Simrad Autopilot AP/28 & 24 displays, Airmar PB-200 with terminator at the top of the mast (with the backup 183 cable run just in case). For transducers we have 2 Airmar P-79’s one for regular depth with the other for the Simrad/Navico BSM-1 (Fish finder) and Airmar CS-4500 ultrasonic speed sensor fed to Airmar data converter box (analog to 0183) that feeds the Actisense NGW-1 into the N2k network… Also have the NEP-1 Network Expander box that feeds “broadband” info to the NSE.
Most recently we added an Actisense NGT-1 to feed N2k data to laptop.
An aside note: (Now need to find good charting software that can read the N2k data so I don’t have to install yet another converter) Any suggestions?
This system also has Simrad 2kw HD Radar, NAIS 300 AIS transponder and the Lawrence HS-7 at the helm in place of the Yanmar 4JH2/Beneteau “control” panel; it gets its data from N2k data box that plugs into the Yanmar wire harness… got this from Ron List at Mas Technologies which is a division of Mastry Engine. Maretron has this type of engine data box too but I believe this Mas Tech version is better. This box takes all engine data to either the NSe8 or HDs-7 via N2k both MFD’s use the same Navionics Chart chip, the HD-7 has internal GPS antenna so it acts as a lower cost back up chartplotter unit at the helm and as the primary engine data display as the same time.
The NSE has its own GPS antenna, PB-200 has GPS antenna, AIS has its own GPS antenna the Lawrnece has one internal, so there are lots to choose from. Speaking of antennas we have the Digital brand on top of the mast for one of 2 Icom 504 VHF radios and a Digital antenna on radar arch for second Icom radio in cockpit. Also have the Digital Antenna Cell Phone amp system and yet another one for the AIS on the radar arch, not to forget the Glomex 10″ TV antenna also.
So far in limited use (Day Sailing on Biscayne Bay or weekend in the Keys) the N2k network and equipment is working fine… only issues so far that we have found is with the Simrad Wind and Tack Is20’s with the True and Apparent Wind speeds… this could be a user “menu” set up issue….not sure… but so far I have not seen a “Glitch” other than that.
We used the Smaller of the two N2k cables, tried to put the power drop in the middle of it all with all Simrad brand cables where we could feeding into the 3 and 7 input “joiners” and other converters.
Overall I am very pleased with the system and at this stage do not have issues with “equipment communications” issues…. Then again we did stay with the majority of the equipment from one manufacturer. This was a tough decision at the time and now reading what Jeremy has been going through it looks like the right decision.
Of course I changed out most if not all lighting to LED…Lopo tri-anchor at the top of the mast all Cantalupi LED with dimmers below and Lumitec LED deck lights.
We are in Miami, and if anyone wants to see this set up in use while in town for the Miami Boat show let me know. [email protected]
I recently installed a much simpler N2K system, but experienced similar problems. I also have a PB200, but decided to run NMEA 0183 cable up the mast instead of N2K. The problem then was to translate the 0183 to N2K for the instruments. I first tried a Simrad AT10, which I have found to be quite reliable, but as it translated a limited set of GPS data (PGN 129025 only), the new MFD I purchased would not recognize its position data. So I tried another well known translator, which the MFD at first recognized (PGN 129029), and then later crashed. Another translator works well for an hour or so, and then simply stops working until power is cycled.
After several months of waiting for answers from the MFD technical support, they finally admitted being aware of the crash problem, and blamed it on “bad data” being sent from the translator. They also stated that the product specifications (which include the unrecognized PGN 129025) was a “marketing error”. They suggested I should look for a “workaround”.
Errors are inherent in all networks, which is why error correction is a key network component. Network errors or “bad data” alone should not cause devices to, as Jeremy experienced, “randomly lock up, or reboot”. If bad data alone can at any time cause a device to fail (likely in fog filled shallow water), it is clearly indicative of inadequate error correction, and cannot be safely relied upon at sea. Needless to say, I found a workaround and returned the MFD.
However, my experiences with N2K have not been all bad. The Simnet devices I installed have all worked without issue, and I like their simple wiring components. With three 0183 translators (PB200, DST, PC), six instruments, and an autopilot, no N2K network errors have been detected. But I won’t be adding further N2K components without lengthy testing, and I won’t be going to sea anytime soon without a 0183 backup in place.
Cheers,
Noel
Jeffrey, with the PB200,
(1) If problems with true/app wind, disable the true wind output on the PB200. Sometimes the other instrument displays or MFD’s (I found this to be the case with Raymarine when using the 0183 output of the PB200) will insist on taking the apparent wind output and converting to true. You get the same outrageously good wind results with the PB200 (app and true) no matter what device makes the apparent to true conversion. Of course you still need a good STW for true to be correct.
(2) Disable SOG/COG GPS output and the compass output on the PB200, the GPS and compass isn’t motion corrected like the wind is, big mast swings throw off the SOG/COG/HDG.
Noel, Why did you decide not to use the N2K output of the PB200? Translating data from 0183 to 2000 is hard, especially when it comes to all the GPS messages. Jeremy got a PB200 with faulty termination; many of us have PB200s that work on NMEA 2000 backbones just fine.
In fact, I’ve used a lot of the sensors and displays that Jeremy has without any drop out or other problems, even on a backbone composed of very mixed cable and connector types. It’s just that Jeremy has an especially large system which seems to include a couple of troublesome devices. Let’s keep things in perspective.
The issue I was focused on in my above post, is that I found issues when I had two devices converting apparent to true simultaneously. The chartplotter and some displays would momentarily display an improbable value. Since only the PB200 had the flexibility to turn off the true output, thats the one I turned off.
Yes, I agree the LED could be the culprit here, however LED interference problems are ancient history and should have been engineered out of any recently produced electronics like FloNet. I shouldn’t have to spend $350 for a bridge to put a band aid on poor design. Without any interest from Floscan the bridge idea is my only alternative.
Ben,
I used 0183 with the PB200 to avoid having to deal with potential N2K problems 60′ in the air. Ironically, I had to retrieve it anyway and send it to Airmar for repair (a fried diode). I’ve since decided to replace it with a simple birdie atop the mast, and move it to the stern. I do think it’s a great sensor, I just want it where I can get at it more easily.
What I don’t understand is why translating 0183 to N2K is so hard? 0183 is a simple, very well know protocol. My Simnet instruments and autopilot read 0183 position data fed through an AT10 from both a PB200, and a trusty old GP30 without error. But I’ve tried both single and multi-purpose (MFD) translators and found only the rather simple AT10 fails to fail.
Is N2K overly complex, or are we trying to move too far too fast? My myriad of recent issues with N2K are symptomatic of what I have witnessed over several decades of working with new technologies before they mature. No doubt, I enjoy being on the bleeding edge at port. But at sea, where reliability is key, I’m sticking with 183.
Cheers,
Noel
P.S. I really need a solid 38k 0183>N2K for AIS if you know of one.
Hi Henning:
How’s this for irony: I am sitting on a plane to New York, writing about technical issues on my boat, after waiting three hours for my flight to leave, delayed by technical issues. 🙂
1/ As you noted, I do use the Maretron DSM 250 as a simple diagnostics tool. It shows network load (mine runs around 12%) voltage , etc. I often leave it running overnight to count bus errors. Maretron also has a N2K testing tool I have used and this is much more precise. It measures impedance, tracks errors down to the device, etc. (But remember, a device may report errors, but not be the problem.) I also use a simple voltmeter and ohmmeter.
I haven’t tried Packetlogger. The Maretron testing tool is self-contained. Their N2K Analyzer does need the USB100, which I believe basically converts NMEA 2000 to NMEA 0183.
I have also used the Actisence NMEA 2000 to USB device and it seems to work well.
For measuring impedance, I just shut down the network and measure impedance across CAN high and CAN Low. On the large network, it is around 64 ohms.
2/ I would doubt that Airmar will offer the older style PB200, but don’t think it matters. Furuno offers a Furuno branded PB200 that sticks with the pin style terminator. Just order the Furuno device. (This wasn’t available when I ordered my PB200. Indeed, I didn’t even know a change had been made until I contacted Airmar tech support asking when the pin was that was referenced in the manual.)
The problem with an inline terminator with the PB200 is that the device and the cable use a custom connector. A pigtail would work, but I try to avoid an excess of connections exposed to weather at the masthead.
If I was dismasted–perish the thought–I would just order the Furuno. I have thought about using NMEA 0183 and converting to NMEA 2000, but–so far at least–conversions seem less to perfect.
3/ The inline terminators I use are from Maretron. (Part number IT CM CF) West Marine has them, as do others online.)
4/ The CS4500 is great. I think it outputs NMEA 0183, so getting data over to NMEA 2000 is not too difficult. The nice thing about using the ST70 pod is that you can set speed adjustments that are stored in the pod. These adjustments can vary for different speeds. (I have them set at 2 kts, 4 kts and 8 kts.) This allows for very precise STW readings. None of this would be possible with a simple NMEA 0183 to 2000 convertor.
5/ I have been using RayTech navigator. Over the Holidays, I upgraded my E-series to the new E-Wide. These do not support Raytech. (Over Seatalk hs) I have it running now getting data from Seatalk, bridged from NMEA 2000 via the E140W. I am considering more up-to-date options (Fugawi for one), but would also be interested in opinions.
6/ Your question regarding cable types is a good one. I have been told that different cables can cause capacitance problems. And that bus capacitance is set by the smallest cable on the bus.
I have also been told that this is the (theoretical) problem with daisy chaining devices.
But I am in way over my head here.
My current plan is to try the new PB200 and see how much that helps. Then, if I still have problems, try isolating parts of the network until I get stability.
For me, it is very much trial and error.
As for the philosophical aspects…
The boat did come with a simple Raymarine st60 speed/depth/wind set up with a couple e-series. I remember one trip to Santa Barbara when the helm instruments were not working. No one in Santa Barbara could help me, so I resorted to troubleshooting and fixing the issue myself.
From there, I added a wireless smart controller, and on and on.
Obviously, there is a hobby aspect to all this. The boat is used for day sailing, weekend trips and long distance cruises. With from 1 to 12 crew. I have three helms set up, depending on use and can convince myself there is some utility (and safety) to the upgraded as well.
But it can backfire when things don’t work. My last trip before the switch to the new E-wides, we were headed into the slip at night. At exactly the critical moment, both the cockpit e series rebooted—going from very dim to fully bright. We all lost out night vision. (Fortunately, superior helmsmanship saved the day.)
So I build in redundancy. The SPX30 pilot is using a hard wired gyro compass. This connects to the NMEA 2000 network—but also to a separate Seatalk network with a left over ST60 pilot. This way I always have a functioning autopilot. My computer has a USB GPS available—just in case.
Looking back, I would recommend sticking with one manufacturer’s equipment, if possible. The obvious problem is that this limits the functionality of your system. Lowrance’s LMF gauges (and EP-85 storage) are uniquely useful when equipped with Floscan’s data. Maretron’s DSM 250 display reads far more PGNs than anything on the market. Furuno’s FI gauges are uniquely useful at the mast. And so on.
So, the real question is: Why doesn’t this stuff work? It is not impossible. Maretron’s devices seem bullet proof. I have heard this is because they use slightly more expensive oscillators.
In any event, they show it can be done.
When we purchased the Airmar PB-200 we ordered both cables N2k and 0183… only as a precaution.
We only hooked up the N2k. Will look into the advise given above regarding the true/apparent wind issues and see if that does the trick.
Jeremy….you have too much crap on your boat.
Any vendor having an electrical noise problem on their product that affects SSB should take the issue seriously. If if the noise is going over the air rather than just over the boat’s network, they can get cited and fined by the FCC. It doesn’t matter how many of their customers actually use SSB, just consider the SSB as a product which happens to indicate there may be a problem worth investigating.
Sigh,
The parties responsible for a SSB transmission are responsible for the performance of their equipment. While the floscan noise issue is clearly annoying at best, in the instance mentioned, the operator remains responsible. There exist numerous ways to suppress noise input including shutting down offending noise sources during SSB use. The threat of a FCC fine is pretty remote. The SSB bands are full of natural and man-made noise.
Cheers
I know it’s been discussed before, but I keep thinking the same thing: N2K/Canbus still seems fairly broken and not very robust. Why didn’t they just use existing ethernet components (modded for the marine environment) and have these devices communicate using existing (and truly tested) protocols like TCP/IP, etc. I doubt they would have these strange issues impedance/capacitance issues, and probably drastically increase the range of drops in the process.
Why does the marine electronics industry insist on re-inventing the wheel and makings things so complicated? And yes, I understand canbus is a standard as well. It just doesn’t seem to work very well (especially for larger installs).
Not impressed with this tech.
Sigh.
Probably the same reason you don’t have an Ethernet mouse or GPS attached to your laptop, Beaver. It doesn’t make sense. Certainly Ethernet has become a marine standard for high bandwidth applications (though sadly not an interoperability standard). And any manufacturer could have built GPSs, depth sensors, wind vanes, etc. but they didn’t. Why not?
Having been messing with this stuff for a few years now, it seems that NMEA 2000/CAN Bus is not the problem. (Although I suppose it could be more error tolerant.)
Maretron device seem solid. I have had no issues with Furuno. So it can be done without problems.
What is a problem seems to be manufacturers with bad practices with oscillators, cable sizes or PGNs that trip things up.
There would seem to be a role here for NMEA. They worry about things that don’t matter and don’t seem involved in things that often do…
Chetco Digital has released this month a wireless NMEA2000 compatible interface using Wi-Fi or wired Ethernet. The module is about the size of a pack of cigarettes This allows basically all gauge and switch PGN’s (including PB200) to be displayed on PC/Laptop, iPad, iPhone, Blackberry, Android etc. using the browser. Anyone interested in more info please contact me. I tested the small module installed on my PB200 and the signals are received wirelessly on my Samsung Fascinate display.
When used on the N2K network I get 40 – 50 gauge and switch indicators on a scrolling page.
The product is not on the web page yet but will be over the next 2 weeks.
Hi James:
I would be very interested in more info. How should I contact you?
James I certainly want to learn more send me info to [email protected] thanks, jeffrey
Thanks for yoru contact I have emailed both Jeffrey and Jeremy. My contact is [email protected]
Steve