• I am getting some odd reading from this sensor using the Espruino module (https://www.espruino.com/MPL3115A2).

    When I run the example code, I get these reading:

    Pressure 442.25 pa
    Altitude 110.125 m
    Temperature 17.6875 C
    

    If I run the sam sensor hooked to an Arduino board, I get these readings:

    100158.25 P
    97.50 M
    15.69 C
    

    The Arduino readings seem to be correct.

    Any ideas?

  • ...I expect both are writing/reading to/from I2C address 0x60?

    ...could be some timing issue... since it/example interferes w/ upload.

    Put code in the onInit(){ ... } function and add this as last line (do plain upload w/o save()):

    setTimeout(onInit,999);
    

    It's a bad practice in Espruino to make (more complex initialization and communication code execute while upload is still going on...

    ...and pls share all code since we do not all your setup... (I just assumed it is invoked while upload is still going on).

  • I am delaying the code. Here is what I have. There is also a display hooked up.

    var i2c = new I2C();
    I2C1.setup({scl: D20, sda: D22});
    i2c.setup({sda:D30,scl:D29});
    var mpl = require("MPL3115A2").connect(i2c);
    var lcd = require("HD44780").connectI2C(I2C1, 0x3F);
    
    lcd.setCursor(0, 0);
    lcd.print("Starting...");
    
    setTimeout(() => {
      setInterval(() => {
        mpl.getPressure(function(x) {
          console.log("Pressure "+x+" pa");
          mpl.getAltitude(function(x) {
            console.log("Altitude "+x+" m");
              mpl.getTemperature(function(x) {
              console.log("Temperature "+x+" C");
            });
          });
        });
      }, 5000);
    }, 1000);
    
  • @calebbrewer

    see nothing glaring... and the deferring is about 6 seconds in total for the first call. Had a quick glance at the module and it seems to handle busy states of the sensor. Going for a single item read for figuring out the issue could be helpful, though.

    I assume you can see the "Starting..." on your HD44780 driven LCD.

    Could it be a power issue? The chip itself accepts - if directly connected - 1.95 V to 3.6 V (internally regulated by LDO) and 1.6 V to 3.6 V on the control lines (clock and data). If it is on a breakout board, it may be a bit more demanding (on the lower end)...

  • Fri 2019.12.27

    Wrap L10 thru L22 in a function labeled onInit() as @allObjects points out, calling that with his line of code as the last instruction in the code file.



    Which Espruino device is being used, and is that module being Vcc driven from the Espruino itself?

    Which vendor was the MPL3115A2 acquired from? Some have the onboard regulator to drop the Arduino 5v down to the 3v3 required.

    Turn on time for the MPL3115A2 is a full second. There still may need to be a longer duration with that snippet.

  • I am using a MDBT42Q breakout. It is on a breadboard. The MDBT42Q and the MPL3115A2 are powered with 5v. The screen does work. I was getting the same readings when it wasn't in the mix. The MPL3115A2 is from Adafruit.

    I have refactored my code to this (with the same result):

    var i2c = new I2C();
    I2C1.setup({scl: D20, sda: D22});
    i2c.setup({sda:D30,scl:D29});
    var mpl = require("MPL3115A2").connect(i2c);
    var lcd = require("HD44780").connectI2C(I2C1, 0x3F);
    
    lcd.setCursor(0, 0);
    lcd.print("Starting...");
    
    const onInit = ()=> {
      setInterval(() => {
        mpl.getPressure(function(x) {
          console.log("Pressure "+x+" pa");
          mpl.getAltitude(function(x) {
            console.log("Altitude "+x+" m");
              mpl.getTemperature(function(x) {
              console.log("Temperature "+x+" C");
            });
          });
        });
      }, 5000);
    };
    
    setTimeout(onInit, 3000);
    

    Per @allObjects I changed it so that I was only reading pressure. When I do that, the readings are 100066, and that is really close to the Arduino.

  • Okay, so that confirms you have a good handle on the power supply side of things.

    Had to re-visit physics for the metric pressure conversions,

    https://www.enotes.com/homework-help/sea­-level-what-approximate-value-atmospheri­c-125807
    'At sea level, the approximate value of atmospheric pressure in those units of measure is as follows: 101.3 kPa which is how it is usually expressed. In pascals, it is 101325 pascals'

    So, making the assumption the Arduino data is accurate, and that your location is roughly 300 ft above sea level, that pressure value appears correct, which agrees with your initial Arduino understanding.

    Am I to understand then, that only accurate data is obtained when L14-L17 are commented out? e.g. the console.log() statements may throw in a timing issue with the data response and I2C comm? @allObjects mentioned busy state in #4 post. Is accurate data obtained for each of the other readings when done one at a time?

    See p.10 and section 5.3

    https://cdn.sparkfun.com/datasheets/Sens­ors/Pressure/MPL3115A2.pdf

    That might be it, as the time to update the WebIDE most likely is taking longer than how Arduino would handle that task, even with the 10msec delay at each register read.

    https://github.com/adafruit/Adafruit_MPL­3115A2_Library/blob/master/Adafruit_MPL3­115A2.cpp

    https://github.com/adafruit/Adafruit_MPL­3115A2_Library/blob/master/examples/test­mpl3115a2/testmpl3115a2.ino

  • @calebbrewer,

    you may have noticed the other Espruino forum conversation about MPL3115A2 Troubleshooting?

    It talks about pull-up resistors among other things. If they are missing, I2C communication fails usually completely, but some capacities on the lines and too weak / strong pull-ups may still yield some results but not reliable ones and can mess with some bits... May be pull-up resistors - or their absence - could be the culprit(s).

    Some other things that bothered me when glancing again over the source code of the https://espruino.com/modules/MPL3115A2.j­s module:

    1. The brief source code inline documentation about usage implies the module request to return a constructor, where as setting/updating the export object shows definitively just addition of the .connect() method. And your code confirms that the latter is correct.

    2. The .connect() does actually (write) something to the sensor AND even to the connector object (initialize busy=false; that controls communication w/ the sensor)... Therefore, the .connect() has also to be in the onInit(){ ... } function when you plan to save() your code and expect it to work on power cycling. For that reason I never directly connect to the requested module ('outside' - location-wise or 'before' time-wise / execution-wise) onInit(){ ... }:

    var i2c = new I2C();
    I2C1.setup({scl: D20, sda: D22});
    i2c.setup({sda:D30,scl:D29});
    var mpl, mplMode = require("MPL3115A2");
    var lcd, lcdMod = require("HD44780");
    
    const onInit = ()=> {
    
      lcd = lcdMod.connectI2C(I2C1, 0x3F);
    
      lcd.setCursor(0, 0);
      lcd.print("Starting...");
    
      mpl = mplMod.connect(i2c);
      setInterval(() => {
        mpl.getPressure(function(x) {
          console.log("Pressure "+x+" pa");
          mpl.getAltitude(function(x) {
            console.log("Altitude "+x+" m");
              mpl.getTemperature(function(x) {
              console.log("Temperature "+x+" C");
            });
          });
        });
    
      }, 5000);
    };
    
    setTimeout(onInit, 3000);
    

    In above code example I applied the same pattern also for the lcd instance / lcd module, even though it could work the other way as well... I try to have fewer patterns of doing things in place to include robustness against changes or differences.

    I do though not believe that any of my code changes fix the issue you face. That a single read was close to what other driving boards read makes me think of the pull-up resistors and may be the wiring... I'm sure you grounded all things well together (have not just ground via power supply but also for signal board to board)... since it is not the first time you do electronics... but I having been fooled by a missing wire or a breadboard contact not doing right would not be the first time...

  • Am I to understand then, that only accurate data is obtained when L14-L17 are commented out?
    That is correct.

    I made the interval 10s and added as much as a 2s timeout between the different reading with the same results.

    I am not using any pull-ups on the i2c connection.
    Everything is grounded.

    I tried reordering the functions and got some different results. I found that it doesn't matter where the temp reading is, but it can't read altitude and pressure (no matter which callback is first), or one of them will come up with crazy numbers. Also, the first reading is always off.

    I am under the impression that the sensor uses the pressure and temp to estimate the altitude.

  • @calebbrewer

    I2C needs pull-up resistors... see https://i2c.info/


    1 Attachment

    • I2C_in_1_shot.png
  • The MPL3115A2 is from Adafruit

    it comes with pullups

  • That's what I was thinking. If it didn't, I don't think it would work at all.

  • ...great... and not so great... because there is nothing to pin the issue on!

  • @allObjects haha! That was my thought too. I can read temp and pressure accurately if I leave out altitude, and that is what I really need. When I get a chance I will dig a bit more into the module (https://github.com/espruino/EspruinoDocs­/blob/master/devices/MPL3115A2.js).

    Thanks for all the help. If anyone has any other ideas that would be great.

  • @calebbrewer

    altitude by pressure requires usually a calibration when being at a point of known altitude and stays valid only when no pressure change due to weather changes happens... That was the best we got in the days of me mountain climbing without GPS - but with an altimeter / barometer. I'd be surprised if this sensor could do better. Taking altitude from temperature is even more a gamble... but yes in general, it works. That would confirm you observing that there is a dependency... May be the sensor is so smart that it takes both into account and tries to make 'some' sense out of them. (Attachment taken from http://ww2010.atmos.uiuc.edu/(Gh)/guides­/mtr/prs/hght.rxml )


    1 Attachment

    • atmosphericPressureVsAltitude.png
  • @calebbrewer
    can you compare adruino code with module code to figure out what is different?

  • Mon 2019.12.30

    The answer is in the datasheet in the link I posted in #7 thread. @allObjects is on the right track.

  • @calebbrewer, just came across this barometric precision sensor that can detect altitude changes in the cm / inch range... and when your partner slams the door, you get air pressure transients / spikes rather than electrical one!

    Notice: It talks about changes, not absolute values!

    https://www.seeedstudio.com/Grove-High-P­recision-Barometer-Sensor-DPS310-p-4397.­html?utm_source=mailchimp&utm_medium=edm­&utm_campaign=bazaar_1226&ct=t()&mc_cid=­704d652ffe&mc_eid=c50e0b4abb


    1 Attachment

    • seeed_DPS310_air_pressure_sensor.png
  • That looks sweet! I'll look into i. Thanks

  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview
About

MPL3115A2 Digital Altitude / Pressure / Temperature Sensor Readings

Posted by Avatar for calebbrewer @calebbrewer

Actions