Timing: Zeitkritische Daten via ESP8266 versenden

International Deutsch
21

Ich finde es immer als krank, Texte als Bild anzuhängen.

Wenn Du nach 100*1,25 ms die 100 Werte abschicken willst, wird evtl. Dein Messintervall darunter leiden.
Entweder testen, ob das Senden jedes Satzes (3 Werte) schnell genug ist oder alle Werte des gesamten Messzyklus speichern (Array oder SPIFFS - austesten) und nach Abschluß senden.

Wenn Du den Interrupt des IC nutzen willst, dann damit nur ein Flag setzen, als Zeichen, dass neue Daten da sind und diese dann im loop einlesen.

Also in etwa so:

volatile boolean neueMessung = false;
...

void ICACHE_RAM_ATTR interruptRoutine() {
noInterrupts();
if (!neueMessung) neueMessung = true;
interrupts();
}

// im loop:
if (neueMessung) {
  // da boolean neueMessung 1 Byte lang ist, wird es atomar behandelt, es ist also keine Interruptsteuerung notwendig
  //holeMesswerte und mache was damit
  neueMessung = false;
}

//im setup
attachInterrupt(digitalPinToInterrupt(DeinInterruptPin), interruptRoutine, flanke); // Flanke = RISING oder FALLING

Das Attribut ICACHE_RAM_ATTR ist eine Besonderheit des ESP8266 für Interruptroutinen, sonst stürzt er sporadisch ab.

Gruß Tommy

22

Hallo Ihr beiden,

wenn ich Eure Antworten recht interpretiere, dann ist der Ansatz zumindest nicht falsch - auch wenn Du Abbildung nicht schön ist :confused: Ziel ist dabei wie es postmaster-ino genannt hast: den

Overhead reduzieren

.

@postmaster-ino: Mit "Freizeit" meinst Du, die Zeit die ich verbrauche wenn ich die Daten wegschicke, oder?

@Tommy: Das mit den Zeiten werde ich morgen testen. Noch eine Nachfrage zu Deinem Kommentar:

//hole Messwerte und mache was damit

. Mit "Messung abholen" meinst Du die Daten per UDP versenden, oder?

Vielleicht noch einmal eine grundsätzliche Frage zum Ansatz: Dieser steht und fällt ja damit, dass durch den mutmaßlichen Timer des Sensors über die Abfrage accel.available() in der loop "hart" mit 800 Hz getriggert wird. Ist dem so? Wenn Ihr als Profis das bestätigt, weiß ich, dass ich auf dem richtigen Weg bin.

Vielen Dank Euch beiden.

Grüße

Bire

23

Hi

Mit Freizeit meine ich die Zeit, Die Du zwischen dem Erfassen von zwei Messungen und Deren Bearbeitung hast.
Mehr Zeit hast Du ja nicht, da Du mit dem Versenden fertig sein MUSST, bevor der nächste Messwert abgeholt werden will.
Sobald der nächste Messwert bereits VOR der Bereitschaft fertig ist, steuerst Du darauf zu, daß Dir einer der Messwerte bereits überschrieben wurde, bevor Du Diesen abholen konntest.
Wenn die Messungen extern gestartet werden - wenn Du die Messung selber nach dem verschicken startest, passiert Dir Das nicht, Du kommst dann halt nur aus dem Tritt - Deine Zeiten passen dann nicht mehr.

Das könnte man aber austesten, wie viele Messwerte Du übertragen kannst, bevor Dein Zeitfenster nicht mehr passt - 10% runter und Du hast noch etwas Luft.

MfG

24

Hallo postmaster-ino,

vielen Dank für Deine gute Erklärung. Noch mal zur Absicherung: Du meinst Du Zeit zwischen dem Aufreten des accel.available()-Falles und der Weiterverarbeitung (println, UDP-Kommunikation,...). Diese Zeit, die ich für die Weiterverarbeitung des Messwertes (beim Versenden eines einzelnen Messwertes) bzw. der Messwerte (beim Versenden von mehreren Samples, wenn ich diese wie vorhin geschrieben z.B. in einem Array sammle) benötige, darf (inklusive der Zeit, die für das Lesen der Samples an sich benötigt wird) nicht größer als meine 1,25 ms - 10% Puffer sein, oder?

Ich werde das morgen gleich mal austesten! Ich tendiere aber dazu, das mit dem Zwischenspeicher-Ansatz umzusetzen, da mir Dein Argument mit dem "Overhead" eingeleuchtet hat.

