• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Anyone sending Signal-k from Arduino?
Quote:Thanks for your reply,
OK, the lag might be an serious issue as you say - I hadn't understood that you "squeezed" pypilot in between the windsensor and openplotter - I assume it is stil
You can configure it to send the wind data from a remote host, etc.. but the preferred setup is directly. pypilot of course forwards the data
Quote:l ok to run the main pypilot sw on the same RPI3 as where openplotter/OpenCPN is running?
Yes of course. The two critical processes (autopilot and imu) set themself up with real time priority for the scheduler.
Quote: - Are you handling the GPS in the same way?
The gps has 3 options... direct serial nmea, gpsd, and remote tcp. I typically use gpsd, because it handles binary gps already. Lag in gps is less critical, as it is lagged by more than this anyway. The autopilot steers to compass, but uses gps to figure out the compass course to steer to hold the gps course... so even gps dropouts will not immediately cause problems.
Quote: - What about the rudder sensor? I'd like this data also to be available to OpenPlotter - do you send that onwards??
Yes, it is sent onwards as wind. The rudder angle is optionally measured as an analog voltage by the motor controller.
Quote: - How do you interface the motor controller - is that also nmea? In that case I will be short of one USB/RS422 adapter and need to share with the AIS tranciever...
The controller must be reliable with little lag. I am using a serial port, and ttl 3.3v. You could use rs232 trancievers for longer runs, or a lower baud rate, but this works for a few meters even at 38400.

It is not nmea, because there are no messages to cover this data. It is also not signalk, as signalk needs excessive processing for a little uC, and at low baud rates adds considerable lag. Also crc checking is needed. Instead it uses a very simple 4 byte per packet binary format, that tolerates losing messages, and occasional corruption. It can be extended as needed.
Quote:All my other sensors on the boat will use WiFi but if this would be an issue for wind then cables it will be.... I just got my 4 port USB extension for my RPI so I guess I could "afford" nmea0183 for wind. (1 for my AIS tranciever, 1 for the VHF, 1 for my STD Horizon plotter, 1 for wind instruments, 1 for GPS, 1 for kbd/mouse - that's 6 -> one spare - two if/when I retire the old plotter)
You could use wifi to try it out. It would be interesting to compare the differences. Besides lag, wifi might be less reliable. In any case, the autopilot steers to compass, so once that is working, you could lowpass the wind input sufficiently. It still uses the compass to help it steer to wind, as this is needed in very light dynamic wind anyway.
Quote:I thought you used signalk converted data in pypilot so I didn't think signalk was an issue but if you take nmea directly then I agree that doing a diversion through signalk makes no sense.... This would make use of one of my Arduino Nanos  in the first place anyhow....
It can accept nmea directly. For signalk, I have yet to implement signalk sensors, but it would not be difficult. The pypilot signalk is slightly different from node at this time, but hopefully they can be compatible soon.
Quote:On the wasted power issue, in my current test implementation i use the Arduino VCC as reference but I planned to turn to the internal 1.1 V reference and with 40 mA max current that would be like a 25 ohm resistor and if i didn't go absolutely wrong that would mean around 40mW + losses in the cable - assume a few more ohms there - say 5 -> 44 mW --- Not so bad.... 

How did you get to 100 mW?? Perhaps I've missunderstood something....
You have both speed and direction right? That would be nearly 100mW which is considerable. Try it anyway. Could use use a much lower resistor like 1 or 2 ohms, and an amplifier?

Forum Jump:

Users browsing this thread: 1 Guest(s)