PGN 127506 Amp hours and N2KView

The friendliest place on the web for anyone who enjoys boating.
If you have answers, please help by responding to the unanswered posts.

Wdeertz

Senior Member
Joined
Jul 3, 2018
Messages
361
Location
USA
Vessel Name
Bagus
Vessel Make
Kadey Krogen 52-01
I have a Victron battery monitor putting out PGN 127506 which includes amp hours. I’m trying to get remaining amp hours to consistently show up in Maretron N2KView. Generally the remaining amp hours show up after fully charged and for the first portion of the discharge but will stop showing up shortly thereafter. Recently I’m not even getting amp hours after fully charging so not sure what is going on.

Anyone using N2KView able to get remaining amp hours to show up consistently?
 
There is probably another device that is also sending that PGN, and N2KView can't tell them apart. Maretron has their own unique way of distinguishing PGNs from different sources which is incompatible with a lot of other devices that do it the way the standard says to do it.

The longer answer is that N2K requires that if a device sends the same PGN for two different things, like two different batteries in your case, those PGNs need to have unique Data Instance numbers so you can tell them apart. They would typically be Data Instances 0, 1, 2 and so on.

If there is another such device on the network, it's PGNs can (typically do) have the same Data Instances of 0, 1, 2.., but since they are coming from a different device, a listener who is following the standard can tell them apart.

So the rule is that Data instances have to be unique WITHIN a given device, but they do NOT have to be unique between different devices.

But Maretron doesn't work that way. They require that all the PGNs across all the devices on the network have unique Data Instances. So they expect all Data Instances to be unique across the whole network. For example, the first device would need to have Data Instances 0 and 1, teh second device would have 2 and 3, and so on for other devices sending the same PGN. So they can't tell apart the data from different devices unless you go in and change the default Data Instance. There is no standardized way to do that, and only Maretron requires it so other vendors just don't do it and don't care, and shouldn't because they are doing what they are supposed to do. Because of this, N2KView is incompatible with probably 90% of the non-maretron devices on my N2K network. It's very frustrating, especially since NMEA certifies all these devices as being compliant and compatible. I have been after Maretron for well over 10 years to change this, but it's clearly not going to happen. And I have been after NMEA to tighten up the standard for well over 5 years, but they just don't care.
 
