Embedded - 304: ADC Channel Six

Episode Date: September 26, 2019

What do you get when you connect the open-source reverse engineer of Valve’s Steam Controller and the main electrical engineer of said device? Jeff Keyzer (@mightyohm) and Gregory Gluszek (@greggersaurus) join us to talk about building and taking apart devices. Greg’s project is on github as the OpenSteamController. He used pinkySim, an ARM simulator. Jeff has left Valve and is now a freelance engineer as well as selling kits on mightyohm.com. The incredibly useful comic on how to solder lives there: mightyohm.com/soldercomic I-Opener was the computer discussed.

Welcome to Embedded. I am Eliseo White. I'm here with Christopher White. We have two guests this week for a bit of a different show. First, let's talk to Gregory Gwuszek. Hey, Greg. Hello. Could you tell us about yourself? So I'm an embedded software and FPGA engineer. A lot of my work these days is targeted at SOC FPGAs, so FPGAs that have hard processors embedded into the fabric. And I do anything from writing VHDL or high-level synthesis targeted at the FPGA fabric to CC++ running on the hard processors. I also liked experiment in makerspaces and sometimes reverse engineer things in my free time.

And you have a reverse engineering open source project that you sent me an email and I looked at and I got kind of excited. Could you give us a brief overview? Sure. So I call it the OpenSteamController project project so it's related to a piece of hardware designed by valve called the steam controller which i made this mistake before so i'll do a quick you know intro of what that is it's a video game controller similar to a playstation or an xbox controller but there were different design decisions made so that it would interface better with pc games especially pc games that weren't originally designed to work with a handheld controller like that.

So the project came about because I thought this was a really interesting piece of hardware and I wanted to see kind of what I could maybe add to the functionality or understand how the hardware and software worked. And then I decided to put it up online, open source, kind of in the hopes that it would inspire or maybe motivate other people to think about how these devices work or what they could do with them. So, yeah, that's the project. I did mention we have another guest.

I would like to welcome back Jeff Kaiser, formerly of Valve, who, well, Jeff, maybe you should tell us about yourself. Well, hello. Yeah, I'm Jeff Kaiser, formerly of Valve, who, well, Jeff, maybe you should tell us about yourself. Well, hello. Yeah, I'm Jeff Kaiser. I'm an electrical engineer. I've been practicing engineering for about 17 years now. I've designed RF integrated circuits for wireless networks and cell phones. I've designed vehicle mounted electronics for street level mapping systems. And I've also designed consumer electronics hardware for gaming. In 2008, I founded a company called Mighty Ohm. That was right around the time that social media was becoming a thing, and so I've been Mighty Ohm on Twitter since around the same time. And around that time, I started doing freelance electronics design work and also started making open-source hobby electronics kits,

including probably most significantly an open-source Geiger counter kit. I've also co-authored a comic book called Soldering is Easy. Which is great. Thank you very much. With Mitch Altman and Andy Nordgren, that's been used to teach people how to solder all over the world. And last time I checked, it had been translated into, I think, 21 other languages. And you had a role with the steam controller while you were at Valve, didn't you? Yeah, I did. I was essentially the hardware architect and the lead, and for a lot of the

program, the only electrical engineer on that project. So I'm pretty intimately familiar with it. So you guys talk amongst yourselves and let us know when you're done, and we'll hit the stop button. Actually, before we do that, which is pretty much my plan, I want to make sure we don't get Jeff into trouble. He doesn't work for Valve any longer. He's not speaking with them. He's not affiliated with them. None of this is intended to give away Valve secrets.

Yeah. And obviously, yeah, I haven't been a full-time employee of Valve since 2017. I've worked there as a contractor since then. But I should also say that a lot of what we're talking about is sort of a long time ago, especially in the consumer electronics industry, because the controller was released in late 2015. So I haven't worked on anything. A long time ago. Sorry. Well, if you think about it, consumer electronics moves pretty fast. We're not building enterprise servers or something like that. So I'll have to be totally honest. I had to do a little bit of head scratching because the details in some areas are a little fuzzy. And then obviously there's IP that I can't talk about because it belongs to Valve.

But I still thought that this was a really cool idea for a show, and I'm super happy to be here. Cool. Okay, so I have one question that has come up on Reddit a number of times. The X slash cross button, the thing that, what is it really supposed to be called? So I think the discussion recently has been that it is the fork button. If you ask the PlayStation folks, which I hadn't heard. I'll be totally honest. I'm not a hardcore gamer. I'm like a super casual gamer. And I had never heard the word fork

used to describe that button before. Greg, what do you call it? I call it the X button. I had also, until I, you know, you had mentioned that I had never heard that before. So maybe I'm not as hardcore of a gamer as I thought I was. Yeah, I think it's the X button. All right.

So let's get to the cool parts of this, where we have the reverse engineering of the Steam controller and the engineering of the Steam controller. What would you like to fight about? I mean mean you're going to be in this rank you're gonna uh greg what was the most interesting thing you came across as you were doing the reverse engineering what what was interesting what was the cool part so the cool part i think the cool so i'm going to try not to be too long winded here, but there's a little bit of a story to get to the cool part, if that's all right. OK. So kind of my initial, I guess maybe the true aspect of what inspired me to try to do something different with this controller is that when you first plug it in, you start it up. It plays a little song, a little jingle, and it does this using the haptics that are part of

the trackpads, which are some of your input interfaces on the controller. And, you know, completely superfluous to the way you would normally use the controller in a gaming scenario. But I thought it was pretty neat and I wanted to customize it. So by default, you can go into Steam and you can select one of, I think, 14 predefined songs. But what kind of inspired me was, hey, can I make this do more than that? Can I make, you know, completely customize what those songs are? And, you know, this started what turned out to be a kind of a two and a year, two and a half year effort for me.

And towards the end of that, I got to a point where I realized, like essentially this jingle data, as I called it, either lives in the firmware kind of it's been, you know, hard coded into there, or it lives in the EEPROM that's associated with the main processor on the controller. And kind of through the reverse engineering, I found out that there's actually a section in EEPROM where you can put your own jingle data. So it was kind of like someone had left there exactly the functionality that I needed, but it wasn't supported by Steam or any of the higher level software. So it was really neat to find that. And then kind of, it was very gratifying to realize that like, I understood all of this, I could throw, you know, custom made jingle data into that EEPROM, then reload up Valve's official firmware, and it was playing my custom songs while everything else was the same.

Jeff, why were there only 14 songs allowed? The funny thing about the jingles is that as a hardware designer, I remember a moment when I was working with the design team and the idea for jingles came up. And as the hardware guy, I remember being terrified that the jingles were not something that the hardware had been designed for originally. It was sort of the idea that you could produce sound with the haptics was kind of a novel and interesting idea. And it wasn't something that I'd come up with myself. It was obvious that they made noise, but the idea that you could produce decent-sounding audio with them was something that I can't claim was my invention at all. And I remember thinking, oh my gosh, I don't know if the electronics can handle this, because this is way outside the scope

