Embedded - 319: Squidly Tentacles

Episode Date: February 7, 2020

Chris (@stoneymonster) and Elecia (@logicalelegance) chat about the year 2038, their projects, their new finds, and future shows. The year 2038 problem is real. Elecia read some of this tweet thread about it. Single file libraries list on github: (https://github.com/nothings/single_file_libs), including the STB image handling library Chris was originally looking for. Chris is working on a MIDI project with a NUCLEO-144 (STM32F303ZE) board and various breakout boards from Adafruit and Sparkfun. Elecia talked about the NASA Innovative Advanced Concepts Program (NIAC) and curved crease origami. She also talked about PID controllers and Tiny ML. We are now soliciting sponsorship!

Welcome to Embedded. I am Alicia White. I'm here with Christopher White. And this week, it will just be us. Again. Well, we have a lot to talk about. Okay, let's talk about it. First, we got an email from our security show

in which we talked about how we would go about looking at security for a system. Do you recall that show? I have a vague memory of saying things on that show, which may or may not have been true. Well, it was just us. And at one point, Chris said something about how, you know, some things don't really need that much security. And as a throwaway, he mentioned seismometers. Now I recall. We got an email from someone who hadn't worked on it but had a good lead on it,

that there was a seismometer that got an exceptionally large cell phone bill because it had been hacked and was sending out spam IMs. So even seismometers are not safe. All right, let me revise my answer to anything that is not connected to anything and never will be connected to anything, cannot harm anything or affect anything, process anything, buy anything, process or sold, sell anything, bought, processed or sold, or is a computer. So all your rocks are safe.

Yes. Smash your computer with a hammer, put it in a blender, bury it in concrete, and it's probably safe. Just goes to show, never try to come up with an example of something that will be safe because it's probably safe. Just goes to show, never try to come up with an example of something that will be safe because it's probably not. Why would you put a cell thing on a seismometer? It's not like they need to know what they say. You know, have little seismometer meter readers driving around in little golf carts

through the, you know, through Central California reading a little number off the, no. Do you want to answer as as best we can, this listener question, or do you want to talk about our projects? Let's get the listener stuff out of the way. Okay, Lee emailed us and said that they had just watched another video on the end of Unix time in 2038. Embedded code that can't practically be edited in many consumer products was one of the concerns. Is this something that is planned for?

What kind of embedded code would care if their clocks suddenly registered to bean back in 1901? Well, Lee, this is a really gnarly question, so we're going to take some time to answer this well the first thing I'll say is it doesn't matter because 2032 is when Cthulhu will rise from the sea and demand that we all bow down before him and his squiggly tentacles so I don't think that we really have to talk about this but for the sake of posterity I guess we could okay for the sake of posterity, I guess we could. Okay.

For the sake of posterity. So what's the issue? So in Unix time, you measure against the year 1970. And this is sometimes called epoch time. Epoch? Epoch. Epoch. Epoch is fine. Anyway, this is sometimes called epoch time. Epic Time? Epic? Epic. Epic. Epic. Epic is fine.

Anyway, so sometimes it's called Epic Time. There was an Apple II game called Epic, and I always said it wrong when I was a kid. Anyway, sorry. Anyway. When you have a signed 32-bit number, you get, what is it, 2 billion? 2 billion. 2.1 billion. 2.1 billion seconds. Thereabouts.

So you get 2.1 billion seconds from 1970 is, well, that's 2038. And when we talk about 1970, it's midnight, New Year's Eve, January 1st, 1970. And the rollover will happen at 3 a.m., 3-14-07 on Tuesday, January 19th, 2038. It's always a Tuesday. So we're not even going to the same day. We're not going to the same time. We're just jumping. And what will happen that Tuesday morning is that instead of it saying 2038, it will say 1970 and you won't even be able to tell the time. No. It will say 1901.

Well, that's the thing. There are a couple of problems we're going to have here. First, there is the 2038 bug, which is signed 32-bit integer time format from 1970. When it overflows, it will go back to 1970. On the other hand, NTP has an issue, which has a unsigned 32-bit integer, and they started counting from 1900. And when that one overflows in 2036, yes, this is confusing, the world will also end. We don't have to worry about the 2038 bug. What did I tell you?

So the 2036 bug, NTP, very popular with how we organize time across computers, with an unsigned 32-bit integer. I mean, how could it care? It's 130-something years? I do have to correct you. Okay. The signed 2038 bug, with the time being stored as a signed 32-bit integer, when it rolls over, it's going to flip the signed bit.

And so it's going to be negative 2 billion, which will go back 7 years prior to 1970. So when systems with the signed integer roll over in 2038, they will go back to 1901. For the ones that handle signs. Which is most. I mean, times and signs are kind of confusing

when you're talking about calendar times. So I suspect 2038, it will be kind of random what you get. It'll be a mess. So the question is, why is this important? Well, actually, I saw this happen recently in a very unimportant way. Chris was looking at our home server on videos, and I don't know when he had ripped the movie,

although it was a movie we owned, so I'm sure it was ripped here. Even that's illegal, so it doesn't matter. You've already outed me. Alright, well, whatever. It was on the server. It was on a server. And there were ones that were organized by year, and then there were a whole bunch in the 1970 category. And that is, we didn't set the time. Yeah, uninitialized tape. So when you see 1970 as an uninitialized time, that's what's happening. But there was a nice thread recently on Twitter about

the 2038 problem already causing trouble. This is from John Feminella, and I'll link to this if you want to follow him or see what he actually has to say. One of my clients is responsible for several of the world's top 100 pension funds. They had a nightly batch job that computed the required contributions made from projections 20 years into the future. It crashed on January 19, 2018, exactly 20 years before Y2038. No one knew what was wrong at first. The batch job had never ever crashed before as far as anyone had remembered or had logs for. The person who originally wrote it had been dead for at least

15 years, in any case hadn't been employed by the firm for decades. The program was not that big, maybe a few hundred lines, but it was fairly impenetrable, written in a style that favored computational efficiency over human readable. And of course, there were zero tests. As luck would have it, a change in the orchestration of the scripts that ran in this environment had been pushed the day before. This was believed to be the culprit. Engineering rolled things back to the previous release. Unfortunately, this made the problem worse. You see, the program's purpose was to compute certain contribution rates for certain kinds of pension funds. It did this by writing out a big CSV file. The results of the CSV file

were put into other programs that ran at various times of the day. He goes on and explains how this all works. And I'm not going to continue, but basically they had something that needed to check out what was going to happen in 20 years to do the pension forecasting. And it turned over. It was a signed time number and suddenly instead of 2038 it said it's 1970 and how in the world can you

contribute to 1970 pension funds? So that's one area. Embedded systems is another big area, right? Because let's say you can fix this. Well, I guess let's stick with describing problems. Other areas this comes into play. Networking. Every router, when doing routing computations

and communicating with other routers, uses time as a means of knowing when data is stale, when it needs to change something, when it needs to broadcast things, for all sorts of reasons. And so if the time magically jumps backwards 100 years or 70 years or whatever, that's going to cause all sorts of problems. Think of certificates for security. Think about bank withdrawals.

Yeah. I withdraw today $2,000 and it's, you know, January 18th, 2038. They haven't fixed their thing. Well, now they're going to have to go back to 1970 and figure out when I actually withdrew it. I mean, what exactly happened here? Time, never work on time. I think we've stated our position on that before, but this is one of those reasons. Yeah, I'm thinking of other embedded systems like medical devices.

Like, oh, there's a maintenance interval. Yeah. And now it says, well, does it start claiming it needs a maintenance when it doesn't? Does it never claim it because the bug is reverse calculation? So you don't need a maintenance for 70 years. If that kind of bug where it decides it never needs to do something, several classes of devices could just stop communicating because they don't need to.

They no longer need to send their heartbeats. It's negative a million years, yeah. And the real problem is there's so much based on Unix that people kind of aren't aware of. And especially with the Internet of Things, all these little stupid devices, well, not all of them, but many, many, many of in the last five years worth of Linux, or even ten years worth of Linux, somebody's going to have a lot of devices out there that are running older systems that don't have this addressed, and they may not be accessible.

They may not be able to... The company may not exist, or the support may not be there. There might not be a scalable way for them to update the firmware to fix this problem. And those will all just break. And they won't be able to communicate with anything because they will be saying, well, my time is this. And some might say, okay, well, that's still 18 years in the future. None of that stuff's going to be working. But there's probably going to be a lot of stuff that's still working.

I'm always shocked at how many things we have that are 18 years old and work. Yeah. there's probably going to be a lot of stuff that's still working. I'm always shocked at how many things we have that are 18 years old and work. Yeah. And they're still, they're internet devices. Some of them are teenagers. So that's the gist of the problem, is there's lots of just insidious things that may happen on all kinds of different devices and databases and systems that run the gamut of small tiny little internet of things devices to huge banking

databases and for firmware it's going to be tough to replace because the chances are you chose a signed 32-bit integer because you couldn't fit. That's what the library does. Well, that's what the library did. Or you can't fit larger. Well, yeah. And so how are you going to do that? How are you going to update it? Nobody's going to have the JTAG tools anymore.

Although I do still have one from about 20 years ago. Wow. Yeah, so there's going to be this, okay, let's hack the binary. Let's search for 1970 in the binary. Hack the binary. Make sure that where we changed it is the only place we need to change it. And that we're not changing some other bytecode to do something else. And then somehow load it back in. I mean, I expect to be well-employed because I know how

firmware updates work, but there are going to be people who don't, they won't have the code, they won't have the update methodology, they won't have the tools, and yet people will still expect things to work. You can't just, and I'm going to pick on Fitbit here, even though I know what their solution is. You can't just make my Fitbit not work anymore. Yeah. And you'd think, we've known about this for a long, long time. I remember talking about this in Y2K, right?

1999 and 98, that issue was coming up, which was a smaller issue. It was a much smaller issue. It was about displaying it to users. It wasn't about... To some extent. There was also... There were a few. ...dumb storage things, but it was a smaller issue.

And even that required Herculean effort that everybody just sort of ignores to make... Well, because not much happened. Exactly. Because of the Herculean effort, not because it wasn't going to happen. Years of COBOL developers getting good contracting rates to fix it. But we've known about this for a long time. And so someone might say, well, I mean, hasn't this been fixed for a number of years? And it's true. It has been fixed in a lot of places. But for one example, Linux, if you're on a 64-bit kernel, which most modern computers are, this is not a problem. It's been fixed. They replaced TimeT with 64 bits.

That'll be good until the heat death of the universe, or at least the solar system explodes, whatever. But Linux 5.6 was the first kernel to fix for 32-bit systems, and that came out in January. January? This year. 2020? Yeah.

So anything running on a 32-bit architecture before that kernel version quite possibly has this bug. And there's other examples. It's been in the last five years where some of the 32-bit architectures have been fixed. And that's stuff going forward, right? It's not like that's going to fix systems that are deployed that aren't updated.

And, I mean, that is still Linux. There's still a lot of 32-bit out there. Yeah. All these arms we're working on. Yep, yep, yep. And they all, you know, and everybody inherits the old time libraries and things. So, yeah, it'll be a lucrative time for us. Because there probably will be a five-year crash effort for as many things to get fixed as possible.

Yeah. Well, and we will have the NTP one in 2036 to look at. NTP keeps computers in sync. As much as telling them what time it is, it's making sure that my watch says the same as your watch and that nothing can happen in the interstitial period between them. But, you know, it'll happen. It'll be exciting.

Yeah. Since that's a protocol, I feel like there's different ways to attack that problem. Well, and that one does roll over to 1900, not to 1970 or 1970 minus 68. That'll be so much fun. Yeah, it'll be good. Future versions of NTP extended to 128 bits. 64 bits for the fractional second. That seems excessive.

As it says, the 64-bit value for the fraction is enough to resolve the amount of time it takes a photon to pass an electron. What? Yeah, at the speed of light. So that seems excessive. Okay.

All right. Well, that's exciting. So why did we use signed 32-bit integers for time? That's this Wii stuff. I mean, there's time T. It's a type in C. I didn't do it. There were two reasons I saw.

One was so you could go backwards in time and represent dates before 1970. Yes, because in 1970, you would want to be able to talk about 1969 and 1968. The other one was that early versions of C didn't have unsigned. Oh, that's exciting. And so once time T became a signed type. Part of the POSIX standard. The great thing about standards is they stick around. Everybody uses them. Everybody gets the disease.

Well, the chances of still doing the podcast in 2038 are remarkably small. That'll be a holographic podcast. It'll be a ha-ha-ha-ha- I don't think you want to go there. That wasn't going to work. I was going to say hobcast. Okay. Have we sufficiently attempted to describe what's going on there? Lee, if we didn't do a good job, let us know.

We'll find somebody else to talk to. Exactly. We'll find an expert. You recently asked about single file library files. Yes, yes, yes, yes. Yes. So we were on Slack and Chris asked somebody for this because he knew the other person had it. And the other person didn't answer right away.

So I went and looked and found it. And then he came into my office and told me about all of it. And I'm like, you should see who sends you Slack messages. It was funny. It was funny. It was funny. The reason I was looking is I'm doing my own little stupid personal project, which we'll talk about in a bit. But I remember at Fitbit, we needed some graphics routines.

I think we were bringing something up, and I wanted JPEG. Not for shipping, but just I wanted to load a JPEG on a prototype device so I could display some images that were straight from JPEG. I discovered or was told about this thing called STB, which is part of the link you sent me. And it's a bunch of single file libraries, for lack of a better term, that do stuff. So the STB one was all about things that people use in game

engines a lot, where you might need to do some graphics compression or decode something or simple little graphics things that people do often. Let me see if I can find it, because I'm a little worried that STB is not what it is.

STB is what it is. I looked it up. Resizing, true type font handling, AugVorbus decoding, and most of these are implemented in a single header file. So yes, it's bad to put code in your header files. We all know that.

But it's kind of cool that you just drop this header in your project and you get JPEG decoding. So if you're looking for something quick and dirty, these are really kind of great. They're licensed, very friendly. So I was looking particularly for bitmap decoding because I wanted to do some bitmaps.

But having found this again, I could just as easily use JPEGs, although they're longer to decode. And they're nice, they're configurable, they've got pound defines for stuff. So if you just want one particular file thing, you can say pound def JPEG, and it'll only include that code. And as far as I remember, most of them are pretty adaptable to embedded,

because if they use malloc, they allow you to switch out the allocator. So you can say instead of using malloc, here's just a big buffer that I've pre-allocated for you. So yeah, it's pretty cool. And STB was just one part of this big thing you sent me, which is on GitHub. Nothings is the name. Yeah, GitHub slash

nothings. Nothings slash single file libs. And it's a collection of hundreds. Hundreds. Amazing. Things that do things you want. There's one about profiling that implements profiling in basically in a header and you just put it in your code and then you link in how it does stuff. But it was super helpful because it's all the things you have to type in anyway. And with an MIT license, those aren't tough.

There are public domain and Apache licenses, so these are all pretty good for you to use. Although we are not lawyers, you should check with your own lawyers. A lot of them are C++, but some of them are C only. But just for example, there's 10 ARGV command line processing libraries, another 10 audio libraries, including a tiny MP3 decoder with neon support for ARM if you've got an ARM chip that has the SIMD instructions, compression, crypto, neural networks, data structures.

When I was looking at it, I was going, why do I do anything anymore? I just pieced together something from this geometry math. Huge numbers of things. So anyway. Unit testing. I was actually, the unit testing ones were the ones that I liked the best. So there's not only, you don't have to write code anymore, which isn't true. There's the, these are, some of them were readable. Yeah, They're great references. It's a really good way to not get lost in too much code.

I mean, if you're looking at something that is doing audio processing, and it's one file, you can make it through one file to look at how you can do compression or crypto or whatever. You can decode audio waves, and it's right there. It's not hooked in with anything else. So yeah, I thought it was really great. I looked it up and realized I'd seen some of these, but I had never seen a collection of them like this.

User interface, there's a bunch of stuff for doing command line interfaces with terminal edit, you know, line editing and history, vectors, video. So yeah, it's pretty cool. I don't know that they're all the greatest quality. Some of them are... Or that they're super fast.

Definitely better than others. But if you're just putting something together in a hurry, or you want just a little piece of code for an embedded project, which is where I'm at, I'm like, the one I'm actually particularly interested in for the little embedded project I'm doing is this Knock Turtle, which is basically a little logo render language thing that they abused the heck out of the preprocessor to make.

But it allows you to have logo-style drawing. You know, remember the turtle? Yeah, I remember the turtle. It drives around. We're super old. They had the turtle. Yeah, so I was going to play with that because that seemed like something I could drop

on my STM32 because there's just one function you fill in to draw a polygon. And once you implement that, the rest of it just works. So, yeah, thank you for that. I was amused to see that many of them have tests. So people who are like, well, how do I do test-driven development? Well, maybe you look at some of these,

because it was nice to see tests being part of the systems. I guess that's the fancy new thing that's happening. So tell us about the thing you are working on. I'm working on, who knows what it is. It's a MIDI thingy. It's a MIDI thingy. And we're going to talk about it a little bit next week, too. So I'm going to try not to necessarily talk about the same things I talked about then.

But what I have is an STM32 Nucleo dev board. And it's one of the M4s with, I think I have 64K RAM, something like that, and 512K of flash. And it's got a usual collection of peripherals. And I've hooked up serial MIDI to it, so not USB MIDI. And I have a display. And I have an I2S codec. And there's something else. There's some buttons.

SD card. SD card. And some buttons and switches and things. And so I'm just kind of experimenting the goal was to since i haven't really done a embedded project from the very start on a board like this i've usually either come into companies where we've pieced something together with a different architecture like x86 architecture still embedded but um a little different kind of approach you know i'm dealing PCI instead of SPI so much.

And I have brought up peripherals and things, but I've never taken a chip and brought code from Xero and seen how that all goes. So I'm trying to do that just so I get some experience with it. I haven't done much C in the last year, so again, trying to keep my skills fresh on things. So just bringing up the peripherals and bringing up the development environment,

playing around with STM's IDE, which they bought from Italic. I think they call it STM32, or STM32 Cube IDE is what it's called, which is a great name. But that integrates the Cube MX stuff right in the IDE, which is Eclipse-based.

It's all right. It's a little slow. It's kicking and screaming. It does everything you want. It's just kind of clunky. Not clunky. Janky? Janky. It's fine. I haven't left it, so it's

fine enough. So my goal with this was to bring those things up, write some code to do something amusing with MIDI and sound and display. And so my first plan is to just make an arpeggiator kind of thing where you hold down a chord and it plays the individual notes from the chord at a certain rate out the output MIDI to the synthesizer or whatever you're driving. And then maybe interprets what's being played and puts something different on the screen.

Happy Cat, when it's happy chords. Happy Cat, some visualization, you know, just some fun stuff like that. But then once you get that far, there's a lot you can do with MIDI to transform things. You could transpose things. You could make a fake delay thing. I talked about the arpeggiator um make a sequencer i mean there's tons of things you can do because you're taking this note data

in and you can transform it in lots of ways and send it out um so that that's sort of amusing and then i have the i2s audio thing on there so i could make a small simple wavetable or other digital synthesizer out of all this too. And I've got the SD card, so I can load images off or load samples and things. So that is what I'm doing. There's no real, this is a product I'm making and here's what it's going to do. It's more like, yeah, let's just do a bunch of things and just have this kind of playground, which the excuse is this is getting me exposed to STM32 HAL, Qube, things that I have seen people talk about, but I've never experienced because every time I've done STM32 or Cortex-M3 stuff, it's all been totally from kind of scratch or with IAR at a minimum or maximum, which is kind of a different experience.

IAR, you know, you get a certain set of libraries, but a lot of the things you do to get peripherals working are more raw and low-level, whereas with HAL, it's like, okay, this is pretty easy to get running, and now the questions I'm having are, is this where I want to stay? Because while I was talking to you about the one issue I was having with MIDI, doing that over serial with the UART, architecturally, how do you want to deal with data coming in at a high rate

and then reading it and then taking some action based on it. And usually you want to have a circular buffer and you take data in on an interrupt and you handle it the higher layers. With HAL, it's doing things at interrupt levels a little weird because they try to make things very easy for you, but in doing so... They sometimes make the interrupt slow. They either make it slow or make it very difficult to do kind of standard stuff. So the way it works normally is you write an interrupt handler, you connect it to your peripheral interrupt, you get that, you gather the data and put it on a buffer and set a flag for the higher level to look at.

With HAL, they give you a function to transmit or receive with interrupt. And so you get a callback. It's not really your interrupt service routine. They have a big interrupt service routine that they've made that calls your callback at the end of the stuff they do. And the stuff they do is to clear the cause register and all the standard things. But what ended up happening for me with doing it their way is at high rate, sometimes something would forget to reset the interrupt flag, so I wouldn't get it ever again. So I had to put a hack in there to kind of almost,

I don't remember if I had to check, if I went and checked, or if I just reissued the receive call another time in a different loop. But it was kind of hacky and it didn't feel good. And I had done some research and there's other ways to do it. There's another library that ST provides called the low-level library, which is kind of one below HAL where you get more direct access to things. And that's probably what I should move to for that particular peripheral. And HAL and LL can coexist, but...

Yeah. It's... It's frustrating because they give you a lot, but then is it what I want? It's kind of like the Arduino thing, except one level away from it. It's like...

I'd say three levels. Three levels away. But it's like you can do a lot, and it's real. It's real embedded. But maybe you're doing too much, or maybe it doesn't quite line up with how you envisioned organizing your software, and so you end up tweaking your software to kind of conform to it in a way that's maybe not optimal.

Compromises. Yeah. It's a trade-off, right, like you said. And the speed of development might be worth it. But, you know, I'm experiencing the joys of bringing stuff up. And I'll talk more next week about the display issue I had. But, you know, some things are really hard. And even if you've done it a million times,

and I've brought up many displays in my career, they're always a pain in the neck. This one was a pain in the neck, too. You could be using more code. We're kind of excited about this single file library. Oh, stealing more stuff? I don't think it's stealing if it's free. Borrowing? Licensing?

If the licensing is liberal, and you're using it only for yourself anyway. I referenced the Adafruit library for the display controller. Because that turned out to be quite complicated. But you're not using their graphics library. You looked at it, but you're not using it. I'm using pieces I might want. But that does more stuff than I need. I don't necessarily want font handling.

So, yeah. But, you know, I haven't really done a personal project like this in a while. The last one I did, I think, was on embed doing a Kerbal controller, which was kind of a different experience. That turned out to be a mechanical project and frustrating because it was so mechanical. Yeah. Yeah. And didn't have a good way to put buttons in a box project and frustrating because it was so mechanical. Yeah, yeah. And didn't have a good way to put buttons in a box and things, make it look nice. I probably should revisit that, but... Yeah, so I'm not really looking for help or suggestions or anything.

Part of the reason to do this was to dive back in and suffer the way I would with a client to kind of do the things I would do for a client who said, I want a MIDI thing. Let's bring this up and see what it looks like. Which is why you're exploring the low level and the how. And using their IDE because... That's what we would do with clients is to let them... For a client, I wouldn't say, yeah, no, we really should just do bare GDB and GCC from the start because you've got, you know, a couple of months for us to bring

that up. That's just not what people, and for clients, I mean, if we're a big company, that makes sense, especially for, you know, you're going to have a big team that's iterating for years. For small startups, oftentimes they won't have the depth of expertise after you go. So having a simple IDE and things like that that is widely used and has nice features is better for them. The one thing I'm finding about HAL, though, is documentation is not really existent, which is weird. It's this big library that's supposed to make things easier to use.

And most of what I'm finding is the header files, which is decent. They actually have decent documentation for all the functions. And there's examples out there, but it's not... Maybe I'm missing something, but I'm not finding kind of a classical... Here's how Spy works in hell. You're nodding, but not agreeing. Oh, well, no. I mean, I haven't looked much. Their header files are

the way to go. I can't say, oh no, here, look at this web page instead. No, it's usually the header files. And then reading the code because the header files left something out or wasn't quite clear enough. Let's see. And I have started a personal project that I'm not sure where it's going.

It has to do with a future guest. But I have started looking at TinyML, which is the microcontroller machine learning thingy-bob from TensorFlow. It's TensorFlow Lite. And I don't know if I buy this machine learning in microcontrollers. And so I sat down and I thought about, well, what would convince me? And I came up with the idea that PID controllers are something I've used a lot in a lot of different ways. And it is sometimes hard to explain to people how to tune a PID controller. It's not impossible, and if you're patient, you can do it,

especially if you treat it as a science experiment. But it's one of those things people get frustrated by. How does PID and tiny amount compare? Are we talking about if I have a differential equation I'm trying to solve using a PID controller, a system or plant that is governed by a DE, I can usually get that with a PID if I have the right inputs and stuff. The differential equation? Yeah. Thank you. Can I do that with machine learning? And what kind of machine learning?

And how much do I have to fuss with it by hand? With PID loops, you can do it mathematically. You can do it with trial and error. You can do it using one of the patterns. With machine learning, it isn't entirely a black box, and it works sometimes, but then sometimes it just goes nuts, and you can't debug it, because you can debug a PID loop. And so I was trying to figure out how to formulate a test that I could use to convince myself, well, if you don't want to learn about an application, you just want to throw machine learning at it, what kind of processing and RAM hit are you

looking at taking? So you don't want to do a deep dive into how does a motor work? You're just going to throw machine learning at the problem instead. What are you giving away in order to increase your productivity that way? And are you increasing your productivity? Now, I know doing this for the first time, I'm not going to be increasing my productivity because I can tune a PID. But in theory, what would I be doing? Unfortunately, I thought about all this. I thought, you know, I'd sometimes just think and think myself into circles. But I ended up with a blank page problem.

Like I know what I want to do. And I found a couple of simulators, but like so much with ML, I just sat down and I could draw the neural net. I could figure out the data, but then there was some gap. And so that's what I'm working on. I'm working on that.

And I think I will solve it. I think I know how to go, how to find the resources to give me a methodology to get through this. But I figured I wanted to mention it so people can start thinking about it since we will have a show about it. Ooh, that may not be for a couple months. Yeah, it's rare in ML that people start from the blank page, right?

And say, okay, I want to solve this problem. I'm going to, what network from scratch might I develop? I mean, usually it's a video or an image problem and somebody grabs one of the standard convolutional neural networks, right? Or it's this kind of problem, I'll use what other people are. There's very little kind of developing

the network architecture. I mean, you might tweak it, but is that the kind of problem that you're finding? What network do I throw at this? No. Okay. I mean, there is a little bit of that, but I think I either want a deep neural network with two hidden layers or I want a recurrent neural network with a little bit of history. And I think input-wise, I am going to try just having the set point and previous process value go in, but I don't think that will work.

With recurrent neural networks, that should work because recurrent neural networks have some memory, so they should be able to sort out differentiation and integration by themselves. Maybe? Maybe? I don't know. But I also think maybe I will put in the error signal and maybe the last 15 of the error signal so that it doesn't have to do integration and differentiation as a black box, and I might even do a machine learning version that has the error signal, the integral signal, and the derivative signal on the idea that it should, by gosh, figure out the PID at that point. Part of what this is going to do is invent PID, right?

The network has got to learn that that this is going to do is invent PID, right? The network has got to learn that that's the thing to do, to some extent. It doesn't have... there are other solutions to control theory. Right, but it's going to learn itself some control method. Yes. And if I feed in the error integral and derivative signals, then I would expect it to get a PID. But if I feed in history or I use one of the memory, one of the neural nets that has a memory,

those should sort themselves out. And it may be a totally different method. And just like the image neural networks, if you interrogate them, you see layers that learned to do edge detection. You didn't tell them to do edge detection. So the same thing you want to have happen. I'm going to give you things. I'm going to give you what the output should be,

and most likely it'll learn to be a PID loop. I'm not counting on that. Or something. But it'll be a control system. I don't know that I'll be able to interrogate the hidden layers. Yeah, that'll be harder with this because you can't really look at them. I don't think it will be visualizable. Although I did think about using a CNN and making the error and input signal and desired output signal be colors and having the image be history, basically.

Yeah. But that just seemed like I was really trying to push something that maybe I shouldn't. And you want this all to run on a little micro, so that's... Well, that's not going to... Right now, I just want the exploration. Right. If I could get to, here's how many nodes, taps, weights. Weights.

Parameters. Parameters I would need to solve this problem, and here's how long it would take to run, that would be a first order solution for me. The tiny ML I'm using because it can go on microcontrollers, so I can go to the next level. Right. But right now I'm just exploring.

Cool. Okay. And then the other thing that I'm actually not working on, but I feel like I should explain because we're going to have a show soon where we will be talking about it, but I think we'll be talking about other things using it. All right, this is already confusing. This is background for a future show. Okay, I've mentioned curved crease origami. This is where you pre-crease something with a curve, and then an embossing tool can be used to press down on the paper.

You score it somehow without perforating it. And you make Cs all around your paper so that they go from the center to the edge. And then you fold them mountains and valleys, ups and downs, and you end up with a spiral. There are patterns out there. You can search for them and I'll put a couple of links in. But it's a neat thing because it's definitely paper folding that doesn't look like any paper folding you would see otherwise. And last spring we had Ariel Waldman on. She was headed off to Antarctica to take pictures of tardigrades. It was pretty cool. But she mentioned NIAC.

Wow, I should have looked this up nasa something something this is synthesizer it's not my voice nasa innovative advanced concepts program which the idea is they nurture visionary ideas. And I wanted to apply not with the expectation of winning, but with the idea of there are some NASA programs out there I think I could participate in that would be very interesting. And so I wanted to understand the process. Okay. Things that can travel to Mars as a flat pack and can be repurposed to be a sensor system.

And the reason the curved creases are important is because they are structurally more solid than a flat crease. Once you get it curved into the crease, it's actually a little hard to press it down. It's harder than it would be if it was a regular crease. And because of my background with sensor arrays, I understand how precise they need to be in order to build like a four-up array in order to get acoustic information or maybe on Mars it would be seismic information or wind information. And you put these in an array that's maybe a foot or two across and you can see the gradient of how these things are changing.

And if you did this with metal, it would be pretty expensive, but it could be very precise. If you did this with a light material and you were doing plastics, you might not be as precise and you might not be as stable. And so I was wondering if I could do something with a plastic that could be both stable and precise using the carved crisp origami and maybe even using flex circuits and making this all one thing. So I wrote that up and I started to put it together and started to enter it. And then I had problems with the, you have to sign up. And before you sign, before you enter your idea, you have to sign up to get government payments, you have to, I don't know, sell your dog and buy ice water from people on an island that nobody's ever been to.

It got really complicated. It was a quest from an 80s RPG or something? It was totally a quest from an 80s RPG. And I ran out of time before my idea could be submitted. And that was fine. But I got to talking to the NIAC people. And we're going to have one of them on the show soon. And kind of take apart my idea as far as what's good about it, what's bad about it.

One of the things that's bad about it is it turns out it's a very mechanical problem. And I'm a software engineer. And my skills are in tiny embedded systems. I have some weird skills in machine learning and embedded systems. And I like to ship things. None of these actually have to do with curved cruiser origami, other than I like it. There are lots of people out there who are far more knowledgeable about it than I am. And anybody who has a mechanical background would do much better at this idea than I can. Anybody who has a mechanical background would do much better at this idea than I can.

Anybody who has a mechanical and space background, again, just so. But we'll talk about the whole proposal process and the whole government grant kind of thing, maybe? Yeah. And we'll talk about... Not just tearing apart your proposal. Yeah. My proposal will just be the example. and that's why i don't think we'll go into it that much we'll just kind of talk about i did a one-page thing and i did a well anyway we'll talk about it then but there's a lot of stuff like this out there and if people

have projects in mind it's it's a route to develop them and get compensation. Because it's not always you have to complete something immediately. It's kind of researchy, right? So there's many prototype stages and you get, not to go into the whole detail, but you get some grant for one phase and then maybe you don't proceed past that or maybe you do and then you get another grant for the second phase. Something that I think a lot of people probably aren't aware exists. Yeah, and it's a little US-centric, but I think some other governments do it, and it's worth understanding that sometimes the rules are on the page just to make sure you can follow the rules.

Yes. And we watch out for that rule 15, ignore rule one and two. Yes. Okay. I have one more thing on our list. Do you want to discuss it? It's a little preliminary, but I guess we can discuss it and see if we get a lot of feedback. Okay. So, dear listeners, we are thinking about selling out. Are you excited? I'm excited. Selling out. Uh, we're thinking about taking ads. And we'll try to make it tasteful. We'll plan on reading the ad copy ourselves.

And there'll be music to indicate when the ad is going on so you can tell. It'll probably be one spot per episode and maybe a minute length, something around there. No more than a total minute for a whole episode, though, I think is what we'll shoot for. Okay. I hadn't gotten that far, but okay. Yeah. Might go a little over, but we're not going to inundate you with four interruptions per episode is what I'm trying to say. And it will be stuff that, I don't know if we're endorsing it, but it will at least not be stuff we, it's not going to be mattresses and underwear. We will have researched it enough to be confident that it's something positive and not you know mattresses and underwear.

There's positive mattresses and underwear out there. But you know, we may not have necessarily used the thing or whatever it is in our professional or personal lives extensively. But we've done enough research to say, yes, this is fine for us to have on the show.

Does that make sense? It works for me. If you want to know about ads, you can email me. I will warn you now, they will probably be pretty expensive just because our listeners are awesome and to sell the ad time means that we are giving up some of our time with our listeners okay so the reason we're doing this we are not quite working full amounts, but that is mostly through choice and through planning because we are going to be busy very soon.

It is a piece of our work. Oh, this definitely is a piece of our work. Oh, definitely. It's sometimes exhausting. But for a long time, I thought we would quit before we did ads. And, you know, we may do one and then decide it doesn't work for us. It's just, the opportunity is there. It's hard to turn down.

We've had a lot of people ask over the last year. And why not? Let's at least try it. And if it means that we can, I don't know, I was so excited to be able to donate money to Digital Nest and have the community support that too. If it means we can do a little bit more of that or whatever. I mean, if people are willing to pay us, I feel like we should stop saying no.

I know that's weird, but... Yeah. So if you have feedback about that, feel free to contact us. I'm not saying we'll necessarily take action on any of it, but it's good to hear what people think. And if the overwhelming response is, no, no, well, then we'll consider that too. But so far, the overwhelming response has been fine.

All right. Well, I think that is it for the show. Thank you for listening. You can contact us at show at embedded.fm or you can hit the contact link on embedded.fm. Thank you to Christopher for producing and co-hosting the show. Thank you to Christopher for producing and co-hosting the show. Thank you to patrons for supporting the show for no reason other than they like it. And we are keeping our patron account and we really do enjoy talking to our patrons.

We have a big bunch of stickers to send. We do. We do. Speaking of holographic. Alright, so now let's get to some Winnie the Pooh. One fine winter's day, when Piglet was brushing away the snow in front of his house, he happened to look up, and there was Winnie the Pooh.

Pooh was walking around and around in a circle, thinking something else, and when Piglet called to him, he just went on walking. Hello, said Piglet. What are you doing? Hunting, said Pooh. Hunting what? Tracking something, said Winnie the Pooh very mysteriously. Tracking what? said Piglet, coming closer.

That's just what I ask myself. I ask myself what? said Piglet, coming closer. That's just what I ask myself. I ask myself what? What do you think you'll answer? I shall have to wait until I catch up with it, said Winnie the Pooh. Now look there, he pointed to the ground in front of him. What do you see there? Tracks, said Piglet. Paw marks. He gave a little squeak of excitement. Oh, Pooh, do you think it's a, a, a woozle? It may be, said Pooh. Sometimes it is,

and sometimes it isn't. You can never tell with paw marks. With these few words, he went on tracking, and Piglet, after watching him for a minute or two, ran after him. Embedded is an independently produced radio show that focuses on the many aspects of engineering. It is a production of Logical Elegance, an embedded software consulting company in California. If there are advertisements in the show, we did not put them there and do not receive money from them.

At this time, our sponsors are Logical Elegance and listeners like you.