Topics created by earla

I need to connect an encoder to a Raspberry Pi and noted the M5Stack EXT-ENCODER (U161) appeared to offer exactly what I needed. However, initial testing identified a couple of issues.

Two test rigs were used - both gave similar results. The first used a commercially available encoder rated at 1600 pulses / round (quadrature) and max rotation rate of 5000 rpm. For the first test, the encoder shaft was rotated by a motor driven friction wheel. The second encoder was a hobbyist unit pre-mounted on a small motor. In both cases the A/B encoder and power connections went to the M5Stack EXT-ENCODER which was further connected to the Raspberry Pi GPIO header as per specifications. No additional pull up/down resistors were added as my reading of the device spec was that these were provided internally by the EXT-ENCODER where required.

The test was run multiple times each driving the motor at higher rotation rates via increased PWM values. Each run was over a period of 20 seconds with the EXT-ENCODER pulse value sampled over the I2C bus every 200ms. The difference between the latest and previous count value was recorded.

The encoder values were computed as per the M5Stack documentation from the 4 bytes pulled from the I2C port 0x59 Register 0x10

The graph below plots the average change in pulse value for 200ms samples at each motor speed.
M5Stack_Ext_Encoder_Characteristics.png

As expected, the value returned by the EXT-ENCODER increases as the motor rotation rate rises. However it reaches a point where increased motor speed results in no further rise in the value returned by the EXT-ENCODER and instead starts to drop. Any further increases in motor speed result in the device reporting the same value repeatedly. I should add these rotation rates were fairly low.

I’m wondering if this means the rate at which the encoders were generating pulses exceeded the EXT-ENCODER’s ability to ‘catch’ them.

So my question is - what is the practical maximum pulse rate the EXT-ENCODER’s STM32F030 microcontroller can sustain and still reliably report it over the I2C bus? I’m using the SMBUS package for this.

I’ve tried both increasing and decreasing the I2C bus speed on the Raspberry Pi but this made no difference.

Another observation during these tests was that the EXT-ENCODER would very occasionally show an unexpected and sudden change in the encoder count value returned from the EXT-ENCODER. The EXT-ENCODER holds the pulse count as an unsigned 32bit integer and can be shown to accumulate counts up to the max value of 4294967295 before wrapping round back to zero (the converse happening for rotation in the opposite direction). However, these random flips of the returned count were obviously happening in the EXT-ENCODER as subsequent I2C calls continued to return values rising from the

Two examples (below) - note that the erroneous value can be either higher or lower than a previously returned value with no change in motor rotation direction.

Eg 1
Prev_val New_val
210624 211307
211307 211989
211989 212667
212667 180582 <<<<<<<<<<<
180582 181266

Eg 2
Prev_val New_val
32389 32506
32506 32622
32622 32736
32736 4294934607 <<<<<<<<<<<
4294934607 4294934720
4294934720 4294934837

Any observations welcome.
john

This sensor is surprisingly difficult to use but I still learned a lot. As suggested, I took a look at the raw data from the sensor using an M5Stack Arduino program. Although you can see the pulse data, it is very unstable, noisy and has a varying offset. Here is a very good description of what it takes to make the MAX30100 work.
https://morf.lv/implementing-pulse-oximeter-using-max30100 In addition to what the article says, the two Heart sensors I have behave differently and would require individual calibrations.