Embedded - 388: Brains Generate EMF

Episode Date: September 30, 2021

Alan Cohen joined us to talk about brain waves, medical product development, open source, and helpful engineering. Alan has been working on VolksEEG (volkseeg.org, github.com/VolksEEG/VolksEEG). This is an EEG (wiki Electroencephalography) which detects brain waves. It uses the TI ADS1299 EEG monitoring chip and the Adafruit Feather nRF52840 Sense. Alan wrote Prototype to Product: A Practical Guide for Getting to Market, published by O’Reilly. He talked about it on a previous episode: 269: Ultra-Precise Death Ray You can find him on twitter as @proto2product  and on LinkedIn.  Helpful Engineering (helpfulengineering.org) aims to deliver more open source solutions to society’s systemic challenges.

Welcome to Embedded. I am Alicia White, here with Christopher White. We've asked Alan Cohen, author of Prototype to Product, to talk about his latest project. Hi, Alan. Thanks for coming back. Hi, thanks for having me back. It's been something like three years since we had you on the show. Could you tell us about yourself as though we don't remember those three years at all?

Okay. Well, that makes two of us then. I'm a systems engineer who's worked with medical devices pretty much my entire career. So typically I'm involved in developing medical devices and sort of helping bridge the gap between quality, regulatory, and engineering kinds of issues. So basically designed for regulatory, right, to make it easy to get things through the FDA. Currently I'm a consultant. I work primarily for two different customers. Okay. And you have a new project. Could you tell us about it briefly, and then we'll get more into it after Lightning Round? Sure. So I've been working with an anesthesiologist in Canada. He

was previously in Boston, which is how we met, a fellow named Brian Glesserson. And we are developing what we hope will ultimately be an FDA-cleared open-source medical device, in particular an electroencephalogram, EEG. And we're calling the project or the device the Volks EEG for people's EEG. Okay, so are you ready for lightning round? I'm never ready, but, you know, I'll try. Okay, here we go. If you could teach a college course, what would you want to teach?

I would like to teach product development, which is in line, of course, with the book I wrote. What is the most important quality for an engineer to have? Patience, persistence, or resilience? Hmm. I'd say patience, but that sort of loops in the others as well,

at least the way I'm thinking about it. As we discovered last week, persistence is just patience with being angry. What is your favorite bird slash dinosaur? Oh, bird slash dinosaur. I guess that's an or, a slash. Or an and. Yeah.

Could be an and. Well, they're kind of, well, they're a continuum, right? Sort of. Yeah. I would say a triceratops. A triceratops. Okay. Okay. Yeah.

We should maybe make these easier. What is your favorite wavelength of laser? Oh, I do not have my wavelengths memorized. I do like blue lasers. So whatever the appropriate wavelength is for that. Brains. Actual seat of consciousness or distraction from the spleen? I would say actual seat of consciousness.

Do you have a tip everyone should know? Yes. My favorite tip is the only thing worse than no information is bad information that you think is correct. So be very careful about what you think you know. Okay. So Vox EEG, an open source EEG. And an EEG, that's the thing that shows the heart rhythm. No. What's an EEG, Alan? Brainwaves. Brainwaves. Oh.

EKG. That's where I was. Or EKG, yeah. Okay, so EEG, looking at brainwaves. Hence the question about brains. Oh, it all is so clear now. Okay. Okay.

I'm not cutting any of this. So what will your EEG do? Well, there's, I guess, going to be two outputs, let's say, from this project. So ultimately, what we're planning on having is a clinical EEG that's similar to other clinical EEGs that you'll find in any hospital or any neurology office. And those are pretty standard. They're well-accepted. They're well-defined. So there are standards that define what an EEG machine does.

So that's, you know, do everything a normal EEG machine does, which is measure brainw waves for various purposes, like diagnosing epilepsy and things like that. On the way to getting there, we're going to be developing a device that is, well, it's for research, but basically will measure, will be used to research measuring depth of anesthesia.

So when you put somebody under anesthesia, obviously you want to make them unconscious, but you don't necessarily want to make them more unconscious than they need to be. So there are devices that will measure depth of anesthesia to help the anesthesiologist understand how much anesthetic to give. There are some non-optimalities, shall we say, about the devices that are on the market. So there are some anesthesia researchers who are interested in looking at brainwaves and understanding depth of consciousness or depth of anesthesia based on those brainwaves. Can you, just to lay a foundation here, because I know very little about EEGs. I know a lot about EKGs and things like that, but I don't really understand how they work and what they're measuring

and what's going on in the brain that can be measured in such a way. And how many sensors do you need? Yeah. All very good questions. So in terms of how they're generated, they're generated by the brain by you know neurons groups of neurons in the brain firing um off and i guess uh collectively

uh large clumps of them in various parts of the brain generate enough um emf that you can you can detect it um so in terms of number sensors involved, typically there's a lot of sensors. So there can be up to 24 sensors, right? And these are very low amplitude signals, as you might imagine. So there's a lot of effort that goes into cutting the noise. But typically up to 32 sensors, depending on what they're trying to diagnose. Now, in the case of EEGs that are used for depth of anesthesia monitoring, typically they use somewhere in the 2, 3, 4 electrode range. You're looking at a very specific area, so they can get away with that. Do you need really good skin contact? Do you have to shave where the where the probes go

