Audible Altimeter part 1

I was looking for a new electronics project to work on, and found some inspiration in the skydiving world. While you're in freefall, it's absolutely critical to know what altitude you're at, so you can know when to safely pull your parachute. Skydivers wear something along the lines of this so they can keep track of altitude, but another useful indicator is what's called an "audible altimeter", an electronic device that's placed in your helmet and sends out a series of warning beeps at pre-programmed altitudes. I was looking into purchasing an audible altimeter for myself, and found that they're all super expensive (over $200), which seemed pretty ridiculous to me considering how simple they are. I decided it would be a fun project to try and make my own since I thought I could produce one for cheaper, and learn a lot in the process.

It's definitely an interesting project because everything has to be made as small and low-power as possible, in order to have it be completely portable and so that you don't have to constantly worry about the battery dying. I decided to go with a rechargeable lithium polymer battery (specifically this one) since they have great energy density and charge rates. I found a fantastic chip which is built to charge a single cell LiPo at up to half an amp from a 5V source, which is great for USB charging. I'd also gotten some experience soldering QFN (leadless) surface mount parts over the summer, and I thought it'd be neat to design a board with these to make it as small as possible.

I wanted to branch out in microcontroller selection and pick a new architecture that I could learn about. I ended up going with an STM32F050 because it's quite powerful for how much it costs, and it's a good match for the features I need.

Other than that, I picked:

• a fast barometer (many of them could only be read as fast as once a second, but this one gives up to 200 readings per second) so that I can get an accurate reading of pressure to calculate altitude from. 
• a loud 4KHz buzzer so that it would be easy to hear
• an FTDI USB to UART bridge so that I could program it over USB
• a 3.3V buck converter, because the LiPo battery outputs anywhere from around 3.6 to 4.2 volts, and everything runs on 3.3V. The buck converter isn't completely necessary because it could be replaced with a linear regulator, but I figured it was worth it to pay a few cents more for something like 20% longer battery life due to the extra efficiency.
• a bunch of 0603 (metric 1608) passive resistors, capacitors, and LEDs, as well as a few miscellaneous parts like buttons, an inductor, etc.

I started out with a quick block diagram of how I wanted to hook everything up:

I forgot to label Vdd from the STM and the BMP180, but they're going to the 3.3V buck output, not the battery voltage.

I basically sat down for a day or two and CADed all of the part packages using Eagle, and put together a schematic that pretty closely follows the block diagram above, plus a bunch of passives, buttons, and a couple other things.

Unfortunately I was in one of those ultra-focused "make this project without thinking about anything else" states while putting this together, so I forgot to take screenshots showing the process.

One interesting challenge was that I wanted the whole board to be completely powered off while not in use, turn on when a button is pressed, and then be able to turn off when the same button is pressed again. Since I'm only using on/off tactile buttons, I had to get a little creative in order to build this behavior. Basically the buck converter's enable pin (EN) is hooked up to a microcontroller output, so the microcontroller can drive it low to turn off power to everything (including the micro itself). The power button is also hooked up to EN, so that when the board is off and you press the power button, the buck converter turns on, turning on power to the whole board. The micro then has to immediately hold EN high in order for the buck to stay on when you release the button. So far so good, right? The one problem is that the micro has to have a way of knowing when you hit the power button a second time, so that it knows when to turn off the buck and power down. I ended up coming up with a resistor divider pulls a pin on the micro low whenever the micro is driving EN, and pulls the pin high when the button is driving EN, allowing the micro to read the state of that pin to decide if it should power off.

With the schematic out of the way, it was time to lay out/route the board! I wanted all the parts to be on one side so that I could put a battery flush on the other. Here's what I was looking at after placing components:

You can't tell from the picture, but the battery connector (bottom right) is actually on the underside of the board to make it easy to plug the battery into. The yellow lines are "airwires", or connections that haven't yet been physically made. The whole board comes in pretty small at just under 2" by 1", which I'm pretty happy with.

