Archive for October, 2010


2 DECs 1 Scooter

Oct 28, 2010 in Project Build Reports, RazEr rEVolution

This will be a really short update, since there’s not too much work left on Über-RazEr besides putting it together. Last time, I got the motor spinning by paralleling the two halves and running them on one controller. I’m now proud to say that the twin-DEC controller is also working. Not under load, mind you – that is testing to come.

Putting all my DECs on one board is akin to putting all my eggs in one basket, but these are some pretty hardcore eggs, so I think they’ll be fine. The carrier board is pretty much just there to route signals, as the DEC modules are more or less self contained.  The inputs to the board are the hall sensors and their power (5 wires), a throttle (3 wires), and a… reverse switch. This might end badly.

Here’s the board after being prepped with headers and cables. A power-up test confirmed that I somehow avoided making solder bridges between my .01″-separated power and ground traces.

Finally, the test.

I initially powered everything off our variable power supply in the interest of not dramatically grenading the DECs with 40 volts of lithium batteries. However, the pulsed current draw of the motor was too much for the PS to handle – it flickered in and out of constant voltage mode about as quickly as the motor spun. This power instability likely contributed to a few DEC freakouts – which fortunately are soft shutdowns, not explosions like if I had made them.

Not only that, but a few times I slowed the motor too fast and the quasi-regenerative characteristic of the DECs caused the power supply to latch into shutdown.

So I threw it all into the wind and hooked up the 40 volt A123 battery. And here it is:

Excuse the less than stellar assembly alignment.

Anyways, that’s two controllers running 2 motors in electromechanical synchrony, all inside one wheel. Pretty nifty.

I recorded the no-load speed this time at 1,360 RPM, pulling almost exactly 2 amps no load, confirming the ~33 RPM/volt characteristic.

At this point, I think it’s safe to start packaging up the scooter. I’m very curious as to the ability of the hacked DECs to run under load.


Oct 22, 2010 in Make-a-Bot, Project Build Reports, RazEr rEVolution

No, I didn’t just 3d-print a whole scooter. But here’s a quick review of the past several days’ work on both rEVolution and Make-A-Bot.

razEr rEVolution

First off, I finally figured out what the hell was causing all my Hall sensors to blank once every turn of the motor. Originally, I had suspected a spurious short caused by some exposed connection on the 5 volt Hall sensor power lines rubbing the aluminum can, or something in that same genus.  However, cross-checking the sensor current draw on a power supply showed that the blanking was actually caused by them losing power.

Uh oh. I pulled the motor apart, and as it turned out, the Hall sensor ground wire got mashed into the bearing when I dropped the stator into the can. It was technically severed, but the bearing closed the circuit so the sensors could be read anyway. At least, for 300 out of every 360 degrees or so.

That’s right. My motor was running its sensors through a bearing. Well that would explain its choppiness and propensity to sound like a moped with a badly tuned engine.

A quick reroute of the ground wire fixed all of that, and here’s a test spin of the Dual (non-)Interleaved RazErMotor using a small Kelly controller.

Yeah, so it sounds as rocky and off-center as most of my other hub motors. Blame my lack of patience in actually assembling the motor components. Otherwise, it’s also mounted solidly to a very hollow and lightly damped tube, which just makes it sound several times worse.

With the windings run in parallel (grouped as shown in the video), the motor came awfully close to scoring a perfect 1337 RPM at 40 volts, measured via LAZERTACH.

If only the battery had been a few millivolts higher.

Anyways, this translates into a “Kv” of only about 33 RPM/V, or 0.285 Nm/A in SI-world. I made an original prediction of 0.66 Nm/A in series connection (if the two half-motors were run as a regular dLRK type motor). In the parallel configuration, that number would be about 0.33 – which 0.285 is close enough to, since my prediction used the most generalized, ideal definition possible.

Next steps for RazEr include finally assembling the DEC carrier boards and then… well, making them carry DECs. Hopefully hotwired ones. As I discovered on the Citycar model, the DECs perform cycle-by-cycle current limiting, which effectively means the peak amps rating is not an average DC value – rather, it’s the amount of current it will try to clamp the motor phases to, period. This was a troublesome discovery for the CityCar model, and unfortunately could have been prevented if I had thought about what current limiting actually means.

I’ll have to see if the roughly 0.6 ohm resistance of each half-motor means that the most I can ever push into them is about 12 volts (I * R, or 20 amps * 0.6 ohms) – past which the DECs will just clamp. Now, of course, there is the option of just adding another current sense resistor to quadruple the original 10A limit… but that’s territory which can easily lose me an entire module in a split second if I’m not careful.

