Reverse engineering of Navico autopilot controls #309
Comments
|
Was following up a few issues I had raised on SignalK and saw a link to this. Canboat has been an inspiration for the OpenCPN TwoCan plugin, so happy to give something back. I haven't been able to get the NAC-3 to go into Navigation or No-Drift Mode because I have yet to figure out what other PGN's are required. For example, in Navigation Mode, even though I generate and transmit valid PGN 129283 (XTE), PGN 129284 (Navigation) and PGN 129285 (Route/Waypoint List) messages, they are not sufficient to enable the NAC-3 to engage in Navigation Mode. There are a couple of PGN's sent by a B&G Zeus MFD that appear to be necessary to support Navigation Mode, but as yet, I have not been able to decipher them Note the NAC-3 behaves as four separate NMEA 2000 devices, Autopilot, NMEA 183 Input, Rudder Feedback and Virtual Rudder Feedback. Similarly the Zeus-2 MFD behaves as several NMEA 2000 devices, MFD, Navigator, Autopilot Controller, GPS. All of these are Manufacturer Proprietary PGN's, with the first two bytes encoded with the Manufacturer and Industry codes as per usual. PGN 65305, NAC-3 Autopilot Status Sample Raw Data Byte 2 indicates the Autopilot Model. 0x64 - NAC-3, 0x00 - AC-12 NAC-3 Autopilot Mode Sample Raw Data Byte 2 indicates the Autopilot Model. 0x64 - NAC-3, 0x00 - AC-12 PGN 65431 Sample Raw Data Byte 4 reflects the Autopilot Mode (or more correctly), the type of angle Byte 5 and Byte 6 encode the angle expressed as radians with a resolution of 0.0001 PGN 130856 Sample Raw Data Decoded Message PGN 130851 Sample Raw Data Byte 2 - NAC-3 CAN Bus Network Address PGN 130860 Sample Raw Data GPS Mode Standby No Drift Mode Wind Mode I haven't figured out what this PGN encodes PGN 65305 Sample Raw Data Byte 2 - 0x01 Presumably indicate a keep alice/heartbeat message ?? Although 0x03 corresponds to the CAN address as the NAC-3 on my network PGN 130850 Sample Raw Data 0x41 0x9F 0x03 0xFF 0xFF 0x0A 0x1A x00 0x02 0xD1 0x06 0xFF 0xFF (change direction by 10 degrees to Port) Decoded Message Byte 2 (nn) - CAN Address of NAC-3 Byte 8 (dd) - Direction, Port = 0x02, Starboard = 0x03 When changing angle, otherwise 0xFF Note, when changing to GPS mode (following a GPS course), the message must be transmitted twice. The PGN broadcast from the MFD which seems to be the key to engaging the NAC-3 in GPS mode is PGN 139820 Sample Raw Data It doesn't match any of the formats in Canboat, but does seem to be a series of key/value pairs. 0x7D 0x99 Decoding each of the values as int, unsigned int, short, unsigned short and converting to latitude, longitude, speed, distance, angle time, doesn't correspond to anything that makes sense. Hope this is of some help. |
|
Thanks. I will be out sailing for a few months, but aim to pick this up after that. |
|
No probs, BTW, Apologies for posting in the wrong spot, but posted an analysis of PGN 130850 & 130851 from the data that Teppo provided in #272 Enjoy your sailing. |
|
BTW, Dyslexic fingers caused typo. A little bit of further analysis, I think the value of key 5, corresponds to distance to waypoint. Really needs to be captured while underway as any values such as sog,, time to waypoint etc. are meaningless when stationary. |
|
See also #409 |
Started with proper analysis of AP48 commands. The intention is to slowly add all 'operation' commands from the AP48 and all data coming NAC-3 and AC-42. This will allow development of open source AP controllers. 'Commissioning' is considered out-of-scope. Although some users seem to think this useful, I feel that it is dangerous to try and emulate the control head / MFD to such an extent, and that this should be left to the device manufacturer. Also, it is different for every generation of AP computer so I also think the work/benefit ratio is too low.
|
Revisited this. All that the NAC-3 requires is valid PGN 129283 (XTE) and PGN 129284 (Navigation Data) messages with the following weird observation, in that Navigation mode could only be reliably selected when the Device Class and Function class were set to 50 & 130 respectively. This made little sense to me. Even if I set the other fields in PGN 60928 (address claim), such as the manufacturer code and the fields in PGN 126996 (Product Information) to match those from a B&G Zeus MFD, it seemed to give random results. Perhaps I was holding my tongue wrong. |
|
Note that in v5.0.2 I have just merged a number of fixes to the "Simrad: Key Value" PGN 130845 which is now mostly readable. Not really AP control yet, but most of the data generated by changing settings on my AP48 are now supported. |
|
Does anyone have a log of n2k data when using the autopilot? |
i captured these recently. when i playback it successfully controls the boat: 1 starboard 2024-06-03-17:57:54.174,2,130850,0,255,8,20,0c,41,9f,01,ff,ff,0a 10 starboard 1 port 2024-06-03-17:57:43.925,2,130850,0,255,8,00,0c,41,9f,01,ff,ff,0a 10 port 2024-06-03-13:55:25.156,2,130850,0,255,8,20,0c,41,9f,01,ff,ff,0a |
|
That helps, but I need a complete session that includes changing navigation modes and includes all the messages coming from the AP. |
|
@sbender9 dropped you a url for a capture file. If anybody else is interested ping me. |
|
I would be interested as well, if only to verify what I am already parsing. Haven't been able to retest this year, but at the end of last year, pretty confident that I could control a NAC-3 (change mode, heading, wind angle) and generate the correct PGN 129283 & 129284 & Keep Alive messages. |
|
@TwoCanPlugIn drop me an email at teppo.kurki@iki.fi and I'll reply with link to the capture file. |
|
Yeah a number of pgns were done last year and are already in the database. The question now is to finish all scenarios and describe them.
These scenarios are:
1. Control a Navico autopilot computer. Convince it that there is a valid control head and allows settings like mode, heading, etc. For example, steer a boat with NAC from OpenCPN or other nav software.
2. Initial setup of a Navico autopilot processor. This is quite a lot of work as there are many settings.
3. Acting as a Navico autopilot processor. Convince physical Navico control heads that there is a valid pilot computer and listen to its commands. For example use a Triton 2 controller with a pypilot, or even a Raymarine AC.
Scenario 2 is for people that are looking to buy only a NAC without any control head, and I think this is probably the more outlying scenario. Scenarios 1 and 3 are opposites of the same coin and will appeal to opposite installations.
The scenarios not only need information on which PGNs are used but also how they are to be sequenced to get a particular result.
I think we should, for now, just add wiki or markdown pages before trying to make a more structured description of these sequences.
|
|
OK, Here goes. I was able to "borrow" neighbour's boat on weekend to capture some more data. It agrees what I had written earlier and at least for scenario 1. Controlling a NAC-3 with another device, it confirms what I was able to do at the end of last season. (My problem is how to package it for OpenCPN, either include it in TwoCan, develop a separate plugin that uses TwoCan, or a separate plugin that uses OpenCPN's native NMEA 2000 support. However that's my problem, not yours). Regarding the other scenarios, 2. Commissiong, is going to require a lot of configuration & analysis, and for 3. Using something like a MFD or Triton 2 to control a PyPilot I think would also be difficult. I also doubt whether someone who invests in a PyPilot (hobbyist, tinkerer) is going to spend a large sum of money on a Triton2? The setup, or at least the captures, which I've filtered to exclude the noise. For Autopilot functions, the capture is between 3 & 5. and the order is the following: Important PGNS are 130850 (Event Command), 130851 (Event Reply), 65305 (SImnet Autopilot Status), 65341 (Simnet Angle). Also important is he use of 65305 as a Keep lAlive from the Pilot Controller to the Autopilot. As moored alongside, a few "Low Boat Speed" alarms. BTW, A couple of additional Alram messages. (PGN 130856 contains the code & text, 130850 contains the error code). For Nav mode, the capture is between 12 and 3. I was only able to perform the Dockside commissioning, which looks to only configure the NAC-3 Virtual Rudder Feedback (eg. turning wheel to full lock and centering. I wasn't going to play with the other settings (eg. boat displacement, boat type, tacking angle etc.), so perhaps not much use. The attached text files are just my parsing of some of the PGN's. They kind of make sense to me and at least for PGN's 130850, 130851, 65341 and 65305 it matches what I have been able to use to control the NAC-3. I guess the one important thing to note, and perhaps one should feel some sympathy towards the developers of the MFD's at Navico. I guess through all of the acquisitions/mergers (Simrad/Robertson, B&G) each autopilot (TP32, AC-12, AC-42 and NAC-2/3), each autopilot has an inconsistent set of commands, so the decoding for the NAC-3 will differ to that of say for example the Simrad TP-32 Tillerpilot. It would be great to get another capture of Teppo's TP-32, albeit with a description of the modes & commands that were issued. Regards... |
|
Oops, forgot to add Non Follow Up mode (NFU). When autopilot is in Standby. Again PGN 130850 sent from MFD to Controller. The usual palaver, Byte 2 is the autopilot controller's CAN bus address, Byte 5 is the Command (0x02) and Byte 8 controls whether to move rudder to port or starboard. For the port & starboard commands these are sent continuously while the port or starboard button is pressed. 0x41 0x9F 0x03 0xFF 0xFF 0x02 0x0D 0x00 0xFF 0xFF 0xFF 0xFF - NFU Mode Didn't get the opportunity to test "dodging" when in Nav mode nor auto tacking when in Wind mode. |
(A lot of) work has already been done on this by @htool, see https://github.com/htool/RaymarineAPtoFakeNavicoAutoPilot
Hans' focus was to be able to use a Raymarine AP with a Navico control head, for this to work it needs to know that the AP is fully commissioned.
I intend to go the other way:
The text was updated successfully, but these errors were encountered: