Something To Aim At

My son has a Bruce Lee calendar in his room. This month, the calendar has the quote “A goal is not always meant to be reached. It often simply serves as something to aim at.” (http://lifehacker.com/5977645/a-goal-is-not-always-meant-to-be-reached-it-often-serves-simply-as-something-to-aim-at) As I mentioned in my last post, I have been reading up on Arduino programming. The book that I have been using has been “Exploring Arduino” by Jeremy Blum. In previous posts, I have been really focused on “pragmatic practices” and applying them to IoT and embedded software development. While I still really value TDD (test driven development), continuous integration and continuous (or at least “push button”) deployment, I have come to realize that it is helpful to have a pretty good understanding of the platform you are trying to be pragmatic about. Blum’s book has shown the light on several areas that I have had yet to explore with Arduino development, and I would like to work on those areas a bit. I almost achieved my goal in the previous posts. And, while my goal was something good to aim at, I am going to adjust my direction a little bit.

As I have worked on the pragmatic posts and my architecture (see below), I came across several interesting problems and/or roadblocks that ended up causing the architecture to change a bit.

In general, I was able to get all of this working, with the exception of one piece; dynamically programming an Arduino in the field by pushing data to the ESP8266 module. (Again, see the diagram above.) While this was a fairly minor part of the diagram, it was a pretty big part of what I was trying to accomplish. I may return to it later.  For now, I am going to move on and focus a bit more on the Arduino.

I have other motivation as well. Some time ago, I was fortunate to be able to work for a major medical device company here in Minnesota. I really enjoyed working at that company both as an employee and as a consultant. While I was on my trip, I had the chance to do some soul searching. I like the idea of trying to help people by working on innovations in the medical device and healthcare industries. I am going to revisit a topic that I was involved with the hope that it may lead to future opportunities in that space.

Also, while building out the above system, I started to discover that the cost involved with hosting the components of the server architecture (Jenkins, Artifactory, the app and the MySQL) in the Azure cloud was about $40/month. Again, as was the case with my AWS work, what I thought was free turned out to not be. I think this is an unfortunate practice of both Amazon and Microsoft. I am doing this as an educational exercise. I view it as a way to explore PaaS and SaaS platforms so that I might be able to recommend them at some later time for an actual business project that I work on. I think that there should be “development” version of these platforms that are free. For now, I will return to good ‘ol free Heroku. I know I can put an app up there and not be charged.

So, without further ado… Here is my next proposed topic:

I would like to build a heart rhythm monitor system (ECG) that is able to do the following things:

1. Capture a significant amount of heart rhythm data and save in some type of local storage.
2. Be able to have the device that captures the heart rhythm data transmit, on demand, that heart rhythm data up to a server.
3. Have a server that can collect heart rhythm data and save it in a database so it can be retrieved at a later time
4. Develop a simple web interface and a native mobile app (Android) that can access the data display waveforms that have been captured.

 

Here are a couple of givens, or assumptions that I am going to start working with.

1. The platform for capturing the ECG will be based on the Arduino, and the OLIMEX ECG Arduino shield.
2. The Arduino will use a local Micro SD card to save the data locally before it is uploaded to the server.
3. The Arduino will use an ESP8266 to transmit the data via Wi-Fi to a server where it will be persisted.
4. The server will be either a Ruby on Rails app or a Java (Spring Boot) web application running on Heroku.
5. The database will run on Heroku. It will likely be either Postgres or MySql.
6. The mobile app will be created with Android IDE.

The ultimate acceptance tests for this project will be for me to strap on the heart monitor, and go for a bike ride around the lake near my house. When I get home, I will then upload the data to the server. Lastly, I will use the web and Android app to view the waveform data.

Stay tuned for more updates as I progress on this little project.