yeah that's a good question too and you know brian my co-conspirator would certainly have a lot more to say about this than i do um i think typically no you don't um the you don't have to shave the contacts uh are very important right so how. I was just talking to him about this this morning, actually. There are disposable electrodes that you can use, which give you their disposable, which is nice, but the contact's not as great. And then there's reusable ones, which actually put metal on the skin. The disposable ones, I think, don't put actual metal on the skin. They have like a salt, silver, silver chloride salt solution.

So you do need to be careful about the contacts, but you don't need to shave, I think, typically. And is it correct to speculate that the signal level is extremely low and noisy from something like going through tissue and brain? Yeah. Okay. Yeah. So it's, well, it's, yeah, so it's noisy because it's low amplitude and because there are different things that interfere with each other in the brain.

And then, you know, yeah, it's noisy once you get it off of the scalp, right? Then, you know, 60 hertz noise or just about anything. There's also noise induced by muscle movement. So if you blink your eye, for example, that will swamp the EEG signal, right? I mean, that's something you can compensate for, right? The person reading it understands that. And that, in some cases, can be good information, too. But it's just the very long amplitude signals.

And one more question, kind of on details. What kind of signals are we talking about? These are very low frequency, sort of. Are we talking about tens of hertz or kilohertz or things like that? Or kind of what ballpark are the signals that the doctor is looking at? Yes, that's a good question, too. A lot of interesting questions. You guys ask good questions,

and there's just a lot of interesting questions around this stuff. So what's typically looked at is in the hertz region or subhertz region. Okay. But there's a lot of interest in looking at higher frequencies to see what can be seen. And again, this is my understanding.

Brian would have better answers to this. So we're going to be sampling up to 256 hertz, which is overkill for traditional applications. But, you know, there might be interesting information there. You have worked as a consultant in medical device development for a while, right? Yes, too long. If a client brought this idea to you, one that needed FDA certification of an EEG machine, what is the minimum time and cost you'd quote them

for making this something to bring to market? So that's a slightly nuanced question. So, or it's a slightly nuanced answer, right? So the thing about the FDA that, you know, is maybe not as well known is that the FDA doesn't clear a design, they clear a device, right? So in order to get a device cleared by the FDA, you need to be in manufacturing or something like that. Right. There's, again, some nuances around that. So that, you know, getting getting set up for manufacturing that requires some capital. So it becomes, you know, the getting through the FDA itself, you know, for particularly for something like this, we could talk about why.

It's not the development design development is not very challenging. So particularly for something like this, we could talk about why. It's not the development. Design development is not very challenging. It would not cost a lot of money. Like, let's say, you know, in the off the top of my head, I'd say maybe $200,000 or something like that. Because it's all about, there's an EEG on a chip that a lot of people use, and it just does everything. The more expensive part, then, is really going into manufacturing and getting that going. So I'd say, you know, maybe we're talking at least a million or two million dollars. And that actually factors into the roadmap for how we're going to move forward on the development.

So we could talk about that at some point, if you'd like. So you do plan to do manufacturing to get that FDA certification of the whole product? Well, maybe not. So we are interested in getting it FDA cleared and getting it into the market because we think this is something that should be done for a number of reasons. We think it's just good for humanity. We may want to partner with somebody or multiple entities to actually do the manufacturing and the marketing, right?

So what we know we're going to do is get it to the point where we've got a reference design, right? Something that we feel that there's a good chance it is FDA-able and we've got good artifacts that whoever takes this to the FDA and then into market can use for that purpose. But we won't necessarily go do the manufacturing ourselves because that's a lot of capital. You really got to build an organization.

We're not averse to doing that, but we don't necessarily need to do that ourselves. And do you have project specifications? I mean, when I've done medical development, there's a lot of documentation that goes on with software requirements documents and a whole list of other documents. Are you doing those? We will. We're not exactly there yet. And let me explain that a little bit. So I think I mentioned earlier that there's actual standards as to what an EEG machine should do. So there's an IEC standard.

I forget which one it is. There's also IEEE standard that says if you want to be an EEG, here are the things you need to do, and here's how you test those things. We will put it in the IEC document. The IEEE one is actually a lot more vague. So to some degree, those are a good chunk of our requirements slash specifications. I don't say requirements, really.

Then there's sort of the product-specific requirements and specifications. And those, we are, you know, we're going to take an iterative approach to that. So one of the things I like to do with medical devices, I'll take a step back. You know, as you're alluding to, there's a lot of process involved in developing a medical device, as there should be, right? You're developing something that, you know that can very directly impact people's lives in a good way or a bad way. So there is a lot of documentation that's involved in trace matrices between tests and requirements and specifications and things. The challenge of that, I find, is that

if you do that sort of high-level process from the beginning, it's very burdensome. And if you guess wrong about what you're developing or how you're developing it, you've got to go back and redo stuff, and you've spent a lot of time dealing with processes that you didn't need to deal with. And one of the things I talk about in my book is that users typically don't know quite what they want until they have it. So the way I like to develop medical devices is to sort of first go through a discovery phase, right? So first go, you know, do some de-risking, right? Like testing out various concepts and then getting some things in front of users and, you know, letting them play around with it and whatnot

