The FXLN83XX is a 3-axis, low-power, low-g accelerometer along with a CMOS signal conditioning and control ASIC in a small 3 x 3 x 1 mm QFN package. The analog outputs for the X, Y, and Z axes are internally compensated for zero-g offset and sensitivity, and then buffered to the output pads. The outputs have a fixed 0 g offset of 0.75 V, irrespective of the VDD supply voltage. The bandwidth of the output signal for each axis may be independently set using external capacitors. The host can place the FXLN83XXQ into a low-current shutdown mode to conserve power. Here is a Render of the FXLN83XX Breakout Board downloaded from OSH park: Layout Design for this board: In the attachments section, you can find the Schematic Source File (SCH), Schematic PDF File, Layout Source File (BRD), Gerber Files (GTL, GBL, GTS, GBS, GTO, GBO, GKO, XLN) and BOM files.    If you're interested in more designs like this breakout board for other sensors, please go to Freescale Sensors Breakout Boards Designs – HOMEFreescale Sensors Breakout Boards Designs – HOME

Hi, The MMA865x, 3-axis, 10-bit/12-bit accelerometer that has industry leading performance in a small 2 x 2 x 1 mm DFN package. This accelerometer is packed with embedded functions that include flexible user-programmable options and two configurable interrupt pins. Overall power savings is achieved through inertial wake-up interrupt signals that monitor events and remain in a low-power mode during periods of inactivity. Here is a Render of the MMA865x Breakout- Board downloaded from OSH park: Layout Design for this board: In the attachments section, you can find the Schematic Source File (SCH), Schematic PDF File, Layout Source File (BRD), Gerber Files (GTL, GBL, GTS, GBS, GTO, GBO, GKO, XLN) and BOM files. If you're interested in more designs like this breakout board for other sensors, please go to Freescale Sensors Breakout Boards Designs – HOME

This presentation was given at the October 2014 ARM TechCon in Santa Clara, CA.  It provides a detailed description of recent changes to Freescale's sensor fusion offering.

  Unibody Package with Dual Side Ports_CASE_867C_05  

This is a PDF version of the Sensor Fusion tutorial I gave at the RoboBusiness conference in Santa Clara on 24 October.

Super Small Outline Package (SSOP) Case no. 1317A and 1317A-04 SSOP package offering robust media protection and small footprint.

You saw it here first! The attached zip file contains full documentation and source code (both CodeWarrior and KDS) for Version 5 of Freescale's Sensor Fusion Library for Kinetis MCUs. The 6 and 9-axis Kalman filters have been rewritten from scratch by fusion expert Mark Pedley.  The new versions have improved dynamic tracking and at-rest stability.  All documentation has been updated, and full implementation details are included.  We continue to use the BSD 3-clause software license, so you are virtually unlimited in how you use the library.   I will note that due to the Kalman filter changes, Mark made some changes to the undocumented Kalman filter packets which are utilized by the Windows Version of the Freescale Sensor Fusion Toolbox.  This breaks compatibility with older versions of the toolbox.  I will be posting a pre-release of the new one immediately after completing this post.  The Android version of the toolbox does not make use of the Kalman filter packet, and should be forward compatible - although an updated version of that is in the works as well.   Structure of the new library is very similar to Version 4.22, which was the previous production version.  There are changes, but I don't expect anyone to have problems adapting existing projects to the new version of the library.  I think you will get improved performance if you do.   Regards, Mike Stanley

Ever wondered about the pin styles for pressure sensors in their data sheets? Well then here are some useful notes. The difference between style 1 and style 2 in the package dimensions is due to the two main families of pressure sensors Freescale offers. Style 1 is usually applicable for all MPXx10, MPXx53 and MPXx2000-series SOP Type package pressure sensors featuring differential outputs. Style 2 is applicable for all MPXx4000-series, MPXx5000-series, MPXx6000-series, MPXx7000-series integrated devices in surface mount packages featuring single ended outputs. E.g. for MPXV7002DP case no. 1351-01 SMALL OUTLINE PACKAGE

System for environmental noise monitoring, with capacity of data storage at micro sd memory, option of wireless communication with computer and other systems to form a sensor network. This project consists on the design of a noise pollution level metering system, using a sound sensor board. Its value in the health area lies in prevents ear diseases and other conditions due noise pollution. The capability to create a sensor network, allows generating a statistical study, as well a more detailed study of the noise propagation patterns or the noise pollution source itself. The acknowledgment of the noise level enable to know the actions required to decrease this kind of pollution without expose human ear. It has several source codes: the main folder is that called "SSProyectoSonometro" which contains the three modes of operation. The other folder called "XbeePracticaDataSender" contains the source code for reception and sending data by Zigbee communication. The video has to be watched with the best quality that Youtube allows for a good viewing.

