Skier impact monitor 02 - An overview

(Complete list of all blog entries in this series)

This week has been quiet so far. On Friday my PSoC4BLE board arrived (a BLE Pioneer Kit), but I had no time to play with it yet. Also I'm waiting for the kit to arrive so I can start looking at the accelerometers. But here is at least an image of the BLE Pioneer board:

(The small breakout on top of the base board is the one I will use. The dark board on the top right is a PRoC BLE board, the one on the left is the PC dongle used for communication)

Hardware

What I did in the mean time is to do some planning. First I looked at the data sheets of the involved components to get more information.

Accelerometer

From the three provided accelerometers, two are designed for high g values (up to 200g) so they look like what I need. The ADXL362 is rated for 8g maximum, so it might not what I need (OTOH it needs much less power than the ADXL377 and 375). So one of the first tasks is to find out what impact accelerations I need to handle. I might build a small wired prototype first which can be strapped to the ski helmet, so I can make some drop experiments with it.

MCU & power consumption

Next was looking at the current consumption of the planned components. The PSoC4BLE is rated as needing 1.7mA at 3MHz, 4mA at 12MHz and 13.4 at 48MHz active mode. In deep sleep mode its needing just 1.3µA. Receive and transmit currents for BLE are at about 20mA, but with a once-per-second connect interval, the average current is at about 19µA. When I assume I can get to 1:100 MCU core usage ration, the average MCU core current would be about 15µA. No too bad.

The accelerometers are more varying. The ADXL377 with its analog outputs runs at about 300µA, the ADXL375 (with SPI) varies between 35 and 145µA (depending on the data rate) and the low-g ADXL362 needs only 3µA (or even less in motion-activated sleep mode). I tend to use the ADXL375, which would give a total average current consumption of maybe 200µA. As a worst case scenario I would calculate with 1mA (when the MCU usage ration goes up to about 1:5). And the the maximum current the system could should draw is about 6mA (full MCU usage, ADXL375, and using many PSoC peripherals - but still only 1-per-second BLE connection).

Power supply

I'm plan to use a small LiIon rechargeable battery. For first tests this will be mobile phone battery I have laying around (about mAh), which is only a little bit larger that the PSoC4BLE board. For the final prototype this will be a 400mAh battery from Sparkfun. Even in the worst case scenario of continuous BLE receive and transmit it should give about 8 hours worth of power, any many days or even weeks in any other case.

That leaves me to the charging solution. I already have made good experiences with wireless charging (and I even participated in the Element14 challenge). So its a no-brainer to do that again. Unfortunately all the Qi-based solutions I could find use rather large receiver coils. So I will go with a solution from SeedStudio instead - its receiver is just 41x31mm. As charger I will use the LTC4054 - its small, and I have used it multiple times before.

User interface

I will design another small PCB with some capacitive buttons and LEDs on it. Its a bad idea to design a completely encapsulated system and then add physical buttons to it... Whether I need this for the final system is to be seen. For the prototype I will use it to get some feedback on the systems working, and to also control e.g. uploading monitor data to the connected phone.

JTAG / SWD

Speaking of encapsulation: For the first prototype I want to keep the capability to use a JTAG / SWD connection for programming. Instead of using a normal connector, I will probably use a system of spring-loaded pins (aka pogo-pins). The skier monitor gets 6 target header pins, which still should be water-tight. They will be encapsulated in the resin, but stick out at the front. Then I can use a matching spring-loaded connector to make a JTAG connection. To ensure JTAG will not get activated in case the case gets wet, I will add a TXB0104 (a level converter with two power rails) as precaution. It will activate the JTAG signals only when the JTAG adapter provides power on the connector.

Hardware diagram

So this leaves me with the following hardware blocks:

Software

The software should fullfil three main functions:

• monitoring
• alerts
• configuration / battery notification

Monitoring

Monitoring what has happened throughout the day is not a real-time activity. Its sufficient to upload the data once a day, or maybe once an hour if a paired device is available. So I will use kind of a RRD system to store recent data with a higher time resolution, but can also keep data for the whole day with reasonable memory consumption. A skiing day doesn't last longer than 8 hours, so thats my time target.

I will keep the acceleration values, maybe in aggregated form (see below). Optionally I might add the ADT7320 temperature sensor so I get an additional monitoring of that (software-wise I might even start with it, since 'temperature' is one of the provided BLE profiles).

Alerting

I want to get an immediate alert when the acceleration on the helmet reaches a critical value. That one should go out to any paired phone immediately, and start a audible notification there.

For calculating what a 'critical value' is, I will use the Head Injury Criterion which is used for assessing the safety of e.g. cars, but also sports equipment. The definition of that is

(from Wikipedia)

with a time interval of 3 up to 36 milli-seconds (typically its 15 ms). It measures not only the acceleration, but also how long it lasts (a really short, hard impact is not as worse as as longer impact with maybe half the force).

Monitoring this means to continually measure the acceleration, and to calculate the integral over the values in near realtime. So I should collect a value every milli-second - that also makes the calculation easier (hopefully). The accelerometers with digital interface fortunately have an internal FIFO buffer so I can do bulk-transfers.

Configuration / battery monitoring

I don't know how much configuration is needed for the monitoring. Maybe I need something for handling BLE pairing information. At least the app need to provide an alert when the battery in the monitor runs low.

Next steps

Since I will be on a business trip for the week, there won't be much progress. I hope to get at least some work with the BLE pioneer board done. Maybe I can start working on the phone software too.