help with nmea 2000

[magna 6882]

Hi Peter
the depth was eratic, maybe 5 minutes once every few days, and showed the speed in the sonar information square along with temp and time.This was back in early 2001.lately the depth starts blinking about 15 minutes out of every hour the speed source warning just started and it just come up for a couple seconds and dosnt seem to affect the ap.
One fella i talked to thought i should check what speed source the ap is looking for. i thought the speed would be coming from the gps.
It very well may be just the wrong settings .originally when the problem fist appeard i suspected the transducer. The manufacture wants me to verify i have been updated correctly. Are you starting to head south?

 

[twistedtree]

Hi Peter
the depth was eratic, maybe 5 minutes once every few days, and showed the speed in the sonar information square along with temp and time.This was back in early 2001.lately the depth starts blinking about 15 minutes out of every hour the speed source warning just started and it just come up for a couple seconds and dosnt seem to affect the ap.
One fella i talked to thought i should check what speed source the ap is looking for. i thought the speed would be coming from the gps.
It very well may be just the wrong settings .originally when the problem fist appeard i suspected the transducer. The manufacture wants me to verify i have been updated correctly. Are you starting to head south?

I don’t know that particular transducer, but assume it’s a paddle wheel. They are very problematic. I would set the AP to use SOG from the gps, and not STW from the transducer. If nothing else it will be more reliable.

If you have two MFDs side by side, you could also move the transducer to the other MFD. it probably requires changing some settings, but would confirm whether it’s the transducer or MFD.

 

[Helmsman]

Buy a 4 tee connector, and replace one of the tees with that. The yellow tee is probably the power supply to your NMEA network. Follow the wire back to see if the wires are connected to bus bars. If the opportunity exists, it is better to have the power tee midway through your network, as opposed to the end the way it appears to be setup.

Aah. The yellow connector is a power isolator. I didn’t see the drawing. Sorry about that.

 

[wkearney99]

Thanks everyone for giving me ideas. i got the wiring diagram attached.

Nice! That really helps clarify. As I suspected, the isolator is there to take the flybridge devices off the network when the flybridge is offline.

Though I would wonder about having the XB-8000 on the flybridge segment. It'd seem like you'd want to have your AIS unit either powered on it's own, or on the 'main' bus. It'd be a relatively simple fix, just move the isolator up there on the end and move the XB-8000 in-between the isolator and the backbone leading down.

I see your B-260 transducer is connected to the 8612 via it's own connector (that isn't N2k). That's how those are usually connected and the data from it is being bridge from that 8612 out to the other plotters AND the N2K network. The config on the 8612 would have to include announcing the PGNs from it to the N2K network.

You mention 'speed'. Where is your system getting it? Because the B-260 does depth and temp, not speed. https://www.airmar.com/uploads/brochures/b260-ss260.pdf

Do you have some other sensor?

Otherwise speed is going to have to be calculated from GPS as SOG (speed over ground). To get STW (speed through water) you'd need to have the usual 'paddle wheel' sensor through the hull.

Which brings me to the question of GPS.... I don't see a standalone GPS unit on your diagram. Nor do I see anything providing heading.

The XB-8000 can, but wouldn't if the flybridge section of the bus wasn't powered.

That would leave the chartplotters on their own to use their internal GPS antenna. This would also introduce the potential for conflicts on the networks (both N2K and the Garmin ethernet links) with too many of the charplotters sending the same GPS (and possibly other) data.

I don't have a Vesper, so I can't attest to it's usefulness for this data. My network as had both a separate GPS and heading sensor. I now how a Furuno SCX-20 satellite compass that does both.

So I'd revisit how the XB-8000 is powered AND go into the configurations on the plotters and displays to make sure how they're configured to get their GPS and heading, and how they retransmit anything back OUT onto both the N2K and garmin network.

That and make sure any duplicate devices on the N2K network (the two GHC20, 8412 and VHF210) each have their own device instance ID. This way if they DO announce anything others on the N2K network won't be confused about the source. The Maretron N2K Analyzer software makes it really easy to see this. I don't know how the Garmin units set this.

 

[Helmsman]

