Okay, Internet, tell me more about wireless bootloading.

chorl11 Comments

One of my perennial bad electrical engineering habits is black-boxing electronics and software – not making much of an effort to understand how a (usually software) system works, just accepting that a solution is available and not extensively exploring it unless needed. Historically, I did this to electronic hardware too, coming from a more R/C hobbyist background (I don’t really consider the battlebots to be “robotics”) where things like “Receiver” and “Motor Controller” were considered atomic components as much as screws – they could not, and should not, be decomposed further. I’ve gotten a bit better at that, what with making entire motor controllers and all, but embedded programming is still one of my sour spots.

This is part of the reason why I like Arduino so much – it’s easy, reasonably well featured, and I don’t have to think about diddling registers and setting bits – 6.115 taught me to never do that again if I could avoid it – just to toggle an output pin. It makes the software experience just a little more like high level application programming, the kind I did before getting into hardware and actually all through high school (Did you know that I was CS before I was EE or ME?). Convenience is of the utmost importance, absolute code efficiency and running speed less so. Probably because I just haven’t done a complicated enough motor controller yet, or a flying thing with enough axes. Granted, I’ve also gotten slightly better at that, since there are just some things which are easier to do, like changing the PWM frequency of analogWrite(), by breezing through the manual and just doing the annoying bit shift thing, or enabling a regular interrupt so some part of my code runs with a fixed delta-time for control calculations. In summary, I favor trying and modifying existing solutions first in order to solve the high level problem of make thing work. Which is another great thing about Arduino and the general OSHW community – someone has probably done it already. Including build a smaller quadrotor, but that’s besides the point.

But I think I’ve reached the end of reasonable high level probing, because Chibicopter is not wanting to program wirelessly at all.

Here’s the rundown. I’m using the Adafruit Solution for wireless code uploading to the ATmega328-turned-arduino. There are some differences between my exact circuit and the “community solution” in this case – I’m running 3.0v logic power and my reset line is coming out of D6 instead of D3. The Little Purple Wire hacks are documented here. Otherwise, the level shifter/buffer circuit (which I feel isn’t really necessary) is the same, and for the first few attempts, the settings for my XBee Series 1 radios were also exactly the same as directed.

So here’s what’s been going on:

The Symptom: The remote reset always worked, but the program transmission itself has a success rate of maybe 5 to 10% at most. The most common symptom is hanging – the RSSI LED on the transmitting Xbee goes out, and the ‘Uploading” stage of the Arduino IDE never completes until it times out with an Out of Sync error. A few times, I’ve had programs make it all the way through and complete, but only once or twice, and then it becomes completely up to chance again. The successful attempts seemed to require uncorrelated “adjustments” such as exact location in room (possible radio bad spots or WiFi interference) and orientation of radio, which at such close range I find implausible to be the problem.

The fixes:

1. Complete hardware swap. I ordered more XBee Adapters because my one remaining unit was clearly showing reliability problems – I had to seat the XBee in the headers in a specific half-out fashion to get the power and associate LEDs to turn on, so to rule out the possibility of bad contacts or intermittent power, I made some new boards up. This did not result in any appreciable change in the operation – the vast majority of uploads still failed.

2. More radio power and XBee swap To test the interference theory, I borrowed Shane’s XBee Pro units which transmit at something like 150mW, which tends to outpower every 2.4ghz device around it. This did not affect the success rate of upload, but in this process one of my transmitting XBees was found out to be damaged. It was replaced with another of my radios (the one which had been handling LandBearShark’s load cell reading telemetry), to no appreciable change. I then borrowed two brand new radios, also to no appreciable difference.

3. Reduction to Tx/Rx only with stock XBee settings I removed the reset circuit’s digital I/O pin function so the pin did not toggle. The programming was then done just by hitting the reset button while uploading with only Tx and Rx active. This got me 2 or 3 consistent uploads (variations of Blink.ino), but after that, it once again become unreliable. I completely refreshed the settings a few times, changing only the baud rate to 57600 8-N-1.

