Timing: Zeitkritische Daten via ESP8266 versenden

Hallo zusammen,

vielleicht erinnert der Eine oder die Andere sich noch an meinen Beitrag von Anfang des Jahres: Konstante Abtastrate für Beschleunigungssensor definieren - Deutsch - Arduino Forum. Hierbei ging es um einen analogen Beschleunigungssensor dessen Daten mit einer konstanten Abtastrate erfasst werden sollten. Mit Hilfe - maßgeblich von serenifly & combie konnte ich das sehr gut zum Laufen bringen.

Der nächste Schritt ist das kabellose "Versenden" der Messdaten über ein ESP8266-Board via UDP nach Labview. Grundsätzlich funktioniert das auch (Code ist beigefügt). Ich kann die Daten in Labview empfangen und meine Analyse machen. Als Hardware nutze ich ein "Pretzelboard", oder "NanoESP" (Alles über NanoESP & Pretzel Board - Internet of Things mit dem NanoESP) Bevor ich jedoch ins Detail gehe, würde ich gerne mit Euch -bzw. mit denen die Lust drauf haben- noch einige Dinge zur Architektur diskutieren, um gleich den richtigen Weg zu gehen bezüglich des Timings, bzw. um es richtig zu verstehen. Letzteres ist mit am Wichtigsten.

Ich stelle dazu einmal ein paar Fragen:

• Die erste Frage betrifft das Zusammenspiel zwischen dem dem Lesen des ADCs und dem Versenden der Daten. Wenn ich das richtig verstanden habe, kommuniziert der ESP wiederum über die SoftwareSerial-Schnittstelle mit dem Arduino. Hier kam mir die Frage, ob es dabei zu Timing-Problemen kommen kann? Oberste Priorität ist ja immer noch die konstante Abtastrate für meine FFT in Labview. Anderst gefragt: Wenn ich einfach sendUDP(String(x)+String(y)+String(z)+";");  in die Funktion printData() einfüge, ist das der korrekte Weg? Siehe auch Abbildung anbei. Bedenken hätte ich, da ja hier detektiert wird, ob Werte von der ADC-Wandlung vorhanden sind oder nicht und diese dann auf die Serial-Schnittstelle geschrieben werden. Von dort hole ich Sie dann mit einer bestimmten Baudrate ab und verknüpfe Sie mit dem ESP. Ich denke, dass es hier -zumindest bei längerem Betrieb- zu Problemen bezüglich des Timings kommen kann, oder ist das tatsächlich der korrekte Ansatz? Hintergrund ist auch, dass ich bei der kabelgebundenen Lösung eine Baudrate bei der Hardware-Serial-Schnittstelle von 500000 eingestellt hatte, um in meiner Visualisierung in Labview alle Werte darzustellen.[/li]

• Meine zweite Frage ist, ob es unter Umständen ein Ansatz wäre, ein Array mit den korrekt abgetasteten Werten zu erstellen und dieses dann in bestimmten -nicht mehr zeitkritischen Abständen- an den ESP8266/Labview zu schicken

• Eine weitere Frage, die ich mir gestellt habe: Es existieren auch Beispiele (die mit den ESP8266-Bibliotheken mitgeleifert werden) die via UDP-Werte direkt versenden, ohne "Umweg" über die SoftwareSerial-Schnittstelle. Das war ursprünglich mein erster Versuch, hier scheiterte ich jedoch. Prinzipiell würde ich das bevorzugen, da keine neue Schnittstelle im Spiel ist und meines Erachtens das Timing damit besser beherrschbar wäre

Ich hoffe, ich konnte Euch mein Anliegen veranschaulichen. Meine grundsätzlich Frage ist "einfach": Wie mache ich eine saubere "Architektur" wenn ich auf die konstante -zeitrelevante- Abtastrate angewiesen bin.