The Vesper Xb-8000 has a load equivalency rating of 2. The total LEN used up top is 12. The lower powered portion of the network is 15 LEN. Moving the XB-8000 to the lower network would raise the bottom to 17 LEN which is still within the recommended spec of 20 LEN.

If the XB-8000 supplies the GPS reading to the network from it’s attached GPS module, taking it offline could be the culprit, if the other devices do not have instances assigned. Since it has worked ok in the past, I don’t suspect that is the issue.

I would start by determining which device has the first incidence in the network. I would then change the incidence number (usually zero if I remember) to one of the other supplied GPS units (MFD, VHF?). If the problem goes away, there is an issue with the original primary GPS signal.

If that is the case, determine what is happening with the original primary GPS. Has there been a recent change on the boat limiting a clear view to the satellites? Is the wire attaching the GPS to the network (if external) corrosion free and tight? If the primary is an internal GPS check the connections (perhaps replace with a spare cable and tee temporarily to eliminate the cable as an issue) to the network from that device. If the problem goes away, then, the cabling was the culprit.

One other thing to check is the terminators. Make sure they are tight. The network should have a resistance of 60. A bad or loose terminator can wreak havoc in a network.

 

[magna 6882]

This drawing is what was installed at the factory. When commissioned they installed a roof mounted gps,the vesper antenna and an airmar weather station. I need to look at where the made the connection. Also the vesper unit is under the helm mounted to the same wall the back bone . My problem might be settings in the equipment since the transducer is connected directly.

 

[wkearney99]

The airmar wx can send GPS and heading. Be sure it's instance ID is set so that nothing bothers getting navigation data from it. Good to know there's a standalone GPS, be even better to know where in the bus it's connected (as in, in that flybridge section?)

The settings in the chartplotters would certainly make a difference but it'd start by making sure each device has it's own N2K instance. The decide which ones are going to be "authoritative" and make sure your plotters and displays reference that device as their source. Most are capable of taking a 'fallback' approach if their designated source isn't available. But that's where it's important for the instance ID to be set correctly so that if a device does have to fallback to something else it's not trying to resolve conflicting data from devices with the same instance ID.

Transducers do fail. I seem to recall reading that some DO NOT like to be powered up while out of the water on the hard. Don't know if yours has that risk or not.

As for the start of all this, the depth and speed problems. It's clear now you have depth coming into one plotter (and you've confirmed there's nothing else showing up the N2K bus that could also be providing it?) Be sure that plotter is configured to pass that along properly. And then make sure anything else that depends on it for depth is also configured properly.

For speed, from what you've described you've got nothing providing actual STW (speed through water). So it's got to be calculated by anything that needs "speed" and that's going to come from GPS and be used as SOG. Make sure your autopilot is configured to use the right source (probably the roof-mounted GPS).

 

[wkearney99]

I've read elsewhere online anecdotal statements about the GPS and heading data coming from weather units as to be "less than useful". And also that the Airmar units can be reconfigured to NOT send this data. But as yet I've not configured my WX220 to not do this.

 

[magna 6882]

I have a call into the fella that installed the roof top stuff to find out if he went to the fly bridge or to the helm. I dont have anything for speed thru water only speed over ground. The depth problem that has progressively gotten worse over the years is one problem. Where the speed gets odd is the plotters show speed fine its just that the speed has disappeared in the little box displayed with the depth. I dont really look at that i just noticed it was gone when comparing last years sonar pictures to this years. The speed disappearing from the auto pilot is new for this month.
You guys are so much smarter then i am regarding this stuff.I need to poke around the plotters its just i dont like doing that while underway. i am going down to boat tomorrow to look at some things. The tester and interface wont be here until monday.

 

[wkearney99]

I agree with not poking around at the plotters while underway. The boat can wander while you're mesmerized by the display.

Which "little box" on which display?

Use your network diagram and the N2K Analyzer program and start disconnecting anything you're not "certain" where it runs. This will help you determine which connectors go where. Otherwise go into your display configs and their 'sensor list' section. They've all got it in the settings somewhere, that's where they can be configured to pick/choose which sources to use. While that list is active on a display, disconnect the drop tee cable from something and see which source drops off the sensor list. While it's nice to have perfect looking labels, for now it'd be just as useful to use some blue painters tape and a marker to label them.

