User Profile

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.