ESP8266 problem with recieved data trasmission via TCP

Question

I am having small project where I want to read couple of analog inputs from Arduino UNO, send it via software serial to ESP8266-01 and from that to python server using TCP.

Data is sent to ESP using this code on Arduino UNO

#include <SoftwareSerial.h>
 SoftwareSerial mySerial(10, 11); // RX, TX
 int pin = 5;
 void setup() {
 mySerial.begin(9600);
 delay(20000);
 }
 void loop() {
 delay(1000);
 int data = analogRead(pin);
 mySerial.println(data);
 }

Code on ESP is bellow

void loop() {
 while(Serial.available()>0){
 char data = Serial.read();
 client.print(data);
 }
}

When data is sent to Python server, it prints it out but data is sent in two seperate parts, so it always looks like this

9
59

, but number sent from arduino is just 959!

Python server code snipet:

while True:
 #Receiving from client
 data = conn.recv(1024)
 print data
 #send data to database
 post.create(
 current = str(data)
 )
 if not data:
 break

So the question is, why data sent to server is separated in two parts? Maybe it have to do something with how data is reading from serial on esp?

• Mark Smith: Suspect the problem to be with the python code. We'd need a complete minimal verifiable example of it.
• Austris: Python server code can be found in link
• dandavis: read() in a loop to a buffer, then print() all in once go; the extra read delay might be hampering you

Answer 1

You assume all 5 bytes of 959\r\n are received by the server at the same time. The data is sent byte after byte, based on the client.print(data) in the ESP code and assuming the underlying library doesn't buffer bytes before transmitting, so there's no way they'll arrive at the server simultaneously. Most likely, your first pass with conn.recv(1024) grabs the first byte 9 and times out. And then on the second pass, the others (at least 2) arrive and are read. The newline between the packets is typical Python 2 print behaviour.

What you need to do is parse the data at the server. Basically read data till you get CRLF i.e. \r\n, which is a good enough delimiter and you're sending it already anyways, and then use that to know when to write to your database.