It's been a while since my last update, I've taken a little break over new year, I did however find some time to write some code. It's pretty much all done bar managing the charging state and some power saving. I've taken my time to do this properly with a clean HPL layer and enough abstraction to make tuning easy.
The video shows a few different things, first the light coming on in vertical (rear light) mode after some 'movement'. Then it turns off after a timeout, with the lamp simulating daylight the light doesn't come on when it is shaken, similarly the leds would turn off under this light if they were already on. The second part shows the change in primary colour when the PCA is rotated 90 degrees, this is the orientation the light would be if it were mounted on the handlebars of the bike so it flashes white instead of red, there is a fair amount of hysteresis in this, I also use activity on the Z (longitudinal) axis to lock this function out so the are no ugly looking errant changes in mode. The third part shows the double-tap gesture to cycle between a number of flashing modes, there are quite a few, I think I'll cull them down to three or four in the end. There are other flashing modes for the 'front mounted' mode as well not shown in the vid, and of course in both cases the last flash mode is re-called when the light turns on or orientation is changed (a simple oversight you'll find in many flashing bike lights on the market). All of the motion sensing is triggered with a hard-wired interrupt from the ADXL345 running in a low-power, low-bandwidth mode, this way I'm making use of a bunch of it's internal sensing features and allowing for a lower duty cycle (read more sleep) in the PSoC.
For the purposes of the video I've overridden the hall sensor, so it is behaving as if it were mounted on the bike.
I've also shortened the timeouts to about 3 seconds, in production code these would be more like 60-100 seconds. In testing I've come across an interesting tuning dilemma, as a user I would probably find it acceptable for the light to come on for say 30 seconds in a dark room if the bike were 'bumped' but not for longer than that (meaning it's easy to turn on, and the timeout would likely be refreshing if say waiting at a stop light). On the flip side if the motion was severely 'de-bounced' as it were I would probably find it ok if the light took up to 20 seconds of movement to come on and then stayed on for longer than in the previous case (say long enough for a red light). Certainly the middle ground between these two scenarios wouldn't be acceptable, I think the answer is a hybrid of long de-bouncing to turn the light on initially, then have the timeout refresh more sensitive once the light is on. Some real world testing will reveal the balance pretty quickly I think.
The last stage of this project is to tick off the USB charging logic and run the stand-alone version of the dev board from the battery.