of what I'd been considering when I designed this stuff. But it turned out that it actually worked really well. So why are there 14? I don't know. I guess we just didn't know 15 to program in there. But that was a feature that came pretty late in the development compared to a lot of other things. Greg, what were the most useful pieces in understanding and modifying the steam controller programming? Was it more about the hardware or the software? I mean, it was a I guess I could say it was equally about both. Like you can't write the software without knowing a little bit about the hardware. I kind of approached this project in a way I would approach my normal

work where normally, you know, a hardware designer gives me a piece of hardware and says, Hey, here, go get this working. Uh, the big difference here is that I didn't have a schematic to work off of. So I didn't necessarily know, you know, I could write a simple program that runs on the processor, but how do I know which GPIO has the led connected to it so I can get my hello world running um so yeah i'd say it was it was both um i needed to know where peripherals were and how to interface with them how to get the thing to start up um how were the test points did you find figuring out the gpios and the connections relatively straightforward or did you have to do a lot of mucking about with chips most of what i did the way i found that out was I spent a lot of time taking

the essentially raw binary of the official firmware and simulating that, and then seeing what it was doing. And so I use that to see, okay, why is it talking to this GPIO, and then writing software to kind of watch and see what it did. I did do a little bit of oming out with a multimeter to kind of see, okay, does this pin connect over to, you know, this switch? But the majority of the way I got that data was kind of seeing what the official firmware did. What tools did you use in this process? So I used a and this is this was my first attempt at really reverse engineering something. So please don't take me as an expert on this. I used a tool or there was a simulation library called pinky sim, I found it up on what was it called on GitHub. I think the whole pinky

part is because it supports thumb architecture in the arm. But it simulated essentially the correct arm ISA that I needed. And it interfaced with GDB, which I use GDB at work quite a bit. And I know how to use that debugger. And then I just kind of took that open source project and started building in my own logging into it and kind of develop that more and more. So I could see, okay, I ran a simulation now, what were the instructions that ran and then even more complex, let me encode that so it looks a little bit more like functions, and I can start building up this map of what the software is. I don't know that that was the best approach. I think if I were to do another reverse engineering project, I would spend some more time using what I've found to be more common tools in the reverse engineering world. Like I know there's something

called, I think it's pronounced Radar A or it's Radar 2. But I also know it's really complex to use. So that was kind of how I went down the path of doing something that was a little more home-rolled. Jeff, what test points should Greg have used? Test points are interesting. I think that if you look at the design, you'll see there's kind of a mishmash of test points. And we use test points a lot during development. And so I'd say probably a third to a half of the test points that are there are test points that we added because we wanted to look at specific nets during development and testing and debugging, the rest of the test points were really driven by the needs of manufacturing, just needing to have functional test coverage for everything that was on the board. And like a lot

of things, it sort of grew organically over time. And it's funny, you know, I sometimes take apart products and I try to figure out, you know, how they work and also sometimes what people were thinking, like what the designers were thinking when they decided to make certain decisions on the board. And I think, you know, the answer, at least on products that I've worked on, is that a lot of it sort of grows slowly over time. And so if you look at the finished result, it might look kind of weird because you're seeing, you know, at least a year or more of work that's all sort of baked into a single thing. But we tried to put test points in the places that would make our lives easy as designers, you know, as the team working on it, we needed to get access to stuff

because we were interested in characterizing, or we were trying to debug specific issues. And so first and foremost, it was sort of what we needed. And then when manufacturing came along, there was a bunch of other stuff that got added pretty late in the game. And that probably wasn't added as carefully as some of the stuff early on. Greg, as Jeff says that there were development test points, you didn't look at them because your I did notice some nets that seemed to be almost related to, you know, maybe a place where you could hook up a JTAG pod. Um, that seemed very tempting. I think I avoided a lot of those because I would have needed to modify the hardware either, you know, tack on wires and whatnot. And I'm paranoid about breaking hardware. So I took maybe a more difficult approach trying to make it mostly software. But that was kind of my maybe not so great reasoning there. How many Steam controllers did you break? Any? I didn't break any. I have two. One of them is fairly banged up as far as, you know, I'm trying to probe these pins and figure out what, you know, I'm trying to probe these pins and figure out what,

you know, switches they go to. And every once in a while, you, you know, just rake the probe across a whole bunch of pins. So it's a little bit banged up, and I've taken it apart, put it back together a couple times, but I was very fortunate that I didn't actually break any hardware. Are there any questions you wish you could have asked Jeff as you were doing the development? little bit of a desire to figure everything out on my own. And so there was kind of a, maybe a little bit of a fear, maybe unfounded that if I got help, it would take away from the things I actually did manage to accomplish. And there's also kind of the learning process of learning how to struggle with something on your own, even if there's maybe a more expedient way to head down that path.

That makes sense. Well, thanks for having me on the show, guys. That doesn't mean I don't have questions for Jeff, don't get me wrong, but they're more after the fact questions than they are that I wish I had someone helping me through the process. Okay, what are the questions? I want to hear these. Yeah, okay. So the first question I had, and I know, Jeff, you mentioned that, you know, clearly you haven't worked with this hardware in a little Okay. So the first question I had, and I know, Jeff, you mentioned that, you know, clearly you haven't worked with this hardware in a little while, so maybe it's going to be a little too specific. But as I kind of mentioned before, I was very concerned with ruining hardware, either through some mistake I would have made in the physical world or most or a mistake I would have made in the software world. So, you know, I'm trying to load software I've built onto this product without knowing much about it. Are there things that were kind of obvious they were, I really could have,

you know, screwed it up and say bricked a board or, you know, broken it. Ooh, I think that they, that the controllers are fairly unbreakable. And that was actually a design goal when we started the project, because we wanted to ensure that if we shipped hardware out into the world, that if folks were, say, doing like firmware upgrades, that it would be really, really hard to make the hardware brickable. And so the inclusion of the bootloader you know everybody knows about the hold the trigger button and then it goes into mass storage mode so that you can replace the firmware that's on the microcontroller that is a feature that we purposely left in the controller because

a we wanted access to that so that it would ease our development so that we could just use the usb connection to upload firmware but also that's something that's actually in ROM. And so it's very, very difficult to make that not work. And so that was a feature that we specifically targeted at, at making it much harder to brick controllers, the radio actually runs its own firmware. So there's sort of a tag team of microcontrollers and the controller, the main microcontroller is running kind of main application code, and then the radio is running radio firmware. And there's a bit of blurring between those. But I remember being quite concerned about bricking the radio because it doesn't have that same sort of backdoor that the main microcontroller does. But we actually added features pretty late in the development to be able to rescue the radio if it got into a bad state. So I think probably the most likely thing is that that would break, you know, because something went wrong on one side or the other of that link, and then you would end up bricking the radio. And to actually save that,