Routing time! This is one of my favorite parts of making boards, it always creates some interesting challenges, especially with smaller boards. Once again, I was in in-the-zone-mode, so I forgot to take pictures of the process.

Looking back I'm a little unhappy with what I consider slightly sloppy routing, all those vias (connections from one side to the other) in the center look pretty messy. Oh well, for revision 1, as long as it works right?

I decided to go with Seeed Studio to get the board fabricated, for smaller boards like this they have an awesome deal of 10 boards for $10, not counting shipping. After placing the order, it was time for the few weeks of eager anticipation that I've come to know over the last year or two since I started making boards.

Of course, it's always worth it when you get a package in the mail and suddenly it feels like Christmas. Here's the top and bottom, with a quarter for scale:

Sorry for the picture quality, maybe one of these days I'll stop spending all my money on skydiving/engineering projects and actually buy a camera instead of using my phone.

Of course as soon as I got these I put everything else aside and rushed to populate one of these with parts, so here's a picture taken a few hours later with everything soldered on:

From there I moved on to trying to turn on the board, and immediately starting having a few problems with the buck converter that it took me a while to get to the bottom of. After decreasing the bypass capacitance on the VCC line I was able to get it to boot up, which allowed me to start programming the microcontroller. Time to learn how the STM32F050 works! Fortunately there's a lot of example code and guides around which make it pretty easy to get things going. I won't go into to much detail about how the code works, I don't think it's useful to paste a bunch of lines of initialization/etc here, so instead I'll describe what I generally did. I started out writing a basic program which holds the buck's EN pin high, turns on the yellow LED, and turns on the blue LED whenever the "ZERO" button is pressed. After getting that all working, I noticed some weird behavior where the board would turn off seemingly randomly. I eventually realized that putting my finger on the top of the board was what was causing it to turn off, most specifically whenever I touched the buck converter. Hmm. It turns out that I had used a large resistor in my voltage divider (the one described above) which caused the EN pin on the buck to be sort of floating, and the transient produced by touching it with your finger was enough to bounce it low, causing the whole board to turn off. Once I knew about this I actually elected not to patch in a bypass capacitor on EN (which would fix the issue), because while debugging I actually prefer the option to have a quick "hard off" available (where the off button is basically touching the EN on the buck).

From there I moved on to figuring out how PWM works on these chips and wrote a function to drive the piezo at different frequencies (e.g. a low frequency/relatively quiet 'boop' when it boots up). I continued to fiddle with it for a week or two, then more or less set the board aside for a while to focus on schoolwork. This semester I have a bit more free time, so I picked the board back up a few weeks ago and continued to work on the code for it. I²C, the communication protocol that the barometer uses, was particularly difficult to get working. I learned that I should have included an extra header for debugging I²C because I had to measure everything by jamming scope probes into the tiny vias on the I²C signal lines. After a few days of working on it, though, I finally got the two chips successfully talking and was able to get a pressure reading out of the barometer.

I took a snapshot of the communication between the microcontroller and the pressure sensor with an oscilloscope:

The other board you can see is ST's awesome Discovery board, which runs for $10 and has an STM32F1 that you can program, as well as a built-in ST programmer which I'm using here to program my board. On the scope, you can see that the first eight data bits (blue) write out 11101110 where they coincide with the clock pulses (yellow). Converted to hex, this is 0xEE, which is the 'write to' address of the barometer, meaning that I'm telling it I'm about to write data to it. The next clock pulse after this is the barometer pulling the data line low, which is an I²C 'ACK', or acknowledgement that it received the previous byte. After that, you can read 11110110, or 0xF6, which is the micro telling the sensor which address it wants to read from (in this case, the address where the last pressure reading is stored). Not currently shown on the scope, the altimeter then sends out its 'uncompensated' pressure reading, which the micro uses (along with a variety of factory calibration parameters previously read from the barometer's memory over I²C) along with a temperature to calculate the 'true' pressure, and then calculates altitude from the pressure.

I had been debugging everything from my laptop, and using debug mode to keep track of variables, which I decided wasn't a great solution for actually tracking how the measured altitude changed as I moved around. I ordered a cheap LCD from ebay and threw it on a breadboard with an Arduino to try and get a portable display which would read out the altitude difference from the zero point in real time, allowing me to run up and down tall buildings and see how well it tracks changes. Because of the way the I²C protocol works, you're able to add new devices to your communication lines whenever you want, which allowed me to simply add the Arduino onto the existing I²C line in order to talk to it. Unfortunately this required somewhat sketchily soldering thin wires onto very small pads on the pull-up resistors on my board, but once I got them there I coated them with hot glue to keep them in place.

Unfortunately, while for some reason the Arduino reads its address correctly (sends an ACK) and does appear to read some of the data sent to it, I've got a bug somewhere because somehow it's not actually reading the data I'm sending. It'll probably take another few days of poking at the Arduino to get it to read data in properly, but my board itself seems to be working as I want it to, for the most part. Pretty close to having it actually be usable for skydiving! I'll probably 3D print a case for it as well.

That's the current state of my altimeter board, I've also got a new project that I'm really excited about (and just ordered boards for!) which I'll write up in the next post.

Introducing the BE3P

In a bit of a departure from my typical posts, I'm going to write one about something that doesn't actually physically exist yet: a brushless 3-phase motor controller I've spent the last week working on with my friend Erik; the BE3P (Banks Erik 3-Phase). Traditional brushed motor control effectively provides the motor with an average DC voltage and then brush contacts in the motor shift as it rotates, causing the magnetic field generated by the coils to always attract the next set of magnet poles, producing torque. Brushless control is a bit trickier, because this switching of the field needs to be handled in software, i.e. the controller needs to determine where the motor coils are in relation to the magnets in order to switch current through them accordingly. We got a bit of a crash-course in brushless motor control from our friend Shane as well as a few online resources, then we immediately started browsing for the major components. We decided to make the controller optimized for the hub motor I built, which probably isn't able to handle more than about 1200 Watts peak. My battery runs around 40V, meaning we're aiming for ~30A peak. Since exploding your components is kind of bad, we over-specced everything a bit (especially the MOSFETs) in order to (hopefully) be able to handle 30A at 40V peak without substantial heatsinking. We centered our design around an Atmega328 microcontroller, an HCPL3120 optocoupled gate drive, and surface-mount MOSFETs rated to 120A at 60V.

Just to warn you, I'm going to try to start basic but this post is necessarily going to get progressively more difficult to understand if you don't already have some idea of motor control theory.

Okay, quick intro: the easiest way to control the average voltage (voltage relates to speed) given to a motor is by taking your battery voltage and pulsing it (relatively quickly, on the order of 10's of kHz) across the motor. You can vary the exact average by controlling the duty cycle (percentage of time that you're applying battery voltage) of the pulses. This type of voltage control is called PWM. So, how do you quickly switch between battery voltage and ground? Transistors! A MOSFET (metal-oxide-semiconductor field-effect transistor) is a type of transistor that can turn on quickly and takes relatively little power to do so. Effectively, the MOSFET has a capacitor ("gate") inside it that turns the "switch" on when you give it a voltage on the order of ~5-15V. "Okay, sweet, my Arduino can do that!", you say? No, not exactly. The problem is that the MOSFET doesn't behave nearly as nicely while the gate capacitance lies between 0V and the "turn-on" voltage of ~5-15V. While your Arduino would (actually it wouldn't, Arduinos have fairly fragile output current limits) be able to drive an "ideal" MOSFET (zero resistance between your output pin and the gate capacitor), in reality there's some amount of resistance along that path, which means that there'll some nonzero amount of time required to charge the gate up. Why? Physics. It ends up being much more efficient to drive the gate with higher voltages (~12-15V) in order to throw higher currents (remember that current is rate of charge flow) into your gate, charging it faster.