and get to the point where we're very confident that we know what we're building. Then at that point, sort of put the hammer down, build, you know, basically go through all the processes that you need to go through ultimately for a medical device. The hammer down part is very important. I've been in two places where that almost never happened, where it just got stuck in experiment phase. And there was this contradictory period of, well, we haven't quite finished figuring out what we're building, but also the CEO or the founder really wants a date on when we're going to ship this. And also he's the person who's experimenting.

I don't know if you have a notion for how to encourage companies to move past the lab point, but that was very difficult in my experience. So I'll say two things about that. One is that that's actually mostly what I get hired for these days is exactly that, right? So to transition teams from, you know, sort of researchy efforts into something that can go into the SBA. So that's one answer. The other answer is that I also think that's the most difficult part of building a medical device, of developing a medical device. Because, you know, at the beginning, when you're starting to design, there's no controls, right? I mean, sort of by definition, you're starting off with a blank sheet of paper. I have actually seen organizations that sort of start controlling things from that point, but it doesn't work well.

It's just a disaster. But by the end the end obviously you need to have everything very much under control you know any small change needs to go through change review board and you know documented and all that so yeah how do you shift from one to the other and uh that's challenging and i think it depends on the different organizations and the engineers so sometimes engineers have a a good understanding of why that's a good thing. And I think generally speaking, no process works or no procedures or whatever you want to call it, overhead, works unless the people doing it absolutely understand why it's a good idea and why it's going to help them. So I think that's a big part of it, is helping people understand the larger picture and then working to get consensus as to how they're going to get there.

And also have management that, it's so important for management to understand you can't just do that overnight, right? For a lot of reasons, that's not good. So having the understanding that it's got to get done, but it's not going to get done in a day. And so you are in the prototype, make it work phase and haven't started the regulatory process yet.

Is that correct? You're talking about my work? For the Vox EEG. Oh, for the Vox EEG, yes, that's right. We're very much in the prototyping sort of proof of concept, you know, building something that we can, that some clinical researchers can start using and giving us feedback on, yes. Tell us about the system? Sure. Well well it turns out that building a system like this this is eegs are pretty low hanging fruit um because there is a there's

actually a few of these they're eegs on a chip right so the one we're using is uh made by texas instruments and it basically has everything you need for an EEG on a single chip, a single, very, very expensive chip. But still, it all works. And it's used by many of the large commercial EEG makers currently. So it's well-validated for its use. And besides that, really, you need a microcontroller, some electrical isolation, not a whole heck of a lot of other things. So right now we're in layout on sort of our first proto board. Actually, I'm sorry, we're in schematic.

We're not in layout yet. It's coming soon, I hope, which is going to be this TI chip, the ADS1299, of which I bought the last 10 from TI, because apparently there's a chip shortage. I've heard that. Yeah. Oh, man. Well, it's something. So I bought the last

10 from TI, and then I found 7 in the UK that should be showing up any day now. So it basically consists of that chip, and we're, that chip and a microcontroller. We're thinking to use the NRF 52480. 840. 840, thank you.

A little numerical dyslexia there. The 52840, which supports Bluetooth, although initially we're not looking which supports Bluetooth, although initially we're not looking to support Bluetooth, but we can if we want to. Rather than putting a chip down, we're looking to use, to start with, the Adafruit

NRF52840 feather board, feather sense, I think it's called, sort of as a carrier for that chip. And then put some isolation on it. So basically the microcontroller speaks, I think it's called, sort of as a carrier for that chip, and then put some isolation on it. So basically, the microcontroller speaks, I think it's SPI, to the ADS chip, and you need to put some electrical isolation in there, you know, somewhere before the patient. It'll be powered off the USB bus, so basically it'll be a little box that attaches via USB to a PC, and we'll have a Windows application on there.

Okay. So the Feather isn't FDA certified, but that's okay because this is the prototype phase. Yeah, it's kind of doubly okay. So it's, well, it may be doubly okay. So this is, we'll talk about medical devices a little bit. So for at the facility where they're going to be used. So typically the investigator will say to this investigational review board at the hospital, I want to do some research and hear the details of the research. And, you know, do you find that this is ethical to do and safe? And the IRB, you know, says yes or no. And typically they're going to look for just basic safety data. And I've built things that have gone through those IRBs before, and it's not proved difficult in the past. So that's one thing. So in terms of the FDA, everything's based on risk with the FDA in terms of medical device development or, you know, with the equivalent

bodies around the world. So to the degree that you can show that something doesn't pose a risk, you're okay, right? So there's no such thing as like FDA, well, I have seen things marketed as FDA or medical device grade components, but in reality, there's kind of not such a thing. It's really being able to demonstrate that, you know, if you use a feather board, it's, you're not using it in a way that, you know, it doesn't add undue risk, right? So there's some mitigation, you know, if it could potentially cause some problem that you have some sort of external mitigation that would prevent it from causing mischief. Yeah. And my understanding is you're certifying your whole system. And if your system includes common off-the-shelf parts, that's okay,

as long as you've certified them as part of your whole system. Similarly, I've shipped things that had ATI GPUs and DAC boards from various companies and common PC architecture stuff running them, and that was never an issue. And so running on the Windows isn't going to be an issue either. Right. The Windows. You'd be surprised. I'm sorry, go ahead.