you need a programmer, you actually have to make physical the radio. And to actually save that, you need a programmer. You actually have to make physical connection to the board to be able to rescue the radio. But I think there's relatively little. The haptics are an area where you could potentially, like if you left the haptics on all the time or you sent like a very weird waveform to the haptics, you could potentially break stuff. Like a song. Yeah, that was initially my concern. So I feel like there might be some edge cases there where the haptics might not survive certain types of abuse. But other than that, it's pretty foolproof, I think.

Okay. There's actually one more kind of specific area, and this is me, you know, interpreting, you know, simulated software. So I may have been understanding the way this was running, or maybe, you know, the software designer was putting something in there that wasn't, uh, you know, related to kind of not ruining the hardware, but there's a specific sequence when the system starts up where kind of a GPO needs to be driven to make the system run. And it seems that the way that GPO is driven is based on a number of different things. So one of them might

be whether USB power is plugged in, and then the other seems to be checking this like, brownout detection bit. So I don't know, like that, I think when I saw that code, that made me paranoid, because it was a little bit like, okay, is there a way I don't understand power systems like this, especially without having any reference material? Could I be doing something that's, you know, going to cause like a battery to blow up or, you know, the chip to brownout? So that's, that's something that, that I definitely designed for to prevent that. So that the controller, I don't know how many folks are familiar with the controller, but it's got two potential sources of power. It has USB power, so you can plug it into a PC and it will happily run off USB indefinitely. Or there's a pair of AA batteries that are in the controller. And I'll say that after having worked with AAs, AA development is much harder than lithium development at this stage, because most of the guys that are making chips and semiconductors for battery management, they don't really care or they don't seem to care about AA design

very much. They're not really thinking about the voltage levels that are associated with like alkaline batteries. And so if you look at lithium battery management circuits, there's a lot of them out there. Every major semiconductor vendor is making chips that work with lithium batteries. And I think that's primarily driven by the cell phone world. And also the fact that there's just lots of products that have lithium batteries in them at this point. But it seems like AA's and alkaline cells have sort of been left by the wayside in this huge wave of lithium development. And so designing a product around AA's and being able to work on regular alkaline cells was actually much more challenging

because we had to sort of roll our own battery management circuits. And so a lot of that complexity that you're seeing is really driven by the fact that we had to sort of build a lot of the battery management stuff from scratch. And batteries are hard, especially alkaline batteries are hard because their internal resistance changes very dramatically as a function of the state of charge. And so a lot of that brownout detection stuff and a lot of the complexity is A, because the controller needs to know if it's running on battery power. And if it is, it needs to do things to connect the batteries to its power rail and do exactly

what I think you alluded to, which is you don't ever want to have a situation where you accidentally charge the batteries through USB or some other power source. And so there's actually some switches that are in hardware that ensure that that can never happen. And that's actually a safety requirement. When you ship a product, if you work with a standards body that cares about safety, and all products going into Europe, for example, need to be CE marked. And as part of CE marking, you need to pass a safety standard. That safety standard will typically have things about batteries.

And if you're using what's called a primary cell, which is not a rechargeable battery, then you're not allowed to charge non-rechargeable batteries. And if you're using what's called a primary cell, which is not a rechargeable battery, then you're not allowed to charge non-rechargeable batteries. And they actually require you to show schematics to a reviewer, and they have to take a look at them, and they may have comments. And there's actually some little changes in the schematics that were driven by regulatory requirements to make sure that the design was safe. But that software stuff is mainly about extending battery life and how you figure out when the batteries are quote-unquote dead, which is actually a very, very difficult thing for AA's, for alkalines. It's, I think, much easier for lithium. But because alkalines have such a changing series resistance and such a changing open terminal voltage as a function of charge, it's non-trivial to figure out when they are

dead. And so there was actually quite a lot of work that went into that. And I think one of the things I'm most proud about about the steam controller design is that the battery life is really, really, really good. And it's even better than I think I had possibly hoped for during design. I designed a lot of it very conservatively, and I was very nervous about battery life. And there were some changes that happened kind of late game that radically improved battery life. And I know that I've heard from some users that they can play for like a year without changing the batteries, which I thought, I honestly, that, that is probably the single thing that I came away thinking, man, that, that worked really well. And I'm really proud of how

that worked out. Do the songs change as the batteries die? No, the controller doesn't cry for help or tell you to change the batteries but maybe it should oh no when i've done haptics and songs it seems like when the batteries die the songs get sad more they don't intentionally get sad yeah we we tried really hard to make everything work a hundred percent and then like turn off. Yeah. Like, like, and that's actually,

that's really, really, really hard to do. And at least for me, it was really hard because I didn't have a lot of experience with battery powered devices when I started this project. And I learned a lot going through this whole process. And I wish I had known some things at the outset because I could have designed the hardware better from the beginning,

but you know, I had, I made some mistakes in the process. And, and when we were in early prototyping, there was a moment when I had, we did a lot of internal playtesting. And there were a lot of people on the group, this is a small group, you know, like 10 people. And there was a lot of internal playtesting on the group. And I remember, pretty early in development, someone coming to me and saying, Hey, uh, there's this weird thing going on where the controller is like resetting and resetting and resetting. And I've only been playing it for like six or eight hours. And I remember getting it on my bench and taking a look for an oscilloscope and sort of having that like stomach drop moment when I realized that I'd made some really, really bad assumptions about how batteries behave

over their charge or discharge curve. And that turned out to be kind of a major showstopper for a short amount of time, because we had to scramble and find a way to get around that without like, by that point, sort of the idea that we would use two double A's was fixed, you know, the form factor was fixed, the board was fixed. Well, not fixed, but sort of the form factor was fixed. And so we had to scramble to sort of find a way around this. And fortunately, we did. And actually, if you look at the board, there are two kind of large ish capacitors that are on either side of the board. And those were added kind of fairly late in development. And those are the solution to the battery life. Without those

caps, the controller would not last for the 80 or 100 or more hours that it does. Greg, do you have any other questions? I do. This may even be more specific. So, you know, no worries, Jeff, if you don't know the answer. But you did mention about the ability to kind of monitor the batteries and whatnot. There was one specific section. So the ADC that's on the board, I think it has maybe eight channels of it. And I understand what most of them do.

But there's one that I don't. I think it's ADC Channel 6. And I somehow got in my mind that it is related to voltage level or battery level. Do you happen to remember what that might actually be there for? I don't remember, and I'm sorry for that. I know that there is battery level monitoring, because if you go into Steam, you will get an indication of the current state of charge of the batteries and so there is analog voltage monitoring of batteries there um there might be some other stuff too uh but my guess would be that it has to do with battery state of charge got it okay