Wenn Ihr noch Infos braucht, meldet Euch einfach. Im Voraus Euch allen vielen Dank und ich freue mich auf die Diksussion mit Euch!

Grüße

Bire

esp_FFT.ino (13.9 KB)

Ich kenne den NanoESP nicht, nur Nano und ESP über I2C gekoppelt.
SoftwareSerial kann störungsfrei meist nur 9600 Baud, dürfte also für Dich zu langsam sein.

Eine Trennung in zeitkritische Messwerterfassung und unkritische Übertragung ist in meinen Augen immer der bessere Weg. Welche Datenmenge müsste zwischengespeichert werden und wie oft soll die Messung laufen?

Wenn Du schon x,y,z per snprintf in buffer schreibst, warum überträgst Du nicht buffer, sondern setzt das über String nochmal neu zusammen?

Könntest Du die Messwerterfassung direkt auf dem ESP8266 machen?

Gruß Tommy

Hallo Thommy,

danke für Deine Antwort und Deinen ersten Hinweis.

Eine Trennung in zeitkritische Messwerterfassung und unkritische Übertragung ist in meinen Augen immer der bessere Weg.

Das würde ich auch so gerne umsetzen.

Welche Datenmenge müsste zwischengespeichert werden und wie oft soll die Messung laufen?

Zur Datenmenge (ich hoffe, ich kann es Dir richtig erklären): Ich denke, hier ist der Engpass meine Darstellung in Labview...Bei der kabelbasierten Version habe ich wie geschrieben die Daten mit 500000 Baudrate "weggeschaufelt" und dann in meiner Darstellunggschleife in Labview (mit Schleifendurchlaufzeit 1ms) wenn ich hier zu lange mit dem Lesen warte, kommt es irgendwann zu einem Überlauf, da zu viele Daten ankommen und die Darstellung zu langsam ist. Das ist das zeitkritische Element. Die FFT mache ich dann in einer parallelen Schleife mit einer Queue (das ist dann nicht mehr zeitkritisch). Ich denke, ich muss die Datenmenge an diese Gegebenheiten anpassen, d.h. dass es zu keiner Verzögerung kommt und ich sichergehen kann, dass ich alle Daten in meinem Labview habe, wieviele ich jedoch konkret brauche, kann ich Dir nicht sagen. Gefühlsmäßig würde ich sagen, dass ich jede Sekunde ein Array von 2000 Samples schreibe (in dem auch wirklich alle Daten vorhanden sind), diese versende und dann in Labview darstelle und analysiere. Meinst Du, das passt so? Problem wird hier sein, dass ich auf einen Schlag die 2000 Samples über den ESP versenden kann. Ich hoffe, ich habe Deine Frage richtig aufgefasst. Wenn nicht, frage bitte einfach nach!

Wenn Du schon x,y,z per snprintf in buffer schreibst, warum überträgst Du nicht buffer, sondern setzt das über String nochmal neu zusammen?

Das stimmt natürlich, werde ich nachher einpflegen, wenn unser Kleiner im Bett ist. Danke!

Könntest Du die Messwerterfassung direkt auf dem ESP8266 machen?

Grundsätzlich ja, das war sogar der erste Ansatz, aber hier bin ich an der Datenübertragung zum Labview gescheitert. Die mitgelieferten Beispiele (WifiWebserver / Client) benötigen alle eine Client-Server-Architektur in Labview, was ich nicht hinbekommen habe. Einzig mit UDP, bzw. mit dem Beispiel aus dem o.g. Link habe ich die Daten rüberbekommen. Zudem kommt, dass ich den Code für die analogen Sensoren schon fertig habe, den würde ich gerne nutzen, da dieser einwandfrei funktioniert und der ESP hat nur einen Analogeingang...

Dir ersteinmal vielen Dank, bis später und Grüße

Bire

Meiner Meinung nach ist der NanoEsp die schlechtest mögliche Variante der Kopplung zwischen beiden Systemen, da sie wohl über Softserial und AT-Befehle geht.