So now we need something that can quickly switch between 0 and 15V to drive our MOSFET which can quickly switch between 0 and ~40V. What, you thought this was going to be simple? (I'm not even going to go into other problems like the necessity of bootstrapping your high-side nFETs to enforce gate drive voltage between the gate and the source by leaving the source voltage floating). Well, this is where gate drivers come into play. Gate drivers are devices that can throw quick bursts of charge onto your MOSFET gates. Perfect! The gate drivers we picked out are opto-coupled, which basically means they have a tiny LED inside them and they dump charge onto your FET gates whenever the LED is turned on. This is great, because it means that all your little 5V microcontroller has to do is turn on an LED in order to drive the motor. Additionally, it means that your 5V systems and your 15V systems are only connected by light, which protects your low-voltage electronics and prevents high noise levels on your signal wires.

All of the above basically needs to be copy/pasted 3 times for brushless 3-phase control, which I'm not going to try to explain too heavily so as to avoid turning this blog post into a dissertation. The main important thing is that for "sensorless" control, meaning the controller doesn't directly know where the motor coils are relative to its magnets, it needs to have voltage sensors on each of the phases such that it can turn one off at a time and sense the voltage coming back out of it, from which you can determine the "electrical position" (basically the position of the coils relative to the magnet poles) of the motor, which in turn lets you drive it to the next desired position.

Okay, now that we've gotten physics/theory out of the way, let's move on to the interesting part: actually designing. Not only is this my first foray into brushless motor control, it's also my first time using Eagle CAD for a major board as well as using surface mount parts at all. This was basically a "learn everything as you go" style project for me, so I just kind of jumped into Eagle and started designing.

Here's an early schematic which shows the absolute basics. I'll explain starting from the far left, because that's sort of the direction of flow for this design. First there's a 15V switching regulator, which converts the 40 volts off of the battery down to something more manageable. Next, a feedback and filtering circuit which allows the 15V regulator to operate and cleans up its output a bit. I then have a 5V linear regulator which converts the 15V down to 5V in order to power the microcontroller. The giant box with lots of pins is the microcontroller itself (Atmega328), which then connects to a couple of status LEDs, as well as the three giant boxes you see in the middle of the schematic. The boxes are inverters and they along with the little resistor and capacitor to the right of them form a little circuit that takes the PWM signal from the microcontroller, splits it into two opposite signals and adds a little delay between turning each side off and turning the next on. This delay is a form of shoot-through protection, which means it avoids allowing the high-side and the low-side to turn on at the same time, which would directly short your battery through both FETs and explode everything. To the right of this inverting circuit you can see all 6 gate drivers, and finally the 6 FETs that they're driving.

Next, I moved on to adding the voltage and current sensing circuits. The current sensing consists of a very small (.001ohm), high current resistor in series with the motor phase, connected to a sensitive differential amplifier, which determines the voltage drop across the resistor and thus allows you to calculate current passing through the whole phase. Current sensing is extremely useful for a variety of reasons: (warning: physics) it allows you to calculate the phase-lag between your drive voltage and the current response of your phase (because your motor is an RL circuit), and since current is what you really care about in terms the position of the motor (because current creates flux which in combination with the field of the magnets applies torque), you need to offset the voltage by that detected phase-lag in order to time the torque with your phases switching electrical positions. Current sensing also allows you to do some nice things like over-current protection, constant-torque control, and the ability to detect shorts between the outputs and (hopefully) save your FETs from detonation.

As for voltage sensing, it's absolutely essential for DC sensorless control because, as I said above, it's the only way you can determine the electrical position of the motor.

Here you can see the current sensors (small boxes to the right of the FETs, and only on 2 phases) followed by the voltage sensors to the far right. The voltage reading is passed through a 2-stage RC low-pass filter, because there are lots of high-frequency voltage transients across the undriven phase due to the PWM on the other two and you want a smooth signal to determine the electical position.

With the absolute basics out of the way, I moved on to adding various extra stuff, including bus capacitors to smooth the voltage across the FETs/provide them with clean-ish power, a battery voltage sensor, a 20MHz oscillator for the microcontroller, an ISP header so I can actually program the microcontroller, throttle/extra input (or output) pins, and finally an XBee header so that the controller will be able to support wireless data transmission.

Yay! With the schematic finished (after like 4 days of staring at datasheets), I moved on to actually laying out the board. I definitely wanted it to be able to fit in my scooter, so I decided to make the outline 2.75" by 3.75".

I'd never laid out a board before, so this was my chance to learn Eagle's board layout features. I experimented with a couple of different general layouts before I settled on one I actually liked, the picture above is one of those early layouts.

This is the general layout I ended up settling on, you can see the massive power and ground traces on the left side of the board, and away from everything but the FETs and bus capacitors.

Here's a snapshot from the end of the first day of laying out, I got a little panicked about how much space things were taking and started trying to cram everything together towards the bottom, which in retrospect was a little bit of a mistake. It turns out I had more space than I thought, so cramming made my layout look pretty disorganized. On the plus side, however, this meant that the last third or so of routing went extremely quickly because there was an abundance of space available.

Here's the finished board design with everything routed, and I also added a logo on the back as well as name/date/credits on the front middle.

Erik and I each independently created our own boards and schematics because we wanted the additional practice, and for our PCB order we just put 2 of each of our boards on a panel. We also ordered enough components for 4 boards, so if all goes well we'll end up with 2 controllers each.

For now, it's time to wait for parts to arrive, which we can fill by starting on the code for the microcontroller. Basically, I'm going to enjoy spending a few days staring at massive spreadsheets which tell me which registers do what.

Hopefully that was at least somewhat intelligible for people of varying levels of experience, let me know if you have questions about the design/components/whatever.

Big update part 1 of 2: Scooter progress!

I feel sort of guilty about writing a blog post when I don't actually have any substantial progress done, so I've had a bit of a blogging hiatus while classes started up and my projects slowed down. However, at this point I've definitely gotten far enough to justify a blog post (well, a two-part one, you'll see a logical separation point here), so I'll just pick up where I left off last time:

The battery!

Well, as mentioned previously, I decided to go with a 12S 3P (12 cells in series and 3 of those in parallel, for 36 cells total) LiFePO4 chemistry battery, cells courtesy of an A123 donation to the MIT Electric Vehicles team. I started off just grabbing a big pile of battery cells and metering them to ensure they were at or close to their nominal 3.3V potential, then running hot glue down the sides and sticking the pack into the shape I wanted. Next, I started glomming solder down on the ends of the cells where I'd be connecting them.

You can also see I've started to add thick copper braid to the cells on the left, which serves as the power line through the battery. I went ahead and connected each set of 3 cells in series, then soldered on small (24 gauge) balancing wires which were color coded for my own convenience. These wires allow the cells to be balanced individually to the same voltage when charging, and prevent degradation of your battery (or possibly exploding cells) which would result from trying to charge the pack while some cells were at significantly lower voltages than others.

I hot glued everything down to prevent it from shifting around

I then soldered on the main power outputs at the very front and back of the pack, and finally flipped everything over and repeated the same process using the braid to form the power line, only instead of balancing outputs I placed wires across the parallel points to help the battery discharge evenly.

You can see the gray wires equalizing the cells in parallel

Finally, I obtained some of the biggest heatshrink tubing I've ever seen, and slid the battery into it:

Half an hour later (okay, maybe a slight exaggeration...) with a small heat gun:

Voilà!

A battery!

Only... it turns out I forgot the middle power outputs, which basically break the battery up into two separate packs that can be charged individually at half the voltage of the entire pack, enabling balancing by most hobby chargers. Oops. Time for some battery-surgery.

Here's the heatshrink cleanly separated at the top

I pulled the pack back out of the heatshrink, soldered on the other two sets of power output wires, and slathered hot glue over everything.

Finally, I applied a new section of heatshrink, charged it up (in something on the order of 20 minutes. Turns out this ~6.6 Amp-hour pack can happily charge at 15-20A within ratings), and was possibly a bit over-eager to ride around with the extra power. The result?

