How do TzTouchXLs and a Navpilot 711C control and be aware of one another?

[PugSndBoater]

Forking this thread from the previous thread about user-objects not syncing across displays, since that more basic (and disruptive!) issue has been resolved.

How are the TzTouchXL MFDs and the Navpilot 711C aware of each other's state and how do they control each other? I don't mean the navigation data part. I know the navigation data flows from the XLs to the NAvpilot using NMEA2K PGNs (129283, 129284, and 129285), which seems to happen correctly, and our vessel can navigate a route on the autopilot. I mean more directly how do MFDs put the Navpilot into "A" or "N" mode, how are the MFDs aware of and control the state of the 711C autopilot (e.g. adjust the chosen heading with on-MFD buttons), and how do the MFDs stop the Navpilot (put it back into Standby "S" mode) from the XL display? That state-control and awareness of the Navpilot by the XLs seems to not work with our MFDs. It worked on our old four TzTouch2 installation, so I'm trying to sort out what's different or missing with the new four XLs.

• Everything is connected to the NMEA2K canbus.
• TzTouchXls are outputting PGN 129283, 129284, and 129285.
• TzTouchXLs have the same NMEA2K device instance (0), per configuration guidance form FishTech, and the same system instance as everything "0"
• Navpilot is set to output PGN 127237 (heading/track control) and 127245 (rudder). Rudder angle shows correctly on the MFD (e.g. in an Instruments page).
• Settings -> Routes -> Route Settings -> Navigate with NAVPilot is enabled on all four XLs
• On the 711, Nav Option -> Nav Data Source is set at Source2 for the TZT16X. Source 1 is blank (---------).
• Navpilot-700 is visible on the XL displays (it appears in the list at Initial Setup -> Sensor List -> Can Bus Sensor)
• PGN sentences 129283, 129284, and 129285 light up (turn black indicating receipt) in the Navpilot's diagnostic screen.

Symptoms:

• If I start navigation from the one XL that I selected as the Nav Data Source 2 (select route, start navigation, tap "Yes" to "Do you want to navigation with the Navpilot?" dialog), the Navpilot starts in "N" mode and I get a "NavPilot activated" yellow banner, but then I immediately get a "NavPilot deactivated" yellow banner on the XLs. The actual Navpilot remains activated in "N" mode but the TzTouchXL seems unaware of the NavPilot's state and is unable to control the NavPilot hardware. Waypoints will continue to update correctly and the route can be navigated successfully on autopilot, though. If I stop navigation on the XLs (Stop icon in the header bar) it doesn't put the NAvpilot back into standby mode like it used to on the TzTouch2s.
• If I start navigation from one of the other three XLs, it doesn't activate the Navpilot hardware at all (remains in "S" standby mode), but I can start navigating manually from the 711C screen (NAV button -> push control knob) and navigation will activate, waypoints will continue to update correctly, and the route can be navigated successfully on autopilot. Just like above, if I stop navigation on the XLs (Stop icon in the header bar) it doesn't put the Navpilot back into standby mode.
• If I start navigation using the controls of the XL (e.g. Navpilot item added to the XL's Data or Route left-swipe-in side menu) the Navpilot activates in "A" mode (showing "Navpilot activated" yellow banner), but then I immediately get a "NavPilot deactivated" yellow banner on the TzTouchXL. The actual Navpilot itself remains activated in "A" mode but the TzTouchXL seems unaware of the NavPilot's state and is unable to control the NavPilot hardware further, e.g. to use the MFD arrow keys in the Navpilot item to change the desired course. Like above, this also only works to active into "A" mode on the one MFD configured as a source in the Navpilot, which didn't used to be the case on our TzTouch2 installation.
• When underway in "A" mode on the Navpilot, if I turn the knob to adjust the chosen heading, on the old TzTouch2s I used to see the heading line drawn forward from the My Ship icon on the MFD to indicate the new desired course, but I no longer see that on the TzTouchXL (I just see the normal vessel heading line from the sat compass, same as when the autpilot is not running). Maybe that's a clue to something amiss?

Hence my question: how do MFDs and Navpilot interact and control one another, not the PGN nav data sent to the autopilot by the MFD, but the actual state and control? For example, are there proprietary sentences doing the control which may be having some problem. The control plane seems to be mostly not be working for us. This isn't a huge deal, because autopilot can still work and we can deal with the error messages every time it starts and inability to control it from the MFD. It's more just annoying because I know how it did work seamlessly on the old TzTouch2 install we had so I'd love to get back to that ease.

 

[FishTech]

To answer your primary question, the control and state is communicated between the two devices/systems via Proprietary PGNs.

1. Before we dive too deep, you are not up to date on software in your NAVpilot. Lets get that updated just in case there is something that was fixed in the background that is not in the documentation.
2. Ensure that your NMEA 2000 and Ethernet networks are shielded.
3. Set all of your MFDs back to the same device instance number. We avoid conflicts here by only letting one MFD talk the common PGNs at any given time. System Instance should be left at zero. (You already did this per another post.)
4. Try turning off the Heading/Track Control PGN 127237 in the NAVpilot. You should not need it and it has been an irritant in the past.

The TZTXL and NAVpilot should work just as well as it did before for you. I've been on vessels using XL with 300, 711C, and 1000 pilots. All of which worked great.

 

[PugSndBoater]

Thanks! Good to confirm its proprietary PGNs, and also to know that the expectation is indeed that it should work the same as before, and you've seen it working as such with XL MFDs and 711C autopilot.

1) Yes, I notice that Processor Ver 1.27 Control Ver 1.08 (Feb 2018) is the latest and we're one version back on Processor Ver 1.26 Control Ver 1.07 (April 2017). I'll get that update in the Navpilot a bit today and report back.