anything else i had one but I lost it. Well, we can come back to it. ADC Channel 6 was a little specific. Somebody asked me that from something I worked on in 2015. I'm like, there was an ADC in that? Jeff, R57. Why did you choose that particular value? Just why, yeah.

I know, I apologize. It was a long shot. Just wanted? Yeah. I know. I apologize. It was a long shot. Just wanted to see. I mean, your best bet would be to connect a power supply or have some batteries that are kind of dead and then some fresh batteries and plug them in and then just measure the voltages on that pin and see what you see. And don't be surprised if there's like a voltage divider or some kind of signal conditioning in between the battery and the measurement point. But if you connect some kind of a variable voltage to the input on the battery terminals, you should be able to see if that's actually influencing that ADC reading. That would be kind of fun. Jeff, did Valve do anything to prevent reverse engineering?

I'd say yes and no. I'd say overall, no. The controller was designed for the team that made it to be easy to work on and easy to debug. And that translated into a controller that was pretty easy for someone else to pick up and figure out how it worked. And that's not something that we were really worried about, except in a very specific area. So I said, maybe yes. And I think in terms of like security, it was designed to be a little bit hard to pick apart. Because, you know, one of the things that you worry about with any kind of a wireless device is, say, for example, you have a wireless keyboard, and you've got a dongle, like a USB receiver plugged into your PC, the last thing

you want is for someone to be able to intercept that communication and start entering, you know, maybe sniffing passwords or entering stuff into your PC to make it run applications or something like that. So there's like a little bit of an attempt to make that secure so that you can't sniff the output on wireless of one controller and use it to steal someone's passwords. But I think beyond a few specific cases, the firmware and the hardware design is not really purposely designed to be hard to reverse engineer.

Even the code sounds relatively straightforward, It's not really purposely designed to be hard to reverse engineer. Even the code sounds relatively straightforward, like unsecured or unencrypted downloads of the code. That's almost goading reverse engineering. Were they more supportive of it or did they just not care? I think that the team in general was very supportive of the idea that the end user could modify and customize the controller. And that's something that we had talked about, you know, pretty early on in development. And it was sort of an extension of a lot of the design kind of philosophies internal to the group. Like we really wanted things to be pretty open. And so a great example of that is a few months after the controller shipped.

So this would be like early 2016. We actually released the CAD for the controller shell and also for some components within the controller. And along with that, we released the CAD for the battery door, which is sort of the cover that's on the back of the controller. And we released a couple variants of the battery door so that if you wanted to, you could actually 3D print your own battery door. And there was a version that had a little cubby that you could put the wireless receiver, the USB dongle into. And the idea was that folks could kind of customize and modify the design, you know, create alternative shells, create alternative accessories that could clip on to where the battery door was to do different things. And I think that was really something that was a core part of the

philosophy of the design team and the design was to make that stuff accessible and open. So yeah, I mean, I don't think that there was really anything we did that would block someone from, you know, doing exactly what Greg did. Greg, did you partially choose this project because it seemed like something that was open to reverse engineering, or was that just, this was an interesting product and you wanted to look at it?

It was both. Definitely the fact of how open it was and that there almost seemed to be a, like, tacit encouragement to do it. I know I've heard interviews, I believe you had Ali Nates on the show like a while back, and he had specifically kind of mentioned how open the controller was and almost that this was an encouraged thing for people to pick apart the

firmware or maybe try to run their own. So yeah, I think if there had been more barriers in place, I may have not done it. I may have chosen a different project or just done something completely different. I guess this is for both of you. Is reverse, right? I think that it's, so in Greg's case, you know, Greg, it sounds like you were interested in learning about how this stuff works. You know, you weren't planning on like making a product necessarily, at least I don't think you were, but you were interested in using this to figure out how this worked and to be able to customize it, to do something that you wanted to do, like play alternative startup sounds, right? So you had sort of that, that interest in reverse engineering based on the things that you wanted

to do with the design. I think that needs to be there because reverse engineering is kind of a lot of work, right? It's not something that you would just do. Well, I was about to say for fun, but I actually think fun is also a pretty good reason why you would reverse engineer something. But, you know, if you think about it, like if you're like a big company somewhere and you're like, oh, we want to make a game controller. And gosh, this company over here, they just created one and it's got like, everything's just right out there. Like we can just swoop in and we can take that hardware design and oh gosh, they've even provided CAD to us and they provided maybe schematics and they provided all this other stuff. It'd be so easy for us just to make a controller. Well, um, I think there has to be like a business need, like there needs to be

a reason. And you know, the, the controller was designed as part of a platform, you know, the controller is intended to be used with Steam, which is Valve's software platform for gaming, right? And so you've got these two pieces that sort of fit together. And I don't know that the controller is as useful apart from Steam, because I think a lot of its value comes from the steam integration. And so you'd, you'd have to have like your own, I mean, specifically for the controller, like why would a, why would a company or a third party reverse engineer the controller?

Well, they'd have to have a platform to use it with. Right. And I think that condition needs to exist in order for reverse engineering to be attractive for somebody. I can see that. But same question to you, Greg. Do you think it's inevitable? And where would you put the line between fair play and intellectual property theft? So I think I agree with Jeff with the fact that there needs to be a motivation. I would say one

other motivation that I would add to what he was talking about is the idea of, I don't know if digital rights is the right idea, but sometimes it feels like companies try to copyright or hide things that are almost setting a bad legal precedence. whole HD DVD, Blu-ray DVD, like encryption code that I'm sure that was being reverse engineered for malicious activities. You know, people wanted to essentially bootleg DVDs and whatnot. But the way that the law kind of went around it, or the companies did is they tried to encrypt or copyright the actual encryption key. I remember being in college at the time and people, you know, printing out this long hex number and posting it there kind of as a little bit of almost civil disobedience. So I think sometimes that drives reverse engineering, like almost someone has said, don't try to get into this system. And people do it maybe a little bit on principle. Like I think Nintendo is a good example of that they put a lot of effort into locking down their systems and again there's i think that

motivation for people to bootleg stuff but then you get a lot of people like i mean i think it would personally interest me to be able to develop software for their hardware because like the nintendo switch is a great example it's a really amazing piece of hardware and like you know why is it that i would have to buy you know, a several thousand dollar dev kit get approved as a developer when maybe I just want to tinker in it in a non-harmful way. I realize that's also a very altruistic view of the world. You know, it's kind of like we should leave everything free and open for everyone as long as everyone's going to play nice, but obviously everyone doesn't play nice. So coming back to kind of the second part of your question of, you know, when does it cross that line? I think it has to do with the person's intention, in my personal opinion, you