I'm just wondering about Windows and how that is at FDA. Did that too, but I like to hear what he says. You and everybody else. Well, you'd be probably, most people are very, very surprised to hear that a lot of medical devices run on Windows. So a lot of bedside monitors and things like that. Yeah, it's actually very common to use as an operating system. And, you know, there are some, you know, Windows deserves some of the knocks it gets, but there are actually some good things about it that do make it reasonably suitable for medical device development. Now, I wouldn't want to use it for real-time safety-critical things, right? Or at least if I

did, I'd have some sort of backup system for mitigation, which is not uncommon, some sort of safety system to keep an eye on things and make sure things don't go nuts. But for most uses, Windows is actually fine fine it comes back to what you said about risk right yeah if you evaluate the risk and say this is mitigated then it's okay but if you're using this eeg to determine how deep someone is in anesthesia with the anesthesiologist if it blue screens or the nordic chip's operating system goes out to lunch and your data becomes trash, this seems important. Like you could give someone too much anesthesia or not enough. Yes, absolutely.

So one of the key things around risk for something like this is detectability. So if it goes belly up, it needs to be obvious to the doctor that it's gone belly up, right? Because you can certainly do anesthesia without a device like this. This is just helping you. So as long as they know whether it's working properly or not, you should be good. I mean, we haven't done our submission yet, so we don't know for sure. And we haven't gone through all the risk analysis, but that's typically true.

Because they've done, I guess they're doing anesthesia without EEGs all the time, right? That's, yeah. In fact, maybe 10%, at the maximum, 10% of them are done with EEG at this point. Okay.

But if it was cheap and it was easy, I could see relying on it. The worst question is if it's lying and it was easy, I could see relying on it. The worst question is if it's lying and they don't know. Yes. That goes back to my tip. Yes. Yeah, so Lisa, you bring up actually a very interesting topic the FDA is very interested in, right? So for a situation like this, where it's very rare to use a device, it's easier to make an argument that, well, they'll know if there's a problem. They're a medical professional, and they'll take action.

Once something becomes ubiquitous and people rely on it, that changes things a little bit. And the FDA, I think, has become more aware of that, that in theory, the doctor ought to be able to figure things out, but, you know, maybe they won't, right? Because they're just assuming this thing works. So that actually becomes an interesting issue, but that's kind of a high-class issue, I think, as you get closer to 100% market saturation with these devices, that'll become more of a thing.

So one of the ways to counter that would be to have the Windows program talk to the feather and say, are you okay? Is your data good? Are you sure? And then you know if the feather has gone out to lunch and is no longer taking valid data. And then for Windows, you could do something similar in that if you fail, you do put up the blue screen of death or you put up something that says catastrophic failure. Please leave me alone until this patient is off the table. Yeah, right. Or you could have the USB, you know, the front-end device that plugs in by USB.

That actually is going to have probably an OLED display, a small one. But that could start flashing and saying, hey, I'm not receiving responses from the Windows machine that I'm expecting to see. Actually, it's interesting. I'd say you spend more effort figuring out how to identify and deal with problems than you do creating the sort of positive functionality that you want in the device. And there's a lot of volunteer effort I was working on a what will hopefully be eventually an open source ventilator so people started working on that when COVID hit and those are actually

devilishly complex devices and can cause a lot of damage very quickly so one of the things that we worked on implementing was to have an FPGA that basically monitored what was going on you know we had a microcontroller uh controlling things and being doing sophisticated stuff and then we set up a sort of a small set of um uh rules that the FPGA could keep an eye you know things that the FPGA could keep an eye on and you know, things that the FPGA could keep an eye on. And if it ever saw deviations from those rules, it would just shut the system down, right?

So that way you have sort of a redundancy, at least, in making sure things are safe. I'm not sure you want to shut down the ventilator. Oh, actually, it's okay to, well, it's okay to shut it down as long as you shut it down safe. So in the case of a ventilator, for every ventilator that's running, there has to be a dedicated person, you know, a medical professional, a respiratory therapist or something,

actually viewing the patient in the ventilator. So in that case, it's actually okay to shut down as long as you, you know, don't pump compressed air into the patient when it shuts down and you allow them to exhale, right? It's definitely something you don't want compressed air into the patient when it shuts down, and you allow them to exhale. It's definitely something you don't want to have happen, but it's better than damaging something. That said, you could implement

what's called a limp-along mode, where it does some sort of small subset of functionality. But in that case, you still need the FPGA or something, some sort of safety system keeping an eye on things to make sure things don't go bad. Because software, I don't know if you're aware of this software has bugs sometimes it doesn't work not mine really i've never heard that before

because i didn't know that brains generate emf so what do i know yeah it's it's i mean your brain i hope your brain knows that it generates EMF. Otherwise, you know what I mean? I mean, EMF is electromotive force, right? Because my brain is not moving without me. I think it's a shorthand acronym for just electromagnetic radiation. Yeah. Okay, fine.

My brain radiates. If I ever go to the FCC, it will be an unintentional radiator. Well, actually you are. Yes. So back to the feather and the NRF 52 840. I looked at your readme and it was a little light on details for firmware and one of the things it said is that you'll be programming it in the Arduino language.

