Wenn Du nach x Paketen den Block sendest, kann es sein, dass diese Aktion Dir den Abstand zwischen den Messungen davor und danach verlängert.
Wie bestimmst Du eigentlich die reale Abtastrate? Die geht ja ins Ergebnis der FFT ein. Ich meine damit nicht irgend einen eingestellten Parameter.
Gruß Tommy
Hallo Tommy,
vielen Dank für Deine erneute Antwort. Ich bin gerade dabei, genau das zu machen, was Du meintest, nämlich die reale Abtastrate bestimmen. Ich nutze dafür micros(), und detektiere (in einer if-Abfrage) das Auftreten eines neuen Wertes, diese Zeit ermittle ich über:
void loop(void)
{
/* Get a new sensor event */
sensors_event_t event;
accel.getEvent(&event);
actVal=accel.getX();
// actVal = loopi;
if (actVal != prevVal){
duration = micros()-startTime; // wenn der Wert empfangen wurde
Serial.println(duration); // ...messe die Zeit
//Serial.println("Hello new value*********************************************************************************");
startTime = micros(); // start timer
}
duration = 0;
prevVal = actVal; // Aktueller Messwert wird zum alten Messwert
}
passt das? Ich werde gleich mal ein paar Tests machen und die Ergebnisse dann einstellen! Ich denke, hier liegt der Hund begraben. Meine Daten kommen schon nicht korrekt raus. Das Wegschicken sollte eigentlich schnell genug sein...?
Vielen Dank, freut mich wirklich, dass Du (noch) Interesse und Geduld mit mir hast!
Grüße
Christoph
bire:
Ich nutze dafür micros(), und detektiere (in einer if-Abfrage) das Auftreten eines neuen Wertes
Ist die Wahrscheinlichkeit dafür, dass nacheinander 2 Werte gleich sind null?
Gruß Tommy
Hallo,
danke für Eure Antworten! Erstens zu Deiner Frage Tommy:
Ist die Wahrscheinlichkeit dafür, dass nacheinander 2 Werte gleich sind null?
Meine Antwort: Wenn ich den Sensor richtig verstanden habe, bekomme ich doch damit einem "harten" Takt die Samples raus. Wenn ich nun in meiner Schleife (die ja viel schneller läuft als Werte ankommen, ich quasi oversample) ständig abfrage, ob sich der Wert geändert hat, sollte doch ausgeschlossen sein, dass ich in meiner if-Abfrage gleiche Werte bekomme, oder? Klar in der Schleife an sich können doppelte Werte vorkommen, Beispiel: Wenn ich mit 0,1 Hz abtaste, kommen 10 Sekunden diesselben Werte, meinst Du das?
Ich habe mittlerweile auch die Tests gemacht.
Das Ergebnis ist wieder teilweise erfolgreich. Ich habe mal folgende Frequenzen eingestellt:
| Abtastrate | 0,2 Hz | 12,5 Hz | 100 Hz | 800 Hz |
|---|---|---|---|---|
| Delta t [µs] | 5000000 | 80000 | 10000 | 1250 |
Mit meiner micros()-Abfrage sollte ich doch konstant die berechneten Werte für Delta t erhalten - eventuell etwas mehr, da ich ja mit Serial.println() etwas schreibe und noch "anderer"(?) Overhead, oder?
Die Ergebnisse seht Ihr anbei (jeweils ein Bild zur entsprechenden Abtastrate im Dateinamen). Die Werte stimmen "in etwa" es gibt aber deutliche Ausreisser (manchmal sogar die doppelte oder ein Vielfaches der Zeit), stabil und damit eine konstante Zeitbasis ist das natürlich nicht. Bei 800 Hz zeigen sich nahezu konstant fast doppelte Werte?
Was bedeutet das nun? Ist "nur" meine if()-Abfrage falsch oder habe ich etwas anderes nicht beachtet? Ich denke, ich bin wieder am Anfang: Wie bekomme ich eine korrekte Zeitbasis hin?
Wäre super, wenn Ihr mir ein paar Anstöße geben könntet, vielleicht fällt Euch ja was ein.
DANKE schon einmal und viele Grüße
Bire
ADXL345mitNodeMCU2.ino (4.49 KB)
Guten Abend,
ich hatte Euch ja am letzten Beitrag über meine Versuche berichtet. Leider bin ich noch nicht weitergekommen. Mittlerweile habe ich mir meinen Sensor einmal näher angeschaut und würde diese Erkenntniss gerne mit Euch diskutieren. Vielleicht hat der eine oder andere Erfahrungen mit dem Sensor ADXL345.
Zunächst einmal glaube ich, dass ich mit der I2C-Schnittstelle gar nicht auf meine hohen Abtastraten komme:
“Use of the 3200 Hz and 1600 Hz output data rates is only recommended with SPI communication rates greater than or equal to 2 MHz.”
(Auszug aus dem Datenblatt). Damit wäre ich wieder einen Schritt weiter. Nun habe ich überlegt, wie ich weiter vorgehen kann. Dabei bin ich auf Folgendes gestoßen:
Der ADXL345-Sensor hat zwei Pins mit Namen INT1 und INT2. Diese Pins können anscheinend so programmiert werden, dass sie mir das Vorhandensein von neuen Daten anzeigen (digital, HIGH oder LOW). Vermutlich muss ich dabei einen DATA_READY-Interrupt definieren.
Wenn ich richtig liege, muss ich diese Pins mit einem Eingang meines ESP verbinden und könnte so erkennen ob neue Daten vorliegen. Für diese Information wird dann über ein zusätzliches Kabel neben den schon vorhandenen SPI-Kabeln übertragen....?
Nun meine Frage: Meint Ihr dieser Ansatz wäre zielführend?
Wenn dem so wäre, wie würde ich das im Code umsetzen? Vor allem würde mich interessieren, wie Ihr bei der Gesamtarchitektur vorgehen würdet.
Wären Interrupt ein Ansatz? Ich stelle mir das so vor: Zunächst muss ich heraubekommen, welche Register ich im Sensor für die Definition des korrekten Verhalten beschreiben muss. Ich definiere anschließend einen normalen Interrupt. Wenn der Interrupt (im Takt der Samplerate) kommt, schreibe ich in diesem meine Daten via UDP weg. Hier habe ich schon die nächste Frage: Ich meine aber einmal gelesen zu haben, dass in einem Interrupt keine Einleseroutinen, z.B. Serial.read beinhalten sollten, da diese sehr lange brauchen. Könnte das bei meiner UDP-Kommunikation auch zu einem Problem werden?
Zusammengefasst: Ich denke, meine Lösung geht nur über die korrekte Einstellung des ADXL435.
Es wäre super nett, wenn Ihr mit mir noch einmal in die Diskussion einsteigen könntet, vielleicht hat jemand von Euch Erfahrungen den Registern dieses Sensors. Ich habe Euch das Datenblatt noch einmal angehängt.
Vielen Dank und vielleicht bis später!
Grüße
Bire
ADXL345.pdf (855 KB)
