Recommended absolute encoders, SSI and SPI


So first of, respect for this project!
We’re looking into using the odrive for our motors but we use both an incremental and a absolute encoder which we intend to keep using, other types will be fine as well. So we are looking into absolute encoders now and we see in the encoder guide that odrive supports the AMT23 and AMT21 which, as we look into them turn out both to use the SSI protocol and not SPI of which the first is not supported by ODrive and the latter is?

What am I missing that the SSI encoder is supported but the odrive doesn’t support SSI?

SSI and SPI are very different protocols. SSI requires a differential RS422 transceiver as a bare minimum - you could add this to the ODrive, but you’d need to write your own code to interface with it and get the data from the encoder.
Probably, a transceiver could work on the I2C pins.
I’m not sure, but it’s likely that ODrive v4 will support SSI out of the box. Ask Oskar.

I think you’re confusing SSI with something else. SSI is generally just SPI without MOSI, and most of the SSI encoders that people want to use (AMT23, RLS Orbis) are single-ended, not differential.

@mart The encoder guide doesn’t necessarily show supported encoders. The AMT23 is SSI, but it has problems with tri-stating the MISO pin, so as a general rule I wouldn’t say it works without a tri-state buffer on MISO. AMT21 is RS-485 which is not supported by ODrive at all, and we have no plans for ODrive v3 compatibility it at this time. I recommend an AS5048A.

Thanks for the replies!

Isn’t it then odd that (well for someone not as experienced as me anyway) this odrive guide is confusing because it notes encoders that are not at all supported?

Thank you for the suggestion @Wetmelon! I will look into that

Hmm. Well, for a start SSI is usually not tri-stated at all. It is point-to-point and doesn’t have a CS wire, in my experience at least. So you can’t have more than one slave device, like you can with SPI.
And of course, there is no ‘register map’ since it’s a unidirectional protocol. It always transmits the same buffer, over and over again, and different encoders and manufacturers differ on its layout. You have to RTFM to know what that buffer means, there’s no standard.
BiSS, by contrast, is much nicer than SSI because it is bidirectional and a bit more of a well-defined standard, so the encoder can tell you a bit about itself, so it’s possible to write code that should work for any BiSS encoder.