know, if you're going to reverse engineer anything and try to learn from it. I think that's great. Like I love the open source world, the open source community, because you can learn so much on your own these days. And I wish that there was more of a motivation for companies to essentially say, hey, you know, you have this device for one person purpose, but maybe we want to make some functionality of that available to curious developers so that they can, you know, we can all learn from each other. But then I think if you take that from the standpoint of, hey, I want to rip this company off or reproduce what they do, then I think you're crossing a line and that's not right. Do you guys remember the iOpener? This is a long time ago, but there was a PC called the iOpener that came out

probably around 1999 or 2000. So this is a long time ago now. But it was a it was like a self contained sort of a iMac looking thing. It was a like a self contained PC that I think had very, very minimal system requirements. And it was sold really, really cheap. I can't remember how much but it may be a couple $100 or something like that, which at that time was like crazy cheap and people on you know slash dot or whatever figured out how to right hack into it to be able to run linux or run custom applications and it was super cool because you could get this pc that could it was it was like super super slow and super limited on memory and storage, but it was expandable because you could add a hard drive.

It had like all the buses inside. So you could add a better keyboard. You could add a hard drive. You could do all this stuff to it. And the reason I bring it up is that through the reverse engineering efforts of a community around it that just thought that this hardware was really cool,

the company actually went out of business. And the reason that happened was that the pricing of the system had assumed that you would be purchasing a service from eye opener or whatever the company was that made the eye opener. And without the service, they went bankrupt. And so that's an example of where they didn't really try to block anyone from reverse engineering their hardware. And there were IDE or whatever buses inside of it that were very easily accessible. People figured this stuff out. But at the end of the day, it destroyed this company.

So it's sort of a sad story. And I think it wasn't malicious. No one was trying to do this to this company, but they basically created this application for hardware that it worked well, but the business model fell apart. And I remember watching that whole saga unfold in, you know, when I was in college. So looking at the Wikipedia page, the device cost $99 with the assumption of the monthly internet service, but it, the actual cost of the hardware was estimated between $300 and $400. So for $99, you could get a $400 computer, and if you don't buy the monthly internet, yeah, they're going to go out of business.

Well, that's an example of definitely hurting a company unintentionally through hacking. Greg, you mentioned that reverse engineering and sharing the information, as well as reverse engineering to learn yourself, is making it open source better because it's more altruistic or worse because it's more likely to hurt the company? I think that's a good question. You know, I tried to put a lot of thought into when I was working on this project about how it might reflect back on, you know, Valve, you know, and given, right, that there's a little bit of hubris in that because this is kind of just a small project, but thinking through more of a worst

case scenario, you know, how could this cause, you know, a lot of pain for a company I respect. And so, you know, I tried to think about like, why am I doing this? Why am I releasing it? And what's the worst that could happen doing it? And, you know, I tried to make it look like it was a cool, fun project, but maybe nothing in there was, you know, another, I should say another version of the firmware that I have on there allows you to use the controller as a Nintendo Switch controller. So after I learned how to use all the peripherals, I essentially just was spoofing the HID USB interface of a Nintendo Switch controller. So you could use this controller on your Switch. And, you know, it's not fully featured it's very simplistic um you know i'm

not and i was trying to be very clear about hey i think this is neat and people might be interested in it but i'm not releasing this as a product i'm not trying to get you to use your steam controller instead of a switch controller or you know not use your steam controller with steam um like there is much better quality firmware out there for this, or there's much better if you want to use something on the switch, there's much better hardware options that were designed for it, please do that. So there's, you know, there's a little bit of the risk or the question of how much do people read what I wrote? And does that fall on deaf ears? You know, are people just jumping right into it and not seeing my intentions? So yeah, I guess that that's where I came from on it was I

was trying to do the right thing and trying to communicate with it, or communicate that in hopes that, you know, that's what the community or people who see this would use it. And also thinking through kind of what's what's the worst anyone, you know, would do with this, as Jeff mentioned earlier, like this is very much designed to be used with steam. You know, I don't think that anyone's going to take what I did and really find a way to monetize that in a way that would say, you know, hurt the sales of the controller, especially that, as Jeff initially mentioned, it's, you know, an older controller in terms of how fast, you know, the market turns these things over. So yeah, those are kind of my considerations and thoughts in the regard of, you know, when I decided, hey,

should I just put this all up open source and kind of let people see what I've done? Well, I'll say that if I had been aware of this project, so say we rewound and Greg had done this back in 2016, when I was still with Valve, I would have thought it was really cool. And it wouldn't have been unusual for me to reach out and to say, hey, I think what you're doing is really cool. Do you want to talk about this? And I think one of my regrets is that unfortunately, I'm not still with the company because if I had come across this in 2019, I would have thought, hey, that's really cool. I haven't thought about this stuff in a while.

Let's talk more about this. And one of the things that I regret is that the schematics. So Greg mentioned early on that the schematics were not available and that made his job harder. And apart from sort of the forced learning that that happens when you don't have a copy of the schematics and you try to reverse engineer a board, I do regret not making those available years ago. And I think that if there had been projects like Greg's project back when I was in a position to do that, I would have definitely pushed for that. See, that's interesting. There are some companies that would allow that, that would say, oh yeah, I'm super flattered that you think my product is good enough to spend your own time on.

And yeah, I want to help you. And then there are companies that would say, no, stop, cease and desist. Here's a letter from our lawyer. I don't know how the companies decide which personality they are. People will see your mistakes. People could run off and do things like the eye-opener story that you hadn't anticipated. Companies that you have worked with, that you've signed agreements with, and maybe you are bound by licensing terms, may object to the fact that you are releasing elements of their design. I know that companies get really touchy about software and firmware, particularly, I think more so than hardware design. You know, I know that companies get really touchy about software and firmware, particularly, I think more so than hardware design. So if I were to release firmware for a product I was working on, and I didn't get the okay of every vendor who I had worked with on code

development, you know, some, some areas I think are much more contentious than others. So, so I think the answer is that it takes work. It takes work and it takes time and it takes some confidence that, yes, this is the right thing to do. This is what I want to do. And I'm willing to assume the risks that I didn't just make like a million of these things. And then someone comes up and says, hey, you've got this resistor kind of in the wrong place. And actually, a prime example of that is the Raspberry Pi. So the Raspberry Pi, I'm not sure if folks know, but they released the Raspberry Pi 4. And then within a week or two, somebody posted online like, hey, your USB-C circuit is kind of broken, and it's not designed according to the reference design for USB. And as a result, the Pi will not work with certain chargers. And I'm not for

a moment going to say that that is an argument to not open source your designs. And in fact, I would love it if the Raspberry Pi Foundation would release full schematics for their boards, because I think that would be very healthy and very good. And think about all of the learning and all of the possibilities that would open. But unfortunately, they've chosen not to do that. However, they did release a one pager in which there was a mistake, and they had already probably made a million Raspberry Pis by the time someone had identified that. So not to say that that's not a good reason to release schematics,

