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
#5
Hi Sean, we have now successfully crossed the Atlantic with pypilot!

Very happy with the steering aspect but the lack of working NMEA output over USB has been a major, major headache. We had to keep the old autopilot switched on to provide heading data for the instruments and for the radar, which doesn't work well without a heading input. It hasn't been good for the state of our batteries having the old system switched on and it still doesn't give us rudder data because the sensor is connected to the pypilot.

The pypilot seems incapable of connecting as a WiFi client to feed data into the xb8000 because there is nowhere to configure the nmea port number for client connection in the LCD interface. That would be the only alternative to nmea output over USB.

Using open cpn as a bridge is not a good solution. Firstly the radar and instruments would fall at the same time if the nav tablet fails. They are supposed to provide redundancy so there are two ways of seeing the data, not to work as a chain when any failed device can bring the others down. Also I have multiple devices which can run opencpn and no way to know which is on at any time. I couldn't set them all to echo the nmea because that would duplicate it when more than one opencpn is in use.

AIS data only comes from the xb8000 so that needs to be the main WiFi hub the tablets connect to. It would be unreliable if it passed through anything else. So autopilot needs to send heading and rudder via instruments to the nmea wired input of the xb8000. Xb8000 only supports 5 WiFi clients, another good reason to use wired connection and save those for the Android tablets (I use Android tablets and phones as instrument displays inside and outside so all 5 are needed)

Xb8000 must be access point not client because we use the Vesper watchmate app for anchor alarm etc.

Finally, the only opencpn devices we normally use on passage are Android, they only have one wifi interface. Adding a raspberry pi plus a second WiFi just to echo rudder data would be a big waste of precious battery power, sledgehammer to crack a nut and probably unreliable.

It's pretty standard for all autopilots to output rudder and heading as a minimum over wired nmea. the autopilot is very likely to be the only source of that data so feedback is unlikely. If its not wanted them the user doesn't have to connect it. Can we get that working as a quick solution until a fully configurable nmea system is working?

As regards the second rudder input, is not important but since you asked... our rudders are hydraulically connected and can get out of alignment so they each have separate sensors and displays to monitor that. Starboard sensor connected direct to an instrument which can output nmea. Port sensor connected to an autopilot which should then output nmea to drive the port instrument. If one ram or rudder fails we lock it as a trim tab and can steer with just the other rudder. It would be nice if we could fail over to the nmea from the instrument on starboard side if the directly connected port sensor fails but mainly we just need the nmea output working on the pypilot so there is something to drive the port rudder gauge.

Anyway, the TLDR version: tinypilot should be a drop in replacement for existing autopilots without reconfiguring everything else on board. Existing autopilots generally all output heading and rudder data over wired nmea so I think tinypilot should do that too (via USB)
  Reply
#6
(01-02-2020, 10:13 PM)syohana Wrote: Hi Sean, we have now successfully crossed the Atlantic with pypilot!

Great news. Any more details on the steering, settings, and power consumption would be interesting.
Quote:Very happy with the steering aspect but the lack of working NMEA output over USB has been a major, major headache. We had to keep the old autopilot switched on to provide heading data for the instruments and for the radar, which doesn't work well without a heading input. It hasn't been good for the state of our batteries having the old system switched on and it still doesn't give us rudder data because the sensor is connected to the pypilot.

The pypilot seems incapable of connecting as a WiFi client to feed data into the xb8000 because there is nowhere to configure the nmea port number for client connection in the LCD interface. That would be the only alternative to nmea output over USB.

This is true. It only listens on port 20220. So if you need nmea data on something which also listens you would need to write a client script which can connect to both servers and forward the nmea sentences. Obviously, opencpn can do this...
Quote:Using open cpn as a bridge is not a good solution. Firstly the radar and instruments would fall at the same time if the nav tablet fails. They are supposed to provide redundancy so there are two ways of seeing the data, not to work as a chain when any failed device can bring the others down. Also I have multiple devices which can run opencpn and no way to know which is on at any time. I couldn't set them all to echo the nmea because that would duplicate it when more than one opencpn is in use.
Yes this is a big problem because then multiple sources can exist and eventually data loops. This is one of the reasons pypilot does not output nmea over serial devices.
Quote:AIS data only comes from the xb8000 so that needs to be the main WiFi hub the tablets connect to. It would be unreliable if it passed through anything else. So autopilot needs to send heading and rudder via instruments to the nmea wired input of the xb8000. Xb8000 only supports 5 WiFi clients, another good reason to use wired connection and save those for the Android tablets (I use Android tablets and phones as instrument displays inside and outside so all 5 are needed)
A limit of 5 clients for wifi seems arbitrary.

