Flavonoid — 5th Prototype
The 4th prototype used the DS1307 for the real-time clock and the AT24C1024 1M bit EEPROM for data storage, while the 5th version used the new DS32C35, which has a combination real-time clock and built-in 8k bytes FRAM for data storage. It saves space — the RTC doesn’t need an external crystal and I don’t need an extra chip for some kind of data storage. Also, the DS32C35 uses FRAM rather than EEPROM so its a bit more robust.
So, in terms of the overall design they’re pretty much identical, but in the implementation I save a bit of physical board space and drop the component count, which is good. It turns out that there wasn’t even much code that needed to be changed — the addresses and registers are pretty consistent between the DS1307 and DS32C35.
I created a control console for the Flavonoid to make it easier to configure and extract recorded data. This makes the device a bit more manipulable — you can adjust the parameters of the device, do some basic diagnostics and that sort of thing. This version also uses a different touch sensor than previous versions — an Analog Devices AD7150. I haven’t actually done much with the touch sensor. In fact, the early iterations of the v05 don’t even have the touch sensor on board yet. In fact, I had thought about not using one at all, but the touch interaction idiom seemed like something worth experimenting with. The original idea, way back, was that holding the device resulted in more power — this idea of creating designs of devices that enforce a sense of affinity, so that you want to keep them with you, nearby — touch and proximity are useful considerations in that regard.
There’s a procedure for uploading the Flavonoid recorded data that’s basically a simple Python script that extracts data over USB. It then uploads the data to the mothership which persists it in a simple data base structure. All the data is fairly transparent. The only weird part is that each “record” contains two floating point numbers that you can’t just eyeball — they’re represented as IEEE 754 numbers, which are four bytes long. Each record looks like this
0011223344556666666677777777
00 – One byte representing minutes (BCD encoded)
11 – One byte representing hours (BCD encoded)
22 – One byte representing day of week (7 – Saturday, 0 – Sunday
33 – One byte representing the calendar date (BCD encoded)
44 – One byte representing the month of the year (BCD encoded)
55 – One byte representing the year (BCD encoded)
66666666 – Four bytes representing a period cumulative sum-of-squares differences in acceleration (IEEE-754 encoded)
77777777 – Four bytes representing a period maximum recorded sum-of-squares differences in acceleration (IEEE-754 encoded)
For example:
MMHHDWDDMMYYAAAAAAAABBBBBBBB
The algorithm is roughly this: acceleration is recorded using 10 bit A2D conversion across each of the three real-world axes. Then there’s a 64ms delay. Then another three samples are taken. A difference is computed across each axis — so x2-x1 sort of thing. This all is done 10 times as quickly as possible, and a simple average is made of the computed values.
Values recorded are accumulated over the entire period. This is done as often as possible until the period time-out occurs. If the cumulative recorded values are above a threshold, then the data is captured and recorded. If the recorded values are not above the threshold, then the accumulated values are carried over into the next period.
The two variables you can control here are the threshold and the period length. The threshold is an integer that is 10 times the value above which the period accumulative total must exceed. The period is a number of possible BCD encoded periods in minutes, from 1,5,15,30 and 0 or 60 (top of the hour).
No comments yet.