Danke noch mal und viele Grüße Bire

25

bire:
@Tommy: Das mit den Zeiten werde ich morgen testen. Noch eine Nachfrage zu Deinem Kommentar:. Mit "Messung abholen" meinst Du die Daten per UDP versenden, oder?

Wenn der ESP etwas holt, dann heißt das schon von der Sprache her nicht, dass er etwas versendet. Dann heißt das, dass er die Messwerte vom IC abholt.
Ob Du die dann auch sendest oder abspeicherst, hängt von Deinem Konzept ab.

Gruß Tommy

26

Guten Abend,

ich wollte Euch -oder die, die es interessier- nur kurz über meine weiteren Schritte informieren:

Mittlerweile habe ich nun endlich alle Komponenten zusammen, um einmal die Zeiten für die Übertragung zu testen. Zudem werde ich auch noch einen anderen Sensor (Datenblatt ist anbei) testen. Dieser hat ein höhere Samplerate (anscheinend bis 3200 Hz) und streamt die Daten, ohne eine die Events zu triggern, wie der andere. Ich werde beide einmal ausprobieren und Euch dann berichten - hoffentlich von einem Erfolg.

Eine Frage hätte ich jedoch noch: Ich habe mir gestern den ganzen Tag den Kopf zerbrochen, wie ich eine saubere Lösung für die "Konstruktion" meines Buffers (wenn ich nicht jedes Sample einzel verschicken möchte). Bisher versende ich ja einzeln. Ich müsste die Werte in jedem Schleifendurchlauf an meinen packetBuffer dranhängen. Habt Ihr da eine Idee?

const int UDP_PACKET_SIZE= 48;

byte packetBuffer[ UDP_PACKET_SIZE]; //buffer to hold incoming and outgoing packets 


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();
}

Ich würde gerne entweder einen solchen Buffer

Buffer = ("x y z; x y z;x y z;")

