My Own Dreamboard: FRDM-KL25Z Motion Data Logger Using MBED

Introduction

Element14 has been running a competition for a DreamBoard and I was wondering how available some of the setups people are requesting are, to work this out I decided to do a simple project. The project goal was to use an ARM processor and incorporate a few sensors and store the data. After looking around I decided to go with the FRDM-KL25Z development board from Freescale and use the FRDM-STBC-AGM01 add on board. As there was no easy way to add an SD card I created my own board for that and at the same time added a battery monitoring circuit to make it a true stand alone unit. All the code was written using mbed to better feature the ARM processor on the FRDM-KL25Z.

Usage Case

The idea behind this project originated from two usage cases with essentially the same basic idea. As I work on equipment that needs to be ruggedized both from the elements as well as from handling, I thought what better way to understand what the equipment goes through than to log it. Its one thing to be told that something needs to stand up to rough handling and abuse but, if that abuse can be quantized it makes designing for the worst case that much easier. The second case and somewhat similar is shipping of fragile packages. It is possible to attach fragile stickers and shock sensitive glass vials but that would only tell you that a threshold force was reached but not for how long or how often or even when during transportation. An active motion logger would resolve all these unanswered questions. Both of these use cases would allow for the use of the FRDM-KL25Z with just one or two add on boards keeping the system simple and as close to a Dreamboard design as possible

Project Goal

Following these two usage cases mentioned above it was important to understand the main goals that this project setou to achieve. As both cases are looking at the handling of an object over a relatively short period of time (1 ~ 8 days) battery life was not critical, a custom battery/SD card board was built but that was mainly because it wasn't until later I found the Freedom Battery Charger Expansion Board. The custom board follows the design of the TI Fuel Gauge BoosterPack but with updated components. Another aspect of the project was price, as it is not known what the units are really exposed to in terms of  abuse, keeping the cost low would mean a damaged or destroyed logger would be no real concern in terms of replacement. Along the lines of a damaged or destroyed unit is the issue of data loss, should an event happen to cause a logger to be destroyed that event should, as much as possible, be recorded. Lastly the project should be implemented quickly and kept simple so that any issues that may arise or any requirement changes should be easily dealt with by anyone capable of understanding simple hardware/software.

Data Acquisition and Volume of Data

Looking to log data for 1 ~ 8 days without missing any abusive handling there was a need to establish how fast the system could sample data and store it without losing any of that data. It was decided by a pseudo scientific method that 50 Hz sample rate should be adequate. This was reached by assuming a falling object from one foot or so would take approximately 0.247s to fall, using 50 Hz would give approximately 10 data points on the way down allowing for an approximate drop height to be calculated as well as the force the unit experienced on impact (depending on the surface)

The accelerometer can log data in either 14 bits or 8 bits. Assuming higher resolution and therefore 14 bits that needs 6 bytes of data per sample or 300 bytes per second. The gyroscope also can log data in 8 or 16 bits and again using the higher resolution gives us 300 bytes per second. Since I2C can be set to run at 375 kHz, this would give a data transfer time of ~6.4ms. The I2C bus was eventually set at 400 kHz with a realistic clock frequency of 375 kHz.

Once acquired from the sensors, the data is stored on a SD card for later analysis.The SD card is written too using the SPI protocol which can achieve a theoretical 40 MHz. After some testing it was determined that the realistic speed for the FRDM-KL25Z programed using mbed was only 1 MHz, while very much slower than the 40 MHz desired it posed to be no issue for the setup. Using an 8Gb SD card the unit would be able to log data for ~154 days or well after the batteries are no longer working. This is estimated from 300 bytes/s for each sensor(8Gb / 600 bytes/s / 60s / 60m /24h = 154.32).

The battery life for this project is estimated to be 5 days using a 1200 mAh battery and the full power run current of 7.1 mA for the FRDM-KL25Z, 35 μA for the FXOS8700CQ sampling at 50 Hz and 2.7 mA for the FXAS21002CQR1. This gives a total current consumption of 9.835 mA and for a 1200 mAh battery that gives ~122 hours or ~5 days, if low power mode was implemented for the FRDM-KL25Z this could be further extended. This does not account for SD writes or other components on the boards.

