Vreemde hoogte waarde uit een BMP en BME280 Sensor

blackdog

Golden Member

Hi,

Ik ben bezig met de code voor mijn LAB 10V referentie kastje en in de voorbeeld code van meerdere Library's zit ook de hoogte berekening, voor mijn project niet erg belangrijk maar ik wil wel graag weten wat er mis gaat..
Ik krijg met verschillende Librarys, Uno, Nano, Teensy controlers er waarden uit die een beetje erg veel naast de echte hoogte waarde zit.

De code laat zien dat ik mij bevind op een hoogte van ongeveer 210 meter!
Zover ik weet bevind mijn werkkamer zich niet bovenin de KPN toren langs de ringweg zuid hier in Amsterdam.
Een normale waarde zou rond 6 a 8 meter zijn.

Heeft iemand een idee waarom die waarde zover afwijkt?
Zou de waarde eigenlijk in voeten zijn weergegeven?
Moet ik de aangegeven waarde dan door 32,81cm delen, de waarde die er dan uit komt zit dan rond de 6,3M, wat zou kunnen kloppen...
Als ik dat deelgetal toepas, dan klopt de hoogte verplaatsing niet meer, dus zeg 40cm in hoogte verplaatsing wordt dan niet meer correct aangegeven.

De standaard Adafruit code gedraaid op een UNO en de BMP280 sensor is via i2c verbonden UNO.

c code:


/***************************************************************************
  This is a library for the BMP280 humidity, temperature & pressure sensor

  Designed specifically to work with the Adafruit BMP280 Breakout
  ----> http://www.adafruit.com/products/2651

  These sensors use I2C or SPI to communicate, 2 or 4 pins are required
  to interface.

  Adafruit invests time and resources providing this open source code,
  please support Adafruit andopen-source hardware by purchasing products
  from Adafruit!

  Written by Limor Fried & Kevin Townsend for Adafruit Industries.
  BSD license, all text above must be included in any redistribution
 ***************************************************************************/

#include <Wire.h>
#include <SPI.h>
#include <Adafruit_BMP280.h>

#define BMP_SCK  (13)
#define BMP_MISO (12)
#define BMP_MOSI (11)
#define BMP_CS   (10)

Adafruit_BMP280 bmp; // I2C
//Adafruit_BMP280 bmp(BMP_CS); // hardware SPI
//Adafruit_BMP280 bmp(BMP_CS, BMP_MOSI, BMP_MISO,  BMP_SCK);

void setup() {
  Serial.begin(9600);
  while ( !Serial ) delay(100);   // wait for native usb
  Serial.println(F("BMP280 test"));
  unsigned status;
  //status = bmp.begin(BMP280_ADDRESS_ALT, BMP280_CHIPID);
  status = bmp.begin();
  if (!status) {
    Serial.println(F("Could not find a valid BMP280 sensor, check wiring or "
                      "try a different address!"));
    Serial.print("SensorID was: 0x"); Serial.println(bmp.sensorID(),16);
    Serial.print("        ID of 0xFF probably means a bad address, a BMP 180 or BMP 085\n");
    Serial.print("   ID of 0x56-0x58 represents a BMP 280,\n");
    Serial.print("        ID of 0x60 represents a BME 280.\n");
    Serial.print("        ID of 0x61 represents a BME 680.\n");
    while (1) delay(10);
  }

  /* Default settings from datasheet. */
  bmp.setSampling(Adafruit_BMP280::MODE_NORMAL,     /* Operating Mode. */
                  Adafruit_BMP280::SAMPLING_X2,     /* Temp. oversampling */
                  Adafruit_BMP280::SAMPLING_X16,    /* Pressure oversampling */
                  Adafruit_BMP280::FILTER_X16,      /* Filtering. */
                  Adafruit_BMP280::STANDBY_MS_500); /* Standby time. */
}

void loop() {
    Serial.print(F("Temperature = "));
    Serial.print(bmp.readTemperature());
    Serial.println(" *C");

    Serial.print(F("Pressure = "));
    Serial.print(bmp.readPressure());
    Serial.println(" Pa");

    Serial.print(F("Approx altitude = "));
    Serial.print(bmp.readAltitude(1013.25)); /* Adjusted to local forecast! */
    Serial.println(" m");

    Serial.println();
    delay(2000);
}

Deze code genereerd in de Serial monitor deze waarde:

c code:



Temperature = 18.46 *C
Pressure = 98872.33 Pa
Approx altitude = 206.23 m     <= ik krijg hoogte vrees :-)

