Hi,
Sure, I am indeed running a Pi 4b as the host (“Raspberry Pi 4 Model B Rev 1.4”), wired to the board. I tried with both long wires and short wires, that did not seem to make any difference at all (right now back to long wires). Here’s what the short wires look like:
(I ran with those wires straight to the board earlier, not just through the extender). Wired in the recommended 3 pairs way.
My understanding is also that there’s no automatic re-transmit or other error correction in i2c so it can’t really slow down due to wiring?
What does replicably make the difference is that with a background process hogging up 100% of CPU on the Pi, it works better.
Regarding your changes I originally tried the version before your changes and it wouldn’t work at all (complained about clock in the past or something like that)
Attached config.txt, I have the line
dtparam=i2c_arm=on,i2c_arm_baudrate=400000
config.txt (2.1 KB)
uname -r reports “6.1.21-v8+” and it is a 64-bit OS.
The pullup resistors on the board itself are 10K, not sure what’s the safest way to test the ones on the Pi .
I tried a few other things, since the board haven’t got level shifters I tried powering it from 5v instead (just in case regulator drop out is somehow a problem), didn’t make any difference.
I was thinking next step in troubleshooting, I would report the amount of time spent in sending vs receiving, to see if it’s data getting received too slow, sent too slow, or perhaps wake ups being too late.
The weird thing to me is that it improves when there’s background CPU load. Which makes me think that it is a wakeups issue. Or something with the CPU governor.
By the way is there any way I can test this without having to power on the whole printer? Does it work if i make a config file with just the accel tester? (I’ll try on the weekend)