AASD-15A CN2/DB25 wiring question

Hi all,

I've been looking at the various wiring diagrams for @Motion4Sim , @Thanos, @Lebois, @knaufinator and SFX100 and noticed that some hook up the Step+ and Dir+ pins to 5v with the Step- and Dir- being connected to the controller pins, whereas others do it the other way around (so Step+ and Dir+ to the controller pins with Step- and Dir- to GND).

I was wondering if someone could explain the pros and cons of each approach.

Thanks!

I don’t think it matters for the clock. It will invert the direction. Aka high is CW low is CCW. Then again there are lots of ways to run a motor in the wrong direction. So you find invert direction software switch’s here and there.

For my own personal hardware I use differential drivers to increase noise immunity. It’s very easy to trigger transitions in a 5v high speed pulse counter with noise. AC servos tend to generate plenty of noise. YMMV.

Thanks for your reply. What do you mean that it doesn't matter 'for the clock'?

Also, I've been wondering about differential drivers - how do you implement them? Is it done natively on the Arduino or do you use external chips for that?

Also this Wikipedia article suggests that differential signalling doesn't actually help with noise cancellation but that balanced lines will (and that article shows a circuit diagram with one end connected to ground rather than +ve). Does your experience suggest otherwise?

The “clock” here refers to the pulse train that drives motion—essentially a frequency signal. Whether you wire Step+/Step– one way or the other, the frequency remains the same. What changes is polarity, which affects direction: high might mean CW, low CCW, depending on how your controller interprets it. But since most setups offer a software “invert direction” toggle, the wiring polarity doesn’t fundamentally affect motion timing—just the interpretation of direction.

As for differential signaling: I use external chips. TI makes DIP-format differential drivers and receivers that are breadboard-friendly. I use the AM26LS31 (driver) and AM26LS32 (receiver) to connect the DB44 from my servo amp to a Teensy. It’s not native to Arduino—you need the external hardware.

Regarding noise: maybe “noise immunity” isn’t the textbook term, but differential signaling does help reject common-mode noise, especially in environments with high EMF like AC servos. Balanced lines are part of that equation—Wikipedia’s right that the physical layout matters. But in practice, I’ve found differential signaling to be a meaningful improvement.

Early on, I used differential receivers for the quadrature encoder signals from my AC servo. That worked well. For pulse signals, I initially just leveled them to 5V and grounded the negative side. It worked—until I noticed drift.

Last month, with the motor mechanically disconnected, I saw it slowly drifting. Once it left the dead zone, it snapped back to the correct position. That told me the encoder was fine, but the pulse signal was noisy enough to cause phantom steps. Unplugging the wire stopped the drift—pretty strong evidence of noise intrusion.

I’m now installing differential drivers for both pulse and direction. If that eliminates the drift, I’ll have confirmed the issue. But of course, your setup might behave differently—depends on your wiring, grounding, and local EMF conditions.

Thank you - that's a very clear answer! Understood on the clock point and on the differential signals. Seems like most people with the AASDs and Arduino don't take this approach so I'll go down the same route for now until I hit any problems.

I don't have a motion rig setup just yet but I do have a static cockpit and the AASD-15A controllers with 80ST-M02430 motors here along with all the other bits and bobs ready for assembly. I'm trying to make sure I lay everything out correctly to reduce the risk of EMI and ground loops in the system, plus I'm going to have a go at building and coding my own 'serial to servo' controller, hence the questions about connecting to Arduino...

On the topic of ground loops, @Thanos mentioned in another thread that a way to eliminate them was to not "wire the DB25 shield on the same ground as the USB" and I was wondering how you do that - what do you connect the DB25 shield to instead?

Also, does that mean that the GND connection you make between the Arduino and the servo controller should not be tied to the USB ground on the Arduino? If so then how do you avoid doing that (I believe the USB ground is tied to the GND pin of the Arduino on the PCB)? This thread provides some answers but seems over the top and I was wondering if there's a simpler solution.

Another suggestion (again from @Thanos) is to use a common ground for the PC and servos behind a line filter. I have built power box just like Thanos' with the same components (including line filter) which should hopefully eliminate some EMI, and I ordered the shielded cables for the servos, as I also did for my DB25 cables. I'm reluctant to run my PC and my servos through the same multibar though because in the UK the max fuse on a household plug is 13A (which at 230V is ~3kW) and 6 x 750W servos could in theory draw 4.5kW plus my PC with high-end GFX can draw a further 500-700W which could trip the fuse.

