Tag: Yuyi Shen’s status report

This week, I wrapped up the circuit design for the motor controller and did the layout for the motor power supply.

Since the majority of the motor controller circuit (up to the H-bridge gate driver ICs) had been simulated in LtSpice, what remained was the design of the chain of logic gates designed to reduce the 4 individual control inputs of the H-bridge gate driver chips to a single PWM pin with an ENABLE input. This was quickly accomplished by finding a logic buffer with delay-equalized complementary outputs (the CD4041UB chip) and a quadruple AND gate for implementing the ENABLE input (SN74HC08).

However, I was unable to simulate the full motor controller circuit until very recently, as the PSPICE model I found for the logic buffer was incompatible with LtSpice (the circuit simulator I had been using to work on the motor controller). Luckily, I found that the recently free Micro-cap simulator had functional models for both digital chips, and set up the following testbench for calculating the motor controller’s overall propagation delays:

Transient simulation with a handful of rising and falling edges at the PWM and ENABLE inputs produced the following plot:

Using the top set of waveforms, I determined that the PWM input’s rising propagation delay was 1.13 ms, while the falling propagation delay was 1.11 ms. Similarly, I found that the ENABLE input’s rising propagation delay was 1.12 ms, while the falling propagation delay was 0.41 ms. This did not change much when I conducted a worst case analysis with the simulation’s logic delay models. Since these values are consistent with the timing delays I had calculated in LtSpice without the logic gates, there is little reason to doubt the accuracy of the simulation.

Since these delays are insignificant in comparison to the periods with which the equatorial mount stepper motors will be actuated (0.3 sec), we will not have to take them into account when programming the equatorial mount.

Furthermore, I’ve confirmed that the flyback diodes I selected for absorbing voltage spikes at the H-bridge output are adequate. Judging from the lower graph, the most an individual diode will experience is a current spike up to ~5 A, which is substantially lower than the diodes’ non-repetitive peak forward current rating (35 A).

Lastly, I’ve finished laying out a PCB for the stepper motors’ 3V 4A power supplies:

The layout was performed in accordance with the guidelines that were laid out in the buck converter’s datasheet, and no major current-carrying trace has a width lower than 40 mils (the width required for 4A of current to cause a maximum of 10 degrees C of temperature rise with 2 oz. of air-exposed copper). The resulting “standard cell” can be dropped into a standalone instance of PCBnew (KiCad’s layout utility) for integration with the motor controller section. As can be seen, the 3V output is available on 3 sides of the cell for ease of placement in the future. Major current-carrying traces will be exposed to air instead of being covered by solder mask.

Unfortunately, I am behind on my schedule. I have yet to make progress with selecting a gyroscope, which I’ll need to finish up next week after consulting with Kenny on the required precision. Fortunately, this involves minimal circuit design, so catching up will be fairly simple.

Next week, I’ll need to design and layout a 8V buck converter for powering the motor controller ICs, in addition to laying out the actual motor controller in KiCad. This 8V buck converter will be laid out in the same manner as the 3V power supply shown above, although it will be easier to design due to the lower current requirement. Due to this, I do not plan to provide an ENABLE input for it in the layout.

The primary concern at this stage of the design is the layout of the motor controller H-bridges. If there is too much parasitic inductance, there is a possibility that the H-bridge MOSFETs will experience a shoot-through failure condition, destroying them. I plan on including diodes in shunt with the MOSFET gate resistors so that they turn on slower than they turn off (introducing a sort of dead time into the operation of the motor controller). If this fails, I can simply find a motor controller on Digikey that satisfies our requirement.

My tasks for this week were to finish designing the circuits for the equatorial mount’s stepper motor drivers and gyroscope. To this end, I have finished designing a buck converter circuit for supplying each stepper motor with 3V (and a maximum of 4A) from the 12 V supply voltage that we’re expecting:

Furthermore, I’ve set up a bill of materials on Digikey for the design: https://www.digikey.com/short/z3w1wm. One assembly costs $8.22.

I have also specified appropriate components for the H-bridge circuits that will ultimately interface with the stepper motor coils:

The MOSFETs were selected to have an on-resistance that’s 20 times less than the stepper motor’s worst-case series resistance spec so that they wouldn’t overly impact the current drawn from the motor power supply by the stepper motor coil. Similarly, the flyback diodes were chosen to have an on-resistance that’s on the order of the stepper motor coil’s series resistance so that they could effectively dissipate voltage spikes from the coil’s inductance. Lastly, the gate driver ICs were chosen to be compatible with 3.3V logic, as the Raspberry Pi has 3.3V GPIO pins.

To confirm my component selections, I ran LtSpice simulations to gauge the power dissipated by the flyback diodes if a single lo-side or hi-side MOSFET abruptly turned off (the worst case scenario in the context of kickback voltage transients). LtSpice simulation indicates that individual flyback diodes will dissipate a worst-case value of 754 uJ over 3.2 ms if a low side MOSFET suddenly fails open while passing current from the stepper motor coil. This corresponds to a power level of 0.24 W, which is about a third of the flyback diode’s maximum power dissipation. Therefore, the diodes that were selected will likely survive normal operation.

To facilitate my teammates’ work with the Raspberry Pi, I used LtSpice to characterize the propagation delay from the voltage at the hi-side input of one of the H-bridge’s gate driver ICs to the current passing through the stepper motor (modeled here as a series RL circuit). I found that the propagation delay for a falling edge at the hi-side input of a gate driver was roughly 1.08 ms, while the propagation delay for a rising edge at the hi-side gate driver input was 1.09 ms. This is very close to the theoretical propagation delay that can be calculated from the L/R ratio of the stepper motor coil (ln(2)*time constant), 1.2 ms. This means that the MOSFETs that I selected for the H-bridge will likely be effective at driving the equatorial mount’s stepper motors.

Unfortunately, I am behind schedule. To get back on track, I’ll need to find an appropriate gyroscope for the equatorial mount and design an interface circuit, and put the finishing touches on the stepper motor driver circuit. The former should be a fairly trivial task (most sensor datasheets will have a recommended circuit for facilitating the sensor’s interface), but the latter will consist of two significant tasks: designing an 8 V switched mode power supply for the H-bridge’s gate driver ICs and developing a chain of fast logic gates to convert the 4 H-bridge inputs into a pair of inputs (one enable input and one control input).

Next week, I intend to finish the stepper motor driver circuit. Given the time it took for me to simulate the fundamental H-bridge setup in LtSpice, I estimate that this will take at least half the week. Furthermore, since I’m scheduled to begin laying out the PCBs next week, I’ll aim to finish the layout for the 3V power supply that I designed this week for the motors.

The primary risk to this objective is the development of a logic chain for transforming the H-bridge inputs into a single control input for use with the Raspberry Pi that we plan to use for controlling the equatorial mount. Propagation delays for each of the 4 H-bridge inputs will need to be matched, which is a relatively difficult task to achieve. My contingency plan is to simply omit the logic chain altogether. This approach will use up more GPIO pins on the Pi, but is more likely to function.