The sensor list in your displays should also help determine if there's any other devices on your N2K network that aren't noted on that original schematic.

 

[wkearney99]

You guys are so much smarter then i am regarding this stuff.I need to poke around the plotters its just i dont like doing that while underway. i am going down to boat tomorrow to look at some things. The tester and interface wont be here until monday.

We're probably only smarter because of experience. There are some debugging skills you have to learn in order to own/operate a boat. As in, which damn thing is broken THIS time around?

Get your whole network turned on (radar, autopilot, displays, vhf, chartplotters, etc). Go into the settings on anything with a screen and start manually compiling a list of what devices each one can see.

That's your best starting point, and it can be done while you're docked.

Then compare to make sure anything with a display can see all of the other devices. That'll give you a good foundation for what you have, and that everything can see everything.

Then it's just a matter of making sure that each device that "consumes" data from the network is getting from the proper source, and that those sources are configured correctly. THAT is where having the N2K analyzer connection can help.

 

[Gdavid]

Lots of good information here, thank you for sharing, especially to Bill.

I have been reconfiguring the meager electronics on my boat, including expanding the NMEA 2000 system and the ethernet networks and everything miraculously worked the first time. I did run the backbone between the upper and lower station in the opposite direction than I planned but it was an easy fix to get the adapter but I wasn't about to re-run that cable.

Thanks again.

 

[magna 6882]

Oky so today i did some checking. I was wrong about having a garmin gps. What is on the roof is a sirius antenna . The gps that show up on the list are the airmar, vesper,and the three garmin mfds. The source for the gps was one of the mfds. i suspect this was done at the factory since the vesper and the airmar were installed later.The airmar had the best signal so i chose that.I had o.oo speed on the display which is better then _.__.

Do i need to make changes to each mfd or do they talk to each other?

 

[wkearney99]

You need to read your chart plotter manuals on how they're configured to use NMEA-2000 device sources.

You should mentally decide which one you're going to consider the "authority" for them all and configure everything to use that one.

Personally, I'd want to have a better source of GPS and heading, and I chose a satellite compass for this as it's much faster and more accurate than using standalone heading and 'mushroom' GPS units.

But if you're OK with how the Vesper it doing it then that would be my second choice. I would not depend on the chart plotters for GPS as they're not as likely to get a solid signal in all circumstances. The Vesper has it's own GPS antenna that's probably better placed.

You need to make sure your chart plotters have separate instance IDs, especially the two that are the same. This so if they do share their GPS to the networks they won't be seen as 'the same' one (which can confuse things).

Lastly, I prefer to configure my network so devices (that can be configured as such) are restricted from sending data that is known to be coming from a 'better' source. There's no need to have each of the chart plotters announcing their GPS data back out onto the Garmin (ethernet) and N2K networks. Your manuals for them should indicate how to set this.

 

[Helmsman]

You need to read your chart plotter manuals on how they're configured to use NMEA-2000 device sources.

Lastly, I prefer to configure my network so devices (that can be configured as such) are restricted from sending data that is known to be coming from a 'better' source. There's no need to have each of the chart plotters announcing their GPS data back out onto the Garmin (ethernet) and N2K networks. Your manuals for them should indicate how to set this.

Bill,

when you set up instancing for the GPS signal, and let’s say, have the SatCom as your first incidence, and perhaps an AIS GPS as the second, then is there anything you need to do if you have restricted the AIS GPS from sending its signal to the network, if the SatCom fails? Or will it automatically begin broadcasting the AIS GPS on formation to the network despite the restriction?

 

[twistedtree]

Bill,

when you set up instancing for the GPS signal, and let’s say, have the SatCom as your first incidence, and perhaps an AIS GPS as the second, then is there anything you need to do if you have restricted the AIS GPS from sending its signal to the network, if the SatCom fails? Or will it automatically begin broadcasting the AIS GPS on formation to the network despite the restriction?

