Zwaartekrachtmeting met smartphone

[jkien]

Mijn smartphone bevat een versnellingsmeter die in rust de versnelling van de zwaartekracht aangeeft. De calibratie klopt niet, hij geeft ongeveer 9.57 aan i.p.v. 9.81 m/s². Zou je met lang middelen op een stabiele waarde uitkomen, zo stabiel dat je het zwaartekrachtsverschil tussen Groningen (9.813 m/s²) en Maastricht (9.811 m/s²) zou kunnen meten? De meetnauwkeurigheid moet daarvoor 0.001 m/s² zijn, of beter.

Ik heb de smartphone (galaxy S4) thuis op de grond gelegd, het versnellingssignaal op de smartphone opgenomen met de app 'sensor insider', en de registratie op de laptop met excel bekeken. De sensor meet de versnelling 5x per seconde. Ik schatte de standaard deviatie (SD) in een korte opname van tien seconde op 0.01 m/s². Als er geen drift was dan zou de standard error of the mean (SEM) = SD/√n zijn. Na een minuut is dat 0.001 m/s², dus dat leek veelbelovend. Maar ik had al eens gemerkt dat de g-waarde van dag tot dag verschilt, er is kennelijk drift.

Ik heb drie lange registraties gemaakt, telkens na een halve dag. Niet sneller achter elkaar omdat er reistijd zou zitten tussen Groningen en Maastricht. Inderdaad is de drift niet verwaarloosbaar, blijkt uit de bijgaande grafiek van de 2-minuutgemiddelde g-waarde. In het eerste uur is er een flinke drift, in het tweede uur is de drift afgenomen, maar nog steeds zou een bepaling van g niet nauwkeuriger worden dan ongeveer 0.01 m/s². Helaas.

Wat ik overigens niet begrijp is dat de driftbeweging geen random walk is, maar gedurende de registratie een langzame beweging naar het niveau van ongeveer 9.57 ± 0.01 m/s². Waarom zou het uitlezen van de sensor de meetwaarde langzaam naar een bepaalde waarde toe drijven, en waarom zwerft hij daar weer van weg als het uitlezen stopt?

g_meting 1085 keer bekeken

Drie registraties van de zwaartekracht, elk 2 uur

Misschien zou het zwaartekrachtverschil tussen Oslo en Mexico City (9.83 vs. 9.77 m/s², [1]), en tussen zeeniveau en een vliegtuig op 10 km hoogte (9.81 vs. 9.78 m/s²), wel meetbaar zijn met de smartphone, als je de drift elimineert door het eerste uur van de registratie over te slaan bij de meting.

[Michel Uphoff]

Temperatuurvariatie? Opwarming sensor, temperatuurdrift signaalversterking?
 
Overigens is jouw accelerometer dan nauwkeuriger dan de mijne, die 9.3 m/s2 aangeeft. Kan je de drie assen afzonderlijk uitlezen? Bij mij zijn de waarden als ik de smartphone loodrecht op een van de drie assen zet als volgt:
 

.	plat	vertikaal	horizontaal
x	-0,21	-,25	10,03
y	0,04	9,40	-0,20
z	9,25	-,45	0,05

 
Dat is pakweg 8% verschil tussen de assen en bij mij is er sprake van een 'ruis' van ongeveer een half procent. Keer ik het apparaat om (dus ondersteboven bij de oriëntatie 'plat'), dan heb ik snel weer 8 procent verschil per as. Maar ook als ik de smartphone roteer over de te meten as ontstaat er een variatie van ongeveer een half procent.
 
Als we het partnummer van de accelerometer kunnen achterhalen zijn er vast wel spec's te vinden die meer inzicht geven, maar vooralsnog is in iedere geval dat ding in mijn apparaat erg onnauwkeurig, en ongeschikt voor dat soort precisie metingen.
 
 

[jkien]