Meine Anmerkung mit Softserial und max. 9600 Baud hast Du geflissentlich ignoriert.
Wenn Du das Teil nutzen willst, dann musst Du auf dem Nano zwischenspeichern. Da fallen mir nur FRAM über I2C oder besser SPI ein, z.B. MB85RS256 (256 kBit).
In wieweit der Nano das Speichern von der Geschwindigkeit her schafft, weiß ich nicht, ich kenne nur die I2C-Variante mit 400 khz und das dürfte auch zu langsam sein.

Ein ESP8266 könnte das Speichern im SPIFFS schaffen - aber nicht Deine Krücke. Das müßte man testen.
Dazu sollte man aber z.B. einen WEMOS D1 mini pro benutzen.
Der kann auch problemlos per UDP kommunizieren (der andere evtl. auch, da gibt es wohl nur nichts für C&P). Ich habe mir die AT-Befehle nie angetan.

Ich habe sonst nix mit zeitkritischen Sachen am Hut, deshalb kann ich da nur wenig Erfahrung beisteuern.
Aber eins ist sicher: Über softserial zum ESP, da kannst Du die Bytes auch auf dem Zettel rüber reichen, das ist schneller.

Gruß Tommy

Hallo Tommy,

danke für Deine Antwort. Auch wenn Du mich sehr ernüchtert hast. Das war quasi meine einzig -von mir umsetzbare Variante- . Du meinst also, dass ich so gar nicht erst anfangen soll?

Meiner Meinung nach ist der NanoEsp die schlechtest mögliche Variante der Kopplung zwischen beiden Systemen, da sie wohl über Softserial und AT-Befehle geht.

Dass das mit den AT-Befehlen nicht ideal ist, habe ich fast befürchtet... Ich würde die auch gerne weglassen . Das heißt, ich muss tatsächlich erst über eine andere Variante die Daten vom Arduino zum ESP schicken und dann vom ESP zum Labview?

Zum D1 mini Pro: Das hat erstmal nichts mit dem Arduino zu tun, oder? Ich würde halt möglichst gerne den Arduino-Code für die ADC-Wandlung weiter nutzen, da mich das auch einige Mühen und viel Zeit gekostet hat.

Deinen Hinweis zur Baudrate habe ich nicht bewusst ignoriert. Ich dachte nur, dass ich dann einfach mit dieser niedrigen Baudrate die Daten zum Labview schicken kann (wenn ich das mit dem Array hinbekommen würde).

Vielen Dank Dir

Grüße

Bire

Guten Abend,

ich bin es nochmal. Nach einiger Recherche und nach nochmaligem In-Mich-Gehen glaube ich, dass ich einen grundlegend falschen Anstatz verfolgt habe. Mein globales Ziel war ja, dass ich die Daten -die ja schon korrekt auf der seriellen Schnittstelle liegen- über eine integrierte Lösung (Arduino+ESP8266) -um den Arduino-Code verwenden zu können- über Wifi/UDP an meine externe Applikation (Labview) sende. Das scheint es mit nur einer Schnittstelle Board --> Labview für eine derart zeitkritische Applikation nicht zu geben, oder?

Es ist wohl so, dass ich mich mit der Programmierung des ESP8266-Prozessors auseinandersetzen muss, oder? Eine direkte, durchgängige Lösung, die ohne AT-Befehle, bzw. die SoftwareSerial-Schnittstelle auskommt existiert offensichtlich nicht. Das heißt, für meine Applikation muss ich immer mit zwei Schnittstellen umsetzen 1. Arduino --> ESP 2. ESP --> Labview, oder?

Ein Breakout-Board, welches meine Anforderungen erfüllt: Direkte Anbindung ESP/Arduino mit entsprechender Performance existiert demnach auch (noch) nicht?