4. Possible undervoltage operation problems The XBee is rated to operate between 2.8 and 3.5 volts. I’m running 3.0v, technically not really “3.3v”, so it could be that the XBee is being underpowered. Testing on real 3.3 volts provided by a bench power supply, using variations of Blink.ino only resulted in the discovery of the “uncorrelated adjustments” like Shane standing 5 feet to my left vs. next to my right, or using the back half of MITERS vs. the front, and turning my wireless LAN/Bluetooth off on my laptop vs. on. I do not believe any of those environmental factors are truly the cause of the problem.

5. Power Supply instability. Xbees, being high powered digital devices, draw current in bursts. I have very little 3.0v capacitance, so maybe little dips on the power supply was causing problems such as when the receiving end sent back start/stop flags. I piled a ridiculous amount of caps on the XBee pins directly during the above power supply runs, to no appreciable gain.

6. Trying a known working board. The 2.007 Nano carrier can wirelessly program using the “community solution” or using bone-stock settings on the XBees and manually pressing the reset button. This was demonstrated several times by Shane, but I could not get any of my hardware to reliably work with it either! This was eye opening, and pointed me to the fact that the problem may not lie with Chibicopter’s board. The full battery of tests – my Xbee adapter with both my radios and his radios, the XBee Pro, his own XBee USB dongle… none of them worked reliably if my computer was involved!

7. Messing with virtual COM port settings I tried the established solution (SET RTS ON CLOSE) with no other changes, changing the baud rate explicitly to 57600bps, and even installing a fresh, new FTDI cable to talk to the XBee adapter (thus installing an entirely new virtual COM with no possible previous changes). While the latter change appeared to result in success (4 reliable uploads), it stopped being reliable again thereafter. So promising ;-;

8. Literally trying wires. Hooking up transmitting TX to receiving RX, and vice versa, with GND bridged. This was literally plugging wires in and out of XBee sockets, and it worked without issue every time. This means the issue lies strictly between how the XBees interact with my computer and with eachother – once I literally bridged the connection, there were no communication problems.

Possible explanations we gathered:

1. Some hardware level difference between computers. While this seems to be a stretch, Shane’s Dell notebook can program Chibicopter with much higher reliability such that the random interference, voltage dip, and noise explanations begin to be plausible, and the Nano carrier essentially flawlessly. My HP DV7 can do neither. I’m not up to date on integrated computer peripheral hardware, but I do want to try the exact same parts on a Macbook – if it works on a Mac, then that would explain why there are so few complaints about it, given the Arduino and OSHW community demographic…

2. I am actually missing something very fundamental and stupid. Given that the uploads are so reliably unreliable, this seems almost like the most plausible explanation. Did I really forget to ground something? Are my traces actually soldered? They must be, because I can definitely program the damn thing over 3 wire serial! Are my XBees just cancerous? They’re both  Series 1 whip antenna types with the latest 10ED firmware now.

I’m willing to rerun some of the tests and provide more verbose error message logs, as well as COM port settings and XBee settings. But what the ass?

 

 

 

 

 

 

Upgrading the 100mm Skatemotor for Chibikart

chorl6 Comments

The “skatemotor” design that ended up in the RazErBlades is kind of abysmal in terms of performance. They were wound with maximum torque per amp (Kt, the torque “constant”) in mind, but the result of winding so many single turns on the stators is that their winding resistance was very high. There weren’t many amps to be had afterwards. I pulled the left skate back out to measure the resistance of the motor, and it was about 1.28 ohms. Entire, single digit ohms. It just meant that I was losing one watt for every amp that was going through them. Since the DEC Modules were limited to 10 amps per motor and the system was 22.2 volts, I was losing potentially more than half of the maximum power to winding resistance.

Clearly this was not going to be acceptable if I was going to run them at 32 volts. The skatemotor windings were single turns of 24 gauge wire – not very conductive by high powered motor winding standards – and 36 turns of it per tooth came out to a torque constant of about 0.25 Nm/A. I aimed to hit this value again, but with bigger wire for less resistance.