Hardware Setup

The hardware consists of of three PCBs. The first board is the FRDM-KL25Z that contains the MKL25Z128VLK4 that is the brains behind the system and has the bootloader for the mbed environment.

Figure 2. FRDM-KL25Z Development Kit from Freescale

The second board is the FRDM-STBC-AGM01 this board houses the two sensors used in this project, the FXOS8700CQ is a 3 axis accelerometer and magnetometer and the FXAS21002CQR1 is a 3 axis gyroscope. The sensors both use the I2C and SPI protocols to communicate with the host processor. Since there are limited number of SPI modules on the host processor and the data rate of the sensors is relatively low the I2C module was selected. Another reason for this choice is the FRDM-STBC-AGM01 is configured for I2C and the the FXOS8700CQ only works with point to point SPI.

Figure 3. FRDM-STBC-AGM01 Sensor Board from Freescale

The last board is an SD card connector breakout board like the DIGILENT  PMODSD  PERIPHERAL MODULE or the MIDAS  UNO32-SD  DAUGHTER BOARD. The board used in setting up this project was a breakout board from 43oh which was replaced by a custom board* that was designed specifically for the FRDM-KL25Z.

Figure 4. Custom PCB Layout with Space for Both a SD Card & Battery Monitoring

The design of this boards borrows from the TI Fuel Gauge Boosterpack. The circuit is the same except for the BQ27510-G2 which has been upgraded to the G3. While the software for the BQ27510-G3 has not yet implemented when completed this will allow for the system to be truly stand alone and take precautions to ensure all data is saved before the battery is about to die.

Figure 5. Custom Board with SD Card & Battery Management Circuit

Figure 6. Custom Board with SD Card & Battery Management Circuit

While there is a expansion board from Freescale that has similar abilities, specifically the FRDM-BC3770-EVB, this board does not contain a SD Card slot and this board was only discovered after the custom board had be sent to the fab. The custom board includes both card detect and write protect pins to allowing the host controller to be sure there is an SD card available and in a usable state before starting the system.

Figure 7. System Implementation Using Three Separate Boards

Software Outline

The software was written in a simple and easy to understand style to allow for anyone wanting to read over the or modify the code to be able to do so. For this reason the code follows a very simple progression as will be outlined below. The code was written in the mbed environment allowing for further simplification, at each stage in the flow diagram for the software there is some code that demonstrates what is required at that stage of the software flow. The full program can be found in the mbed repository here.

This project uses interrupt driven programming, this means that all events in the main loop only happen after an interrupt routine has set a flag signaling for the main loop to take action. Both interrupts that are used are fired when a sensors has recorded a preset number of samples in its FIFOs. When the interrupt occurs it sets a flag letting the mainloop know that there is data to be fetched from that sensors FIFO.

Figure 8. Interrupts That Drive the System

The first step in the code is to include the two libraries that are needed, mbed.h adds the basic functionality for the chosen platform and SDFileSystem adds the functionality for writing data to the connected Sd card. Once the needed libraries have been added, the registers used by both the FXOS and FXAS sensors are defined, this allows us to keep later I2C calls simple and self explanatory. The next step is to initialize the needed system modules.

Looking at the flowchart below we see the first module that is initialized is the serial port. This port is mainly used for debugging as it is a relatively slow port and in mbed serial communication is a blocking operation, it is therefore not desirable to use the serial port during high speed data acquisition. I2C is initialized to enable communication with the sensors and at a later stage the battery monitoring IC as well. The I2C port used is port PTE pin 0 for the data line (SDA) and pin 1 for the the clock (SCL).