Vielleicht noch eine Zwischenfrage: Ist der Prozessor des ESP vergleichbar mit dem Atmega vom Arduino? Dann könnte ich wenigstens Teile des Codes weiterverwenden.

Ich hoffe, ich konnte Euch mein Anliegen erklären. Auch wenn meine Lerknkurve in den letzten Montaten sehr steil war, bin ich doch immer noch von der Ausbildung Maschinenbauer... Wenn hier noch weitere Entwicklungsschritte auf mich zukommen, muss ich vielleicht das Gesamtkonzept überdenken...

Danke nochmal an alle

Grüße

Bire

Der ESP8266 ist ein völlig anderer Prozessor, als der Atmega328 oder andere Arduino. Er ist ein 32-Bit-Prozessor und im Vergleich zum Arduino sehr leistungsfähig. Mehr RAM, mehr Flash, 80 oder 160 Mhz Prozessortakt aber nur 1 analogen Port und weniger digitale IO.

Wenn hier jemand etwas zur möglichen I2C-Geschwindigkeit des 328 sagen könnte, könnte man über weitere Möglichkeiten nachdenken oder über die SPI-Anbindung von FRAM.

Gruß Tommy

Guten Morgen Tommy,

vielen Dank für Deinen weiteren Hinweis. So wie es aussieht, werde ich das aber leider mit meinen beschränkten Kenntnissen nicht ohne Weiteres hinbekommen.

Ich werde nochmal etwas recherchieren und mich dann u.U. wieder melden, wenn ich etwas rausbekommen habe oder einen alternativen Ansatz umgesetzt habe.

Vielen Dank Dir noch einmal.

Grüße

Bire

Moin,

Du kannst die auch noch den ESP32 anschauen. Der kann noch mehr als der ESP8266.

Viel Erfolg!

Chris

Guten Abend,

ich habe heute noch mal einiges ausprobiert - wie angedroht ;). Anbei findet Ihr meinen neuen Versuch. Nachdem Ihr mich überzeugt habt, dass das über die SoftwareSerial-Schnittstelle und die AT-Kommandos nicht zielführend war, bin ich den Weg gegangen, den Ihr beide (themanfrommoon und Tommy) angedeutet habt: Die Datenerfassung direkt auf dem ESP zu machen. Ich habe dazu bei uns noch ein NodeMCU 12E-Modul gefunden.

Zunächst einmal: Ich weiss nun nicht so recht, ob ich hier im Arduino-Forum (noch) richtig aufgehoben bin, da es ja nun um einen anderen Controller geht. Ich würde trotzdem einmal gerne Eure Meinung einholen, bzw. ob ich auf dem richtigen Weg bin.

Folgender Stand:

Die Verbindung zu Labview via UDP ist wieder aufgebaut, auch ohne die AT-Befehle. Die für mich große Herausforderung war ja, dass ich den bestehenden Arduino-Code (mit dem Hardware-Timer) nutzen wollte. Das musste ich ja nun auch verwerfen. Stattdessen habe ich eine Timing-Bibliothek aus Ich bin umgezogen. In der Loop-Schleife wird ständig überprüft, ob es zu einem "TickOccured" kam und dann wird der Wert via UDP verschickt. Bitte beachtet: Bisher ist kein Sensor angeschlossen. Meine simulierten Sensorwerte sind die Werte der "loopi"-Integers. Morgen/heute Abend muss ich dann noch den Sensor einbinden, weshalb an dieser Stelle dann noch 3x DigitalRead() Aufrufe kommen werden. Ich kann ja keinen Analogsensor nutzen, da der ESP nur 1 einen Analoginput hat. Der maßgebliche Code-Abschnitt ist folgender:

void loop()
{

 if (TickOccured){
    
    loopi++; 
    
    // set all bytes in the buffer to zero
    memset(packetBuffer, 0, UDP_PACKET_SIZE);                         // reset packetBuffer
    sprintf((char*)packetBuffer,"%i %i %i;",loopi,loopi+5,loopi+10);  // write sensor data to string

    // start data transfer via UDP
    Udp.beginPacket(ip, recPort);
    Udp.write(packetBuffer,UDP_PACKET_SIZE);     
    Udp.endPacket();

    // only for testting
    Serial.println();
    Serial.println("Tick Occurred");
    Serial.print("Millis: "); Serial.println(millis());
    Serial.print("Counter: "); Serial.println(Counter);
    
    TickOccured = false;
 }
 delay(0); 
}

Jetzt zu meinen Fragen:

• Meint Ihr, das ist nun zielführender? Vom Grundkonzept her gesehen. Meint Ihr, das wäre zumindest eine solide Grundlage um weiterzumachen? Wichtig ist ja das Timing. Werden die Daten hier tatsächlich mit der eingestellten 1ms "erfasst" und über UDP verschickt?
• Was haltet Ihr von dem Timer den ich eingesetzt habe? Bei der alten Lösung hatte ich ja einen Hardware-Timer. Hier konnte ich sicher sein, dass meine Werte mit 2000 Hz gesampelt wurden. Diese habe ich dann mit einer enorm hohen Baudrate weggeschickt und dann in Labview verarbeitet. Jetzt versuche ich ja Ähnliches nur mit einem Software-Timer. Ist dieser Timer aber genauso stabil/sicher? Wahrscheinlich nicht, denn das ist kein Hardware-Timer, oder? Ich habe aber an einigen Stellen gelesen, dass der Hardware-Timer nicht eingesetzt werden soll, da er ausschließlich von der ESP8266-Bibloithek genutzt werden sollte...
• Ich bin auch noch über eine Ticker-Bibliothek gestolpert...Habt Ihr hierzu Erfahrungnen?
• Bei meinen Tests ist mir aufgefallen, dass ich bei der Initialisierung des Timers bei os_timer_arm(&Timer1,1, true);
  als Minimalwert 1ms eingeben kann. Ich müsste ja aber auf 0,5ms runter, um auf meine Abtastrate zu kommen... Sind Euch hier Beschränkungen bekannt?
• Wenn ich nun tatsächlich in zeitliche Beschränkungen / Probleme laufe. Wäre es doch hier ein Ansatz mit einem Array zu arbeiten und dieses dann nur "zeitweise" zu versenden, d.h. nicht bei jedem Auftreten des Timers die Werte zu versenden, sondern nur in das Array zu schreiben?

Ihr seht, ich habe Eure Hinweise aufgenommen und -hoffentlich- auch so wie Ihr meintet umgesetzt. Es würde mich sehr freuen, wenn Ihr noch einmal Lust habt und mir ein paar Hinweise geben könntet.

Ich bedanke mich bei allen, die bisher geholfen haben. Vielleicht bis später!

Grüße

Bire

UDP_Web_Forum.ino (2.43 KB)

Auch mit ESP8266 bist Du hier richtig.

Ich verstehe nicht, wie Du von AnalogRead beim Arduino auf 3xDigitalRead kommst. Ansonsten gibt es Analogmultiplexer.
Du kannst aber auf dem ESP ein SPIFFS-Laufwerk einrichten und dort Deine Werte in einer Datei zwischenspeichern.

Zur Geschwindigkeit kann ich wieder nichts sagen.

Tip zur Verkürzung der Sendung:

// anstelle immer den ganzen Puffer zu senden
Udp.write(packetBuffer,UDP_PACKET_SIZE); 
// könntest Du nur den belegten Teil senden
Udp.write(packetBuffer,strlen((char *)packetBuffer)+1));  // +1 wegen abschließendem 0-Byte

Gruß Tommy

Hallo Tommy,

danke für Deine schnelle Antwort. Kurz zu den Analog-Digital-IOs: Ich hatte einen Drei-Achsen-Beschleunigungssensor (analog). Diesen muss ich nun mit einem gleichwertigen digitalen Sensor ersetzen, deshalb DigitalRead. Es waren jedesmal drei Achsen, sorry, da hatte ich mich mißverständlich ausgedrückt.