2) They are shielded -- we buy high quality name brand cabling -- but I'll verify the runs just to be sure.

3) Yes, though pending my question I edited my reply on the other thread to ask: I can't seem to get the instances to change back to 0 on the XL MFDs. It makes the update, but on each reboot of the MFDs they seem to revert back to the 0,1,2,3 instnacing we set originally. I need some help to sort that out.

4) Ack. I'll turn this off and report back.

 

[PugSndBoater]

Works! Thanks @FishTech.

After doing/checking the 4 things you suggested, all the expected functionality has returned (full control and state syncing between XL MFDs and the Navpilot).

My unverified hypothesis is the Navpilot firmware update mostly solved it -- we were only moving up one version and there's nothing in the release notes to suggest it would be relevant, but as you say it's always possible something else was changed in the background for the release that isn't mentioned in the release docs. Or else just a reflash of the Navpilot cleared some kind of stuck state.

The only lingering bit I didn't fully resolve is the MFD device instances. I can't seem to reset them all to 0. I've tried 2 or 3 times, but every time I set them to 0 and power the MFDs down and then power them back up again the MFD instances are back to 0,1,2,3 that I (mistakenly) set initially. The good news is that, at least as far as I can tell, having differant instances per MFD doesn't seem to be affecting any functionality that I've noticed. But it's still not what you said should be the proper config and you said it may cause some problems. Is there any other way to change the NMEA device instances for the MFDs that I should try, e.g. through serviceman? I tried via Initial Setup -> Data Sensors -> Sensor List. I tried via the Maretron NMEAAnalyzer software. Both ways I can set the instances all back to 0 with MFDs on, but it reverts after MFD power-cycle.

 

[FishTech]

Happy to hear everything is functional again! I'm trying to get some time in the lab to test this and see if I can do anything to make it happen.

 

[FishTech]

Works! Thanks @FishTech.

After doing/checking the 4 things you suggested, all the expected functionality has returned (full control and state syncing between XL MFDs and the Navpilot).

My unverified hypothesis is the Navpilot firmware update mostly solved it -- we were only moving up one version and there's nothing in the release notes to suggest it would be relevant, but as you say it's always possible something else was changed in the background for the release that isn't mentioned in the release docs. Or else just a reflash of the Navpilot cleared some kind of stuck state.

The only lingering bit I didn't fully resolve is the MFD device instances. I can't seem to reset them all to 0. I've tried 2 or 3 times, but every time I set them to 0 and power the MFDs down and then power them back up again the MFD instances are back to 0,1,2,3 that I (mistakenly) set initially. The good news is that, at least as far as I can tell, having differant instances per MFD doesn't seem to be affecting any functionality that I've noticed. But it's still not what you said should be the proper config and you said it may cause some problems. Is there any other way to change the NMEA device instances for the MFDs that I should try, e.g. through serviceman? I tried via Initial Setup -> Data Sensors -> Sensor List. I tried via the Maretron NMEAAnalyzer software. Both ways I can set the instances all back to 0 with MFDs on, but it reverts after MFD power-cycle.

After changing all the instances of the MFDs to 0, give it 10 minutes and then power cycle the system. There was once, years ago, a menu item that needed time in the background for the setting to take hold.