That's a really good question, and my own approach is a bit different from Bill's. Let's stick with the GPS example, but it applies to other types of data as well. I prefer to leave any GPS data turned on if I think I might use it on the network, and I do it for exactly the reason you bring up. If the primary GPS fails, most devices listening to GPS data will automatically switch another GPS data source that's available. I want that to happen automatically. If you turn the data sources off, then you need to know how to go turn them back on, and it's a manual, somewhat time consuming process to do. The only reason I would turn off GPS data from a device is if I'm pretty certain I will never use it, and I'm also trying to reduce traffic on the network.


As for the consumers of the GPS data, how you guide them on which GPS to use, and any preference order in selecting among them (so-call Source Selection), will depend on the device. Some give you no direct control and pick the device on their own. Some let you select a single device to use, but it's unclear what happens if that device is unavailable. Others let you indicated a priority list of devices to use, which if course is the ultimate.


I'll follow with a separate post about Instancing which is intimately linked to all this, and which I think deserves some clarification.

 

[Helmsman]

That's a really good question, and my own approach is a bit different from Bill's. Let's stick with the GPS example, but it applies to other types of data as well. I prefer to leave any GPS data turned on if I think I might use it on the network, and I do it for exactly the reason you bring up. If the primary GPS fails, most devices listening to GPS data will automatically switch another GPS data source that's available. I want that to happen automatically. If you turn the data sources off, then you need to know how to go turn them back on, and it's a manual, somewhat time consuming process to do. The only reason I would turn off GPS data from a device is if I'm pretty certain I will never use it, and I'm also trying to reduce traffic on the network.


As for the consumers of the GPS data, how you guide them on which GPS to use, and any preference order in selecting among them (so-call Source Selection), will depend on the device. Some give you no direct control and pick the device on their own. Some let you select a single device to use, but it's unclear what happens if that device is unavailable. Others let you indicated a priority list of devices to use, which if course is the ultimate.


I'll follow with a separate post about Instancing which is intimately liked to all this, and which I think deserves some clarification.

Thank you. One of the areas reviewed in detailed in the NMEA2000 workshops I attended was instancing and how it can impact the entire system. I look forward to getting your perspective.

 

[twistedtree]

"Instancing" for N2K is not as cut and dry as one might hope.


What's been described in this thread is a rigid need for all devices to have unique Instances, or at least for all devices producing the same data to have unique instances. That is a uniquely Maretron view of the world, and is not shared by any other manufacturer. But Maretron has been very vocal about it and has convinced a lot of people, me included for a long time, that it's how N2K works. Not only is it untrue, but it is incompatible with many, many devices. By way of example, on my N2K network today, approximately half of the device, all certified and from reputable manufacturers, are incompatible with Maretron because of this.


Sticking with our GPS example, The ONLY way Maretron can distinguish between two GPSes is if they have different Device Instance numbers. The N2K Standard tells how to uniquely identify devices, and it's NOT this way. In fact they say that a network must work correctly even when ALL INSTANCES are zero.


The way a device is uniquely identified is via it's "NAME" field which is made up of some codes for the device type, a manufacturer ID, a unique serial number, and an instance number. That collective is how you identify a device, not just the Instance Number.


When selecting a data source, all the other equipment I have used shows a list of available devices reflecting these "NAME"s, so you can see the Vesper, Airmar, and MFD as data sources. Some devices show the unique serial number, and some show the instance number. But the source selection is never based solely on the Instance number, and Maretron I think is the only vendor who requires that they be unique. Maretron blames everyone else noting that the Instances are required to be programmable in the N2K standard. But the standard doesn't say how, or whether it needs to be user programmable, etc. And other vendors respond by citing NMEA's description of how devices are identified, and the note that the system must work with all instances zero. So for 22 years this has persisted.



NONE of this is checked or enforced in device certification, and this sort of thing is responsible for 100% of the N2K problem that I've encountered. Although I think Maretron is a big part of the problem, I really blame NMEA for allowing such ambiguity, and failing to include such a critical operation as part of certification. They make such a big deal about only using certified devices, but in my experience certification is completely irrelevant as an indicator of compatibility, and this is a good example why.

 

[twistedtree]

