 Go. All right, so open sourcing the engineering design process. Basically, I'm a doubly and I'm going to talk about everything that goes into building an electrical system that you should think about documenting. Slide. All right, so first, what is the engineering design process? It's the miracle that occurs between when you have an idea and when you try to get hardware. And it's a miracle because depending on what you're making, it can be incredibly complicated. If it's a mechanical system, a code system, there's a lot that goes in there. Slide. So the idea, OK, well, I'll just talk about what I did, but it's really hard based on what you're building. You can have design for manufacturing rules. You can have schematics and bombs. But there's a lot of other things you might contemplate when you're building a system. Slide. So convention states that if you're doing open source hardware, a schematic and a bomb and a Gerber is sufficient to reproduce your design. It's like an executable file. Should that be sufficient documentation? And the answer is no. Do you know what this board does? If I gave you the parts list, how long would it take you to figure it out? Slide. Because there's nothing open about your hardware if I have to reverse engineer it in order to improve on it. And it's the same thing for code. If you don't have a documented code, or if you had like a lot of contemplation about a protocol that went into you making a system, if you tell the story of your contemplation, then other people can actually like work with you in a dialogue to improve upon your project. And I'm going to run through briefly what we need to do for hardware in order to make that possible. Slide. So industry beats hackers and hardware design exactly because when you're at a company behind the NDA and firewall, you're required to document everything about your product, including your rationale and every decision as you go. Their motivation is if they lose an engineer, they don't want to lose the project. And it's very, very strict how open things are so that you can have a very good review and a dialogue between generations of engineers and engineers across companies and across continents. Slide. So this is the vaulted engineering design process. It's literally what you do every day when you're messing around with a system, but you be formal about it. So you have an idea, and then you ask important questions about the system you want to build. Then you answer internally all of those questions, and this is what most people skip. They don't write down their rationale. They don't say, oh, I'm really trying to build this radio system, so I need to make these decisions. And so when they end up two years down the line, they don't remember why they chose to do something. Then another thing a lot of people skip is you need to hold a review. You need to invite other people who have not been there with you from the beginning to look at what you're doing and sanity and check your stupid mistakes. Then a lot of other things we all usually skip. We try to go to the end and get a final product, but you really want to make one, test it, go through and do full test coverage. This is very important for hardware. It's also very important for secure software. And go through and see if you address your original questions, and then you make money in profit. Slide. So it's a real pain in the ass to go through a formal design process, but if you do it, it really, really saves your bacon because the cost of mistakes in hardware is a lot, yes, delicious bacon, but the cost of failure in hardware is you might have dropped 20 grand on a build and it comes back and you've got 500 boards that don't work. Slide. So the following are crib sheets for the process that I follow when I go through and do engineering design regardless if it's for work and prototype medical devices or the ninja badges or hobby projects. So read the details later on because we're gonna go through it really quickly. Slide. So this is an example from work. I've given this talk before so all of this is totally public, but I had a project where one of the faculty members wanted me to build an autonomous robot. And I say, okay, well, as an engineer, my process goal is to front and load all of this design work and the effort so that I can debug this and reuse it trivially easy. I wanna do the work now so that when I have to look at this project in two years, I don't need to do any work later. I wanna be very, very lazy down the line. Slide. So every project begins with the motivating questions and always, always do this. Why are you making it in the first place who's it for, how it will be used, what features are necessary, what features or bonuses? You know, argued there are legacy requirements for other systems and really like how and then the last questions are about manufacturing. Who's gonna build this? Are you building it by hand? Do you have a budget to have someone build it out of house? How many do you need to make and what's your timeline? Slide. So this is the hardware design workflow that's explicit to electrical engineering design. It's different from mechanical design, but the concepts are you actually review at your design concept level like when you have an idea you make sure it's a good idea and you make sure it's worth doing. Then you do all of the specific work for your CAD program from dealing with parts and the schematic and the layout and that's like, it's like writing your code, it's like setting up your framework in a development environment. Then you have all of your manufacturing, that's the third part where you check based on who's making it, if you're doing all of the right things to make it easy for them to make to make sure that when your stuff comes back it's what you thought you were building and it's correct. And there's a lot of detail in this. So it's very important to go through each step in a logical flow. Slide. So this is what I did for that demo robot is I actually broke it down into modules and I'm like, what is already existing so that I can reuse it? Because if I have to redesign everything and be original every time I make something I'm never gonna get beyond a blinky light. So you go through and for hardware you go through application notes and data sheets, old projects, cookbooks like Horowitz and Hill, off the shelf and other things in the community because someone else might have already built what you're looking to build and you just need to put a little bit of an extension on it. And then to be rigorous I break it down into block diagrams and look at the input-output relationships much like you would if you had an input parser going to an operating system. Slide. So I mean even pros use Arduino. The take-home lesson at the bottom before going through the design rationale is final releases are what are optimized but if your first point in a project is to build something that works, build something that works, hardware is iterative and you can always optimize later. So an Arduino is open source. Great, I can copy the files. The Mega had a really fast SPI bus which was one of my requirements for this robot. I didn't have to waste any time on originality. The learning curve for the tool chain is null and I thought okay maybe like other people have worked with these servos and I can piggyback on their code. I had to rewrite the library but I thought I might have had a shortcut for being lazy. Slide. So going through the next bits which get really into doubly stuff. You wanna Wikipedia these lexical definitions have grayed out the definitions that you should read later but a part library is the representation of physical parts in your CAD system. A schematic is the logical drawing of how you connect all this stuff. A layout is the software representation of how it physically looks as a circuit board and tape out is the step where you're done doing all of your CAD cycling and double checking of everything on paper and then you send it up for manufacturing and start to pray that it comes back right. Slide. So best practices when you're doing a schematic is start with your CAD library and curate your parts as you go. So as you pick parts from Digi-Key to using your design make sure they're in your library and make sure they're correct. If you copy a library from like Sparkfun double check the footprint. I've never seen people commit stuff back. Take time to find multiple vendors. Take time to note physical design rules. Go. One. Out of time? Yeah. Okay. Glory. So that's all I'm... I hate to... I really hate to say this and this is me being completely selfish and circumventing the rules and being unfair. I actually kind of want to see like the rest of this. It's really educational. Right. Exactly. You know the... What's IRC say? Oh IRC is loving this. They're all... Yeah, they're... Yeah, it's hilarious. So I'm gonna try to do the no nerds left behind thing. I'm gonna take a poll in IRC and take a poll out here. How many people wanna see the rest of the talk? Okay. And then because there's actually a 30 second delay, gonna wait to see what IRC says. Okay, plus one. Plus. Plus one, plus one, plus one, plus one. Okay. Okay. Continue. All right. I'll try to go faster, but I'm trying not to talk too quickly. No, I think the ongoing gag on... Oh, okay. Now they're saying faster, but the ongoing... Faster, oh. Okay, yeah, just go for it. Okay. So from the previous slide, basically that you wanna curate as you go and keep a list of every part you buy by multiple parts. I'm not kidding. If a vendor sells out of a part and it's critical, you need to know how to replace it. And that means note what's critical about your parts. If you don't give a shit what value or resistor is, say that in your bill of materials that you keep private and release later. If it's very critical that an amplifier is not subject to noise, write that down because otherwise in two years, when you forget why you picked that amplifier, you're gonna shoot yourself in the foot. Okay, so best practices for PCB prototype is all of those things have rules that go along with them. You should follow them in the layout and then just iterate until it works. Pre-tape out checklist. This is what you do before you pray. Go through and actually make sure that you fixed all the bugs that you're like, I'll fix that later. That's really annoying. Make sure that everything matches again between the PCB footprint for the part and what you are actually buying. Don't put MOSFETs in backwards. You have to jump with the staples and it's a bitch because staples are hard to solder. Make sure that all the pinouts are correct. Make sure that your schematic matches your prototype. Like, don't change things on the fly that you can't prove that they work. And then just go through and be very anal retentive about the layout. Your vendor will thank you because otherwise they'll come back and say, I can't build this, what the fuck is your problem? Slide. So this is a fabrication package checklist. This is what you send to a manufacturer when you want them to build your design turnkey. You might say, well, I don't need this if I'm building it myself, but the answer is you do because then when you forget because you're cracked out after 48 hours of staying awake building things, you have your references here. You've written it down. You save yourself time. Next. So, and this is the design documentation checklist. And most of this you should have already generated during your process. And then it's just really easy to open up to other people so they can learn from your process. Both from the goals, the system block diagram. I literally do break everything down by that block diagram and have a paragraph in my user document about stuff. Did I do this for the Ninja badge? No, not yet because I didn't do it before. And it's a year and a half later and it's still not done. Same thing with your software firmware, Safari and how a user should use it. So next. So you're like, are these things I should do or things you should talk about? The answer is both write down your rationale as you go along and then that document generates itself. And then the next person can come and work with you because slide, the predicate of read the fucking manual is write the fucking manual. And slide. And documentation should be a dialogue. I should see that you made a really awesome RF widget or a near field communication widget for this Android phone and I should be able to be like, oh hey, oh he found out that like this part from this vendor is a piece of shit and you should always use like the free scale part. Oh, awesome. I'm never gonna like make that mistake again. So if you write the story and I write the story and we both put it out there, we can really build awesome systems. Slide. So the added benefits of openly discussing your process are one, you seem less hardcore because everyone sees how much you mess up but then you get to defeat things like analyst bias where you assume that I'm perfect or asshole bias where you assume that you're perfect or cargo call bias, which is like what everyone does with radio they say it's black magic. If I copy it exactly, it will work not understanding any of the underlying process parameters of physics that might make it not work. Slide. So the real world example is that robotics controller I built. I've been able to hand the documentation and it hit off to a bunch of different people and it's gone in things from microscopes to diagnostic machines and human assistive robotic devices and I've had to do maybe about five to 12 hours of extra work. It's wonderful. Slide. You know, it's the same thing whether or not you're doing it for a hobby or whether or not you're doing it for industry. This basic documentation just you start to get into things like how does your stuff fail over time and temperature and in the field? And it's just a matter of details and complexity but the form of the process and the form of what you want to document is always the same. Next. So the more you share and the more others can question your design and question your sanity when you're making something, the faster that we can all learn from our collective mistakes and the sooner we can celebrate our collective successes and make much, much more excellent systems together. Thank you.