softwareserial receive serial data with Cr and linefeeds in it

Hi, I’m telnetting to some host on my network via ESP8266 wifi chip and UNO. The ESP chip is connected via softwareserial to the UNO.

The Telnet host sends back a big block of data (~1kB) spread over several lines.

Problem is that serial buffer stops ‘buffering’ when it encounters a linefeed/carriage return.
So only the first line of text is stored, the rest gets lost.

When I use the ethernetshield (via SPI) I don’t have this problem.

#include "ESP8266.h"

#define SSID        "telenet-EC102"
#define PASSWORD    "xxxxxxxxx"
#define HOST_NAME   "192.168.0.174"
#define HOST_PORT   (62910)
#include <SoftwareSerial.h>
#define _SS_MAX_RX_BUFF 512 // RX buffer size //BEFORE WAS 64
SoftwareSerial mySerial(3,2);

ESP8266 wifi(mySerial);

void setup(void)
{
    Serial.begin(115200);
    mySerial.begin(9600);
    Serial.print("setup begin\r\n");
    
    Serial.print("FW Version:");
    Serial.println(wifi.getVersion().c_str());
    Serial.print("Alive:");
    Serial.println(wifi.kick());
      
    if (wifi.setOprToStationSoftAP()) {
        Serial.print("to station + softap ok\r\n");
    } else {
        Serial.print("to station + softap err\r\n");
    }
 
    if (wifi.joinAP(SSID, PASSWORD)) {
        Serial.print("Join AP success\r\n");
        Serial.print("IP:");
        Serial.println( wifi.getLocalIP().c_str());       
    } else {
        Serial.print("Join AP failure\r\n");
    }
    
    if (wifi.disableMUX()) {
        Serial.print("single ok\r\n");
    } else {
        Serial.print("single err\r\n");
    }
    
    Serial.print("setup end\r\n");
}
 
void loop(void)
{
    uint8_t buffer[128] = {0};
    
    if (wifi.createTCP(HOST_NAME, HOST_PORT)) {
        Serial.print("create tcp ok\r\n");
    } else {
        Serial.print("create tcp err\r\n");
    }
    
    char *hello = "Hello, this is client!";
    wifi.send((const uint8_t*)hello, strlen(hello));
    
    uint32_t len = wifi.recv(buffer, sizeof(buffer), 10000);
    if (len > 0) {
        Serial.print("Received:[");
        for(uint32_t i = 0; i < len; i++) {
            Serial.print((char)buffer[i]);
        }
        Serial.print("]\r\n");
    }
    
    if (wifi.releaseTCP()) {
        Serial.print("release tcp ok\r\n");
    } else {
        Serial.print("release tcp err\r\n");
    }
    delay(5000);
}

example text coming from server:

H:LEQ1280431,115f0f,0113,00000000,75110ed4,03,32,0f090e,1030,03,0000
M:00,01,VgICAQZLZXVrZW4PjpACCEJhZGthbWVyELQ8AgEPjpBMRVExMTYwNTQ0FVJhZGlhdG9yIFRoZXJtb3N0YXQgMQEBELQ8TEVRMTE2MDk0NBVSYWRpYXRvciBUaGVybW9zdGF0IDECAQ==
C:115f0f,7RFfDwATAf9MRVExMjgwNDMxAQsABEAAAAAAAAAAAP///////////////////////////wsABEAAAAAAAAAAQf///////////////////////////2h0dHA6Ly9tYXguZXEtMy5kZTo4MC9jdWJlADAvbG9va3VwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAENFVAAACgADAAAOEENFU1QAAwACAAAcIA==
C:10b43c,0hC0PAECEKBMRVExMTYwOTQ0KyE9CQcYAzAM/wBESFUIRSBFIEUgRSBFIEUgRSBFIEUgRSBFIERIVQhFIEUgRSBFIEUgRSBFIEUgRSBFIEUgREhUbETMVRRFIEUgRSBFIEUgRSBFIEUgRSBESFRsRMxVFEUgRSBFIEUgRSBFIEUgRSBFIERIVGxEzFUURSBFIEUgRSBFIEUgRSBFIEUgREhUbETMVRRFIEUgRSBFIEUgRSBFIEUgRSBESFRsRMxVFEUgRSBFIEUgRSBFIEUgRSBFIA==
C:0f8e90,0g+OkAEBEKBMRVExMTYwNTQ0KyE9CQcYAzAM/wBESFUIRSBFIEUgRSBFIEUgRSBFIEUgRSBFIERIVQhFIEUgRSBFIEUgRSBFIEUgRSBFIEUgREhUbETMVRRFIEUgRSBFIEUgRSBFIEUgRSBESFRsRMxVFEUgRSBFIEUgRSBFIEUgRSBFIERIVGxEzFUURSBFIEUgRSBFIEUgRSBFIEUgREhUbETMVRRFIEUgRSBFIEUgRSBFIEUgRSBESFRsRMxVFEUgRSBFIEUgRSBFIEUgRSBFIA==
L:CxC0PAkSGQAgAAAACw+OkAkSGQAKAAAA

