String ohne New Line

Beantworte bitte mal diese Frage:

Wenn du sowas hast:

blah \n blah \n

Dann ist das nicht eine Zeichenkette bei der man irgendwie das Newline dazwischen entfernt, sondern einfach zwei Zeichenketten. Diese sollte man dann erst mal getrennt einlesen.

Wenn du alles wirklich als eine Zeichenkette möchtest dann brauchst du ein anderes Trennenzeichen dazwischen. Aber ein Newline doppelt als Trennzeichen und als Endzeichen zu verwenden geht nicht zuverlässig. Du bist schließlich nicht mit dem Sender synchronisiert, bzw. es gibt kein Startzeichen.

Sicher, dass du auch auf der richtigen Baustelle buddelst?

Was ist das denn für eine seltsame Software, welche die Daten verfälscht?
Sicher, dass dem so ist?

Ja?
Schade, dass wir/ich nicht erfahren, welches Modul sich so verhält.....

Scheint, scheinen, vermuten: Prüfen!

@ stef308
Du zeigst weder Rohdaten, noch deinen vermutlich fehlerhaften Code.
Auch wenn es die anderen versuchen, aber ich kann dir so nicht helfen, auch wenn ich will.

Hier den Empfangsteil. Es ist per SoftwareSerial angebunden das Bluetooth Modul. BT_RX ist als String deklariert:

while (BT.available() > 0) {              //while serial is available, make...
    BT_RX = BT.readString();                //store received string from serial to BT_RX
    MP.print(BT_RX);                        
    MP.print('\r');                         
    TC.print(BT_RX);                        
    TC.print('\r');                         
  }

Ich nutze ein HC-08 BLE Modul. Das sendet immer 20 Byte. Gesendet werden die Daten über das Smartphone, welches den Text in 20Byte grosse Teile trennt, da die Zeichen/der Text sonst nicht alles ankommt. Hier war der Thread in dem ich das mit den 20 Byte grossen Daten erst realisiert/verstanden habe: Empfangsproblem von Daten über Serial - nur 12 Zeichen
Am Ende ist noch der Ausschnitt von meiner App wenn das was hilft, wie ich die Daten sende.

Ich werde morgen Post #3 und #19 versuchen einzupassen und schauen was ich da erhalte.

1 Like

Immerhin ein Funken von Info...
Dem Datenblatt kann ich entnehmen, dass Paketweise gesendet wird.
Aber nicht, dass man auch in diesen Päckchen füttern muss.
Auch dass da irgendwelche Return oder NewLine eingestreut werden sollen, da ist nix von zu sehen.
Die Übertragung ist transparent.

Dir ist schon klar, dass readString(); einen Timeout hat?

Ich behaupte:
Du buddelst auf der falschen Baustelle!
Allerdings kann ich nicht testen, da keine solchen Module da.

Ach! Da war doch was...

Dein Problem ist Deine APP!
Wenn Du split machst, generierst Du neue Strings.
Dass wird dann jedes Mal mit \n abgeschlossen.
Idotischerweise baust Du selbst sogar ein \r manuell dazu.

Bau das mal nicht mit split sondern mit segment.
Für mich liest sich das so, das Du damit eine Zeichenkette und keinen String bekommst.

  • die fügst Du nach dem Empfang wieder zusammen, indem Du liest bis ein \n auftaucht.

Genau. Das kann ich versuchen. Ich meine aber viel versucht zu haben mit der App, und es funktioniert wirklich wenig damit der ganze Text gesendet wird.
Das carriage return brauche ich zwischen den einzelnen Texten. Aber das new line nicht :wink:

Wie kommst Du auf diese Idee?
Du baust Dir eine Krücke, obwohl Du keine Beine hast.

Wenn Du etwas teilen willst, dann trenne das sinnvoll.
Derzeit ist Dein String aller 18Zeichen immer mit \r\n abgeschlossen.
Das selbst eingefügte \r nutzt Du, das automatische \n willst eliminieren.
Der Sinn erschliesst sich mir nicht.