So who knows – maybe this is an opportunity to finally design the Melontroller.


No, I haven’t waterjetted it yet. Quit asking.

All the work on Make-a-bot so far has been in the CAD domain. I’m slowly filling out the basic geometric sketch presented last time with T-nuts and … you know, actual components.

I’ve added some more solid material to the Z-axis column. In retrospect, the original column idea was quick and easy, but I had qualms about its stability… as well as the fact that I designed it at like 5 in the morning. Things which I design during those hours almost never turn out right.  Conceptually it’s sound, but solid mechanics will probably tell me otherwise once I build it.

As a result, I’ve added the Giant Aluminum Tower around the existing guide rod and motor mount.  The GAT will be put in compression from the top using the threaded rod, and the guide rods will not be structural any more. At least, this arrangement should be more stable than the original plan.

So now with the geometric structure complete, I can start filling in the details. Check out this Cleverly Engineered System for attaching the Y-axis limit switches!

I decided to keep a “flying limit switch” setup i.e. keeping them on the carriage instead of on the machine base because the front and back sides of the base are decidedly asymmetric – I wanted to keep the number of part variations down. Plus, I was going to need a wiring harness for the traveling Y-axis anyway.

The added bonus is that because the endstops have been reduced to a hardware problem, they can be adjustable. So, those three screws on the motor mount let me slide the rod in and out to engage the switch at whatever distance i feel like is appropriate at the moment.

Taking a page from my engineering books, I’ve decided to put one half of each axis on flexure mounts. Each of those pull-tab-like rings is the new bushing mount for its quadrant. Therefore, the bushing is allowed to flex side to side very slightly to accomodate for misalignments in the guide rods.

In short, 3 points of contact fully define two objects with respect to each other. Adding a fourth is redundant, and unless they are all in the same plane, will cause problems. For a machine axis, this means binding, and that’s why many linear guide systems have only three bearings, or have adjustable ones.

Assuming I did this right, the bushing should be allowed to float side-to-side (i.e. in the direction of X for the picture shown) on the order of only a few thousandth of an inch or less. The flexure, being very short, will still support some of the vertical loads (in the direction of Z) of the whole system. Because only this side of the Y axis is flexure-mounted, there will not be slop in the X direction because of the fully constrained bushings on the other side.

If I did it right.

So now I’m starting to add the intricate T-nut work to the frame. These T-nuts are a departure from my usual style (flat bottom) and are more representative on what’s found on most other 2D-fabbed works in Makerdom.

The reason is that flat-bottomed T-nuts are very sensitive to hardware length tolerance. There’s nowhere for the screw to go if it is slightly longer than the design length, and it will just dig down into the material and defeat the purpose of having the nut there – if the nut is just pushing back on the material, that fastening location does not provide any fastening force.

The cruciform T-nut (Crüx-nuts? Jesus nuts?) allows for variations in screw length by letting the screw poke out past the nut. Now, I’ve never found my screws to be more than .01″ or so apart, but I’ve accomodated for up to 0.55 inch actual screw length on 0.5″ hardware here.

There’s also another Clever Limit Switch setup on the ends of the Y-axis carriage. Again, adjustable by turning the little cap screw that ultimately gets faceplanted into the limit switch.

Notice the X-axis carriage also having flexure mounted bushings.

For kicks, I dropped Cold Arbor’s assembly model in side by side. This machine is going to be pretty chunky. For reference, CA is 20 inches across the curved diameter and about a foot tall at the upper edge of the saw.

It’s definitely bigger than a Cupcake. So what’s the next size up, a muffin?

Maybe I should look into stronger stepper motors…

Project Make-A-Bot

Oct 17, 2010 in Make-a-Bot, Project Build Reports

I have waited long enough.

If I trace out my history of fabrication methods, I can observe that I’ve basically gotten hooked on one new methodology or machine (one sort of begetting the other) every year since 2006. Before then, my robots were practically all hand-crafted and fabricated using only basic shop tools.

2007 and 2008, my first year in the northern wasteland MIT, was the first time I had consistent access to machine tools. Thus, many of my works from then feature alot of heavy billetwork. I really liked making things out of big bricks of aluminum or solid rounds of steel.

All that changed when I found the waterjet. As one look in my project hive will tell you, I can’t build anything without a waterjetted part any more. It’s actually kind of depressing, because I will actually wait 3 days for an opening on the machine to make something which amounts to a flat piece of metal.  Instead of, you know, manning up and just cutting it out on the bandsaw.

