Evaluation Kit for Freescale Xtrinsic Sensors - Review

Firstly Thank you to Element14 for allowing me the opportunity to do this road test. Secondly sorry for this road test review taking so long, I was planing on doing some testing with an environmental chamber and other interesting setups but after a few attempts to get access I have had to resort to other methods due to red tape and/or time.

First Impression

The package is is very much down to business, after opening the box you are greeted with a quick guide sheet that lets you get going very quickly, (I must note no anti-static bag for the kit). The driver needed to communicate with the sensors on the board are all installed on the board. Opening a serial terminal you are up and running immediately. I prefer to use AccessPort for my serial communications as I find it simple and reliable and the usual recommendation of hyperterm is no longer free.

Looking a bit further

At first I was a bit disturbed since I was hoping to evaluate these sensors to see if they were worth integrating in a later test board I have planned. Unfortunately I could not find them on Newark's site and this put a big damper in my plans, I have since checked and they ARE now available at Newark. I have noticed that some people had mentioned using this as a IMU for RC helicopters or other such devices that may not need very high accuracy positioning. For such a purpose I would have liked to see a gyroscope added just to help with the sensor fusion and error cancellation between sensors.

The Sensors

There are three sensors included on the eval board (and a fourth on the development board). The pre built application supports only the three on the sensor board. The sensors are the MAG3110 is a magnetometer, the MPL3115 which is an absolute pressure sensor and there is the MAA849 which is a accelerometer. The pressure sensor has been placed on the board closest to the signal lines, while I have seen no real effects of this I may have preferred to see this more isolated on the sensor board. The sensors are all evenly spaced and centered on the board, while this does look aesthetically pleasing it may not have been the best placement for the component requirements.

Testing

MAG3110 Data looks pretty consistent over a ~12 hour period for the x axis the y axis looks noisy and the z axis looks like it has three values. Since the numbers differences are only one value apart (ie 74 - 75 for z axis) I would not be to worried about using this for most of my applications or those that his sensor is designed for. I have done this test with a very basic form of shielding around the test board and had it near my laptop where the fan may come on periodically (I’m not sure if it did since I was sleeping). There were two considerations for night time testing, 1) less people moving around and 2) less sun activity. I am hoping to do a test at a later date to test repeatability. I would like to use LEGO Mindstorms to rotate the board 360° and take a measurement at each stop point. While this sounds like a good idea there are various obstacles to getting it done quickly and easily.

MPL3115 data at first worried me since it changes a lot over time. This worry was partly put to rest by looking at the atmospheric data for may area (using the two closest airports) and looking the air pressure trend over that same time duration. Since the MPL3115 displays altitude and there is a messy equation between pressure and altitude, I over simplified everything and just assumed they are inversely proportional to each other (no this does not work very well but for back of the envelope testing it seems to give a reasonable result). The worry that this over simplification did not dispel was the initial values, over the span of 5 or 10 minutes there is an altitude change of several feet, 15 - 25 in some cases. I am hoping to do a bit more investigation into this as this could really prevent the usability of such a sensor. If I have to wait 20 minutes for my sensor to stabilize (in which time atmospheric pressure is naturally changing as well) the whole idea of using this as a altimeter gets complex and messy).

MMA849 was the most complex to test and I really would prefer not to give this sensor a review since I don’t think I have done it any justice in testing it. I have been trying to contrive a setup (that is not to complex) that would allow for me to test the Zero point of this accelerometer, all I have come up with at this time is an air table (used for laser and high precision measurement experiments) but as of yet I have not found anyone willing to let me use theirs. I have thought of comparing it to another (industry proven accelerometer) but unless both are sufficiently fixed to the testing mount (a lot easier said than done) this would be an exercise in futility.

What I have attempted to do is sample data over time and then use a line of best fit to see how close it comes to the expected value. I have included just the Z axis graph as they are all pretty much the same (very noisy).

The offsets that I found for each axis are: x-axis -5mg, y-axis 10.93mg and z-axis 1036.4mg. while not very far from the expected values of zero and 1000, it must be remembered this is only after performing a line of best fit. By looking at the above graph it can be seen that the numbers are really all over the place.