Iemand een idee waarom de hoogte waarde zover afwijkt, ik ben bekend er mee dat deze meting niet zo precies is, maar deze afwijking is wel erg veel.

Dank vast en groet,
BRam

You have your way. I have my way. As for the right way, the correct way, and the only way, it does not exist.
Frederick E. Terman

Honourable Member

Serial.print(bmp.readAltitude(1013.25)); /* Adjusted to local forecast! */

Wordt dat getal ergens aangepast?
De luchtdruk in Amsterdam is momenteel ca. 99610 Pa, geen 101325 Pa (1013.25 hPa). Bij jouw meting zal het misschien nog lager geweest zijn - het weer is er wel naar.
En pas natuurlijk op met die hPa, als je ook Pa gebruikt.

Keramisch, kalibratie, parasitair: woordenlijst.org
blackdog

Golden Member

Hi Frederick E. Terman, :-)

Ik heb in de code met de waarde die je had opgegeven aangepast, kom ik op +62 meter uit, nog steeds een factor 10x te hoog.

Voor de goede orde heb ik de code een beetje aangepast, zodat hij nu hPa aangeeft, de hoogte is nog steeds onzin, en ik denk dat ik die waarde maar vergeet, is ook niet echt nodig.

c code:


Temperature = 20.55 *C
Pressure = 988.65 hPa
Approx altitude = 63.29 m

Ben al een uur aan het zoeken op het inet, dit heeft weinig positieve resultaten opgelevert.
Het kan ook bijna niet denk ik, doordat de luchtdruk steeds veranderd, maar ik dacht dat ze b.v. de referentiewaarde van 1013,25hPa zouden kunnen verrekenen.

Groet,
Bram

You have your way. I have my way. As for the right way, the correct way, and the only way, it does not exist.

Voor de duidelijkheid, de BMP280 meet alleen druk. De altitude wordt vervolgens bepaald met een berekening. Als de gemeten druk klopt, dan zou de afweiking zitten in de druk die je mee geeft aan je functie.
(Zomaar uit interesse, waarom wil je de druk weten in je referentie voeding?)

c code:


float Adafruit_BMP280::readAltitude(float seaLevelhPa) {
  float altitude;

  float pressure = readPressure(); // in Si units for Pascal
  pressure /= 100;

  altitude = 44330 * (1.0 - pow(pressure / seaLevelhPa, 0.1903));

  return altitude;
}

https://github.com/adafruit/Adafruit_BMP280_Library/blob/master/Adafru…

PE2BAS
buckfast_beekeeper

Golden Member

Toch een heel normaal resultaat. Beide sensoren zijn door Bosch ontworpen als 'luchtmassameter' voor auto's. De reële hoogte interesseert de wagenbouwer niet. Hij wil alleen dat er bij lagere luchtdruk een ander mengsel wordt gebruikt dan bij hoge luchtdruk. Wat oudere reizigers zullen zich nog wel herinneren dat een atmosferische wagen, afgesteld op zeeniveau, moeilijk te starten was op 2469m hoogte zeg maar op de col du sint bernard. Zeker geen choke of de motor was 'verzopen'. Aan dit euvel verhelpt de luchtmassameter. De berekende hoogte is dus geen maat voor de reële hoogte maar een berekende hoogte op basis van de luchtdruk.

Kijk ik op de, geijkte, kwik barometer achter me, dan geeft die 989hPa. Kijk ik op wat Wheatermap doorgeeft voor de regio is dat 996hPa. Kijk ik op mijn 'Afterburner' gegevens met BME280 geeft die.

De Afterburner gebruikt die gegevens om de pompfrequentie van de standverwarming aan te passen aan de hoogte. Ook hier is de mix lucht/brandstof bepalend voor een zuivere verbranding.

Kijk ik naar mijn fijnstof sensor met BME280, dan heb ik deze gegevens. Dan zijn de gegevens niet 100% identiek maar meer dan nauwkeurig genoeg voor gebruik in een auto. De rel vochtigheid is te verklaren door de ene sensor in een serre en de fijnstof sensor buiten.

Nog wat info

Van Lambiek wordt goede geuze gemaakt.
blackdog

Golden Member

Hi Heren,

Dank voor de info, intressant!
Ik laat de hoogte meting gewoon achterwege, wat ik al aangaf niet nodig voor mijn toepassing.
Zou ik het toch willen hebben, dan had ik al goede resultaten voor de hoogte met een GPS moduul.

