Configured absolute encoder per official documentation. absolute_setpoints → CLOSED_LOOP_CONTROL worked correctly for a period of time, then the issue suddenly began occurring.
Problem
When DC (24V) is applied, the SPI encoder fails to initialize:
spi_encoder0.raw = 0
pos_vel_mapper.pos_abs = NaN
spi_encoder0.errorkeeps incrementing
NaN persists regardless of how long I wait after DC power-up
The only workaround found: disconnect and reconnect USB once → SPI communication recovers and pos_estimate reads correctly → then applying DC power afterward allows normal motor operation.
Questions
Is there a known issue where the SPI interface fails to initialize properly during DC-only boot on ODrive Pro?
Is there a way to force SPI re-initialization after boot (e.g., via odrivetool command or config flag)?
Is there a recommended power-up sequence or startup delay for BiSS-C encoders powered from the SPI connector?
Interesting – haven’t heard of this issue before. Should just start up / work while powered. What does spi_encoder0.status and spi_encoder0.warning return? Does it work when only connected over USB / no DC voltage applied?
Thanks for the response. Unfortunately, development on this system was paused due to other priorities, so I wasn’t able to run the specific tests you suggested.
Partial answers to your questions
I did check spi_encoder0.status and related SPI status fields at the time. Based on those readings, I concluded that the encoder was not completing initialization. I don’t remember the exact values, but that observation was consistent with the symptoms.
I also tried rebooting ODrive via CAN Command ID 0x16, but it didn’t consistently resolve the issue:
worked occasionally but failed most of the time
I’m not sure whether I tried Command ID 0x18 (clear errors) — I plan to test this when I get the chance and will update the thread with the results…
Root cause — identified via a different controller
In the meantime, I encountered the exact same issue on a different controller (Everest XCR) using the same encoder, which helped me identify the root cause.
Encoder: RoboDrive RD50 (TQ-RD50 AksIM series) — not a generic AksIM
This violates the encoder’s expected initialization sequence
Results in silent initialization failure → raw = 0, pos_abs = NaN, errors continuously incrementing
Workaround (on Everest XCR)
Used the CoE (CANopen over EtherCAT) vendor-specific object 0x217c (Set feedback power supply status) to disable and re-enable the controller’s I/O power during startup — effectively power-cycling the encoder after the controller had fully initialized.
This has resolved the issue completely with no recurrence since.
Conclusion
I’ve used other BiSS-C absolute encoders without ever encountering this problem
Root cause is likely insufficient tolerance in the RD50’s circuit or firmware for CLK-before-VDD power sequencing
Choosing a more robust encoder is the best long-term solution
That said, it would be very helpful if ODrive provided a way to toggle the SPI connector’s I/O power via firmware or hardware — similar to what 0x217c offers on the Everest XCR. This would allow recovery from encoder initialization failures without requiring a USB reconnect.
Unfortunately there’s nothing equivalent to the Everest’s 0x217c on the Pro. The 5V/3.3V on the feedback connector is always on with no switch in front of it, so there’s no way to power cycle the encoder from firmware, and a soft reboot (CAN 0x16 or odrv0.reboot()) will also not cause the encoder to lose power. One workaround would be a small high-side load switch between the ODrive’s 5V and the encoder’s VDD, with an RC on the EN pin. You could also drive the EN pin from a GPIO on the Pro, so you can toggle it on demand. This could also be easily done with a small PFET or similar.
Though I agree, maybe just finding a better BiSS-C encoder would be easier it’s always crazy to me how much difference there can be between devices that supposedly all follow the same standard, haha.
it’s always crazy to me how much difference there can be between devices that supposedly all follow the same standard, haha.