Now you've done it. Yeah, now you've done it. Arduino's not a language. Processing is sort of a language, but it's just C++ with some pretty bells and whistles. Processing? Wire. No, processing is... Is the Arduino language? Yeah. Processing? Wire. No, processing is...

Is the Arduino language? Yeah. Processing is something else. Processing is the thing you make pretty plotter diagrams with. Unless they both named it processing, which would be terrible. Oh, I think... Sorry.

You're right, actually. I thought that the Arduino... There's something involved with processing. Okay, so it's not an Arduino language. I'm going back to it's just C++ with some pretty bells and whistles. Well, so a couple of comments. One is that the discussion that you guys just had is actually exactly why I just called it Arduino. Because people know what that means. But, you. But referring to it otherwise can be confusing. In terms of it being C++, yes, it is. It's got some nice bells and whistles, but it's also got some ugly parts too, I think. So for

example, I don't believe you can do object-oriented programming in Arduino or processing or whatever we want to call it? No, you totally can. That's one of the great things about it is that you end up with these nice classes and objects so that if you wanted to use the accelerometer on the feather sensor that you're looking at, you just call accelerometer and then if you want to set up a callback to get data, it's pretty easy. It's very object-oriented because it treats each hardware peripheral as an object, which I think is a good way to think about object-oriented programming because I'm an embedded software engineer, and those are actually objects.

Wait a minute, you were talking and I just totally interrupted you. Go ahead. No, but so for example, on an Arduino, speaking Arduino or whatever we want to call it, could you, can you build a class? Oh yeah.

And inherit from that class. You can? Yeah. Yeah. Oh, okay. Well then I've been proven wrong. I apologize.

So. Oh, wait a minute. So there's the dot INO file, which is still a C++ file. Uh, it's just got... It's handled special. Header files are included when it's compiled.

But you can make a CPP file. And if you dig into the Adafruit libraries, those are all CPP files. And they're linked... Oh, yeah. I understand that. They're not linked together as a library and then parsed later. It's all just compiled to C++

and then C++ objects to a full image. Oh, right. Yeah, no, that part I understand, right? So you can jump into, you know, the.ino files.

I think they just get translated to CPP files and then they get compiled. Yeah. So that part I get. It's also true, though. So this is something I'm grappling with a little bit, and maybe you guys have some thoughts on this.

C++ is, how can I put this? It's very easy for people to do things with it that end up being bad things. Yes. This is resonating, yes. What do you mean? The underground volcano layer that I made in C++ is fine. What? Okay, that joke made sense in my head. Let's just go on.

Yes, in C++ you can make objects that call objects that you can't see and do some pretty interesting things that make a system confusing. And at least in most versions of C++ that aren't super new, they've added a lot of safety features to it, but C++ is still a descendant of C, which allows you to do whatever you want, which is often bad. Yes, let's point that thing at your foot and then fire it. Pointers. Oh, pointers. I love them, but yeah, I think 80% of debugging I've ever seen

has involved pointers. I guess one of the things that I grapple with a little bit is, if we're going to have a volunteer effort around developing the firmware, and more largely the software on the PC side as well. How much rope do we want to give volunteer developers to hang themselves? You know what I mean?

I do. And, I mean, this feather, you can run MicroPython instead, although that's another layer of something you'd have to watch. But MicroPython would make the code much easier to develop. That's interesting. I don't have experience with MicroPython,

but it sounds like you do. A little bit. I mean, it's Python, so it's pretty easy to modify. And as long as you have the drivers it isn't slow i don't know if there would be an eeg driver at this point uh probably somebody will tell me that yeah i guess i guess the question is it depends on what your volunteers are working on right if they're if they're working on low-level hardware interfacing

stuff then yes they're going to be probably using c or c plus plus and that's just the way life is if they're working on higher level stuff like signal processing then that can be abstracted away and done somewhere else and you can still do that in c or c plus plus by architecting the software in different ways and having, you know, things kind of protected against each other, which is harder to do on a microcontroller like an NRF, but I forget, is the NRF, it's a Cortex? M4. It's an M4.

I don't know if it has an MPU or not, but. It has a floating point acceleration. Yeah, but I was asking about the MPU, which is an option. Yeah, yeah, I get your concern. I don't know that there's a great answer. I mean, Python is a good answer if it could work, but I do have more concerns about performance there than Helio does. I have concerns about performance there.

Although at 256 samples for four or eight channels, that's probably okay. But the other EEGs that I was looking at here were like 20 hertz, and 20 hertz at eight samples, that's trivial. It's asleep for most of the time. Yeah. Yeah, that's more typical.

It's a lower sampling rate, but more channels, usually like 24, maybe 32 channels for standard EEGs. So, I mean, I guess my default would be... I mean, you wrote a whole article saying, don't use Arduino for professional work, and it might be time to... I still believe that for a number of reasons. One is that you are very likely to be including some GPL code or LGPL code, which just says that you have to make your compiled object available for other people to use in their code. But that doesn't apply here because it's open source anyway.

That is true. So, okay, I will stop arguing that. All right. Yeah. I mean, yeah. The other consideration here is that we want researchers to be able to muck with things, right? So by definition, that's why we're building this. We want them to be able to make changes they want to the code and do the research and then release this code to the rest of the world. And Arduino just seems like something that, just to take a step back, in a lot of ways, I'm not a fan of the Arduino platform.