Thank you. One of the areas reviewed in detailed in the NMEA2000 workshops I attended was instancing and how it can impact the entire system. I look forward to getting your perspective.

Was the workshop a NMEA course? I'd be real interested in how they positioned all this, and whether it agrees or disagrees with my post.

 

[wkearney99]

Ok, let's back up, if you have more than one source for a particular kind of data it's worth making sure anything expecting to use that data in a way that's 'shared' is being consistent about it. Especially if they're the same model of device. Otherwise anything listening for data isn't going to be able to make as educated a choice about which source to use. Not that they "won't".

I don't know how well those Garmin units handle source changes on the fly. I know my Furuno gear seems to handle GPS reasonably smoothly but does not like heading shenanigans.

Second, quantity of traffic on the bus can make a difference. The less you have chattering on the network the less chance there is of anything missing anything. It's not a big deal until you get a lot of things making rapid updates. I ran into a problem with this when doing some firmware updates over N2K.

It was with Maretron gear, so that could certainly be a reason for their diligence about it. But the bus was "too busy" and the updates didn't take, leading to one unit getting into a locked state requiring it to be sent back for repair. Personally I view this as a deficiency on Maretron's part because their updater software wasn't being very diligent about checking some of the firmware and bus stats BEFORE blindly bricking one of the units. This is sort of a non-issue for others as most do not have on-network firmware updating features (if they have firmware updates at all).

I don't have a dog in the race on instance IDs. I have experienced problems with heading and GPS units that went away with IDs configured as per Maretron's recommendations. That and I had no new problems introduced with anything else as a result of doing it. My device selections are somewhat varied, but not a complete mix of "everything". So I don't have specific experience on whether a Garmin plotter will/won't benefit from this. And my Raymarine gear was several generations old, and likely not applicable to more recent offerings. So please don't get the impression I'm laying claim to be an expert about everything here. More like 'battle tested' than 'lab trained'.

I'm absolutely not looking to argue a pro/con on the instance ID scenario.

I'd definitely welcome some examples of how Maretron's perspective did not work. If just to avoid getting caught in the same scenario.

And I completely agree that NMEA's handling of this has been far too vague. I don't hold out a lot of hope for their next offering to be any 'less worse' either.

 

[wkearney99]

When selecting a data source, all the other equipment I have used shows a list of available devices reflecting these "NAME"s, so you can see the Vesper, Airmar, and MFD as data sources. Some devices show the unique serial number, and some show the instance number. But the source selection is never based solely on the Instance number.

I'd question the statement of "never based solely". Because I'm not entirely certain what data is present in the PGNs sent on the wire. I don't remember the names and serial numbers being part of the data sentences. Sure, querying for that during setup certainly makes it easier for users. And most displays have a 'scan' mode to find things. But in the data itself during regular operation? It would seem like a gigantic waste of packet space to stuff that into every sentence. Using the IDs would be far more concise. Thus multiple devices sending the same PGNs would be difficult for a receiving device to determine which-is-which without the "ID" being stable and unique.

Again, not trying to argue who knows better, just sharing what I've learned and how that's shaped how I view the situation. I'm all ears for learning more about it.

 

[Helmsman]

Was the workshop a NMEA course? I'd be real interested in how they positioned all this, and whether it agrees or disagrees with my post.

I took four one day courses in Orlando last September. Two basic, two advanced. There was a “mix” regarding it. The straight up training (book) taught to use instancing to eliminate conflicts. In discussion, with real world conflict problems presented, the focus was correction with instancing possibly being the problem.

 

[wkearney99]

Bill,

when you set up instancing for the GPS signal, and let’s say, have the SatCom as your first incidence, and perhaps an AIS GPS as the second, then is there anything you need to do if you have restricted the AIS GPS from sending its signal to the network, if the SatCom fails? Or will it automatically begin broadcasting the AIS GPS on formation to the network despite the restriction?

Let me clarify, there's nothing I've seen in any of the specs that sets up something as first, second or ordered in a use pattern. At least it's never come across that way to me.

And after many decades of dealing with tech products and networking I've learned never to make assumptions about ordering and/or dynamically configured setups.

