Hi! We're using this pressure sensor since some time and once in a while we have units returning weird altitude information (like altitudes over 14000 meters while we are at 350 above sea level). The sensor replies to all commands, and temperature information makes sense. It's just the altitude reported that makes no sense at all. Sensor is reset once before performing readings (polling used on a time basis longer than acquire time). Same software works perfectly on other units.
Could they be faulty sensors? How can we check if a sensor is working well?
Hey, Tomas!
I'm having the same issue with the barometers.
On one product I get 1 or 2 failures in a batch of 125, but on another I got 20 failures in a batch of 125. This has been going on since we switched to the MPL3115A2.
We've been through all of the rounds with the assembly house, and have seen the boards being processed. We even use leaded solder in our products, so the temperature peak is much lower than for unleaded. I've written firmware to use the on board I2C hardware of the uC, as well as some slow bit banging code. Always a high failure rate.
I've read all of the comments I can find and this is the only other person to admit to a high failure rate.
We have measured failed units at various altitudes with a vacuum pump and have noticed each failed unit appears to have gotten a fixed offset that tracks as it is brought to different altitudes.
We sent back many units to NXP when this first started and they said we had junk in our sensors. I took several new sensors from inventory and took photos with our microscope. Many had some junk in them. They appear as strands of possibly the same material you are using to coat the die. The failures have occurred with parts from several batch numbers.
The MPL3115A2 seems great for our application, but not at these failure rates.
Help!
Tom
Hi,
Are you able to log both the raw data from registers 0x01 – 0x03 and your calculated altitude values? Maybe the calculation fails to extend the sign-bit, so it wraps around to a very high number.
If you read out the pressure, what do you get?
It might be also a timing issue. Can you monitor the traffic on the I2C bus using an o-scope or a logic analyzer?
Regards,
Tomas
PS: If my answer helps to solve your question, please mark it as "Correct". Thank you.
Hi Tomas.
We're getting altitude data directly from the sensor (initialized to altitude mode, 8 samples data oversampling).
Set to pressure mode, the sensor returns 4161.75 Pa (OUT_P_MSB=0x04, OUT_P_CSB=0x10, OUT_P_LSB=0x72, result checked with spreadsheet MPL3115A2 - Output_Measurements_Calculator_v03).
Altitude data was also decoded with the same spreadsheet to be sure we're calculating it correct.
Again, temperature information makes sense, I2C communication seems fine as the sensor replies correctly to commands like WhoAmI. This is happening on just some sensors, boards and software are generally working correctly.
It seems that this sensor pressure transducer is not working, is there a way to recognize this by software? Or should we just check the readings and discards the sensors returning values out of range?
OUT_P_MSB | 4 |
OUT_P_CSB | 10 |
OUT_P_LSB | 72 |
Hi,
These values really do not make sense and may indicate some problems with the pressure transducer. Unlike other types of sensors (accelerometer, gyro), the MPL3115A2 does not have self-test capabilities, it only allows to check the I2C connection by reading the WHO_AM_I register.
I do have a few other questions. How many MPL3115A2 sensors have you tested so far and on how many of them you are observing this erroneous readings? How did you solder them? Is the output value of 4161.75 Pa constant or varies somehow in time? Where did you buy the sensors from?
Best regards,
Tomas
Yes, I can imagine being a problem with the transducer, and we would like to find a way to perform a test that would make us check if a sensor is reliable or not. If we get values in the operating range would be enough to accept a sensor for "good"?
Regarding your questions:
- We have tested about 200 boards with a fault rate around 10% (quite unusual). This is happening with this particular board while we're using the same sensor previously without any problem (I think less than 5 faulty sensor over about 1000 boards)
- We're staring investigating the soldering phase and see if we'll find out something unusual there
- Readings are almost stable around the value out of range
- We always got the sensors from Farnell in Italy
I hope you can suggest us a test we can use to check if a sensor is faulty or not, in the meantime I will check about the soldering and will let you know.
Thank you.
Hi,
I am confused about your description of the failure rate and occurence of this issue.
„This is happening with this particular board while we're using the same sensor previously without any problem“
What do you mean by „particular board“ and „the same sensor previously without any problem"? Please elaborate on it a bit more.
Best regards,
Tomas
Hi Tomas.
Following up my previous message, is there a document other than AN3484
and AN3150 being specific on soldering the MPL3115A2, with complete
temperature information and diagrams? Or should we just follow the JEDEC
STD. 020?
Thank you.
Hi,
There is no additional document, the MPL3115A2 fulfils the lead-free soldering requirements of the JEDEC J-STD-020D standard, i.e. reflow soldering with a peak temperature up to 260°C.
Best regards,
Tomas
Hi Tomas, sorry for being confusing.
By "board" I mean the PCB of this specific product. We're using this
sensor on other products we have designed and we don't have this kind of
problem on them. We're currently concentrating on identifying
manufacturing differences between this product and the others (company
assembling the electronics is the same).
Best regards.
Il 14/06/2016 11:38, TomasVaverka ha scritto:
>
NXP Community
<https://community.freescale.com/resources/statics/1000/35400-NXP-Community-Email-banner-600x75.jpg>
>
MPL3115A2 returning weird altitude info
reply from Tomas Vaverka
<https://community.nxp.com/people/TomasVaverka?et=watches.email.thread>
in /Sensors/ - View the full discussion
<https://community.nxp.com/message/672190?et=watches.email.thread#comment-672190>
>