Developer

Altitude sensing - Ublox versus SCP1000

I got a SCP1000 absolute pressure sensor and have been looking at the relative performance versus ublox.


Here is the data from my first flight test - ublox is blue, scp1000 is pink. The data was taken while manually flying a SkyFun "pusher jet" in somewhat gusty wind conditions.


There are several things that stand out to me. First is that the scp data is a lot "noisier". Does this actually represent the movement of the aircraft? Perhaps. I cannot really say after this one test.


Second is that the ublox appears to lag badly during fast descents. Seems to keep up going up, but not so much coming down. I suspect this has something to do with the ublox filtering algorithm.


The third thing I see, about which I am the most curious, is that something produced some kind of offset to the pressure at the beginning and end of the flight. If you look closely at the beginning of the graph, you can see that the pressure altitude starts at the same value as the gps altitude (by definition in the software). However, while still on the ground, something causes the pressure altitude to jump down about 22 meters. It bounces back and forth for one period before takeoff. Then at the end of the flight, you can see that the landing altitude is about 22 meters below actual, but then something happens on the ground that causes it to bounce back up around the correct value. This is a real problem. My only theory so far is that putting the canopy on may be trapping some small amount of pressure. However, if this were the case I don't know how the sensor would have the relative level of accuracy it does during the flight. The effect does not appear to be related to airspeed, as the changes noted at the beginning and end were while not in motion.


I also noted that except for the bottom of the "second valley", the effect I noted above, if it is coming and going, could produce the "noise" seen in the pressure altitude. You can see that the peaks of the "noise" correspond fairly well with the gps altitude for much of the flight.


I welcome all thought and comments.....


E-mail me when people leave their comments –

You need to be a member of diydrones to add comments!

Join diydrones

Comments

  • Developer
    Here is the code exerpt:

    double x;
    double p = (double)press_gnd/(double)press;
    double temp = (float)temperature/20.f + 273.15f;
    x = log(p) * temp * 2927.1267f;
    press_alt = x + ground_alt;

    You need to have the ground pressure and the ground altitude.
  • Hi Doug,

    Which formula do you use to translate baro pressure to altitude?

  • Be careful that the cap or anything else is not actually touching the gel area on top of the scp1000, that will cause weird behavior, way off in altitude. I have the cap on it, it got misaligned on the sensor and was touching the gel area, and that seemed to be the cause. The cap has a single hole in it, I suppose the hole should be placed opposite, not above the port, if the light matters. But even still, I think light would get it depending on orientation. I wonder if the sensitivity is from the gel expanding when heated by infrared.
  • A simple GPS should not be trusted for altimeter readings. You can easly test this by logging altitude readings from a stationary GPS for a period of time.
    See also:
    http://www.google.com/search?hl=en-GB&q=altitude+readings+from+...
    altitude readings from gps - Google Search
  • I forgot to add that sensor FAQ items 4, 5, 6 are about "Performance:
    Noise / unstable pressure readings" .

    Best regards,
    Jean-Claude
  • There is also a discussion on the UAVDEVBOAD discussion about the same sensor
    http://groups.google.com/group/uavdevboard/browse_thread/thread/8cf...
    To summarize:
    Ufo-man reported that the calibration coefficients in eeprom are easily corrupted and this sensor was discontinued.
    And below my last replies:

    "Effectively , i went to VTI website to find some informations

    1) This SCP1000-D01 is marked as "obsolete*

    2) There are 2 versions of this ASIC :
    Version B , the oldest
    Version C which is fixing some issues(The version can be read in
    Register REVID 0x00)
    Interesting point : in Rev C, they did changes in the logic about
    the low noise configuration during Start-UP sequence.
    As a result low noise configuration during startup sequence can be
    removed from the code.

    3)they also provide a "code example" pdf , which shows that they check
    for the EEPROM "checksum error" after the startup sequence
    "Read DATARD8 register and check that LSB (bit0) is one, if not EEPROM
    checksum error is detected --> SCP1000 will not give reliable pressure
    data"

    Here is the link url to all the documents (faq, source code, SCP1000
    series diff )
    http://www.vti.fi/en/support/obsolete_products/pressure_sensors/

    I also found that a specific "seal gasket" is highly recommended by
    the Manufacturer to improve measurement reliability when exposure to
    humidity and sun !!
    http://www.vti.fi/midcom-serveattachmentguid-63da650c40290b49e107c28a..."

    Jean-Claude
  • @Doug - I seen some discussion elsewhere after I posted this question, someone had discussed fusing the accelerometer output with the pressure sensor output with a simple kalman filter (maybe even a complimentary filter). The static noise of the pressure sensor was greatly tamed when not corroborated by the accelerometer data. Maybe fusing all three pressure sensor, accels and gps.
  • Hey guys...actually they are both VERY close they are just stated differently...they are both 30,000 to 110,000 Pa - the SCP goes up a little higher to 120,000 - it is just that one is stated in kPa and the other in hPa - and you are right Doug, the Bosch module is MUCH faster. I have a few of these - would you guys (Doug, Michael and Jack be willing to test them in the same fashion you have above if I sent them to you??
  • Developer
    @Michael - I had not looked at the BMP085 before, but it looks pretty good. You will note that VTI does not give any accuracy specifications, only resolution. After my testing today I can tell you that the accuracy and resolution differ by at least an order of magnitude, perhaps 2. So I wouldn't get concerned with the "low" accuracy spec on the Bosch - it may actually be better than the VTI. The Bosch is faster too.
  • Developer
    GPS altitude measurement is accurate only on some locations and if US military wants, they can "crash" your plane pressing one button at their GPS control center. I live in Asia area and even when I have 10 or more satellites locked and 3D Fix. My altitude for fixed antenna can jump -+ 70 meters in just matter of minutes. so at least on this area GPS altitude measurement is big NONO.

    I've been making those measurement with ublox 5 too. Heres few pics taken from u-console while antenna was stationary on my balcony on 10th floor. One measurement was made on 10 May and another just few days ago. So you should not trust too much on your GPS altitude data.

This reply was deleted.