It's my impression that unless you specifically disable outputs of PGNs then a device will always continue to put them onto the network. The data is there from anything that can send them, and can be consumed by anything that's listening.

This it gets tricky when you have a device that's consuming data intermittently from the "wrong" source, or one that's "different" than the others... leading to confusion.

I had an intermittent heading sensor (which I think was an old Airmar unit). It was slower to update than a "less older" Furuno unit. My chartplotters and autopilot weren't configured to stick with one source (and both sources were configured 'the same'). Thus my heading would go wonky from time to time. When this happened during active autopilot the rudder would end getting hard changes as the autopilot tried to resolve what it suddenly thought was a radical heading change. When in reality it was the bad heading sensor confusing it AND the autopilot not being told to use the other one. And near the end I also had what I think was an intermittent rudder sender. To debug all this I had to learn a WHOLE lot more about what was in the boat and untangle how it had previously been configured by persons prior to me.

So, all this... how much applies to your situation and how much do you have to learn? Probably not all of what has been discussed here.

It's my feeling that when multi-station setups come into play, it's helpful to get a full picture of what's on the network(s) and get yourself a 'known good' starting point.

For a single station setup very few of these 'finer points' probably matter.

 

[Helmsman]

The way I was taught uses this hierarchy of logic

Instancing is used when you have dual pieces of equipment, such as two fuel tanks, two transducers, two or more gps, etc.

Some devices may use the instance number to determine priority.
Some displays/devices may use the instance number and label to help identify the device to the user (this may or may not be user selectable)
It is important to understand how manufacturers handle and treat instance configurations.

A PGN should define all data transmitted from a device.
All devices must support a minimum group of messages.

Certified products use a device's Source Address and Instance Number to identify devices transmitting the same data messages on the network.

Certified Products are required to have an Instance Number and the ability to change it in the field.

It is important to understand how Manufacturers implement instancing in the field.

So, it is somehwhat dependent on the manufacturers and how they handle instancing as long as they follow the rule that "it is mandatory that every NMEA 2000 device has the capability to have the instance number changed." An understanding of a particular manufacturers rules is important to understand how they handle instancing. Furuno, which is what I am installing on a new build, has the ability to decide which instance to assign.

 

[twistedtree]

I'd definitely welcome some examples of how Maretron's perspective did not work. If just to avoid getting caught in the same scenario.

The problem with Maretron’s approach is that there are devices where you cannot change the Device Instance, and then Maretron can’t distinguish PGNs from the two devices. ICOM VHFs and Furuno autopilots come to mind.

The issue also extends to Data Instances which are a bit different. For some PGNs, a Data Instance in part of the PGN and intended to make the PGN’s self-identifying when a device can send The same PGN for different things. Battery status is a good example. A single device with a single Device instance can monitor multiple batteries, making it necessary to identify which battery is being reported in each PGN sent by the device. Data instanced are used to tell you that it’s battery 1, or 2 or whatever. The spec is clear that data instances must be unique for the PGNs coming from a particular device, but it is equally clear that they are only required to be unique within the scope of that device. If you have two battery monitor devices, each capable of monitoring two batteries, the first device would send PGNs with data instances 1 and 2, and the second device would also send PGNs with data instances 1 and 2. And listening device is expected to select the data it wants based on the device that’s sending it, and the data instance for the battery reported by that device.

Maretron doesn’t do it that, and instead requires that all the data instances be globally unique across the network, not just unique across a single device. Lots of devices that follow the spec do not provide for changing the data instances because there is no need to. But that renders those devices incompatible with Maretron because they can’t tell the PGNs apart from one another.

I have 8 Victron devices, each of which reports battery status for one or two batteries. But Maretron can’t tell any of them apart because the data instances are all either 1 or 2 rather than being 1-16. Victron has been good enough to show ways to hack the system to change the device instances, but when you do it breakers their management which expects things to be according to the standard.

It’s quite the cluster.

 

[twistedtree]