Setting up the interrupts is a two step process, first we set pins to be interrupts in this project, pins PTD4 and PTA5 are set as FIFO full interrupts from the two sensors. The second step with regards to interrupts is done in the main function and that is to assign what to interrupt on (high -> low or low -> high transitions) and when an interrupt occurs what function should be called. In this case both interrupts are happen on a rising edge and they call functions called fxas_data and fxos_data respectively.

The last step in the initialization before going into the main function is to set up the Sd card communication. This is done by creating a SDFileSystem object and then giving that object the pins used for MOSI,  MISO,  SCLK and CS. In this project the default SPI port was used, PTD2, PTD3, PTD1 and PTD0 respectively. It has been verified that it is possible to use other SPI ports but for simplicity only one is pointed out on the platform pin descriptions.

After the initializations are completed the I2C clock frequency and serial baud rate are increased to allow for faster communications and reduced interruptions. For this reason the SDFileSystem used in this project has been modified to increase the clock frequency to 1 MHz to prevent the system from losing data during a SD card write cycle. The next step is to create a directory on the SD card in which to place or data and a file with heading. The last step in the main functions initializations is to set up and start the sensors, this is done by calling fxas_init() and fxos_init(). Once all these steps have been completed the system will start logging data.

Figure 9. System Initialization

The main loop runs in the background and does all the heavy lifting. The first step in the main loop is to look for a FIFO full flag set in one of the two interrupts. Once a flag has been set the main loop will read all available data samples and store them in a local buffer. This buffer was arbitrarily set at 23, for better performance and possibly longer sleep times by the processor this could be set to 30 or 32 samples. When all the samples have been read from the sensor a data ready flag is set, this flag indicates to the next step of the main loop that data is ready to be sent to the SD card.

After data from both sensors has been read in, which should happen very close in time as both sensors are running at 50Hz, the main loop will send all available samples to the SD card. To do this correctly and in somewhat of a understandable fashion the MSB and LSB of each sample are concatenated before sending the data to the SD card. As the accelerometer data is 14 bits long and the LSB is left justified, there is a need to first shift the MSB left by 8 bits then OR the two bytes and finally right shift  all 16 bits by two to arrive at 14 bits of data. As fractional operations are  computationally heavy on microprocessors multiplying the data by either 0.976mg or 7.8125mdps has been left to be completed on the PC.

Once all data has been sent to the SD card the file is closed, this is done once every 30 cycles to ensure minimal amounts of data are lost. It is not done more frequently as this adds extra overhead to the SD write cycle. After closing the file the buffers are cleared, while not essential this was done to remove any question as to the correctness of the sampled data.

Figure 10. Main Loop Where the Time Consuming Operations Occur

The software in its entirety can be found here, the project can be added to your project space and then downloaded to your own FRDM-KL25Z from that location.

MBED

As part of this project was to show of the ARM core at the center of all the processing, the mbed environment was used. Along with showing of the ARM core mbed also allows for implementing programs in relatively simple and quick ways to be used as a prototype or in some circumstances for get to the final product quickly. While using mbed for this project I realized the ease with which other wise long and complex tasks can be achieved. Setting up interrupts and along with what action should be taken when fired only takes two lines. Similarly setting up the SD file system also takes two lines of code.

That being said there are some thing to watch out for. During this project I was not able to use the blue LED for debugging, this was discovered only after I was no longer able to save data to the SD card. It was later noticed that the SD card clock and the blue LED are on the same pin. Other issues where setting clock frequencies. The clock for the SPI but does not appear to be able to be set above 1 MHz, while I have tried a few different ways to reach this I was not able to do so. The same issue is noticed with the I2C bus, going above 375 kHz does not appear possible, I was hoping to achieve 400 kHz but setting the frequency higher only seems to decrease the clock frequency after a certain point.

Also not having a built in debugger when you are used to depending on one is a huge change in the game. Another big change that may take getting used to is the bootloader. Where with a conventional IDE there is a one step compile and program, here there is a two step compile and download and then drag and drop into the platform. While not a huge game changer it does slow down the programing iterations. Both of these may have bothered me but in a weird way I feel doing more programing like this would make you a better programmer as there is a need to do this better and in a more thought out manner the first time and less by trial and error.