but it's scary as a designer to know that the world is going to be looking over your shoulder. And of course, that assumes that anybody actually cares, right? Because I think a lot of times we do things like this. And then, you know, think about how many projects are on GitHub that nobody's ever really looked at, right? But anyway, I'm just saying I think it's not easy. It takes some doing to want to be open and to be open about the intimate secrets of a particular sometimes, as in the case of Raspberry Pi 4, you are vulnerable, but you can get help that way. And they might not have discovered that until they had caused a few fires

if they hadn't open sourced that. Well, I don't think it would cause any fires. Let's not. I don't know. It just didn't work. It just didn't work. Okay. But it broke the board, too. No, no, no. It was a cable thing, and if the cable

didn't identify the right way, it didn't charge. Oh. Okay. It's made a lot of cables not work. Any cable that had any high-quality cables that could also carry high-speed data didn't work for charging. Well, it'll be interesting to see if they decide to be more open or less open in the future as a result of this. I totally agree with you that if they were open more, they probably would have a better design.

It might be more likely that someone would rip off their design, And I think that's probably precisely what they are worried about. But it also would probably result in a better hardware design. But does that really stop anybody? I mean, if something is a big enough target, people rip it off, even if you don't open source it, right? I mean, there's plenty of PyLikes out there, right? I think that's very true. And I think if you go to the markets in Shanghai, you'll find ripoffs of

all sorts of products that were not open in any amount. And I think in some ways, hardware designers use that as a badge of honor. I remember hearing from someone saying, the first time a Fitbit, like a counterfeit Fitbit showed up in the markets in China, that was like a rite of passage for the design team saying, hey, we've made it. Someone cares enough about this product to rip it off. And I think that's actually really true, right? If someone cares enough to rip off your product, you're doing all right. Like that's something to be quite proud of. And they're going to do that whether you release schematics or not, because you're absolutely right. It's not that hard. I think I was sort of thinking to myself when, Greg, you were saying that you had tried to conserve controllers when you were doing this

reverse engineering. That's definitely not what you would do if this was like your job, right? What you would do is you would buy a pile of controllers and you would take one and you would desolder all of the components and then you would scan both sides of the board or maybe you would put it through an x-ray and you would get all the nets, right? And I think that's down. This is the recipe. I think that, you know, there are things that I think that when you're, when you're maybe a hobbyist or you're starting out in electronics, you're thinking, oh gosh gosh, I just bought this really expensive product and I'm trying to figure out how it works. That's not how you would do it if you were going to scale up. If your livelihood depended on reverse engineering things, you would throw lots of products at it and you would test down individual layers of the board, just like you would decap a controller, for example, and they'll say, oh yeah, you know, company X, they were able to make this for $7. And we know this through, you know, we provide these spreadsheets. And if you subscribe to our service, you can,

you see all their vendor lists and all this stuff. And I got to say that there's so much BS in that, like, how can they possibly know how much it costs to make anything it's so specific and related to business agreements on so many different levels and volumes and sourcing and all these special arrangements and you when you get into the industry you sort of realize how full of bs that stuff is uh but anyway these are people who like they're, they, they are making money in the business of reverse engineering things. And I'm pretty sure that they buy more than one. You know, I definitely took some skills from my everyday job and how I approach this. But if I were being, you know, if there were money behind this, if there were schedule, all those things that, you know, I normally think about when I'm doing my work, I would have taken a much different approach to this. You know, like one perfect example of is really my whole intention when I started this off

was how can I customize this jingle? And once I kind of realized the data is most likely in the firmware probably the most efficient way to do it would have been to set up a rig that literally goes through you know byte by byte or bit by bit in the firmware changing it until you hear your tune change and then you can figure out what bytes to go change from there and just modify you know the firmware itself like part of the reason this took me, you know, I spent the past two, two and a half years on it is that, I mean, it was a little bit of short-sightedness always thinking I was around the corner to the solution, but not going about

it necessarily the most efficient way. But then in the end realizing, hey, I have this whole pile of knowledge from what I thought was going to be a simple goal. You know, what else can I do with that? It's different kinds of planning and learning. There's the exploration of playing, which is what you do in your off time. And then there's the systematic approach where money and time fight a battle and it isn't the same as when you're playing. And so the reverse engineering professionally would be quite different than hobbyist versions. Right. And I think because of the approach I took on this, like I took a lot away in terms of personal knowledge and personal development that I probably wouldn't have if I was doing a

more direct or economically viable approach. But you did spend quite a bit of time on this. And I understand wanting to change the jingle. This is a lot of time. What made it interesting enough to push you past the hurdles of, eh, this is hard. I don't care. I think part of it was, um, it started to become a puzzle. Like once I got past, it was always, I was always, it was always in the back of my mind. And I was thinking about the next step of how would I do this? How would I do that? And you would, you would just uncover more and more layers. And it's, it's very much like a puzzle, a very intricate puzzle where you're assembling someone else's work. And in the end do you get you get to see a picture that was already on the box um you know it's not like how how worth it is that but there's a you know there's an

an enjoyed ability factor to that of discovering this almost like a like an archaeological dig of like okay well what could this variable possibly be Now I've seen it used in these three different places. It must be related to this function now. Okay, what's that function do? And I think it was just little things like that that kept me going forward. And then the momentum of like, well, I spent the last six months on it. Let me just spend another three. Okay, I've spent nine months on it. Let me spend another six. And next thing you know, it's two and a half years later. And you started out with the jingle. That was the thing that drew you. What else did you discover? What else can you change?

So that's really the only functionality I found that I could change in terms of keeping the original firmware on there and getting results. There are other things in the EEPROM, like there seems to be one variable that is your hardware version that you'd probably don't want to change. But all the other work that I did was I made custom firmware that sat on there that allowed you to use the Steam Controller in one of two ways.

One of them I call kind of like a dev kit. So what it does is you load this firmware up on there and then your USB cable becomes a simulated serial port. And then I have a very simple command line interface where you can essentially say, tell me what the ADCs are reading, tell me what my GPIO states are, tell me what values I'm getting back from the trackpads, all of that. And then I also took that same knowledge base and converted that to a version of firmware that uses the USB port and essentially, I think I mentioned before, is a wired Switch controller. So you load this