I hope the above information helps those interested in these sensors. I hope to at some point if and when I get time to do further and more rigorous testing to get a better insight into at least two of the three sensors on this board. I will close with a quick pros and cons list, if you feel I have missed something or that I should maybe do something differently please let me know I would love to  really see what these things are capable of.

Pros:  

Easy to use

Fast setup

Easy to use output format (relative time stamp may have been helpful)

Cons:

Newark’s delivery time...  (from end of road test to shipping date could have been faster)

Not easy to manipulate parameters (change sample rates, output formats, etc.)

No access to out of the box application code

Overall

Good product to do fast and dirty testing to see if it is a part that could work for you and could use further testing in your application.

Original post on Element14 can be found here

Sensor Board Layout for our Rocket

This Time

In this blog post I plan to go over the board layout for the components chosen in the previous blog entry and explain the reason for the layout and placements that I have chosen. I was hoping to give an outline for the software but due to the stage in the design that will have to wait.

Figure 1. Almost Complete Board (No power routing)

Layout

I designed and laid out the board using Eagle and for this design I opted to make most of the  schematic symbols and footprints. I felt it would give me better knowledge of what was happening in the design. While this does take more time (especially when you read the data sheet incorrectly) it did help me have a better understanding of how to orientate components when working on the PCB layout. The main drive behind the layout was to reduce cross talk between signal traces and to have the smallest form factor. The first drive follows a recent seminar I attended in which the main message was, all traces should be treated as transmission lines and as much as possible all traces should be one dielectric from ground. After looking around, this simple message of “one dielectric from ground” is a very big and complex topic one that maybe in a future blog I will attempt to tackle.

In working with the second drive, component placement became a big issue and in this application there were two considerations. The first has to do with the type of sensors being used. There are three magnetometers (LSM9DS0, LSM303D, MAG3110) and according to Freescale’s app note, magnetometers should be placed as far as possible from signal and high current traces (due to electric currents producing magnetic fields). With this in mind a lot of time was spent trying to keep the three magnetometers somewhat isolated.

Figure 2. Magnetometers (yellow) separated from other components

The second consideration with placement and in some ways a conflicting requirement was to have a balanced PCB. Since the rocket will not be much larger than the PCB there is a concern that an uneven horizontal distribution may cause the rocket to be unstable. (Note: the physics have not been worked out nor is it known how fast the rocket rotates if at all wich may render this concern moot).

Figure 3. Attempting to balance the board to prevent the rocket from wobbling

As I am still in the layout phase, I will explain how the layout reached where it currently is and hopefully point out a few things I learnt along the way. It can be daunting opening the PCB layout after completing the schematic design.

Figure 4. PCB Layout after completing schematic

After going through countless sites, not one listed a good way to start your layout for anything more complex than four or five components. After trying various techniques the one that worked best was to group all main components (sensors, uC, etc.) with their secondary components (resistors, capacitors, etc) and then work with the groups. Once everything is grouped, moving the groups to reduce the number of crossing air wires between major components helps reduce later frustration. One very obvious but probably overlooked option is to move connections from one pin to another. Doing this may be some what tedious but in terms of layout and preventing traces from crossing eachother or needlessly being routed halfway around the board, this can make the final layout a lot simpler and cleaner. In my design I moved connections around multiple times helping to reduce the need for vias and potential cross talk.

Once major components are arranged the secondary components need to moved to ensure they  are where they need to be relative to the major component (some capacitors need to be connected to a specific pin, read the data sheets). Once secondary placement is completed anything that is left can be arranged to decrease crossing airwires. This whole process is an iterative process. For the current design, I have already done numerous times.

Figure 5. Original PCB layout proposed

Once component placement is complete everything needs to be connected. At this point the “one dielectric from ground rule” applies. Ensuring anything that has fast switching speeds (not clock speeds but transistor switching speeds) is closely coupled to ground can be a mission in itself.  A lot of time was spent ensuring as many signal lines as possible were closely coupled to ground to reduce any chance of cross talk or coupling between single lines. During this stage I still continued to move component groups and even swapping pin connections to achieve simpler routing. At times the simplest method to see how the routing would work was to route the connections and use the move tool to see how that trace could be best arranged. It may not be evident for the pictures but I have allowed enough space for the ground plane to fill most of the spaces between signal traces.