BTW, there are a couple of things you can try to perhaps get things working as you desire. But if you late change anything in your network, it might break again. Thank you N2K and Maretron :-(

The first is to figure out what other devices are sending PGN 127506. You can use N2KAnalyze to do this, though it will be a bit tedious. Using it, you can look at the PGNs being sent by various devices. Check any chargers, battery monitors, solar chargers, or any other things that might be sending that PGN. When you look at each of the 127506 PGNs, you will see the data instance in the PGN data. To make it work, you need to somehow make the PGN you care about have a data instance that is different from all the others. Then you need to configure the N2KView gauge(s) to use that data instance. Make certain N2KView isn't set to use "Any" instance.

If you need to change data instances, you will have to dig into each devices documentation to see if there is a way to do it. Oh, and call Maretron and yell at them for their proprietary approach to data source selection that is incompatible with so many products. They will tell you that the spec requires that the data and device instances be changeable, and that everyone else in non-compliant. But it doesn't say how you change those instances, so as long as there is some way to change them, even if it's inaccessible to an end user, a device is technically compliant. Also keep in mind that messing with the data instances in a device may mess up other software. Victron cautions about this with respect to their VRM offering.

Good luck!
 
TT, thanks for the inputs. I’ve used N2KAnalyze and confirmed there are only 2 devices outputting PGN 127506.

The first is a Victron BMV702 battery monitor set as device instance 1. For this device it shows PGN 127506 as DC instance 0 (with amp hours, amps, etc for the house bank which is battery instance 0), PGN 127508 with battery instance 0 and PGN 127508 with battery instance 1 (start battery).

There is another device labeled “System battery” which I’m not 100% sure where it’s coming from but maybe the Cerbo Gx (there is also a separate device for the Cerbo). This device is instance 239 and outputs both PGN 127506 and 127508 with instance number 239.

I’ve tried both device 0 and 239 in N2Kview with no luck. Any other suggestions?
 
Just to confirm and for clarity, there are two difference instance numbers. A Device Instance, which pertain to a device, and is found in the contents of the device info PGN. I don't recall the PGN number. Then there is the Data Instance which is contained in certain PGNs. Maretron is a source of confusion over this because they just refer generically to an "Instance Number" without being specific about whether they are talking about a Device Instance or a Data Instance.

You want to check the Data Instance which is the field contained inside PGN 127506. I think you are saying that two different devices send 127506; the BMV702 with Data Instance 0, and the "System Battery" device with Data Instance 239. I want to confirm that these are indeed the Data Instances, not the Device Instances.

Looking more closely at 127506, it reports state of charge as a %. But you say you are trying to display AH-remaining and that's not in 127506. That's what I call a compound data field, i.e. it takes more than one piece of data to calculate/display it. I think it requires 127513 which provides the Ah capacity of the battery, plus 127506 which provides the %SOC. From that you can calculate Ah remaining. I don't see any PGN that reports that directly.

I'd suggest first trying to display % SOC and see if that is stable. If your two devices sending 127506 have unique Data Instances, which is sounds like they do, then set the N2KView gauge to use Instance 0 to match the BMV. That should work.

Next try to see if/who is sending 127513, and that the Data Instances are.
 
TT, thanks, I’m about to give up. All other battery parameters show up fine (SOC, voltage, amps, temp, etc). BMV702 device/data instance 1, system battery device/data instance 3 (changed from 239). PGN’s only showing DC instance and battery instance, no device instance (attached photos). I was unable to find any device sending PGN 127513. I do know that at one point N2Kview would show 600Ahr (which is bank capacity) immediately after a full charge and then count down from there as power was used but would eventually drop out at about 525. At this point I’ve simply removed this field from my DC screen, I have SOC so can compute Ahr in my head.

Have a new Mconnect on order for the past 2 weeks but seems none available to ship. Hopefully over time Maretron can improve this new html device to fully replace the kludgy N2kview.
 

Attachments

  • IMG_0238.jpeg
    IMG_0238.jpeg
    219.6 KB · Views: 7
  • IMG_0239.jpeg
    IMG_0239.jpeg
    210 KB · Views: 7
  • IMG_0240.jpeg
    IMG_0240.jpeg
    234.7 KB · Views: 7
It's starting to dawn on me that the Maretron move (N2kview, IPG100 and even the mPower) may have been a bad one in our case. "Dawn" through my brain takes some time ;).

Peter, wondering what your post N2K-via-Maretron solution space is?
I'm feeling it's either sideways to n2k + SignalK, which mucks up my digital switching on mPower as it's so Maretron specific, or moving fully away and to DIY to esp32, Node(Red) and HA, probably keeping SignalK.

Maybe something like Kincomy for the switching, although limited to 7amp per relay and relays don't give the full mPower switching solution (still need to run separate power to the device through the relay).
 
Last edited:
It's starting to dawn on me that the Maretron move (N2kview, IPG100 and even the mPower) may have been a bad one in our case. "Dawn" through my brain takes some time ;).

Peter, wondering what your post N2K-via-Maretron solution space is?
I'm feeling it's either sideways to n2k + SignalK, which mucks up my digital switching on mPower as it's so Maretron specific, or moving fully away and to DIY to esp32, Node(Red) and HA, probably keeping SignalK.

Maybe something like Kincomy for the switching, although limited to 7amp per relay and relays don't give the full mPower switching solution (still need to run separate power to the device through the relay).
And there is the problem. There just isn't an equivalent replacement, and more so if you are using the digital switching stuff. What I would give for an alternative to N2KView.... Their network modules are fine, even if quite dated. With one or two exceptions, none of them have changed since I started using the stuff in 2010.

I think the biggest issues with the alternatives is that you need to be a programmer to implement any of them. You rattled off a bunch of modules that various people have done nice things with. I haven't tried any of them simply because my programming/building skills are so stale and I know it will be a big investment in time to get ramped back up again. I have dabbled since then, but the last bit of production code I wrote was in 1996. A few things have changed since then...

What I did take on, not for monitoring but for control, is PLC programming. Along with that is HMI (display screen) programming because controlling stuff usually involves monitoring too. I first used it for sensing and controlling all of the main AC power switching. It detects shore power on multiple inlet cords and connects them to various load panels based on some rules. It also controls boosting in my isolation transformers. Plus it's tied to the battery system and when the batteries get low it starts a generator and switches loads over to it. The result is a boat that is super easy to use. When I dock, I just plug in the nearest shore cord and switch on the pedistal breaker and everything else takes care of itself. Same when I depart - I just turn off the pedistal breaker and put the cord away. And away from the dock all I have to do it start a generator from my control panel and all the loads connect automatically. It even adjusts the Victron input load limits based on what's powered and what the power source capacity is. It's been really good, and a PLC is a great solution for it because they are so bullet proof. I would never under any circumstances do stuff like this with Maretron. But getting back to monitoring, the result is that I do all my AC power monitoring via the PLC, not via Maretron.

At this point I consider my N2K bus as a proprietary Maretron monitoring bus. I have a bunch of stuff working on it, but I know it's all fragile. And 90% of my Victron stuff can not be displayed because of this stupid Data Instance issue.

Sorry I don't have an alternative, and please let us all know if you find one....
 
Yes, the Maretron UX is around 20 years out of date, and the proprietary nature of their use of N2K makes it even worse. I assume the other proprietary digital switching + information/control hubs are the same (from my research).
I haven't done any serious programming for 20 years and really don't want to dive into C++: I grok C, but not that abomination :LOL:. I've tried with some ESP32 on Halmet and my eyes are still glazed over. Python, Java or typescript would be fine, but I'm still not seeing the actual capability yet in the hardware because the use case for not-low-amp, high quality DC 12V control and switching isn't in the home automation space. There's some coming out of the RV and caravan space, but again I'm not seeing anything resembling the Maretron mPower, let alone the theoretical cohesion of N2k. On the other hand, the focus on protocols like Matter and coming products there means that space has raced away from a wired N2k (canbus) in the wireless realm. Even in our aluminium cat wireless works fine in the distances we're talking about.

No alternative I'm sorry (I was hoping you had one :cool:). But I'll keep looking...
 
Back
Top Bottom