firmware on, you plug the controller into your Nintendo Switch, and it looks just like this, you know, essentially $20 officially licensed product. The Switch doesn't know any different. I think that the idea of using a finished product as a development board, that was the thing when I when Alicia, you had emailed me originally about Greg's project, and I took a look, it was like, Oh, yeah, that's super cool. And that was definitely something that I pushed for pretty early in the controllers design. You know, if you go way, way back to when we first started working on this, there was a pile of dev boards, you know, at some point, we had a microcontroller dev board, and we had, you know, gyro dev board, and we had all these things that we were sort of stitching together. And I was a big proponent of no, like, let's just make something that's even fairly form factor, and try to get all this stuff onto a single board because it's going to make everyone's lives much easier. And I would absolutely, A, advocate for that because dev boards are super inconvenient.

I'm not a fan of dev boards because a lot of times it's more work trying to wire things together than it would be just to spin a board and put it all on one. But I think the idea that you can use a product as a dev board, I think that's really interesting and cool because you've sort of got everything there. You know, the only thing you don't have is you don't have breakouts for all of the unused IO on the micro. And that's something that, you know, we had early on because it made our lives much easier to have all the unused pins broken out to test points. But unfortunately, you know, the needs of manufacturing, you don't have the space to be able to do that anymore. And so a lot of those went away pretty late in the design. But there was a long time when there were actually a lot of extra test points, because we were using the board as a development board.

So I think that's a great idea. And I think that's the thing about the OpenSteam controller project that I looked at and was like, yeah, I think I totally agree with that. And I think that's a great idea. And I think that's the thing about the OpenSteam controller project that I looked at and was like, yeah, I think I totally agree with that. And I think that's a great use of the hardware to be able to use it to prototype things. up manufacturing console manufacturing i was gonna ask if if jeff if he'd recreated something that you guys had uh during manufacturing or were there not that sort of test center test console uh we had a lot of that um so yeah it's definitely we had tools that were designed to do exactly the same things i mean obviously not emulating another controller, but to basically take all of the eyes IOs and then display those and to be able to change registers within the micro and stuff like that. And that's something that I used a lot. I was probably one of the biggest consumers of that because as the hardware guy, you know, there were some features that came

very, very late in the program. And it's always a hard thing when you're the hardware guy saying, Oh, gosh, I need to validate that this stuff works. But the thing, the feature in the controller isn't ready yet. And so we're about to go and make a whole bunch of these, like, I need some way of verifying that these things actually do what they're supposed to do. And so some of those test tools came as a result of me sort of screaming that I needed some way of getting confidence in the hardware before the sort of like the product level features were ready. And a great example of that is the gyro. The gyro was a feature that got added, the hardware got added very early, but the actual

like user facing features got added pretty late. And so there was this big gap where I was actually at some point advocating like, hey, why do we even have this thing on here? Because we're not using it for anything. But I'm really glad that the team talked me down off the ledge because that turned out to be, I think, one of the most significant features of the design in terms of what has really gotten a good response from the users is the ability to use the gyro to assist with aiming.

Jeff, has this been weird for you? I mean, talking to Greg, has it been weird? I actually, I don't think so. Because, and I was thinking about that. I saw you'd given me some notes and I sort of looked at that and I was like, I started thinking about that yesterday. It you'd given me some notes and I sort of looked at that and I was like, I started thinking about that yesterday. It's like, is this weird? The controller project was essentially my whole life for about five years.

And that's a long time, I think, for any project. It's a long time for a consumer electronics project. But I was one of the major members of the team from the beginning and was a big advocate and a driving force behind the development. And, you know, the controller exists because of my efforts and because of the efforts of a probably surprisingly small team of, you know, just a handful of people who were involved from the beginning to the end. And I was one of the folks who was involved since there was barely a hardware group. I remember getting poked fun at for ordering, I think the most expensive oscilloscope that

Valve had ever purchased was the one that I purchased when I joined the company. And I remember showing up and there not really being much of anything. We didn't really have hardware tools. We had some prototyping stuff, thanks to the efforts of Jerry and Ben and some other folks who had been there first. But I was one of the folks that helped build up the hardware group from the start. And the controller was the project that I joined almost from day one. And it was because I believe that this was the right product for us to make. And I believe that it was something that we could do. And I thought we could do something really novel and interesting, and we could do it well, because it would play off of the strengths of the company

and the strengths of this sort of brand new design team that had formed at that time. And so, is it weird? No, because I've been talking about this product for, you know, now it's been like seven years, but I've been talking about it for about as long. And it's something that I've invested a huge amount of time into. You know, is it weird to talk about it as no longer an employee of the company? I mean, yeah, it is a bit. And I need to be sensitive to the fact that I'm not involved in development anymore. You know, there's other folks that are sort of carrying that torch on and I'm not connected to that stuff anymore.

But this is a product that I poured a lot of blood, sweat and tears into. And it feels good to talk about it because it's something that I'm really proud of. And I think the company is really proud of as well. Now I kind of want to end the show. That was a fantastic final thought, but I still have more questions. I'll just cut it out. Maybe we can cut and paste that to be my final thought. I'm not doing that. Because I'm probably not going to have one that's anywhere near as coherent as that one. You can just skip. Greg, is it strange to talk to Jeff?

It is and it isn't. I think from the perspective of when I started this project, I knew it was something that I thought was really neat and sure there's always that kind of like you know dream in the back of your mind that other people are going to think that what you're doing is neat and also worth looking at so it's surreal and it's flattering to talk to Jeff you know especially like

hearing how long he was involved in the project and how big of a you know factor it was in his life at that time so yeah no I think it's you know, factor it was in his life at that time. So yeah, no, I think it's, you know, it's really awesome and flattering. Greg, what are your plans with your OpenSteam controller project on GitHub? So I have, you know, I've gotten the most kind of basic functionality of the controller working. There's still some things that I haven't interfaced with yet.

The radio chip's a great example, which actually I know Jeff brought up earlier, the idea that you could very easily kind of brick that. So there was a hesitancy there, I think, to tackle that. So things like that, exploring kind of the remaining interfaces, like I never got the gyroscope interfacing to that quite working, might be part of it. But I think what's kind of motivating me the most at this point, and that's really what's going to drive how much farther I take this effort,

is actually the Switch version of the firmware. It's by far gotten the most response that I've seen out there. And I'm not saying I want to take this and make it, like I said, a competitive product with these other qualified products that people are really trying to sell, but I want to use it as an experimentation platform to see, can I add functionality to the controller that other companies won't do or maybe haven't considered with the key functionality that I want to see how well I could get it working as like a recall function. So you could essentially tell the controller to, you know, record your inputs and then play it back. And

thinking of that in the context of like a really difficult side scroller, if you would just need to do certain parts of the level once, which there's a whole debate about whether that's cheating or not. But I think that could be an interesting thing to implement and play around with. Jeff, do you have any advice? Gosh, that the thing that you just said, Greg, sort of reminds me of this interplay between openness and configurability and cheating. Because that is a potential problem when you have a controller that you can customize. And even with the built in customization, that was a concern is, oh, can you make bindings for the buttons that give you an unfair advantage?