With a few issues encountered along the way there is one very big positive to mbed. There is a large and very helpful community. No matter how big, small or subtle the issue I found that the community was both willing and very capable of helping.

Project Testing and Usage

The project while on a basic level is complete this is room for further progress. At this point there is a need to use the project to log how a package that is shipped is handled so as to better understand the design constraints to build a resilient outer shell.

In order to use this unit in a somewhat meaningful way the data obtained from this project is put through a graphing program to determine how the unit has handled. My program of choice is GNUPlot or Excel. While Excel has a limitation on the number of points it will plot for you (1048576) GNUPlot does not. Below I have included data samples from some test with this project to give an idea of what the project is capable of.

Figure 11. Accelerometer Data Recorded on a 15 Minute Drive

Figure 12. Gyroscope Data Recorded on a 15 Minute Drive

Issues experienced and their resolutions

Pin mapping and peripheral usage

FRDM-KL25Z not capturing Interrupts

Non-blocking interrupts

Arithmetic or Logical Shift in mbed

SDFile system working in standalone but not with other code

Logical operator frustrating me

FXAS21002 Not Generating Interrupts

Odd behaviour with F_STATUS register FXOS8700C

FXOS8700 data appears very noisy

*Rev A of the board is on branch Board_Inverted and not on the main branch at this point in time.

Original post on Element14 can be found here

Child Safety Seat Using the KEA-64 to Prevent Heat Stroke

Introduction

This past summer has been somewhat of a sad one. With this past summer not being particularly hot there was still an ongoing media presents of infant fatalities related to heat stroke due to these unfortunate children being left in cars. This past year alone in the USA there were approximately 30 fatalities due to heat stroke[1]. For some people and even the car companies this sounds like a small number and a number that does not warrant the need to invest any engineering resources, but for each of those children and parents or for someone who needs to deal with the aftermath, there may be a different view. For this reason I started thinking what would be an easy and simple way to help these children.

This graphic SIMULATED video gives an awfully real feeling of what a child goes through as they experience this horrible ordeal.

Issue & Resolution

It is known that the greenhouse effect is the major cause for a car heating to well above the outside temperatures. This happens when sunlight passes through the a window and strikes an object inside the car converting the sunlight to a longer wavelength that cannot escape thus increasing the temperature in the car.

Figure 1. Greenhouse Effect Causes a Car to Heat Up Quickly

A seemingly simple solution would then seem to be to break thermal seal allowing for the heat to escape and reducing the internal temperature. If the windows of the car could be opened then the temperature would not increase as fast and may even decrease. The objective behind this solution was to find an immediate low cost low complexity solution. Allowing strangers to help also seemed a reasonable option. This assumption was made due to the realization that in most cases where children were saved from extreme harm and even death, it was often a stranger that helped, so why not start with that as a part of the solution.

There have been other attempts to resolve this issue but they are usually complex solutions requiring a decent amount of infrastructure. As car companies are dealing in the millions of units, anything that adds even a 1¢ quickly adds to $10,000 over the manufacture of the product. While this may seem trivial, to a CEO and shareholders this is money no longer in their pockets and therefore lost revenue [2]. For this reason alone it is worth keeping the system to minimal cost input and try use systems already available in a car.

System Hardware

Freescale recently released their KEA family of ARM processors. These microcontrollers are made for automotive applications and therefore have specs that allow them to operate in the temperature range of -40 ℃ to 125 ℃ (-40 ℉ to 257 ℉). Using the KEA64 as a starting point a very simple and basic prototype was developed to see how well it performs, if the basics could be proven to work and show its reliability and safety than it would be worth attempting to incorporate such a system in an actual car.

Figure 2. TRK-KEA64 Development Board

Keeping to simplicity and minimalism the demo system is composed of only 4 components. These components are the KEA64, an ADT7420 and for the demo a stepper motor controlled by a ULN2003. Missing from the demo are pressure sensors used for child detection. The system operation follows a simple linear flow removing potential logic confusion or code errors.