Danke für Deine Hinweise. Das mit dem SPIFFS-Laufwerk werde ich mir gleich anschauen und selbstverständlich auch Deinen Hinweis einbauen.

VIELEN DANK

Grüße

Bire

Der digitale Sensor liefert aber nicht 3 Mal je 1 Bit (diegitalRead liest auf einem Eingang Low oder HIGH - mehr nicht) für die 3 Werte. Ich glaube Du hast da etwas Grundlegendes nicht verstanden.
Gib uns mal einen Link zu dem digitalen Sensor.

Gruß Tommy

Hallo Tommy,

sorry, hat etwas gedauert...Das kann sein, dass ich das nicht richtig kapiert habe. Mit digitalem Sensor meinte ich so eine wie den hier. Diesen Sensor nutze ich gerade. Ich benötige ja einen, der nicht analog ist. Dieser nutzt die I2C-Schnittstelle. Ich nutze auch die beiliegende Bibliothek. Diese liefert mir auf Anforderung -eben wenn ein "TickOccured" auftritt einen Wert, der dann idealerweise korrekt abgetastet ist. Sehe ich das falsch?

Wenn das nicht so ist, muss ich doch multiplexen und versuchen auf den Hardware-Timer zu gehen, um 1:1 die alte Lösung zu erhalten.

Wäre super, wenn Du noch einmal Lust hättest. Ich möchte das ja wirklich kapieren.

Vielen Dank Dir und Grüße

Bire

SparkFun_MMA8452Q_Basic.ino (111 KB)

Du solltest Deinen Code direkt in Codetags in den Beitrag einstellen (</>-Button im Forumseditor oder [code] davor und [/code] dahinter - ohne *).
I2C ist ok, das hat aber nichts mit digitalRead zu tun und ich weiß nicht, ob es schnell genug ist. Das musst Du ausprobieren. Der IC kann 400kHz Taktrate, das könnte passen.

Eine solche Echtzeitanforderung mit vergleichsweise so geringen Grundkenntnissen ist schon ziemlich sportlich.

Gruß Tommy

Hallo,

Du hast völlig recht:

Eine solche Echtzeitanforderung mit vergleichsweise so geringen Grundkenntnissen ist schon ziemlich sportlich.

Ich hoffe, Du siehst aber, dass ich mich bemühe. Ich möchte das wirklich verstehen, deshalb meine Nachfragen. Du meinst also, das "könnte klappen"?
Was mir immer tatsächlich etwas schwerfällt ist das "Timing" der Mikrocontroller / Prozessoren im Ganzen zu verstehen, z.B. was macht denn der Timer genau, was passiert parallel, wenn z.B. wie hier auf die I2C-Schnittstelle zugegriffen wird, wie lange dauert ein Analogread(), usw. Leider findet man in den Einstiegsbüchern / Beispielen meist nur die Lösung und keine Hintergründe. Hättest Du da vielleicht einen Tipp, oder einen Literaturhinweis, vielleicht auch "nur" ein paar Stichworte für eine Recherche. Ich denke Du bist vom Fach, oder? Bei mir ist das immer nur Add-On-Geschäft - leider...

Vielleicht hast Du ja noch einmal Lust mir zu antworten

Viele Grüße

Bire

Wie schon gesagt, mit harten Echtzeitanforderungen habe ich mich nie beschäftigt. Es gab / gibt keinen Grund für mich dazu. Da wissen andere User mit Sicherheit mehr dazu.

Genaue Daten dazu bekommst Du nur aus dem Studium der Datenblätter und der Erfahrung von Usern, die schon mal auf der Geschwindigkeitsschiene geritten sind.
Ansonsten ausprobieren und messen.
Du hattest ja bereits eine Lösung, die funktioniert hat. Warum musst Du die auf WLAN umbauen?
Das wird ein längerer Evaluationsprozess ohne Garantie auf Erfolg.

