Genau so sehe ich das auch.
Aber evtl. kann ein C++ Profi was dazu sagen.
Ok, danke.
War mir def. bisher nicht bekannt.
Dann bleiben da noch die Pins. Die sind in deinem Sketch anders.
ja, ich hab halt 12 und 13 genommen statt 10 und 11
Das hab ich schon gesehen.
Und falsche Angaben sind eben irreführend.
Setze Texte bitte in Codetags und nicht als Bilder. Das gibt Augenkrebs.
Wie das geht, steht hier.
Gruß Tommy
hatte ich doch gemacht ? siehe mein erster Post, ganz artig und brav mit <CODE...
Wobei die 13 ist am Nano schlecht, weil da eine Led dran hängt, die das Signal verfälschen kann.
ja, hab es mittlerer Weile mit 10 und 11 probiert, macht leider keinen Unterschied
Ok, dann wäre jetzt mein letzter Tipp:
Nicht so schnell hintereinander senden und im Sender testweise ein delay(2000); in der loop() einfügen und def. nicht Pin 13 verwenden.
Und für eine ausreichende, stabile Spannung hast du gesorgt ?
Bin doch bin auf falschem Dampfer. Habe nur den String Zusammenbau getestet mit SerMon also sollte der senden ohne dem
while (1) {
// CODE
}
die Ausgabe vom dataString
der String = *1300*300*1300*300*6400*6400genau....selbst noch mal getestet.
Der bleibt im while() hängen, deswegen auch meine Frage in Post#4.
Wie @fony schon schrieb, damit das funktioniert, muss der raus.
Dann läuft der Sketch durch.
Wundert mich nur, dass @tobias4511 das nicht selbst gemerkt hat. Dazu hat man doch serielle Ausgaben. Die sollten auch so lange drin bleiben, bis der Sketch richtig läuft.
Manche denken wenn die Serials kommentiert sind landen trotzdem im Speicher
OK, ich meinte auch tatsächlich "auskommentiert", also nicht aktiv.
Optimaler lässt sich das per " Präprozessor-Direktiven" erledigen.
Er bleibt vor der While-Schleife schon hängen
Ja...und wo genau ?
Wir können das hier leider nicht sehen.
Edit:
ich habe jetzt noch mal deinen Sketch mit dem von Wolle verglichen.
Die sind ja schon recht unterschiedlich. Da hängt der wohl schon hier:
while (requestString != "request") {
//Serial.println("Wait for Request");
if (hc12.available()) {
requestString = hc12.readString();
//Serial.println(requestString);
}
}
Warum hast du den den nicht direkt übernommen, wie geschrieben ?
Ich habe den Code jetzt zum Laufen gebracht.
Das Problem war, dass ich auf Receiver-Seite in einer Schleife ständig "request" gesendet habe.
Das geschieht so schnell in der Schleife hintereinander das im Puffer letztendlich mehrere Wörter hintereinander geschrieben wurden (etwa so : "requestrequestrequestrequestrequestrequestrequestrequest" )
Auf Empfänger-Seite lese ich den Puffer aus und vergleiche mit "request".
Dieser Vergleich wird dann nie übereinstimmen und er hängt in der Schleife fest.
Meine Überlegung war, das Wort "request" solange zu senden, bis es am Empfänger ankommt.
Das es sich im Puffer kumuliert war mir nicht bewusst.
Schönen Dank für eure Hilfe!
Tobias
P.S. Übrigens ist die Methode readString() SEHR langsam!! Da dauert es über eine Sekunde, bis die Daten ausgetauscht werden. Die Methode read(); hingegen ist blitzschnell. Habe die Parameter jetzt alle als Bytefolgen (lowByte/highByte vom Integer-Parameter) mit read()/write() übertragen.
Weil sie nicht weiß, wann die Zeichenkette zu Ende ist und deshalb wartet.
Schließe Zeichenketten besser mit einem '\n' ab und nutze besser readBytesUntil() bis zu diesem '\n'
Gruß Tommy
Nein, ist sie nicht!
Wahr ist, dass sie nach 1s in einen Timeout fällt.
Aber das ist kein Problem der Methode, sondern liegt an deinem nicht vorhandenem bzw. kaputten Protokoll.
Also erstmal vor der eigenen Tür den kehren, bevor man sich über "andere" beschwert.
Ich habe mich nicht beschwert, nur festgestellt!
Und es ist nicht mein Code sondern der von „Wolle“ . Den hatte ich 1:1 übernommen, getestet und mich gewundert, wie lange die Übertragung dauert.