An interesting observation about pigpio vs the old on-off library

[JaapvanEkris]

In preperation for the 0.9.7 release I've been regression testing the improved physics engine with all the old recordings of a C2 RowErg. In this, I notice that a group of older recordings are a lot messier than the younger recordings. In fact, they contain so much data drops and oounces, that even the 0.9.7 version struggles to handle all the noise (although it is better capable). But some files are so messy that the drag calculation gets completely thrown off.

Looking at the boundary between good and bad files, I found that there is a radical change at 25-09-2022. Before that date, a session typically had thousands of stroke detection errors (i.e. the data wants to move to recovery/drive, but it is kept back due to the safety net of maximum recovery/drive time) and hundreds of drag calculation errors (i.e. a drag GoF below the set required GoF), even on 0.9.7 with identical settings. After that, a session hardly has any dragfactor calculation errors, and only occasionally a stroke detection error.

Looking back in the change logs, I found this change: the change from unfiltered On/Off to pigpio with bounce filter that happened at that exact date. To me, this is a clear indication that we need debounce filtering, but also something more reliable than On/Off (if we need to move to RPi 5 which doesn't have pigpio).

[Abasz]

This is expected, mostly because old on/off version did not record the deltatime at the hardware but rather when the handler run:

https://github.com/laberning/openrowingmonitor/blob/9d7c2a08c06066f14106df635b17671bf9d3f596/app/gpio/GpioTimerService.js#L37

      const hrDelta = process.hrtime(hrStartTime)
      hrStartTime = process.hrtime()
      const delta = hrDelta[0] + hrDelta[1] / 1e9
      process.send(delta)

This meant that actually we are not registering the delta time based on the actual impulse trigger but rather the time when the handler processes in the javascript code. That include latency and dependency on task scheduling from the kernel. It made delta Times inconsistent and dependent on the system

Not to mention that we query hrtime() twice that makes things even worse because if there is any delay that would poison the next calculation... I dont see an option on on/off that would allow retrieving the original interrupt event time (though it may be possible to change the code but not sure). On/off uses Epoll that is basically polls the pin and sends a signal when state changes. This is similar to pigpio but not exactly (actually this is the reason why on/off works and pigpio not

On/Off library has not been updated for 5 years. So that is not the way to go.

The only way forward:

1. Some creates a js wrapper around some C Rpi interrupt library (or python that wraps C :) ) that allows registering the interrupt time at the hardware level and pass it on to the js wrapper.
2. We create the above js wrapper
3. We create the underlying interrupt code as well as the js wrapper.

There is no way around this.

to option one I have found this: https://github.com/sombriks/node-libgpiod

Author says on the pigpio realted issue: joan2937/pigpio#589 (comment)

That this is an alternative. But It does not seem to support interrupt (yet?)...

We need to accept the fact that Rpi is not build with realtime hardware in mind.

[JaapvanEkris]

Yeah, that seems the general idea from all discussions on the pigpio github board as well. I'll keep watching that space, as I actually hope somebody will stand up and make something we can use. There are plenty of 3D printers etc. that run into the same issue, so hopefulle someone feel scompelled to resolve this.