First step was to check out what copier motors I already had. I picked my favorite part numbers – RK2-0614 is on the left and RH7-5219 on  the right. I didn’t get pictures of the ‘before’ windings, but they were sufficiently dense to make me wonder if they were hand-wound. Given that these are all made in China anyway, it wouldn’t be surprising. The right one was particularly interesting, since it already used multi-wire parallel windings, and is actually the same tooth geometry that I used in the skatemotors originally. The left one has narrower teeth – potentially detrimental for high torque production since the small cross section of iron may saturate if I put too many turns on it. Only a pass with FEMM will tell me for certain.

Because I had four of the left (RK2-0614) and only one of the right, the choice to design with that one in mind was clear. I began running some rough numbers on just how many turns of larger wire I can reasonably stuff into the much wider slots. 36 turns of #24 AWG wire fit into the right with a fair margin, and I discovered that I could reasonably get about 30 turns of single #20 wire or doubled #24 wire into the slots. That would be really Adrianing it and being super-clean, too.

RazEr rEVolution was wound with double #22 wire, but making sure the wire laid flat and didn’t cross over eachother was difficult to keep track of, and by the end I was running out of patience. When the wires crossed, the advantage of packing is lost – as a result, the sides of the windings tended to be much fatter and messy than the ends.

The converse tactic to being careful in laying the wire strands adjacent to eachother to maximize packing volume is “Hobbykinging it”…so called because…

That’s 8 turns? Yep, that is the inside of the typical 80mm “melon” motor. Those things are wound with something like 90 parallel strands of very fine wire each maybe the width of a hair or so – possible #40 AWG or equivalent. Smaller wire is much more flexible and packs relatively easily, and to a degree you can get better results by packing more parallel strands of a smaller wire together.

There is a limit, however – the smaller the wire, the smaller the copper-to-insulation area gets. Even those 90 strands of #40 wire can only amount to a ~#20 gauge equivalent. In terms of circular mils of copper area, the former is (cite) 9.65 * 90 = 868 circular mils, and the latter single 20 gauge wire is still over 1000. I bet I could put several parallel #20 wires in a melon rewind and get even less resistance in it, because the larger copper wire is still enclosed by the same thin layer of insulation.

But the main reason they do it is for ease of winding – bigger wire is tough to form and bend, while a billion small strands can be wound by anyone, and in a production system which involves low skilled migrant workers the task must be accomplishable by anyone.

…including me!

I tried a hex-28 gauge winding here, and I like it alot. Through some crafty decision making, I decided that six strands of #28 wire was a place to start with polystrand winding experiments. That, and MITERS has a 20,000 mile spool of #28 wire, or so it seems. Six parallel strands of #28 yield an equivalent of #21 wire, which is certainly a step up from #24 – a doubling of copper area.

I loved how easy this was to wind. All I had to do, really, was pull tightly, and the wire would just flatten and spread itself. As a result, that is a full 36 turns of hex-28 (so that caption is completely and utterly inaccurate). While I finished 30 turns successfully, the last layer ended on the outer diameter of the stator, and so I carefully wound back towards the inside diameter again, stuffing more turns on. A run through with a popsicle stick flattened the sides well enough that the whole coil seems to pack neatly under the teeth.

I strongly approve. Hex-28 is probably going to be the winding of choice for Chibikart’s 100mm skatemotors…. not just because we have like 20,000 miles of it. I swear. 36 turns would yield essentially the same back-EMF constant, so what I get is a torquier and more efficient motor since it can suck down more amps (more torque) but not heat up as much (less resistance losses). The resistance of that one coil with excessively long pigtails is about 51 milliohms. Four of those in series make a single phase, and eight of them make for one set of powered windings (two phases are switched at any one time in a conventional BLDC motor), so the total “line to line” resistance of the motor will hopefully be only 0.4 ohms! That means for the same amount of resistance heating, I should be able to stuff 1.8x the current through: sqrt( 1.3 ohms / 0.4 ohms) since dissipated power is proportional to current squared.

At this point, I’m just waiting on parts. I’ve ordered all the magnets, just 20 x 5 x 2mm bricks for now, from superdupermagnetgeorge. I’ve also went ahead and ordered some spare 98mm skate wheels since I’m sure if this thing actually works I will instantly drift and brake the current skate wheels into dust very quickly.