This may not always be easy but seeing as data transmission rates are increasing as are transistor switching speeds (this is one of the main causes for noise) if we don’t start now it will only be harder later.

One thing I did not mention was in the design phase I tried to always keep power sources as close to where it would be needed in a hurry. This is accomplished by putting bulk capacitors close to all sensors (yes this is in most reference designs) but not just for Vcc, if there is another power line that may have a sudden power draw, I have put one there as well. Keeping rapid long distance power demands low (using a local pool and letting that replenish slowly over time) helps to keep fluctuations on traces low decreasing noise. Along with each bulk capacitor there is a decoupling capacitor to reduce line noise.

Over all I have spent a few weeks getting to where I am now starting from a very general layout to moving each component group and switching pin connections as needed to finally having a layout that I am almost ready to have fabricated.

Hopefully all connections and footprints are correct and I will have a workable board first time round (really hoping)

Figure 6. Bigger view of current board

Original post on Element14 can be found here

Adding Sensors to Our Rocket

Hello all and welcome to my blog. In my blog I plan to look at sensors in interesting applications and how they can be tied with uC for processing or transmission to a remote location for other uses.

I am currently working with a student team from University of Waterloo on a rocket for an upcoming competition. Our team is currently working on a rocket for the 10,000 ft category and being an electrical engineer my sub team is responsible for the for the safe return of the rocket as well as telemetry acquisition and potentially ensuring the rocket does not overshoot the 10,000 ft mark by too much.

For this purpose we will have various sensors on board. We will attempt to use the on board sensors to determine parachute deployment altitude, max altitude obtained as well as projected altitude based on initial acceleration and current altitude. Due to the nature of the competition as well as the altitude of the rockets there are strict standards (at least by University standards) that need to be met. I have therefore taken upon myself to test various sensors with the aid of a toy rocket. This will provide some engine vibration/shock as well as a 10th to a 5th of the projected final altitude. There is also the always present possibility of a very hard landing that the sensors may also be subjected too. I have chosen one rocket for now but this may need to change as I reach the final hardware design.

The sensors I have chosen are three accelerometers, two gyroscopes, two magnetometers two pressure sensors and two temperature sensors. The reason for redundant sensors is so that one board can be made that will test the two best choices against each other. The “best” in this case means sensors that are easy to use and have the range and resolution that we felt would be acceptable for our application. To prevent too many sensors I have chosen only two of each (although some may be redundant by a built in function of another, temperature for example). I will briefly explain the sensors I have chosen.

Accelerometers

I have broken the accelerometers down into two groups one dealing with the beginning and end of the rocket's trajectory and two others for the middle (longer) part of the trajectory. This is due to the different force ranges that the different parts of the trajectory will display.

ADXL78 - Analog Devices single axis accelerometer has ±35g ±50g ±70g setting allowing for  initial and final stages of the rocket trajectory to be easily measured. This is an analog sensor, that has is sensor in the plane of the chip making mounting and placement very important.

ADXL362 - Analog Devices 3 axis accelerometer with ±2g ±4g ±8g settings. I personally like ADI even though their sensors are expensive but they are also known for their high quality. This has a sample rate of up to 400 Hz which will hopefully be enough to get the resolution needed for the application.

LIS3DH - ST Micro 3 axis accelerometer with setting ±2g ±4g ±8g ±16g. ST has cheaper sensors and it would be nice to put it against the Analog Devices sensor to see if there is any noticeable differences. The LIS3DH has a data rate of up to 5 kHz which may be helpful if the ADXL362 does not give enough data for the application.

Gyroscopes

Unlike the accelerometers I don’t foresee an extremely  high rotation rate on the rocket and therefore have only included two standard gyroscopes.

FXAS21000 - This is Freescale's gyroscope, while I have not used Freescale sensors before I have had them pitched to me. I figured I would try them out and see how they stack up to ST. This gyroscope is has sampling rates of ±200 °/s,  ±400 °/s,  ±800 °/s and ±1600 °/s which for the application should be more then enough.

