+- phyphox Forums (https://phyphox.org/forums)
+-- Forum: German / deutsch (https://phyphox.org/forums/forumdisplay.php?fid=11)
+--- Forum: Experimente und Ideen (https://phyphox.org/forums/forumdisplay.php?fid=13)
+--- Thread: Beschleunigungsmesser für Fahrgeschäfte (/showthread.php?tid=421)
Beschleunigungsmesser für Fahrgeschäfte - MinesBoom - 10-08-2019
Hallo, ich bin neu hier im Forum und hatte zunächst nach vorhandenen Threads in der Richtung gesucht, aber nichts gefunden.
Meine Idee ist, dass man zwar einfach einen Beschleunigungssensor während einer Achterbahnfahrt o.ä. mitlaufen lassen kann, allerdings hat man dann keine Informationen darüber, wo/wann man sich während der Fahrt befindet.
Aus diesem Grund muss man irgendwie wichtige/interessante Stellen markieren können (Ruheposition am Anfang,...).
Meine Idee war es, den Mikrofon-Pol des Heatset-Anschlussen einfach auf GND zu ziehen (wie es die Pause-Taste eines Headsets macht)
Erste Tests mit einem Heatset und dem vorinstalliertem Experiment "Audio Spektrum" ergaben, dass in der Historie der Fourier-Transformation eindeutige Balken auftauchten, immer wenn ich den Pause Knopf am Headset betägte.
Allerdings stieß ich dann, als ich einfach eine Audio-Quelle im eigenen Experiment hinzufügte auf das Problem, dass bei der anschließenden Auswertung lediglich ein (mir) nichtssagendes Wellenmuster auftauchte und teilweise bis zu 45% der Audio-Messwerte fehlten (bei einem Buffer von 1000 (Standart-Größe) waren in der Tabelle ab Zeile 560 oder so nur noch "NaN".
Daher meine Frage: Sind die Werte in der Tabelle Zeitbasiert oder werden die anders (also z.B. von den Beschleunigungs-Messwerten abweichend) in der Tabelle abgespeichert?
Erklärung zu den Bildern:
fig. 1: Wie ich die Audiosignale aufgenommen hatte
fig. 2: Die Messwerte vom "Mikrofon" als Graph dargestellt (etwa ab 450 hatte ich immer wieder den Mikrofon-Pol auf GND gezogen)
RE: Beschleunigungsmesser für Fahrgeschäfte - Sebastian Staacks - 10-08-2019
Willkommen im Forum!
Um eine nahtlose Aufnahme in phyphox zu erreichen, muss man wissen, wie der Puffer genau gefüllt und wieder ausgelesen wird. Phyphox führt die Anordnung unter "Analysis" periodisch durch und nimmt dazwischen die Audiodaten in einen internen Puffer auf. Jedes mal, wenn der Analysis-Block ausgeführt wird, wird alles was phyphox in der Zwischenzeit aufgenommen hat in den Puffer geladen, den man im Editor verbunden hat, (wobei dessen Inhalt überschrieben wird) und der interne Puffer wieder geleert.
Das Problem in dem Beispiel ist nun (wahrscheinlich), dass im "Main"-Tab "sleep" auf 0 steht. Dadurch wird der Analysis-Block mit der höchstmöglichen Rate durchgeführt und der interne Puffer sammelt gar nicht erst 1000 Werte. Es liegen immer mindestens 10ms zwischen den Durchgängen, was bei 48kHz nur 480 Werte sind - in der Praxis sind es ein paar mehr, da das Smartphone auch etwas rechnen muss, aber wenn es kein lahmes Handy ist, wird das nicht viel mehr.
Um den Puffer ganz zu füllen muss einfach unter "main" durch ein vorgegebenes Delay dafür gesorgt werden, dass phyphox wartet bis genug Werte da sind.
Für die (wirklich sehr spannende Anwendung) ist es aber nötig, dass keine Samples verpasst werden und da hätten wir mit einem entsprechend hohen Delay statt dessen das Problem, dass mehr als 1000 Werte aufgenommen und dadurch welche verpasst werden. Statt dessen kann man eine nahtlose Aufnahme erreichen, indem bei kleinem Delay (kann dann auch ruhig auf Null bleiben) die Werte mehrerer Durchgänge zusammengefasst werden. Dazu kann einfach ein "append" dazwischen gepackt werden. Dabei muss dann beim Ausgang von "append" die Einstellung "clear" auf "disabled" gesetzt werden. Dadurch werden neue Werte immer weiter dazu gepackt. (Nicht übertreiben: Das Smartphone muss die schließlich noch zeichnen können.)
Das wiederum ist aber nur gut zum ansehen der Daten. Damit hat man nun einen schönen großen Puffer, bei dem man sogar sehen kann, wie die aufgenommenen Daten nach links laufen, wenn das Handy mit einem 10 Sekunden-Puffer (480.000 Werte!) klar kommt. Damit kann man hoffentlich sehen, was passiert wenn man den Knopf drückt (muss gestehen, dass ich da nicht sicher bin, was ich erwarte), aber um nachher in den Daten nach dem Auslöser zu suchen, ist das keine so gute Idee, da man dann einen riesigen Puffer durchsuchen muss.
Da wiederum ist die ursprüngliche Version sogar ideal:
Da der Puffer nie ganz voll läuft, sollten eigentlich keine Werte verpasst werden und das Handy kann sich in jedem Durchgang bequem um die 560 Werte kümmern. Ich würde den Puffer sogar noch ein Stückchen vergrößern, so dass auch nichts verpasst wird, wenn ein Durchlauf mal etwas länger braucht.
Je nachdem, wie das gesuchte Signal aussieht, kann man dann in den 560 Werten beispielsweise mit "max" schauen ob eine Spitze aufgetreten ist oder ob die Werte durch die Erdung durchgängig auf Null lagen und dann kann man über "if" den Wert aus einem "timer"-Modul in einen weiteren Puffer scheiben und so die Zeitpunkte speichern, wann gedrückt wurde.
Einfach die komplette Audiospur aufzeichnen dürfte leider keine Option sein. Eine einminütige Fahrt würde 48.000*60=2.880.000 Werte generieren. Das ist bei einer Audio-Software in einem binären Format (typisch wären hier 16bit = 2 Byte pro Sample, als MP3 komprimiert noch viel weniger) absolut kein Problem, aber in einem Text-Format oder als Excel-Tabelle wird die Export-Funktion wahrscheinlich nicht mit so vielen Werten klar kommen.
Jetzt bin ich mal gespannt, wo hin sich die Idee entwickelt...
RE: Beschleunigungsmesser für Fahrgeschäfte - MinesBoom - 10-10-2019
Zunächst muss ich mich bei Sebastian bedanken für die hilreichen Hinweise, auch wenn ich bis jetzt noch nicht alle umgesetzt habe (muss mich noch mehr in PhyPhox reinarbeiten).
Jetzt aber eine neue Sache, die mir aufgefallen war:
Nach einem kurzen Test (ich hatte ein Heatset mit ausgebautem Mikrofon in der Klinkenbuchse) ist mir aufgefallen, dass ich einen deutlich stärkeren Auschlag bekomme, wenn ich in der Nähe vom eingebauten Mikrofon (also das im Smartphone selber) mit meinen Fingern schnipse (bis zu +/-0,5) als wenn ich den Knopf im Headset drücke (vom Mikrofon weg gehalten, maximal +/-0,001 oder so). Aufgrund desses vermute ich, dass die App sowohl die Werte vom eingebautem Mikrofon als auch von Heatsets mitschneidet (den genauen Grund kenne ich [noch] nicht, es kann ja auch am Gerät selber liegen oder gar am Betriebsystem)
Da ich morgen in einem Freizeit-Park bin (ich war am Sonntag aufgrund dessen auf die Idee gekommen, die Fahrten mitzuschneiden) werde ich mich lieber nach dem Besuch genauer damit beschäftigen, habe dann aber (hoffentlich) ein paar Werte (gerade vom Mikrofon), mit denen ich weiter machen kann.