It was during the summer of 2009, when I was an intern at iRobot, that I got introduced to 3D printing firsthand. Before then, it was just a curiosity on Youtube and Wikipedia. But at iRobot, alot of my tasks revolved around 3D printing. You see where this is going.

What the waterjet did for me in 2D, the 3D printer can do for me in 3D. I can easily put together 3D structures out of flat pieces, but why not skip directly to the 3D? Or even better, use 3D pieces to MAKE A 4 DIMENSIONAL PART?

3d printing

Commercial 3D printers, like waterjets, are big-investment machines that are closely guarded by their purchasers. Despite falling prices as more manufacturers emerge and technologies mature, a machine that produces structural parts stills runs over $10,000 commercially. I definitely don’t have that much on me at the moment, despite a surprising number of people pitching into the tips jar (THANKS EVERYONE!!!). Plus, just buying one would be no fun.

Structural is a pretty important qualifier here. There are many processes which all fall under the “3d printing” colloqualism. There’s the classic “3D printing” powder-and-binder technology such as that commercialized by Z Corporation (MITERS represent). There’s stereolithography, which uses a liquid polymer and a laser (or strong UV light and micromirrors) to solidify tiny dots of the liquid; SL and related processes can get features down to the micrometer or smaller. And then there is laser sintering, which combines the powder of 3D printing and the laser of STL to let you make parts out of anything that melts. Which is to say, anything – including metal and ceramic. SLS/DMLS is one of the latest technologies to emerge and is therefore unthinkably expensive.

Of those technologies, really only SL and SLS produce parts that can be described as “structural”. The powder-binder method can produce any color a regular printer can, however, which makes it still favorable for product development.

Oh, I forgot one method. Fused deposition modeling / Fused filament fabrication machines extrude a little noodle of plastic and drag it around to shape parts layer by layer. It produces parts which are almost as strong as the parent plastic, doesn’t have outstanding Z-axis feature resolution, but is fast and relatively cheap. It’s also the technology which has made it to the hobbyist and amateur domain.

DIY 3d printing

The “maker scene” has been enthralled by 3D printers for some time. The concept of on-demand digital, individual fabrication is pretty much the embodiment of Makerdom. As such, there have been several attempts at making an affordable, open source 3d printer. The projects which have had the widest reach are RepRap, Fab@Home and Makerbot (which itself was a branch of RepRap). As far as I know, all attempts so far have been FDM type machines – which are conceptually the simplest, since all you literally are doing is dragging a molten plastic noodle around. There’s details involved, but it’s less complicated and cleaner than diddling with powder.

For some time, I’ve been mostly ambivalent to the DIY 3d printer world. Primarily it was due to lack of research and other projects filling my time (and the waterjet having successfully seduced me), but I was also a little put off by the design limitations imposed by the RepRap project because of the end goal of self-replication…. which I find a bit creepy anyway.

I was first introduced to the Makerbot Cupcake over this past summer because Trevor built one. By then, Makerbot Industries had already refined that design so it was more robust and streamlined. I was impressed by the build quality of the Cupcake, even when it hadn’t been fully dialed in yet. I’d almost say it was on par with the Stratasys Dimension printers I used at iRobot, and certainly stellar for the sub-$1000 cost.

Maker Faire NYC

I was completely sold, though, when I tripped down to Maker Faire NYC 2010 for kicks. 3D printing had an entire three tents full of exhibitors, so I had a firsthand comparison of all the different DIY variations, as well as commercial solutions.


Also, RepRap Mendels.

The Makerbot Cupcakes here were well-tuned and well-trained, constantly producing little giveaway trinkets for the crowd. Print quality on those was phenomenal and the parts themselves solid – it took real effort to break , even between layers (I had also previously been put of by 3D printing due to iRobot’s Dimension machine making a few parts with weak layers).

Makerbot Industries chose this occasion to introduce the Thing-o-Matic, which is a bugfix, refinement, and feature request update of the Cupcake.

my turn

That was it. I spent the entire bus ride back to Boston thinking about 3D printers and the crazy things I could do with them. I contemplated just buying a Cupcake kit (or a ToM kit when they ship), since everything would work and there’s a huge userbase to turn to if it doesn’t.

