canboat
Issue 514 not completed
You already closed issue 514. I have no permission to reopen.
You only fixed the one PGN that I mentioned as an example. But there are more PGNs where OFF_ON must be replaced with OFF_ON_CONTROL:
PGN 127510 "Charger Enable/Disable" is a command, not a status. PGN 127510 "Equalize One Time Enable/Disable" is a command, not a status. PGN 127510 "Over Charge Enable/Disable" is a command, not a status.
PGN 127511 "Inverter Enable/Disable" is a command, not a status. PGN 127511 "Load Sense Enable/Disable" is a command, not a status.
The last two are not even LOOKUP, but NUMBER.
And as these are commands they should be named "Turn On" or "Enable" instead of only "On".
In general, @Elmue, please consider a more constructive attitude towards open source projects. Your issues here usually sound like accusations instead of contributions. There's a consistent theme throughout issues you filed against many projects on GitHub. It's often along the lines of "Look, you're doing it wrong! Your code is bad!". Which might be true in some cases, but it's still not an attitude that will make others welcome you in their projects.
I'm not trying to insult you. Just getting all these notifications for the canboat project which I'm watching on GitHub, and the accusatory tone from your side really sticks out. Please try to be more positive and turn your findings into helpful actions.
I'm not trying to insult you. Just getting all these notifications for the canboat project which I'm watching on GitHub, and the accusatory tone from your side really sticks out. Please try to be more positive and turn your findings into helpful actions.
I have exactly the same experience & feelings as André.
The fields reported are normal fields as far as I can determine. What gives you the idea that they are meant only for setting properties?
I did not have the intention to accuse someone. I wrote more than once that Kees is doing a great work with this project.
The issues section on Github is to report things that are not correct. If this is taken as a criticism, I cannot help. For me critics are never bad. They are to correct errors. So they are always positive because they are thought to improve this project. This is at least my intention.
What gives you the idea that they are meant only for setting properties?
The official NMEA documentation says that all the above parameters are set commands and not status.
Kees wrote:
I already made the argument that this 1.3 or whatever version of the documentation is NOT permissible and I do not want to read it and it is OUTDATED.
I already explained this before: This document has been leaked 4 years ago and so it is public now. It is the same as with all other leaked documents for example on Wikileaks. Once leaked they are public.
Do you fear that the NMEA will demand you because you use document that is public for 4 years now ? They would first have to demand the Chinese guy who uploaded it.
What concerns outdated: The description of these messages may perhaps be incomplete if new parameters have been added in the last years.
But the NMEA cannot (CAN NOT) modify existing messages. If they did they would break the communication with all existing controllers that already send these messages.
Imagine you work in a company that produces NMEA products, like Maretron for example. You build your devices following the rules of the NMEA and tomorrow they change the meaning of the parameters and all your products that are already in the warehouses and shops become useless ? They cannot be sold anymore because the NMEA had the worst idea to change everything over night ?
This is TOTALLY impossible. I explained before that the NMEA cannot change existing messages once they are published. Therefore it is irrelevant if this document is from 2009 or from 2019 or from 2025.
The only difference will be that in newer NMEA versions they may have added new parameters to existing messages. So the message becomes longer. But they cannot change existing messages.
I am working a lot with J1939 where I have compared older documents from 2003 with newer documents from 2022. And it is exactly as I say: They never CHANGE existing messages or parameters. Not one single message of more than 8000 messages that I compared in an automated way has been modified. All they do is to ADD new parameters to the end or add new lookup values to the existing ones. And obviously they ADD new messages.
So we can trust this leaked document although it is from 2009.
You see that PGN 127510 was used to configure a charger.
As you see this PGN can be used to limit the output current of the charger and configure other settings.
Kees, do you really think that in between 2009 and 2025 the NMEA has completely reverted the meaning of these parameters ? In 2009 they were used to configure a charger. And in 2025 they are suddenly used to obtain the status of a charger ? The opposite ?
If things would work like you say, no company would ever produce CAN bus controllers based on NMEA documents if the standard changes from one day to the next day to the exact opposite.
And how do you think we should interpret value 3 for such a command pair when the message is transmitted?
Go and take a good look at the Complex Command PGN 126208 works. You do not need to transmit fields that you are not changing. So having this value "no action" is strange and, in my opinion, incorrect.
I have no proof, but I bet you that in newer NMEA 2000 standards the meaning has been clarified to be "unknown" when the status is transmitted.
BTW my patience with you has now run out. Telling me what to do and being generally belligerent and condescending is not how this works.
You have now been warned three times by various persons in this repository alone.
Next time you transgress my personal boundaries I will block your account. I do not feel elated about that, but I do not need the aggravation that you are causing me.
And how do you think we should interpret value 3 for such a command pair when the message is transmitted?
The usage of "Take no action" is very simple. It follows the rules of all the J1939 messages that are explained in the J1939 documents.
Let's say someone on CAN bus wants to turn On the charger, but does not want to modify the parameters "Equalize One Time" and "Over Charge Enable".
They will send PGN 127510 with: -- Parameter 3 "Charger Enable / Disable" set to "Turn On" -- Parameter 9 "Equalize One Time Enable/ Disable" set to "Take no action" -- Parameter 10 "Over Charge Enable/ Disable" set to "Take no action"
The option "Take no action" is required to leave a parameter unchanged while changing other parameters in the same message. It is all explained in the J1939 documents. And NMEA is based on the J1939 protocol. NMEA only added a few messages to the already existing 10 thousand J1939 messages.
Go and take a good look at the Complex Command PGN 126208 works.
I did not only take a look at it. I already implemented it in code and tested it with your logfiles.
If they send the same command with PGN 126208 they can simply send Parameter 3 "Charger Enable / Disable" set to "Turn On" and leave the other parameters 9 and 10 away as they do not want to change them.
However depending on the programmers of the CAN bus controllers they could also send "Take no action" for parameters 9 and 10 while using PGN 126208. They would just waste some useless bytes on CAN bus. This would not be an error, just sending useless data that has no effect.
I see so many useless data being transmitted by NMEA wasting bytes on CAN bus that I would not be surprised to see that. For example PGN 126996 sends 4 fix length strings of 32 characters creating a packet of 134 bytes just to transmit a few version numbers. NMEA is so inefficient is flooding CAN bus with empty bytes. Most of the 134 bytes will always stay empty. Why don't they use StringLAU here ? Seeing all this inefficiency I would not be surprised to see a PGN 126208 setting parameters to "Take no action"
I bet you that in newer NMEA 2000 standards the meaning has been clarified to be "unknown" when the status is transmitted.
Never. As I explained: It is not a status. It is a command. If you read the J1939 documents there is all explained. I already posted a screenshot of the J1939 document of the 2 bit switches in another issue here. I post it here again:
This is a screenshot from the official document SAE J1939-71 from the year 2022. Nothing has changed since my oldest document from 2003.
There are two versions of the 2 bit switches: -- For Status : On, Off, Error, Not Available -- For Command: Turn On, Turn Off, Reserved, Take no action This is J1939 standard for hundreds if not thousands of messages. PGN 127510 follows the rules.
Therefore your XML file must distinguish between 2 bit status and 2 bit command.
I bet you that in newer NMEA 2000 standards the meaning has been clarified to be "unknown" when the status is transmitted.
They will never do that. Your bet is lost. For example parameter 3 in PGN 127510 is used to Turn On / Off the charger. The value "Take no action" is required to leave a parameter unchanged if you only want to change other parameters. So they cannot change this tomorrow to "Unknown" -- first, because it is a command and not a status -- and second because they would break the communication with all the controllers that use PGN 127510 today.
It is completely impossible that they change this. This is standard in hundreds if not thousands of J1939 messages.
BTW my patience with you has now run out.
If you feel offended by me I apologize. It was never my intention.
All I want is to improve your work. There are several errors and I help to fix them,
For example in your definition of PGN 127511: There is field 5 "Reserved" that should not be there. Field 6 has the name "Inverter Mode" but the mode displayed as NUMBER (0, 1, 2, 3, 4). This mode is defined by NMEA as "Standalone", "Series master", "Series Slave" etc. The lookup is missing. In parameter 8 "Load Sense Power Threshold" the unit "Watt" is missing and it is 16 bit, not 8 bit. In parameter 9 "Load Sense Interval" the unit "Seconds" is missing and it is 16 bit, not 8 bit. If I use these definitions the message will be decoded wrong and my users will see wrong data.
If you feel offended when I name the errors in your XML file then I don't know what to do. My purpose is to fix all errors in the XML file as far as possible.
I write high quality software and I don't want my users to see wrong data.
If you feel offended by helping you fixing the errors, then tell me so and I will stop providing my help to this project. It costs me time to write here and I do this to help. If you don't want my help, then I can spare this time.
I can fix your XML file on my own and use my own corrected version. That is no problem. It is much faster for me to fix the errors on my own than posting a long explanation here.
The sad thing is only that all this bug fixing work will not be available to all the people who use your files. Everybody has to do this work again and again because it is not fixed in the original version here on Github.
So decide if you want me to help improve your data or not.
In 2009 they were used to configure a charger. And in 2025 they are suddenly used to obtain the status of a charger ?
No, it was apparently always used to obtain the status of a charger, from your screenshot:
Any device capable of charging a battery may transmit this message
It's even in the PGN description: Charger Configuration Status
So my assumption is that they accidentally used "Command Pair" instead of just lookup yes/no. The difference isn't very big: the only thing is that 0x03 / 0b11 has a slightly different meaning of "No Change" instead of "Data not available".
But with your choice of lookup value, how is a charger supposed to say "Data not available" (not that this is very likely, admittedly.)
Nowhere does it say "This message may be sent to a charger". In fact, it explicitly says that the values may be set using "Complex Command" PGN 126208.
An additional reason I doubt the correctness of the PGN description that you found is the remark that the PGN is less than 8 bytes. But it isn't...
As to NMEA 2000 being just a slight variation on J1939, hmmmm they did add the "Fast" mode of sending data > 8 bytes because TP is too slow for the many large messages needed. Also, most devices do not transmit or understand any J1939 messages at all except the address claim procedure.
PS a small hint: to be taken seriously in NMEA2000 is to talk about devices, not controllers -- which I guess is J1939 nomenclature.
As to the definition of 127510 and 127511 - in 15 years no-one has ever reported any logfiles containing them to me. I have also not seen it on the networks I have access to. So the first knowledge I have of these is you putting up this screenshot of the old NMEA database. Now that you have done so I will fix my definitions as you have now provided this information.
I will verify the information you uploaded here by generating fake versions of 127510 and 127511 and verify that Antisense EBL reader decodes them this way as well.
In fact, we could do that for other not-seen PGNs.
Have you noticed the flags that are in there that describe whether the PGN has been seen in real life / logfile, and whether we think we understand all field lengths, datatypes etc?
Any device capable of charging a battery may transmit this message The complex Request/Command/Acknowledge can be used to set the following parameters
I admit that these two seem to contradict each other. But what if this is not a contradiction ? What if this message can be used to broadcast the current status of a charger and may also be used to configure a charger through PGN 126208?
So using PGN 126208 it sets the parameters and not using PGN 126208 it contains the current status? We would have to read the NMEA documents which don't have.
how is a charger supposed to say "Data not available"
Perhaps if a feature is not implemented in the charger. For example if the feature in parameter 9 "Overcharge the battery in an attempt to bring the cells to the same level of charge" is not implemented in this type of charger? If the charger only charges until the battery is full it cannot provide this functionality and would send Status = "Not available"
While less than 8 bytes....
The message has exactly 64 bit. I have no idea what they want to say with this. This is strange.
As to NMEA 2000 being just a slight variation on J1939, hmmmm they did add the "Fast" mode of sending data
Correct. NMEA added their own stuff to an existing standard. They do not use SPN's but they use PGN's which coexist with the PGNs from J1939. They invented their own string type LAU which does not exist in J1939. J1939 has multiple types of strings, but no one supports Unicode characters. Perhaps NMEA thought that Unicode is required and invented a string for that. They could have simply used UTF8 but I suppose that they chose 16 bit Unicode because a message that consists of 100% Unicode occupies less bytes than encoded with UTF8. They added 32 bit floating point numbers. As they can perfectly transmit longitude and latitude with extreme precision using only 32 bit integer, I dont know who needs floting point numbers. And they invented their own way to send date and time.
But that's it. All the rest is common. So they mainly added new stuff, but the underlying J1939 infrastructure is the same.
Also, most devices do not transmit or understand any J1939 messages at all except the address claim procedure.
May be you did not see them yet. But I have seen that. In one of my first postings I sent you a logfile of 3 MB in Linux CAN dump format. In this file there is an E.Controls engine controller which sends both: J1939 and NMEA:
I collapsed most messages to make the screenshot smaller. As you see nearly all messages are J1939, but two messages are NMEA. They come all from the same engine controller. This is a bilingual controller.
And here you see another example:
This is a Maretron Load Controller that sends pure J1939 messages. Whenever you see numbers in the column "SPN" they are J1939 messages. By the way: this from your Dirona logfile.
TP is too slow for the many large messages needed.
It is not slower. It has advantages and disadvantages. It needs one packet more, the Management packet, that is true. But it allows to send 1785 bytes in one message while Fastpacket allows only 223 bytes. TP allows much more control than Fastpacket. A receiver of a message can abort the transfer. Also acknowledgment is implemented. A receiver can even deny to receive a message while it is busy which is very intelligent and frees CAN bus from useless traffic. The biggest advantage is that TP allows to send a long message directly to one device and not only broadcast and this independent of the PGN. Transport protocol is far more versatile than Fastpacket. Fastpacket is very primitive compared to it. Is suppose that this is the reason. NMEA wanted something that is simpler and therefore easier to implement in firmware. The most stupid design of NMEA was to define some PGNs as Fastpacket and others as Single and this is fix for all the future. There is no flexibility so they cannot say tomorrow: We want to add more parameters to a packet that today is defined as Single packet. It will always be limited to 8 bytes. In many aspects J1939 has been designed more intelligently than NMEA.
to be taken seriously in NMEA2000 is to talk about devices, not controllers
This has nothing to do with J1939 nor with NMEA. Do you know what CAN stands for ? Controller Area Network. Invented by Robert Bosch Gmbh in 1983 before even J1939 was invented. All devices that are connected to a CAN bus are called CAN bus controllers. That is standard nomenclature. CAN bus is not only used in vehicles, but also in stationary industry (robotics). It will be difficult to find a name that matches the wide range of hardware that can connect to a CAN bus.
As to the definition of 127510 and 127511 - in 15 years no-one has ever reported any logfiles containing them to me.
Well that is general problem of your reverse engineering project. If you dont want to read the official documents you will have thousands of messages that exist but you have never seen them. I implemented more than 8000 parameters of J1939. What I see in logfiles is a tiny part of them. And when people send you logfiles they come probably from their yacht where they have only a few devices connected to CAN bus. But in a bigger ship you will see much more messages.
Have you noticed the flags that are in there that describe whether the PGN has been seen in real life / logfile
Yes I have. But even if you have seen a message it does not mean that all the definitions in XML are correct. There will always be a doubt. By the way: If you have never seen a message, how does it get into file ?
In fact, we could do that for other not-seen PGNs. and verify that Antisense EBL reader decodes them this way as well.
This would mean to reverse engineer this software instead of the messages itself.
I have plans to verify your XML data with the available documentation in the NMEA document. Are you interested in the results or will you reject it because the document is from 2009 ?