Our pressure sensors are designed to be used with clean, dry air only. However, most of our customers ran their own tests to determine if the response of the sensor would be appropriated for their specific applications. I personally ran a test with an MPXV5700AP directly exposed to car coolant @25°C and 100PSI, zero failure was detected for almost a month. See attached .xlsx for detailed information. The error of the sensor was calculated comparing the output of the sensor with a mechanical manometer, however this was only an approximation since the mechanical manometer was used as the "true pressure value". In this kind of applications, we would recommend to use Parker O-lube silicone grease or DMS-T46 or T51. This type of grease is used by most of our customer without problems. In fact the basic recommendations are to use a silicone oil (or preferably grease) with high viscosity and high molecular weight. In this case the size of the molecules are big enough to limit the penetration of the grease inside our protective silicone gel which is over the die. In terms of contaminants, the silicon grease must be free of halogenures (Cl content < 50 ppm) to reduce the risk of bond pad corrosion. On the other hand, don't forget that whatever the material you will use, as soon as you put something on our gel you have a high probability to see some offset drift. This is coming from additional mechanical stress and/or gel swelling. The amount of gel and global mechanical design are usually also part of the offset drift.

All, We are busily working to integrate Version 7.00 of the sensor fusion library into the Kinetis Expert (KEX) ecosystem.  ETA is early August.  I have attached here a preview copy of the user manual for that release.  This is subject to the usual disclaimers: content subject to change, no liability, yada yada yada.  There are a LOT of changes.    These are documented ad nauseum in the user guide.  I've also added a lot of our old blog content into the user guide, as I keep getting requests for them.  Please take a look and give me your feedback.   FYI, Here is a sample main() for the new fusion, running on FreeRTOS:   /* FreeRTOS kernel includes. */ #include "FreeRTOS.h" #include "task.h" #include "queue.h" #include "timers.h" #include "event_groups.h" // KSDK and ISSDK Headers #include "fsl_debug_console.h"  // KSDK header file for the debug interface #include "board.h"              // KSDK header file to define board configuration #include "pin_mux.h"            // KSDK header file for pin mux initialization functions #include "clock_config.h"       // KSDK header file for clock configuration #include "fsl_port.h"           // KSDK header file for Port I/O control #include "fsl_i2c.h"            // KSDK header file for I2C interfaces #include "Driver_I2C_SDK2.h"    // ISSDK header file for CMSIS I2C Driver #include "fxas21002.h"          // register address and bit field definitions #include "mpl3115.h"            // register address and bit field definitions #include "fxos8700.h"           // register address and bit field definitions // Sensor Fusion Headers #include "sensor_fusion.h"      // top level magCal and sensor fusion interfaces #include "control.h"           // Command/Streaming interface - application specific #include "status.h"            // Sta:tus indicator interface - application specific #include "drivers.h"           // NXP sensor drivers OR customer-supplied drivers // Global data structures SensorFusionGlobals sfg;                ///< This is the primary sensor fusion data structure ControlSubsystem controlSubsystem;      ///< used for serial communications StatusSubsystem statusSubsystem;        ///< provides visual (usually LED) status indicator PhysicalSensor sensors[3];              ///< This implementation uses three physical sensors EventGroupHandle_t event_group = NULL; static void read_task(void *pvParameters);              // FreeRTOS Task definition static void fusion_task(void *pvParameters);            // FreeRTOS Task definition /// This is a FreeRTOS (dual task) implementation of the NXP sensor fusion demo build. int main(void) {     ARM_DRIVER_I2C* I2Cdrv = &I2C_S_DRIVER_BLOCKING;       // defined in the <shield>.h file     BOARD_InitPins();                   // defined in pin_mux.c, initializes pkg pins     BOARD_BootClockRUN();               // defined in clock_config.c, initializes clocks     BOARD_InitDebugConsole();           // defined in board.c, initializes the OpenSDA port     I2Cdrv->Initialize(NULL);                                 // Initialize the KSDK driver for the I2C port     I2Cdrv->Control(ARM_I2C_BUS_SPEED, ARM_I2C_BUS_SPEED_FAST);      // Configure the I2C bus speed     initializeControlPort(&controlSubsystem);                           // configure pins and ports for the control sub-system     initializeStatusSubsystem(&statusSubsystem);                        // configure pins and ports for the status sub-system     initSensorFusionGlobals(&sfg, &statusSubsystem, &controlSubsystem); // Initialize sensor fusion structures     // "install" the sensors we will be using     sfg.installSensor(&sfg, &sensors[0], FXOS8700_I2C_ADDR, 1, (void*) I2Cdrv, FXOS8700_Init,  FXOS8700_Read);     sfg.installSensor(&sfg, &sensors[1], FXAS21002_I2C_ADDR, 1, (void*) I2Cdrv, FXAS21002_Init, FXAS21002_Read);     sfg.installSensor(&sfg, &sensors[2], MPL3115_I2C_ADDR, 2, (void*) I2Cdrv, MPL3115_Init, MPL3115_Read);     sfg.initializeFusionEngine(&sfg);         // This will initialize sensors and magnetic calibration     event_group = xEventGroupCreate();     xTaskCreate(read_task, "READ", configMINIMAL_STACK_SIZE, NULL, tskIDLE_PRIORITY + 2, NULL);     xTaskCreate(fusion_task, "FUSION", configMINIMAL_STACK_SIZE, NULL, tskIDLE_PRIORITY + 1, NULL);     sfg.setStatus(&sfg, NORMAL);                // If we got this far, let's set status state to NORMAL     vTaskStartScheduler();                      // Start the RTOS scheduler     sfg.setStatus(&sfg, HARD_FAULT);            // If we got this far, FreeRTOS does not have enough memory allocated     for (;;) ; } static void read_task(void *pvParameters) {     uint16_t i=0;                       // general counter variable     portTickType lastWakeTime;     const portTickType frequency = 1;   // tick counter runs at the read rate     lastWakeTime = xTaskGetTickCount();     while (1)     {         for (i=1; i<=OVERSAMPLE_RATE; i++) {             vTaskDelayUntil(&lastWakeTime, frequency);             sfg.readSensors(&sfg, i);              // Reads sensors, applies HAL and does averaging (if applicable)         }         xEventGroupSetBits(event_group, B0);     } } static void fusion_task(void *pvParameters) {     uint16_t i=0;  // general counter variable     while (1)     {         xEventGroupWaitBits(event_group,    /* The event group handle. */                             B0,             /* The bit pattern the event group is waiting for. */                             pdTRUE,         /* BIT_0 and BIT_4 will be cleared automatically. */                             pdFALSE,        /* Don't wait for both bits, either bit unblock task. */                             portMAX_DELAY); /* Block indefinitely to wait for the condition to be met. */         sfg.conditionSensorReadings(&sfg);  // magCal is run as part of this         sfg.runFusion(&sfg);                // Run the actual fusion algorithms         sfg.applyPerturbation(&sfg);        // apply debug perturbation (testing only)         sfg.loopcounter++;                  // The loop counter is used to "serialize" mag cal operations         i=i+1;         if (i>=4) {                         // Some status codes include a "blink" feature.  This loop                 i=0;                        // should cycle at least four times for that to operate correctly.                 sfg.updateStatus(&sfg);     // This is where pending status updates are made visible         }         sfg.queueStatus(&sfg, NORMAL);      // assume NORMAL status for next pass through the loop         sfg.pControlSubsystem->stream(&sfg, sUARTOutputBuffer);      // Send stream data to the Sensor Fusion Toolbox     } } /// \endcode