De Bosch sensoren komen goed overeen met andere luchdruk sensoren die ik hier heb, dus ik denk dat daar geen fouten in zitten.
Op het moment van dit typen klopt de luchtdruk met wat hier wordt aangegeven:

https://www.weerplaza.nl/nederland/amsterdam/5575/actueel/

Ik ga verder met de rest van de code na dit verhelderende inzicht. :-)
Nu nog wat beter weer, zodat ik weer eens een flinke wandeling kan maken, kunnen jullie daar ook voor zorgen? :+

Groet,
Bram

You have your way. I have my way. As for the right way, the correct way, and the only way, it does not exist.

ELKE barometrische hoogtemeter moet je justeren. Dwz, je moet weten wat de druk op 0m is. Dat is je referentie. Luchtdruk verandert continu, dus je kunt nooit absoluut de hoogte bepalen door luchtdruk te meten. Zo ook met de bm*280

"We cannot solve our problems with the same thinking we used when we created them" - Albert Einstein
blackdog

Golden Member

Hi flipflop, :-)

Mijn aanname was dat omdat er een referentiewaarde van het zeeniveau wordt aangegeven,
dat dit op een magische manier in de berekening van de hoogt zou worden verwerkt.

Weer een aanname het ronde archief in, maar ook weer kennis opgedaan door jullie!

Groet,
Bram

You have your way. I have my way. As for the right way, the correct way, and the only way, it does not exist.
Lucky Luke

Golden Member

Voor de CanSat competitie (ergens in een vorig leven…) werden ook luchtdruk-sensoren gebruikt voor de hoogte van de cansat. Ook met een #define in de code geprobeerd te justeren obv de weersvoorspelling. Wat beter werkt, is achteraf de hoogte die ‘ie voor de lancering en na de landing meet als nul te nemen. En daarna eventueel nog te corrigeren voor de hoogte van het terrein.

Dat kan uiteraard ook door de hoogte van je werkbank als ‘0’ te definiëren en daarna een trap op te lopen. Of af.

IIRC heeft Aart een keer gespeeld met luchtdruksensoren die dusdanig gevoelig waren dat ‘een deur open doen’ in de grafiek terug te zien was.

Eluke.nl | De mens onderscheid zich van (andere) dieren door o.a. complexe gereedschappen en bouwwerken te maken. Mens zijn is nerd zijn. Blijf Maken. (Of wordt, bijvoorbeeld, cultuurhistoricus)

Op 10 maart 2023 15:23:38 schreef blackdog:
..Mijn aanname was dat omdat er een referentiewaarde van het zeeniveau wordt aangegeven...

Ook op zeenivo is de druk elk uur anders.
Overigens was ik best onder de indruk van die hoogtemeting met die sensor. Het resultaat had best was ruis, maar toch kon ik een verschil van een meter prima zien in de resultaten.

"We cannot solve our problems with the same thinking we used when we created them" - Albert Einstein

Welke heb je echt? Een BME of BMP; zijn verschillend en ik lees dat sommige leveranciers ze degene sturen die je niet wilt.

Er zouden mislukte versies zijn die dan als de ander verkocht worden.

blackdog

Golden Member

Hi Panda, :-)

Ik heb de BME280 en de BMP280, en meerdere stuks van ieder.
Meerdere Librarys getest en op verschillende microcontrolers.
Daar zit het probleem niet in.

Groet,
Bram

You have your way. I have my way. As for the right way, the correct way, and the only way, it does not exist.

Dus "10x fout" is een "oneerlijke manier" om naar de fout te kijken.

Als jij in Verbier op 1500m had gezeten(*) dan had de fout ongeveer ook 50m geweest en dan is het ongeveer 3% ipv 1000%...

Een offset van zeg 50m vind ik niet eens zo slecht. De absolute calibratie van die dingen is nogal tricky. Dus ik verwacht dat als je in de code iets doet als:

c code:

current_pressure = 994;
offset = -7;
println (bmp.readAltitude(current_pressure + offset));

en dan aan de offset rommelt totdat het vandaag klopt (wel even de actuele druk bij jou goed inschatten... Schiphol meet en publiceert hem in ieder geval minstens ieder uur).
(Teletekst 707.7: METAR AHAM .... Q0994 ... ). (Nu ruim een halfuur oud, over een half uur is er een nieuwe.).

(*) Random bewoonbare plek waarvan ik de hoogte weet die niet ongeveer nul is.

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/
blackdog