In fact I only need the last line, can I dump the first bits of text before encountering the “L:” from the last line of code? the ESP is configured for slow communication:9600. Can the little UNO dump ballast text so memory isn’t overrun?

Can the character sequence "L:" be treated as a sentinel? If so, the problem shouldn't be that hard.

Problem is that serial buffer stops 'buffering' when it encounters a linefeed/carriage return.

No, it doesn't. The buffer doesn't care what data is in it.

Please post a link to the source code for your ESP8266 library.

I have been dabbling with an ESP8266 but just using AT commands and my own receiving code from Serial Input Basics

@PaulS, it may be that the library the OP is using is getting stuck on the CR and LFs

...R

econjack: Can the character sequence "L:" be treated as a sentinel? If so, the problem shouldn't be that hard.

yes, "L:" can be the sentinel.

PaulS: No, it doesn't. The buffer doesn't care what data is in it.

I upgraded the ESP firmware to 0.9.2.2 because default ESP baudrate was 115200bps, too fast for softwareserial...

the buffer stops exactly after the first line of text. I've tested with other first line lenghts too, verified with putty telnet session....

I still suspect it has to do with the cr and lf. With the ENJ28C60 ethernet device (uipethernet) I had exactly the same problem (telnet client example). W5100 chip works fine with the telnet client example.

I still suspect it has to do with the cr and lf. With the ENJ28C60 ethernet device (uipethernet) I had exactly the same problem (telnet client example). W5100 chip works fine with the telnet client example.

If the data is coming into the W5100 chip correctly, but not the others, it is NOT a cr/lf issue. It has something to do with how you get the data from the various chips.

#define _SS_MAX_RX_BUFF 512 // RX buffer size //BEFORE WAS 64

You have to modify SoftwareSerial.h if you want to change the buffer size; that #define will not be used anywhere. Do you have enough free SRAM for a 512-byte buffer?

