Posts: 1
Threads: 1
Joined: Jun 2024
Institution: Halbleiterlabor der MPG
Hallo, ich möchte zum Mitschreiben einer Druckmessung den Zeitpunkt als absolute Zeit (Systemzeit oder UTC oder ähnliches) rausschreiben, um die Werte mit meteorologischen Werten vergleichen zu könnnen. Die Zeitangabe muss
nicht genau sein, auf ein paar Sekunden kommt es dabei nicht an. Die Angabe von timeOnX="true" im xml file
nach <graph hat bei mir leider nichts bewirkt. Vor allem bräuchte ich die Zeiten auch in der exportierten Liste .
Grüße
Posts: 523
Threads: 24
Joined: Apr 2020
Institution: RWTH Aachen University
Die Einstellungen an den Graphen ändern nichts daran, wie die Daten exportiert werden. Zeiten werden von phyphox intern als einzelne ganze Zahl verwaltet und das ab Messbeginn, weil es in den meisten Fällen ein geeigneter Referenzpunkt ist. Eine absolute Zeit ist sowohl intern als auch im Export schwierig, da phyphox keine Zeichenketten in Containern unterstützt.
Seit gut drei Jahren (auf Wunsch unserer Geophysiker, soweit ich mich erinnere) wird aber in den Metadaten beim „Daten exportieren“ über das „⋮“-Menü die absolute Startzeit der Messung gespeichert. In Kombination mit der Zeitspalte ergibt sich so das Gewünschte, oder? Die Metadaten fehlen allerdings, wenn individuelle Graphen exportiert werden – das scheint mir auch schwierig zu lösen zu sein…
Smartphone-Uhren sind nicht sonderlich gut synchronisiert und können einige/viele Sekunden daneben liegen. Einen Einblick gewährt
https://time.gov – und irgendwo auf der TODO-Liste steht auch, dass wir mal darüber nachdenken, ob/wie wir die Zeitreferenz in phyphox verbessern…
Posts: 7
Threads: 1
Joined: Jun 2024
Quote:da phyphox keine Zeichenketten in Containern unterstützt
Hallo zusammen,
ich arbeite auch grad an einem Langläufer-Experiement für das ein Concatenate-Container sehr hilfreich wäre.
Um auf dem Display Zeilen einzusparen würde ich gerne einen leicht lesbaren Zeitstempel im Format "<HH> h <MM> m <SS> s" oder "<hh>:<mm>:<ss>" ausgeben.
Das wäre ein Container, bei dem man als "Value" Strings eingeben könnte und der einen zusammengesetzten String ausgeben würde für die Benutzung im "View" oder im "Export". Der Aufwand wäre dann aber doch schon bei der impliziten Formatumwandlung von Zahl nach String, da müsste man wohl eine Formatierung mit eingeben können. Hmm, wahrscheinlich macht das nur Sinn, wenn es gleichzeitig auch einen cast-Container gäbe, der einen Zahleninput zusammen mit einer Formatanweisung in einen Ausgabe-String umwandelt. Ist doch immer mehr als man erst denkt. Eine alternative Implementierung könnte ein neuer View-Typ "concatenate" sein, bei dem man entsprechend Input-Variablen und Formatanweisungen zusammenführt; das würde aber beim Export nicht helfen. Wollte es nur als Anregung mal posten.
Viele Grüße, Trikes.
Posts: 523
Threads: 24
Joined: Apr 2020
Institution: RWTH Aachen University
Wir haben Format-Strings mal auf die TODO-Liste geschrieben, da uns spontan ein paar weitere schöne Anwendungsfälle einfallen. Vermutlich wird es auf ein aufgebohrtes Value-Element hinauslaufen, das problemlos mehrere Input-Elemente verträgt.
Kurze Anmerkungen zu Langzeitmessungen: phyphox wurde nicht wirklich damit im Hinterkopf gebaut und je nach Datenmenge schickt der „out-of-memory killer“ die App recht herzlos ins Nirvana. Die Näherungssperre in den Einstellungen ist praktisch, damit eine Messung nicht versehentlich gestoppt wird, aber das Display ist dann abgedunkelt…
Posts: 7
Threads: 1
Joined: Jun 2024
06-21-2024, 08:13 AM
(This post was last modified: 06-21-2024, 08:14 AM by Trikes.)
Ein wenig off-topic, bitte nicht so genau nehmen:
Quote:Langzeitmessungen
Wahrscheinlich wäre die Laufzeit meines Experiements so bis maximal 3 oder 4 Stunden; solange ich halt auf dem Rad unterwegs bin. Werde zu dem Experiment noch Fragen separat posten, deswegen hatte ich mich ja die Tage hier im Forum angemeldet. Klar, das Betriebssystem des Handy macht die Vorgaben, auch was den Akkuverbrauch angeht.
Quote:Näherungssperre
Würde die auch durch starken Regen ausgelöst werden; vielleicht gibt es dazu schon Erkenntnisse. Neulich bin ich in Regen geraten und die Regentropfen haben nach über 90 Minuten das Experiment beendet und die Phyphox-App geschlossen ohne dass die Daten gespeichert werden konnten. Vielleicht eine Touchsperre für bestimmte Bereich des Bildschirms, die durch ein besonderes Wischmuster oder einen Tipprythmus oder durch einen Tastendruck (laut/leise/ein) gelöst werden könnte. Sicher, meistens wird die App nicht im Regen benutzt. Wollte es nur mal loswerden. Merci.
Posts: 523
Threads: 24
Joined: Apr 2020
Institution: RWTH Aachen University
(06-21-2024, 08:13 AM)Trikes Wrote: Quote:Näherungssperre
Würde die auch durch starken Regen ausgelöst werden; vielleicht gibt es dazu schon Erkenntnisse. Neulich bin ich in Regen geraten und die Regentropfen haben nach über 90 Minuten das Experiment beendet und die Phyphox-App geschlossen ohne dass die Daten gespeichert werden konnten. Vielleicht eine Touchsperre für bestimmte Bereich des Bildschirms, die durch ein besonderes Wischmuster oder einen Tipprythmus oder durch einen Tastendruck (laut/leise/ein) gelöst werden könnte. Sicher, meistens wird die App nicht im Regen benutzt. Wollte es nur mal loswerden. Merci.
Ich würde eher davon ausgehen, dass der Hauptspeicherbedarf von phyphox als zu groß angesehen wurde. Je nachdem was und wieviel Daten gesammelt werden, sammelt sich bei 100 bis zu 500 Hz ganz gut etwas – und phyphox ist in dieser Hinsicht nicht sonderlich optimiert.
Die Grenzen bei „Sperren“ liegen vermutlich beim OS, dass aus guten Gründen nicht will, dass Apps komplett die Kontrolle übernehmen. Bisher gibt es in phyphox keine Infrastruktur, um im Hintergrund zu laufen, so dass sich das vielleicht über Widgets lösen ließe. Bei iOS könnte es sogar grundsätzlich nicht zulässig sein, da Apple – auch aus verschiedenen guten Gründen – Apps darin einschränkt. Wir sind leider weder Audio- (Messen mit Musik?) noch Fitness- (ja, YMMV) App…