Skip to main content

Motobrain: Interesting Investigation Concludes

I've had a problem with the way Motobrain calculated current flows for quite some time. Basically it always read a little higher than I expected it to if the textbooks are to be believed. Furthermore, one half the board always read a about 10% higher than the other half. It is not very unexpected that the "textbook" calculation and real life are a bit out of sync. Still, I wanted to know why the error was inconsistent between the two halves of the unit. That part was a bit unusual.

powerpcbIMG_20140801_114345_271[1]
Normally, the way you go about solving an issue like this is to exclude stuff until the problem is gone. First, I excluded the Power board, the PCB with all the high current flow, heavy copper, and power transistors (shown right). I did this using the test jig (right, below) I designed to test all the Motobrains that come out of the factory. The MCU board (the board with the sensors, microcontroller, and Bluetooth radio) plugs into the jig and is given a series of test signals to confirm it is working. These test signals showed a similar error where the same half the board reported a higher current flow than the other. I concluded that the problem was clearly with the MCU board. Since then, I've spent a couple months looking over the schematic and PCBs for flaws that would explain the issue. Countless measurements showed the "error" somewhere earlier in the signal path than I tested though. As luck would have it, the Motobrain design for the signal path in question has a series of amplifiers. This means that the signals are smaller the earlier in the signal path we go. It got to point where I don't own sensitive enough test equipment to do a useful measurement. I best voltage measurement instrument I own is not sensitive enough to test the signal. Well, the Motobrain MCU board is sensitive enough but I was trying to exclude it so I couldn't use it obviously. Rather than beat my head against the same old wall today, I decided to focus on more practical concerns and calibrate the Motobrain to output accurate results. This means I was going to "fix" the firmware to correct for the nominal read error from the sensor. To do this, I needed I do some precise measurements at series of different calibrated current flows and graph them out. Conveniently both sides of the board show a linear deviation from the true reading which makes it very easy to null out in the firmware. Fixing it was as easy as taking the current measurement and dividing it by 1.11 or 1.22 depending on the side of the Motobrain. I did this and updated the Motobrain on bench. The readings were all accurate and I was pleased. Case closed... then again, while I'm here why not beat my head against the wall some more?!?

Always a glutton for punishment, I decided to compare the fresh readings to the historical data I had collected some weeks ago when first built this Motobrain. Every Motobrain is run through a battery of tests and the results are cataloged and stored electronically in case they may be informative in the future. I figured that if I see some failures in the future I may find a pattern in these data to help explain things. So, I pulled out the file for the Motobrain I had just collected these calibrated current flows from and compared them. What I found surprised me. Like I had observed before, the errors were certainly similar and the same half of the board was high relative to the the other. What surprised me was the magnitude of the error. The errors were much larger on the test jig than they were with the actual Motobrain Power board. It suddenly occurred to me that I did a poor job excluding the Power Board from a role in this issue. The simplest thing to do was to indict the test jig in this error I was seeing. About 3 minutes and a couple of quick measurements later, I was able to confirm the test jig was responsible for introducing all the errors I was seeing on the Motobrain MCU board when in the test jig. This means that the MCU board was actually excluded from guilt in the error reading after all. By pure coincidence, both the Power board and the test jig were introducing the same type of error on the same sensors of the MCU board. Flaws on both the test jig and the Power board that affected the MCU board in the same way was beyond my simplistic expectations. I did that first measurement on the test jig, got the reading I was expecting and stopped looking. In science, this is called "confirmation bias" and I fell for it hook, line, and sinker!

 So, what was the actual problem? I still don't have sensitive enough instruments to be absolutely certain if I don't use the Motobrain MCU board to do the measurement, but now that I trust those sensors again, I have identified the likely issue. It is minor differences in the way I designed the Power board itself. The path the electrons take on half of the Power board is about 900µm (900 micrometers) longer on the half that reads higher. That distance increases the resistance of the flow path by about 66µΩ or 0.000066Ω (also known as half a bee's dick of resistance). The signals we are measuring are extremely small though and every little bit of resistance matters. Normally I don't need to worry about such differences because because I give myself much larger margins of error to worry about but Motobrain's high current capacity obligates me to an extremely low output impedance and means that I do need to be a bit more thoughtful. Oops, my bad.
powerpcb-trace

Comments

Popular posts from this blog

A Capacitive-Touch Janko Keyboard: What I Did at the 2017 Georgia Tech Moog Hackathon

Last weekend (February 10-12, 2017) I made a Janko-layout capacitive-touch keyboard for the Moog Werkstatt at the Georgia Tech Moog Hackathon. The day after (Monday the 13th), I made this short video of the keyboard being played: "Capacitive Touch Janko Keyboard for Moog Werkstatt" (Text from the video doobly doo) This is a Janko-layout touch keyboard I made at the 2017 Moog Hackathon at Georgia Tech, February 10-12. I'm playing a few classic bass and melody lines from popular and classic tunes. I only have one octave (13 notes) connected so far. The capacitive touch sensors use MPR121 capacitive-touch chips, on breakout boards from Adafruit (Moog Hackathon sponsor Sparkfun makes a similar board for the same chip). The example code from Adafruit was modified to read four boards (using the Adafruit library and making four sensor objects and initializing each to one of the four I2C addresses is remarkably easy for anyone with moderate familiarity with C++), and

Onboard Firmware of the Human Brain

Freesiders are continually tinkering with robotics and other such machinery .  Many of these embedded processors and firmware are becoming open source and every-more diversified in the wake of the modern Maker movement . One notable boost to the hackerspace arsenal is the Arduino (an like platforms).  This offers designers an incredible power to devise not just individual devices but even the emergence of complex, integrated systems . This evolutionary pace of modern technological systems may be significantly faster the biologic system development, but there may be a few well learned tricks yet to be mastered.  It seems that studying how nature has managed to solve many development challenges will aid in designing robotics, where efficiently counts just as much. One  challenge, that is particularly interesting, is data processing.  Artificial intelligence is labored with processing data and producing a meaningful and useful output.  When considering the increase in sensory

Freesiders Hackers Collaborate in Medical / Surgical Research

Published in the May issue of the Journal of Foot and Ankle Surgery : " A Novel Combination of Printed 3-Dimensional Anatomic Templates and Computer-assisted Surgical Simulation for Virtual Preoperative Planning in Charcot Foot Reconstruction ." This collaboration of specialties represents an undertaking by members of Freeside Atlanta , Southern Arizona Limb Salvage Alliance , and The Podiatry Institute .  Charcot foot reconstruction remains on of the most challenging procedures in foot and ankle surgery.  These procedures are often lengthy procedures which can be riddled with complications. With the help of Freeside Atlanta Members, institutional researchers used open source Osirix Image viewer and 3D Software such as Newtek's Lightwave or Blender to create simulated surgical reductions as well as 3D printed templates.  Freeside Atlanta members assisted in providing 3D printing solutions and know-how to the project. Experimental test prints were done on a M