Bij de drie zwaartekrachtmetingen van bericht #1 heeft de smartphone ook de temperatuur geregistreerd, zie onderstaande grafiek. Bij alle drie was er geen opwarming maar afkoeling. De temperatuur begon iets verhoogd, door voorafgaande activiteit, en daalde door de rust van de meting tot kamertemperatuur (19°C), in een kwartier tijd of sneller. Aangezien de gele curve in bericht #1 begint met dalen en de andere curves met stijgen heeft die helling vermoedelijk niets met de temperatuur te maken. (Ik neem aan dat de accelerometer dezelfde temperatuur had als de temperatuursensor van het toestel.)

g_meting_temp 1079 keer bekeken

Ik heb de zwaartekrachtregistratie nog eens uitgevoerd in de koelkast bij 10°C. Het blijkt dat de koude sensor een hogere g-waarde aangeeft. De verhoging is 0.20 m/s² per 10°C afkoeling. Als het een lineair verband was dan zou het uiteindelijke temperatuurverschil van de gele en paarse curve (1°C) resulteren in een g-waardeverschil van 0.02 m/s².

De orientatie van het toestel is ook bij mij van invloed op de g-waarde: plat 9.60, verticaal 9.40, horizontaal 9.20 m/s². Plat neerleggen heeft de voorkeur, want dan kan het toestel niet omvallen.

Mijn toestel bevat een K330 3-axis accelerometer van STMicroelectronics. Het toestel bevat overigens ook een 'derived' sensor met de bedriegelijke naam 'gravity sensor'. Het is in feite dezelfde sensor, maar de software vermenigvuldigt de drie versnellingscomponenten met een factor zodat de grootte van de nieuwe vector exact 9.80665 m/s² wordt. Deze g-waarde hangt dus niet meer af van de orientatie van het toestel, maar het is natuurlijk nep. Voor het huidige topic is deze 'gravity sensor' ongeschikt.

[Michel Uphoff]

Als je twee even langdurige metingen doet met zoveel mogelijk dezelfde uitgangssituatie (zelfde startcalibratie, omgevingstemperatuur, trillingsvrije locatie, te beginnen bij telkens volledig volle accu).
 
Als het (eventueel langdurig voortschrijdend) gemiddelde tussen beide metingen meer afwijkt dan de gewenste resolutie, lijkt mij dat het geen zin heeft verder te kijken.
 
Hier het datasheet van dat ding (in mijn Samsung tablet en idem smartphone zit overigens dezelfde) :

DM00037200

(1.43 MiB) 132 keer gedownload

[Benm]

Tja, het datasheet zegt het wel een beetje natuurlijk:

f Linear acceleration typical zero-g level offset accuracy(3): 0.06 g (typical, niet maximal)
Linear acceleration zero-g level change vs. temperature: 0.5 mg/K (typ).

Bij elkaar genomen met een 10 graden temperatuur verloop zit je dan aan een nauwkeurigheid van 0.07 g, MITS de sensor is ingesteld voor het bereik van maximaal 2g. Staat het ingesteld voor de maximale 16g kun je daar vermoedelijk nog een factor 8 bovenop gooien (staat niet echt gespecificeerd, en de waarden zijn al typisch en niet maximaal).

Overigens denk ik dat het vrij typerend is dat die waarden niet zo nauwkeurig zijn voor smartphones - op mn eigen LG telefoon wordt 0.95g aangegeven als het toestel gewoon op tafel ligt, op zn zijkant geeft 1.01g, en rechtop 0.98g.

Voor nauwkeurige metingen aan versnellingen lijken deze sensoren tamelijk ongeschikt, maar je kan er bijvoorbeeld best mee meten hoe hard je auto grofweg optrekt, remt, of door een bocht gaat. Toegepast in laptops werken soortgelijke sensoren ook om een vrije val te detecteren en dan de harddrive te beschermen tegen de onvermijdelijke klap op de grond die volgen gaat. Dat is ook waar ze voor bedoeld zijn, niet voor natuurkundig onderzoek naar de precieze zwaartekracht.

[jkien]

Dat de sensor niet goed gecalibreerd is maakt hem nog niet ongeschikt voor een hoger doel. 

