results from testing

[joshua-8]

Please contribute your own testing results or ask about how tests were performed.

[joshua-8]

With an I2C clock of 400kHz, I got the signals for the A and B channels of an encoder port up to 4.4kHz without seeing any lost steps when connecting to only one port at a time (though reading from all 8). I was also able to keep this frequency while connecting 3 signals to 3 ports that share a port of the Arduino.

[joshua-8]

If the I2C clock is set to 400kHz, I found that only very occasional steps were lost with 3.25kHz signals to each channel (or 13kHz encoder steps per second). The signals were simulated by an esp32 and connected in parallel to multiple inputs.

[joshua-8]

I was reading the encoder boards at approximately 100Hz

[joshua-8]

notes from testing V2

__________________________ (session 7)
after more optimization (and screenshots with logic analyzer)

reading QT Py ESP32S3 made: 1,47429,0,2,0,0,3,0,0,4,0,0,5,0,0,6,0,0,7,0,0,8,-43183,0,

yahboom tt motors powered with 9 volts (overvolt, so worst case)

D4 and D5 are motor 1
D6 and D7 are motor 8

motor 1 logic analyzer readings: 11927+11927+11922+11923=47699
percent error: 0.566%
15000 steps per second
motor 8 logic analyzer readings: 10899+10899+10892+10891=43581
percent error: 0.913%
14000 steps per second

interestingly, the logic analyzer reads different numbers of pulses between two channels of one encoder, it shouldn't be possible to have a difference larger than 1 or 2, so the analyzer might be dropping some pulses.

old code:

My theory is that spending a long time in an I2C callback can cause encoder pulses to be dropped.
new code:

spends less time in callbacks (bytes are sent one at a time from a premade buffer)

Saleae Logic file (logic analyzer)
Session 7.zip