oder soetwas (mehrzeilig)

 Buffer = ("x y z;
           x y z;
           x y z;");

erhalten.

Ich hatte versucht, das über chars zu lösen, aber leider ohne Erfolg. Mir will es nicht gelingen, die jeweilige aktuelle Zeile an den bestehenden Buffer "dranzuhängen". Das ist sicherlich total einfach, aber ich habe mir hier gestern wirklich die Zähne ausgebissen.

Wenn ich das habe, kann ich einmal beide Wege ausprobieren: Das unmittelbare Versenden jedes Samples sowie das Versenden als Gesamtpacket von mehreren Samples

Vielleicht habt Ihr ja eine Idee. Ich freue mich über jeden Hinweis, dann kann ich am WE noch etwas weiterarbeiten.

VIELEN DANK Euch schon einmal. Ihr habt mir schon sehr weitergeholfen.

Grüße und Euch schon einmal ein erholsames Wochenende - wenn es soweit ist :slight_smile:

Bire

ADXL345.pdf (855 KB)

27

Entweder Du arbeitest über ein Array aus int mit 3 Mal Anzahl der Messwerte (schreibst also x,y,z immer hintereinander) oder Du schaust Dir mal struct an (3 int in einer Datenstruktur - das wäre dann Dein Datensatz) und ein Array aus diesen structs.
Die Länge ist in beiden Varianten gleich, in der 2. Variante sehe ich mehr Übersichtlichkeit.

Darin schreibst Du über einen Index Deine Messwerte. Wenn Du fertig gemessen hast, überträgst Du das häppchenweise (wegen UDP_PACKET_SIZE) an den PC.

Gruß Tommy

28

Hallo Tommy,

das hört sich super an! Danke!

29

Guten Abend Tommy,

ich war nach Deinem Hinweis noch fleißig und ich habe es -denke ich- umgesetzt. Wäre super, wenn Du mal noch einen Blick drauf werfen könntest ob das so passt. Die Werte kommen nun in Labview rein wie Sie sollen. Über das Timing muss ich mir noch Gedanken machen.

#include <ESP8266WiFi.h>
#include <WiFiUdp.h>
#include "Arduino.h"

// Timer library from http://bienonline.magix.net/public/esp8266-timing.html

extern "C" {
#include "user_interface.h"
}

os_timer_t Timer1;         // Verwaltungsstruktur des Timers
int Counter = 0;           // Argument für die Callback-Funktion
bool TickOccured = false;  // Flag, dass in der Callback-Funktion gesetzt wird
                           // Die aufwändigen und zeitintensiven Funktionen werden
                           // anhand dieses Flags im Hauptprogramm durchgeführt.


void timerCallback(void *pArg)
{ TickOccured = true;
  *((int *) pArg) += 1;
} 

const char* ssid = "+++++++++++";
const char* password = "++++++++++";

struct dirs{
  int x;
  int y;
  int z;
};

struct dirs accels[10];

WiFiUDP Udp;
unsigned int localUdpPort = 4210;  // local port to listen on
char incomingPacket[255];  // buffer for incoming packets
char  replyPacket[] = "Hi there! Got the message :-)";  // a reply string to send back

IPAddress ip(192, 168, 1, 226);  // destination device IP (Labview)
int recPort = 91;  // reciever Port (defined)
int loopi = 0;

const int UDP_PACKET_SIZE= 48;

byte packetBuffer[ UDP_PACKET_SIZE]; //buffer to hold incoming and outgoing packets 


void setup()
{
  // Initialize serial interface
  Serial.begin(115200);
  Serial.println();

  // Set Wifi values
  Serial.printf("Connecting to %s ", ssid);
  WiFi.begin(ssid, password);
  while (WiFi.status() != WL_CONNECTED)
  {
    delay(500);
    Serial.print(".");
  }
  Serial.println(" connected");

  // UDP parameters
  Udp.begin(localUdpPort);
  Serial.printf("Now sending data from ESP8266 with IP %s & UDP port %d\n", WiFi.localIP().toString().c_str(), localUdpPort);

   // Set timer values 
   TickOccured = false;
 
   os_timer_setfn(&Timer1, timerCallback, &Counter);
   os_timer_arm(&Timer1,2000, true);
}

void loop()
{

 if (TickOccured){
    
    loopi++; 
    
    accels[loopi].x = loopi; accels[loopi].y = loopi+5; accels[loopi].z = loopi+10; 

    Serial.print("x = "); Serial.print(accels[loopi].x);
    Serial.print(" y = "); Serial.print(accels[loopi].y);
    Serial.print(" z = "); Serial.println(accels[loopi].z);

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

if (loopi==9){
   // start data transfer via UDP
      
    for (int i=0; i <= 8; i++){

      memset(packetBuffer, 0, UDP_PACKET_SIZE);                         // reset packetBuffer
      sprintf((char*)packetBuffer,"%i %i %i;",accels[i].x,accels[i].y,accels[i].z);  // write sensor data to string
      
      Udp.beginPacket(ip, recPort);
      Udp.write(packetBuffer,UDP_PACKET_SIZE);
      Udp.endPacket();

      delay(200);

      Serial.println("packet sent...");
    }
  loopi = 0;      
}
 delay(0); 
}

Meine Sensorwerte sind bisher immer noch simuliert mit den Integers. Die realen Werte hoffe ich morgen einzubinden. Der Timer kommt auch noch raus - der kommt ja dann prinzipiell vom "Takt" des Sensors.

Wäre supernett wenn Du mir ein Feedback geben könntest, ob ich Deine Hinweise korrekt umgesetzt habe.

Viele Grüße und Dir vielen Dank!

Bire

30

welche Aufgabe hat das delay(200) und wie passt das in einen Sketch der "zeitkritische Daten" versenden soll?

31

Hallo,

ich habe das mehr überflogen. UDP habe ich nicht genutzt, mit HTTP schafft der ESP8266 bei guten WLAN-Verhältnissen ca. 200-300kB/s zu übertragen.
SPIFFS wäre meine Speicherversion, der Zugriff dürfte da ausreichend schnell sein, mit Streamausgabe bekommt er zumindest ein 200kB Bild aus dem SPIFFS in rund 1s in das Browserfenster.

Gruß aus Berlin
Michael

32

Du sammelst die Daten um Zeit zu sparen!
Verschickst dann aber in einer for Schleife lauter einzelne UDP Pakete?

Das würde ich nochmal überdenken.

Gruß Fips

33

Guten Morgen alle zusammen,

vielen Dank für Eure Hinweise / Fragen (zu denen ich wiederum Rückfragen habe und auch eine Antwort):

welche Aufgabe hat das delay(200) und wie passt das in einen Sketch der "zeitkritische Daten" versenden soll?

Das delay ist nur um mal das Ganze sehen zu können, kommt zum Schluss raus, klar. Danke für den Hinweis

Verschickst dann aber in einer for Schleife lauter einzelne UDP Pakete?

Das würde ich nochmal überdenken.

Ich hatte versucht, das Ganze in einem Rutsch zu machen und zwar indem ich mein struct Array an udp.write() schicke, daran bin ich aber gescheitert. Hier wäre die Frage: Wie kann ich das Array (das ich ja schon in meiner Erfassungsschleife gesammelt habe) in einem Rutsch versenden. Das war mein Ziel, habe ich aber bisher nicht hinbekommen. Ich denke, hier müsste ich dann auf UDP_PACKET_SIZE achten (dass der Puffer nicht überläuft). Wenn Du mir einen Lösungsansatz hättest wäre ich Dir sehr dankbar.

SPIFFS wäre meine Speicherversion, der Zugriff dürfte da ausreichend schnell sein, mit Streamausgabe bekommt er zumindest ein 200kB Bild aus dem SPIFFS in rund 1s in das Browserfenster.

Das hatte Tommy auch schon einmal vorgeschlagen...Wie wäre hier die grundlegende "Architektur"? Damit meine ich z.B.

  • A Schreibe ich jedes Sample in den Speicher versende es dann unmittelbar direkt nach der Erfassung oder
  • B soll ich das auch Puffern und später wegschreiben (so wie ich es auch jetzt gerade versuche mit dem struct array()) in einem Rutsch (als Array) oder einzeln in einer loop? Vielleicht hast du bei Deine http-Lösung auch sowas umgesetzt und kannst mir einen Hinweis geben.

Ich freue mich auf Eure Antworten. Wäre wirklich genial, wenn ich die Tage den "Durchbruch" schaffen könnte! Danke an alle, die hier mitdiskutieren.

Viele Grüße und vielleicht bis später

Bire

34

bire:
Wie kann ich das Array (das ich ja schon in meiner Erfassungsschleife gesammelt habe) in einem Rutsch versenden.

Mit Udp.write(). Wie sonst? Einfach mal die Doku ansehen:

buffer: an array to send as a series of bytes (byte or char)

Also das Array auf byte* casten und fertig

Das braucht man keine extra Puffer und Arrays. Eine Array Variable ist schon das Äquivalent zu einem Zeiger auf das erste Element. Dann muss man nur dem Compiler sagen, dass er dass wie einen anderen Datentyp behandeln soll. Da passt natürlich nicht immer, aber gerade structs und Arrays beliebiger Datentypen kannst du so immer wie Arrays aus Bytes behandeln

35

Guten Abend bzw. guten Morgen,

vielen Dank -mal wieder Dir Serenifly für Deinen Hinweis. Ich habe es -ebenso mal wieder- glaube ich fast hinbekommen. Nur ein (hoffentlich kleines) Problem habe ich noch: Labview erwartet einen String aus UDP-Datagramm. Mittels der bisherigen Methode

Udp.beginPacket(ip, recPort);
Udp.write(packetBuffer,UDP_PACKET_SIZE);
Udp.endPacket();

hat es immer geklappt, dass ich das auch in "Reinform" in Labview empfange (siehe io.PNG). Wenn ich nun aber das Array caste bekomme ich sowohl bei byte * als auch bei char * "kryptische" Zeichen. Mache ich etwas falsch? Das ist der Code:

      Udp.beginPacket(ip, recPort);
      Udp.write((byte *) &accels,sizeof(accels));  // oder char *
      Udp.endPacket();

In Labview gibt es die Funktion "String nach Byte-Array" welches ich auch schon genutzt habe. Dieses Array hat die Größe 120 (also genau die Größe, die ich vom ESP weggeschickt habe). Sollte also bis auf den Datentyp passen. Warum passt das dann aber nicht bei char wie bei dem anderen Beispiel? Ich den Inhalt des Arrays auch einmal angehängt. Hier ist es so, dass offensichtlich immer 4 Werte für einen Werte geschrieben werden, z.B. wenn man nur Udp.write((byte *) &accels[2],sizeof(accels[2]));
rausschreibt, kommen die Werte (siehe auch Datei accel[2].PNG)

2 0 0 0  7 0 0 0 12 0 0 0 raus. es sollten aber nur die reinen Messwerte (bzw. meine simulierten Integers sein:

2 7 12 // entsprechend  accels[2].x = 2; accels[2].y = 2+5; accels[2].z = 2+10;

Mache ich hier etwas falsch oder habe ich etwas nicht kapiert? Ich denke, es liegt am Datentyp byte...?

Ich hoffe, Ihr versteht was ich meine. Wenn nicht, fragt bitte nach!

VIELEN DANK an Euch alle und Grüße

Bire

io.PNG
io.PNG791×768 47.8 KB

nio.PNG
nio.PNG793×770 60.5 KB

accel[2].PNG
accel[2].PNG795×771 42.7 KB

36

Also der Unterschied zwischen einem String und rohen Bytes sollte dir inzwischen klar sein. Sagt dir ASCII was?

Dass Labview da nur mit Strings arbeitet ist ja selten dämlich. Wenn es nicht auf Performance ankommt, kann da ja ok sein, aber sobald man Zeit sparen möchte ist das tödlich. Dann kannst du es nämlich vergessen Arrays oder structs auf einmal zu senden. s(n)printf() ist dann in der Tat die beste Wahl

Es gibt in Labview Hilfsfunktionen um Binärdaten und Strings und umgekehrt zu wandeln. Stichworte: flattening/unflattening:
http://zone.ni.com/reference/en-XX/help/371361J-01/lvconcepts/flattened_data/
Aber wie man die Daten in C++ so aufbearbeitet dass Labview damit richtig umgehen kann ist was anderes.

Ich habe auch gelesen dass Labview Big Endian ist. Arduino ist dagegenen Little Endian. Da muss man auch aufpassen.

Das ist aber alles nur Zeug was ich kurz mit Google gefunden habe. Auskennen tue ich mich da nicht. Wenn du selbst suchst findest du vielleicht mehr

37

Guten Morgen,

vielen Dank. Ich habe und werde mir jetzt noch mal in Ruhe die Daten anschauen die ich vesende und das noch einmal nachvollziehen mit den Datentypen. Dann ist das meine nächste Baustelle :confused: :

...wie man die Daten in C++ so aufbearbeitet dass Labview damit richtig umgehen kann...

Ich werde das heute mal versuchen und melde mich dann wieder.

Vielen Dank Dir und Euch!

Grüße

Bire

38

Guten Abend alle,

ich will Euch hiermit berichten, wie es mir die letzten Tage ergangen ist. Wie so oft bei mir, gab es kleine Fortschritte, aber auch wieder neue Fragen. Vielleicht hat der Eine oder Andere Interesse und Lust, mir noch einmal auf die Sprünge zu helfen.

Kurz zum Stand: Ich bekomme die Werte nun wunderbar nach Labview rein und kann diese hier abgreifen. Sowohl als Pakete als auch als einzelne Werte. Soweit alles wunderbar und das ist sicherlich ein Meilenstein. Ein Problem hat sich jedoch heute offenbart: Meine FFT-Berechnung passt nicht und ich denke, das liegt an der fehlerhaften Zeitbasis –schon auf dem Controller.

Ich habe deshalb mal zwei Ansätze umgesetzt. Ich nenne diese mal Ansatz A (Array-Ansatz) und B (Sample-Ansatz).

Grundsätzlich funktionieren beide Varianten, was schon einmal gut ist. Nur ich glaube, ich habe hier noch ein Problem: Bei der Berechnung der Fouriertransformation in Labview kommen falsche Werte raus. Vorab: Ich bin sicher, dass der Algorithmus richtig ist, da er bei Referenzsignalen, die korrekt abgetastet wurden, richtige Ergebnisse zeigt.
Es wäre wunderbar, wenn Ihr mir ein paar Hinweise zu meinen Gedanken geben könntet.
Zeiten
In der loop()-Schleife schreibe ich ja mit einer gewissen Geschwindigkeit die Daten weg, dazu kommt die Zeit, die ich benötige für die Konstruktion des Arrays und die Schleife an sich dauert ja auch einige Zeit. Ich habe mal einen kleinen Test gemacht und die Zeiten (über micros) für folgende UDP-Blöcke.

Udp.beginPacket(ip, recPort);
Udp.write((byte *) &accels[0],sizeof(accels[0]));    
 Udp.endPacket();

„gemessen“. Bitte beachtet: Ich schreibe sowohl die Einzelwerte als auch die Pakete über ein Array raus.

Dabei habe ich im Mittel 58 Mikrosekunden = 0,000058 sec = 17.241 Hz gemessen. Das heißt für mich doch, dass ich theoretisch Frequenzen bis zu dieser Frequenz erfassen kann und die Werte einzeln wegschicken könnte, wenn ich alle anderen Einflüsse vernachlässige. Wäre super, wenn Ihr das mal bestätigen oder widerlegen könntet. Das aber nur als Vorbemerkung.

Ansatz B („Einzelwerte“)
Beim Ansatz B schreibe ich jedes Sample einzeln weg. Der Sensor den ich nutze (Datenblatt liegt bei), hat eine Output-Rate von bis zu 3200 Hz. Das heißt wohl, dass jeweils mit dieser Frequenz ein neuer Wert ankommt, das heißt aber nicht unbedingt, dass ich mit diesen Werten abtaste, wenn ich das richtig verstanden habe?! Ich setze zwar im Sketch meine Abtastrate auf die besagten 3.200 Hz, schreibe aber mit einer ganz anderen Frequenz. Entspricht nun diese Frequenz meiner Abtastrate? Ich habe auch schon mit dem Wert der Register ADXL345_INT_DATA_READY_BIT / ADXL345_DATA_READY experimentiert, da ich davon ausgegangen bin, dass hier vielleicht eine saubere Zeitreferenz geschaffen werden kann, die quasi „wartet“ bis ein neuer Wert da ist. Auch bei der maximalen Frequenz von 3.200 Hz (=0,0003125 Sekunden) sollte ich –theoretisch-jeden Wert einzeln wegschicken können. Versteht Ihr was ich meine?!

Ansatz A („Array“)
Beim Array Ansatz schreibe ich jeweils 44 Werte (jeweils 12 Byte) in ein Array und schreibe dieses dann auf einmal weg. Vom Gefühl her und durch Euer Anraten unterstütz hatte ich ja eine Array gesammelt und dieses dann in Paketen weggeschickt. Diese Arrays baue ich dann in Labview wieder zusammen, bis ich eine bestimmte Sampleanzahl habe und mache dann meine FFT. Meine Idee war, dass die Werte hier äquidistant vorliegen, aber auch hier kommen falsche Wert raus.

Zusammenfassung
Mein Sensor kann -theoretisch zumindest- ausreichend hoch abtasten, ich bekomme –ebenso theoretisch- die Daten schnell weg. Was mir fehlt, ist eine „hart“ getaktete Zeitbasis der Messwerte des Sensors. Vielleicht über einen Interrupt? Ich denke, das ist das Problem?! Vielleicht seht Ihr ja aber auch noch andere Probleme.

Es wäre super, wenn Ihr Euch noch einmal Zeit für eine Diskussion nehmen könntet. Ich freue mich über jeden Input.

Euch einen erholsamen Abend und Grüße

Bire

UDP_Web5_send2Packets_ADXL345.ino.ino (6.08 KB)

ADXL345.pdf (855 KB)

39

Mein Vorschlag bezüglich des Arrays war alle Messwerte zu sameln und nach der Messung zu verschicken.
Mit dem Schicken zwischendurch bringst Du Dir die Zeitbasis durcheinander.

Gruß Tommy

40

Hallo Tommy,

freut mich, dass ich von Dir höre :slight_smile: Auch auf die Gefahr hin, dass Du mich für blöd hältst, aber zu Deiner Bemerkung folgende Nachfrage: Was meinst du mit alle. Alle Werte aus einem bestimmten Zeitintervall, z.B. 2 Sekunden? Mein Puffer in Labview kann ja aber maximal 548 Bytes empfangen, das ist die maximale Paketgröße?! Siehe auch:

Deshalb schicke ich die Werte auch wieder einzeln weg. Mein Array (aus drei Integers) ist pro Sample 12 Bytes, deshalb schicke ich dann nach 44 Werten weg (mit etwas Reserve). Ist das nicht was Du meintest oder stehe ich auf dem Schlauch?

Die Pakete kommen sauber im Labview an. Meine Idee war, dass ich -wenn ich die Werte bereits im Controller sammle- hier das delta_T immer meiner Samplingrate entspricht und ich dann die einzelnen 44er Pakete wieder "zusammenbaue". Aber da liege ich wohl falsch?!

Würde mich über eine Antwort sehr freuen!

DANKE (ich lerne hier wiklich so viel von Dir) und Grüße

Bire