Quote:Xb8000 must be access point not client because we use the Vesper watchmate app for anchor alarm etc.

Finally, the only opencpn devices we normally use on passage are Android, they only have one wifi interface. Adding a raspberry pi plus a second WiFi just to echo rudder data would be a big waste of precious battery power, sledgehammer to crack a nut and probably unreliable.

It's pretty standard for all autopilots to output rudder and heading as a minimum over wired nmea. the autopilot is very likely to be the only source of that data so feedback is unlikely. If its not wanted them the user doesn't have to connect it. Can we get that working as a quick solution until a fully configurable nmea system is working?

Basically, yes, but it's complicated. It's not very difficult to add exactly what you want but it would make things worse for other users. For example, it would be sending rudder and heading output to the wind sensors. It might receive nmea data over wifi from somewhere and need to output over a wired port??

Eventually it's going to need to have a way to fully configure all the nmea ports. Specify which data to repeat where, and at what rate. Which ports have priority and even what sentences to accept or reject. I didn't really bother with this because nmea0183 is somewhat outdated and the current behavior works in many cases.

Quote:As regards the second rudder input, is not important but since you asked... our rudders are hydraulically connected and can get out of alignment so they each have separate sensors and displays to monitor that. Starboard sensor connected direct to an instrument which can output nmea. Port sensor connected to an autopilot which should then output nmea to drive the port instrument. If one ram or rudder fails we lock it as a trim tab and can steer with just the other rudder. It would be nice if we could fail over to the nmea from the instrument on starboard side if the directly connected port sensor fails but mainly we just need the nmea output working on the pypilot so there is something to drive the port rudder gauge.
Ok. So you could also possibly read from the rudder sensor on port side to directly output nmea as well and drive the gauges. pypilot motor controller could also sample this same analog voltage and get rudder angle this way. The problem is the actual angle once read and calibrated might be different.
Quote:Anyway, the TLDR version: tinypilot should be a drop in replacement for existing autopilots without reconfiguring everything else on board. Existing autopilots generally all output heading and rudder data over wired nmea so I think tinypilot should do that too (via USB)

I would agree but I don't want to output wasted data over nmea if it isn't needed for most cases. It does take more processing power and goes against my goal to use higher level logic and configuration to avoid wasteful computations. At a minimum this is going to need a boolean option (checkbox) to output nmea on serial, but a full configuration would be better.
  Reply
#7
Could you run Kplex on the tinypilot device?


Sent from my iPhone using Tapatalk
  Reply
#8
(01-04-2020, 03:24 AM)tkurki Wrote: Could you run Kplex on the tinypilot device?

Yes, kplex could run on the tinypilot, but I am not sure if it can do exactly want is needed.   If it can read a configuration file which tells it to connect to pypilot and output to another tcp connection or serial port then it would be a viable solution.

Also consider all the hops the data makes before it reaches the end gauge and how much total lag, if greater than 200ms it will be noticeable.
  Reply
#9
Pypilot to kplex over tcp in localhost, kplex to serial. Where would the delay come from? Or did I miss something?

OP said gauges are wired, I assume radar as well.

I believe this is what kplex was built for, but have not used it myself.






Sent from my iPhone using Tapatalk
  Reply
#10
Big Grin 
(01-02-2020, 10:13 PM)syohana Wrote: Hi Sean, we have now successfully crossed the Atlantic with pypilot!

Well, that is a pretty impressive feat, and if I'm not mistaking a major milestone for the PyPilot! Congratulations to both you and Sean. Marketeers would welcome something like this as a 'success story' and even if you're not into corporate stuff it still deserves to be highlighted. Can you share any pictures or footage of your installation or passage to this forum please? 

BTW if you are thinking about a tattoo may I suggest 'PyPilot'  Smile.
  Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)