Das eingefügte \r ist einfach immer zwischen den 1MText\r, 2MText\r und 3MText\r um die Texte anzuzeigen. Diese Befehle gehen an eine Lampe/Leuchte weiter die dann den Text darauf anzeigt. Der Text kann ja auch länger als 18 Zeichen sein, dann ist das carriage return nicht nach 18 Zeichen.
Das new line sollte nicht sein.

Wenn Du das weg lässt, ist es 1MText\n, 2MText\n ... usw.
Wo ist der für Dich wichtige Unterschied, der sich mir nicht erschliesst?

Ein CR als Trennzeichen zwischen einzelnen Teilen würde ja gehen. Jedenfalls wenn man den Code entsprechend anpasst (bei meinem würde das CR ignoriert). Aber ganz am Ende braucht man ein LF als Endzeichen um die gesamte Übertragung abzuschließen.

Alternativ geht auch ein sichtbares Zeichen wie ein Komma oder Strichpunkt wenn es im sonstigen Text nicht vorkommt.

Oder man sendet jeden Text als eigene Zeile. Anstatt irgendwie zusammenfügt. Möglichkeiten gibt es da viele. Was besser ist hängt aber davon ab was das überhaupt sein soll und was man damit macht.

Das macht doch keinen Sinn.

Die Frage ist: was soll das \r dort bewirken?
Die Zeichenkette ist bis zu 20 Zeichen.
Ob mit oder ohne \r.

Schlußendlich wird da nichts getrennt.

Hallo zusammen

Ich habe anhand der Beispielsketche hier die einige gegeben haben und dem Hinweis, dass vielleicht mit der App was ist nochmals genauer unter die Lupe genommen. Die App sendet in der Tat ein NullTerminateString, also \0 am Ende des Strings. Dies kann man nun ja schon gut gebrauchen, um das Empfangsende zu markieren/erkennen.

Ich habe dann die Beispiele von vorangehenden Posts durchgesehen und mir dies zusammengeschustert:

String BT_RX;
char BT_var;

void setup(){

Serial.begin(19200);
Serial2.begin(19200);

void loop() {
  while (Serial2.available() > 0) {
    BT_var = Serial2.read();
    BT_RX = BT_RX + BT_var;
    if(BT_var == '\0'){
    Serial2.print(BT_RX);
    Serial2.print('\r');
    Serial.print(BT_RX);
    Serial.println('\r');
    BT_RX = "";
    }
  }
}

Jetzt liest er die eingehenden Daten und speichert sie zu BT_RX bis es das NullTerminateString '\0' empfängt. Dann sendet es den String an den Serial Monitor und wird auch korrekt ohne \n angezeigt. Ob es jetzt wirklich eine new Line war ist fraglich, aber es hat mir einen Unterbruch zwischen den Zeichen generiert und den zweiten Teil der Zeichen auf eine neue Zeile geschrieben.
Am serial Monitor vorher:

0T1HALLOGUSTAVWIEGEH
TESDIR?

Jetzt mit diesem Sketch zeigt es alles richtig an:

0T1HALLOGUSTAVWIEGEHTESDIR?

Ich danke vielmals für die guten Hinweise und Beispiele!

Danke für die Rückmeldung :slightly_smiling_face:

Wenn Du noch "□ Lösung" anklicks, wird dies auch in der Übersicht angezeigt.

Die Terminierung beim Senden hat zur Folge, das readString() der Meinung ist, da ist Schluss. und erst beim nächsten Umlauf einen neuen baut.
Darum habe ich das in #19 mit dem lesen in ein Array gezeigt.
Ich habe vergeblich auf eine Antwort darauf und die entsprechende Ausgabe vom SerMon gewartet ;( Dann wäre das schon längst erledigt gewesen :wink:

Na dann...