Some extra hardware was used in this demo, but the basics of the system is already found in most modern cars today. While some extra coding may be needed, the overall system could be implemented with no additional hardware added by the car company. The addition of pressure sensors as well as communication from the car seat to the car could be added to the cost of the car seat removing this from automotive production cost. This no extra cost method may allow for more serious consideration and implementation by a manufacturer.

System Operational Model

The program in the KEA64 is interrupt driven allowing for simplicity as well as maximum power consumption. The flow of the program is outlined in figure 3 below.

Figure 3. System Flow Diagram

The system is initialized when the car is powered up (change of battery) or when the back door is opened. This is done to ensure whenever a child is in the back seat the system is in a known state. During initialization the ADT7420 is set to sample once per second and interrupt on a high temperature. Once initialization is completed the system goes into a low power state. The system will remain in this state until either the back door is opened at which point the system is reset or until a high temperature interrupt is fired.

If a a temperature interrupt is fired the system wakes to start doing a situation assessment. The first step taken is to check the car's internal temperature. This is done to prevent the system activating based on a false interrupt. Should the interrupt in fact be false the system is put back in power saving mode to once again await a temperature interrupt.

However, should it the system verify the cars internal temperature is high the system will then attempt to check if a child is present in the car. This is done by reading three pressure sensors fitted in the child's car seat. The sensors would be fitted to the bottom, the back and shoulder section of the seat. If a child is in fact in the seat and not something else 2 of the 3 sensors should indicate so. Using this method of two out of three the system would then assume a child is present  and move to the next step. This would involve opening the windows and monitoring the car for a reduction in temperature, if the car does not begin to cool the horn and flashers could be activated in an abnormal fashion to attract the attention of other people in the vicinity.

Figure 4. Locations of Pressure Sensors in Child Seat

If instead it is found that although the car is at a high temperature but there is no child present the system would disable the temperature interrupt and go back into a low power mode. The disabling of the interrupt is to prevent further false alarms until a child is possibly placed in the back seat. This would be determined by one of the rear doors opening. Once opened the system would once again reset itself starting the monitoring cycle anew.

Code for the above system can be found here

Initial Concerns and Solutions

When starting of the project one major issue that was a recurring concern among people consulted for this project was theft. There appeared to be a concern that if someone could somehow heat the car to the critical point, the windows would open and the car could be easily broken into. For this reason as well as others the need for sensors in the child seat to detect whether it is in fact a child present is crucial. In the initial attempt it has been assumed that a three sensor system would be sufficient. By placing a sensor in the seat, back and shoulder parts of the child seat it would be possible to determine if a child or something else is in the seat.

Another concerns was power consumption. While it is often assumed a car has a large battery that could not possibly drain easily this thinking needed to be reconsidered. The first issue pointed out was the other systems using power, each device added could easily tip the consumption scale causing  unsustainable power consumption . Another scenario is a car left for a long duration without being driven. In this case the battery has no chance to recharge and therefore if a car was left for several months the battery would be dead. For this reason the system is put into a low power state to reduce power consumption. The KEA64 when in run mode uses 6.7 mA (~2.25 Ah over 2 weeks) and 5.5 mA in WAIT mode (~1.85 Ah over 2 weeks). If the KEA64 is however in STOP mode the KEA64 only draws 145 µA (~48.7 mAh over 2 weeks) even with the ADT7420 sampling at 1 sps which has a current draw of only 65 µA (~21.5 mAh over 2 weeks) the total over a two week vacation would be 70.2mAh.

It is for this reason if an interrupt is fired and a child is deemed to be absent the interrupts are disabled. This prevents the system needing to wake each time the temperature gets above a set value when it is already known a child is not present.

System Testing

The system was tested at various stages during the project as well as upon completion. During the project a hair dryer was used to simulate high temperatures. While the whole system was not subjected to these elevated temperatures this method was sufficient to test the functionality of the system. Included in this testing was successive cycling to ensure such cases as a car being cooled by AC and than left to heat up and then cooled again would not negatively affect the system.