oqibidipo: ```

define _SS_MAX_RX_BUFF 512 // RX buffer size //BEFORE WAS 64



You have to modify SoftwareSerial.h if you want to change the buffer size;

I don't think the buffer size is the problem. It seems from what the OP says that the ESP8266 library that he is using treats CR LF as a terminator.

As I said in my earlier Post I have had no trouble receiving multiple lines without using the library.

...R

Robin2: I don't think the buffer size is the problem. It seems from what the OP says that the ESP8266 library that he is using treats CR LF as a terminator.

As I said in my earlier Post I have had no trouble receiving multiple lines without using the library.

...R

Euhm, what is an 'OP'?

So you guys think it's ESP firmware related? I think I have the possibility to upgrade to a later firmware, maybe that helps. Otherwise i will ditch the Uno and try the arduino core on the ESP...

TLS1000: Euhm, what is an 'OP'?

So you guys think it's ESP firmware related? I think I have the possibility to upgrade to a later firmware, maybe that helps. Otherwise i will ditch the Uno and try the arduino core on the ESP...

The OP is the Original Poster - the person who started the Thread.

I am NOT suggesting it is a problem within the ESP device. I am wondering if it is a problem with the library you are using.

Does your ESP8266 respond to AT commands ? If so try accessing it without the library.

...R

Robin2: The OP is the Original Poster - the person who started the Thread.

I am NOT suggesting it is a problem within the ESP device. I am wondering if it is a problem with the library you are using.

Does your ESP8266 respond to AT commands ? If so try accessing it without the library.

...R

yes it does...

I can also use the UNO's (reset tied to ground) ftdi to send AT commands to the ESP via serial monitor or putty.

I'll try setting up the telnet connection via terminal, since the telnet server sends the text upon connection.

thanks for the tip

TLS1000: yes it does...

I can also use the UNO's (reset tied to ground) ftdi to send AT commands to the ESP via serial monitor or putty.

I'll try setting up the telnet connection via terminal, since the telnet server sends the text upon connection.

I wonder if there is a misunderstanding ?

I was trying to suggest that you program the Arduino to send the AT commands and then receive the responses using (for example) the code in the second example in Serial Input Basics

...R

Robin2: I wonder if there is a misunderstanding ?

I was trying to suggest that you program the Arduino to send the AT commands and then receive the responses using (for example) the code in the second example in Serial Input Basics

...R

I understood your remark, but I want to rule out the chance that there would be a problem with ESP firmware. Instead of letting arduino send the commands, I send them myself from terminal.

I upgraded the ESP from 9.2.2 firmware to 9.5.5 AT firmware.

Via terminal connection (serial) to ESP I managed to set up wireless TCP connection to the server. I received all the data there is, so not only the first line of text. SO problem with ESP firmware is ruled out now.

Problem with the firmware upgrade is that the default baudrate is 115200. I'll probably have to compose my own firmware version with the toolchain tool for setting default speed at 9600.

First I'll try my program on a mega with the ESP connected to it's own UART at 115200bps.

thanks for the link, I'll probably have to read it again a few times when I get back to the UNO.

TLS1000: I upgraded the ESP from 9.2.2 firmware to 9.5.5 AT firmware.

I admire your courage. :)

...R

Just finished testing the program on Mega. Problem remains the same!!

ESP on it's own UART at 115200bps, only first line of text gets processed on Arduino.

I guess I'll try sending the AT commands manually then without the ESP library, with risk not having all the right connection failsafes.

Damn, as a relative newby I love working with libraries for doing the grunt work. I had a look inside the sourcecode of the ITEAD library(https://github.com/itead/ITEADLIB_Arduino_WeeESP8266) I'm using but my programming skills fall short for good understanding.

Help....

I downloaded the library that you linked to in Reply #14 and I have tried the Example HTTPGET.ino on my Mega and it seems to receive several lines of stuff without any problem.

...R

Hi Robin, thanks for checking. Couldn’t it be that it’s due to the nature or size of the text that’s being transmitted to the server it goes wrong?

I’ve been looking in into the ITEADLIB and found the piece of code that’s working on the received text:
I don’t see the problem…

uint32_t ESP8266::recvPkg(uint8_t *buffer, uint32_t buffer_size, uint32_t *data_len, uint32_t timeout, uint8_t *coming_mux_id) 
297 { 
298     String data; 
299     char a; 
300     int32_t index_PIPDcomma = -1; 
301     int32_t index_colon = -1; /* : */ 
302     int32_t index_comma = -1; /* , */ 
303     int32_t len = -1; 
304     int8_t id = -1; 
305     bool has_data = false; 
306     uint32_t ret; 
307     unsigned long start; 
308     uint32_t i; 
309      
310     if (buffer == NULL) { 
311         return 0; 
312     } 
313      
314     start = millis(); 
315     while (millis() - start < timeout) { 
316         if(m_puart->available() > 0) { 
317             a = m_puart->read(); 
318             data += a; 
319         } 
320          
321         index_PIPDcomma = data.indexOf("+IPD,"); 
322         if (index_PIPDcomma != -1) { 
323             index_colon = data.indexOf(':', index_PIPDcomma + 5); 
324             if (index_colon != -1) { 
325                 index_comma = data.indexOf(',', index_PIPDcomma + 5); 
326                 /* +IPD,id,len:data */ 
327                 if (index_comma != -1 && index_comma < index_colon) {  
328                     id = data.substring(index_PIPDcomma + 5, index_comma).toInt(); 
329                     if (id < 0 || id > 4) { 
330                         return 0; 
331                     } 
332                     len = data.substring(index_comma + 1, index_colon).toInt(); 
333                     if (len <= 0) { 
334                         return 0; 
335                     } 
336                 } else { /* +IPD,len:data */ 
337                     len = data.substring(index_PIPDcomma + 5, index_colon).toInt(); 
338                     if (len <= 0) { 
339                         return 0; 
340                     } 
341                 } 
342                 has_data = true; 
343                 break; 
344             } 
345         } 
346     } 
347      
348     if (has_data) { 
349         i = 0; 
350         ret = len > buffer_size ? buffer_size : len; 
351         start = millis(); 
352         while (millis() - start < 3000) { 
353             while(m_puart->available() > 0 && i < ret) { 
354                 a = m_puart->read(); 
355                 buffer[i++] = a; 
356             } 
357             if (i == ret) { 
358                 rx_empty(); 
359                 if (data_len) { 
360                     *data_len = len;     
361                 } 
362                 if (index_comma != -1 && coming_mux_id) { 
363                     *coming_mux_id = id; 
364                 } 
365                 return ret; 
366             } 
367         } 
368     } 
369     return 0; 
370 }

TLS1000: Hi Robin, thanks for checking. Couldn't it be that it's due to the nature or size of the text that's being transmitted to the server it goes wrong?

Have you tried the example that I tried?

I infer from my experience that the library is NOT being distracted by CR LFs within the data stream.

(The library is just a nice party frock over the AT commands)

...R

Hi Robin, I haven’t tried the example, but I think I found the problem:

Untill now I didn’t succeed in receiving anything from the ESP without the library.

I tried replacing the ‘wifi.recv’ command from the library using

<

  char c;
   while(Serial1.available()>0){
     c=Serial1.read();
     Serial.print(c);

but I didn’t receive anything, so I kept relying on the library for receiving the string data

Simple solution for my problem was to wait a bit for the server to respond:

   unsigned long start=millis();
   char c;
   while(Serial1.available()>0 || millis()-start<2000){
     c=Serial1.read();
     Serial.print(c);
   }

Now I get from serial monitor:

ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
+IPD,70:H:LEÿQ1280431,115f0f,0113,00000000,65145efd,00,32,0f0ÿ914,0802,03,0000
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
+IPD,15ÿ0:M:00,01,VgICAQZLZXVrZW4PjpACCEJhZGthbWVyELQ8AgÿEPjpBMRVExMTYwNTQ0FVJhZGlhdG9yIFRoZXJtb3N0YXQgMÿQEBELQ8TEVRMTE2MDk0NBVSYWRpYXRvciBUaGVybW9zdGF0IÿDECAQ==
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
+IPD,331:C:1ÿ15f0f,7RFfDwATAf9MRVExMjgwNDMxAQsABEAAAAAAAAAAAPÿ///////////////////////////wsABEAAAAAAAAAAQf////ÿ///////////////////////2h0dHA6Ly9tYXguZXEtMy5kZTÿo4MC9jdWJlADAvbG9va3VwAAAAAAAAAAAAAAAAAAAAAAAAAÿAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAÿAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAÿAAAAAENFVAAACgADAAAOEENFU1QAAwACAAAcIA==
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
+IPD,590:C:10b43c,0hC0PAECEÿKBMRVExMTYwOTQ0KyE9CQcYAzAM/wBESFUIRSBFIEUgRSBFÿIEUgRSBFIEUgRSBFIERIVQhFIEUgRSBFIEUgRSBFIEUgRSBÿFIEUgREhUbETMVRRFIEUgRSBFIEUgRSBFIEUgRSBESFRsRMxÿVFEUgRSBFIEUgRSBFIEUgRSBFIERIVGxEzFUURSBFIEUgRSÿBFIEUgRSBFIEUgREhUbETMVRRFIEUgRSBFIEUgRSBFIEUgRSÿBESFRsRMxVFEUgRSBFIEUgRSBFIEUgRSBFIA==
C:0f8e90ÿ,0g+OkAEBEKBMRVExMTYwNTQ0KyE9CQcYAzAM/wBESFUIRSBÿFIEUgRSBFIEUgRSBFIEUgRSBFIERIVQhFIEUgRSBFIEUgRSBÿFIEUgRSBFIEUgREhUbETMVRRFIEUgRSBFIEUgRSBFIEUgRÿSBESFRsRMxVFEUgRSBFIEUgRSBFIEUgRSBFIERIVGxEzFUURÿSBFIEUgRSBFIEUgRSBFIEUgREhUbETMVRRFIEUgRSBFIEUgÿRSBFIEUgRSBESFRsRMxVFEUgRSBFIEUgRSBFIEUgRSBFIA==ÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
+IPD,36:L:CxC0PAkSGQÿAgAAAACw+OkAMOGQAKAAAA
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ

there’s still a lot of nonsense in it, and sometimes the serial1 overflows(only 64 bytes), but at least most is there.

The data from the server is sent in separate packages, because of the leading “+IPD” characters addad by the ESP.
The Itead library analyses if there are “+IPD” characters&buffer size ("+IPD,:") and then jumps to the ‘has data’ part. This ‘has data’ has a timeout of 3000ms, in which the other incoming data is discarded

Stupid me:

updated serial read with gives me correct data:

while(millis()-start<2000){
      if (Serial1.available()>0){
        c=Serial1.read();
      //data+=c;
        Serial.print(c);
    }
}

serial monitor:

create tcp ok


+IPD,70:H:LEQ1280431,115f0f,0113,00000000,7cd89a8f,00,32,0f0914,0a12,03,0000

+IPD,150:M:00,01,VgICAQZLZXVrZW4PjpACCEJhZGthbWVyELQ8AgEPjpBMRVExMTYwNTQ0FVJhZGlhdG9yIFRoZXJtb3N0YXQgMQEBELQ8TEVRMTE2MDk0NBVSYWRpYXRvciBUaGVybW9zdGF0IDECAQ==

+IPD,331:C:115f0f,7RFfDwATAf9MRVExMjgwNDMxAQsABEAAAAAAAAAAAP///////////////////////////wsABEAAAAAAAAAAQf///////////////////////////2h0dHA6Ly9tYXguZXEtMy5kZTo4MC9jdWJlADAvbG9va3VwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAENFVAAACgADAAAOEENFU1QAAwACAAAcIA==

+IPD,590:C:10b43c,0hC0PAECEKBMRVExMTYwOTQ0KyE9CQcYAzAM/wBESFUIRSBFIEUgRSBFIEUgRSBFIEUgRSBFIERIVQhFIEUgRSBFIEUgRSBFIEUgRSBFIEUgREhUbETMVRRFIEUgRSBFIEUgRSBFIEUgRSBESFRsRMxVFEUgRSBFIEUgRSBFIEUgRSBFIERIVGxEzFUURSBFIEUgRSBFIEUgRSBFIEUgREhUbETMVRRFIEUgRSBFIEUgRSBFIEUgRSBESFRsRMxVFEUgRSBFIEUgRSBFIEUgRSBFIA==
C:0f8e90,0g+OkAEBEKBMRVExMTYwNTQ0KyE9CQcYAzAM/wBESFUIRSBFIEUgRSBFIEUgRSBFIEUgRSBFIERIVQhFIEUgRSBFIEUgRSBFIEUgRSBFIEUgREhUbETMVRRFIEUgRSBFIEUgRSBFIEUgRSBESFRsRMxVFEUgRSBFIEUgRSBFIEUgRSBFIERIVGxEzFUURSBFIEUgRSBFIEUgRSBFIEUgREhUbETMVRRFIEUgRSBFIEUgRSBFIEUgRSBESFRsRMxVFEUgRSBFIEUgRSBFIEUgRSBFIA==

+IPD,36:L:CxC0PAkSGQAgAAAACw+OkAMMAAAAAAAA
release tcp ok

I’m at the homestretch now.

Robin, thank you for your help