the voltage was crap - I replaced one of the batteries and now the power is solid.

The motors still wouldn’t calibrate, i was getting phase inductance out of range error on the motor calibration. As I see in the code the values were commented as arbitrary, I commented that test out in the firmware and now axis0 calibrates fine, the encoder calibrates, and the motor runs fine. Axis1 however, I’m getting this with encoder calibration:

In [52]: odrv0.axis1.encoder
error = 0x0010 (int)
is_ready = False (bool)
index_found = False (bool)
shadow_count = 86 (int)
count_in_cpr = 86 (int)
offset = 0 (int)
interpolation = 0.5 (float)
phase = 2.6179871559143066 (float)
pos_estimate = 86.02304077148438 (float)
pos_cpr = 86.02426147460938 (float)
hall_state = 1 (int)
pll_vel = 0.0 (float)
  mode = 1 (int)
  use_index = False (bool)
  pre_calibrated = False (bool)
  idx_search_speed = 10.0 (float)
  cpr = 90 (int)
  offset = 0 (int)
  offset_float = 0.0 (float)
  bandwidth = 100.0 (float)
  calib_range = 0.019999999552965164 (float)

if i plug the motor and encoder into axis0 it calibrates and runs fine…

You have encoder error ERROR_ILLEGAL_HALL_STATE = 0x10. This means that all hall signals are 0 or all are 1: this is not allowed and means something is wrong with the hall feedback. Please check your wiring and if it looks good, please double check behaviour with an oscilloscope or logic analyzer.

OK I connected my new fancypants oscilloscope probes inline with the signal wires from the hall effect sensor and the board, this is what i see when rotating the wheel

looks ok :\

am I right that there is a direct trace on the board from the hall effect sensor sockets to the chip? Is there somewhere else i can probe to troubleshoot?

Probing R32, R33, and R34 shows the same result. The same wheel (and different wheels i can replicate with) calibrate and work on M0 so i think they are fine

Nice scope!

I agree, those signals look fine. Yeah it’s a direct signal, so probing at the wires should be fine.
I don’t have any clue why it should work on M0 and not M1. Maybe a loose wire right when you were testing on M1?

To be completely sure, you can set up your oscilloscope to trigger mode “pattern” and look for “LLLX”, set the trigger level to 1.6V. Then power cycle the ODrive, then activate single trigger mode, and then run the calibration.

1 Like

OK, brand new board, brand new set of hoverboard wheels.

exact same thing, encoder error 0x0010 - both wheels work fine on axis0 but not on axis1, with the exact same commands and wiring


Were you able to use the oscilloscope in pattern mode to check?

I was helping a client today and we also got ERROR_ILLEGAL_HALL_STATE on M1, it only happens when M0 was also running. We use the oscilloscope to track down the issue: We think it’s switching noise of M0 was coupling to M1 encoders. We think it’s the the switching noise from the motor capacitively coupling from the motor to the frame, then conducting through the frame to the other motor, and coupling to that encoder.

We fixed it by soldering some 47nF capacitors from the hall signals to GND to filter it out, as per this photo (after testing I’d say maybe around 22nF would be better):

I think having filtering capacitors for these kinds of hall sensors is probably a good idea in general, since they are driven quite weakly and have a strongly coupled GND to the motor phases. For ODrive v4 I will try to have space for optional hall filter components.


Thanks for this, I used 22nf capacitors and it solved the problem!

1 Like

I also have this problem with odrive 3.4v with hoverboard.
Will try the caps.
Does this also happen with 3.5V?

Mine was 3.5 48v with hoverboard.

After googling around and checking different kind of hall sensor.
It seems that most of them you need around 10K pull resistor. In the schematics we do not have a pullup resistor for the ABZ encoder. I presume we are using the builtin pullup of the stm. Based on the datasheet these are typical 40K. Maybe this is the problem. The hall sink current is weak which also result in a weak signal that can get noise easy.

Anyone know where in the code I can disable the internal pull up so I can connect an external pull up on the encoder inputs.

We do have 3k3 pullups:

Opes I missed that. Learn a lesson: Do not fix problems at 2:00 AM Thanks for the reply.

I just ran into this same problem. Axis1 would not work with my hub motors with the encoder throwing a 0x0010 error. I tried the suggested fix, soldering 22nF capacitors across the encoder inputs for M1 and it fixed the problem.

I then ran into a related problem where on one of my two Odrives axis0.encoder would throw a 0x0010 error the first time it dropped back to zero rpm. I tried the capacitor mod on the M0 encoder inputs and it seems to have also fixed that problem. So it appears hall encoder noise issues are not limited to the M1 inputs.

Might be worth mentioning this gothca on the hoverboard getting started page.


We fixed it by soldering some 47nF capacitors from the hall signals to GND to filter it out, as per this photo (after testing I’d say maybe around 22nF would be better)

I’m trying to replicate this on my newest oDrive. So I don’t make a mistake, can you help me recall what exact pins each capacitor is connected between, @madcowswe? Thank you!

1 Like

The connections are:

Lead 1 Lead 2

I’m having the exact same issue but adding the capacitors doesn’t fix the problem (it fixed it on M1 but not M0). I’m using decently long leads to perhaps that is the cause. Would switching the shielded cables help?

Also the encoder.pos_estimate is reported correctly even when the error is thrown. Perhaps there is a way to solve it in software?

What value capacitors did you put, and where did you put them? Can we see a picture?

Yes, I’m going to post a picture when I get back to lab today.

They are 47nF capacitors. Currently added them using a breadboard (between ground and the ABZ pins)