Sort of in theory, I really shouldn't like it at all for a lot of reasons. But in practice, it just seems that it works with people, like it resonates with people, and it works for some reason, which I don't quite understand. I guess it's maybe just the right ease of use, safety. I'm not sure what it is, but somehow it just seems to be okay. So that's a consideration, too. You want something that end users can kind of muck with given, you know, that they're pretty intelligent end users, but they're not developers necessarily.

Okay. I mean, that's a really good argument for keeping at least the very top level in the Arduino INO format. That's also an argument for MicroPython because that's also an argument for micro python because that's that's really a set it and forget it sort of have a file and then you can do the underlying bits in c++ and even if you end up wanting to do FDA-style unit tests and hardware tests and even bring-up tests, you can do those either with a different INO

or with straight C++ the whole way through. Yeah, so I think whatever goes into the FDA will probably look significantly different in terms of the code, right? And that's sort of another challenge that we have is that – so I mentioned the challenge of needing significant capital to get into manufacturing, right, and to have some sort of organization that can actually go out and market and sell something. There's another challenge in that there's, you know, the amount of effort that's needed to get a device into researchers' hands through an IRB is a lot less effort and a lot less,

well, let's say a lot less effort than getting something put together that will clear FDA. So that's going to be quite a bit more work. getting something put together that will clear FDA. So that's going to be quite a bit more work. Not a horrific amount of work, but it looks different than what the process and the code is going to look like for research use. What does IRB mean? Institutional Review Board, I believe. And that just means that people can use it

for research, but they shouldn't be using it for health and safety. Yes, basically. So, every, sort of, any teaching hospital certainly has an IRB, right? Some group of people that vets

applications from people who want to do research, right? to make sure they're ethical and safe for the subjects. It's certainly helpful if you're FDA cleared. They have no questions about it at that point. But if you're not cleared, at least it's been my experience, that as long as you can demonstrate credibly that things are safe. Any investigator states that this will function and do what it's intended to do in their research, that's okay. But yeah, that's different than going through the FDA. That's a different process. And that's where the software starts to need that traceability matrix and where you start looking at the operating system, which the NRF52, if you run it with Nordic stuff and you do have BLE, that's going to have their operating system or Zephyr sure that the INO Magic Pixie Dust

is certifiable, except in a very different form. Well, it would come down to risk, but that said, my instinct is to not go with Arduino, anything Arduino for the

device, you know, the cleared device. I think whether, you know, the cleared device. I think whether, no matter how the risk works out, I think it's really harder to control Arduino-type stuff, because it's pretty much, it's mostly intended for hobbyist kind of work, so things can be a little patchy

as to how well things work, and this and that. One of my concerns is less about, like, can you certify this, but more about things like, from what I remember, they really want to know what versions of everything goes into your software is. And with Arduino, it kind of ramifies into this. So this library included this one, and we download it, and it'd be very, very difficult to document all of that and kind of lock it down to,

okay, we're, you know, version 1.6 of this particular Arduino spy driver. Yeah. Oh, you wouldn't do that. You would copy the spy driver into your subfolder, your INO subfolder, so that you had all of those files to commit into your subfolder, your INO subfolder, so that you had all of those files to commit into your version. Sure, but you'd want to know what those were in case you needed to recreate that. Yeah.

Yeah, anyway. Yeah, and then you can get into funky issues. This is an issue with Linux, actually, which probably is an issue with Arduino that I haven't thought through too much, where let's say in Linux land, you're using a certain version of the kernel, and then, you know, three years later,

there's some sort of nasty bug that gets caught in, well, within the kernel that'll get fixed in the kernel that's current at the time, but it won't get fixed in the kernel you're using, right? But then you have an obligation often to backport wherever that fix is and put it into your kernel, which becomes a hassle. And then you've got to think about all the dependencies

at that point and what's going on. So that can be very challenging. Yes. And there are companies that take care of that for you, but that's not always what you want to do, especially with an open source project. How are you going to make money? I don't know that we have the exact answer, but we have sort of thoughts about that. So our thought is that getting to the point where we've got a research device that's not gone through the FDA, that's something we can handle on our own. We actually got a little bit of money.

Brian has a little bit of a grant that we're working off of, and we are now being sponsored by a group called Helpful Engineering, which is a very interesting group. They exist to help open-source healthcare products. I think they're typically health- healthcare products. I think they're typically health-oriented products. So by helping them with financing and various

infrastructure kinds of things and process, I mean, I don't think we need too much help on the process side, but we could sure use help with money and legal stuff and marketing and all that kind of stuff. So that'll be very helpful. So I think we're good getting to the point where we could do some protoduction. I don't know if that's a term you've run into.

So basically building a small number of research devices to give out to people. The amount of effort involved is probably at the level that volunteers can sustain. So the cost shouldn't be very high. The next step, though, to build something that is a clinical EEG, that's going to require some significant money. So we're sort of grappling a little bit with how to do that. I mean, either we could say take Passover reference design and say, you know, I mean, reference designs aren't that difficult to do as long as they don't have to actually pass FDA. You know, pass it to a larger entity and figure out some, you know, we're also working on licensing to keep people from taking advantage of this, like big companies from stealing the design and just using it and making lots of money off of it. But somehow, you know, get another entity to do the, you know, complete the development, start manufacturing it through the FDA,

