Thanks! No, I didn't add the WidgetKit Extension. Had no clue it was necessary. I'll give it a shot.

Did some additional testing in a car at slow speed. Turns out the updates with varying locations work down to about 2mph. Below 2mph, updates continue and accuracy is updated, but the location never changes. This went on for over 100'. This makes the location unusable for trolling speeds or a more critical application such as an anchor monitor. It seems the issue is down to location's not updating when the speed is below 2mph. Like sitting still on the bench, I could still make the locations change by "wiggling" the phone when the car was traveling below 2mpg.

I should mention this only happens when the boat is moving very slow, say around 1.5mph. Not sure what speed kicks it out of this mode, but at 30mph I get continuous updates.

I was surprised to find that the phone app continued to pass my commands through to the autopilot even after locking it. I would have been perfectly happy to have kept it on while using the autopilot, so the functionality to continue while locked was an unexpected bonus. The HW autopilot’s only function is to maintain a heading. Anything else will be features I add in the phone app. I plan on implementing a route tracking feature once I verify the HW autopilot is doing its job. That and a few others would be tedious if not impossible to implement on the watch, so my plan is to have the phone be the brains of the operation.

I integrated the approach gleaned from the test app into my autopilot app, and I can now control the autopilot from my watch. The watch sends messages to the Bluetooth manager on the phone, and those messages are forwarded to the Bluetooth peripheral in the autopilot. Works like a champ!

I just added "DispatchQueue.main.async { self.rcvMsg = msgStr }" where recvMsg is my published variable, and I now have two way communication working! Thanks again for your time.

Well, I've got one way communication now, but only when I run on the actual devices. running from the simulator I still get the pairingID issue. I can send from the watch to the phone, but the other direction, I have the following issue when updating my watch View from the ViewModel... Publishing changes from background threads is not allowed; make sure to publish values from the main thread (via operators like receive(on:)) on model updates. I'm getting closer, but time to pack it in for the night.