De belangrijkste omstandigheid lijkt te zijn, volgens de grafiek van bericht #1, dat de tijd sinds ontwaken (van de sensor, uit power-down mode) groter is dan een uur. Misschien is een haalbaar doel dat een app ('gravity detective') de zwaartekrachtvermindering tijdens vliegen op 10 km hoogte kan meten. De app geeft de g-waarde als een 2-minuutgemiddelde, en een halfuurgemiddelde, en verwerkt daarin correcties voor de variabelen die hij zelf kan meten: temperatuur, orientatie van de smartphone, vullingsgraad van de accu, amplitude van omgevingstrillingen, en tijd sinds ontwaken. Liefst zou de app de benodigde correcties zelf geleerd hebben bij verschillende temperaturen enzovoort (op zeeniveau).

[Benm]

Het zou natuurlijk handig zijn als zo'n app die sensor continu aan kon laten staan (zoveel verbruikt ie niet), zodat je van dat eerste uur af bent.

Wat ik wel interessant vind: Is het daadwerkelijk het eerste uur? Of krijg je iets soortgelijks als je de meting 2 uur laat lopen, de telefoon kantelt, waarna weer een lange stabilisatieperiode nodig is? Misschien eens meten hoe dat zit.

Eerlijkgezegd denk ik niet dat het met opwarming te maken heeft, daarvoor is de periode te lang en de temperatuur zoals gemeten heeft er ook geen enkele relatie mee. Nu kan het zijn dat de gravitatie sensor intern opwarmt zonder dat de temperatuursensor dit kan meten. Volgens het datasheet verbruikt ie 6 mA bij 3.3 volt voeding, pakweg 20 mW. Zoiets moet wel heel goed thermisch geisoleerd zijn om lang te doen om een equilibrium te bereiken - waarom men dat zou doen is me een raadsel.

[jkien]

De sensor bevat in feite drie onafhankelijke accelerometers, voor de x-, y-, en z-richting van de smartphone. Ik heb ze na elkaar getest met 6 uurs metingen van g.

Het resultaat, zie figuur, laat zien dat het 5-minuutgemiddelde vaak een uur of langer stabiel is. De regel dat je het eerste uur na het ontwaken van de sensor moet negeren lijkt weer van toepassing. De horizontale en de verticale orientatie van de smartphone geven het stabielste 5-minuutgemiddelde, gemeten naar de spreidingsbreedte. Hun spreidingsbreedte over de hele meetperiode exclusief het eerste uur is 0.04 m/s². (Dus teveel voor het zwaartekrachtsverschil van Groningen en Maastricht). Ik zou me kunnen voorstellen dat de accelerometer van de z-richting, die gebruikt wordt bij de platte orientatie, iets minder presteert doordat de behuizing in die richting kleiner is. Misschien hindert dat zijn beweging. 

Bij de horizontale orientatie heb ik de smartphone op de tijdstippen A en B geschud en gekanteld. Het 5-minuutgemiddelde verandert daardoor iets. De verandering is snel; niet langzaam zoals bij het ontwaken

g-metingen 1070 keer bekeken

Geel: uurgemiddelde; zwart: 5-minuutgemiddelde; grijs: ongemiddeld.
Rechts dezelfde gele curves verticaal 5x vergroot.

[Benm]

Het lijkt er inderdaad wel op dat het eerste uur onbetrouwbaarder is, al maakt het 5 minuten gemiddelde ook aardige uitschieters na het schudden van het toestel - het scheelt toch 0.01 g na 2x schudden. Wel opvallen dat horizontale en verticale orientatie veel minder gevoelig zijn voor dat opstart effect vergeleken met de platte orientatie.
Misschien kun je eens navraag doen bij de fabrikant van die sensor waarom dit het geval is. Als je aangeeft hun sensor te overwegen voor research gebruik zou je nog wel eens een mooi antwoord terug kunnen krijgen - voor hun r&d afdeling is het natuurlijk ook wel leuk dat iets dat gemaakt is als 'welke kant is boven' sensor een toepassing kan vinden in wetenschappelijk onderzoek.