Golden Member

Hi rew, :-)

De fout is wat groter dan 10x.

De waarde zou ongeveer zeg 7-Meter moeten zijn, dit volgens diverse GPS metingen.
Als dan 210 meter wordt aangegeven kan je niet meer spreken van een "foutje".

Zoals je aangeeft in je stukje code zou ik een offset kunnen gebuiken, maar het blijft dan toch nog natte vinger werk, de luchdruk varieerd voortdurend.
Ik weet nu waarom de hoogte meting onbetrouwbaar is en zal dat als ik deze sensoren gebruik, deze waarde niet meer gaan toepassen.
Natuurlijk is het goed bruikbaar voor korte termijn relatieve metingen of zoals door buckfast_beekeeper aangegeven toepassingen voor verbrandings motoren.

Oja, net nog een testje gedaan met de waarde van de huidige luchtdruk in te geven voor het Zee luchtdruk niveau, kom ik mooi rond "0-Meter" uit.
Door de deur hier snel open te doen zag ik de luchdruk een beetje stijgen.

Door het "nullen" is het ook heel goed te zien dat het met dit weer nogal onstabiel is wat luchdruk betreft.
Nu waait het maar een beetje in Amsterdam, dit is goed zichtbaar door de sneeuw die er op het ogenblik valt.
De beweging van de Sneeuw lijk een beetje op het gedrag van mijn thee plaatje die ik liet zien genomen met de thermische camera in mijn oven topic, vloeistof gedrag, draait alle kanten op.

Groet,
Bram

You have your way. I have my way. As for the right way, the correct way, and the only way, it does not exist.
buckfast_beekeeper

Golden Member

Ook GPS varieert. Hier staat een GPS 24/7 aan en is vast gemonteerd. Je zou dus verwachten dat die vrij accuraat zou zijn. Toch is er ook vlot 4m verschil op beperkte tijd. Als ik de webinterface opende was het 16m 10 gebruikte sats en 12 in view. Minder dan een kwartier later was het dit.

Weer 10 minuten later zitten we op 16,7m.

Het gemiddelde over 24h zou 16,9m zijn.

Van Lambiek wordt goede geuze gemaakt.
blackdog

Golden Member

Hi buckfast_beekeeper, :-)

Die variatie in de hoogte het ik ook geregistreerd, vooral bij de niet optimale plaatsing van de sensor.
Ik hoop binnekort een goede GPS sensor op dak te hebben met vrij zicht.

De huidige locatie van mijn sensor is niet optimaal, net als bij jou komen er dan een aantal tijdstippen voorbij waarbij de positie een beetje aan de wandel is :-)

Zover mijn kennis reikt hierover, is het afhankelijk van de kwaliteit van de sensor, het zicht van de sensor, welke services er worden gebrukt en de instellingen van de sensor.
Ook heb je bij bepaalde services ook nog de opzettelijke onnauwkeurighied die er wordt toegepast zoasl bij GPS.

Mij Leo NTP server ziet bijna altijd minstens 9 Sattelieten en vaak ook 13 stuks, dit bij en niet optimale plaatsing van de antenne voor deze NTP klok.
Jammer genoeg geeft de Leo NTP Server niet de hoogte aan, wel de andere coordinaten.

Groet,
Bram

You have your way. I have my way. As for the right way, the correct way, and the only way, it does not exist.

Ik heb altijd gedacht dat drones werken met deze sensoren, je vliegt dus makkelijk tegen een toren aan met deze afwijkingen.

Guus@Sint-Michielsgestel
Arco

Special Member