…who the hell am I kidding. A few weeks of idle time while I attended to such distractions as über-RazEr and Melon-scooter let me materialize the design in my head a little more. What I was mostly after was:

  • Easy to build. I was enamored to see T-nuts on the Cupcake. I was really not impressed by the heap of threaded rod that is Mendel. I hate threaded rod with the burning passion of ten thousand power MOSFETs. Overall, I shouldn’t have to machine anything.
  • Large build volume – I wanted to aim for 6 x 6 inches square, by maybe 8 inches tall or so. Not that I think I’ll be hitting the 4 inch cube limit of the Cupcake any time soon, but it’s nice to keep in mind.
  • Modular, in case I ever want to replace something and keep the machine’s functionality.
  • The motorized build platform.

The “Plastruder” tool head is a design which has been refined many times, and they’ve got it working reliably now. There’s many details in the extrusion process such as feed rate, temperature, and speed that have been figured out by the community. Therefore, I intend to just get the tool head and stick it on my own hardware – at least until I know what I’m doing.

Same with the electronics, and most definitely the software. We know what happened last time I built something requiring custom electronics and/or software (It’s still ALMOST THERE, I promise).

In all, it’ll be “Makerbot-RepRap-compatible” but on an indie platform.


Without further ado, here’s the first pass at the CAD model. This model currently has no final geometries, dimensions, or methods of attaching anything to anything else except maybe exploiting the strong nuclear force.

The machine looks kind of like a Thing-o-Matic without the surrounding structure. The reason for making this machine more stand-alone is because of my modularity concerns – building a whole box structure with a machine integrated inside is less appealing to me than building a machine and then putting it in a Nice Box.

I took a page from the MakerBot design book by using the screwed axis endcaps. I’d have used shaft collars here, or drilled and tapped otherwise.

The axes are moved by steppers and timing belts, except the Z axis, which uses a leadscrew. I hadn’t yet specified the particular leadscrew yet, so that part is implicit.

The spider plate in the center is designed to mount the eventual motorized platform, but can also mount a conventional acrylic/kapton one. I wasn’t particularly impressed by the magnet-attached build plates of the Cupcake. It seemed to wobble alot, and suffer from poor alignment, but I’ll give it credit for convenience. I don’t mind giving up a bit of convenience if I’m not ending up building a motorized surface, so the attachment might be via thumbscrew or something.

The axes have a whole 6.5 inches of travel in the X and Y and currently 7 inches of travel in Z. This is, however, not accounting for the added height of a motorized platform or head height variations that might be yet to come.

As a result, this thing is kind of huge – a full 15 inches front to back, 14 side to side, and 17 top to bottom.

Oh, it’s also all aluminum. I have a few extra 1/4″ plates left over from the summer robot build, so it’s going to be metal. Total overkill for a process with almost zero tool pressure, but \m/etal. I’ll have to be careful in making sure the axes don’t have too much inertia or else the stock stepper motors will not be able to handle it (a clear excuse to put a bigger motor on it).

The name MAKE-A-BOT is just a silly derivation of a Bostonian slurring of “Makerbot”.


I’m guessing at this point this will be a late fall term project and probably extend into the January punt period called IAP. Most of the parts are stock, there’s zero machining (yet), and the structure is entirely waterjetted (however, I am not opposed to making it all acrylic, in case it will be laser-cut and have embedded LEDs).

Some random musings I had involving the design, which will not be in the first iteration (if ever at all), include

  • Full heated cabinet for the main machine. Having a heated base is good, but a heated cabinet is better because of the even thermal distribution in the plastic while the part is under print.
  • Printing bonded iron stators. This was the “killer app” which made me determined to build this in the first place – experimenting with the manufacturing of poured iron-epoxy stators for motors. With solid fill, each layer is bound to take several minutes, which is enough time for fast-set epoxy (60 second, etc.) to get structural enough to support its own weight. Mix in an absurd amount of iron powder or filings to the resin on the way and you will hopefully get a material with 60-70% the saturation of a legitimate iron core, but hey, at least you made it.
  • Maybe some day I can actually try making an SLS machine.

If you’ve lost track of how many things I’m working on right now, it’s technically just two – RazEr rEVolution and now the Make-a-Bot.

Revisiting the DEC Module: I should bake a cake for Maxon

Oct 12, 2010 in Project Build Reports, Reference Posts

At the beginning of summer, I wrote up a quick report of some experimentation with Maxon’s DEC Module. In short, they’re bite-sized little BLDC motor control boards which can run up to 50 volts and 5 continuous amps. They have real current control and also can perform closed loop speed control. Overall, I’ve found them very versatile and useful. Four DECs have now logged several whole miles!!! in the RazErBlades.

