A few months back I realized I was losing motivation for my work and feeling too mentally depleted after work to focus on any personal projects. I was organizing some books on my shelf and I found an old classic for me: “C Programming” by K.N King. I remember fondly when I first bought this book as a child. Anyway, not to get too sentimental, but scanning through some sections that I wasn’t totally confident in such as the oddities and peculiarities of preprocessor programming, I was struck with the realization that my lack of motivation stemmed from the stagnation of “on-my-own-time” learning and development (not just product development :p). Everything I had been learning over the months prior to the precipitation of this conclusion was out of necessity for my work.
I’d been doing small projects such as pipelining this servers build and routine maintenance, but I have this gnawing desire to work on something I had wanted to start working on since the beginning of this year. A distributed Bluetooth mesh data acquisition system. Something about ad-hoc networking is just so cool to me; couple that with very low energy requirements, size constraints, a necessity for synchronicity between devices, and that I am building most of the hardware and software from scratch I think it will be a very challenging and satisfying project!
First Steps
Yes, yes, requirements definition is important but I find this is usually where I lose momentum on personal projects. Using “agility” as my excuse I’ve just loosely defined some very broad and mostly non-functional requirements so I can start evaluating and selecting parts:
- Sensory input from PPG, ECG, accelerometer, and EDA data, would be nice, though PPG is preferable to ECG given the lower effort to attain a signal with a tolerable SNR when implemented in a wearable with dry electrodes.
- If ECG is available, users shouldn’t need to use wet electrodes if they are in optimal measurement conditions, though the option should be available.
- The acquisition start should ideally be synchronized to within 1ms. If a device looses connection with the mesh and fills its buffer it should be able to restart on reconnect and maintain the same standards for synchronization.
- The device itself should be as small as possible within reason. My thought is if I have something that is very small I can have it snap into different “carriers” that could be used to fix the device to different anatomical regions on the user.
- I think continuous BP would be very interesting. Because the potential for the introduction of significant error from a multitude of sources, I would need a robust scheme for detecting the introduction of error and correcting or indicating to the user that there is a greater margin for error.
This is all I have the stamina I have to write at the moment 🙂 but I would like to keep adding to this list. I am going to start adding some requirements to my “openproject” app so I can keep track of what needs doing throughout the development. I’ve already starting looking at the main components such as the BLE module and AFE to give me a better sense for what’s most economically feasible and will fit in the small space I would like the end-product to ideally occupy. Most importantly right now, is to choose parts that I will have some chance of purchasing. I’ve seen a lot of really interesting highly integrated and capable “wearable AFEs” come out very recently, so I am excited to more critically evaluate the capabilities of each one and come up with more ideas for their application. Availability will be a much larger determinant than I would ever want, but such is reality. I have a better sense for what direction I want to take this than I’ve laid out here, but I wanted to write a quick post on this so I can try to make it the norm for me to start coming up with ideas in writing rather than a disparate set of scribblings and mental images 🙂