Using BiSS Encoders

Hello Fellow ODrivers,

My team is thinking of using the AksIM-2 BiSS encoder for our next ODrive project. I wanted to know if there are any tips/tricks you recommend before we start.

We plan on using the ODrive Pro for this. We saw that this particular encoder is experimentally supported and wanted to reach out and see if we can get a head start.

I attached a pic of the encoder configuration for anyone interested.

Hi! Shouldn’t be any issue at all. People have used this exact encoder before.

Hello ODrive team,

Before ordering ODrive Pro drives, we would like to confirm compatibility with our encoder.

ENCODER (already purchased, cannot be changed)

  • Model: Mosrac C90140A200112S, inductive absolute, single-turn
  • Interface: SSI over RS-422 (differential CLK+/CLK-, DATA+/DATA-)
  • Resolution: 20-bit, binary code, MSB first
  • Clock: idle high, 0.5-5 MHz; position latched on the first falling edge
  • Pause / monoflop time: > 25 us; max request rate 30 kHz
  • Supply: 12V (from an external DC-DC converter)
  • Datasheet attached

MOTORS: Mosrac U20035 and U16035 frameless torque motors (48V, 20 pole pairs)

QUESTIONS

  1. On your forum, you mentioned that SSI is not officially supported, but SSI encoders may work in SPI encoder mode set to RLS or MA732. For this 20-bit RS-422 SSI encoder, which mode do you recommend?
  2. Is this wiring correct: CLK+/CLK- to G0+/G0-, DATA+/DATA- to G18+/G18-, G17 not connected?
  3. In these modes, what SPI clock frequency, clock polarity and phase does the Pro use? Will it match this encoder’s SSI timing?
  4. The encoder sends 20 bits. Will the Pro correctly read the top 16 bits, or could the bits be shifted or misaligned?
  5. Is there any way to configure a custom SSI bit length (e.g. 20 bits), similar to biss_c_bits for BiSS-C? Are there plans for official SSI support?
  6. Is it OK to power the encoder from an external 12V supply, with its GND connected to the J8 feedback GND?
  7. Is a 120 ohm termination needed on the G18 data input, or is it built in?
  8. Has anyone tested a similar RS-422 SSI encoder (e.g. Netzer VLP-80) with the ODrive Pro? Any known issues?
  9. If the SSI read works, will future firmware updates keep this mode working, or should we stay on a fixed firmware version?

We plan to order two ODrive Pro units once compatibility is confirmed.

Thank you for your help.

Hi!

I’ll go through this one-by-one:

On your forum, you mentioned that SSI is not officially supported, but SSI encoders may work in SPI encoder mode set to RLS or MA732. For this 20-bit RS-422 SSI encoder, which mode do you recommend?

We currently (as of firmware v0.6.12) do support some encoders over SSI: Supported Motors/Encoders — ODrive Documentation 0.6.12 documentation

It’s generally not difficult to add additional encoders, so as long as there isn’t ‘weirdness’ in the SSI protocol, the vast majority are compatible. The main issue is that (unlike BiSS-C), SSI isn’t a standardized protocol – two SSI encoders aren’t necessarily guaranteed to report the angle data in the same format, have the same parity (if any), have the same error/warning/test bit locations, etc. That being said, a good number of encoders have similar frame structures, so sometimes you can just use the same protocol as another encoder.

In the case of this MOSRAC, it seems it’s a very very trivial SSI protocol, identical to the Netzer VLP-80, so you should just be able to use the SpiEncoderMode.NETZER_VLP80 protocol with singleturn_bits set to 20. I have a side project to add support for generic SSI encoders – once that lands you’ll be able to specify e.g. SpiEncoderMode.SSI_GENERIC and then set singleturn_bits.

Is this wiring correct: CLK+/CLK- to G0+/G0-, DATA+/DATA- to G18+/G18-, G17 not connected?

Yep!

In these modes, what SPI clock frequency, clock polarity and phase does the Pro use? Will it match this encoder’s SSI timing?

SSI encoders typically use SPI mode 2 (clock polarity high, first edge sampling), which is also what the VLP80 mode uses. The frequency is (off the top of my head) 1.5625MHz by default, which you can change: ODrive API Reference — ODrive Documentation 0.6.12 documentation (though not much reason to do so for this encoder)

The encoder sends 20 bits. Will the Pro correctly read the top 16 bits, or could the bits be shifted or misaligned?

It’ll read 32-bits then only keep the top 20 (or at least however many you set singleturn_bits to). Typically SSI encoders are good at ignoring extra clock signals – I haven’t heard of an issue with MOSRAC encoders.

Is there any way to configure a custom SSI bit length (e.g. 20 bits), similar to biss_c_bits for BiSS-C? Are there plans for official SSI support?

Addressed above, but tldr (1) SSI isn’t a ‘real’ / formally-defined protocol, so it’s hard to add something that encompasses everything, but yes I plan on having a generic mode for arbitrary-bitwidth ‘simple’ SSI encoders (no parity/warn/err bits), which the MOSRAC would fall under. Realistically since the VLP80 is one of those ‘simple’ SSI encoders, it would be the same as the VLP80 mode but under another name :slight_smile: . And yep, today you can change singleturn_bits for the VLP80 mode, which you’d want to do here.

Is it OK to power the encoder from an external 12V supply, with its GND connected to the J8 feedback GND?

Hmm. That’s more tricky. If your 12V supply isn’t isolated, then you’ll create a ground loop. So I certainly would not, unless you’re using an isolated 12V supply. I’m curious though – why not just power off the Pro’s 5V? The MOSRAC’s datasheet says it supports 5-30V supply voltage, and I’m sure the majority of their customers uses 5V (as well as everyone I’ve seen use a MOSRAC with an ODrive).

Is a 120 ohm termination needed on the G18 data input, or is it built in?

Not needed – built in on the Pro.

Has anyone tested a similar RS-422 SSI encoder (e.g. Netzer VLP-80) with the ODrive Pro? Any known issues?

Yep :slight_smile: we have customers using them in the field. Haven’t heard of any issues!

If the SSI read works, will future firmware updates keep this mode working, or should we stay on a fixed firmware version?

Chances are we’ll add a GENERIC_SSI mode, but I don’t anticipate us removing the VLP80 mode. If we do, then it would be a simple API change, and functionality would be the same (just VLP80 → GENERIC_SSI, keeping singleturn_bits the same).