Creative Commons images are CC BY-NC-SA 3.0

12.95

added to your
shopping cart

quantity
In stock 68 in stock
12.95 1+ units
11.66 10+ units
10.36 100+ units

Description: Now mounted on a breakout board, the MPL115A1 is a digital barometer that uses MEMs technology to give accurate pressure measurements between 50kPa and 115kPa. We stock the SPI interface version of the sensor. Average current consumption is 10µA at one measurement per second.

The sensor outputs both temperature and pressure readings on the SPI bus. See page 3 of the datasheet for information on how to take readings from the pressure sensor.

Features:

  • Wide supply voltage range
  • -40°C to 105°C maximum temperature range
  • Low power consumption
  • kPa accuracy

Dimensions:

  • 5x3 mm (1.2mm height)

Documents:

Comments 14 comments

  • NEGATIVE TEMPERATURE ERROR?
    I can’t for the life of me work out how nobody has reported this?
    On my MPL115A1 device, when the temperature goes over 25 degrees c, the computeTemperature() function in all Arduino examples I have found) returns a negative temperature like “-12222.4 degrees. (and some people can’t understand why I hate ‘C’).
    The offending code is the last line of that function, where it computes the return value:
    return 25 + (uiTadc - 472) / -5.35;
    The error occurs because the Arduino processes ‘part’ of the above using integer arithmetic and when the ADC crosses the 472 constant the ‘sign’ inverts. The compiler is probably getting confused because ‘uiTadc’ is an unsigned int.
    THE FIX: Simply add a ”.0" (decimal point zero) after the 472 constant, this forces it to be computed as a float, so that when we multiply it by ‘-5.35’, ‘C’ doesn’t choke on it and sprurt out it’s breakfast. I also added additional brackets as shown below, though probably not needed.
    return 25 + ((uiTadc - 472.0) / -5.35);
    Once I did that, I got more stable results when below 25c and correct (i.e. positive) results above 25c.
    I found I needed to tweak the function to improve the accuracy. I calibrated it by printing out the ADC count (uiTadc) at two known temperatures, and with a simple Excel spreadsheet, I found the following was perfect for my chip:
    return 25 + ((uiTadc - 498.0) / -5.35);
    I’m running this on a Mega-2560, there may possibly be a bug in the Mega core which might explain why nobody has reported this already?
    Hope this saves somebody from ripping out their last few sprigs of hair, like I did!!!
    Cheers,
    Paul Taylor {Affordable Technology - Perth}

  • Here’s an example Arduino sketch for this device.
    http://forum.sparkfun.com/viewtopic.php?f=8&t=23965

  • The data sheet linked to above is a bit incomplete. The full data sheet is on Freescale’s website (I won’t link to it here, because who knows how long that will be valid).

  • I purchased this version and I am having trouble making it work (Talk) SPI. The chip has M1PR written on it. Does that actually translate to MPL115A1? The datasheet is not useful. Why not post a current one from freescale? http://cache.freescale.com/files/sensors/doc/data_sheet/MPL115A1.pdf?fsrch=1&sr=1

  • I have no idea how to program this thing. Are there any tutorials online? Something like this but for this particular sensor: http://arduino.cc/en/Tutorial/BarometricPressureSensor

  • Are the breakout pins on 0.100" centers? Thanks…

    • They are indeed. 99.9% of our products use this spacing (Nate once said that the only universal connector is an 0.1" header); if it’s different for some reason we try to be very clear about that.

  • Does anyone have an updated tutorial for using this device? The link provided isn’t working.

  • Miah- thanks for posting that example code, as I think most people here will agree that the C code provided with the product under ‘example code’ is pretty awful to read. However that link now appears to be dead. I have been unable to find a good Arduino example, even pure C would do fine as long as it’s readable. Anybody able to hook me up?

  • Thanks for the Neg temp fix - right on target. Saved me a lot o'grief…

    • return 25 + (uiTadc - 472) / -5.35;

      the line above is indicative of extremely poor coding. instead of a floating point division by a constant, that could have easily been turned into a multiplication saving some precious cycles. instead of dividing by (-5.35) the code should multiply by (-0.187).

      • The comment above is indicative of extremely poor development practices. Most compilers these days are good enough to automatically optimize things like that. Code is meant for humans to read. Legibility first. Avoid unnecessary optimizations (especially when the compiler does a better job than you can anyways), and only optimize based on measurements, not preemptively.

        • did i hit a nerve or something? you seem to have no clue how many hours programmers spend coding in assembly to ensure a higher degree of determinism because they cannot rely on the compiler to do the trick. the worst approach to embedded programming is to assume that “the compiler knows best and does a better job than ‘you’ can anyway”, and if you do not believe that just read a few lines how the compiler can get confused when you declare uiTadc as unsigned. in addition, this code is meant to be portable, you do not know what compiler people are gonna use, the “most compilers” approach does not cut it. code is meant for programmers to read, not for humans. when you code you would assume that your target audience is another programmer, unlike what your CS101 java teacher is preaching.

  • Can I use it as an altimeter? I need to open a parachute before my package crashes into the ground (need to interface it to an Arduino board)


Related Products