Is grinding out math problems just busy work? Is the current state of Math class curriculum hampering the real life deployment of engineering skills?
Podcast Transcript
Host 1
Hello, and welcome to the macro fab engineering podcast. We are your hosts, Steven Craig and Parker,
Unknown Speaker
Dolman. This is episode 285. So, last week, Stephen, you had a question for everyone.
Host 1
Yeah, that question was, what was the most computational intensive work you've had to do on the job? So my response to that is, I don't know, did we even talk about it last week? I think we just left it open it that I think we left it open. Yeah. Okay, is I did a mix integrator and interger nonlinear optimization problem, which is like, kind of, like, sorting algorithm. But the thing with with mixed integer is you need to, it's like, I wanted whole numbers out of it. And so a lot of times when you do like a bin packing algorithm, or whatever, you get lots of fractions. Well, you can't have, for example, you can't have fractional PCBs, like you can't have half a PCB on a panel. And this was just kind of a thought experiment I was doing at work. And since it's a, it was a packing algorithm, it was nonlinear, because you could, there was not a, a fixed endpoint, I guess, the problem because there was a bunch of different inputs in the, I think that had a basically n squared. variable in it. Okay. So many nonlinear. And so how I solved it is, I kind of cheated is I basically made a I looked into because I wanted to solve it in Python. And I looked at installing a lot of these the called M I N L, PS, which is mixed integer nonlinear optimization problem. And tried solving or have like, basically, basically, what you do is you can't remember the python module, but you can build the model, which basically you go, this is the formulas that you're trying to optimize for. And like, your variables are x and your and y, and you're trying to solve for z in these bounds and this kind of stuff, you basically build that model. And then you send it to a solver. It's like, Yeah, and you just let it rip. And the one I found that I was using for a while was called the pot solver, a P O P T, I think, BYU is, is running. It's like it's like a academic server. But you can just send it problems. And so I was using that for a while to just play around with, you know, could I do an offline style packing algorithm for that and kind of cheated, I guess, because I didn't actually write the solver myself. But I found a good solution for it and did work. The only problem was during the summer, I'm going to guess that there's no students, there could be BYU. And sometimes the server would go down, and you're like, Well, my solver ain't working anymore. Well, I guess I guess that counts for the question, because the most computationally intensive work. Maybe you didn't necessarily do it on like a piece of paper, but it is probably the most computationally intensive. Yeah, the big thing was actually building the model correctly, though, like, making sure that when you built the model, it would give you the right answer when you solved it.
Host 2
Yeah, the big thing was, because a lot of those bin packing algorithms would be a lot easier if you could use fractions for like, the outputs. Like I mean, the first thing I tried to do was like, solve it. And then like, min max the output, so like, if you got 4.6, like, go like you would floor that to like four? Yeah, sure. But then you you leave a lot on the table. Basically, putting it into a mix integer was the way to go. And then setting it to whole numbers only. Nice.
Host 1
How long did that take you to crank it all out? Oh, I think it was about a week of just trying to figure stuff out on in the afternoons. Just trying to figure out like how to build a model correctly and. And then find a solver that works. A big thing was actually finding a solver that worked. I really wanted to be local on your machine. But I couldn't really find a solver that. I guess the best way to put it is was easy to get running. Makes sense? Yeah. And then this was just an API endpoint. You just kind of like bundled Your your model up and then sent it and they had their own Python script that kind of did that for you.
Unknown Speaker
Man, I wish I knew what the, the module I was using for the, for the building the model are you tell us your Steven, I'm going to look that up?
Host 3
Well, last week I talked about, you know, I got to really dig my teeth into a differential equation. But in terms of probably the most computationally intensive thing I've had to do. So, at my first job, I was asked to, or I, let's say I inherited a project, that
Host 1
this, this device needed to work universally with any probe system that could connect to it, which traditionally, each device was calibrated to each probe, and you would buy them in sets, or you would buy a family of probes, where their characteristics were generally close enough that you could plug it into a family calibrated device, and it would work. Well, the company wanted to make a universal device that could take any probe, plug it in, you could connect over USB and say it's this type, and then it would put coefficients into the microcontroller that would change itself to figure it out. So basically, what happened was every probe was nonlinear and needed to be a think it was a sixth order polynomial, but each probe had a polynomial over temperature. So in one axis of a chart, you have a polynomial in that is the probes characteristic across frequency. On the other axis, you have temperature, but then there's sort of like a more quantized axis that is each probe. So I had to I had to take each probe, characterize it across the frequency spectrum, then put it in a thermo Tron, move it to a temperature, characterize that polynomial, move to the next one. And I created a we called it a surface. So it was a 3d map. Yeah, it was a 3d. Yeah, it was a lookup surface that was based on temperature and probe type. And then we had a little AVR, just crank that out in the in the device. So in terms of like, it's not particularly difficult, but it was a bit of a lot of it was like a month and a half of constant temperature testing and probe testing, to get to generate all of these polynomials. And from what I know, they're still using that stuff. So. So I looked it up. It's PIO, Mo, p, y, O Mo, that's a, a python module that you can for building models, and then you attach a solver, so it's solver agnostic, I guess. So you can use a different back end, but allows you to build models, mathematical models, so cool. Chris Lasky. I think that's how you pronounce that left, he sent us an email about this topic. And our assessment that it is uncommon for engineers to need this is quite biased, since both of us work in engineering, manufacturing, well, okay. And this comment that Chris was given is in relation to last week where I was mentioning, you know, this was one of the first times I've really had to dive into a differential equation and, and really get dirty with some upper level math and things. And so I wanted to clarify a point because perhaps I didn't actually express it properly last week. I think the clarification is not that I'm saying that that upper level math is unnecessary, or tedious. And we shouldn't be learning that, in fact, quite the opposite. I'm very much positive towards that, I think we should be really getting into it. I guess the point that I want to get across this, say, if you're you're green eyed and you just leave college, don't be disappointed if your job isn't doing that all the time. Cuz there's a high likelihood it's not going to be doing that. Now. Now, Chris pointed out at his job. There, there are engineers who do that. He's doing something of that, like higher level math as a requirement for accomplishing the tasks up. I guess what I'm just getting at is, like I said, Don't be disappointed if that's not what you're doing. Yeah. And those three classes and math classes, even though if you might not use those at your job, like actually doing like a differential equation or whatever, those help reinforce your gut checks and your rule of thumbs that you end up developing over your life as a engineer. Yeah, I mean, over 10 years later, I was able to recognize a differential equation and I was able to crank it out. And that's only because I did my college work. Now, this is gonna be a side tangent, I guess on this is why I don't necessarily agree though spending so much college work on actually cranking out like differential equations and stuff, though, I would have rather learned how to write a program or figure out a different way to solve those problems. Like recognizing recognizing a problem is a differential equation and how to solve that perfectly fine. But sitting down and then like spending basically your first two years of your engineering degree in math classes just cranking out like, by hand those formulas? Is that really the best use of your time and money? I don't know. I think you need to do some alpha and like, just punch it in and it'll spit it out. Yeah, someone had to write Wolfram Alpha, you know, some of you. But that's the thing is, though, is you can leverage the whole thing about the human experience and human thing is leveraging the past. And then and then sitting down, and I don't think it's that easy. Doing differential equations by hand, isn't really doing that. i If you don't do it by hand, then I don't think it's, I don't think you have first of all the the appreciation for it. And they might not stick out as cleanly. And as clearly to you, when you do actually run across them. Oh, no. Because you can't, you can't just like plug in a bunch of variables into Wolfram Alpha, and have it say like, Oh, I understand what you want out of it. No, no, that's thing is understanding what building it like how earlier I was talking about this, like building a model. Right? I couldn't, I could sit there and by hand crunched the model and solve it. But why? Well, okay. Okay. I, there's a difference between understanding mathematical concepts, and just hammering out arithmetic. Yeah, no, but how much? How much of your math class was just hammering round arithmetic, though? That's every single test? Well, no, I don't think so. I don't think so. Especially the upper level stuff, especially like, I remember distinctly calculus three, when we were having to find like the volumes of unique shapes, you like it just said volume, find the volume of the shape. And you had to, in your mind, see which direction you were going to approach it to do a triple integral, and you could approach it any way you want. But in some ways, were easier at the end of that test, and have that answer question though. Did you have to write an actual answer? Or could you just left the equation? Well, okay, if you're, if you're a true mathematician, you just get to the point where you find out yes, there is a solution, I have found that a solution exists. But then at the end of the day, an engineer needs an answer. But if honestly, if you can just leave the question there or not question the formula there that you've, you've solved it, except that now you're just like, you can take that model that you made that solves your volume of that weird shape the volume of the cow, right, the friction is sphere cow. And throw that into your computer, I rather would learn would have done that like, like I would have we, as engineers, we would have benefited more from that than actually sitting down and then cranking through that formula by hand, the answer and the answer is 42. At the end? That's the answer to every question in college. I still think that there's value in in completing your work and going to do the point where you can't go any further. I think that is there's maybe your first math class. Well, but it made Okay. Things are different between physics, mathematics and engineering. You know, the, the mathematician wants to know, Can you can you chunk this apart to find does the solution exist? The physicist wants you to characterize it and say, what happens across if I change this one, if I take this one variable and multiply times four, what happens to the end result? And then the engineer actually gives you real world values and says, find the answer. Now, there's, there's a difference between all three of those worlds. And I think being able to think about each one of those separately makes you a well rounded engineer. Sure, it's just it's a waste of time on the test. Navy, and it all takes is you just have a this is like, when you're at a job, you don't do that stuff by hand because you get you get it checked. Because if you do you have it's more error prone to do it by hand and get your model done by a computer process by computer so I'd rather have learned that part. Well, okay, but but here's the thing like Yeah, I use simulation all the time. But that simulation is informed entirely by the equations that I knew. Because I crank them out by hand, I don't just plug in a circuit into my simulator. And then whatever it gives me, I believe to be truth. Like I plug in a circuit, and I already have an idea what the output is going to be. I just don't know exactly what it's going to be. And the simulator helps me kind of narrow the field into what that's going to be. Well, that's totally fine. But did you take that model and crank it out by hand first, though? No, but like, the fundamentals of that model? I did? I don't know. I just don't see. It's just a waste of time. I think. For me, I think yeah, well, okay. So here's the thing. I think the way you're thinking is perhaps a little bit more at engineering technology, which, frankly, I think et students get the short end of the stick, because what you and I do on a regular basis is e t work. But we went to school for double E. And we got, we got hammered by a bunch of like crazy theory. And then as soon as we left, they said do practical stuff. No, no theory is totally fine. I love those classes on the school, the thing that I get is, what I'm trying to get at is like, you solve a differential equation once, solving 100 of them. Does that make you understand it better, not really. Getting to the point where you actually get to the point where you've created a differential way, the you created the model, the formula that describes the system that you're or problem that you want to solve. going farther than that, is just arithmetic at that point, it's just, it's busy work is what it ends up being. And a computer is very good at doing busy work. I'd rather have learned building that model. And then and then learning how to actually make a computer do the busy work for you. That's way more useful for real engineers, I think, then sitting down and then for two years, just busting out arithmetic. Well, I don't think it's like memorization, I don't think it's that easy. And I memorize a lot of stuff anymore. Like, like, it's been proven that schools that base their curriculum on on memorization is isn't as good as other processes. I think repetition is is powerful, incredibly powerful for remembering things. In fact, the human brain, I learned this in a in a college class, in a psychology class, if you want to remember anything, the rule of thumb is to do it seven times, even if you're trying to remember somebody's name or somebody's name, say it in your head seven times. And that they've, they've proven that if you if you do something over seven times, you get incredibly diminishing returns on remembering it, because you've basically remember it by seven. So seven is sort of like the sweet spot. And so when it comes to doing arithmetic, doing arithmetic in different ways, so different problems that challenge your mind and a different attacking it from do it seven times and don't do it 100 times. I don't know maybe our experience was different in school. Well, so we, we talked about this before apartment on the podcast, but we have we've gone. So Steven went to a&m University here in Texas, and I went to University of Texas at Austin. And the biggest difference where I can figure out is my math classes, I took math classes at the math department with mathematicians, like I was like the only engineer in my class. And that's really common for that engineering in the engineering department that at UT is just to engineering classes, like anything else like chemistry, or all your extracurricular that, like they let other departments handle that. Whereas at a&m, I recall you take with all your peers, which might be the difference. So it's still the math department, and it's still by math people, but there was enough engineers that they just decided, you know, this is a math class where all the students are engineers. And for the for the first four, all the way up through defeat queue. They were identical to the math classes. After that. They started becoming tailored, where you do less proofs, and you do more projects that implement what you're learning. So honestly, I wish we would have done projects that implement it all the way down to Cal one. I really wish that was the case. Because I took classes that I took a lot of DSP classes which does a lot of calculus stuff. And that stuff I really liked, because you built the model, and then you coded that into your C program that ran on the microcontroller. And you let it solve it. But you But but but you still had to tell it what to do. So you had to have an understanding of what it was doing? Yes, but I didn't have to do the busy work. Sure.
Host 3
Sure. That's fine. That's totally fine. In terms of, once you've gotten to the point where, like, the fundamental and the concept is in your mind, yes, I agree that the busy work is annoying.
Host 1
Yeah, I didn't have to spend three semesters doing busy work, because I could benefit from the first semester, but whatever. It just, it's just frustrating. We're like, looking back in college, and what was a waste? I say waste of time, it's, it was never a waste of time, right? But what could have been used better? Would have been sure you spend part time, you know, during maybe a first couple of iterations by hand, so you least learn what how it works write by hand, how, how the all the functions and stuff work, but then move into Okay. Now let's actually do a real application where you need to do this this computation 1000 times, how do you do 1000 times in like a seconds?
Host 2
So that's just me, though. I want to be interesting, see, where the divide is?
Host 1
With our listeners on this topic, so I did not expect to talk about this for 22 minutes, but we did
Host 3
not as a great we haven't even really breached the next topic, which is awesome. And, you know, it's funny, because we mentioned in here, what Well, Chris, Chris mentioned that, Chris laughs keep going back to that email that was sent to us mentioned that we both work in manufacturing. Actually, both Parker and I have worked in design for a good chunk of our careers. And manufacturing is a portion of that. So that, you know, that kind of just leverages a little bit more what I was talking about where, you know, depending on what industry you're going into, will very heavily dictate what kind of mathematics you're going to expect. And on top of that, the like a lot of our listener base isn't just electrical engineering, I, my guess is electrical engineering probably has some of the more intensive mathematics stuff, whereas like industrial engineering is not going to experience a differential equation as as, you know, as often or something crazy. Like, I think Chris mentioned something about RF and in some of the crazier high frequency world, and that stuff starts to get really nasty really fast.
Host 1
So you know, it's actually, Steven Nyes design background is why we are really good at the manufacturing side, as well, because we screwed it up, and we've done it before. Yeah, I like I like your sentiment, we can leave it with this. Parker wrote theory classes do reinforce your gut check and your rule of thumbs at 100% on the present. And again, I'm not against theory, I'm just against the busy work, because, you know, we got computers to do busy work for us. Let the robots do it. Is that the whole point is like the let the robots do as much as you can all the busy work. So alright, let's move on. Okay. So over the weekend, I think on Saturday at six o'clock central time, we did a kind of like introduction for hardware engineers on Python, basically setting up a Python environment on Windows 10. And then setting up a IDE pi charm, and then basically writing a little scripts to talk to an Arduino with Skippy. And that was a really good success. We didn't actually run into that many issues, and Steven got his bike. He has an old an old PLC and a Arduino PLC. Yeah, that thing is from like, episode like, 40 of the podcast. This thing is really cool. And you got a really to flip on it in like, less than an hour.
Host 3
Yeah. Okay. The thing that I was most surprised about is I, you know, I was quiet 90% of the time I just kind of followed along Parker's stuff. And this is not a dig on Parker. This is just like a general dig on these kinds of things. Like, I was expecting to run into some kind of snag where we'd have to debug a whole bunch of crap and it would be annoying, you know, like, for some reason, like Python wouldn't install on my computer or whatever. Not like everything went super smooth. And we've really didn't run into any errors whatsoever.
Host 1
Yeah, it was a lot of fun actually. I think it's it's one of those I've done the busy work before. I'm trying to make. So what you're telling me is I just let the computer do the busy work. Exactly. See somebody knew the fundamentals of what to do.
Unknown Speaker
Yes. No, that's fine, because but that's what we love that topic in the past.
Host 1
Yeah, so that went really well. I guess we have the recording up on Twitch, if you want to recap and go check it out. Yeah, it's a twitch vaad I need to download it. And then I don't know if I'm gonna edit it, or just I think I just toss it right onto YouTube. I don't think we said anything naughty on it. So you can just dump it on. I'm more worried about like, editing it down to be more concise, because it's an hour plus long and a lot of it is us just like chatting. Actually, okay. That's true. We did get a lot because we do have a podcast. No, no, no. So here's the thing, though. You were you were pretty concise for the first like 30 minutes, and we got to a Okay, so if you want to get to like the meat and potatoes and the conclusion, watch the first 30 minutes, if you want to just hang out with us watch the second 30 minute. Yeah, pretty much. Yeah. No, it was it was great. I'm super excited about it, I think I think it turned out well. And hopefully we're gonna grow that and do some more stuff. Yes. And speaking of all that, I finally made a huge breakthrough today on at work on this kind of stuff. Basically, I was running into an issue with I've got like, eight devices that I got to like talk Skippy with, and all that stuff. And I was basically running into this issue where devices would just lose connection randomly, but then immediately get it back. And I was really struggling to how to solve that correctly. Because we're using this module called PI visa, pi visa vie, know, pi visa pi. And trying to solve that problem. And there's not a lot of good solutions out there. And I couldn't really figure out like, a really good way to do it. One of the solutions was actually migrating off of windows being the OS, and moving to Linux, Windows, especially windows 10, I found out does a lot of weird stuff with USB devices, and it will tend to like, disconnect you, but then reconnect you and not tell you that happened. Like it won't tell like the top level that that happened. It like hides it from like, the the physical hardware layer interconnect, which kind of sucks because then you go and try to talk to your device and the device goes, what it's, it's crap like that, why I like embedded programming above computer software like. And so what I ended up doing is I migrated off to Linux, which fix that problem. And then because when when it would happen on Windows, you just get a generic like, connection error, and you don't know how to solve it. And it's just like, error. And you're like, well, that's generic, and you don't really know much how to fix it. So migrating to Linux, it actually would give me real errors that I could actually go in, fix my my code. And a lot of it was fixing. Basically, I was running into conditions where I was trying to I was doing a read or write and then immediately trying to read the port when it was still the buffer, we're still draining out basically. So waiting for that kind of stuff. And then when devices do reset, I could actually properly reconnect to them. And so in Windows, it does weird stuff on the comport and that it's really hard to reconnect to devices without having to like act instead. Excuse me, without just disconnecting the device physically and then reconnecting it. And Linux, you can get around that pretty easily. And so while I was able to do is basically, when a device got disconnected, it would look at the ports and it would reconnect and sometimes it reconnects on a new port. And so you have to go okay, where's What's the new port I had to go to connect. So as long as that two devices disconnect at once, my solution is fine. But the chance of that happening is pretty low, right? It's never happened so far. In the couple of months I've been testing it, it's always been like one would fail. And I really want to fix that problem. Like I don't know what actually causes a comport device to just stop. It could be I'm running eight devices on like a single hub. And there's a lot of communication going on. But it shouldn't be, that shouldn't be a problem. And I'm using a high end hub. I'm not using like, a cheap, you know, Dollar Store hub. I'm it's like $180, industrial, USB hub. That's all like self powered. And it's like 100 watts of power and all that good stuff. And I don't know what the, my solution works now, as I'm no have a problem with it. And just, I wish that wasn't a problem of just devices randomly disconnecting sometimes. So if you only have like, one device, it seems to be fine, I think is just a
Unknown Speaker
there's just so much communication going on with those drivers, that it just one just hiccups basically.
Host 1
How fast are you having to hit everything? Um, well, I'm trying to hit them as fast as I can. That's the thing. I'm trying to hit everything as fast as I can. Now, it's pulling the buttons on the unit once every second and a half, which isn't a lot of data either. That's no, that's really slow. It's really slow. But yeah, I think it's just the fact that it's like eight devices. And, and I do make sure like, the devices are locked. So like when when a part of that because the the script is multi threaded. So you have to I had to worry about making sure that only a one thread is only accessing the device at once. That's all groovy. That's never been. That's not a problem. But yeah, it's just I don't know.
Unknown Speaker
Sunspots, man. Are you doing multi threading in Python? Yes. Oh, cool. Yeah,
Host 1
that's how it handles like the, because I'm loading a lot D UTS, or device under tests into a fixture, but you can asynchronously add them in. And so that's how it handles is one thread is basically handling like the user interface. And then a, it has a queue back end. And then another thread is handling sticking stuff out of the queue. And then running tests on that, because you can only run because how the how the tests are set up, you can only run a test on one piece of hardware at a time. But you have 12 units like multiplexed into it. So the idea is the operator loads one presses the button loads, another one presses a button. And then by the time they're done loading the whole unit up, the first one is done, and they can pull it out and free load that and then the next one's done, etc, etc, all down the chain. So it's just continuous operation. Yeah, continuous operation. But today was a big, big plus up because finally got a good way on resetting the devices correctly. And reconnecting to them without having a issue at fault basically, make so like, the operator doesn't know something bad happened. Right?
Unknown Speaker
And so yeah, I'm gonna be wrapping that up, hopefully tomorrow. Oh, nice. It's probably gonna be Thursday, though. You've
Host 1
been working on that for a long time. Yeah, didn't like eight weeks. So in kind of in relation to the Python class, because it went well. I figured we could use what we did in that class to kind of resurrect something that I've had on the back burner for a while. I've had a design that I started about a year ago. And
Host 3
it's a board that allows me to do production bias testing on my guitar amps that I have. And the reason I put it aside is because I just didn't need it at the moment, I knew I would return to it. And it's something that could, like there's, there's many different levels of intensity that we could add to it. But given how well the Python class that Parker taught, went, we kind of discussed well, how do we how do we like upgrade this to the next level, and kind of looking at gooeys and accepting data in and then displaying it to a user is the next sort of logical step on that. So I decided to resurrect this bias test board because I eventually will need it and I want to get it done sometime. So the funny thing is with with COVID and with the parts shortage and almost everything I designed is just not available or it's obsolete now. So it's just like okay, well, effectively, I kind of have to start over. Luckily it's not a very difficult design. What it what it all boils down to is I'm just Taking a bunch of voltage measurements. That's, that's it. And at the same time, I love this too, because it's going to relate to if we ever get into that multimeter design. So this is sort of like, we can use this as a stepping stone of concepts and things. So if I have 10 voltage measure well, more than 10, but specifically 10 voltage measurements that I need to be able to measure up to 550 volts. And
Host 1
what it actually ends up boiling down to is with the circuitry I chose, it'll I have my, my voltage sensing range is zero to 1000 volts, which is well beyond what I need. But what I love about that is any kind of transient that happens, or if the device gets put in an incorrect situation, or like say, somebody accidentally plugs it into like 220 volts, I'll still be within range, and I won't damage any my inputs and things. So I'm sacrificing a little bit of resolution range for just a enormous front end that doesn't require, like diode protection, which can throw off the results that I'm I'm looking for, by loading the inputs incorrectly. So the thing about this, so I've got 10 voltages that I need to read, that are up to 550 volts, then I have four voltages that I need to read that are in the range of like, typically like anywhere between 10 and 50 millivolts. So like way extremes on the side, and at the end, at the same time, I also want to have a resistance measurement in this box. So for low voltage measurements, 10 very high voltage measurements, and one resistance measurement. And because of all of that, there's there's some unique characteristics that made finding an ad for this kind of difficult. So I you know, I haven't really talked too much about this. Parker in the past. Have you dealt with a DS much besides microcontroller built in microcontroller ones? Yeah, not much. I've done some current sensing. But yeah, nothing that required like what you're talking about here? Yeah, like dedicated service, add stuff on the oven blade, some dedicated ADCs for that kind of stuff, but nothing like it was like, okay, it has enough resolution, and it might it's probably fast enough. It's good enough. That's okay. So that's, that's just the thing, okay, if I find searching for ADA DS to be both really, really fun, but also just mind boggling. Because it's so the ADA DS have so many characteristics about them, that it becomes difficult to dig through all of the data sheets to find this is the one that will do it for me. And I kind of as I was going through and trying to find a good add that would meet my application. I started writing down characteristics I'm thinking about to find this. So we've got obviously we got resolution, because that's what everyone goes to right away. But you have this one, you have speed, how many samples per second is the thing going to do? For me, cost is a factor. I'm only going to be building one of these. But I don't want to spend $60 per piece on a on an ad, you know, I just don't want to I could but I don't want to accuracy, which is different than resolution. That is that is one. All closers that bid to the real value. Right? Well, and that has a lot of implications. There's there's linearity, there's full scale gain errors, there's all these other characteristics to go into it. But there's there's features above and beyond that. Like, what does it have a cup holder? What protocol does it does it communicate? I was gonna say protocol, but I like the cup holder. That might be worth the $60. Right? Yeah. So yeah, what protocol like if you've already got SPI on your board, do you want to add ITC or whatnot? What what voltage ranges? does? Does that protocol work on? Are you going to do to do level shifting? The you know, some of them have programmable gain amplifiers in front of them or digital filtering and things like that. Do you want all of that jazz on it? Some of them have internal clocks for their for their sampling speeds. Some of them require you slap a crystal on the outside, like none of this is easy. And you kind of you kind of just wish you could say here's my voltage range. Here's the resolution in bits that I want. Give it to me, but like not that never works, right? Like that's it sure when you're talking about an eight bit add in, you don't need lots of resolution that might get you by. Right. But but in terms of what I'm talking about,
Host 2
you also got the package to like the physical, right package of the part. Is
Host 1
it something you want to deal with? Yeah, you might find like this really awesome. Add, but it's in like a ridiculous BGA package that you don't want to deal with. Right? Because it'd be like the only BG on your board? And it would it would quadruple the price of your PCB for them for the BGA. Or your assembly. Yeah, yeah. So yeah, there's, there's, there's a lot more than these the factors that I put down there, but these are kind of like the big ones that are. So for my high voltage measurements, I have a high voltage, high accuracy kaduk resistive divider that's on a ceramic substrate. So this thing has really low temperature coefficient. And its accuracy is like, point zero 5% tolerance. And I think it has even better. What is it resistor to resistor tolerance on the inside the ratio itself. So this particular one has a bunch of different ratios, you can do 1/10 1/100, one 1000s, whatever, whatever you're looking for. So I've selected to do one 1000 resistance ratio on there. So 500 volts, zero to 500 volts would give me a range of zero to five, 500 millivolts, which is not particularly large, because I could have done zero to five volts, right, that would that could potentially make sense. But in with the ad that I chose, it actually makes sense to go lower on your input voltage, and then use the programmable gain amplifier, because you can actually get more resolution by gaining up afterwards, which is kind of crazy. But I'm basically following what the datasheet recommends from this kind of stuff. So your overall noise is a little bit higher. And I mean, a little bit, we're talking about fracture C is a little bit off just a little bit, but your resolution can actually get higher by doing it that way. So having a higher gain on the inside, gets me a little bit more resolution. So for all of my hand off, your your increase in noise is not enough to offset the loss and resolution. Right. Right. And the difference, the difference is fractions of microvolts. So it's kind of ridiculous here. That's a really good gain stage in there. Yeah, no, it's incredible. It's well, and and on top of that, I'm buffering my stage because this resistor divider here has like, I don't remember, it's like 10 mega ohms for the whole stack, I think so it's like nine Meg and 900k. And then 90k, or like, it all adds up to 10 Meg. And, and I specifically, so I chose a low offset op amp to act as a buffer in between the A to D in this. So I've slapped that in there and then put a small amount of filtering on that. Because I don't want my A to D to drag down my voltage divider and just give me errors just from being there. Which, you know, I may run into such a small amount of air. But I think with the one 1000s division, I the lower tail end of that resistor is so low, that slapping on an op amp buffer on the front end is going to basically show up as no error or so low that it will be beneath the resolution of the ADD, which the add I finally ended up choosing was the ATS 1256, which well, it comes in two different flavors, the 1255 and the 1256. Which that and those are actually in stock, actually in stock, I could buy it right now, which is great. So both of those are a single add, but they have the 1256 as a multiplexer on the front end. So you can you can multiplex between input channels. And so you can expand it to be eight channels effectively. So a pair of these will allow me to do all of my measurements by just multiplexing between the inputs. At the same time, it's kind of cool because the inputs can all be configured to be single ended or differential if I wanted them to be. All of my measurements are positive and ground referenced. So I'm just going to do single ends just to make it easy, but I suppose I could do differential on my resistance measurement. But for the resistance measurement, I just developed a constant current op amp output that just spits out one milliamp and it and then I already know that my I'm not trying to measure any resistor with it, I know guaranteed that the minimum resistance I will ever subject this to is 100 ohms. And the maximum is 2.2k. So I know that if I pump 100 milli Amps into it, I'll have 100 millivolts up to 2.2 volts. So I just have a range right there to deal with. So I'm not trying to make like a end all be all resistance measurements, just This is a production thing with known reasons. Yeah, this is a product. A, you're basically building a purpose built multimeter. So it's not a multimeter. It's a
Unknown Speaker
in this case, a dual meter. Right, right, right. Well, and the hope is a single range
Host 1
ohm meter with a single range voltage meter on it. Well, yeah, on top of that, it does this thing is not going to have test probes. It has a header connector, that you just plug into my PCBs, and my PCBs have a standardized layout that plugs directly into this. So like, the user doesn't even need to clip anything in, they plug into one pin header, and, and then it just dumps out stuff. So so the goal here is to make something that allows me to not have to train people how to calculate bias. I'll let a Python script do that. And so I want to make a graphical Oh, you're letting the python script do the busy? Exactly, exactly. Yeah, I see I know how to do it. But that's because I've done it 1000 times. So yeah, I want to I want to make like a red light, green light kind of thing. So have a graphical interface that shows the numbers on it. But the user doesn't need to know the readings that are actually coming in, it's just red when it's not right. And then they turn a trim pot on the board. And and when the power dissipation in the power section is just right, it turns green and they stop and they and they're good to go. It wouldn't be cool if when they knew which way to adjusted. i Well, I know that that clockwise is hotter and counterclockwise is cooler. So yeah, we could we could put a little arrow indicator Yeah, just lawyer tell them which way to turn it. But the test procedure already starts with before turning on the device, you turn the trim pot fully counterclockwise, so you're only going to be turning low. Yeah. Okay. Got that makes sense. You don't want to put it into an overheating situation right from get go right from the get go. And the guy turns the operator turns it on and goes to lunch. Right. Right. Exactly. So yeah, yeah, that's the very first thing you do. When you get that design mostly done. We should do an episode where we just cover it in like all that design stuff like this is the resolution and then calculate all that stuff out. That'd be fun. Yeah, I mean, I've done a good chunk of that. I mean, I'm already putting parts on the PCB right now. So I
Unknown Speaker
shouldn't say calculate it out. I'm, like, go through the
Host 1
what's the best way to put it? Because you've already done the, like, explain why you're picking these parts. But like, you know, I forgot to mention this is 24. bit add. So it's very high resolution. What what what would be interesting is to are you aware of E knob, effective number of bits? Like, yeah, so you buy a 1224 bit add, you're not getting 24 bits of resolution out of it, right? You're basically never going to get in after maybe like 12 bits, you're never going to fully get all of those bits. And I know somebody's gonna chime in and be like, Well, I have a circuit that doesn't sure it could happen, right? But, but the, I'm not going to get 24 Full bits, I know I need 17. So I got a 24. And I'm allowing myself a budget of a handful of fits to screw it up with power supply, crud, and layout crappiness and things like that. As long as I have, as long as I have 17 bits, then I will be able to read the 1010s of millivolts on a 500 volts signal. And that's what I do. Yeah, it's really good, right? So you need a really high resolution. You know, it's funny, the only reason I need to do that is because I'm trying to measure some current, some really low value current in that situation. So I'm measuring across the resistance, which Hey, that's why you have the resistance measurement as a separate thing in there you can measure the resistor store it in the program and then you can calculate your current based off of an actual measured resistance value in there. Okay, so I have a better way to phrase what I was saying earlier is we should just go through the the formulas and how you pick these parts. Cool. Yeah, so like, on rest solution. This was your range. And then this was your considerations of your input into why you picked that resolution. I love that. Yeah, let's let's do it. Yeah, for sure. We're gonna make sure that it works First, though, also, well, here's here's his. That's true. So back it all up. Here's one of the reasons why pick that chip has nothing to do with most of those things except for cost. If you go to try to find a high resolution, single package, add in singles, let's we'll just talk about singles. Right now, you're looking at like four to $20, somewhere in that range for like the lion's share of them. This ad is 1256 is $17. But it has eight, a to DS inside of it. So each A to D is like two bucks. So that was one of the big drivers. They're not cheap part. But it also it's a really good part. It's yeah, it's a fantastic part. Although it has so many bells and whistles, that it's going to be a trip to programming, the programming is actually easy, it only has a handful of registers in it. But almost every register you write to has an impact on your E knob. So like if you change your speed, that's yeah, it'll change your email. If you change your gain, that'll change your email. If you change any of these things, you have to you have to remember, like you can't just willy nilly change anything inside of this, you have to know what what the impact is of doing it. On top of that, there's this one, okay, so this thing has a self Cal Situ thing that's really cool. You can throw it into self Cal mode, it turns off all the inputs, and it dumps a voltage onto the input. And then and then it goes through a calibration routine. Now depending on other settings, that calibration routine takes a certain amount of time, and they have a very well defined chart of how long it takes. So let's say you turn the multiplexer to look at one input on this device and you're reading some voltage and then you want to go to a different input. But you want to change some of those other characteristics like the gain or you want to change the buffering or filtering on the input, well, then you have to run that self cow as well. So you kind of also have to consider like, Oh, my loop time of how fast I'm doing this. If I'm changing any settings, do I need to do another self cow? Or can I just accept the error that comes along with not doing yourself cow? Well, that screws to the knobs too. So it's like, yeah, it's gonna be really, it seems really, really easy to program, but very deep to get the actual result you're looking for. So it'll be fun. Yeah, I think so too. So, yeah, before we close out, we'll just spend a real quick second on this. So on July 9, our President Joe Biden signed an executive order that includes some wording for right to repair, which is kind of interesting, Parker and I have mentioned right to repair a handful of times on the on the cast. And I just thought it was interesting. Some of the some of the wording that was included in here. Cuz now it seems like there's as opposed to state and local legislation, it looks like it's getting a little bit higher up to federal legislation. So back in May of 2021, the FTC, the Federal Trade Commission, released a report called nixing the fix, which was basically a just an overview of what right to repair, not even right to repair. It's an overview of repairing your own devices. It's not dangerous state of the industry and repairing your repairing anything, actually, it covers a lot of things. It's like 56 pages, which isn't too much. But if you got a moment scan through it, because there's a lot of really interesting stuff in there. And this, this report was presented to Congress I don't remember exactly when. But But this report is basically what has led to the this executive order which we know what we have a link to the executive order up here. The wording that's actually in reference to right to repair is pretty thin. It's not much. In fact, I got the wording right here it says there's a little bit of legal speak, so I'm going to jump in the middle of it here it says. Let's see here. The chair of the FTC in the chairs direction dogs, our discretion is also encouraged to consider working with the rest of the commission to exercise the FTC has statutory rulemaking authority as appropriate and consistent with applicable law in areas such as and then they have a bunch of different areas and one of them is unfair anti competitive restrictions on third party repair or self repair have items such as the restrictions imposed by powerful manufacturers that prevent farmers from repairing their own equipment. So it kind of almost seems like the wording that's in here is dedicated to farm implements. Which you know, with the whole done Jerrick. Dodgy here. Why am I messing up the name now? The John Deere, John Deere that geez, well, yeah, then got some dyslexia going on here. John Deere, it seems in relation to that case, right? Or the that idea. But it is interesting that we're starting to see a lot more traction on that on a more federal side. But basically, what that saying is, if you're John Deere, you can't if you can't,
Unknown Speaker
on purpose, prevent someone from doing that stuff, repairing their own device? Well, and
Host 1
the thing is, you know, this executive order just basically grants the FTC FTC, the ability to look into this not even the ability and it's basically just saying, like, keep an eye out on this. So there's nothing like legal about this yet. It's basically the FCC has kind of, they're allowed to research this now. Or look more into it. Right, right. Don't turn a blind eye to it. Yeah. Because I don't think the FTC containment do anything about it yet, either. Yeah, I don't I don't believe they can. Cool. Yeah. So we'll put the links up in the neck fab.com/blog. So I'm going to my homework. And for everyone that's listening, as well. Well, I'm gonna do is I'm going to read this FTC report nixing the fix that came out in May 2021. And then we'll bring this up again. Next podcast, talk about this report, because I was skimming through it before the podcast. And it looks very interesting on kind of like the state of repairing things. And I kind of want to read about other industries and that kind of stuff. I can't comment too much about it, because I don't know anything about this whole executive order or this report as well. So that's, so one thing, as you're reading it, just keep this in mind. They do. They break it up into sections, and I think they do a pretty good job of defining what those sections are. And one of the sections I think is really good. It is the arguments from the manufacturers side, not necessarily the manufacturer ups, or the the property owners or the Yeah, the owner of the VIP VIP, basically, it's all of their arguments, and some of those arguments and they don't present them in a in a bad light or even a good light. They just say these are the arguments. And I enjoyed reading that because it was a very clear and concise way of putting together a lot of the things that Parker and I have said, especially today reference, I wish right? Especially stuff about safety. Right? Yeah, you know, or, or if somebody else fixes it. Are they going to fix it correctly? So yeah, I want to go through and I'll, I'll make some notes. So that's what we that's our question, I guess. For our listeners this week, is it's not really a question. It's more like, read this, please. It's this. This stuff's really important, in fact, and it affects every party, every single person that listens to this podcast, right. And if it's part of an executive order, it may be federal law sometime in the future.
Unknown Speaker
Yep. So that was the macro engineering podcast where your hosts Parker Dolman and Stephen Gregg, let everyone take it easy. Maybe Joe Biden can write an executive order that says you have to listen to this podcast.