This past week or so has produced some promising movement as well as some valuable learning experiences, I will outline these below.
ADXL362 Dead
As noted in Blog Entry 3, I have been working to get the SPI working in a useful and simple format. While working on this there were issues in determining if it was the code or the ADXL362 that was not working correctly. This is where the first lesson was learned, the true value of simple and cheap test equipment. By simply connecting the breakout board to a Bus Pirate ($30) it was a simple matter to determine that it was the breakout board (I assume the ADXL362 itself and not one of the caps) was no longer working. This simple test board paid for itself just in removing aggravation and showing where the issue truly lay.
While I thankfully I have another breakout board from a previous project I am still unsure as to why this breakout board has stopped working. The connections between a previous test and the test that appeared to break the board where the same. In fact the board had been working over night and only the next morning did the board give up the ghost. Maybe after the challenge is over I will see about determining the real issue and possibly replacing the ADXL362 on the board.
Getting SPI Working
This leads to the second valuable lesson, the true value of demo code. While the CC3100 uses the SPI module and works well and the datasheet for the MSP430F5529 is pretty well written there were still issue getting the SPI working correctly for the ADI devices. TI has demo code for all the modules on the MSP430F5529 which gives a good starting point to get your code up and running. Again, here the Bus Pirate came in handy, the ADXL362 registers were returning values that differed from the datasheet, particularly the REVID, XDATA and STATUS. This was lead be to be a bit uncertain with the code I had written. I therefore again used the Bus Pirate to verify the correctness of these values. It should be noted that for all of the SPI testing the Saleae Logic was used to read the values sent and received to the ADXL362. Although there is now a new version I have found this to be an indispensable piece of test equipment that now together with the Bus Pirate has saved many hours of debugging.
Another interesting lesson learned was time delays in the SPI protocol or at least with the ADXL362. During some debugging there appeared to be an issue that I thought a longer delay could resolve or at least shed some light on so the delay between sending and receiving data was increased to ~100 clock cycles (for i < 100). Once this was done the ADXL362 stopped responding. Using the Saleae Logic analyzer it was easy to see that the only difference was the timing, while no information could be seen ADXL362 datasheet and in theory the time between sending bytes to the device is not constrained the long durations (1.17 ms vs. 0.56 ms) was not liked by the ADXL362.
SPI Logic
The last issue encountered with the SPI module was using an inbuilt delay between sending or receiving multiple data bytes. Working from the CC3100 demo the code implemented was as follows
while (!(UCA0IFG & UCTXIFG));// USCI_A0 TX buffer ready?
UCA0TXBUF = 0xFF;// Transmit first character
while (UCB0IFG & UCRXIFG);← Logically useless….
RxData[j] = UCA0RXBUF;
Logically this does not make sense, according the the datasheet URXIFG = 0 when no interrupt pending, therefore in the above case as long as an interrupt is pending the code should remain in the while loop and NOT service the RXBUF. What should work but doesn't for some unknown reason is ”while (!(UCB0IFG & UCRXIFG));”. With this logic the program reads the RXBUF only once and then appears to freeze without spending too much time on it I was not able to find a root cause for this. I would assume that somehow when UCTXIFG is read and therefore cleared UCRXIFG is also being cleared.
While this appears to work for the CC3100 I can only assume that the time RXIFG never gets set in this case possibly because the RX happens at the same time as the TX. I have not checked the errata for the MSP430F5529 but will possibly do so at a later date.
Note: It just occured to me that the code actually reads UCB0IFG which includes BOTH UCTXIFG and UCRXIFG thereby clearing both of them. While I a not sure if this is correct appears somewhat plausible. The only issue is that the same code still works for the CC3100 with no apparent issues, but that may have something to do with timing and that the CS pin goes high between a Tx and RX in that case.
ADC
Work on the ADC has also begun this week. While the sample code does yield some results it has so far proven unreliable but a starting point nonetheless. For further testing to again check the response as well as to get a better understanding of the ADXL377 (high g analog accelerometer) was connected to an oscilloscope to check responses and behaviour of the device. As of yet there appears to be an issue hopefully with the oscilloscope as the understood response should be ~1.5 V at 0g - 1g which is not was displayed on the oscilloscope. The oscilloscope used has been showing some issues (NOT the oscilloscope provided with the SIC kit but one at work) so hopefully when I can make some space on my desk I will breakout the new oscilloscope and test the part with that.Hopefully with the new oscilloscope a clearer understanding of how the ADXL377 works will be achieved as well as how to better interpret its output.
Next Steps
The next major step is to get the ADC on the MSP430f5529 working so that all three channels of the ADXL377 can be read and possibly the three channels of the AD8232 (Heart Rate Monitor Front End) working as well. Once this has been completed and well tested both the SPI code and the ADC code will be integrated into the overall project code and tested to ensure no functionality in the project code has been lost or corrupted.
The past week has been spent trying to get a reliable SPI connection between the MSP430F5529 and the Analog Devices sensors as well as mapping pin connections for all devices needed for this project.
SPI Connection
The initial design plan was to use one SPI module for all SPI devices, this would include the CC3100 as well as the accelerometers and temperature sensor. The spi.c file was altered to allow for multiple device selects and all code was changed through the tcp_socket demo project. Once this was cleaned up and compiling with no issues the code was tested with the CC3100 and found to be working reliably. The next step was to attach a second SPI device.
At this point interesting things started to happen. When the ADXL362 was connected as it should be (MISO <->MISO, MOSI<->MOSI…) the CC3100 no longer worked, however, switching the connections (MISO <->MOSI, MOSI<->MISO) the CC3100 proceeded to work again. Using a logic analyzer it was clear the SPI was communicating in both cases but possibly not correctly (clock ticks were missed due to sampling rates of the old Saleae Logic) . It was also pretty clear from the sample data that the SPI frequency was set to 12 MHz. Once this was discovered and realizing it was not a hardware issue (verified using a Bus Pirate to talk to the ADXL362) the datasheet for the ADXL revealed the clock speed for the device MUST be between 1 MHz and 5 MHz (or 8 MHz depending on datasheet version). The Plan now is to write a new SPI driver for the ADI devices that will run at an acceptable clock rate for ALL the needed devices (ADXL362 1MHz - 5MHz, ADXL375 < 5 MHz, ADT3720 - Unknown). Once reliable communication has been established correct interpretation of input data will be worked out to enable proper interpretation and use of sensor data.
UART Code Removal
Also this week, time was spent removing code to control the CC3100 via UART. This was done to increase code readability and to remove possible confusion within the code. This was also done to help identify unused pins that may be used for the UART control of the CC3100. During this process the overall understanding of the code was greatly increased.
Pin Mapping
Since there was no clear indication of what pins were free, a quick code review was done to find all used pins and what they were used for. This was done to find all available pins and to correctly detail the used pins. As can be seen in the table below the CC3100 has a lot of pins broken out but only six are used. There are four for SPI, one for interrupts and one to enable and disable the CC3100, this excludes the 3.3 V rail and ground.
Once these were eliminated from the list six analog pins were selected, these would be set aside for the ADXL377 and time permitting the heart rate monitor. These were chosen next as there are only a limited number of analog pins on the MSP430F5529 and it was preferable to try have them consecutively numbered to potentially allow for easier programing.
Once the analog pins were selected the SPI for the ADI devices and their chip selects were chosen. All pins assigned so far can be seen in the table below.
Table 1. Pin Mapping For MSP430F5529 & CC3100
Next Steps
This coming week will be spent getting all SPI devices working correctly and reporting back some data (Device ID) and formatting that data correctly. Once the SPI modules are working correctly and their data is correctly interpreted the ADC module will be attempted.
It may be obvious by now, but the user interface has been neglected at this point due to complexity in the learning curve for QT. For now data will either be sent to plot.ly for plotting at a decimated rate or logged on a local computer in a not athsetic interfcae, something like a terminal.
Its been a while since my last update. In this time I have received the contest kit, which I will outline below, and outline a basic approach to move forward taking into account the short period of time left for this project. There has also been some analysis done on data rates and possible data representation for end users.
Kit Outline
The kit came with everything as expected. One big Tektronix box with the oscilloscope, four brown boxes one each with the AD8232 breakout board, evaluation kits for the ADXL375, ADXL362 and with the ADuCM350 development kit. Lastly there was the ADT7320 flex board and the ADXL377, ADXL375 and ADXL362 breakotboards. All the break boards were well sized to include just main components with its needed external components as well as space for a through hole connector. Opening everything at once was rather overwhelming. At this point it was decided a plan was needed to move forward, the previous one step at a time and hope it all works was not going to work.
Project Outline
Looking at what parts there where, their complexity to use and the project duration an outline was formed. As there is no way to use this project fully without a user interface (maybe a flashing LED in case of severe injury…) this was determined to be the first step. It allows for parts delays and other unforeseen issues to carry on while work moves forward. For the interface I have decided to use QT due to its apparent simplicity as well as due to the easily available help I have due to its use in my work place.
While I work on the interface there is the need for the embedded code to move forward as well. For this an MSP430F5529 will be used for two reasons. Firstly it integrates easily with the CC3100 that will be used to transmit the data back to the PC. Secondly it is relatively easy to use and with only two months to complete the project using a controller and IDE that is known will help save precious time. Unfortunately do this this choice the possibility of using the heart rate monitor may be reduced do to the abilities of the MSP430F5529. During this time all code will be written in a hardware independent nature so as to allow for switching the controller at a later date should the possibility arise.
Keeping the available time frame in mind the sensor choice has also been reduced. The system will start with just the two high g accelerometers and a temperature sensor. This will allow for a basic system to help iron out the basic bugs. Also as these sensors do not need any intense calculations to get them up and running their data will be useful to test and work out any bugs in the WiFi connection as well as in the the user interface. One main aspect that will be attempted will be to have a hardware abstraction layer to allow for the overall system to be ported to a separate microcontroller at a later stage should time permit,
System Capabilities
Looking over the system there was a clear need for a single wireless connection that could handle all the data. A quick calculation was done to determine what bandwidth was needed in order to allow for a better choice of wireless protocol.
Figure 1. Data Flow & Data Rates as Data Moves through the System
At the above calculated data rate of 264 kbps there was no real choice other than WiFi. While for a single player or even two players other options may be possible, for a full team the data rate quickly climbs above 1Mbps and only WiFi has a practical data rate above 3Mbps. While in theory the WiFi can handle the data rates for a team of players it is unclear at this point if the range needed to cover a hockey rink is possible. As the design moves forward this will be tested and hopefully resolved.
Basic Sensor Fusion
Due to both the relatively high data rate needed as well as the need to verify data values using redundant data the system will incorporate a very basic form of sensor fusion. To reduce noise in the system only shocks above a predetermined threshold will be registered. The accelerometer data will be combined to using an as yet undetermined algorithm (potentially simple averaging will produce sufficient results). This single result will be relayed back to the PC helping to reduce the required bandwidth as well as presenting the end user with only easy to understand data. In the first iteration there will be only one temperature sensor but there is a hope to add a second sensor. Having two sensors positioned on the temples will allow for a easy averaging and easily averaged results that should yield a consistent and repeatable body temperature.
Figure 2. Simple Representation of How Data Will Be Merged in the System
User interface
The other aspect of the design that has been looked at and has been started is the user interface. The concept is to have an uncluttered easy to read and understand interface that allows for anyone to quickly understand the situation of a player. For this reason there is both a text based output as well as a graph based output. These together allow for both an immediate situational understanding as well as a context to be added to the current situation to help understand the whole situation. For now there is no method for looking at more than one players information but the hope is to add in tabs or a drop down menu to allow a user to select an individual player to view in detail. Also in order to allow for a coach to quickly identify an issue even if the coach is not viewing a the information of a player who may be in trouble that players tab will flash yellow or red depending on the severity of the situation, there may be the potential to rather automaticly switch tabs so immediately the coach could see the relevant information.
Figure 3. Simple User Interface Displaying All the Relevant Data in an Easy to Understand Format
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.
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 steppermotor 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.
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
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.
.jpg){kind=spacer}
.jpg)
