SparkFun Electronics Commentsurn:uuid:214d0e4e-f1b1-d287-ce26-ac5b4c9f82492024-03-29T07:24:37-06:00SparkFun ElectronicsQCPete on DEV-14747 - SparkFun Pi AVR Programmer HATQCPeteurn:uuid:4de9da04-4ea0-63c8-8592-a2901d83cbf52018-07-31T16:41:55-06:00<p>Hey 773,
Thank you for your comment! I appreciate your kind words, constructive criticisms, and ideas for solutions! I do not perceive them as "attacks" in any way.<p>I agree that data logging is very important, and I look forward to pursuing this further. We've always relied on a more manual recording of problems (in our own internal data system), but it is far from perfect, and it only records the problems that a technician or test developer actually records. I have integrated some data logging systems in the past for a different product that required calibration and we needed a very large sample set (<a href="https://www.sparkfun.com/products/13144" rel="nofollow">the capacitive touch potentiometer</a>). But that system actually just logged to an uSD card using an <a href="https://www.sparkfun.com/products/13712" rel="nofollow">openlog</a> on the test fixture and required manually pulling the card to retrieve the data. Not ideal, I know, but it got us through those initial builds and we were ultimately able to fine tuned the default settings.</p><p>Putting a serial number into the bootloader hex of every Redboard (and other AVR products) would, indeed, be pretty awesome. We've struggled with adding some sort of unique data to products in the past. Ultimately, we now have the "batch ID" printed on a sticker, so if there is an issue, we can at least track down the other customers that may have received a bad product. But honestly, that is a pretty rare thing around here, and the functional test fixtures do a pretty darn good job of catching issues before it leaves production. But as we grow, and see larger and larger orders, those strange little errors can lead to very big problems.</p><p>That reminds me, one time we did a huge run of the <a href="https://www.sparkfun.com/products/12923" rel="nofollow">microviews</a> and during a firmware update, the bootloader was actually not included in the "combined hex", and then it still passed testing. That was a tough lesson. I can't remember the exact number of units that went out bad, but I think it was in the thousands. It was a flaw in our process at the time that led to that disaster, and now we require third party double-checking on any firmware updates.</p><p>So thanks again, and I will definitely keep you posted. Automated data logging would be an amazing next step for our testing tools! And, as always, please don't hesitate to comment your thoughts about products and especially testing - we love it!</p></p>
Customer #134773 on DEV-14747 - SparkFun Pi AVR Programmer HATCustomer #134773urn:uuid:86780b53-3d57-e73c-f7c7-13d0b105cc8b2018-07-29T20:26:47-06:00<p>First, let me say that I've met Pete Lewis (he was the "tour guide" when I visited SparkFun a few months ago). I have great respect and appreciation for his work, and that of all the folks at SparkFun!<p>I have more than 25 years of experience in the field of Test Engineering, ranging from "operator" in a factory (that's what got me to go back to school and get my Engineering degree) to doing both "hardware system architecture" and "system level software" on testers that sold for several million dollars apiece. (As one example, every true Intel Pentium ever made was tested on a machine I helped design.)</p><p>Based on all that experience, I have a few comments, mostly for anyone (including the folks at SparkFun) using one of these in an "industrial" setting. Please remember, this is not an "attack" on anyone -- it's just I've learned a few things in all my years of testing, and can enourage others to avoid the mistakes I've made.</p><p>My first thought is that if you use something like a Raspberry Pi 3 Model B+, you can use its WiFi capabilities to connect to your LAN (Local Area Network). By setting up a "designated directory" somewhere on a file server, it is possible to have the tester/programmer to at least verify that it's got the correct version of the code to be loaded. (Actually downloading from the server each time it's turned on is probably a bit much, but with not much programming you can do something like compare a "version_number" file locally to one on the server, and if there's a mis-match either automatically down load it or flash the lights to tell the operator that there's a potential problem.)</p><p>My next thought is that you should ALWAYS do some "datalogging". You might not need it now, but it can come in handy in the future. It is a LOT easier to log data now than to not have "historical" data in the future. This can be as simple as just writing a line to a CSV file on the aforementioned server for each device tested/programmed. It should, at a minimum, include the tester/programmer's name (and maybe a serial number for the tester/programmer), a time/date stamp, the version level of the software on the tester/programmer, the version level of software being loaded into the target, an operator ID, and a result code. It is also a very good idea to keep track of "retries", i.e., when something went wrong on the first attempt to test/program a given target and the operator decided to try it again.</p><p>I've been thinking about a way to obtain an operator ID for a "headless" tester/programmer. What I'd be inclined to go with would be a USB drive (aka a "thumb drive") with a file in it's "root" directory that contains the operator's employee number or name or some other identifying info. I did think about using the Blue Tooth capabilities of the 3 B+ to either talk to an ID chip in the badge or the operator's cell phone, but those seemed like they might be a bit flaky if there were too many people in the vicinity.</p><p>I'm also a big fan of things having a "machine readable serial number". One way that you might do this would be to designate four bytes at the end of the boot loader to be a uint_32 serial number (we can only dream of building more than 4 billion Red Boards!). The tester/programmer would have to keep track of what the last serial number used is, so that it can insert it. By the way, this could be an easy way to take care of most of the "retry" detections: the tester/programmer could try to read the serial number to see if it "makes sense" (i.e., is less than or equal to the last serial number used, and it's non-zero) -- then it's likely a "retry" unless the last attempt failed in writing the serial number.</p><p>This brings me to my one suggestion for enhancing the hardware: add a second capacitive touch pad labeled something along the lines of "retry", so the operator has a way to indicate to the tester/programmer that it's an actual retry. Although this does NOT likely make any difference on the procedure that the tester/programmer will use to test/program the target, it DOES make an important difference in the datalogging.</p><p>You could, of course, use Ethernet to connect any of the tester/programmers to the LAN, but this makes for yet another cable to hook up and clutter the work area.</p><p>There is a lot of important information to be had from analysing the aforementioned data: First, it can quickly alert you that there might be problems when you have too high a failure rate on testing/programming. Second, a good idea can be had of how much labor you can expect to expend to test/program a planned production run. Another thing that can be done, if the devices are serialized, is that if a failing device is returned from a customer, the exact lot can be identified, and if there are several in the same lot, you may be able to say "XYZ sent us a bad batch of XXX parts".</p><p>Obviously, if you're just tinkering with this on your own "bench", or using it, say, in a school lab, you can ignore all my comments!</p></p>