that kind of thing. Excuse me. Or we'd have to do that ourselves. And we'd have to raise, you know, a good chunk of money and pay people to do those things. Because those are things that I don't think you could have volunteers do. I just don't think that'll work. It requires too much effort.

We had some listener questions around what you were just talking about, which is how are you going to protect company assets and IP while open sourcing the project? Are you open sourcing the hardware, the software, the documents, everything? You said licensing, and I'm not sure how that would work with open sourcing. Yeah, so there's different open source licenses you can use, right? So one model would be something that basically says, hey, it's open source for, you know, you could do like a dual licensing thing, right?

You could say for non-commercial purposes, non-profit purposes, NGOs, governments, whatever, you can have it, good luck. And if you're a commercial entity, then you got to talk to us about it. And we haven't gone through the details of this. We've talked with an attorney who's actually pretty sharp about this stuff and sort of started to think about what's important to us. And then that would get turned into some sort of licensing scheme. In terms of what would be open, I mean, our intent certainly is to have all the hardware and software be open, at least to people who aren't looking to make a bajillion dollars off of this, right? So not-for-profit entities, countries, like say poorer countries or entities within poorer countries that want to serve those countries, that kind of thing.

So that will all be open and it's all going to be sitting on our repo and people will be able to use it. The thing that we're not as certain about is what happens in the next stage, right? If we're going to work with people, if there are going to be people who are going to manufacture this and commercialize it, or if we do that ourselves, right? What will that demand in the way of protection of intellectual property? So for sure, the electronics and software and probably mechanicals that gets actually a little interesting would be open source. The FDA documentation, I'm you know, we're not sure of right now because it would kind of depend on the way we proceed. I'm sure that's a very unsatisfying answer, but that's like I do right now? Because it would kind of depend on the way we proceed. I'm sure that's a very unsatisfying answer, but that's what I could do right now.

I mean, I understand. Although that would be amazing if you documented the entire regulatory approach, even from device classification. Why is this a class whatever, what is the trace matrix, this is the risk mitigations. I mean, you never get to see those things. Boy, it would be neat to be able to see them.

They'll certainly be there to some degree. One of the things that helpful engineering is very interested in doing is just what you're saying right they want to make this process open which we agree with highly so we'll be working with them they're actually going to um uh use our project to sort of help calibrate their processes and their processes are all open so a lot of that will be in there i think what is just a question mark in our minds is what this looks like when you, you know, when the design moves over to some entity that, you know, is well capitalized. There are investors in there somewhere who want some sort of return. The hope is to keep it as open as possible, but on the other hand, we'll need to do what we need to do to get this out there. So I don't have a 100% answer for you, other than a lot of it will be open because of helpful engineering. Are there prior examples of this kind of hybrid approach with a medical device being open? I don't know of too many. You mentioned the ventilators, which I think there were several attempts at that over the last couple of years.

And you worked on at least one of those. Do number of other people within our sort of hospital organization. So there's an organization now called Mass General Brigham, used to be Partners Healthcare, which includes Mass General Hospital, which I do a lot of work with, and Brigham and Women's and some other sort of Harvard fancy hospitals. So a group of us in that organization were working on a ventilator. We were trying to do something quickly, but not just a bag with, you know, a motor pumping it, which is what most of these other devices are. But then it became clear we didn't need all those ventilators right away. So we merged with another group called RespiroWorks, which is actually a really great group that was working

on their own ventilator. And they're in it for the long haul. So they're trying to build something that can go through the FDA and be a real medical device. And everything they're doing is open also, so people can certainly get on their Git repo or get onto their site. It's respiraworks, R-E-S-P-I-R-A-W-O-R-K-S.org, I think.

But beyond that, I don't—so those aren't systems that are working now, or that's not a system that's actually up and running. Well, they've got actually a very good prototype. I don't know of anything that's made it through the FDA that's open source. I think there's some software that's into the FDA. There's a group that's doing some software for diabetes management, and I forget, Tidepool or something maybe. And I think they're in FDA, but I don't think they've gotten out of FDA. And I don't know anybody else who's done that as open source. You're on the leading edge of figuring out this path. Yeah, and it's challenging.

Respira Works is on the Helpful Engineering website. Is that how you found them, or is that how you found Helpful Engineering? That's actually a very good question. I think I found them both back when we were working, and we called our ventilator Boston Vent, I think. And I was aware of both of them. And then when it became clear that there wasn't an enormous need for ventilators right away, like we originally thought there was when COVID hit, I contacted both of those to discuss, you know, it was clear that if ventilator development was going to continue, that it was going to be a much larger effort, right? Because we didn't need emergency devices that, you know, we needed devices that were going to be fully FDA cleared.

And that's a much, much different thing, much larger effort. So I wanted to talk to some people about banding together to support an effort like that. And that's how I found both of them. And I contacted both of them and got involved with both of them kind of separately, even though Resphere Works is sponsored by Helpful Engineering. I have a couple of listener questions that I'm going to use directly instead of paraphrasing. From Jakey Poo, have you ever tried to control something with your mind? My body is often controlled by my mind, but not all the time.