Einstiegsbücher helfen da überhaupt nicht. Was Du willst ist meilenweit vom Einstieg entfernt.
Echtzeitgeschichten entwickelt man im Normalfall nach mindestens 1-2 Jahren Erfahrung mit vielen anderen Projekten.

Ich glaube, ich kann Dir an der Stelle kaum noch weiter helfen. Ich hoffe für Dich, dass andere mehr Erfahrung mit Hochgeschwindigkeit am ESP8266 haben.

Gruß Tommy

Hallo zusammen,

vielen Dank erst einmal Dir, Thommy für Deine Geduld. Ich habe mich noch einmal reingekämpft und mache noch einmal einen Versuch, vielleicht kommen doch noch ein paar Kollegen mit

mehr Erfahrung mit Hochgeschwindigkeit am ESP8266

dazu. Ich habe auch den Betreff entspreched geändert, ich hoffe, das ist ok.

Es wäre super, wenn der eine oder andere meine Gedankengänge bezüglich des Timings unterstützen/widerlegen würde:

Mittlerweile habe ich mir noch einmal das Datenblatt meines Sensors genauer angeschaut. Dabei ist mir aufgefallen, dass hier ja die Möglichkeit besteht, Hardware-Timer zu definieren. Diese sind sogar auf den Ausgängen 1 und 2 herausgeführt. Könnte ich damit etwas anfangen?
Ich habe heute etwas mit dem Beispielcode experimentiert, dabei bin ich über folgende "Flags" gestolpert, die -vielleicht- genau in meine Richtung gehen. Die Kommentare sind aus dem Quellcode.

  //  3. Initialize with FULL-SCALE and DATA RATE setting. If you
  //     want control over how fast your accelerometer produces
  //     data use one of the following options in the second param:
  //     ODR_800, ODR_400, ODR_200, ODR_100, ODR_50, ODR_12,
  //     ODR_6, or ODR_1. 
  //     Sets to 800, 400, 200, 100, 50, 12.5, 6.25, or 1.56 Hz.
  accel.init(SCALE_8G, ODR_6);

Hierzu meine Frage: Liege ich richtig, dass das die "Datenerfassungsrate" ist, die ich dann als Eingang für meine FFT nutzen kann?
Was mich betätigt, ist die Tatsache, dass die if-Abfrage in der Hauptschleife offensichtlich auf vorhandene Werte "wartet" und dann erst weitergeht

// The loop function will simply check for new data from the
//  accelerometer and print it out if it's available.
void loop()
{
  // Use the accel.available() function to wait for new data
  //  from the accelerometer.
  if (accel.available())
  {
    // First, use accel.read() to read the new variables:
    
    unsigned long currentMillis = millis();
    
    accel.read();
    
    // accel.read() will update two sets of variables. 
    // * int's x, y, and z will store the signed 12-bit values 
    //   read out of the accelerometer.
    // * floats cx, cy, and cz will store the calculated 
    //   acceleration from those 12-bit values. These variables 
    //   are in units of g's.
    // Check the two function declarations below for an example
    // of how to use these variables.
    printCalculatedAccels();
    //printAccels(); // Uncomment to print digital readings
    
    // The library also supports the portrait/landscape detection
    //  of the MMA8452Q. Check out this function declaration for
    //  an example of how to use that.

    Serial.println(currentMillis - previousMillis);
    previousMillis = currentMillis;
  }
}

Das bedeutet doch, dass ich tatsächlich die Werte gleichmäßig abgetastet erhalte, oder? Nur um es zu begreifen Wie muss man das dann verstehen, dass die if-Abfrage tatsächlich auf den Timer zugreift und mit dessen Takt auf neue Werte wartet?