I'd question the statement of "never based solely". Because I'm not entirely certain what data is present in the PGNs sent on the wire. I don't remember the names and serial numbers being part of the data sentences. Sure, querying for that during setup certainly makes it easier for users. And most displays have a 'scan' mode to find things. But in the data itself during regular operation? It would seem like a gigantic waste of packet space to stuff that into every sentence. Using the IDs would be far more concise. Thus multiple devices sending the same PGNs would be difficult for a receiving device to determine which-is-which without the "ID" being stable and unique.



Again, not trying to argue who knows better, just sharing what I've learned and how that's shaped how I view the situation. I'm all ears for learning more about it.

Good observation. It depends on whether you are talking about a Device Instance, or a Data Instance. Some PGNs, but not all, carry a Data Instance. See my previous post for more info.

The Device instance along with the rest of the NAME is only exchanged at address claim time. So a device needs to maintain an inventory of what’s on the bus and who’s using which source address. When a PGN like gps data is received, all the receiver knows is what source address is came from. It then needs to look up who that is, and decide what to do with the PGN. If there is a new address claim process, everyone needs to update their inventory and mapping for who’s using which address because addresses are assigned dynamically and can and will change.

 

[wkearney99]

The problem with Maretron’s approach is that there are devices where you cannot change the Device Instance, and then Maretron can’t distinguish PGNs from the two devices. ICOM VHFs and Furuno autopilots come to mind.

Was it you with the Icom problems? Where it was repeating erroneous GPS data?

The issue also extends to Data Instances which are a bit different. For some PGNs, a Data Instance in part of the PGN and intended to make the PGN’s self-identifying when a device can send The same PGN for different things. Battery status is a good example. A single device with a single Device instance can monitor multiple batteries, making it necessary to identify which battery is being reported in each PGN sent by the device. Data instanced are used to tell you that it’s battery 1, or 2 or whatever. The spec is clear that data instances must be unique for the PGNs coming from a particular device, but it is equally clear that they are only required to be unique within the scope of that device. If you have two battery monitor devices, each capable of monitoring two batteries, the first device would send PGNs with data instances 1 and 2, and the second device would also send PGNs with data instances 1 and 2. And listening device is expected to select the data it wants based on the device that’s sending it, and the data instance for the battery reported by that device.

Maretron doesn’t do it that, and instead requires that all the data instances be globally unique across the network, not just unique across a single device. Lots of devices that follow the spec do not provide for changing the data instances because there is no need to. But that renders those devices incompatible with Maretron because they can’t tell the PGNs apart from one another.

I have 8 Victron devices, each of which reports battery status for one or two batteries. But Maretron can’t tell any of them apart because the data instances are all either 1 or 2 rather than being 1-16. Victron has been good enough to show ways to hack the system to change the device instances, but when you do it breakers their management which expects things to be according to the standard.

It’s quite the cluster.

Excellent point regarding battery reporting. Is the Maretron unit you've having issue with the DSM410 4" display? Or something else?

I'm interested in getting more battery data from my Mastervolt organized setup, but that deserves a conversation thread of it's own. I'm leaning toward an Airmar Smartboat gateway and have a thread about here over here: https://www.trawlerforum.com/forums/s4/airmar-smartboard-anyone-using-them-yet-63879.html

 

[twistedtree]

Was it you with the Icom problems? Where it was repeating erroneous GPS data?







Excellent point regarding battery reporting. Is the Maretron unit you've having issue with the DSM410 4" display? Or something else?



I'm interested in getting more battery data from my Mastervolt organized setup, but that deserves a conversation thread of it's own. I'm leaning toward an Airmar Smartboat gateway and have a thread about here over here: https://www.trawlerforum.com/forums/s4/airmar-smartboard-anyone-using-them-yet-63879.html

Yes, I had loads of trouble with the icom M506 and ended up not using the N2K interface.

I’m using N2KView, but I believe all their display products work the same way.

I haven’t tried Mastervolt with N2K.

 

[Helmsman]

Yes, I had loads of trouble with the icom M506 and ended up not using the N2K interface.

I’m using N2KView, but I believe all their display products work the same way.

I haven’t tried Mastervolt with N2K.

How about Actisense?

 

[twistedtree]

How about Actisense?

I have generally had good luck with them, but their product line is pretty limited. The N2K to USB interface is widely supported for PC access to N2K, but it still depends on the particular application.