2019-09-30, 12:22 PM
(2019-09-30, 01:21 AM)seandepagnier Wrote: It does not output or repeat nmea data to usb serial ports for this reason of creating data loops. It is possible to receive wind, gps, rudder angle, and autopilot apb messages over usb serial ports currently.
For now the easiest way to get rudder angle on usb serial is to receive the tcp socket connection using opencpn or another program, and have it relay the data to the serial port. Usually opencpn dashboard is used for rudder angle which is not a serial connection.
I would make it possible to output nmea on the serial port, but mostly it is not useful, wastes processing time and also produces sentences which are never consumed anyway. There needs to be a config file to determine which sentences to produce, which sentences to forward, and what rate ideally, so for now this not implemented.
Hi Sean,
My WiFi access point is the XB8000. It needs to be because it provides the ais data stream and I can't have any delay or complication in that. It is essential that the xb8000 is in access point mode also because I use their excellent watchmate app for all my Android instrument displays.
The pypilot must also be in access point mode so I can configure it. The xb8000 doesn't seem to work as a router so I can't connect to the pypilot web interface at all if it connects as a TCP client to the xb8000.
The instruments are connected by Nmea 0183 to both the pypilot and the xb8000. The only way the instruments and therefore the xb8000 and OpenCPN can get rudder and heading data is if the tinypilot can output it to the instruments via usb serial.
The instruments don't have WiFi so theym receive the rudder and heading via the usb serial.
I think the right way to do this is probably to have configuration for each connection to either send or receive each sentence, especially heading and rudder angle, much like opencpn does.
I thought through a lot of simpler options but none of them will work for all use-cases.
It's not even true that failing to output on usb serial will prevent feedback loops. You could receive input on usb, output it on TCP and then it could come back again on usb.
There are better ways to avoid feedback loops. One option would be setting each sentence to be an input or output but not both. This ignores the possibility that input and output are connected to different devices and data should pass down the chain. In the end the only option seems to be making it fully configurable, but with some idiot proof defaults (like no output on any interface by default, each output sentence to be configured individually).
Also, it's not clear what happens when there are rudder inputs from both nmea and the internal sensor. On our catamaran we can use the rudders independently and they both have rudder sensors. If a ram fails I can lock and isolate one rudder and steer with the other. In that case I would like the pilot to use nmea rudder input and ignore the internal sensor attached to the locked rudder. Configuration options for the source of rudder, heading and wind data are needed. This also applies to the case where wind data is received over both TCP and usb serial - how do I choose which one the pilot will use?
Seems like borrowing/cloning the connections config dialogue from opencpn would be the best approach as it will be familiar to most users.