Why should you be better than the rest of us? He did clarify with EEG signals, not telekinesis. Although he didn't say anything about actually controlling your body. He did clarify with EEG signals, not telekinesis. Although he didn't say anything about actually controlling your body. Well, it's EEG signals. I guess EEG is derivative of other signals, so I guess I lose on that one. I have not. You've never tried one of the Neuralink or... Well, Neuralink is the one where they stick things into your brain.

Oh, no. I tried one of the how to meditate better by having lights that tell you if your brain is calm. I've seen video game controller interfaces with a brain thing that you can train yourself to do. Are those bunk? Yeah, I haven't used them. I have used the meditation. I've meditated with applications that

let you know how well that's working. So I have done that. But in terms of moving stuff, yeah, I've seen also the video game controllers that you can drive using EEG, but I have not tried them. Could this be adapted into a controller?

Sure. Obviously. All right. Seha asked about the unique challenges that are faced in designing embedded medical devices. And it's a broad question that we've kind of touched on in certain places, but I know it's kind of near and dear to your heart. So how would you describe the unique challenges faced when designing embedded medical devices? It's summed up 20 years and like, you know, maybe two minutes. You got a few minutes here.

Well, I'd say at the highest level, you know, you might say there's no unique challenges. I mean, I'm sure that's not true. But basically, it's just doing product development and really understanding what your constraints are and your requirements and not cutting corners. Because if you're building consumer products, typically it's easier to cut corners on things. You don't have a regulatory agency looking over your shoulder quite the way the FDA can. Although actually for a lot of consumer things, the lawsuit issue becomes big, right? If you cut corners and screw something up, you hurt a lot of people and you get sued for a lot of money. So in a lot of ways, it's not so much different. The ways it's different, well, one is the FDA.

You have to appease them as a stakeholder. They've got regulations that you need to actually understand and understand how to deal with. And then there's lots of standards, which is kind of secondary to dealing with the FDA or other agencies like that. A typical medical device, there's probably a dozen standards that you need to deal with. And for some, like ventilators or proton therapy systems, there's dozens of standards. So you really need to get comfortable with those standards and understand practically how to conform to them. The other thing I think is interesting is that everything's risk-based, as we discussed a little bit before. So that means, I guess, first of all, you need to really consider risk in the work that you're doing. So typically you need to do risk analysis before you

start working, then keep doing it while you're working. So it will help you to understand what you should be putting your efforts into. Because if you can show something's not a high risk, you could put effort into it, but it may not be as important as putting that effort in something that's higher risk. It also comes into play when you're designing something, and this is actually, I do this a reasonable amount, is if you understand sort of how to look at risk, it'll inform your decisions about architecture in particular, and it'll make things easier to de-risk, to take the risk out of, right? So for example, if you only have one subsystem in a system, if you can just get to the point where there's only one subsystem that can add a lot of risk, it's easier to mitigate that situation than if all your subsystems can add a lot of risk. Then you've got to mitigate all these subsystems, which becomes a lot more work.

So that kind of thing. And are you looking for volunteers to help with the Volks EEG project? Yes, absolutely. So it would be good to have somebody on the firmware side. We have, I think, an API defined, right? So basically the firmware is going to be, on the one side it's going to have USB, on the other side it's going to have the ADS-1299 chip. So there are actually existing libraries. A number of people have interfaced Arduinos, Teensies, and whatnot to ADS-1299s,

not at a level where they'd be okay for clinical use, but sort of as experiments. But because of that, there's software that exists that seems to do what we need. So it's basically we'd be porting it into this system. And then on the software side, on the PC side, I'm going to say another language that tends to draw out passions, C Sharp. I'm a big fan of C Sharp.

So it would be great to find a C Sharp developer, particularly somebody who's had some experience with graphics, because we're putting up real-time waveforms, although we have done a proof of concept on doing that in C Sharp, and it works pretty well. And if somebody wants to learn more about the medical regulatory part, is there a good way they can help on this project? That's a good question. Yeah, it would be useful. So in terms of the regulatory aspect, it's, you know, I think we know what to do, but it would be nice to have,

if there's somebody who's really interested in learning the regulatory side of this, who wanted to write up documentation and whatnot, that would certainly be welcome. All right. Alan, it's been really great to talk with you. Do you have any final thoughts for us? This is something I've wanted to do. So this is an idea I've had for about 20 years now to build open source medical devices because I think that there's a lot of great advantages to them. And if people go to our

Git repo, they'll see a little bit of a write-up about this. But I guess I would urge all engineers, but all people generally to, if you can try to figure out how to use your superpowers to help people out, even if it's on the side,

the world would be a better place. So go forth and make the world a better place. Our guest has been Alan Cohen, author of Prototype 2 Product, a practical guide for getting to market, and consultant in medical device development. He's co-founder of the Volks EEG project, and there will be links in the show notes. Thanks, Alan. Great. Thank you guys. Good to talk with you again. Thank you to Christopher for producing and co-hosting, and thank you for listening. You can always contact us at show at embedded.fm or hit the contact link on embedded.fm. And I don't really have a quote for you. Although looking at the helpful engineering website, their vision is pretty cool. They have a vision of a world where improved access to resources and opportunity increases

innovation, stability, and prosperity. It's a little markety, but I don't know. I could live in that world.