Step / Direction


I’ve been experimenting with GPIO EXTI as well and found it rather noisy. I’ve had a button hooked to one of the gpio pins and it would falsely trigger input sometimes - occurring more at higher speeds.

I think shorter cables or twisted pairs might help?


Here is a little more info on my step/dir adventure. I have been using the gnd from the J2 connector and it does act quite a bit better but still getting extra steps. I have put the controller (a leafboy 77 also known as AKZ250 USB card for Mach3 and am using Mach3 to control that). as close as I can get. Actually the M1 pins (gpio 3 and 4) act a little better than the M0 pins 1 and 2. I have routed my encoder wires and motor wires as well as I can. I am not sure what to try next but I’ll be sure to let you know.


In response to srk. Shorter cables are always a good idea but I don’t think that will help in this case. As far as twisted pair, that won’t help either because it is not a differential signal. My encoder cables are shielded but the shield is floating. I have huge motors so I am going to try and get them as far away from the board as I can.


Do you have access to an oscilloscope? If so, can you please make a measurement of the step pin(s) with the J2 GND as reference?


There is an electrical issue on ODrive that we uncovered, with significant help from @Bart’s testing.

For now it means you shouldn’t use J3’s GND, but instead J2’s GND when using step/dir.

Please see this topic:

Grounding issue on the left side of the board

Hi, I have a 3.4 ODrive and I’m having a problem getting Step / Direction working.

I’ve had the ODrive working in Velocity Control, both sensorless and with encoder and also in Position Control and now want to utilise the Step and Direction mode.

Firstly, I set the ODrive up to work in Position Control mode, verified that, then set the compile time parameters CONFIG_UART_PROTOCOL to none and CONFIG_STEP_DIR to y in tup.config. Ran make in the firmware folder and make dfu in the tools folder and the processor erased and flashed the firmware ok.

Restarted the ODrive, it goes through its calibration routine, a bleep then turning one way then the other, then stops.

Now, If I GND both the Step and Dir inputs, the motor turns at a fixed velocity, I put a scope probe on the grounded input Step and there is a regular pulse spike occuring every 60uS.


Little more info, when ERROR_DRV_FAULT occurs and the motor is de-enegised, the periodic spikes disappear.

I’ve got a v3.4 48volt version which looks a bit different, I’ll flash that tomorrow and retry.


Yes it’s very easy to have noise couple into the step/dir signals. ODrive v3.5 has some RC filters on the inputs to help mitigate this. On v3.4 I had good results when soldering in some RC filters, though it was a bit fiddly to get the capacitors into place. I used 330 ohm and 4.7nF. Here are some pictures of what I did:

I had some passive breakout boards that made it really convenient to insert the series resistors. If you don’t have this, you can just use through hole resistors. You can also see where I soldered in the capacitors next to the ARM chip.

I decided that it was more convenient and likely to yeild the best results for me to put the capacitors as close to the ARM chip as possible, connected directly to the GND that feeds it. You can see the GND is the upper of the thick top (red) traces if you zoom in the picture.

I scraped off the solder mask and used long solder blobs to reach across to get connections I wanted.

If you think it is too fiddly for you to install the capacitors the way I did, you can try to have them be external right at the J3 connector.


Thank you Oskar for your quick reply and fix, I’ll implement that mod and report back. Cheers.


Excellent, That’s fixed it. Thank you Oskar.


I’m having problems with Step and Direction mode picking up extra steps. The Step input seems to be sensitive to interference. I’ve played around with different values on the RC network, but can’t eradicate it totally.
My ODrive is within 15cm of the motor which I think maybe the source, so I’m going to try extending the motor and encoder wires.
I was also wondering if a configurable software dead time to the Step input could be possible, to ignore pulses less than a certain width?


Extending the distance of the ODrive to the motor to just over a metre didnt help.

In the interrupt routine for the Step input, I was thinking of inserting a short delay, then checking the status of that input and if it was still high, then perform the step, otherwise dismiss it as a false input and return without doing anything. Can you see any problem with doing that?


I’ll chime in here, and I really don’t know about odrive, but I would hesitate ever solving a hardware issue with a software patch of sorts. Creating a check is fine unless you are doing it as a solution to ignore a constant unknown problem. My experience has been this method, while easier, has a high chance of compounding the problem at high speeds or in even noisier environments. Even the resources allocated to the check itself can become a problem down the road. Grounding, shielding and understanding component isolation are a better direction in this case. Software should only come after the hardware is solid or you risk redesign at a painfully late stage. My 2c.

I don’t want to insult you so ignore if you’re past this, but twisted wire pairs solves a lot of these issues and often gets overlooked. Good luck.