Ich wollte das über die "Millis"-Abfragen überprüfen. Das ganze wird definitiv schneller, je höhere Werte man dem ODR-Flag gibt, allerdings bleiben die werden die Millis-Werte ab ODR = 50 bei einem Wert von 25 konstant und entspricht nicht mehr der Sollfrequenz, z.B. bei ODR_800 = (1/800) * 1000 = 1,25 ms? Bedeutet das, dass die Werte doch nicht mit 800 Hz aufgenommen werden, oder "nur" dass ich zu lange brauche um Sie zu lesen?

Nehmen wir an, das Ganze passt so. Wie würdet Ihr jetzt weiter vorgehen? Die Daten sind nun mit der korrekten Abtastrate erfasst, nun muss ich ja noch die Daten versenden, ein direktes Platzieren in die if-Schleife wäre vermutlich nicht zielführend (da mutmaßlich) die UDP-Kommunikation zu viel Zeit benötigt und dann unter Umständen der neue Wert auf die Kommunikation warten muss:

void loop()
{
 
  if (accel.available())
  {
     accel.read();
     printCalculatedAccels();
    
    // start data transfer via UDP   --> Vermutlich hier nicht richtig, oder?
    Udp.beginPacket(ip, recPort);
    Udp.write(packetBuffer,UDP_PACKET_SIZE);     
    Udp.endPacket();
  }
}

Oder sollte ich hier besser ein Array füllen, oder das SPIFFS-Laufwerk beschreiben? Vielleicht habt Ihr mir hier einen Hinweis zur "Architektur".

Die Ino-Datei liegt wieder unter der Library von Sparkfun. Das Datenblatt habe ich beigefügt.

Wenn Ihr noch etwas braucht, meldet Euch bitte. Es wäre super, wenn Ihr mit mir noch einmal diskutieren könntet, dann habe ich glaube ich eine reale Chance das hinzukommen und vor allem: zu verstehen!

Danke und alle und Grüße

Bire

MMA8452Q-rev8.1.pdf (1.11 MB)

Guten Abend,

ich habe noch einmal etwas "gehirnt" und auch die Hoffnung nicht aufgegeben, dass jemand meine Gedanken bestätigt oder verwirft. Ich habe einnmal versucht, das grafisch darzustellen (siehe anbei).

Wie im letzten Beitrag gemutmaßt, kann ich den Timer des Sensors als Trigger nutzen. Im Falle von 800 Hz (maximale Output-rate) erhalte ich also alle 1,25 ms einen Wert. Meine Idee wäre nun, eine gewisse Anzahl an Samples zu erfassen und diese dann bei einem gewissen Wert z.B. 100 Werten an Labview wegzuschicken.

Jetzt wäre meine Frage: Ist das zielführend, oder wäre es hier doch besser über das SPIFF-Laufwerk zu gehen.

Eine weitere Frage: Wäre unter Umständen ein Interrupt eine Idee? Ideal wäre ja ein Konstrukt, welches die Datenerfassung in der Schleife stetig weitermacht, und nur beim Auftreten eines Falles (in diesem Fall konkret wenn ein Index gleich einem vorgegebenen Wert nMax ist) wegzuschicken?

Es wäre wunderbar, wenn Ihr mir noch einmal auf die Sprünge helfen könntet. Ich bin wirklich bemüht das zu verstehen. Ich denke, der eine oder Andere hat doch bestimmt schon ähnliche Applikationen umgesetzt.

Ich freue mich über jeden Hinweis und sende Euch viele Grüße

Bire

Ablauf.png1251×1272 38.5 KB

Hi

Reine Theorie

Denke, das Sammeln kannst Du nur so weit treiben, daß Du in der 'Freizeit' die gesammelten Daten auch weg bekommst - zumindest, wenn Du 'Echtzeit' beibehalten willst.
Zumindest würde sich so der Overhead reduzieren lassen, als wenn Du jede Messung einzeln verschickst.

MfG