This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
nmea output not working on usb-serial
#1
Hi there,

I have an rs422-usb converter connected to the usb port of the tinypilot. The converter is connected to nmea 0183 connections (in and out) of my instruments. It is receiving wind data (and various other sentences) successfully and repeating them to TCP.

Unfortunately the NMEA output is not working. The tx light on the rs422 converter never lights up. I would like to output at least rudder angle RSA and compass HDM so that they can be shown on my instruments.

The tinypilot does output these sentences on TCP over wi-fi but not on the usb serial connector. It is recognising the usb serial connector and using it as an input for wind data (the "W" appears on the tinypilot screen), just no output.

Is this a missing feature or is there something I can do to turn it on or fix it? A working rudder instrument is especially important for us and I have to keep reverting to our old autopilot (which has working nmea output) to get  a rudder position display. It needs to avoid repeating back any sentences which were received from the instruments as that would cause a feedback loop.

It should ignore any rudder position coming back from the instruments as that will be an echo of what it sent. The position coming from the servo should take priority. Same with heading - internal sensor value should replace the received nmea value.

Thanks!
  Reply
#2
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.
  Reply
#3
(09-29-2019, 08:21 PM)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.
  Reply
#4
(09-30-2019, 07:22 AM)syohana Wrote: 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.
This is a strange access point.
Quote: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.
This is one option, but it's not yet implemented... The other is to use two wifi adaptors in the machine with opencpn. I have done this frequently with multiple pypilots, and if a rudder feedback, gps or wind sensor fails on one autopilot, it receives the data from the other one, and opencpn is connected to both pypilots which makes this possible.
Quote:The instruments don't have WiFi so theym receive the rudder and heading via the usb serial.
The machine with opencpn could output the rudder and heading to the sensors after receiving it from wifi, but I agree it would be nice to have it directly from the pilot too.

Quote: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.
Yes, maybe a config file or something. Really it could be a completely separate program from the autopilot that most users don't need.

This program could connect to the tcp nmea stream of pypilot and just output it on a serial port, as well as writing incoming serial data to the socket while filtering certain sentences in both directions. It could be an additional service of pypilot.

Quote: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.
Yes. Feedback is possible in many cases with multiple receivers.

Quote: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?
Can you explain why you need to use the rudders independently? I am curious? Can they be used as a brake this way?

pypilot chooses a priority of incoming sensor data. Basically, it chooses data from the motor controller, gpsd, signalk, nmea serial ports, and nmea tcp sockets in that order.

If the rudder feedback stops working on the motor controller, it will switch to the nmea provided one.

I'm not sure this will fully solve your case of having two rudders. This is definitely not something pypilot currently is aware of.
Quote:Seems like borrowing/cloning the connections config dialogue from opencpn would be the best approach as it will be familiar to most users.
  Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)