Pypilot heading display

[nousian]

Sorry to be confusing... but there are 2 separate uses of udp sockets. One is for commanding the servo in manual control mode (slightly less latency) and may not be worthwhile.

The other use is used by upy_client, and a udp_port is sent to the server as a setting, eg: udp_port=23423

a) The server will then reply to watched values via udp on this port rather than tcp. All watch requests as well as setting other values are still sent via tcp, and the tcp connection should still be monitored. udp is connectionless and therefore not 2 way communication

Ok this clears it a bit.

b) units are in period.
c) If you send a period of 0, you would get the fastest rate.
d) you could run pypilot_client or watch "values" to get the keys

Will try.

e) ok. I would try getting it working with tcp first, and try udp if you really need it. 30 second delay makes no sense, 4 second delay also makes no sense. The udp vs tcp is a split second difference or generally you cannot tell. Play with other platforms and see... Find a way to flush the buffer. I did put the udp support in for a slightly more responsive esp32 control.
f) imu.heel is a lowpass version of imu.roll

Thanks, will try. I don't foresee problem or 30sec delay like someone - not me - had with tcp, but I have found udp works "nicer" with esp32. I have a hunch it is an issue with esp32 and its ip stack is not being that well fully optimized, but could be some other issues as well. I noticed this myself, I am feeding the heading from my DIY ublox F9 gnss rtk compass with esp32 to nmea 2000, with sending it from rtk receiver to esp32 via udp the end steering result is noticeably better than sending it via tcp. Have not measured the latency difference though, but it must be in the tens of milliseconds range I presume. With linux, tcp vs udp in local networks makes little difference.

And if/when I eventually manage to feed the heading to nmea 2000 to be used by other (commercial) autopilot, the less delay there is the better.

[seandepagnier]

I am developing wireless wind sensors using esp32. What I have is 2 esp32's. One of them at the sensors transmits the data using esp-now which is not wifi or bluetooth, but an esp specific protocol that has low latency. The other esp32 receives esp-now and can relay either via wifi, or more generally plug directly into pypilot via usb. The intention here is to eliminate the lag issues with tcp and even udp on both esp32, as well as linux, as I even find 500 millisecond hiccups on wifi data to be common and this is an issue when reacting to wind gusts.

[nousian]

I am developing wireless wind sensors using esp32.  What I have is 2 esp32's.  One of them at the sensors transmits the data using esp-now which is not wifi or bluetooth, but an esp specific protocol that has low latency.    The other esp32 receives esp-now and can relay either via wifi, or more generally plug directly into pypilot via usb.    The intention here is to eliminate the lag issues with tcp and even udp on both esp32, as well as linux, as I even find 500 millisecond hiccups on wifi data to be common and this is an issue when reacting to wind gusts.

I have not experienced major issues with esp32 udp. A lot of udp errors show up constantly, right now my nmea 2000 esp32 has 260h uptime and 8M (!) udp errors reported/counted, so reliable it is not. But then again, in my use case udp packet is sent over and over, so missing few makes little difference

I currently have two esp32s transmitting wind data wirelessly between each other. One is hooked to "old" wind display, direct to analog transduced, and sends the wind data over UDP, another is hooked to nmea 2000 bus and injects the received UDP data into NMEA 2000 PGNs.

Right now in quite a gusty wind the needles in analog wind display and NMEA 2000 hooked Furuno wind indicator are 100% perfectly synced. No way there can be more than few 10ms delay between those two, even 100ms would show up visually, I would argue.

But as I said, haven't measured these so no hard data, just an empirical observation. But my hunch is esp32 udp works fine, if not 100% reliably.

edit. Oh bollocks, just realized by looking at those numbers, it is almost 10 udp errors per second. Many hundreds are transmitter, but still it is very high even in percentage wise. Maybe I take half of my word back about esp32 udp stack. I wonder what is the underlying issue, as OSs like linux have had this sorted out for almost over a hundred years.