Issues with AMT232b-V encoder

We tried to connect only one AMT232b-V encoder to Odrive 3.6-56v with firmware fw-v0.5.1 and got the following errors in encoder.config.mode = 256:

  1. when Odrive is turned on and AMT232b-V is connected, the Motor::DRV8301_setup() -> DRV8301_enable() function hangs.
    The state of the CS pin (4) connected to the encoder is currently 1

  2. if you disable MISO AMT232b-V the hang-up in the Motor::DRV8301_setup() -> DRV8301_enable() function will not occur.
    If you turn on the Odrive with the encoder disconnected from the MISO to avoid hanging and then connect the MISO, then when entering the AXIS_STATE_MOTOR_CALIBRATION mode, the ABS_SPI_COM_FAIL encoder error occurs.
    We have separately checked that the data from the encoder is received via SPI and the encoder is working and transmitting data successfully.

Thus, we could not use the AMT232b-V with Odrive.
Perhaps you will comment on this situation.

Maybe we should check if MISO turns to the third state (HI-Z) when CS=1 ?
Recommendations for using the tristate buffer (74AHC1G125S) extends to a situation where only one AMT232 is connected?
Perhaps in future ODrive versions it is a good idea to have a separate SPI for encoders
because we have often encountered similar conflicts between motors and encoders tied to the same SPI bus

We would be very grateful for your help

Yes, usage of the AMT232b-V encoder requires either a tristate buffer or sequencing power to the encoder after DRV setup has finished.


We connected the encoder via a buffer controlled by the CS signal, after that the initialization of the motor drivers is successful.
We use a non-inverting buffer 74AHC1G125SE. Here’s the buffer and encoder connection diagram

We use a proprietary AMT-06C-1-036 cable for AMT232b-V but on the first connection we did not connect the shield of the cable to GND and when we started AXIS_STATE_MOTOR_CALIBRATION there was an ABS_SPI_COM_FAIL error.

When we connected the cable shield of AMT-06C-1-036 to GND of odrive, the calibration processes AXIS_STATE_MOTOR_CALIBRATION and AXIS_STATE_ENCODER_OFFSET_CALIBRATION became successful,
but on the spi_error_rate chart there are peaks, but within acceptable limits.
The graph is shown in the figure below.

When trying to run AXIS_STATE_CLOSED_LOOP_CONTROL after this, spi_error_rate immediately starts to grow up to 1 and an ABS_SPI_COM_FAIL error occurs.
The graph is shown in the figure below.

We don’t know how to check if it is related to interfering signals or if there is a conflict inside the driver, but we have checked that in the AXIS_STATE_MOTOR_CALIBRATION state, MISO of Odrive is always in 3-state when the encoder’s MISO is disconnected.

To check for SPI bus conflicts, we set breakpoint before the SPI request and pull MISO to 3.3V or GND with a resistor, disconnecting the MISO of the encoder. Then we put a breakpoint in the callback of the encoder and then we watched the content of the received message (0xffff or 0x0000 if no conflict).

However, CLOSED_LOOP_CONTROL did not work in Debug assembly because it did not keep up with the timings. Therefore we did not have the possibility to check if there were any conflicts on the SPI bus in this way.

What way of debugging would you recommend to determine if there are any conflicts in this case?
What can we do to get out of this situation and what is it related to?

1 Like

It’s probably noise. I and others have solved this with differential encoder adapters.

Thank you, it all worked out.

1 Like