Upon completing this first stage the system was tested in thermal chamber. The chamber was set to 65 ℃ although the critical temperature is set to 50 ℃. This was done to speed up the testing since while the chamber may register 65 ℃ the air inside takes a while longer to reach the set temperature. Figure 5 below shows the thermal chamber as well as the system inside.

Figure 5. Thermal Chamber with System inside

Figure 6. System in Thermal Chamber Resting on Cardboard to Insulate the Two Systems

The full system test can be seen in the video below. As expected when the system reaches the critical temperature the “window” rolls down. The video shows this test being performed once but the actual test was completed several times to ensure repeatability.

While not shown in the video, this test was performed a few times in close succession again to ensure the system could handle a modest cycling of the surrounding temperature.

Figure 7. ULN2003 Arlington Array Used to Control the Stepper Motor

System Issues (KEA64)

During testing, with both the hair dryer as well as in the thermal chamber, it was noticed that the KEA64 had an unusual and unexpected behaviour at some points. This was evidenced by the LEDs turning on when nothing had happened. With the hair dryer this was witnessed when the hair dryer was initially turned on but not near the unit. In the oven, as can be seen in the video below, it happened when the oven was turned on.

It was not possible to reliably reproduce the issue with the hair dryer, however, with the thermal chamber it was reliably reproduced three times as seen in the above video. Each time the issue was reproduced, it was only when the chamber was turned on, having an initial large power draw, but never when the chamber was being turned off. The few times it did occur with the hair dryer it was also only when turning on the hair dryer.

While further testing needs to be conducted to better understand the issue, there are a few similarities between the two situations which leads to some initial thoughts. In both cases the power outlet is shared by the KEA64 system and either the hair dryer or thermal chamber. With the hair dryer the KEA64 was powered from a laptop that was sharing the same outlet and with the Thermal chamber the USB power supply was plugged in the same outlet as can be seen in figure 8. In the case of the hair dryer and the laptop it may be though that the power supply as well as the USB subsystem would shield the KEA64 from any negative power effects seen at the outlet. In the second case, with the thermal chamber and the USB charger, again it would be assumed that the charger would provide some form or isolation.  In both cases without proper testing the isolation can not be be guaranteed, perhaps in later testing a battery pack could be used to ensure complete isolation from the power mains.

Figure 8. KEA (Top Right) Plugged into Same Socket as the Thermal Chamber (Bottom Left)

These symptoms have led to the assumption that it is a power issue of some sort and related to the KEA64 and not the ADT7420 generating false interrupts. This is assumed because the motor does not run as it should if it was an interrupt generated falsely by the ADT7420. It is therefore assumed the KEA64 is susceptible to something either EMI or some power disturbance that is causing some bits to be flipped.

Figure 9. Power Supply Used to Power the System During Thermal Chamber Testing

Figure 10. LEDs on KEA64 Lit Showing Some Issue & the Breadboard Isolated from the Chamber with Cardboard

Moving Forward

The next steps for this project would be to attempt to control the windows in a car via the CAN bus. As these commands are not published this will require some reverse engineering. The CAN bus will be accessed via the OBD port as this is the the easiest and most convenient access point but this may provide other issues. Some ODB ports do not allow all messages to be transmitted to the CAN bus but rather only those needed for diagnostics. Another issue is controlling the windows when the car is off. In this case it would be needed to turn on the electronic subsystems of the car in order to power the windows. Each one of the issues pose their own challenges and will hopefully be dealt with to accomplish the end goal of this project.

Code

https://github.com/KazzL/Child-car-seat-to-prevent-heat-stroke

Footnotes

[1] http://www.kidsandcars.org/statistics.html

[2] http://www.reuters.com/article/2014/04/11/us-gm-recall-saturn-insight-idUSBREA3A1KJ20140411

Original post on Element14 can be found here