Notice how the brake no longer looks functional? Yeah, the brake was no longer functional.

I successfully made everyone at MITERS cringe by mounting my battery exclusively with Gorilla tape. Don't worry, 100% legit engineering here.

In the meantime, I actually received my slightly more powerful shady Chinese brushless motor controller in the mail, and immediately proceeded to snip off most of the useless cables on the box (powered brakes? side-lighting? Hah!), disassembled the case, and stuck a nice new coating of solder across the built-in current limiting resistor, halving its resistance and drastically increasing the output of the controller.

Current limiting resistor circled red

I reassembled the case, applied motor controller to scooter, applied battery to motor controller, and guess what? Everything actually worked! My scooter received an immediate upgrade to scary-fast, and at 6.6Ah, the battery will last much longer as a result. Assuming an average consumption of about 600W going at 20mph, the ~43V pack should last for about 28 minutes, or a little over 9 miles.

That's all for Part 1, but I'll throw in a sneak peak for next time right here:

Expect Part 2 to come in the couple weeks or so!

Hub motor! (ohgodherewego)

Since clearly I wasn't feeling MITERS-y enough having built just a quadcopter, I opted to tackle a scooter as well. (Okay, that's kind of false, really I've been wanting a faster way around campus for a while and Charles had a super giant BLDC motor stator he threw my way on the cheap).

68mm x 38mm 12 tooth stator in all its massiveness

Also of interest is how I'm building a scooter, which as far as I can tell amounts to approximately the weirdest way that one could possibly conceive of/design a scooter - I'm designing a scooter around a motor which in turn I'm designing around a stator. The only reason for this is that I just happened to acquire a stator before anything else (generally just getting a stator that matches your other constraints is probably a good idea).

If you'd like a crash course in BLDC motors, read the really super handy hub motor Instructable. No, really. Read it. Basically the stator is a big chunk of iron made up of a bunch of thin iron sheets which are then laminated together, and epoxy (that green stuff) is slathered all over the inside. The sheets/lamination allow for a high degree of magnetic permeability in the radial direction and much less in the axial, which helps direct the magnetic fields generated by the coils outward, towards the motor can/permanent magnets (don't worry, I'll show you what these are in a second!) and back inwards towards the next coil.

So, without further ado - the actual motor!

Together and with kinda transparent endcaps

Fancy exploded view!

So, from left to right, we have:

1. Left endcap
2. Left bearing
3. Axle
4. Tire/wheel
5. Can
6. Magnets
7. Stator (shown with coils)
8. Right bearing
9. Right endcap

The endcaps are to be turned from solid aluminum stock, the bearings are 1/4" ID 1-1/8" OD high-load sealed McMaster bearings, the axle was turned from a giant aluminum rod found lying in MITERS scrap, the wheel... well, we'll get to the wheel a bit later, the can is a solid steel tube with channels for screws to pass through, and the magnets are 1-1/2" x 1/2" x 1/8" high strength rare-earth neodymium.

Let's get on with the first machining work for the project, the axle:

Note that this is AFTER a significant portion of material has already been removed

Here you can see a giant chunk of pre-axle aluminum, chucked into one of the super classy lathes at the Edgerton student shop. I did some huge passes until I got close to the flange sticking out of the left end of the axle (rendered above in the exploded view), which serves to easily place the axle into the stator without worrying about positioning it. I then worked the right end of the axle down to the correct sizes, arbitrarily deciding that I'd treat the end currently chucked as the left side. Finally, I drilled out the end with a #7 drill bit (.201") so I could put 1/4"-20 threads in it later.

This thing spawned an incredible amount of aluminum chips

I then flipped the part and chucked the center to finish off the left side as well:

I decided that I didn't want the axle to be press-fit with the stator because then it's less easy to take out/replace and I don't trust press-fits quite as much as axle pins. Thus, of course I had to do it the Classy Way and machine a rounded channel to stick a pin through. I threw the axle on a mill, cut out the channel for the output wires to escape from, and like 8 slooowwww eyeballed passes of a 1/16" ball mill later I had a reasonably good approximation of a 2mm pin channel.

