Embedded - 508: Descartes' Demon

Episode Date: August 21, 2025

William Griffin spoke to us about hardware-in-the-loop testing, simulation, terminology, learning complex topics, and books. We don’t usually expand upon the show title but Wikipedia has a rabbit hole called Evil demon so there you go. Books mentioned: Make: Electronic Music from Scratch: A Beginner's Guide to Homegrown Audio Gizmos CMOS Cookbook How to Measure Anything: Finding the Value of Intangibles in Business Surely You're Joking, Mr. Feynman!” Adventures of a Curious Character Drive: The Surprising Truth About What Motivates Us Leadership BS: Fixing Workplaces and Careers One Truth at a Time (though we then talked about a different Jeffrey Pfeffer book: 7 Rules of Power. William Griffin and  Bailey Steinfadt (333) have started Spark Embedded, an embedded software and simulation consultancy.  Transcript Mouser Electronics has a dedicated Empowering Innovation Together hub that covers the latest breakthroughs in tech. Their new series explores how AI is reshaping engineering—from design automation to rapid prototyping and predictive maintenance. You’ll find insightful articles, podcasts, and videos that showcase real-world applications across industries. If you’re ready to see how AI is powering the next generation of engineering, head over to Mouser.com/empowering-innovation.

Welcome to Embedded. I am Alicia White here with Christopher White. Our guest this week is William Griffin, and we'll be talking about simulation and hardwares and models and math and probably books, probably a lot of books. Hi, William. Welcome. Yeah, there's definitely going to be a lot of books. Thanks for having me. Could you tell us about yourself as if we met at SuperCon? Oh, well, I'm a huge fan.

Worst way to start a conversation with me. Yeah, let's see, I'm an engineer. I've been working with embedded control units for vehicles for about 20 years. I've done a lot of hardware in the loop test systems. a lot of lab view and teaching those things. Similarly, I've done a lot of model-based system design, my backgrounds in physics. So applying that to kind of help with developing control systems

and then also a fair amount of engineering, leadership, strategy type things, founding and leading teams, helping create some innovative programs to align, you know, engineering business and strategy, help build up software craftsmanship across an engineering organization. And I guess that's kind of like the big thing is I'm really passionate about helping build, you know, collaborative engineering cultures. And just now launching a new company

with a longtime friend of the show, Bailey Steinfet. It's called Spark Embedded. And yeah, we want to create a place where we can have collaborative teams of experienced engineers that are helping to, you know, take on those tough challenges and maybe apply some of this MBSD and Hill, not just for these big companies, but for smaller and medium-sized businesses. Yeah, give back to the community. All right. Since you do know the show, we're going to go straight to Lightning Round. Are you ready?

Is anyone ever ready for this? This is the fun part. Favorite type of vehicle to control. Boy. Ooh, I like to fly spaceships in video games. Favorite simulation software? I use simulink a lot. Is SimCity a simulation?

Why not? Yeah, I'd say so. It's a Tamagotchi. A simulation. A simulation. Very low fidelity simulation. Okay. Favorite programming language. I think I'm most comfortable in LabVue from over the years.

But I first learned on MatLab. What is the most amazing thing you've seen or done with Labview? There's two questions there. You're making me struggle. Well, you can pick one. I mean, one of my prouder achievements is helping to set up a hardware in the loop simulation lab and develop the original architecture for that, for a major vehicle tractor company that probably everyone's heard of, but I probably shouldn't say the name.

And yeah, that's turned into now they've got hundreds of simulators for all sorts of different vehicles. Complete one project or start a dozen. I'm definitely like a mono-focused person, one, two projects. And then I say that and I'm like, but I'm usually reading five or something. six books at a time. That doesn't count. Those are different. Okay, okay, fair enough. Favorite fictional robot.

So tough. So Alicia knows I'm a big fan of murder bot. We have murder bot parties here, but I guess my favorite's data from the next generation. And do you have a tip everyone should know? I have one that I applied before we started talking. Have you guys ever heard of the hungry judge effect? No. A judge is more likely to convict you if it's right before lunchtime or less likely to parole you, I think, is where the tests are done.

I see. Yeah, exactly. So you got something you want to be mentally present for, take a break beforehand, have a sweet snack or something to give you some energy so that your brain is on for that conversation. This is similar to my, if you totally want to derail a meeting. plan it for about 2 o'clock in the afternoon and bring chocolate cake. The sugar rush is fast and everyone crashes. It's a lot faster if you bring whiskey. Or it turns into an all-nighter.

I have a quick sponsor announcement before we jump back in. If you were interested in AI's impact on design engineering, Mousel Electronics has some great resources to check out. Their empowering innovation-together platform is diving deep into AI-powered engineering. Think faster prototyping, smarter automation, and more sustainable production. It's about helping engineers unlock the full potential of artificial intelligence in real-world designs. You'll find podcasts, expert articles, and videos that keep you informed and inspired. Sound like you're a thing?

Head over to mouser.com slash empowering dash innovation and explore the latest content. Okay, so simulation and hardware in the loop. Those are two separate things that you have mentioned, but they're different. Could you describe hardware in the loop as though we hadn't all listened to Komethe's episode a few weeks?

weeks ago, a few months ago. Yeah, sure. Hardware in the loop. So essentially what we're talking about there usually is you've got some piece of software. In my field, it's been embedded control units. But you've got some piece of software and you're actually putting it on the hardware on that ECU. And you want to trick the ECU into thinking it's actually, you know, on a vehicle out in a field, driving things around or controlling a transmission or an engine.

So you give it all of its inputs and you give it all of its outputs. And you do your best to convince it that it's out there doing real stuff and then see what it does. Where do you get these inputs and outputs? Do you record them from actual events or do you simulate them from physical models? You can do both. what I would say with recording, this gets into the essence of in the loop when we talk about hardware in the loop, right?

With a recording, you've got your input that you're feeding the recorded data, right? And you're feeding that to your controller. The controller does something and has some sort of output. But there's no loop. That output doesn't affect the recording, right? You can't just, it doesn't dynamically change what happens in the recording. So if it says turn left and the recording

was for a vehicle turning, right? Well, it's still going to turn right. You've got an open loop test there, right? Within in-the-loop simulator, now you're dealing with something that actually closes it, and that usually has, like you said, like we call it a plant model or some sort of emulation of the physics

or the environment, maybe other systems that it's interacting with. If it's a transmission, then it can, you know, an engine, something like that. And that's a part of this. loop. So the outputs of your controller are measured, red, fed through this model, and then this model has its own outputs that end up being, you know, generating analog signals or, you know, encoder signals, whatever you're using. And that goes back and actually

gets fed as electrical signals to the ECU unit. So that's the whole loop in hardware in the loop. One of the problems with testing, when we talk about control units, we're talking about PID control and LQR control, things that are not as simple in and out. There's delays and phase shifts and the inputs and the outputs are not trivially connected, or not linearly connected, right? Yes. oftentimes, but not always. I mean, you don't have to be doing those complicated systems to be able to try to do some in the loop, get value

out of in the loop simulation. But certainly you get even more value when it's those dynamic kinds of interesting control algorithms. When I have done hardware in the loop with recorded data, it has been to do regression tests to make sure that the controller,

control unit has not changed from what we expected, has not gotten worse. And when I have done the simulation, it has usually been to test the simulation, test the control unit more as a first time, first pass. Often as a way to make sure my hardware in the loop is acting similarly to how my physical unit should be working. You put in an impulse and look at the squiggles that come out for the physical system and then for the simulated system and then you try to mash them so that they manage to make the same frequency and level of oscillations in your control. are they both valuable for you, or do you think the simulation is really the only way to go?

Oh, gosh. So what you're saying is like you're feeding back, like, based on, like, how it operated in the real system, you're feeding that back into the plant models to kind of update them and make them better reflect reality. Is that right? Well, the plant models here are inside the control unit, or the plant models? is the simulated system. I thought you called the simulated system, the plant. I've always hated that word, and there's just... Yeah, and maybe I'm misunderstanding your question here. The specific reason I hate the word plant in this context, but that is unrelated to the world here.

It's always been because I... When you talk about a system, which part is the plant always confuses me. Is it the whole system? Or is it the system that the control unit is responding to? Or is it the control unit itself? Because I've seen it used in all three places, which just makes me want that word to go away because I don't understand what it means when you say it.

So having confused probably myself, the listeners, Christopher, and William. Where were we? I don't think I got your question quite right then. So could you? Okay, so you have. have the control unit that is running our software, maybe running a PID loop, maybe just running a recorder, data recorder, or some form of control.

This is the system under test? This is the device under test. Okay. This is the system that is being the hardware part of the in the loop. This is the hardware we've developed. And now we can either hook it to a recording of the data that we got from the field. And play it back. And play it back.

Okay. Which William pointed out that if something's miswired, like left and right or opposite, or your algorithm has improved so that you get a different response, you won't get that different response and recorded data. You'll just have a different output. Alternatively, you can take all of those wires that go to your board, and instead of playing recorded data into them, you can add them to a simulated system that actually physically models

the real world. Like, if this is a car or a tractor, you would have your device under test and then you would model the transmission and the steering and the rocks in the field. I don't know. It's Descartes demon for hardware. What's Descartes' demon? That's the conjecture that there could be a demon that actually is giving you all your visual and sensory inputs and that the real world is simulated by an evil demon. It's the matrix for your hardware. Yeah. Okay, okay, yeah, okay. So, yes, I was comparing the value between these two and whether there is value in both

and which part of this whole system between the simulation system that does the physics, the device under test control unit, or the whole thing is called the plant. Or if the plant is something else on your desk that's green, that you shouldn't pour as much coffee into it as you do, but you know what else you're going to do with your coffee? drink it it's cold uh sorry where were we i think you were formatting a question i think i got the question okay so i think what you're asking is like are both of these types of testing valuable

this open loop testing and closed loop testing and i'd say yeah duh of course any testing is better than no testing first of all right um and this is something I read it. We promised books. I read an interesting book. My mentor, Tim Gifford, had recommended maybe a few months back called How to Measure Anything. And one of their biggest points is, like, you should measure things. You shouldn't get into this mindset of, like, if I can't get the absolute perfect test in place,

then I might as well not even bother testing at all, right? usually whatever that first measurement is that you take gives you the most information and you don't have to get to this place where it's all perfect fidelity and high statistical significance and things like that you can still get useful feedback even from low fidelity testing that helps you find those big mistakes early except there is there's a cost to this Yeah. And having a bad hardware in the loop, having a complicated simulation, can take away engineering time from developing what could be a better solution. How do we measure anything?

How do we measure the value of our simulations? Yeah, I mean, there's no real, like, clean answer here. You know, in theory, you'd say, well, I just want to have the absolute best, you know, highest fidelity model that represents, you know, the universe precisely down to the, you know, quantum level. And that sounds all nice, right? But we're not doing Descartes' demon. We're not doing the matrix here. And that's expensive, right? That requires really good hardware. It requires a lot of knowledge. and a lot of time and a lot of expense and we've got businesses to run, right? And products to get out the door. And that's just not realistic, right?

So we need to figure out, like, what's the right amount of fidelity there? And it's just kind of an art. You start to ask you, well, how important is it, right? So if you're doing a PID, again, depending on, you know, the time aspect of your PID, you may need higher and higher fidelity to deal with that.

But if you're doing something that's simpler, you may not need a lot of fidelity. It may be good enough to have a very simple, basic mathematical model of your application without going into that level of detail. Or if you're doing functional safety, right? That's a place where you might need higher fidelity in order to get your certifications

or sending a product out into space where you can't test it, right? I mean, the one time it goes out is the only time. So you better have a pretty good model and have it pretty thoroughly tested in simulation before you send it out. Or you might waste a lot of resources. That kind of makes sense? Yeah, it came up in a conversation recently when I mentioned that my analytic physical models matched my, my analytic models matched my physical models, but neither one of them matched my,

matched my simulated system and someone asked well why bother with the simulated system then I said because I can throw the simulated system off of cliffs and if I do that with the actual model people get mad at me so there is a value to the simulation beyond its ability to actually beyond the obvious that you can do things that are too expensive or too time consuming because you can often run a simulation at multiple X of actual time. Yeah, yeah. So there's a lot of like really good things, you know, beyond just the testing. I mean, the testing's great, right?

So you can measure things that you would have a hard time measuring in reality, right? Because if you're in a model, you can see all of these, you can see all the pressure and the flow or, you know, what's going on with current and things like that that you might not easily be able to measure. out in the field, right? Yeah. Do these dangerous things, and you can do it early on. But I also, I mean, I don't think that's the only thing that you get out of it. Sorry, you were going to jump in there, and I went right over you. No, no, I mean, yes, I was just, yes, you can measure more things than you necessarily can do on your physical model.

Because you can stick on some simulated sensors and they can tell you what's happening. And like you were saying, with pressure. Yeah, yeah. And, you know, this is one thing. So people talk about MBSD and I want to get my terminology straight here because different people mean different things. When I talk about MBSD, I focus on model-based system design. That's what I was going to get at.

People use a different thing for S in different situations. Oh, okay. There's model-based system design and there's model-based software design. And I hear a lot of software design, but I feel like that kind of limits our mental scope of what we're actually trying to do here. If you think of it as system design, you can develop these control models, you can develop these plant models, these physical models, before you ever get any hardware or even settle on, you know, what your product's going to look like. And then you can start to play with both of them, not just the control model and making the control model, you know, work the way you wanted to work. But also you can say, well, if we change this aspect of the system or, you made it a little bit

different in this way, well, then we can control it better or we'll get this extra feature out of it or things like that. And so it's more like when we talk about model-based system design, we get this kind of back and forth between the two that's really, really powerful. And it happens earlier in the cycle. We talk about, you know, in software shifting left, right? being able to test things early on, where it's cheaper, where you've got more chance to influence the outcomes, right? And before your product gets built, you can already start testing things and trying out ideas and making suggestions for changes.

I think it's funny you say that because most of the time when I get started with that and then I say, well, what about another sensor here or really make the system a lot more stable? The answer is always, no, that's too expensive, or when I say, okay, how much does it weigh? Because that's really important to my calculations. They're like, oh, well, you know, somewhere between 30 pounds and, I don't know, maybe 250. And I'm like, that's not a range. That's just, you know, everything. Sure, sure. Yeah, I definitely think of it from the perspective, you know, agile or.

you know, lean MVP type thing, minimal viable product. So like these things are, it's iterative, right? And so, you know, they give you a big range. Well, okay, you know, give me, at least try to give me, sometimes I'll use the phrase like your 90% confidence interval. You're pretty sure there's less than a 10% chance it's outside of this range. But, you know, that's going to change over time. we're going to adjust and iterate, and the control system will have to change to adapt to that.

That's the reality of dealing with systems, right? If in the opposite would be worse, honestly, they tell you, well, this is the exact way. And then you say, well, okay, we need to make this one change, though. And they say, no, we already told everybody this is the exact way. We can't make any changes. That's way worse. what kind of systems are best uh can best utilize this model based system design i mean you mentioned tractors yeah um definitely robotics of just about any kind yep yep those are big ones um i mean i

I worked primarily, and they call it the off-highway vehicle industry. So that's construction and forestry and mining and tractors. I guess that's kind of the big ones. So that's where we used it a lot. I know automotive uses it a lot. I've talked to colleagues that use it in space, or space technology, I should say. They don't actually send their hills to space. yeah, I don't know.

Usually it's more complicated systems, but I do think there's more room for, you know, smaller and medium, you know, businesses to be able to take advantage of these. I mean, obviously you still have to weigh the costs, the pros and cons, right, of investing in this. But the idea of being able to, you know, try out your algorithm and see how it works

and see what goes wrong with it early on and adjust the product plan. Oh, I miss medical devices. That's a really great place for it, too. These things that are, yeah, fairly complicated and have to get right. But it's a powerful tool that can help others, too. What about things like FitBed? And I don't mean FitBed itself.

I mean, like, a consumer product that has a limited number of inputs and a complicated interface and a complicated interface and a complicated. BLE interface, do you think those have a good place for the model-based design, or does that not have enough algorithmic interest and should be tested under like TDD or other forms of testing? Sure. So I don't have a Fitbit. I've never had a Fitbit, but I think they've got, what, an accelerometer in them. You mentioned some Bluetooth. User interface, maybe one or two other sensors.

Yeah, a couple sensors. Yeah, which I have actually hooked up user interfaces to my hills before. You know, if you're like, think of a tractor, right? They've got some sort of control system in there and you've actually even gone so far as to set up multiple monitors and make

a fake cab for the tractor and have people sit in the cab and control it. like they would, and they're controlling a virtual machine moving around. Is that pure simulation, or does that actually have hardware there? Yeah, it has actual hardware. So we'd be doing it with hardware than we'd simulate, actually. We'd actually put all of the controllers, or at least all of the ones that were most important into that simulator, and that would allow us to essentially simulate the whole

vehicle without having the vehicle there and see problems and communication between the two. You mentioned Bluetooth. Again, from my background, I've done a lot more controller area network can messaging. And in that case, yeah, we've definitely simulated that and the delays that come from that, right? Because there's some time to measure things, some time to send a message, receive it, and, you know, complete the loop sending the control algorithm or control. value back out to the thing that is actually doing the controlling and telling it what to do. And so that's a case where, I mean, we're talking usually tens, maybe hundreds of milliseconds,

but still valuable to be able to see how that affects things. And if we can reduce canned traffic and still get by with a good control. Do you, so you show it to humans for some in the loop, simulation and can you have you ever done it so that you end up with a camera that then has to parse it and

and use that as part of the testing mechanism no is fine I'm not trying to trick you I'm just wondering if you have I'm just trying to understand what you mean by having a camera and trying to parse the camera so let's say your your tractor has a small display four by six-ish inches for those of you who want to know four by six of what's and and you can then

have a camera look at that and make sure that as you are doing testing it is showing the right thing yeah I've never done that as a hardware in the loop test system before but I have like had team members that have worked on, you know, vision systems like that, that are monitoring the, you know, the AV system for, for, in this case, I think it was motor, motorcycles. It goes back to the question of how far do you measure. What do you measure? What do you simulate? What do you, which part is the hardware in the loop and which part is the loop? Yeah, yeah. So that's something we've kind of. of like brushed over here, but, you know, hardener in the loop is just one kind of simulation.

I mean, we actually, you know, if we're doing model-based system design, we're probably starting with what's called model in the loop. So when we say all these in the loops, it's very confusing. So just like get that right out of the way. Whatever that first word is, that's sort of the thing that's under test. So when we say model in the loop, it's like a control model. So you're just working on your computer at this point, right? And you've got both your plant model and your control model. on your computer, they're connected up. Maybe your control model is set up to run like a fixed step sort of, you know,

ticks like it would on your controller, right? But then maybe your plant model has real physics and it's got variable time steps so it can solve, you know, huge systems of differential equations and get, you know, realistic outputs like, you know, like real physics, right? Which doesn't really operate on a tick basis, at least as far as we know. get down to the quantum level and maybe that'll change. And so in this system, if we were talking about different implementations of this, your control would be your PID loop, let's call it that because it's easier to think of that.

And the plant here would be gazebo or Wii bots or Simulink or something that that simulated the physics of the real world and interacted with your model, your control unit through whatever mechanism, whether it was by simulating physics or maybe writing to and from files on your disk drive so that it could read them back and forth. Is that right? Am I getting it? Yeah. For the most part, I wanted to nitpick out a few words, but I think I'll just let it slide for the moment. Like, this is all happening in Simulink, right? So your control model is developed in Simulink and your plant model is developed in Simulink. No, no, let's be realistic. Nothing I am developing is in Simulik. And I should be, you know, cautious. I mean, my modeling is

my MBSD has been in Simulink. There are other tools out there. I just, I don't really know them. That's not where my career has been. So maybe I'd be curious to hear more about that. Well, see, my point with my model is not in Simulink is my model is likely to become the thing that runs on the control unit in the vehicle. And so I usually start very early in C and have it talk to WeBots, Gazebo, Simulink, another Python script that would simulate whatever I needed. or even an Excel sheet. So, yeah. So, yeah, my model's never insomelink because I don't really use MATLAB very much. Yeah, well, let me put in a little advertisement for it then.

One of the things, you know, models, you know, they're abstractions from reality, right? They're simplifications. We talk about control models. It's kind of similar. We get some extra benefits out of that versus just jumping right into C code. First of all, like the control model, it's usually focused on like what is the application doing, right? That PID loop, it's abstracted from the operating system and all of those things, which kind of has a nice benefit in that your mind is allowed to focus to, you know, keep it simple, stupid, right? to have that ability to focus on the application logic

and not worry about all of these little day-to-day bugs. Oh, I didn't declare that as a non-volatile and things like that that can really trip you up when the code gets in the way. And that's really nice for your stakeholders too. Maybe you're talking to mechanical engineers or electrical engineers or even pull up simuling for business people and show them, okay, here's the kinds of things we're doing.

here's the data coming out of it. Here's how we analyze the results. By the way, you can have this data, and you can use some of these tools to analyze this and see if it's doing what you want. And then the last thing I wanted to mention about that is the portability side of it. In that, you know, we're dealing with an abstraction of the controls.

And the nice thing is that's not hardware dependent. So your model kind of becomes the source of truth. And we make a distinction here. We say model deliberately. It's not code, and that's because we actually generate code from the control model. So we set up a special system target file type of thing and use a target language compiler, and we actually generate C code. I've seen that C code.

Don't be proud of it. It's not meant to be read, right? That's not meant to be, you know, I mean, you can read it. And there are better ways to set it up. in worse ways to set it up for sure, for sure. A good modeler will help to make that more readable. But the point is, like, the source of truth is the model itself. And so then if you want to, you know, port your application to a different controller or a

different board or a different processor, you just have to change that system target file and that target language compiler. All of your logic, still tested, still good, is able to. able to move over and you just generate a different C code for it, which can be really powerful. It's not fair because I started early with Matlab. And then it was always too expensive after about year 2003. And so I haven't, I don't know what the state of it is now. And I would never go back to Matlab, I would always go for whatever the Python version is right now, which not SciPy. It's not overlord, overtone, over something.

There are a whole bunch of kids. You're looking to me to help you. There are a whole bunch of control kids. Anyway, I wouldn't go back to Matlab because it's expensive and I tend to work with smaller companies. And so it is true. True that when I last showed some of my Python simulation code to some business folks, they did run from the meeting pretty much screaming, which was sad. I didn't think it was hard code. And I understand, you say you just change the target. And I say, if it's in C, it's, and you don't have to change the target. It's just C.

You can run it on your computer and have it deal with files, or you can run it on your arm cortex M3 or your PIC 32 or PIC 8, and it's the same code in all of them, as long as you have your variables sorted, which unfortunately I do naturally, so I don't worry about that. To me, it's more confusing to have the model, because you say it's a model of truth, and I say it's a model of truth on your computer

and where mine is a model of truth on my microcontroller, which isn't really, neither one is true. There is no truth. Sorry, you got me reading about Descartes's demon, and now I'm sure there's nothing real. There is no truth. I think, I mean, a slightly less, okay, the way I would look at this is

the simulink is your C code the simulink is the model it's the thing that you are making the controller out of and the control system out of and it produces C code and the C code is should be treated as you would treat the object code and stop worrying about it

and as long as you know you're doing the right things with testing and the model appears to work in the model situation and it appears to work on the target and, you know, everybody's happy. I don't think there's a problem with that. It's a top-down approach, which totally works. Right, right.

And for certain customers and systems, I think that's way more appropriate than some of the things that we traditionally do with Embedded, which is start at the C-code or start a Python. But, you know, if you're making a gas turbine engine control system, I don't know that I want to start with C. But I have all these nice libraries. All I have to do is type in P.I.

idea and it does everything it's supposed to do. It even differentiates properly sometimes. Yeah. I wanted to come back to one thing that you said earlier, Alicia, which is the cost. And so you said you were working with smaller companies. One thing that I'd point out, too, is that I think there's some sort of startup program that Mathworks has that will get it really cheap for you. Well, really cheap is relative, right? It's not free. But we, When we're talking about, like, big companies buying these licenses, you're measuring in the tens of thousands of dollars. So not cheap, let's say. But you can get it down into, I want to say, like, $4,000 for, like, every license that MathWorks has.

If you're dealing with, like, a startup that has, I don't know, I've got some criteria there, like, less than five years, less than a million in revenue, to less than 10 developers, I think, something like that. So I know you're starting a consulting business. The one thing about a consulting business is we're not a startup. And yet we're the ones who need to have access to these tools. I mean, yours will be for five years. But ours has been going on for quite a long time. And we're small, but we're not a start.

Yeah, the customers would have to get the licenses and share them with them. Yeah, I was going to say, yeah, you can work with them. And sometimes they do. Yeah, yeah. But sometimes there's a reason they're in the same boat, and they don't want to do the paperwork. They never want to do the paperwork. But it's been the same with compilers. We've dealt with customers that are like, we're using Kyle.

Yes, and now we're using GCC on everything. Kyle, I'm so happy. But that's a relatively new thing. It is. It is. I still have many compilers installed. We all have been through IAR, Kyle. So, I mean, this is not a foreign situation.

No, it isn't. I guess it was just a benefit is there, then it's worth it. I loved Matlap after school. Yeah, me too. I used it all through grad school. And I was really getting into Simulink, and then it was just too expensive. And I think I kind of got to stay in school. Well, yeah.

But then I kind of got burned when I got out of school and had to find all new tools. And that was before Python had all of it basically replicated. So I'm, Matt Lab, I appreciate it. It's amazing, but it leaves a little bit of a bad taste in my mouth. And not just because Simulink is one of those liney languages like Labview is. Limey? I need to type. I don't draw my coat.

I'm just questioning the adjective. It has a lot of lines. Right, actual drawn lines. Drawing lines. Drawing lines of code. Yes. Okay. Right.

And boxes. Boxes. Like, why are there boxes here? Because it's visual. Yeah, I don't get it. Okay. If you can't read my code aloud like a story, I don't want it. I'm going to stomp off to my room.

Sometimes it is actually more intuitive, especially on the physics side, right? Like, you get a schematic for like an electronic schematic or a hydraulic schematic, right? The way we build up the tool and seeming like it's called Simscape, it looks like a schematic. So your electrical engineer or your mechanical engineer can look at it and be like, yeah, that looks like what it should. Yeah, that's the thing. It's for these big physical systems with lots of, like you say, hydraulics, electronics, mechatronics, all this stuff. If you want to simulate that, I don't think you want to be starting at the typey, typy languages.

Because you've got to start with something that looks normal. to someone who does the physics or, you know, a block diagram that makes sense and then how these things feed to each other. So making robots in Wii bots is usually a very dry sort of thing. And I'm terrible at it. And I am amazed to watch someone be able to create this robot very quickly. And then they'll want to change something and they'll have to rebuild it from scratch.

And I'll be like, oh, no, you just change the line in the protophile. and it's just this whole like discrepancy in world view whether or not you should be drawing things or whether you should be typing things and I am so far into the typing zone anyway sorry William you're in the drawing zone aren't you we have derailed this conversation I guess you could say I am I mean when you're doing mat lab that's typey right um yeah like Python um but I guess I'm ambidextrious in that a little bit. You mentioned different types of simulation, and we talked about hardware in the loop where the loop is the simulation and the hardware is what

you're testing, and model in the loop, which is more when you're testing the model, which is more the math area, unless the code. You have two more acronyms here, S-I-L and P-I-L. S-I-L is

software in the loop? yeah perfect yeah so you take your model right you generate your code or maybe you write some hand code but now you want to see does it how does it interact with the physics so you connect up import a block one of these silly little blocks with all the liny things and connect up to your plant model and see how the code itself operates and then the processor in the loop again remember this first word it's the key, right, of what's under test. So put your software on your processor. You don't have the rest of your board, the rest of your ECU,

but you still connect it up to a plant model and see what it does. I've seen vehicle in the loop. The other day I saw, oh, a friend mentioned human in the loop. I don't know what he meant by that. That was just a text, but I'm curious. He said they were doing that at his new company. That does sound like the matrix. Well, I mean, you did mention you had humans interact.

with your hardware, it is questionable which one of those two you were testing. Good point. I mean, it's arguable that human is part of the loop. Part of the loop. No, because they do something and something happens in simulation. If the simulation is the loop. Yeah. Yeah, hardware at the loop.

It's funny that I guess I, even having read about this and thought about this, I accept that in the loop means in simulation, but I don't think I ever quite triggered on that. It was always testing. It was hardware in the testing loop, not hardware in the simulation loop. Because you can simulate software on its own and put it into like unit tests.

And the unit tests don't test everything. They don't need to simulate everything. They only need to simulate small parts of it. Christopher is giving me weird looks like I have to simulate something. I'm just realizing all of this is simulation at some level. Yeah. And you can do unit testing. Tomogachis there.

You can do unit testing or more likely manufacturing testing where you have the hardware and you communicate to it and you expect certain responses. So you're unit testing with hardware in the loop, if that makes sense. Does that make sense? Is everybody nodding? Yeah, yeah. That's why I said manufacturing testing, because that's something, an area people would understand,

or bring up testing where you have the board in place and you're testing it as you, but you weren't letting it just run as a normal system. You're doing part testing. Yeah. So the idea that in the loop means with simulation is a little new to me. It makes sense, but a little new to me. So I'm still wrapping my head around it. And you keep saying with simulation.

I mean, I would say open-loose loop tests are arguably a kind of simulation. So you can do unit testing. You can do that closed loop or you can do that open-loop. We'll do open-loop tests of models as well, especially early on and specific components. So I don't want to confuse you here. I think that the key here is, is there a closed loop or is it, you know, input, unit under test, output, and it doesn't wrap around to feed back to the inputs. Okay, that's a very good point, because there's a lot of unit tests that is just input to output and whether or not.

so for it to be in the loop there has to be a simulation unit under test output and unit under test has to go back to simulation yes did everybody draw like like a box that's the simulation and a box that's the unit under test i'm getting hung up on that Okay, model and simulation. Let's get those two straightened out. So the model is the noun. The simulation is the verb. So it's the act of the thing running. So when you say it goes to simulation, it's linguistically confusing to me.

Okay. This is because you're all in simulink and I am trying to wrap my head around doing this with C. or a microcontroller hooked to maybe a physics unit like Ross's gazebo or maybe a series of files that it, I worked on an audio system and we would play files for the audio system to listen to. And so that playing of files was the simulation in this case. And the hardware would listen, and then it would respond, and the simulation would be able to say, you responded correctly. That was right. Or it would then play a different file so it could figure out what was wrong.

Okay. Okay. I'm being pedantic. I think I know what you're saying simulator, I think, not simulation. Sure, yes. That's all right. That's all right. Yes. I guess my terminology there is difficult because I have one simulator. that is the, which is like the large program, Ross Gazebo. Yeah. And then I have simulations, which is the data that represents the vehicle going to this location. And that's the simulation.

And I have a vehicle going to that location. And so I think about how my model is working in this simulation or that simulation. or that simulation that are both running on the same simulator. These words are very confusing. It's good. It gets you, you know, it's a chance to learn, right? It's a thing that I try to, when I'm leading teams and helping, especially, you know, younger engineers, is like, learning happens, you know, at the edge of what you know and what you don't know.

So you have to go into uncertainty and, yeah, it's okay to, you're going to make mistakes and things aren't going to go right. But if you weren't making mistakes, you're probably not learning. So hopefully this is helpful to you and to the listeners too. I've had a listener recently who asked, how do you learn complex things? And maybe, and we didn't answer that question because we didn't know how would you have answered it? Oh, more books. Has anybody read? Surely you're joking, Mr. Feynman. Not a personal favorite of mine, but I know a lot of people who love it. Right, right. I'm not going to comment on the man because I definitely think there's some problematic aspects there.

But I think his description of how he learned, you know, he talked about reading a paper and the first time he reads it, and it means nothing. to him. And then he forces himself to go back and read it again. And okay, well, now that I have the context, I kind of understood where it was going and it made a little bit of sense, but a lot of the details don't match up. And then comes back and reads it again. And the third time, suddenly things are clicking and falling into place and everything starts to make sense.

I think that's a real challenge, right, to force yourself to be in that discomfort and to be in that place where you don't know what's going on. and have to do it again and again until it starts to click. That's a good anecdote from the book. It has been hard for me to remember that it's okay if learning is difficult. Yeah, I mean, my favorite thing to say

is hard things are hard. But it's so easy to look around to people who know things and think that it was easy for them to learn. Yeah, but you're not looking at the 10,000 hours or whatever that they spent. doing it you know stuff hard things take repetition repetition a lot of repetition and uh seeing you know variants of things that are similar to it but with yeah it learning things is anything worth learning is difficult usually at some level unless it's just you know somebody's

phone number but then we all hope that this is going to be the thing we're spectacular are at. This is the thing that comes easy for me. Well, I think that's a cultural thing. Is it? Yeah. I don't, see, I think computers was the worst thing for me because I watched many other people learning computers for the first time, a college level computer course. And I watched so many people around me have a hard time. And I didn't understand. It was like computers made more sense to me than just about anything.

made more sense than the social interactions made more sense than the math I was trying to learn which was calculus right but there's plenty of things that aren't easier for you that are easy for other that you know everybody everything's easy for everybody else I see I mean people do have affinities for thing but I think we overstate affinities for things

right I completely agree and it is it is hard and you have to keep working I think computers were, quote, easy for me, too, except I started using them when I was five, and I spent every day on them from five to when I went to college. And it's like, okay, so that's, you know, what is that? 13 years or whatever, I was using computers before I even got to learning about computers formally. That's not nothing. And I think I had some of that, too. I mean, you just forget, yeah.

Many afternoons spent in the library with the TRS 80 and a tape deck. And you don't count the things that are fun. Right. That's not learning. That's just fun. And that exploratory learning is where, like, real magic happens, right? You read a textbook and you, like, you learn the exact thing that everyone else learned from the textbook. But, man, that exploratory learning, that's where it, like, gets in your gut and allows you to, you know, thrive in the learning process.

And to look back on the simulation stuff, I think, you know, I've been doing a little bit of electronics, trying to learn some electronics. just for fun and that being able to explore either with a breadboard and parts and not have any fear of failure or with things like online simulations of circuits which they're very good ones that are free and you can just put parts together and put a fake oscilloscope and see what happens and test circuits and stuff i mean apart from reading the art of electronics which the first couple times i tried to learn electronics that's what i did oh read the art of electronics and then i'll know Electronics. No, that doesn't work. It doesn't work. You'll have read the art of electronics.

You'll have read the first chapter. You've read the first chapter and bounced out of it. But nothing, yeah, you have to get your hands dirty and actually try things and see, see what makes a difference and make changes and, oh, that did that. Oh, that's interesting. Or find the places that you don't understand, you know, that you can put your effort into because everybody has different things they get hung up on. Yeah, yeah. I want to like mention something, you know, this is like part of what I see my responsibility. I'm an engineering leader is like creating that safe environment where people can learn things and fail at them. There was this program I helped put together at my, my former employer called the Software Craftsmanship Club program. And it kind of came out of this idea that, you know, myself and a colleague, his name's Joe Fisher, don't know if he'll listen to it. But thanks, Joe.

We were lamenting that, you know, everybody's doing the work, right? And when they want to learn something, they go to a course to learn it, but it's kind of a solo thing and it's, you know, dry knowledge, right? It's not living knowledge. And so we decided to like kind of do this experiment where we'd create a software craftsmanship club and get together, you know, maybe eight people, something like that. and we set up people in pairs and said, you guys pick your language, whatever you want to do.

You want to do Python. You want to do C++ or C. But we're going to pick topics and go through them, like clean code and things like that. And we'll go through them as a group, talk about them as a group, and then we'll assign little code cata's, little projects for people to do.

Or like, you know, hour-long projects. And they go off and apply what they learn. in it and they, the partners would kind of do code reviews of each other and say, hey, I did it this way. You did it that way. I like the way you did it. You know, kind of learn about the coding, learn about the concept, and then iterate again. And all outside of the, you know, the raw, you know, when you're working on code for a client, right, or for your boss, you're not safe to experiment. You can't try stuff. If it fails, you're going to be in trouble, right? So kind of creating the space where like a group of people

could kind of self-direct and pick out different topics and learn on it and talk to others about it and actually apply it. And I don't know, that was kind of like one of my more happy magical experiences as an engineering leader, seeing that start to come together. When you told me that, I immediately jumped to Greg Wilson and his software carpentry. He was on the show a year ago, two years ago. And it was

a somewhat similar concept of trying to make code more approachable and as an ongoing learning exercise.

To make better code, not just here's what you do, but here are some idioms that are better.

Oh, don't forget about software patterns. And, things that are part of the ongoing learning process that it's hard to maintain when life you know when life gets in the way it's hard to say oh you know i kind of promised myself i'd read a technical

book every quarter and i'm i haven't because i'm busy there are ways to get into it how did you keep people interested in motivated you know when i think about motivation I've you guys heard of more books, Daniel Pink's Drive. I think I've heard of it, but I don't know much about it. Okay. Like the root of it anyway, he's a psychologist, right? And kind of gets at the root of what drives people. And it comes down to kind of three concepts.

Autonomy, mastery, and purpose. And so autonomy is the aspect of, you know, you want to be able to decide for yourself what you want to do. So like with the software craftsmanship clubs, we didn't like dictate you have to do this as a club, right? We bring, we actually have the club vote

on the next topic, right? And so they got that kind of sense of like control of their own fate, right? And then the mastery, obviously software craftsmanship, right? That's the idea of like, oh, I'm going to get really good at what I'm doing and

that feels like, you know, progress. that feels like, you know, leveling up in the video game sense, right? And then from the purpose side, I guess that kind of comes internally. Like when I'm leading teams, I'm definitely sitting and talking with engineers and trying to understand, well, what are you doing this? What is your purpose? And trying to help them evolve that too and ask themselves the questions. And so, yeah, I guess that's, I lost track of what your question was.

But hopefully I answered, this is how to motivate. This is where it comes from. You don't motivate people per se, but you can kind of highlight what drives them and create the space for them to follow their own motivation. We've been doing Tech Book Club on the Embedded Patreon Slack, and it's been a tough book. That's a tougher book than I intended.

Bailey's mentioned it. But it's interesting. And I have found for some of the things, of the other people who have done, so the Tech Book Club is, I mean, this book is led by me because it is the book I wanted to read and I said, anybody who wants to join me, please do. I will make an effort to make it accessible and basically please join me, but, you know, do which you want. And other people have stepped up and said, okay, I'm reading this book.

Anybody wants to join me. I want to talk about it. And that has led to, you know, other people reading books and talking about it. And I felt bad because Philip of Embedded Artistry read a book that I recommended. And I was there with him for the first half and then the book got super boring and he finished it. And I was like, yeah, I didn't because it got super boring. But sometimes all you need to do is to find a group and say, yeah, this is what I'm doing. and I promised that I will do it

and I would really be happy if I could talk to you about it and whether that's three people in your group at work or three people in your LinkedIn group, that may be enough. I mean, I don't think I could stop data-driven science and engineering now because they're all kind of interested. I am too. But it is, it's harder than I thought it would be. but soon we will get to how data and control systems are the same thing and i am so looking forward to that okay yeah no i can't agree more i love learning with others um and i get lots of

great friendships and discussions and you know the enriched learning experience of well here's how i see it and they say well i don't quite see it that way and like that's the That's so valuable. And then we follow it down the weird avenues. I don't know. There's so much good out of that. Well, like the first half of this show where we tried to figure out terminology, like simulator. Have you read any good books lately?

Have I read any good books lately? Yeah, I've read lots of good books lately. So I'm in the Des Moines Tech Book Club, which is some of my besties here, since I've moved here a couple of years ago. We read books. I read fun books. What are you looking for? What is the Des Moines Tech Club read recently that you liked?

Good question. Let's see. I have not been a fan of the latest book. So that's probably not a great example. I mean, you can totally slag them. I'm happy with that. But if you want to stick to the positivity thing, I'm good with that, too. Yeah. In fact, so I did the thing that you just said, I made a promise to myself a few years ago that like I'm going to stop wasting my time. Like once I decide like this isn't valuable, I'm like, I'm one of those completionist people. It's like, oh, I got to finish it. And I'm like, no, I'm going to be hard about it because life is short and I don't want to waste time finishing things that I don't want to do. So I dropped out of this book and I'm planning to join back for the next one. But yeah.

As far as like books that we read recently, oh, there's one called Leadership B.S. From your region, California, Stanford, I think. Jeffrey Pfeffer, I want to say his name was. And he talks about kind of like the things that you're told that kind of make you feel good. So he's been studying organizational dynamics for 50 years. and you know there's you know a lot of things out there and I and I want to we want to believe those right they sound good you know a lot of motivational talk around leadership and and things like that and he kind of puts a pin in some of that and says look you you should also know the reality which is you know what really happens with power is not necessarily what we want to believe happens with power in organizations or even with the people who are saying. this actually did to get where they are. And so understanding the difference is critical.

You can waste a lot of time and energy, not understanding that and believing the things that maybe people are saying that isn't really reflecting reality. And he tries to help people navigate what real power dynamics happen within organizations and how you can use that to kind of make organizations better. Are you laughing? No, no, I'm thinking. I'm thinking of the time I quit my job, but I only told, like, my boss and my boss's boss

and didn't tell anybody else. And then I sat down to lunch with my boss's boss, and he said, have you told anybody? And I said, no, but I'm very interested in how the brumer mill has worked. And so we got into this long discussion of how information travels through the organization we were in and how amusing it was to watch and who the connectors were and and I'm not going to say gossips but let it take take it as said which I guess I did anyway yes sorry you know I'm I'm humming because you're you're making me think yes cool what about you Christopher have you read any good books have I read any good books late well I'm I'm just starting to do the thing that you mentioned

of reading more than one book at a time usually I only read one book at a time Um, but, uh, so I'm reading, I'm trying to read a nonfiction book and a fiction book at the same time and switch between them, depending on what I feel like at the moment. The fiction one is Will White's pilot, right? Yeah, kind of. Which hasn't been as good as the first two in that series. I was, I was just going to mention I'm continuing the Pratchett read through. Oh, oh, the Pratchett reads through, yes. Yeah.

Which I've already talked about, but I'm also reading a history book, the Battle of Cry of Freedom, which is about the Civil War, which I'm quite enjoying. also from a political standpoint and I love history I took a dog botics course recently that did a drum machine and that book the makebook that kind of goes along with that that was written by Kirk Pearson the what is it called? Hang on

electronic music from scratch I've gone through most of that reading it while also going through this other class and that class led me to another book that I'm kind of flipping through. So I'm not calling it's reading, but it's an old book called the Seymots Cookbook by a guy named Don Lancaster.

And it's all about things you can do with Seymus chips. And the impetus for this was making synthesizers out of various logic components and I sees and things and op-amps. So I'm kind of looking through that for things I could do as projects. Is there anything, maybe I'll ask, for both of you. Like, recently that you've read in a book, a concept or an idea that's just really

influenced how you see the world or found profound. Hmm. Tough question. I'll throw it too, Lisa. Okay. So I mentioned the data-driven science and engineering, Stephen Brunton and Nathan Cuts, that we're reading for a tech book club. Okay.

The thing is, I briefly said something about, you know, dynamic systems treated as data systems. This book has blown my mind so many times because of things like that, where, I mean, I've taken machine learning as a course from, I did the Andrew N course, I did the, the Carr's course from, the Car's Course from Udocity. Yeah, so you have. And I've done classification in practice. I've done machine learning in practice as part of jobs. So a decent background of that. Half of my major in college was control systems. So really happy with PIDs, not so happy with like Hamiltonians and Jacobians and LQRs because that was after my time or beyond my abilities. I don't know. Anyway, he keeps like just taking these things that I think of as data solutions and data views of systems.

And then he uses them to do things I would never agree to and never have considered. like Fourier which to me is you know really special very important for control systems important to understand you're doing signal processing a very interesting way of looking at the world it's just another data tool for him wavelets just another basis function similar to any SVD that you could do it doesn't really matter you know just you have a tool box of tools and that's just one of them. And I'm like, no, no, no, no. Forier is the most important tool ever. But for him, he's got, you know, a ton of them and he's just flipping through them to do different data things. And it keeps blowing my mind that you can just do that. These things

that I thought of as concrete whole. visible and useful in many ways, balls of information, he's just like, he's like put it in a gumball machine and said, oh, you can have any one of these. And I'm having a really good time with that. I know that, like we're in chapter five, I think, finishing chapter five, which is classification. We're going to go to neural nets next. But then we go to the new chapter, which is all about dynamic systems and treating those as data systems. And I'm like, no, no, no, PID, I don't think we can go there with a PID, but I've actually read ahead. And I know that we can, and I'm just still boggled by it.

I mean, what's math, right? It's just, you know, logical rule systems. This is all just a cheater way to teach somebody linear algebra and ODE's. But I didn't know that you could call it data science, and I would agree. Just linear algebra and Odees is everything. Yes, yes. It's the universe. It's a reason we do quantum and general relativity with all of this stuff.

And PDEs, but... Well, I mean, PDEs is part of this, too, but I didn't ever agree. If he had written the books, linear algebra, PDEs, and ODE's, for engineers, I'd have been like, I'm not reading that. You can just stay on the shelf, thanks. But somehow he's got me engaged. And I'm just gobsmacked by it. So this is an interesting thing with the plant models and stuff.

I mean, you can just, you don't have to, I talked about using the hydraulic schematics and electronic schematics and stuff like that, but you can just represent those as math too. And in fact, there's a whole like system identification concept where they just like gather the data, they just censor up particular products, right? and just gather all of the data and create a mathematical model that represents that thing without ever trying to understand the underlying physics or mechanics or things like that. Yes, I believe in this book, we will be going back to that where you take the outputs of your system and you don't care what the inputs are. You just treat it like a data system and then you create an analytic solution for, from that, which is so wrong, you can't do that, but you can't. It's just, it's using,

it's using the system to describe itself instead of trying to make a model and using, and then trying to fit the model to the realities of physics once you have static friction and all the other kinds of friction and damping and brownouts and bleed resistors and so many complaints here. You know, it makes me think of something. So this is, we're going back over 15 years now, I think, to my graduate advisor. His name was Cliff Chonzie, absolutely beautiful man. But I remember one of our last conversations before he died, we were talking about, he called

them automaton's. But he was talking about how. how, you know, what, you know, he anticipates in the future is that essentially what we have today, like AI models that could look at raw data and discover, you know, what we understand is the current laws of physics now, but also by looking at that raw data, find additional patterns that we don't necessarily understand and actually start to discover the laws of physics that are beyond us and explain things, you know, dark energy or dark matter. or, yeah, down at the quantum level, too. Didn't you tell me about a kid who went through, like, a bazillion amount, an incredible amount of astro data and came up with a whole bunch of discoveries because he used different techniques? I'm going to plead the, I'm old and forgot about that.

It was a good article. I will look at it. I think it went out in our newsletter, so I'm pretty sure we have it. Which Christopher puts together. There's no question that I both found. this, posted it somewhere, disgusted with you, but I have zero memory of this at all.

But yeah, it was, it was, there were patterns that nobody else had noticed because they didn't look in that way. Yeah. So yeah, I think I think there'll be more of that. Although finding an external pattern,

finding a pattern in the data, sorry, that's better than external pattern, is not the same as finding the cause in the physics. And not all patterns are real. As humans, as good pattern recognizers and seeing phases and everything. Yes. Yeah, we had to be careful of that too.

And for that matter, I mean, what we understand as physics is just models, right? We don't know if they're real. I mean, we used to have force equals mass times acceleration. And then we had to redefine what acceleration was because Einstein came along and said, yeah, it's not quite what we thought it was. Just don't go too fast or be too near something big. This should be fine. These are approximations, right?

Yeah, that's the whole thing about physics and learning physics is one series of approximations getting slightly less bad over time the more you learn. And I'm sure that's true. I mean, all models are wrong at some level, right? Yeah. Okay, I wanted to ask you a little bit about Spark Embedded. you and Bailey have started a company.

What do you want to tell us about it? Let's see. Kind of came about. Bailey and I started, we started a group called Iowans of Things, which is a sort of embedded group. Sorry, I just got it. Yeah, yeah, yeah.

IOT, okay, okay, got it. Iwins of Things. So an embedded group for kind of people. in Iowa to meet up and talk to each other. And we have hardware hangouts where people come and talk about stuff. And then we have the firmware fellowship. I guess we're into alliteration where it's more, you know, technical conversations. Anyway, we started that a couple of years ago and started like hanging out and getting

to know each other and liking each other and started doing bar trivia together. We had a team called The In Sparkled Barbarians, have a team. In fact, Wednesday night is the end of our season, and we're in the lead at the moment. But that led to us having conversations about, you know, we're working for other companies, and why don't we think about working together and, you know, kind of creating a space that we would want to work for, right? She was working solo at the time. But, yeah, I'm very passionate, like I said, about, like helping create collaborative teams where we can bring in engineers that can can really learn to work together, learn from each other, start experimenting,

which involves, you know, potentially making mistakes and failing and see if we can use, you know, MBSD and Hill to help accelerate firmware development and, yeah, and then also then feed that back out into the community and see if we can help, help others do this too. And so Spark Embedded. We're actually kind of technically launching here after Labor Day, but we've already been doing a lot of the groundwork and got some plans. I don't want to turn it into a whole advertisement, but if you want to talk to us, we're both on the Embedded FM Slack, or you can find us on LinkedIn. We're going to be at SuperCon and Embedded World in L.A. here in a couple of months.

Honestly, just really would love to meet people who are interested in working with us or partnering with us. Regardless, even if you're not interested in those things, we just want to meet people who are, you know, love what we do, right? And have great conversations and learn from each other. So, yeah, I'd love it if people would come up and say hi or send a DM or whatever. And we could chat more. Cool.

And then you said you're going to supercromb an embedded world, which was the other question I had for you. So I think we've kept you quite a while. William, do you have any thoughts you'd like to leave us with? Sure. So I had one, I was thinking about, I have this friend, Dustin Thostensen. He's in the Des Moines Tech Book Club, and he has this thing that he says that most engineering problems aren't technical problems. They're people problems. And I completely agree, 20 years into my career, like, you know, we talk about systems.

We talked about a lot about systems today, right? But it's not the individual pieces that are so bad. It's the that are so challenging. It's the connections across the system, right? And people and communication, those are different parts of a system too. And so, yeah, the way we helped optimize systems with people is embracing, you know, things like curiosity, embracing uncertainty, and being okay with asking questions and learning from our mistakes.

And that's how we eventually get those better outcomes. That's what we're trying to do with Spark Embedded as well. So, yeah, I guess the last thought is, you know, think about that. Think about how people, we don't think about how people are problems. But think about how people are a part of the system and how you can help to make the system better by working with people. Our guest has been William Griffin, engineering consultant and co-founder of Spark Embedded. Thanks, William.

Thank you. Thank you for having me. Thank you to Christopher for producing and co-hosting. Thank you to our Patreon supporters. Thank you to Mouser for sponsoring the show. And thank you for listening. You can contact us at show atembedded.fm or at the contact link on the Embedded FM website, which is where the show notes and the transcripts also live.

And now, do you want a joke or do you want to quote? I should mention the changes to Patreon. For Patreon supporters or people who aren't Patreon supporters, if you become $5 or above members monthly, you will have access to a new ad-free feed of the show through Patreon and potentially some bonus episodes that will only be for people at that level. And we'll be doing some trials of things, we've mentioned on previous episodes for those and maybe some special things with some guests

that are kind of off the beaten path of our usual shows but sort of fun things. And I will also be posting those things to coffee, but there's not an easy way to get like an RSS feed of that from coffee. So if you're okay with that, you'll get them, but it might require you to download them or play them within coffee. So add free stream and bonus episodes coming to the five tier and this will be the first episode that goes on the head free stream. Do you want a joke or do you want to quote? I want a joke.

What is the difference between a strong person and a really, really, really strong person? Repetition!