And I think that a lot of the concerns just did not actually materialize. But if you remember way back to like Nintendo and Atari and early games, having rapid fire was considered sort of cheating, because it it certainly made it much easier to be competitive with like side scrollers and stuff where it's just about how many times you can push a button in a given amount of time. But no, I think that, Greg, you know, your plans and goals, it all sounds really cool. I mean, I think that the controller is a great learning platform in that the design is not obfuscated, really. It's all just right there. And I think that there are definitely going to be peripherals that are a lot harder to get working, just because there's a lot more proprietary firmware that's involved. And like the radio is a whole ball of

stuff. And obviously, you know, you've, you've got like the fact that you need to be careful about making a transmitter that transmits on the wrong frequencies and transmits with the wrong power levels and duty cycles and things like that. But I mean, it's all out there. And I think that it's, it's, it seems like a really interesting project to sort of be tackling peripheral by peripheral and, you know, making the controller behave like another controller. Obviously that's not something that you would really do as the design team behind the controller. You're not going to be able to market this thing as a replacement for another company's controller. But I think as an individual, you can do all sorts of crazy stuff. And that's really interesting and cool.

Jeff, what are you up to these days? I have spent the past couple months basically investing in my business. So I'll be honest, you know, I've had a business for about 11 years now. This is Mighty Ohm. This is Mighty Ohm, yeah. So I started Mighty Ohm in 2008, and I started it really with kind of two goals. You know, one was to do freelance work because I had been working in the semiconductor industry for about, I think, eight years at that time and had been wanting to sort of stretch my

legs and do more product level design. I was a chip designer and I was sort of tired of working at this very, very close up, zoomed in level where all I really got to see were chips, I didn't get to see how they were used, I didn't get to work on evaluation boards or like product level, I didn't really get to implement those chips into products. And I was interested in sort of seeing the whole, like top to bottom levels of hierarchy of the design. And so I started this company with the idea that I would do embedded systems, which I'd always been interested in and was just starting to become much more accessible. The days of the PIC were kind of coming to a close and the AVR, this was before

ARM was really something that everyone was talking about, but there were much more accessible microcontrollers becoming available. And I wanted to play with them and learn things. And I also wanted to learn PCB design, which I had done, but at kind of a horribly primitive level up to that point. I'd been designing boards in AutoCAD for very simplistic reference designs for RF circuits. And so I started this company with the idea that I would explore these new areas and sort of market myself in that way. And then the hobby electronics stuff kind of came as well, because I wanted to teach myself a lot of these skills, because I had no formal training, I'd never done PCB design professionally. And so what better way to sort of build my own stuff. And so if you sort of fast forward a ways,

when I joined Valve, my time really shrunk. I wasn't able to dedicate myself to Mighty Ohm very much. I sort of kept it going, but it was on the back burner. And so I've sort of been thinking about, well, how do I invest more and grow this again? Because I'm interested in building more types of products under my own label. And I actually just got back from giving a pair of Geiger counter workshops at CCC camp outside of Berlin. And that's not something I would have really been able to do when I was working for Valve, because it would have been really challenging to take that time away. And so I've been investing

some more into that. And then also trying to figure out what big thing I want to pursue next. You know, I've been working on the controller for quite a few years. I'm at a kind of a crossroads in my career where I've worked on a lot of different things. And I'm sort of trying to figure out on the slider, do I want to be more of a specialist? Or do I want to be more of a generalist? And that's something I have been thinking a lot about, because I spent the first decade of my career in RF design, in a position where there were really only three or four companies in the country that I could work for. And I think my biggest regret is that I didn't go work for Apple in the mid 2000s, because I remember hearing rumors about a phone project and being like, Oh, that sounds really

cool. But gosh, I don't know, Apple, it's going to be really different. And I shied away from that. And I stayed at the company that I was at. And I sort of have watched the iPhone being like, man, I could have been in there. Ground zero when that was first becoming a thing, because I worked for a component supplier to Apple. And so I was hearing about a lot of these things that were going on. But anyway, I spent the first decade of my career being hyper, hyper specialized and wanting to become more of a generalist so that I could see, like top to bottom product design and also have more flexibility so that I could live where top to bottom product design and also have more flexibility so that I could live where I wanted to live. And I could work for sort of a more interesting array

of companies. And Valve was a great place to be to become more of a generalist because I was a member of a super tiny design team where I had to do whatever was needed to get a product out the door. And that included manufacturing support and being in China. And it included having to learn manufacturing tests and a bit of firmware and like all of the things that were needed to, to ship a product and also doing a lot of PCBs and FPCs and things like that. But I'm at a place in my career now where I'm like, well, do I want to continue being a generalist or do I want to get back to my roots and pursue RF design again? And I don't have the answer to that. I'm actually not sure. But it's something that I've been thinking about a lot, because I need to decide what the

next big thing for me is going to be, be it working for myself or working for a big or a small company. It's always a hard crossroads, but I feel like it could be an entirely separate show. Yeah. And I think we are about out of time for this one. Greg, do you have any thoughts you'd like to leave us with? Yeah, I think, you know, this is something I've seen echoed throughout my career and was further echoed by kind of the efforts I put into this project. And that is my advice to anyone out there who does anything complicated is take a break. Walking away from a tough problem, especially making sure you're walking away mentally, sometimes is the only way that you really get the best clarity on what maybe a good solution is. And I know that was important with this project for me. There were some times where I set it down for weeks or not months because it felt hopeless to carry forward. And then I would figure out how to do it. And I'm pretty happy with how everything's turned out so far. Right. Jeff, what about you?

I think that thinking about my experience over the past few years, the piece of advice that I would give or the thing that has helped me is become comfortable with not knowing what you're doing all the time. Because if you're working in a new area, it's you want to come in and sort of present yourself as this expert. But I found that if you're working with the right team in the right environment, it's okay to not know the answers. And that's something that took me and I'm still not 100% comfortable with, but just being comfortable with the idea that you're constantly learning, and that you're not going to know all the answers and that you're going to fail. And if you fail fast, it's a very powerful learning experience. Our guests have been Jeff Kaiser, freelance electrical engineer and founder of Mighty Ohm, and Gregory Guszczak, software engineer at CriticalLink and creator of the OpenSteam controller repository on GitHub. Thanks, guys. Thanks for having me on the show. Thanks.

Thank you. Thank you to Patreon, Slack for the great questions for Jeff and Greg. If you want to hang out with us and your other listeners, feel free to donate a buck on Patreon and we and thank you for listening. You can always contact us at show at embedded.fm or hit the contact link on embedded.fm. And now not a quote to leave you with, but an instruction. If you are able to get the flu shot, you should, you should do it soon because the holidays are coming and you don't want to give your loved ones the flu. 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.