Das Sonar ist wahrscheinlich eines der faszinierendsten Experimente, aber auch eines der verwirrendsten, wenn man nicht genau weiß, wie es richtig durchgeführt wird. Dieses Video erklärt, wie ihr euer Smartphone in ein Sonar verwandelt.
2 Gedanken zu „Experiment: Sonar“
Kommentare sind geschlossen.
Spricht etwas dagegen, beim Datenexport statt 5.157440900802612E-4 den Wert 0.0005157440900802612 oder einen verkürzten Wert auszugeben? Die Sensoren sind nicht so genau, dass mehr als 10 signifikante Stellen gerechtfertigt geschweige denn notwendig wären.
Werte mit Exponentialschreibweise können in weiteren Programmen Probleme verursachen.
Vielen Dank für den Hinweis! 16 signifikante Stellen sind in der Tat etwas extravagant – ich denke, der anspruchsvollste Sensor in dieser Hinsicht ist der Drucksensor, welcher mindestens sieben (!) signifikante Stellen ausnutzt – aber der schummelt auch ein wenig, da er relativ zu 1000hPa misst, das Ergebnis dann aber absolut ausgegeben wird (also z.B. 1001.234 hPa).
Dabei muss ich auch gestehen, dass beim Export keine expliziten Vorgaben gemacht werden, sondern es sich einfach um die Standardausgabe des jeweiligen Systems (Android/Java bzw. iOS/Swift) handelt. Intern wird mit Double-Genauigkeit (64-Bit-Fließkommazahlen) gerechnet und entsprechend werden automatisch 16 dezimale Stellen mit Exponent ausgegeben, um diese Werte ohne Verluste als Zeichenkette darzustellen – für phyphox natürlich mehr als nötig, aber da die Dateien dem Datenaustausch dienen und nicht „von Menschen“ gelesen werden müssen schadet es auch nicht wirklich.
Die Exponentialschreibweise würde ich in jedem Fall beibehalten, da die Genauigkeit dadurch unabhängig von der Größenordnung bleibt. Dabei müssen nicht nur die Sensoren, sondern auch die Auswertung in den Experimenten bedacht werden. Beim Sonar erhält man bei der Normierung auf eine Kugeloberfläche beispielsweise durchaus Werte über 1E9, die auch exportiert werden können. Wer weiß, was die Nutzer in eigenen Experimenten so zusammenrechnen und in welch unhandlichen Einheiten die arbeiten – eine Einschränkung vorzugeben, keine Ergebnisse unter 1E-10 oder über 1E10 zu exportieren wäre eher unschön…
Bei welcher Software treten denn Probleme auf? Das Format sollte jede gängige Programmiersprache verstehen können und entsprechend müsste die Software schon eigene String-zu-Fließkomma-Konvertierungen implementieren bzw. es gezielt verbieten…
Daher meine Bitte: Wenn es eine konkrete Software gibt, die die Daten nicht schluckt, bitte Bescheid sagen. Dann passe ich das Format entsprechend an oder baue eine Alternative (weniger Stellen, kein Exponent, anderes Format) ein, damit man die Daten weiterverarbeiten kann.