L3GD20H - While I have not used this exact sensor before I have had experience with ST sensors (partly why they feature in every sensor group) and have found them pretty easy to work with. While they may not be at the level of ADI, for their price point they do offer a good product. This gyroscope is capable of sampling at ±245 °/s,  ±500 °/s and ±2000 °/s I hope to see what ST is capable of with this sensor.

Magnetometers

MAG3110 - Having had the chance to test this exact device (same with the pressure sensor below) in a recent road test and seeing (from preliminary testing) that it appears to have a pretty stable output, I thought I would test it in flight with all that comes with that. the sensitivity of this sensor is 0.01 µT and a has a full range of ±1000 µT.

LSM303D - Ulike the MAG3110 this magnetometer has a selectable range ±2, ±4, ±8 and ±12 gauss (1 gauss = 100 µT). The LSM303D also has a built in accelerometer with ranges of ±2g ±4g ±6g ±8g ±16g, I may try use this instead of the LIS3DH to help reduce the number components in the final design.

Pressure Sensors

MPL3115A2 - I had the fortune to test this in a recent road test and found it to be a reasonably good device and since other members of the team had liked some features of the sensor (altitude output) it became a necessity to test what the MPL3115 is capable of. This is an absolute pressure sensor which means that the outside pressure is compared to a vacuum pressure inside the device. this sensor range is 50 to 110 kPa (1 kilopascal = 10 millibars).

LPS331AP - With not too many pressure sensors on the market (Honeywell is expensive and as a company not easy to deal with) ST became the default sensor to compare against. This is also a absolute pressure sensor with a 260 to 1260 mbar absolute pressure range which fits nicely in the altitude/pressure range we expect to operate at.

Temperature sensors

With temperature sensors there is not much to talk about. I have chosen two in this case just to give a comparison. Again a lot of the other sensors have a temperature sensor built in and I will be looking to see if these two could be replaced by one or a few of the other built in temperature sensors.

ADT7310 - This is a SPI temperature sensor with a range of -40 °C to 105 °C and an accuracy of 0.5 °C. The ADT7310 has a 16 bit resolution and can be read in either continuous mode, one shot or at one sample per second. If a different read rate is needed a timer interrupt on the uC could be used to set the one shot read at the needed interval.

STLM20 - this is an analog sensor with a range of -55 °C to 130 °C but with a lower accuracy of only ±1.5 °C. For some applications this may be a bit of a wide variation but, for our application this will be well within the allowance for maintaining battery temperature and board temperature (our final goal is to fly in a desert). What is important is the delay time that the sensor may experience in reading the true temperature and the repeatability.

MicroController

The uC that I have chosen is the LM4F120H5QR (TM4C1233H6PM) by Texas Instruments. I have chosen it because I find TI easy to work with and a product that has lots of support. I also needed something faster than my usual MSP430 and with more I/Os. At the same time I am hoping to get more exposure to the ARM architecture and an easy to use RTOS.

Principal of operation

For this board the objective is simply to collect as much data as possible and to try verify which sensors perform the best for our application. Therefore the principle of operation here will be to try run either an RTOS that will service all the sensors and dump the data in different files on a SD card (or at least in a way that the different data can be pulled out) or to have an interrupt driven program that will retrieve the data from each sensor and store it to the SD card for later analysis.

This is a seemingly simple project, the difficulties lay in putting a relatively large number of sensors in a confined space (1.3” x 5”) and to connect them all with little to no cross talk. The payload area is currently 1.63”x10” which seems sufficient but with such a narrow board wiring becomes challenging. Another challenge will be to power everything from a small enough battery so as not to impede the rocket but also to allow for all devices on board to work at their close to peak performance. With standard engines I am not sure I will reach my 1500+ ft goal but maybe a few adjustments will allow for this to be possible.

Next time

Next time I plan to go over the board layout and explain the reason for the layout and placements that I have chosen. I also hope to give a better outline for the software operation.

Original post on Element14 can be found here