I have been working on a hydroponic garden that is controlled with Arduinos. I have everything working except for the user interface. What I would like to do is have an LCD screen paired with a rotary encoder for use on the garden, and an ESP8266 WiFi module set as a server working with a custom Android app that I am writing.

I have been working on writing the app and the code that will allow the Arduino and the app to talk to each other, but I have been running into a problem. Sometimes the serial data between the ESP266 and the Arduino is not being picked up by the Arduino. I have verified that the data coming out of the WiFi module is correct, but the Arduino seems to be missing characters. This seems to happen almost at random. Sometimes it will work, and other times it will simply get stuck. I used a SoftwareSerial library to add an extra serial port and printed what the Arduino was receiving from the WiFi module, and it just seems to be missing random characters.

Up until now I have had the WiFi module connected and the LCD screen. I was using the LCD screen to display debugging messages. I took the LCD screen off and deleted all the LCD code and now everything seems to work just fine.

The LCD screen uses I2C.

Why does disconnecting the LCD screen solve the issue? Is there a way to make both run at the same time? The LCD uses I2C. I am unaware of anything that would prevent this from working.


  • 7
    Without seeing your code, and preferably a schematic, a reply would be guesswork. – Nick Gammon Feb 20 '16 at 3:14
  • I'll guess it's the incompatible voltage levels because ESP8266 is a 3.3V device that'll output 3.3V logic high. Try converting the ESP8266's TX 3.3V to 5V serial and Arduino's TX 5V to 3.3V serial – Avamander Feb 20 '16 at 10:03
  • Please add some info on the memory statistics with and without the LCD code. And the obvious question; are you using String? – Mikael Patel Feb 20 '16 at 10:14


The SoftwareSerial library requires continually polling the serial ports over short periods of time therefore it presents a problem of having to parse received data into something usable, which is going to be nearly impossible as your program is going to be too busy trying to keep up with all the incoming NMEA characters to assemble it all into something meaningful.

So in your situation the data from the ESP8266 module is probably fine as you say, but parsing it and sending it to the lcd over I2C is a lot of work and sometimes it will "lose" data it simply doesn't have time to process. This explains why the data loss is hit and miss, and gets resolved when you reduce the processing workload of your program by removing the lcd component.


What you need here is to use an interrupt-driven SoftwareSerial library instead, which works by filling a buffer in the background with received data and allows a little breathing room to process the serial data. A great example is the NewSoftwareSerial library. This link will show you how to use the library , also expand into the details my answer to give you a deeper understanding.

  • I am using the native serial pins on the Arduino to receive information from the WiFi module. The SoftwareSerial library was only used to print to the computer to see what the Arduino was receiving from the module. Would the same problem happen with the native serial pins? – CBSoftware Feb 20 '16 at 17:55
  • 2
    Old thread, but this answer contains incorrect information. From arduiniana: "NewSoftSerial is in the core! Starting with Arduino 1.0 (December, 2011), NewSoftSerial has replaced the old SoftwareSerial library as the officially supported software serial library." So that library still blocks. I would suggest my library, NeoSWSerial. It does not block on receive and can transmit and receive at the same time. See also this answer regarding "native serial pins", aka HardwareSerial. – slash-dev Sep 17 '16 at 16:11
  • @slash-dev My answer does point to the NewSoftwareSerial library, what exactly is incorrect?. If you have a custom library you think would suit the OP's needs please add a full answer above as a useful reference for anyone with a similar issue. – javawocky Sep 17 '16 at 19:50
  • I agree that the polling approach is causing problems, but but he is already using that library. NewSoftwareSerial is the current SoftwareSerial. Although the start of each character causes an interrupt, SoftwareSerial polls for the remaining 9 bits, with interrupts disabled. :P I was reluctant to add a complete new answer, because your analysis is correct, but the library suggestion is not. Alternatives are listed in my other answer, here. SoftwareSerial is last choice for many reasons, including the OP's problem. – slash-dev Sep 17 '16 at 20:43

Not the answer you're looking for? Browse other questions tagged or ask your own question.