SOP Axial Port Package_482A-01

The MMA8491Q is a low voltage, 3-axis low-g accelerometer housed in a 3 mm x 3 mm QFN package. The device can accommodate two accelerometer configurations, acting as either a 45° tilt sensor or a digital output accelerometer with I2C bus.      • As a 45° Tilt Sensor, the MMA8491Q device offers extreme ease of implementation by using a single line output per axis.      • As a digital output accelerometer, the 14-bit ±8g accelerometer data can be read from the device with a 1 mg/LSB sensitivity. The extreme low power capabilities of the MMA8491Q will reduce the low data rate current consumption to less than 400 nA per Hz. Here is a Render of the MMA8491 Breakout Board downloaded from OSH park: Layout Design for this board: If you're interested in more designs like this breakout board for other sensors, please go to Freescale Sensors Breakout Boards Designs – HOME

        The FXTH87xx is a sensor for use in applications that monitor tire pressure and temperature. It contains the pressure and temperature sensors, an X-axis and a Z-axis accelerometer, a microcontroller, an LF receiver and an RF transmitter all within a single package.        Recently a customer requests help to connect FXTH87xx with Infineon TPMS receiver. We connect them each other through some testing and verification finally. The target of this document description is to replace external emitter with FXTH87xx. This document take an example to offer the users a method how to detect and decode an unknown sensor Emitter Packets using instrument provided by R&S or Anritsu, then duplicate this Emitter packets into FXTH87xx to form 315MHz, 433.92MHz TPMS emitter and receiver solution. Customer who adapts FXTH87xx can easily connect it with any external receiver using the similiar concept.

