Stephen is on the hunt for the next step in his electrical engineering career and shares the shifts in the industry and what employers are looking for.
Why is there such a disconnect between component datasheet drawings and EDA footprint layout tools? Stephen and Parker dive into this on this podcast.
What are the pros and cons of becoming an electrical engineer? With great power comes great responsibility or just the lack of sleep!
Visit our Slack Channel and join the conversation in between episodes and please review us, wherever you listen (PodcastAddict, iTunes). It helps this show stay visible and helps new listeners find us.
Robert Keim from All About Circuits
Parker is an Electrical Engineer with backgrounds in Embedded System Design and Digital Signal Processing. He got his start in 2005 by hacking Nintendo consoles into portable gaming units. The following year he designed and produced an Atari 2600 video mod to allow the Atari to display a crisp, RF fuzz free picture on newer TVs. Over a thousand Atari video mods where produced by Parker from 2006 to 2011 and the mod is still made by other enthusiasts in the Atari community.
In 2006, Parker enrolled at The University of Texas at Austin as a Petroleum Engineer. After realizing electronics was his passion he switched majors in 2007 to Electrical and Computer Engineering. Following his previous background in making the Atari 2600 video mod, Parker decided to take more board layout classes and circuit design classes. Other areas of study include robotics, microcontroller theory and design, FPGA development with VHDL and Verilog, and image and signal processing with DSPs. In 2010, Parker won a Ti sponsored Launchpad programming and design contest that was held by the IEEE CS chapter at the University. Parker graduated with a BS in Electrical and Computer Engineering in the Spring of 2012.
In the Summer of 2012, Parker was hired on as an Electrical Engineer at Dynamic Perception to design and prototype new electronic products. Here, Parker learned about full product development cycles and honed his board layout skills. Seeing the difficulties in managing operations and FCC/CE compliance testing, Parker thought there had to be a better way for small electronic companies to get their product out in customer's hands.
Parker also runs the blog, longhornengineer.com, where he posts his personal projects, technical guides, and appnotes about board layout design and components.
Stephen Kraig began his electronics career by building musical oriented circuits in 2003. Stephen is an avid guitar player and, in his down time, manufactures audio electronics including guitar amplifiers, pedals, and pro audio gear. Stephen graduated with a BS in Electrical Engineering from Texas A&M University.
Special thanks to whixr over at Tymkrs for the intro and outro!
All right. Welcome to the macro fab engineering podcast. I'm your guest, Robert chyme.
And we're your hosts Parker Dolan
and Steven Craig.
This is episode 125.
Robert Kahn is a graduate from the University of California of San Diego with a bachelor's degree in electrical engineering. Robert has an extensive experience in a wide variety of fields, including analog design, firmware development, digital signal processing, power management, motor control, digital camera design, low noise, PCB layout, system integration, designed for harsh environments, neural networks, and software defined radios. Robert is the technical director for all about circuits.
So Robert, what don't you do?
There, there are quite a few things. So I I've been fortunate in my professional experience. And also with all about circuits, I've been fortunate in having the opportunity to do a wide variety of design work, analysis, work, testing and development. So it keeps me interested, I don't like to be confined within a very small intellectual space.
Yeah, that's that's a pretty impressive background there. That was quite a quite a mouthful worth of worth of stuff you've done for sure.
Yeah, no, it's, I mean, a lot of this is from one I worked for a defense contractor. And, and we did a wide variety, we had a wide variety of projects, and I would just go from one to the next. And it seemed like everyone was something different. And it was great. I mean, I learned so much, because I was always doing new things. And there wasn't a lot of it was an excessive supervision, let's say it was kind of here's the project, make it work. And you know, you learn a lot when you have to learn things on your own.
Totally. So is there anything else that you want to? Well,
despite that long list of engineering activities, I I also am a professional copy editor and a professional writer, and actually identify now more as a writer, as a language professional than as an engineer, though I do both. And that's how I became involved with all about circuits. The website, I started as a writer for them, and then everyone sort of realized that there was another role waiting for me. So I became a technical editor, and helping to improve the technical accuracy of all the articles published on the site, and then became the technical director. And now I manage help to manage the contributors help to ensure technical accuracy in all the publications. I'm also the lead technical writer. So you know, if anyone visits the site, you'll see that I have a large, long, long list of articles that I've written for all about circuits. So I kind of stepped really stumbled across a position that allows me to combine not only my engineering skills, but also my skills as a language professional.
Cool. So I think the topic this for this podcast is going to be the role of open source information in the electrical engineering community.
Yeah, it's, it's something that, that I work with a lot, you know, being involved with all about circuits and managing the content, writing content, you know, all the content is freely available, and design files are made freely available, firmware is made freely available. So it's something that we think about a lot, and that we interact with a lot this issue of, well, there's value in this intellectual property, there's value in this knowledge, but we want to make this knowledge and this design information available to everyone for free. But then you still need to generate income somehow. So it's, it's an interesting concept, this idea of making information, even design information that potentially involved many hours of labor making that freely available, but also maintaining the financial integrity of an organization.
So I guess the first good question will be is What does open source mean to you? Now? This is a question I think, for all of us.
Yes, I agree. It's a question. I think for anyone who's involved in the prototyping movement, who's involved in helping hobbyist young engineers develop their own designs, and improve their design skills? What does it mean to me? Well, open source I think is typically associated more with the software world and I don't write software. I'm not a software person at all. Do firmware, low level firmware design, not software. So to me, open source isn't really an AI isn't related to this idea of I'm going to write a bunch of code and make it available to everyone and they can modify it and do whatever they want with it and compile it and what have you. To me, open source means knowledge that's freely available, including knowledge that in that arena generates from labor, such as writing for more module or even designing a schematic. So, to me open source means the idea, the conviction that there's inherent value in making information and knowledge available to people anywhere in the world for free.
I would I would agree with that, um, I view open sources not as Oh, I can go and copy that, but more of a, oh, I want to see how that thing works. And so I can learn about it and incorporate it into my project,
right? I mean, when I design a schematic, and I write an article about it for about circuits, and I make the design files available, you know, the idea isn't, Oh, someone's gonna take this and duplicate it, and manufacture it and make a bunch of money. I mean, I guess that could happen. But it's extremely unlikely. You know, what's in my mind is, well, if someone really wants to learn, I've got this article text here that I try to explain things clearly, and try to focus on some interesting details. But in the end, the person has to interact with this knowledge has to interact with this design, this is how you really learn, it's the feedback cycle of first you receive, but then you have to produce then you receive again, and you refine what you've produced. And it's a cycle that eventually leads to true acquisition of knowledge. So when I make those design files available, that's my attempt to to give the reader the ability to really incorporate that knowledge to really reach true understanding of the material because it allows them to interact directly with the manifestation that I have created of this particular concept.
I really liked that, I think I think that puts a lot more of the the emphasis on the knowledge and the understanding as opposed to just purely execution. Because if it is just execution, then in effect, you're just providing a kit in a way and there's nothing wrong with that. But a kit sort of has boundaries that it fits within it exist as as that one item, whereas like just providing knowledge, like Parker was saying you can you take that you explore that, and you put that into your own usage. So I really liked the way that you you put it
I think you expressed it really well to when you say you know the difference between understanding and creating versus execution, you know, in this in the current environment that we have, there are a wide variety of resources that will help someone to execute, you know, it's basically this the step by step, or you can download a reference design from TI and copy it or, you know, or you can buy a kit that is maybe still involves a little bit design, or maybe not much design at all. But there there are many ways to execute. But kind of my mission, and to a large extent, what all about circuits focuses on as well is that we don't want to just provide a path to execution, we want to provide understanding knowledge, growth, so that the reader so that the people who are looking for this information become designers themselves, and not just imitators, not just people who follow directions.
So you touched a bit on it earlier, but like, do you think that open source projects can be, you know, long term financially successful? Or do you think this is just a social movement? And is it more about bringing knowledge and foot that functionality to the
community, it's certainly the ideal is to bring knowledge and functionality to the community, but we live in the real world, you know, people like me who write articles, we have to eat too. And so we and furthermore, I don't really believe in this idea that really excellent material, or excellent content, or excellent knowledge can be had completely for free, you know, that we all have to live we all have to we all have only so many hours in the day. And then people who have, you know, the best knowledge and or who have, you know, truly reliable knowledge and reliable skills? Well, you know, we usually have to go to college and college costs a lot of money too. So there's always money involved. I think that the interesting aspect of this commitment to open source is, is the commitment to make knowledge available for free, but also the commitment to try to be creative in producing the income that we need to sustain the movement and trying to be creative and figuring out how to bring in financial resources for the benefit of the community but without burdening the community, especially those who are not able to pay or who are in a different country where the economy is different. You know, so that that's it there's a delicate balance there between maintaining financial integrity and making information freely and readily available to everyone who wants it.
So it Do you think that may be jumping the gun a little bit here, but what do you think the future of open source looks like? It looks more like a more thriving community environment.
I think the future of open source, I, you know, maybe this isn't really idealistic. But I think the future of open source is more or less what it's gradually becoming right now, which is groups of people who are committed to it, and you have the knowledge and you have the skills and are ready and willing to make this information available to anyone anywhere. But the funding has to come from other sources. And well, the fact is, people are not going to be manufacturing integrated circuits in their garage. They're not going to be fabricating sophisticated printed circuit boards in their garage, there, there are inevitably organizations that will have to make things and sell them at a profit. And so I think that it's kind of like the way that a government subsidizes a university, you know, governments typically have quite a bit of money. And one of the better things that they do with it, is subsidized universities so that people who don't have so much money can learn and become educated and skillful. So I think that those corporations out there need to embrace this movement as well, they need to make a commitment to support it financially. I think everyone benefits in the end, but you know, they have to be convinced perhaps that, that this is something that's worth their commitment, that's, that's worth an investment of financial resources on their part so that other people can pursue the open source ideal.
Very cool, very cool. Okay, so next question we have on here is version control for PCBs. Parker, you want to you want to take this one?
Yeah, actually, I was gonna backpedal a little bit on that open source projects for long term financial success. Because of its, if you're, if you're a maker out there, and you're doing an open source project, it, it kind of fizzles from my experiences, it only really works, if you have a really nice project. Cuz like, if you take let's for the example, the Arduino project, the software is only built by the community. And it's supported by the financial success of selling the hardware, which is also open source, but then you have clones and stuff like that, that are there, they, those companies that are making the clones aren't really driving the software development, but it's the people who buy those clones, and then go, oh, I need to, you know, give back to the community or find a bug and, you know, report it and stuff like that.
Yeah, I think there are several dimensions there. And in the end, I think what it comes down to is that a variety of people are involved in maintaining this movement. And like you said, even the user is to an extent, even, perhaps a user who's still learning still a student, doesn't mean that they can't contribute to the success of the movement. cran, you just you gave a perfect example, find a bug? Well, you might be a, you know, in your first year of college, you can still find a bug. And and you report that bug, and that could help 1000 people, you know, so I, you know, there are there are organizations that have quite a lot of money, and they certainly have a role, but at the same time, everyone has a role in in supporting this movement and helping it to remain viable in the long term.
Correct. Yeah. So next question was version control for PCBs? Because, however, version control for a, let's say open source project works, compared to say, an open source software project. Interesting
question. I, I think, to an extent, there's a pretty large gap that separates PCB version control from software version control. I mean, version control software is a pretty fundamental critical aspect of the development process. I think, with PCBs, it often is less critical. I mean, for one thing, you generally don't go through so many versions of a PCB, in many cases, I think, maybe only one if you do a good job the first time. But if we're talking about making design files available to the public, and then a certain design gets adapted by different people for different purposes, with minor modifications, or major modifications, I think in the end, it will be difficult to control something like that. I don't know. Like with GitHub, I don't know is does GitHub have a platform for for hardware, or is it only software?
It does hardware in the sense of it will version control the files you give it? Because that's the thing about PCBs is it's really a lot of visual stuff, like where parts are placed and how the schematic is laid out. I guess you could do kind of like because the big thing with version control for software is seeing the changes in how the lines of code have changed. What's been added what function was removed or changed? But you don't really have that with PCBs? I guess you can do like, no netlist changes and stuff like that. But yeah, it's not really a, a place for it on something like GitHub, besides just storing your files.
Yeah. Well, and, and GitHub handles it like code, I park. And I've actually, we've, we've kind of mentioned this before, where, you know, it seems like there's, there's general ideas on how to revision code, and people kind of stick to some paradigms out there. But when it comes to hardware, they just kind of make a hardware file, and throw their boards in there. And just, it's sort of, it's a little bit of like, good luck with it. So, you know, when it comes down to something like that, I think, probably your best bet is to just, you know, keep keep a version in the title of the of the files, whatever your PCB schematic is, and then wherever you can write notes, if you have a roller rev, you know, just at least write some notes describing what's different.
Yeah, I'm typically because I use GitHub for my stuff for my hardware projects. And usually I will, it they have a release function, and Aiden, why, you know, get a board made, I just click release, and that's the files I send off to get made. There was a I don't, I don't recall the name. But there was a GitHub like, websites that does like, like, get like Gerber differences. I think there's a company called CAD lab that does revision control for like, only Eagle boards. So like, you can see the differences and how the traces are laid out and stuff.
Well, it actually highlight the difference between the two. I think so i
But it only works for Eagle. That's pretty cool. Actually. I think all teams got some stuff like that, too. But yeah, it's a difficult problem.
It is, I don't know if there's, you know, if we really have the tools that we need for that, at this moment, it's not widely available. But at the same time, honestly, in my opinion, there's not as much need for it, especially with the smaller PCBs. I mean, if you're designing a motherboard, that's kind of a different story. But, you know, I think that the audience that we're talking about right now, we generally are not designing motherboards, we're designing wearables and IOT devices and sensors, and processor boards and whatnot. So you know, the amount of design information contained in a schematic like that can't really be compared with, you know, potentially the length of a code project of a firmware project for that board. So I, I think, in a lot of cases, the version control the adaptation, the modification can be done fairly manually. And I think that can be effective.
Yeah, that's what Stephen was talking about, like, basically, for every release, you have a change log that you've updated. Right?
Yeah. But that ends up being a really manual process, which is fine, you just have to stay on top of it.
How do you collaborate multiple engineers on a single PCB?
Well, that is a tough one. I mean, from my professional experience, it's not really done. And not that it can't be done. But I don't, I don't know that it's the most effective way to produce a good PCB. You know, I know for myself, when I get really involved in a, in designing a schematic, or also laying out a board, I'm pretty intensely immersed in that project, it's kind of you kind of have to really submerge yourself in the identity of that board. And its its functionality and its purpose. It's it's an intense connection that I use, you know, when I'm designing and I don't know, for me personally, I don't think that I could really tolerate, quote, interference from another engineer. Now, design review, Design Review is a different story. I am the first person to go out and ask for suggestions and corrections, and concerns and comments once the schematic is done. But I don't think that personally, you know, in the midst of that design process, I don't think that I would want the, quote, help or collaboration of another engineer, it's just the connection is too intense, and kind of it's bipolar. There's not really room for another member in that in that experience.
Yeah, that was the the biggest concern from a couple of our listeners was usually for open source projects is for hardware is there's 1% Does like 99% of the work and sometimes you know, that person just gets burned out and then The project kind of dies.
Yeah, I mean, I think when you have, I'm typically designing smaller boards, I think if you have a larger project, this is where the system engineer comes into play, you know, a good system engineer who can really break down the functional blocks of this design. And this has to be done carefully. But you know, someone, a good engineer can do it. And if you really break down those functional blocks in a logical and effective way, and then you carefully develop the interface document, you carefully establish the interface specifications that describe the interaction between blocks, I don't see why you can't assign those blocks, as separate engineers, you have to be diligent in respecting the Interface Specification, you have to be diligent in perceiving this design as a part of a larger hole, you know, as a component and a system, not as your own personal design. But, you know, I think that even small teams, even startup teams, or something, if they're designing a complicated board, and this is a skill, they should develop, really partitioning and design into functional blocks. Diligently establishing the interface specifications, and then allowing separate engineers to work separately, and then you have an integration session at the end of that.
So you were mentioning? Yeah, yeah, you're mentioning in your your actual design review, you were you were saying you prefer to do kind of design reviews at the end of schematic generation. I'm curious if that's like, in general, like the way you normally do it across the board, or if that only applies to small boards. The reason I'm asking you is just out of a personal preference. From my side, I like to do design reviews, not every step of the way. But more often than you know, once the schematics done. So I'm just curious about your personal preference on that?
Well, it depends on the complexity of the project, I think that if I were in a more professional environment, and I were doing a project, that was they have complicated interfaces, or a variety of functional blocks, you know, to me, kind of the the standard of excellence is three design reviews. One is you're basically presenting your plan, you know, block diagram more or less, and then one after the schematic is done, and then one after the layout is done. That's not always feasible to get that much feedback. But for me, my feedback is golden, especially when I'm working with seasoned engineers. So I, to me, to an extent, the more the merrier. I mean, there's limits, of course, but there's so much value and putting human beings physically together in a room, you know, print out, I know, it's, you know, we don't like to print things out so much these days, but I'm sorry, you print out that schematic, you know, get everyone a copy of it, and you sit there and you really turn your brains on. And powerful things happen. When human beings get together like that, and really make that effort to combine their intellectual abilities and combine all their experience and combine all their concerns and, and different approaches to solving problems. So you know, like I said, higher complexity project, basically, conceptual design, review, review, the block diagram, schematic design, review and layout design review,
I like how you brought up the block diagram design in, I think that's overlooked quite a bit in the initial hardware design for for projects. And it really helps you get that block diagram block down, it really helps limit your scope creep later down the road?
Absolutely, absolutely. I mean, in the professional environment, projects typically start with a requirements document. And not to say that it doesn't evolve. But at the same time, there's a document and if your design fulfills that document, that's a success, if it doesn't do something that somebody wants, but that something isn't in the document, you're not held responsible for it. So like you said, this kind of gradual, oh, but this would be nice to have. And this would be good. And well, what about this? And oh, boy, did you put this in there, so on and so forth? You know, well, there's value in a discussion like that, but at the same time, the engineer has to be able to point to a document or to a block diagram for a simpler design and say, Look, I'm trying to design to the document. And if you really need these features need to talk to the program manager and have them inserted in the document. So getting all official with it. Well, you know, this is again, with a higher complexity project these things can fall apart. I'm I'm trying to, I'm trying to give some advice that I think will help small engineering teams or growing engineering teams to develop successfully and efficiently develop higher complexity PCBs and higher complexity systems. And the fact is, it has to be organized or things can become very frustrating. I mean, it can even go so far as losing a team member if someone just gets sick and tired of constantly redesigning a board because You know, people always want additional features, and then they start to blame it. Well, you didn't put this in there, you know? And then what wasn't in the wasn't in the requirements document, you know? So it helps to get everybody happy.
Yeah, I, I would agree is on the I've definitely stopped working on open source projects because of scope changes. And like, I am not redoing that section of the board. I've already read on it four times already.
You reach a limit. I mean, in schematic design, good schematic design takes time, and you reach a limit when, you know, when you constantly are redesigning something that was functional the first time, you know,
correct? Well, and I think that's, I think, honestly, you hit on the head with the exact answer to that question of it. At first, when you asked that question, how would you collaborate with multiple E's on a single PCB? The first thing that comes to mind is, well, how does everyone you know, log in and actually, like, move things around on the schematic and PCB or the layout? And the answer is, one guy typically does that, but everyone has their input on it, and everyone does it in an organized fashion.
Absolutely, yeah. Yeah, it could be, you know, you have a brainstorming session with all the designers and you come up with a block diagram. And then the next session, you pick components, that, you know, this is the kind of microcontroller we want to use, this is the accelerometer, you know, brand, or whatever, etc, etc. And then someone comes up with a schematic, then you review, then everyone reviews, the schematic, and then so on and so forth.
Now, that would be cool if GitHub had a way to handle all of that interaction, too, without getting too chaotic.
Yeah, I mean, I think that was software. Again, I don't have experience in software development. But I think that, you know, there are tools that allow software development to proceed fairly efficiently. With a variety of people working on the same piece of code. I don't know exactly how these things work. But you know, somehow the tasks are divvied up. And the code modules somehow are consolidated into something I don't know, that's my impression. But my point is that I don't think that same model can be applied to PCB design, it really, I think, comes down to one person who's putting the components on there, double checking the footprints, making the connections, double checking the resistors have the right power rating, etc. But this one person needs to have a network of contacts, experts, etc. So that he or she can consult and benefit from other people's expertise.
So Steven, cuz you've worked at other companies and design boards? How did y'all handle projects?
Oh, you know, it was similar to that. However, it was potentially a little bit, a little bit more loose. Just because the companies I've worked with, funnily enough, I've worked in teams that have multiple engineers, but I've actually never worked on a team that has had more than two electrical engineers at any one point in time. Plenty of other mechanical engineers, and blah, blah, blah, but the electrical engineer seemed to be, you know, a little bit more scarce. And so, you know, that person was working on, you know, 15 other projects, and I was working on 15 other projects. So it was, it was a little bit more rare to have the other electrical engineer, you know, have time to really sit down and look at your stuff. But we tried to as much as possible. So, you know, what we just described, it was a really, in my opinion, it sounds like a really, like, fantastic and ideal situation. And it just doesn't always work out that way. So we attempted to, but it didn't always turn out
that the previous company before Mac fab, I was the only engineer. So it was like, we came up with like, a product design. And then I executed it. And then we went through a like iteration of each product. And that was about it.
Right, right. Yeah. And sometimes sometimes that's just the way it goes. Sometimes you you kind of have to check your own work. I have done like official reviews before. In fact, I had one. One engineer hand me a project he was working on. And it was he was about to go to, like first prototype. And basically I was asked to take as long as it took and it took three days, but I went part by part checked every footprint checked every datasheet check every piece of his design. And yeah, it was it was it was three, almost three full days of work looking at it but and I found a couple of things too. And it was you know, there was a few things to change. Some some things that were designed things, some things that were just like, Oops, you chose chose the wrong footprint here, whatnot. So it is really valuable if you get the chance to do that
cool. Guy. Anything else. Robert, to add to open source?
Um, no. I mean, I think that again, it's it's something that we all need to be aware of, and that including corporations and We need to consider what we can do. Writers, readers, corporations, manufacturers that are what we can do, to make sure that high quality knowledge is available to people everywhere, but at the same time that we can maintain financial stability, because this is how high quality material is produced, you know, people need to put live and even have a house to live in.
So, actually, I'm going to add another question here is, what what is the best thing one of our listeners can do to help open source, like, just in general,
I think it really depends on you know, your position in the movement, your position in the field. You know, if you're a skilled professional or an advanced student, well, then you have knowledge, which can be made available, there might be various ways to monetize that, and I'm not an expert in that field. But but the point is that we don't, we don't want the monetization to seriously interfere with someone's ability to make this knowledge available. And to help other people to spark innovation. You know, it's kind of like how fire spreads, you know, is that innovation begins somewhere, but by providing knowledge, you can help to spark innovation from other people. And so again, if you're a professional, if you have special skills, or advanced knowledge within you find ways to make that available, while also maintaining, you know, maintaining your income you need or, you know, make sure you have time for leisure activities as well, you know, these people that go work a nine to five job and then spend all night, you know, writing their blog or developing a website, like, well, we need to have balance here, you know, because that's, that's, that's a recipe for burnout. You know, and it's a human beings don't work that way. So we need to be able to find balance between work and recreation and enjoying life, but also being willing to do work that doesn't produce immediate remuneration. In terms of financial resources. If you're still more on the learning side, you know, you're a undergrad student, or just a hobbyist, or young engineer that maybe didn't get a really practical education. And I understand that completely, you come out of college with a lot of theoretical knowledge, but don't know how to design a circuit. Well, you don't be afraid to access to make use of that open source knowledge, which is available on all about circuits, of course, is what I'm familiar with. But there are a wide variety of websites that make this knowledge available. And furthermore, to interact, you'll be a member of the community don't You don't have to just read the article and then be done with it. You know, there's there are forums, there's a you can comment on the article, you can request information, you can request to become a contributor and write articles about whatever you happen to have expertise in. So it's, it's a matter of participating and as open source material, not just by reading, but also by commenting by contributing by becoming a member and active member of the community.
How this will actually just jump to this one is. So if you're designing a product, does this doesn't have to be open source or related or not, but as a do you do it form following function or function following form? Basically, like, do you find how you want the product to look first, like the case and out someone uses it? And or is it the other way around?
Well, obviously depends on the on the requirements of the project, and, you know, maybe on how much time I have available or what resources I'm working with, but in general, you know, I'm kind of a, you know, I'm kind of a hardliner, when it comes to electrical integrity and good design practices. So I generally, you know, I'm going to design a schematic according to my ideas about good design practices about robust design. And and then when I lay out a board, you know, it's generally going to follow follow the electrons so to speak, you know, that I'm, I'm looking at the the performance characteristics of the board, I'm looking at what's going to maximize my single signal integrity, I'm looking at what's going to provide low impedance pathways, what's going to provide a good ground return, what's going to provide clean grounds, you know, for my analog and digital circuitry, and so, I generally let the electronics kind of guide me I let the I let the electronic concepts and, and and needs drive the design. And, you know, I might adjust at the end, especially if there's a certain form factor I have to me but again, if I'm going to go to the trouble to design a circuit board manufacturer and assembler one way or another, you know, I really believe in doing whatever I can to maximize signal integrity, maximize reliability. Woody. So that tends to be my emphasis that tends to be what drives the design.
Yeah, this this reminds me a lot of hitmen which iPhone it was, but it was like the iPhone seven or six, where they actually had to modify one of the BGA packages by cutting out a cord. So they can fit a capacitor. And it's like, that's really one of those. Okay, they're really going for the form, because they didn't, you know, build their PCB large enough for that the Fit otherwise.
Yeah, I mean, these things happen. These things happen, right. But I think it's ideal when you know, or at least the better approach eliminates situations like that. Whenever possible,
yeah. Yeah, I typically will do the schematic and then do a rough layout, and then be like, Okay, what do I kind of want the scene to look like in the end, and then find an enclosure or get something custom on like, okay, I can, this product can use a custom enclosure, because the margins high enough and stuff like that. The best option is just to make it the best performing board. And in this 3d printer, custom enclosure, right?
Yes. And that might work for a one off.
But for, you know, 1000s?
Well, and at the same time, I think we have to recognize that maximizing performance and maximizing signal integrity isn't always the first priority. I mean, as an engineer, especially an engineer, engineer, dedicated education. You know, that's typically my priority. But if I were working for an engineering company, designing consumer electronics that were basically designed to be replaced after a year, has to look flashy, or it has to fit in your pocket or what have you. Well, the fact is that signal integrity and and high frequency performance, and what have you, isn't always the first priority. And so it depends on it depends on what the people in charge are saying.
Yeah, it's, um, it also reminds me a lot of the term cutscene, which is basically going through your product and removing parts that, you know, they're not required to make your product work. I don't know if y'all know what the background from that term is?
No, no, yeah, the guy who went and popped off bypass caps. Now this
is this is older than that. This is in back in the 40s, and 50s, with television receivers. And so the engineers would design a TV that would work everywhere, like so it would work really far away from tell from the broadcast stations. Well, most people live in the cities, and they have a really strong signal. And so he would just go through and just remove all the parts that weren't really necessary if the TV was supposed to stay inside, you know, the city. So yeah, his name was a madman mutts
saying, Yeah, I could imagine that. You know, what the fact is, there often are a lot of components on a on a board that are not strictly necessary, you know, they're there to make the board more reliable, or just to cover unforeseeable circumstances or whatever. But, you know, if you have to make it fit in a small enclosure, you have to save every penny, every penny, inevitably, some of those will be eliminated. And that's, that's the reality of engineering. And,
you know, well, it's just different words.
And we know what that actually is. That actually goes back to what you were saying earlier with the, you know, a lot of times, the engineer will just get a spec sheet of here's what the design needs to do. And sometimes that spec sheet will give you the information you need to know to give you like, just to be just good enough engineering, you know, it might say, hey, yeah, we need a really fantastic TV, but it only needs to work in the city, you know, and that, and that should give you enough information, such that you don't have to design the most amazing thing on earth. It's just good enough.
Yeah, yeah.
Well, that's like the famous scene is like one word to describe engineering. Good enough.
I think it's very true. You can always make a design more robust. You can always add features. At some point, you have to stop and say, Okay, what does this thing really need to do? And that's what you designed to? Yep. Right.
Right. We were actually talking about it earlier today at work. It engineering is just educated compromises. Just a whole bunch.
I like that a lot. Yeah, it's a good one.
Yeah. So yeah. Um, so Robert, what is your favorite article that you wrote for all about circuits? And why?
Hmm, it's a tough one. I've written many. I think that one of the most popular How about
one that you just remember?
I think that was let's see if I can see I'm sure I remember at least one of them. I think that one of the most popular also happens to be one of my favorites, which is actually a series that I wrote on. It's called the clean power series. And the first two articles are about decoupling capacitors, essentially. And I, I'm one of these people who I'm not satisfied, if we don't understand something, you know, everybody knows how to put point one micro farad capacitor, you know, next to their microcontroller. Okay, fine. But, you know, you have to go deeper, and I'm just not satisfied. Why?
Point one micro?
What's that?
Oh, I said, Why point one? microfarad?
No, exactly. And the article talks about that talks about the value of talks about, you know, the case size, or at least one of the articles in the series, you know, in other words, essentially says to the reader, okay, I know that, you know, you're supposed to do this, but what's really happening? Why is it necessary? How do you optimize a decoupling design, you know, then the third and fourth article in this series, if I recall correctly, are about ferrite beads, and you know, the sort of complementary role of ferrite beads and providing clean power to your integrated circuits. And again, I think those articles are all kind of emblematic of what I enjoy the most, the most, which is really penetrating into the heart of the matter, really going deep into the theory and to the conceptual framework, and to the, the real engineering knowledge and the things we learned in school to an extent, but then applied, applied, manifested in coherent form. So that we're, we're, we're combining practical techniques with theoretical knowledge in a way that actually makes our designs better, more robust, higher performance, whatever. So. And I think I have a variety of articles like that. But that's what comes to mind is, you know, the clean power series, taking something as universal as a decoupling capacitor, but really digging deep, what is this about? What are the underlying concepts? Why do we do this? How do we optimize it?
You have anything Steven?
I'm gonna have to go read that series. Actually, no, it's funny, we got an intern at work. He just started, I think, last week, and today, he and I were going over bypass caps, and he didn't realize he's just a junior in now in electrical engineering. And so like, this is their sort of a new concept for him. So I'm totally gonna send him the link to this now. That's great. Cool.
So um, well, another thing, Robert, is, what's your favorite microcontroller slash dev board slash toolchain?
Well, I, I think to an extent I'm a little bit I don't know if it's it's a bias. I don't know how to describe it. But somehow I ended up using Silicon Labs for almost everything.
Oh, yeah. That's my favorite right now.
Oh, is it really well, there you go. I don't know, in my experience, and maybe this is just again, a biased perception. But it seems to me that professional engineers often favor silicone lamps devices, whereas they're much less known among hobbyists, or younger students, I'm not sure if it's just a marketing thing. Or maybe maybe they cost more in at least, you know, in small quantities, I think, I don't know, but I've been using them for a long time. And I find that they're, their data sheets are very clearly written and have good diagrams and are accurate, I find that the chips are reliable, that they're high quality, that they they have a wide variety of devices that offer a different collection of features. I guess I think maybe initially Silicon Labs started as started by really emphasizing the mixed signal aspect of microcontrollers. Now I think it's very common, but maybe originally, I wasn't really in the game back then maybe originally it was more unusual. And that's another reason why I became kind of connected with Silicon Labs is because as you know, when I first entered the engineering world, I was doing mixed signal basically everything you know, analog digital conversion, and and so, I wanted microcontrollers that could do all these things, you know, they could do the digital analog conversion, analog digital conversion, competitors, what have you. So then I but as I continued to use them, I was more and more pleased with the quality of the chips with the reliability with with the, the the wide variety of features and then on top of that, the development boards were widely available even when I was working in the professional world, we would use their development boards quite extensively. So the development boards are widely available and reasonably priced. And then the tool chain I've always found it to be adequate that you know, the newest one, which is Simplicity Studio, sometimes. I'm kind of more kind of old school I just appreciate Do more bare bones approach. I mean, I like you know, configuration tools help you configure the hardware, you know, that's convenient, as long as they work, which not always, but usually they do. I mean, Silicon Labs, I think is reliable. But I know what you're saying you can't you know, you have to be careful. You have to, you have to double check. But yep. So I found the tool chain to be very effective, easy to use, not bloated. So I, what can I say I, I really, I'm afraid I've kind of given up on branching out into other manufacturers. Man, I've used that mill. I think I've used something else. But But honestly, I've just kind of given up I'm so satisfied with Silicon Labs that and I don't I, you know, I'm getting older, I don't want to have to relearn, you know, the details of the hardware and the interfaces and, you know, the, you know, getting the oscillator started properly, or whatever, it's just I know how I know how to use Silicon Labs devices, I know how they work. I've I've, you know, basically worked out all the the bugs and the hardware design mistakes. And so I I basically use them all the time now.
It there's something to say about not having to read learn the basics. Between projects for the site kind of stuff. Yeah, I mean,
it. I honestly, it scares me, I the, you know, I have this kind of fear that I'm going to get some contract from someone who's going to mandate that I use matte mail or that I use, I don't know who else to pick 16 Yeah, yeah, exactly. You know, there's give me the exact part numbers are great. And I'm gonna break out sweat. Because how many hours am I gonna have to spend reviewing the details and looking at all the little intricacies of the the low level hardware and how to configure the hardware. And then of course, the worst case scenario. So I have some elusive bug. And, you know, with Silicon Labs, it still happens sometimes. But it usually is resolved fairly quickly, because I probably run across this same bug, you know, previously in my engineering career, but if I'm using a new microcontroller, who knows, maybe I'll lose the day trying to track down some bug or some, you know, you know, improperly configured hardware peripheral or whatever. And I don't want to spend my time that way.
All right, one last question, Robert. Yep. You ready for it? Is a complete departure from everything else to is? Where do you see EDA tool? So those are tools that you design your circuit boards in? In five years? How are they going to change? And actually what EDI tool that you do you like to use? I use dip trace? And what do you what do you hate the most? I'll
get to that? I used to dip trace, I used to trace it. I hear that? Did I hear that? Right? Yeah, you have? Oh, yeah.
The other end of the channel,
I it didn't make anybody, any engineer that comes anywhere near me asking about development tools, I will gladly speak for half an hour about the virtues of dip trace. Am almost beyond belief that it's not more well known. And I feel like some people will complain that it's not free. And say I'm sorry, it's not free. But you know, I pay I just bought $1 pair of shoes. Okay, I'm willing to pay $80 for a pair of shoes, it's gonna last me a few years, you think that'd be willing to pay $80 for a PCB schematic for a schematic and PCB layout tool that I can use basically, indefinitely. And that is very sophisticated and reliable and easy to use, and so intuitive. Maybe I'm wrong, maybe it is well known. But it seems to me that it's not. And I think that's a sad thing, because they're selling an excellent product at a very reasonable price. And it's extremely intuitive, which for me is is virtue number one because I hate reading, looking at tutorials, I hate reading manuals, I hate, you know, searching around trying to figure out how to make a new footprint or whatever. It's intuitive, it's reliable, it has the features that I need. And I really I commend the the designers, I think they made an excellent product.
It and it just left click button. Which that's kind of nice.
Yeah, I mean, I think maybe some people consider the interface to be a little bit awkward. I don't know, you can always design something a different way and call it better. But to me what they have is totally functional. And so anyway, it's good, good. It's I would say it's been better than good enough. I think they really I think they went I think you're getting much more value than you're paying for that's I think the price is really reasonable. But I think even on top of that, you're getting much more than you're paying for. Lee's favorite. I think I've used a few that I don't like so much but here. Here's the irony is that the only CAD tool that I've attempted to use and basically walked away from the computer and discuss You know, figuratively speaking was Eagle. And I just find this comical because it seems like eagle is totally rooted in in the, you know, the the innovator community in the hobbyist community in the student community and I honestly am at a loss as to why I opened that program out. Okay, everyone uses Eagle, I'm just going to use Eagle, it's not even free anymore for commercial use, I don't know if it ever was actually. But the point is, I was amazed at how non intuitive it was. I mean, I was, um, was a fairly seasoned engineer, I couldn't figure out how to use the thing. So I'm not saying it's impossible, I'm sure that if I read about and use the tutorials, whatever, but to me, the interface was not intuitive. And it was not natural. And I didn't, I didn't like the appearance of it. So I I have to admit that my least favorite is Eagle,
we just can't be friends anymore.
i This is what I assumed would happen. I I accept this. I needed to speak the truth. But if you don't want to talk to me anymore, I understand.
Now that's fine. That's actually that's actually the biggest complaint I hear about eagle is is that but I mean, Eagle was the first professional I guess in quotes EDA tool ever used and like, I got it right away. Okay, I think it's just because I came from an old school CAD background. And that's what eagle is,
you know, maybe that's what it is. Because, you know, most of my design experience, my initial design experience was within a large company. And we had advanced tools. I mean, I think I used peak had originally and then later DX designer, or maybe another maybe a third one, I can't even remember. But the point is, these were very expensive tools. But they weren't high quality. I mean, it was intuitive. The interface was pleasant to look at. So that was my background. And I think that dip trace for me was basically a very affordable version of those advanced tools that I use when I was working for a corporation. It could be that I just don't have the background and the experience necessary to readily learn a tool like Eagle. And I readily admit it could be my problem could be mine. It could be my defects, not the software's it just, but that's the fact is that I tried it and I couldn't use it.
No, it's It's I've tried using dip trace and Ky CAD and I can't wrap my head around how they close. I'm like, why is this like this?
So it's it's a matter of your your background, your experience, right? I mean, that's the bottom line is that it's what are you comfortable with? What are you accustomed to? And so Exactly. Your mind
my favorite guest Robert, by the way.
And I don't I just want to be known I pay for dip trays. I've never asked for anything for free. I you know, there's no advertising relationship here. I just I think that when people make an excellent product and sell it at a good price, they should be recognized. Right and
Amen. Where do you see EDA tools in five years, I guess where do you see dip trace in five years? Well,
this is where I guess it gets a little bit controversial. Honestly, I'd like to see that. I like this in five years. I'd like to see cad tools doing exactly what they're doing today. In the sense that I don't want, I call it brain replacement software. And I think that cogitation intellectual exertion is something that is satisfying to the human soul, it's satisfying. In the in the context of the human experience in the concrete in the quest to achieve something to design something. There is a place for tools, there's a place for things like MATLAB, you know, especially people like me who can't fathom advanced mathematics, okay, I'm glad that MATLAB is there, but we have to find a balance. You know, we have to find a balance with respect to maintaining the opportunity and maintaining the need to exert ourselves intellectually, to still maintain an active role in the design process. And even you know, right now, you know, I don't use auto route, I don't use automatic component placement. I just, I don't think that they're really that effective, honestly, but that's my opinion. But even if they were I wouldn't use them I don't want to because it takes me out of the design process it and so maybe you can maybe it's it's okay to use an auto route and maybe the board will work but what are the unintended consequences? What are the secondary consequences of withdrawing intellectually from that design task and in my opinion, it's kind of a ripple effect you never know how the overall design might be influenced by the fact that you are not staring you know, with your eyes starting to water and you know, getting a headache staring at the computer screen doing every single trace optimizing every corner you know, checking the the trace separation looking At the width, the trying to even just make the board look more elegant or make the board look neater. You know, I think that the engineer needs to needs to draw a line and say, Okay, at this point, I am going to do this myself, I'm going to engage the mind. And I'm going to tackle this task. So, again, to answer your question, what dip trace does for me right now and other tools as well is exactly what I want it to do actually does more than I want to do. But I can ignore those features. And I wanted to say that way, I don't want to change, I want to be the driver. In this design process. The tool is there to be exactly that a tool. You know, I pick up a hammer, I don't expect it to build the house for me, but I can't hammer that nail myself. I cannot do it. But all I need is a hammer hammer and a sonic build house. I want that software tool to be a tool, not something that removes me removes me intellectually from the design process any more than it has to
do you have anything else Steven?
That was very elegant. Oh, you
want to sign us out?
Yeah, sure. I think that was the macro hub engineering podcast. I was your guest Robert Kahn
and we host Parker Dohmen. And Steven Craig later everyone take it easy Thank you. Yes, you are listener for downloading our show. Have you have a cool idea, project or topic that you want Steven and I discuss, tweet us at macro fab or email us at podcast at macro fab.com. Also check out our Slack channel we talk about open source projects all the time. If you're not subscribed to that podcast yet, click that subscribe button. That way you get the latest episode right when it releases and please review us wherever you listen as it helps the show. stay visible. helps new listeners find us
What are the pros and cons of becoming an electrical engineer? With great power comes great responsibility or just the lack of sleep!
Why is there such a disconnect between component datasheet drawings and EDA footprint layout tools? Stephen and Parker dive into this on this podcast.
Stephen is on the hunt for the next step in his electrical engineering career and shares the shifts in the industry and what employers are looking for.