't Is een lastige sensor met een bar slecht geschreven en onbegrijpelijke datasheet. (je ziet duidelijk dat ze meer verstand van auto's hebben)
Het zou me niet verbazen als er ergens een fout in een van de berekeningen zit.
(hoewel de gevonden afwijkingen voor de automotive toepassingen irrelevant zijn, daar steekt 't niet op 100m...)

Ik vroeg me net wel af waarom Galileo eigenlijk nog steeds niet erg van de grond komt, het is toch al een tijdje operationeel...
(en ongeveer 4x preciezer als GPS qua positiebepaling)

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com
Frederick E. Terman

Honourable Member

In elk geval, die druk-naar-hoogte-berekening klopt wel. Als ik het nareken met de gegeven waarden voor zeeniveau en gemeten, dan krijg ik er dezelfde hoogte uit. En je ziet ook inderdaad een berekende hoogte 'nul' als je voor die twee waarden hetzelfde getal hebt.
Het zal dan wel zo zijn dat de sensor de luchtdruk fout meet.

Een drone vergelijkt de gemeten luchtdruk met de luchtdruk zoals hij die mat toen hij op de grond stond. Fouten maken dan bijna niets uit, omdat het verschil daardoor praktisch niet verandert, zodat de berekende hoogte daardoor ook praktisch geen fout oploopt.

GPS-hoogte is op onze breedten wat onnauwkeuriger dan GPS-lengte en -breedte, doordat de satellieten gemiddeld vrij laag boven de horizon staan.
Je schermbeeld geeft dat trouwens ook aan: VDOP is groter dan HDOP.
Samen geven ze de complete PDOP: 0,892 + 1,342 = 1,622.

Keramisch, kalibratie, parasitair: woordenlijst.org
Arco

Special Member

Moet je bij hoogteberekeningen ook niet de luchttemperatuur meenemen?

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com

Ik vroeg me net wel af waarom Galileo eigenlijk nog steeds niet erg van de grond komt, het is toch al een tijdje operationeel...

Toch nog niet ZO lang, de chipsets zijn nog duur, flink wat duurder dan de vorige generatie die enkel GPS en Glonass kon ontvangen en interpreteren.

Moet je bij hoogteberekeningen ook niet de luchttemperatuur meenemen?

Als er bedoeld wordt: afleiden van de hoogte uit de gemeten luchtdruk: jawel, en om het echt nauwkeurig te hebben, ook de vochtigheidsgraad.

GPS-hoogte is op onze breedten wat onnauwkeuriger dan GPS-lengte en -breedte

Dat durf ik een understatement noemen :) Toen ik nog in Haacht (BE) woonde, kreeg ik hoogteaanduidingen tussen -15 en +25 meter, met een weliswaar cheapo usb-ontvangertje dat toch zowel GPS als Glonass ontving.

Ook toen ik nog uit vliegen ging - en daarboven in het ijle zwerk kon ik echt veel satellieten ontvangen! - viel het me op dat GNSS geen stabiele hoogte-informatie afleverde. Maar ook dat ging uit van dat cheapo usb-ontvangertje.

[Bericht gewijzigd door Paulinha_B op vrijdag 10 maart 2023 20:59:07 (12%)

Arco

Special Member

Als er bedoeld wordt: afleiden van de hoogte uit de gemeten luchtdruk: jawel, en om het echt nauwkeurig te hebben, ook de vochtigheidsgraad.

Dat staat ook in de datasheet dat de temperatuur, luchtvochtigheid en druk allen nauw met elkaar verbonden zijn.
(zijn vrij complexe formules om alles precies te berekenen...)

Arco - "Simplicity is a prerequisite for reliability" - hard-, firm-, en software ontwikkeling: www.arcovox.com

Complex, inderdaad, en niet zo super-relevant voor de meeste mensen.
Die vochtigheidsfactor kan (puur op mijn gevoel weg) nooit meer dan centimeters verschil maken, wat maakt dat dan uit. Zolang de motor draait vliegt men zo hoog en zo laag als men wil (binnen de grenzen van wettelijkheid en fysica, uiteraard), en laat de motor het al eens afweten dan gaat het alleen maar neerwaarts - waarbij het ook al niet op een centimeter komt ;)

buckfast_beekeeper

Golden Member

Op 10 maart 2023 19:06:36 schreef blackdog:
Hi buckfast_beekeeper, :-)

Die variatie in de hoogte het ik ook geregistreerd, vooral bij de niet optimale plaatsing van de sensor.
Ik hoop binnekort een goede GPS sensor op dak te hebben met vrij zicht.

De huidige locatie van mijn sensor is niet optimaal, net als bij jou komen er dan een aantal tijdstippen voorbij waarbij de positie een beetje aan de wandel is :-)

[...]

De antenne heeft al buiten gehangen aan een paal zowat 3m boven de aarde en 10m van het dichtste obstakel. Nu hangt de antenne onder een kunststof dak ook ongeveer 3m hoog. Het resultaat verschilt niet significant. De sensor is de veel gebruikte NEO-6M met externe antenne.

Van Lambiek wordt goede geuze gemaakt.

Als je denkt dat je de hoogte uit een luchtdruk kan herleiden dan ben je gewoon compleet idioot bezig. Iedereen weet dat je de huidige "luchtdruk op zeeniveau" moet invoeren om een betrouwbare hoogtemeting te krijgen.

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/