The new code I posted yesterday is based on the assumption that the motion processing code takes less than 1ms, so that no samples will be missed. I was aware that the assumption is probably not true, but thought I really ought to check this morning; net is that it takes about 3.14ms and so 3 samples are missed. That’s more than enough to skew the accelerometer integration resulting in duff velocities and drift
I couldn’t spot any areas of the code that could be trimmed significantly, so it’s back to working out why pypy runs some much slower than CPython – about 2.5 times based on the same test.
I will be sticking with this latest code as I believe its timing is still better than the time.time() version. I just need to speed it up a little. FYI the pypy performance data from their site suggests there should be more than a 6 fold performance improvement based upon the pypy version (2.2.1) used for the standard Raspian distribution; that’s more than enough.
I am still tinkering with kitty++ in the background, and have the macro-block data, but need to work out the best / correct way to interpret that. But it’s blocked because for some reason kitty’s Rasperry Pi can’t be seen by other computers on my home network other than by IP address. Just some DHCP faff I can’t be bother to deal with at the moment.