canboat
Some minor topics
Reviewing the XML file I found some things:
A new string type is required: String_LAU2 It is used in DD198 in the PGNs 130070, 130071 and 130072 It allows up to 891 Unicode characters. It uses two length bytes.
Why has anchor depth the unit "m/s" ?
<EnumFieldType Value="1800" Name="Anchor depth" FieldType="NUMBER" Signed="false" Resolution="0.01" Unit="m/s" Bits="16" />
There is a copy / paste error in enum SERIAL_BIT_RATE:
<EnumPair Value="10" Name="19200" />
<EnumPair Value="11" Name="19200" />
And the unit "baud" is missing.
The enum WP_POSITION_RESOLUTION should be:
0 "> 0.1 min"
1 "0.01 ... 0.1 min"
2 "0.001 ... 0.01 min"
3 "0.0001 ... 0.001 min"
4 "0.000001 ... 0.0001 min"
As far as I understand it is usual to display vessel speed in knots. It is easy to convert "m/s" into "knots". But it is currently not possible to know for which parameters this unit makes sense.
It makes sense for "Speed over Ground", "Current Speed", "Speed through Water", "Longitudinal Speed", "Transverse Speed", "Stern Speed"
As far as I understand also "Wind Speed" is measured in knots. What about "Wind Gusts" and "True wind shift" ?
Is "Drift" also measured in knots ? And what about "Next Leg AWS", "Polar Speed" and "VMG to Wind" ?
They all have the same unit "m/s".
I'am confused by all these speeds. And I'am currently not able to find out which parameters may be displayed in knots.
Surely it makes no sense to display "Windlass Line Speed" in knots. And also the GPS parameters which use speeds like "RRC" in "DGNSS Corrections" are surely not displayed in knots.
So one option would be to introduce a new FieldType "KNOTS_SPEED" But the better option would be to already insert the unit "knots" and the Resolution multiplied with 0.51444 so the results are displayed alone by the XML file data without having to write any additional code.
Vessel that operate on rivers/lakes/canals (inland bodies of water) tend to use (are regulated by) SI units at least here in EU. So km/h (vessel speed) and m/s (wind speed) over knots etc. m/s for wind speed is sometimes used for seagoing vessels also (probably due to the weather reports using m/s) but other things are still in nautical miles and knots - captain preferences.
BTW you are asking a lot of downstream application features to be added to this project. meaning all other now need to have to update their projects enums, even if for them distinction in which context knots are used makes no difference.
As far as I understand it is usual to display vessel speed in knots.
As I've said before, you are clearly not a sailor.
Some sailors may use imperial units (knots, feet, nautical miles, fahrenheit, pound per square inch), others may use metric units (metres per second, kilometres per hour, kilometres, metres, centigrade, pascal), others more archaic measures (chains, fathoms, beaufort) and many a combination of both.
That is why marine electronic equipment such as multi function displays, instrument displays and software applications allow users to configure their preferred units. I suggest you step onboard a boat before making such absurd comments.
NMEA 2000 uses SI units; Other than making your life easier, your suggested change is of little use to other applications and more importantly will break them.
Re PGN 130070, 130071 & 130072, Do you have any sample data? Or are you basing your comments from perusing an old version of the standard of dubious providence?
The following code snippet
// Repeated Fields
unsigned short routeId = 2;
payload->push_back(routeId);
payload->push_back((routeId >> 8) & 0xFF);
std::string waypointName = "Here to There-Comment";
payload->push_back(waypointName.size() + 2);
payload->push_back(0x01); // 1 indicates ASCII encoding
for (size_t i = 0; i < waypointName.size(); i++) {
payload->push_back(waypointName.at(i));
}
routeId = 5;
payload->push_back(routeId);
payload->push_back((routeId >> 8) & 0xFF);
waypointName = "And Back Again - Comment";
payload->push_back(waypointName.size() + 2);
payload->push_back(0x01); // 1 indicates ASCII encoding
for (size_t i = 0; i < waypointName.size(); i++) {
payload->push_back(waypointName.at(i));
}
generated the following.
Until shown evidence, I have a higher degree of confidence that Actisense would follow the current version of standard than you.
meaning all other now need to have to update their projects enums
Well, that is a very old problem of any software developer. A new version of a library or a new version of an operating system is released and suddenly some functions are deprecated and others to are be used in the future.
Also the NMEA is deprecating messages. For example 130310, 130311, 130312, 127503, 127504, 127507, 127509 are deprecated.
If you develop software you have only 2 options: 1.) You adapt your software to all the changes that are coming. 2.) or you use the old database and let it all as it is.
But in the wold of software a standstill does not exist and will never exist. And adapting a few enums is a work of a few minutes for you, It takes less time than to write a comment here complaining about a useful improvement.
You can even implement a fallback: If a future database version has a FieldType that is unknown in your code you switch to NUMBER. Then you have nothing to do when a new FieldType is introduced.
It would be sad if Kees does not develop this database to become better every day because a few people are complaining that they have to do minor changes like adding a new FieldType.
I suggest you step onboard a boat before making such absurd comments.
It is funny that once you wrote that I'am aggressive. Look at your own writing. I never made any absurd comment here. But you are quite aggressive.
instrument displays and software applications allow users to configure their preferred units. I
It is funny how you are contradicting yourself. I want to write a software where the user can do just that: chose the display unit he wants knots or km/h. But therefore I must know which of all the units "m/s" can be converted and which not.
I have a higher degree of confidence that Actisense would follow the current version of standard than you.
I have higher confidence in the NMEA than in Actisense which is writing quite sloppy software. Just read the documentation that is publicly available:
I'm picking the following as legitimate improvements:
- Lookup SERIAL_BIT_RATE has duplicate value 19200
- SIMNET_KEY_VALUE value 11524, "True wind shift" should be "ANGLE_FIX16".
I will check if I can verify the length of those strings, I will check if I can get my MFD to produce this PGN.
You other remarks:
- Anchor depth is already in m, not m/s. Fixed in ed5a1f12.
- PGN 128520 field 3 Track Status is a terrible field as it combines both a lookup in the lower two bits as well as two bit flags in the upper two, so I have chosen to map this as three fields (Track Status, Reported Target and Target Acquisition.)
- WP_POSITION_RESOLUTION: < means not inclusive and ] means inclusive in a range. This is standard math notation.
It's funny that you slag Actisense of writing sloppy software -- they have been on the NMEA committee for decades and have chaired the NMEA 2000 committee for years.
@Kees:
they have been on the NMEA committee for decades and have chaired the NMEA 2000 committee for years.
Do you say that because Actisense sends some people to a comittee, some other people who write software automatically do a good work? I cannot see any logic in this. They are different people.
It's funny that you slag Actisense of writing sloppy software
I don't understand this. It is strange that you have all the information and did not notice on your own what quality software Actisense is writing??
Look at this screenshot:
What information does Actisense give you here ? Industry Group = 4 Device Class = 85 Device Function 130
Do you have all these numbers in your memory so you know what they mean ? I cannot imagine that you say this is a very well written software of high quality. Why are they too lazy to look these values up in the table and show what they mean ? A high quality software would display:
Industry Group = Marine Device Class = External Environment Device Function Atmospheric
The numbers that they display are completely useless.
And what about this ?
Do you know by memory which company has the code 666. No! It is not the devil. It is Schaeffler Technologies AG & Co. KG Why do they not display this ??
And this one ?
What is MOB Status = 0 ? What is MOB Emitter Battery Status = 0 ?
A software of high quality would display
MOB Status = MOB Emitter Activated MOB Emitter Battery Status = Good
Why is Actisense not able to display this ?
And these are only three examples. Do you need more ? You can take nearly every message and you will find this lack of quality. Most of the enum values which have a meaning are only displayed as numbers.
It's funny that you slag Actisense of writing sloppy software
It's not funny. It is a fact. If they would use your database they would display all these values.
And to use NMEA Reader you have to buy an extremely expensive NGT-1 interface for $230 US ! It is a shame that they take that amount of money and display only the most rudimentary information to their clients.
And I'am not even talking about their primitive GUI which requires you to click each message one by to see only one message at a time.
And their NGT-1 is extremely slow. It works only with 230 kbaud! This is very few for a CAN bus with high traffic. I suppose for that reason I see lots of missing messages in some logfiles. The user does not even notice that messages are missing. But if the CAN bus traffic is higher than the transfer speed to the computer some messages will be omitted.
On the other hand my software HUD ECU Hacker works with a cheap CAN bus adapter that you can buy for $20 US in Alibaba and that works with FULL USB speed (12 Mega Baud) and displays ALL the information decoded to the user. https://netcult.ch/elmue/hud%20ecu%20hacker/#J2534_Adapter
The NGT-1 is a solid piece of kit that many offshore racing teams depend on for thousands of ocean racing miles. Including my team. Even at $255 it is a pittance given the budget of the rest of the kit we carry.
Any feedback re: the NGT-1 or NMEA 2000 spec is best directed to the links I've provided below.
Associate membership to NMEA is $255 per year. https://web.nmea.org/atlas/forms/1 Strike up a conversation with the NMEA president https://www.linkedin.com/in/mark-reedenauer-0352646/ Or the chair of the NMEA 2K committee (also from Actisense) https://www.linkedin.com/in/andy-campbell-14105287/
Good luck.
@Elmue
I'll say this only one more time.
You are not a sailor, you have never set foot on a boat and your comments only serve to display your ignorance of all things nautical.
And their NGT-1 is extremely slow. It works only with 230 kbaud! This is very few for a CAN bus with high traffic.
NMEA 2000 is 250Kb/sec. That is the standard. That is what all marine equipment certified for NMEA 2000 uses. I'm not going to do the math but given that a CAN frame contains a significant number of overhead in addition to the actual data, the NGT-1 would appear to me to have sufficient throughput.
And to use NMEA Reader you have to buy an extremely expensive NGT-1 interface for $230 US !
It is a diagnostic and configuration tool for use with Actisense devices. It is little different to N2KView which is used with Maretron devices and CANLogViewer which is used with YachtDevices gateways.
Why are they too lazy to look these values up in the table and show what they mean ?
99.99% of sailors would not use these diagnostic tools. Their primary displays on vessels are chartplotters and instrument displays which show vital information to the sailor. For example a sailor only needs an alarm to be raised when a Man Overboard Beacon has been activated and that it is displayed on their chart so that they can plot a course to that position. They don't need to be overwhelmed by the details that so enthrall you.
On the other hand my software HUD ECU Hacker works with a cheap CAN bus adapter that you can buy for $20 US in Alibaba and that works with FULL USB speed (12 Mega Baud) and displays ALL the information decoded to the user.
It is great that you are building a better mousetrap, but be aware that 99.99% of sailors are probably uninterested in your improved mousetrap and that your mousetrap doesn't catch the proprietary PGN's that the commercial marine equipment manufacturers use.
More importantly, your software and inexpensive CAN Bus adapters are not NMEA 2000 certified. In the event of a maritime accident, investigators and insurance companies may determine that the use of non certified equipment was a contributing factor.
@woobagooba
Strike up a conversation with the NMEA president
I have no idea what you are talking about? I'am not interested to improve the sloppy Actisense software: I'am writing my own high quality software.
@TwoCanPlugin:
NMEA 2000 is 250Kb/sec. That is the standard.
I know that. This is not a news for me.
the NGT-1 would appear to me to have sufficient throughput.
I did not analyze their adapter because I dont have it, But I have implemented several CAN adapters into my software which also use COM ports. It is usual that these adapters transfer data in ASCII format over the COM port. That means a data byte 0x8A on CAN bus is transfer as two ASCII bytes "8" and "A" over the cable. Additionally they must transmit the PGN, Priority, Source, Destination or the CAN Bus address and they must transmit where a new packet starts and ends or the length. All these bytes summed up result in a throughput far less than 230 kBaud. If they use ASCII transfer they will perhaps get a throughput of 100 kBaud. On a CAN bus with high traffic you will lose messages.
But even if they do not use ASCII transfer, there is no reason to reduce the USB speed (which is 12 MEGA bit/s) to something as slow as 230 kBaud. Why do they limit the USB speed at all ?
Because they probably use something like this:
They use for example a FTDI USB to RS232 converter chip and connect that to the processor. This limits the speed to the RS232 speed. This is a wrong hardware design!
A more intelligent design would use processor which has direct USB support instead, without needing a converter chip between processor and USB and they could use the full USB speed. This NGT-1 is badly designed. That is a fact that I do not discuss.
I dont know which software has grabbed the Susteranna 2020 logfile. But this logfile contains 290 errors! Here a small part of them:
Why are all these packets missing ? Are they lost because of a slow CAN adapter and a high bus traffic? Or did someone manually manipulate the logfile ?
If you use badly designed software like from Actisense you will not even notice this. They will hide all these errors from you.
Their primary displays on vessels are chartplotters and instrument displays which show vital information to the sailor.
You are totally missing the point. My software does not aim to replace any display on your boat. It is a diagnostic tool to analyze the data and find errors on CAN bus. And not only in vessels, but also in motobikes, ATVs, cars, trucks, buses, construction, agriculture and forestry vehicles. (If you would ever have read my page you would know this.) https://netcult.ch/elmue/hud%20ecu%20hacker
My software allows to grab logfiles that you can later analyze. It is not the purpose of my software to display to the sailor that someone has fallen over board.
that your mousetrap doesn't catch the proprietary PGN's that the commercial marine equipment manufacturers use.
Once again you show a great disrespect and write in a very aggressive tone.
My software will show all the messages that are in Kees's database. So it will show SIGNIFICANTLY more data than the primitive Actisense software that is not even able to fully decode a standard ISO Request.
More importantly, your software and inexpensive CAN Bus adapters are not NMEA 2000 certified.
If you would have read my page you would know that J2534 adapters are an industry standard that is used in the ENTIRE vehicle industry since decades. They can much more than only CAN bus. And they can much more than only vessels. They can connect to ANY vehicle on this planet. They are also used by tuning software to program ECUs on CAN bus. This means they transfer a new firmware version to the processor which is a very critical process. They are the most versatile and they are the most sold adapters worldwide. They are universal adapters, they are cheap because many many software uses them.
And as they do nothing more than transmitting the packets from CAN bus unchanged to the computer there is not much to certify. This is not a difficult task that would require any certification.
All the decoding of the CAN packets is done in software on the computer, not in the adapter.
As you see, you have no idea what you are talking about. Use Google to read about the international J2534 standard.
In the event of a maritime accident, investigators and insurance companies may determine that the use of non certified equipment was a contributing factor.
Once again you are completely missing the point. My software has absolutely nothing to do with marine accidents! It is a diagnostic tool to analyse CAN bus problems. And it is allows reverse engineering of ECUs or any other CAN bus devices.
the use of non certified equipment
Can you answer me one question ? What is this NMEA certification worth at all, if not even Actisense (which are supposedly in the comittee) complies with the NMEA rules that they have created on their own???
You yourself posted a screenshot of PGN 130071 where they decode a String_LAU2 wrongly. PGN 130071 expects a string with 2 length byes as the NMEA defines in their NMEA 2000 Appendix B.1 that you never have read.
But you send a string with one length byte and they decode it correctly. That means that NMEA Reader does not decode two length bytes and so does not comply with the NMEA documents.
The NMEA says that it should use 2 length bytes, so you should see crippled data. If the NMEA is doing the certification in such a sloppy way, this certification is useless. Or NMEA Reader is not even certified at all. What a shame for a company that sells this NGT-1 very expensive.
It is so funny that here are people posting who supposedly work since years with NMEA and believe to be the most sailor experts but neither have read the NMEA documents nor do they notice all the bugs and contradictions that I find every day working with this.
Why do I have to report bugs in Kees's database at all? I'am new to this. Why did TwoCanPlugin, who is supposed to be such an expert, not already report all these bugs ? What is your level of professionality ?
@Elmue If you have issues with the NMEA 2000 spec, certification process, or licensing issues ... take them directly to NMEA. Likewise with Actisense product issues ... take them to Actisense. Offer your considerable software engineering talents to move those communities ahead. Complaining about any of that here will not get you the resolutions you seek.
The signal to noise ratio of your contributions here will vastly improve if you focus on issues the canboat team is able to control, offer your feedback respectfully, keep it short and to the point, and take the rest to the appropriate destinations.
My B&G plotter doesn't support the "Route and WP service" PGNs, so I have no way of corroborating the field lengths from a 2nd source. Maybe someone with a Garmin or Raymarine plotter can try this?
I sent it an ISO Request for PGNs 130064 and 130065 and the answer came back negative.
These plotters sync the routes and WPs only within the same Navico group, using Ethernet.
FYI to send such requests you can use
(php ./util/format-message $mfd_id request_pgn 130065; sleep 30) | actisensense-serial -o <dev> | analyzer | grep 130065
which in my case produces:
.... 0 31 59904 ISO Request: PGN = 130065 (Route and WP Service - Route List)
.... 31 0 59392 ISO Acknowledgement: Control = NAK; PGN = 130065 (...)