For those of you who do not have access to Google Play, here is the latest .apk file for the Android version of the Sensor Fusion Toolbox.  This version should trap problems which caused previously reported crashes.  There are no visible changes to the functionality.   IF you have access to Google Play, we recommend that you use that as your default installer, as you can automatically get updates.

The attached is a preview copy of build 422 of the sensor fusion library, which is currently being tested by the Freescale Sensor's team. Please consult the docs/Release_Notes.txt file for changes from build 420, as well as known errata. This version is released under the following license:   Freescale Sensor Fusion Library for Kinetis MCUs IMPORTANT. Read the following Freescale Software License Agreement (“Agreement”) completely.  By downloading this file, you indicate that you accept the terms of this Agreement and you also acknowledge that you have the authority, on behalf of your company, to bind your company to such terms.  You may then download or install the file. FREESCALE END-USER SOFTWARE LICENSE AGREEMENT Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:     * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.     * Redistributions in binary form must reproduce the above copyright  notice, this list of conditions and the following disclaimer in the  documentation and/or other materials provided with the distribution.     * Neither the name of Freescale Semiconductor, Inc. nor the  names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL FREESCALE SEMICONDUCTOR, INC. BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. © 2004-2014 Freescale Semiconductor, Inc. All rights reserved.

As requested in a prior posting...

This is the 9 December 2014 build of Vibration Monitoring program written by Mark Pedley in the Sensors Solutions Division systems/algorithms team.  It is compatible with Freescale FRDM-KL25Z/KL26Z/KL46Z/K64F Freedom development platforms.  You can flash your board using the File->Flash pull-down menu.    The application contains an option for controlling motor bias and feedback via optional motor control shield to be discussed in an upcoming Freescale blog.  Use the View->Motor Controls pull-down to enable those functions.

Hi Everyone, In my previous tutorial, I demonstrated how to import an ISSDK based example project into MCUXpresso IDE, build and run it on the Freedom board (FRDM-KL27Z). If you want to visualize/log sensor data, easily change sensor settings (ODR, Range, Power Mode) or directly read and write sensor registers, you can use the Freedom Sensor Toolbox-Community Edition (STB-CE) as described below or in the STBCEUG. 1. Connect the SDA port (J13) on the FRDM-KL27Z board to a USB port on your computer. 2. Open STB-CE GUI by double clicking the Freedom Sensor Toolbox (CE) shortcut located on your desktop. 3. Select "Out of Box Sensor Demonstration". 4. Select the Project to be launched and click on Continue. Base Board Name – FRDM-KL27Z Shield Board Name – OnBoard Project Name – MMA8451 Accelerometer Demo 5. The ISSDK-based MMA8451 Accelerometer Demo firmware is loaded to the KL27Z MCU and the MMA8451 Accelerometer Demo v1.0 GUI launched. 6. In the Main screen you can change basic MMA8451Q accelerometer settings (ODR, Range, Power Mode), enable embedded functions (Landsacpe/Portrait, Pulse/Tap, Freefall, Transient), start/stop accelerometer data streaming and/or logging.   7. The Register screen (MMA8451) provides low-level access (R/W) to the MMA8451Q registers along with a detailed description of the selected register. 8. To change the bit value, simply click on the corresponding cell (make sure you selected the Standby mode before writing a new value to the selected register). I hope you find this simple document useful. f there are any questions, please feel free to ask below.  Regards, Tomas

This this shows how to implement the power cycling feature described in Section 4.8, Fusion Standby mode, of the Version 7.00 Sensor Fusion User Guide.  It will power down the gyro when the board is stationary, and also suspend sensor fusion.   Last computed results continue to be sent until new motion is detected.  One nice side effect is that 6-axis yaw drift is almost eliminated.