10-08-2019, 09:33 PM
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...
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...