My current plan is to run the PC through one socket and the servos through another (with the servos on the 'shielded' side of the EMI filter, but the PC won't be shielded at all). Will this be enough? The grounds will be tied in the fuse box on the wall (there will be about 4m of wire from the PC to the fuse box and about 8m from the the servos to the same fuse box) but I wasn't sure if that setup could still create a ground loop. Do I need to connect the earths of the two multibars (or is this essentially done in the fuse box and therefore unnecessary)?

Sorry for all the questions but I want to try to get this right first time. Thanks again for any guidance you can provide!

It’s raining, so I got motivated to tinker in the shop. Right now, I’m using my shop computer and everything’s plugged into the same circuit. But for the full rig, I’m in the US and will be running a dedicated 240V circuit for the servos. In the shop, I’ve got a step-up transformer and just one motor.

So what happens when you connect to two different AC circuits? I dug into this, and it turns out the standard practice is to connect the shield at only one end. It acts as a Faraday cage—shunting EMI to ground without creating a loop.

When I looked at the wiring diagram for the servo, it clearly shows the shield tied to chassis ground on the servo side. That tells me you don’t connect it on the controller side. Leaving it floating avoids the risk of ground loops, especially when your PC and servos are on separate circuits.

I thought the DB shield was tied to 5V ground—but turns out it had fallen off the dev connector. Reconnecting it noticeably reduced noise. After repeatedly shooting myself in the foot, I finally got the differential signal working, and that helped even more. In the context of common grounds it is of note that there is no "ground" on a differeential signal. So there is some isolation there.

Here’s how I measured the impact: I watched the internal position display on the servo and hit a stopwatch every time it rolled over 1000 counts. (It’s 10,000 counts per revolution.)

• No ground or differential: 800ms/1000
• Just ground: 1500ms/1000
• Ground + differential: 4000ms/1000

Now the drift is barely visible. Before, it was obvious. YMMV. Since I close the loop, it’s less critical—but if you’re running pulse counts open-loop, that drift will accumulate. I will leave the ground disconnected for now.

I haven’t added decoupling capacitors yet to the differential driver. In theory, I should be able to feed 3.3V directly into the differential driver, but when I do, the noise gets worse.

I’m using a Teensy 4.0, which runs at 3.3V supplied via USB. The 3.3V and 5V grounds are tied together. The Teensy 4.1 has hardware Ethernet, which would be a great way to isolate grounds—i.e., no USB connection. An ESP32 could also work. I chose the Teensy for its FlexPWM and hardware quadrature decoding (no interrupts). It’s got enough horsepower for all six axes. For my setup with encoders and limit switches, the limiting factor is I/O pins. The 4.1 gives you more.

My first drift axis attempt destroyed a worm gear in under an hour—those motors were junk. I switched to a ball screw and a 1kW DC motor, but struggled with that too. Eventually I gave up and moved to AC servos, which are surprisingly affordable now. I’m nearly ready to see what breaks when I attach it to the rig.

Sounds like we’re pretty well synced . I’ve got working single axis software, and the closed-loop vs open-loop logic is fairly isolated. I even have a parameter that selects the control algorithm. In general, a blend of velocity control and PID works best. I also have a velocity-only mode that’s very smooth, but it doesn’t control the acceleration curves at all.

Feel free to PM me if you want to discuss the software details. It should run on other platforms, but I rely on having two serial ports—one for debug, one for PC comms. The Teensy’s USB interface supports multiple virtual serial ports over a single connection, which is super handy.

Ok, looks like you're making progress. Well noted on the point about only connecting one end of the shielding to the servo and not the other, I'll make sure I do that when hooking everything up.

I have thought about using an ESP32, which is what @knaufinator uses in his setup. This is appealing for two reasons: firstly it's a much faster MP with more ports and two cores so you can run separate threads for servo control and serial input/interface and secondly he's been looking at using the RMT (remote control) functionality on that platform that should allow for much faster PWM signals. The new branch of his code (phoenix) implements this but he notes it's untested for now.

The downside is that they're 3.3v pins so would need to add level shifters, and fast ones at that. Also the micro USB connectors on both of my ESP32 dev boards have come off and I buggered one up trying to re-attach it so need to order more, which means I can't use them right now without hooking up a serial breakout board and I couldn't be bothered to do that.

So for now, for testing, I'm using an Arduino nano and just playing around with one servo. I have also set up software serial for feedback, as you suggest.

In terms of the software side, I'll be using FlyPT Mover to send axis position data to the Arduino. My understanding was that this handles all of the mixing, spike filtering, motion smoothing, PID, motion limiting etc. so we just need to get the Arduino to move the axis to the position sent by FlyPT Mover.

However this got me thinking about how the Arduino code actually works and I'm not sure I fully understand. I think what happens is that FlyPT sends position data roughly every 2ms (about 500Hz) and in between each position datapoint the Arduino is sending hundreds of commands to the servo to move to the last received position, then it sends commands to move to the new position (when that one comes in) and so on so it's forever 'chasing' the target. What I don't get is how any smoothing or accel/decel ramping handles this constant target shifting in the Arduino, or does it just not matter?

Lastly, I was playing around with ChatGPT to see if it could write me some code to do all these things and I have to say I've been pretty impressed with what it's come up with in 15 minutes. Full code using hardware timers, trapezoidal acceleration/deceleration ramping, homing, park, e-stop (with rate limited resume), spike filtering and position reporting back on software serial. I started out asking it for some simple functionality (i.e. control a servo with pulse/dir based on 16 bit data received over serial) and then it suggested some features and I told it to add some specific features and it looks quite good. Still need to test it so if it works I'll post it here.

One other thing I asked it was my original question about why some people use positive referencing and others use negative on the pulse/dir lines and which is best. Here was its response:



So basically positive referencing (as @Motion4Sim and @knaufinator use) is better. So now you know!

I don’t know much about FlyPT—I’m using SimTools 3, with about 95% racing and 5% flight. One thing I’ve noticed is that AC servos behave very differently from stepper motors. If you command a servo to move 10,000 counts, it’ll only do that reliably if you apply proper acceleration control. If you try to push it to 3,000 RPM without ramping, it might only make it to 7,000 counts before falling short.

Just to clarify—my setup is calibrated at 10,000 counts per revolution, and each revolution equals 5 mm of travel. That means each count is 0.0005 mm. So if you lose 300 counts in a move, that’s only 0.15 mm—not a big deal. But if that happens 1,000 times, you’ve drifted 15 mm. Typically, there is a way to display error counts on the front panel.

That’s why acceleration control matters. AC servos won’t hit a target position reliably at high RPM unless you ramp properly. Without it, they’ll undershoot—sometimes by thousands of counts. If you’re running open-loop, that error accumulates fast.

So I am setting next to my setup noticeing that it is drifting alot with the ground disconnected and differential output. I think that the rate of drift depends more on which way a wire is bent vs differential sending. My breadboard is a bit of a hot mess.