I’m always out for more amps, however. The DEC is marketed as a 5 amp controller, but it will gladly hold currents of 10 amps forever, as I found out in the ‘blades. As that post addressed, it isn’t the semiconductor which is a limit to the DEC’s output power. The FETs, while small physically, only have about 6 milliohms of resistance when switched on The gate drive itself is also fairly well matched to the FETs. It’s just Maxon’s well-known conservative rating for their parts, which probably contributes to their reliability significantly.

But what this really means is that a 10 amp Maxon controller should be capable of about 195,000 amps in reality[citation needed].

Well, 20 is close enough to 195,000. Can you spot the hack?

It’s the lamest thing ever. I just piled another current sense resistor in parallel with the one already on there. The DEC uses a 10 milliohm 2010 package SMT resistor. A compatible one is this, from Digikey.

What’s that cute little PCB the DEC is mounted to?

Like the RazErDEC and Double DEC’er board, it’s designed to hold a DEC module and provide some glue circuitry. Unlike those two, however, it’s a bit more “general purpose”. I lead the D2 and D1 mode pins out to their own header for setting closed loop speed. I also threw in a selectable inverting circuit which flips the state of the REVERSE pin, in case the motor is happy running backwards when you really want it to run forwards. Otherwise, it has the analog throttle and digital reverse pins brought out to another header. There’s also a supplemental bus capacitor.

The “killer app” for this board so far is the  model CityCar at the Media Lab…

Yes, those are Turnigy Short Melons attached to the Epic Robotic Steering Arms.

Moving on… The DECs are currently a stopover solution as we ditch the flakey Kelly KBS controllers and eventually move onto a fully integrated control solution involving the Hexbridge Shield.

pushing the limits

Now, realistically speaking, I don’t expect the DECs to survive at the full 50 volts and 20 amps. The FET package is simply not designed for high power. The model CityCar will only be running 12 volts, which (while admittedly a bit of a waste of the Melon’s potential – it’s being used for form factor, not power) eases the power handling of the boards significantly.

I expect if I’m actually to use the DECs at 20 amps for any length of time (e.g. for the new RazEr) I’d have to come up with a heat sinking solution. There’s many components on the power side of the board which are taller than the FETs, so it’ll involve some creative layout for certain. I’ll probably have to remove one or two of the large blocky capacitors onboard – which is fine as long as I provide it additional buscap anyway.

RazEr rEVolution: End Menial Labor

Oct 10, 2010 in Project Build Reports, RazEr rEVolution, Reference Posts

When we last left rEVolution, I was halfway through the process of turning my hands into bloody, tattered stumps. It’s a ritual that occurs with the construction of every hub motor (which means I went through it four times to make the RazErBlades).

And by all that I mean winding the motor. Here’s the end result, terminated for presentation.

I ended up keeping the “split dLRK” winding style – making 6 teeth wound AabBCc and the other 6 aABbcC.  They’re terminated in separate non-connected star points on the underside. The leads are grouped by their respective phases – motor 1 is the classic white-red-black, and motor 2 gets yellow-green-brown.

My patience deterioration is very clearly shown in the picture. I wound this motor starting from the Aa side and proceeded counterclockwise. You can see a decay in the quality of windings and the neatness of layers right after the aA phase on the left. Then by the last one, it’s all gone to hell.

To maintain engineering rigor, I took measurements of the DC resistance of each phase. This will pretty much determine how much current the motor can ever pull.

I proceeded to defenestrate engineering rigor (MITERS has very large ceiling-height windows, so this was easy) by scribbling the resistances hastily on the workbench. In dry-erase.

From the picture, you can deduce that the C phase of motor #2 is about 10% short of turns. Yeah, I think I pretty much stopped caring by that point. The other phases should have 39 to 42 TPT, but I’m guessing 35 or less made it onto the last C phase if I’m lucky.

Fit test!

I tried giving the motor a test spin using a sensorless controller (essentially by bootstrapping off Melon-scooter), but neither half-motor exited the “starting” regime. This was concerning. Did I terminate them wrong? Wind something backwards just a little bit?

A few minutes of diagnosis revealed that the motor was technically running smoothly, but the controller just didn’t increase throttle. Applying voltage to each half-motor in each combination of the 3 leads (i.e. A to B, A to C, B to C…) produced 6 identically spaced angular positions each time – which is indicative of correct winding, since that’s pretty much what your controller does anyway, just alot faster and without colliding alligator clips.

