Back on track

Great weekend and lots done on the project. I have all the new sensors working and the streaming webpage data working as well.

Next weekend I’ll put this in the box and focus on local data failover.

Back to basics

Sometimes you have to start over a little. That’s what I did tonight. It was time to change the accelerometer and power inputs, so back to the breadboard I went…but only for a bit!..

Also, my new OLED from Adafruit is bad. Check out that I think the issue is:

Back at it

I was in Pittsburgh most of last week, so I haven’t had a chance to progress much on the project. I resumed today by 3D printing most of the parts for the next revision and working on the database logging. I have the initial flow of starting the recording and logging to the database.

My next advisor meeting is this Thursday. My plan is to have the Azure side nearly done and the basic Flask framework functioning.

The next steps are to have the local sqlite working to cache data and implement SocketIO for push data into the browser. I also plan to do some work with chart.js for the webpage.

Accelerometer fun!

In prototype #1 the accelerometer was analog. This worked fine until I decided I wanted to measure the battery life. I traded measuring battery life for the light sensor.

Fast forward and I started buying components for the four ‘production’ loggers and I couldn’t source the same analog accelerometer I had used. So, I moved to digital. Using this:.

In the end I get a better accelerometer, I retain my light sensor and have one analog input free!


I’m working more on the cloud database piece today and realized I needed more space than the allotted 32mb that is given with the Microsoft Imagine plan through the college. Seriously, 32mb?


I now have the RFID working. Currently it just scans a tag and displays it on the screen, but it works!


One of the things I don’t like about 3d printing is the surface finish. While I plan to try some things for the sides, the top and bottom are the roughest looking. My original plan was to laser cut some nylon and add it to the top and bottom. I did that this weekend and I actually hate it. The laser cut came out perfect, but I don’t like how it looks on the box.

So, my next adventure in 3d printing will be to try “ironing” whereby the top surface is dressed by the hot extruder tip. Fingers crossed….

Time Limited Peaking

Growing up a kid in the 80s, I spent a considerable amount of time in front of this cassette deck with headphones on. I was quite lucky to live in a household with an amazing stereo system. What does this have to do with my master’s project? Well, I was thinking today about how dataloggers work in the field. Most of them take a snapshot every x seconds and store it to a file for reference later. Some more advanced units keep a min, max for the duration of the logging. This is where the tape deck comes in…

The tape deck above had a florescent VU meter system that Pioneer called Fluoroscan. One of the features of the VU was to keep track of level peaking. Especially helpful during recording, the peaking indicators let the operator know how loud the signal ever got to tape. There were three modes, off, on and this mode where the peaking was reset every few seconds. It gave an idea of peaking for a short moment of time.

I’m not sure how I thought of this today, but I am going to implement the concept in my project. While the ADC is running in a loop on a separate thread, which is quite quick, the writes to the database will probably be only a few times a minute. Capturing the min and max is great because those could easily occur outside the capture window to the database, but time limited peaking will capture more of the ‘in the moment’ mins and maxes.

Here’s how it will work:. Every ADC cycle the output will be compared to a peakmin and peakmax value. If the value is to be updated (+/-), it will do so and flag a timer of, say 30 seconds. Any time that peak is exceeded, min or max, the timer is reset to 30. If the timer runs out, then the peak value is set to the current ADC value and the process starts over again.

I think the output analysis will be interesting to see, especially comparing to the snapshot output and the overall min/max.

ADC issues

The ADC I chose says that an input should never exceed VDD. Makes sense, but one thing I didn’t think about is when I am measuring a battery and I power the unit off. VDD goes to 0 volts, yet an analog pin has the battery voltage on it.

As a result I managed to damage one input of the ADC. This means prototype 1 will lack one axis of the accelerometer as I am now using one of those pins for the battery.

The fix was somewhat simple; I connected a transistor optocoupler to the battery and the ADC and I switch it using the watchdog output on the PI.

Battery life!

A quick update! The battery lasted a bit over 24 hours, which is perfect. Issue is the low battery light came on but the service did not power the system down?? I think I am going to change the way that functions and use the ADC to drive it. This way you can set a low voltage point and shutdown from there. I’ll do that tomorrow and try again.