Biohacking projects are not new to Hackaday and it’s certainly a genre that really piques our interest. Our latest biohacking device comes courtesy of [Manivannan] who brings his flavor of a wearable biosensor with some security elements built-in through AWS.
The hardware is composed of some impressive components we have seen. He has an AD8232 electrocardiogram front end, the MAX30102 integrated pulse oximeter IC for determining blood oxygen and heart rate, and the ever-popular LM35 for measuring body temperature. Either of these chips would be perfect for your next DIY biosensor project though you might try the MAX30205 body temperature sensor given its 0.1-degree Celsius accuracy. However, what really piqued our interest was the use of Microchip’s AVR-IoT WA Development Board. Now we’ve talked about this board before and also mentioned you could probably do all the same things with an ESP-device, but perhaps now we get to see the board a bit more in action.
[Manivannan] walks the reader through the board’s setup and everything looks to be pretty straightforward. He ultimately rigged together a very primitive dashboard for viewing all his vitals in real-time, demonstrating how you could put together your own patient dashboard for remote monitoring of vitals or other sensor signals. He emphasizes that all this is powered through AWS, giving him some added security layers that are critical for protecting his data from unwanted viewers.
Though [Manivannan’s] security implementation doesn’t rise to the standard of medical devices, maybe it will serve as a case study in the growing open-source medical device movement.
How is piping health data through AWS going to ADD security?
Given the recent track record of AWS, by making sure that fewer people are able to see it under any circumstance.
Well, they considered security and then decided to outsource it at the cost of privacy.
To add some evidence to my other co-commenters, I’d like to add some reference [1]. Yes, go ahead and let your life depend on that o.O
[1] https://ptrace.fefe.de/aws-error-500.png
I don’t want to be too negative, but unfortunately, the project is executed quite badly as well.
I’m not sure why, but there seems to be very little understanding of what the sensors do and how they actually work. The very badly organized code repository doesn’t help there either.
So, what’s the big deal here? Essentially, ECG values are sampled in some kind of best-effort way every 500 ms and then directly sent to the web-based frontend. This really indicates a fundamental lack of understanding on even the most basic properties of an ECG waveform. Even without knowing the biology or physics behind it, you really ought to know that the ECG measures some properties of your heart beat, i.e. you need to measure far quicker than your heart beats. Sampling once every 500 ms is laughable, as even with a heart rate of 50/min, slightly more than 2 sample points per heart beat is obviously not enough. Let’s not talk about the ungodly amount of jitter that’s introduced if you do sampling and transmission as part of the same routine, which would quickly become your biggest problem if you could manage to increase the sample rate to some value that affords actually digitizing the ECG waveform.
I’m honestly quite annoyed at these projects, as they show little care for the actual sensing task and are just a hidgepodge of stuff with some buzzwords or fancy technology strewn in for good measure. It’s totally okay to build a prototype or a demonstrator of how something could work, you don’t need to have something ready for manufacturing just to publish it. However, what annoys me to no end with this stuff is the way this is presented as some kind of tutorial on how to build such a thing. Even the obvious shortcomings aren’t properly discussed, if at all. I’d rather not have anything than badly executed projects; they pollute search results and teach people wrong approaches, which is quite damaging in the long run.
I know that HAD is always on the search for content, but I don’t think you should be promoting this kind of stuff that suffers from such obvious shortcomings. If this was presented as “how to get sensor data into AWS with a nice dashboard,” I’d be mostly okay with the bad sensor handling, but the way this is presented, it’s just rubbish.
Agree. This is garbage in, garbage out.
Wow. Is HaD starting to attract all the haters ? Instead of dumping on this project, why don’t you make your own ? Someone made something which is semi useful. Yes, it is not perfect, but instead of cribbing, why don’t you IMPROVE on it ? Even if it is not perfect, I am sure someone can find it useful. Getting so many sensors to work together in a nice portable package is amazing. Show me ANY other project which does something similar or STFU.
I think I explained why I think the project is ill-executed, thus the “all the haters” comment is a bit unfounded, don’t you think?
I made my own projects, but I don’t consider them to be good or interesting enough to serve as a reference on how something is done–in contrast to what the article is trying to do here, I might add. The article is written as though the proposed project was some kind of solution to a problem, but it doesn’t even adress sensor handling properly. I find this dangerous: If lacking approaches (and this is very generous, as I think the approach is just wrong) are presented prominently, without a discussion of their limitations, people might be inclined to use these approaches in their own projects without even considering that they might have some very obvious limitations. So you always need a reasonably proper discussion of the limitations of an approach, especially when presenting a ‘project’ to an audience that includes detailed information on how to imitate the project. That’s the fundamental objection I have against this: The shortcomings are never properly discussed, while at the same time, the scope and style of project documentation suggests something elaborate and complete enough to be shared in a way that allows people to easily replicate it. It’s not a work-in-progress, it’s a finished thing with video, project documentation and everything.
So on to your next point, improving on it. I don’t plan to and I don’t need to. The nice thing is that you can communicate about abstract concepts without having to implement them. Even if I hadn’t implemented an ECG data acquisition (which by chance I have in the past, but that’s not relevant here), I can posit from some general principles about measurement, data acquisition and data processing that the approach that’s taken here is just fundamentally flawed. It’s flawed in such a way that it should be blatantly obvious to anyone who has at least taken some time to figure out what the properties of an ECG signal are, and even reasonably obvious for someone who has a bit of experience or common sense with heart rates and microcontroller measurements. Which, I might add, the author of the project seems (or claims) to have, so I’m all the more confused. There may be good reasons, but they need to be properly discussed, which didn’t happen.
My big fear is that indeed, someone does find the project useful and applies all the bad ideas executed in it to other application domains. They are not so much at fault here, because seemingly working and complete projects automatically present themselves as good starting points for own development activities. However, this project is not working and this very fact is never discussed properly.
Your last point about the sensors is a bit a matter of perspective. There are 4 sensors there, but their cycle times are different, so handling of the sensors with long cycle times is offloaded to an auxilliary processor–a quite odd decision, I might add. Usually, it’s the other way round: You offload the timing-critical realtime tasks to an auxilliary processor, in this case the ECG data acquisition, and possibly some processing and filtering (neither implemented here), while the processor running the communication task can handle the occasional reading of the temperature sensor’s and the SpO2 sensor’s last value and check some accelerometer movement detection flag. Instead, the auxilliary microcontroller does all that and exposes this data via an I2C interface. However, since some authentication chip and the SpO2 sensor seem to share I2C addresses, an I2C multiplexer is used that connects either the SpO2 sensor or the main microcontroller to the auxilliary processor. While the SpO2 sensor is read, the auxilliary processor’s I2C bus is disconnected from the main processor and then there’s a period of a couple seconds where it is connected again. So now the auxilliary processor isn’t always reachable via I2C, which will completely ruin the timing of the main processor and necessitate error handling and recovery.
None of this is hinted at in the article, and even the much more sensible alternatives (I2C address remapping, bit-banging, other interfaces) aren’t discussed.
Sorry, this is just a very badly executed project that doesn’t work at all. Which wouldn’t be such a problem if it wasn’t presented as such, even giving completely pointless and wrong suggestions that this might be used for ECG monitoring during exercise, when it is obvious that it lacks performance to do so.