final project -- weekly assignments -- about me -- fab academy

Week 12: That Gearbox Doesn't Sound Healthy...

Output Devices... As LEDs are boring and I need to drive DC motors for my final project, I decided to implement the first step of DC motor control: Setting the motor voltage. A common way to do that is by using PWM - Pulse Width Modulation, switching the voltage on and off quick enough so the user (hopefully) will not notice. In Theory, you can get near-DC results with the right filtering... In Practice, that is rarely done and often not sensible.

I do have a board with a dsPIC on it and a 6A full bridge, I built two of them before to put them into standard RC servos, and I want to use their basic schematic for my final project. The one I used is already stuffed into one of the cheapest servos I could find:

Those three little squares near the motor form the H-Bridge - Each of those is a pack of two MOSFETs, adding up to two half bridges like this one:

I will not put the full schematic of that board on here - Not because I don't want to share, but because it has a fatal error that I do not want anyone to accidentally copy.

dsPIC PWM Basics

Contrary to their 8 Bit counterparts, the 16 Bit PICs have PWM modules that are so packed with features you have to read a serious amount of documentation to get at them (30 pages of register descriptions...?!?). Luckily, to simply drive a DC motor I will not need most of them, and can leave a lot of configuration stuff alone.

As a first basic principle, all PWM modules are synchronized by a master time base unless you explicitly configure them not to be. That has its advantages driving multi-phase inverters, but makes all those shiny overview schematics a holy mess. I just used a more or less standard configuration from the datasheet here, with an auxiliary clock derived from the internal RC oscillator, running at roughly 118MHz. That sounds like a lot, but actually isn't - To get 16 bits of resolution, the PWM has to count up 65536 steps, breaking that fast clock down to a mere 2kHz. Most humans can hear 2kHz really fine, which is why that fast clock is multiplied by 8 internally.

For this week, I intentionally slowed down the PWM module for a bunch of reasons. First, Transistors don't switch instantly. While switching, they burn power and heat up, which is why high switching frequencies can result in a lot of heat, which is not something I want to have on a completely untested board. Second, a low PWM frequency gives me the advantage of actually hearing what happens, so if strange stuff happens I might instantly know more. Third, classic DC motors tend to get stuck at low resulting voltages and high PWM frequencies, so that's another source of errors I don't want to have now.

A nice feature of the PWM module is automatic dead-time generation. Again, Transistors don't switch instantly, so you have to wait for one to actually turn off before turning on the other one. That waiting time can be configured and will be added automatically... For this week, I set it to an insanely long time just to be safe.

PWM resolution (and Frequency) also result from the amount of timer ticks you count. I reduced the resolution to 15 bits, more from a hunch than anything else. It allows me to store the voltage level as well as the polarity in a single integer, which is nice.

What You Don't See...

... makes you scream. There is one feature that is, contrary to everything else, enabled after a reset. A feature I don't need, don't want and didn't even think about: The inputs for an external overcurrent protection circuit. Thanks, microchip, it only took me two interesting hours of yak shaving debugging to find that one.

Results

With a bit of playing around and some really ugly delays...:

It really sounds awesome awful. Cheap stuff, those gears...

As always, the sources are ready for downloading.

Another Board

Since someone had the idea that I have to make a milled board for this assignment, I milled a board. First, of course, was designing a board (so it can be sensibly milled). I worked on the basis of the motorboard (so I can keep the software), but switched to cases that are a lot less work to solder on milled boards. For this board, I reduced the motorboard to the PIC (it's the same dsPIC, just a different case), the same H-Bridge (in a different case) and a single status-LED. I did connect the current sensing (with a simpler filter, though) in case I actually reuse that board for software tests later on.

The layout is kind of a quick job, and could be way smaller in general. The DRV8801 theoretically needs some PCB area as it's cooled through the PCB, but I'm not really putting any load on it with the small geared motor - something around 100mA. So, I just put the components down as they fit, aiming for a width of roughly 25mm as I have shrink tube for that.

Then, I milled it on the LPKF:

After sanding down the board so it shines and putting in rivets for the vias, it looks OK:

I had to work double sided to get some stuff sensibly connected, so it's a rivet or two...

The source files for this board are available, of course.

I put on solderpaste using the same technique as for the input devices board, putting a layer of paste over rows of pads and then scraping out the excess paste.

Then, I put on the components:

Then, it was time for the oven. Again, I did not really time the process, but look in and wait for the tin to melt and the bubbling of he flux to stop. I ended up around 2:15 this time. This board ended up with one little bridge between the pins of the PIC:

That one was easily correctable with a bit of solder wick, though.

After cleaning up the bridge, I soldered in the jacks (and the bottom sides of the rivets). Soldering the rivets is not strictly necessary, but they tend to lose contact after a few months when you don't, so it's better to just do it. There are no components on the bottom side this time, so it looks rather plain:

Then, I had to adapt some software for it. The original output devices firmware won't work, as I used a different H-Bridge back then, and a slightly different PIC. The Software for the motorboard won't do much, either, as it only works when told to do so. I can tell it to work, though, as I put in that 3-pin connector, and I can attach my USB-UART cable to that. Starting with the firmware I made for Interface and Application programming, I only needed to modify the pin assignment for the UART input. The output is disabled, as there is not angle sensor anyway... That software is here to download, of course.

final project -- weekly assignments -- about me -- fab academy