I pretty much just declared it to be a fault of shitty sensorless aircraft controllers being unable to deal with inertial loads or high friction systems.

Without a supply of hall sensors, I put the frame and motor away and started thinking about the other parts of the electrical system.

EVs generally have 3 big components – motor, controller, and battery. With the latter two, you can shoehorn anything in as a motor. With motor and battery, you can be a dumbass like me and control the vehicle with a mildly more civilized form of touching 2 wires together. But without a battery, what am I to do – run the whole thing from a bag of lemons?

Luckily for me, people have figured out how to stuff the equivalent of tanker-loads of lemons into lithium nanophosphate cells. Above is the 12S2P A123 DeWalt 36v Lithium pack during mid-assembly.

I managed to find some terrifyingly wide copper braid this time, and I think the cells just look so much better with them instead of the \m/etalpaxxx‘ quadruple braid. The massive interconnects just scream this pack will dump enough amps to destroy you and everything you ever loved.

Another serving of giga-braid later and the pack structure is complete. I decided to split the pack into 2 6S packs again for balancing purposes, but this time the pack isn’t two separate entities. Shane supplied me with Real Legit JST-XH Connectors of Battery Balancing (+14, for pin count), or otherwise I would have probably resorted to 7 pin-header again.

Bottleshrink returns once again, but this pack is so long that I needed the midsections of 3 bottles to completely enclose it. Luckily, it fit 2 liter bottles fine, and I just pulled a few out of the recycling bin.

A quick check of the cell levels revealed that these cells are in fact still quite healthy despite sitting for an unknown period of time.

Of course, that all went to hell on the first charge, and I had to spend an hour manually bringing each cell group up to full.

back to motters

Given that the motor itself seems to be correctly wound, I surmised that all my problems would go away as soon as I added the requisite hall sensors to the slots.

And here they are, temporarily CA’d in place as a soldering fixture. LRK-style motors need a physical 120 degree sensor arrangement, but I’ve always found cross-stator wiring work to be awkward. Therefore, like on the skatemotors, I take the B sensor and flip it around for a 60 degree, every-two-slots layout.

I secured a chunk of 6 pin cable to the access slot in the shaft using epoxy. At the same time, I elected to secure the phase leads to the other side of the motor. The whole epoxy-globbed mess was then introduced to my epoxy curing oven fixture implement hair dryer hanging by its power cord from the ceiling.

After the first round of epoxy set, I finished connecting the sensor wires. Unfortunately, I managed to break off the output pin of the B sensor… and so ended up having to install the opposite one anyway.

Luckily, this design left plenty of space near the edge of the stator, so running the wiring all the way around the motor wasn’t as difficult.

The sensors got their own layer of goop. I kept finding buckets of different epoxy fillers around MITERS – this is “cellulose” filler, which probably just means paper dust.

It claimed to be less cancer-inducing than either the silica or phenolic microspheres, so I gave it a shot.

After another hour or two of watching glue dry, I put the motor together. Here it is – Dual (Non-)Interleaved RazErMotor!

But does it work?

That’s a gooooooooood question.

Using the Kelly KBS which sort of miserably failed at running Melon-scooter, I was able to briefly power up and spin the DNIR to full speed. Qualitative observation tells me that at least I didn’t get it that wrong. The fact that it moved at all meant that I got the sensor arrangement correct for the “split dLRK”. Now, for this test, I just paralleled the equivalent phases of each half-motor. Once I put together the RazerDEC board, each motor will be powered by its own controller, but triggered from the same sensors.

The speed was visually in the “correct” range and it started and ran smoothly with no signs of improper winding or termination.

that is, until it started sounding like a moped.

Oscilloscope diagnosis of the sensor outputs showed that every mechanical revolution, all 3 sensors were blanking. This caused confusion for the controller for a split second until the sensors outputted a valid signal again.

Well, this is disappointing. The sensors – which, mind you, I had JUST encased permanently in a cellulose-epoxy matrix – seem to be having power issues once per mechanical revolution. I’m fairly certain it’s power, anyway, because there is no physical way for all 3 sensors to read the same field orientation the way they are set up.

This actually means it shouldn’t be hard to fix – my guess is that somewhere, a bare solder joint is nicking the metal can once per revolution and causing a short between sensor 5 volts and ground. A further test to confirm (or dispel) this would be to look for dips in the 5 volt line during each revolution.

In the mean time, there’s no pics of it running, therefore it didn’t happen.