So I tried both of these today.
Dropping back to 10 x 3.3 T-motor propellers had no obvious effect so I’ll go back to the 11 x 3.7’s I’ve been using recently.
GPIO.wait_for_edge() is looking promising. In the official code, the Python call combines initialization, waiting, and cleanup into a single call to catch the hardware data-ready interrupt on the GPIO pin. This was 50% slower than my Python hard-loop reading the data ready register instead.
But by splitting this into three, edge_detect_init(), edge_detect_wait(), and edge_detect_term() with a wrapper to maintain back-compatible support for wait_for_edge(), my code now only calls edge_detect_wait() in the main processing loop – the other two are only called at start-up / shutdown. This means various bits of epoll() fd setup now only happens once rather than each processing loop.
The overall processing speed has only increased by perhaps a percent or two (expected), but critically, this represents getting marginally prompter indications of a new batch of sensor data availability. And hopefully therefore, reduce the risk significantly of dodgy sensor reads which mess up the velocity integration.
In my rewrite of the GPIO event handling code, I have broken some of the other event detection function I don’t use, but once I’ve reinstated that, I’ll see if Croston will accept these changes into the mainline GPIO Python library.