Did I mention how much cutting oil I went through?

And a couple shots of the finished product:

Shiny!

You can't see the pin, but trust me it's there. And yes, it's just the unfluted half of a #47 drill bit. Whoops.

Threads were added to the ends a bit later.

Alright, as for the down-and-dirty motor-y bits: coils are on 3 independent phases - the A, B, and C phases. Each phase, in turn, has two each of both capital and lowercase winds (where capital indicates one chirality and lowercase indicates the opposite), so if you were to write out a typical (dLRK if you know what that means) winding 'scheme' it would look like this: A a b B C c a A B b c C. Note how there's one letter for each tooth, and in my case I used capitals for clockwise and lowercase for counterclockwise. I calculated I'd need about 88 winds per phase to get the amount of torque I want (how? READ IT) and I decided I could probably cram that much 20 gauge wire around each tooth. This was a bit of a mistake, as I discovered when I tried to wind it in series with two strands of 20 gauge and found that I couldn't quite manage to pack it in close enough. After failing at winding this in series, I settled on a parallel winding scheme to make winding the motor physically easier. The capital teeth all connect to a common "star" point and the lowercase teeth each go to their respective letter's output cable. With the parallel approach, instead of 22 turns with two strands of 20 gauge wire it's 44 turns of one strand of 20 gauge, which is a bit physically easier to manage.

As you can see, "a bit" easier still isn't easy

Well, it was a fun several hours of wrestling wire into areas smaller than it wanted to go, and after the experience I have a few pieces of advice for anyone else wanting to do this:

• MAKE SURE that your iron core is fully epoxied everywhere the magnet wire will be coiled around. If you see a gap then seal it with super glue otherwise you'll be stripping coating off the wire and causing a short
• Take a small wooden dowel to pack down your windings to create more room. I ended up whittling the end of one down as I went so I had something small and pointy to manipulate the wire with. DON'T use a metal flathead screwdriver/metal anything else to do this, or you WILL strip off your coating and have to restart
• Measure (multimeter) and make sure your windings aren't shorted to each other/your axle/the stator core as you finish them, so you don't have to redo them later
• Double (and triple, and quadruple) check your chiralities before you start wrapping! Make sure you stay consistent with direction between your windings

I only got as far as 8 teeth wound (2/3rds done!) before I was somewhat displaced from the area I was winding in. I'm going to finish while I'm at home Friday, I promise! I don't want to let this hang over me when I'm back in Boston starting Saturday.

Anyway, here's where I'm at:

A couple of the teeth look downright disgusting, but if it works, it works!

tl;dr if anyone links me this or this I may get slightly irritated. It's quite possible I'm terrible at the whole patience thing.

Anyway, now that I'm at a bit of a stalled point as far as windings go, I decided to go ahead and order the scooter I want - this one, owing primarily to its 140mm wheels, which are large enough to comfortably accommodate the rather fat stator (and magnets, and can). The current plan is to get the scooter, measure/CAD the handlebar attachment and wheels, and then design my entire frame around the constraints of my hub motor, the front wheel, the handlebar, and the vast amount (well, 30) of the A123 3.3V battery cells I picked up.

I've also decided I'm far too lazy to want to machine all those slots in the steel can, so instead I'm going to opt to kitmotter it and just waterjet a bunch of half-circles complete with screw slots out of 1/4" steel (this will also give me the advantage of being able to include placement slots for the magnets so I don't have to worry about making separate spacer plates for them just to glue them in the correct places). I'm also going to have a fun time of drilling all the through holes in the aluminum endcaps, but frankly that's about the laziest solution I could come up with for holding everything together, so I can live with it.

I'm hoping to tear through the rest of this when I get back on campus, hopefully I can have most everything out of the way prior to REx because my life is going to get completely sucked away by EC stuff for about a week.