ESP8266 Community Forum

- Tue Oct 06, 2015 6:50 pm #30722 I am building a wireless ws2812 LED setup. I know there are ws2812 libraries around but their timing still doesn't seam reliable and for me large strips (256 LEDS) I get bad flicker, addressing etc. That I don't with FastLED on an Arduino/Teensy.

So I have a fairly simple sketch, it listens on UDP port 7777 and Streams that data out over the Serial to an Arduino. The Arduino is 5V. But as I am only connecting the TX from the ESP-01 to the RX of the Arduino Hardware serial line, so should be fine.

Anyway, after a certain amount of time, 5 - 10 minutes or so. The ESP-01 stops Streaming data out over Serial. The blue comm LED no longer blinks. Restarting my UDP Streaming app doesn't help. The module can still be pinged, so it has not totally locked up. The module also sends a 'G' byte message back to the remote IP the packet came from. The app only sends packets if it is receiving 'G' bytes. But these messages also stop. Here is the code:

Code: Select all#include <ESP8266WiFi.h>
#include <WiFiUDP.h>

//how many clients should be able to telnet to this ESP8266
#define MAX_SRV_CLIENTS 1
const char* ssid = "...";
const char* password = "...";

WiFiUDP UDP;
WiFiClient serverClients[MAX_SRV_CLIENTS]; //Whoops. left over from the telnet example.

#define LED_COUNT 256
#define LED_SIZE 3

#define HANDSHAKE_SIZE 3

unsigned char gLEDS[LED_COUNT * LED_SIZE + HANDSHAKE_SIZE]; //Lead with a 3 0x01 start bytes
unsigned char defaultColour[3] = { 255, 167, 50 };

IPAddress lastAddress = IPAddress(192,168,2,120);

#define STREAM Serial

unsigned long time;

void resetLEDS()
{
  for(unsigned int i = 3; i < LED_COUNT * LED_SIZE; i+=3)
  {
    gLEDS[i] = defaultColour[0];
    gLEDS[i+1] = defaultColour[1];
    gLEDS[i+2] = defaultColour[2];
  }
}

void setup()
{
  STREAM.begin(250000);

  gLEDS[0] = 0x01;
  gLEDS[1] = 0x01;
  gLEDS[2] = 0x01;

  WiFi.begin(ssid, password);
  STREAM.print("\nConnecting to "); STREAM.println(ssid);
  uint8_t i = 0;
  while (WiFi.status() != WL_CONNECTED && i++ < 20) delay(500);
  if(i == 21)
  {
    STREAM.print("Could not connect to"); STREAM.println(ssid);
    while(1) delay(500);
  }

  UDP.begin(7777);
 
  STREAM.print("Ready! IP: ");
  STREAM.print(WiFi.localIP());

  resetLEDS();
  WriteLEDS();

   time = millis();
}

void WriteLEDS()
{
  STREAM.write(gLEDS, LED_COUNT * LED_SIZE + HANDSHAKE_SIZE);
  //Wait to write all this out to serial
  STREAM.flush();
}

void loop()
{
  if (UDP.parsePacket() != 0)
  {
        lastAddress = UDP.remoteIP();
       
        /*
        STREAM.print("Recv Packet from: ");
        STREAM.print(address);
        STREAM.print("\n");
        */
        int totalBytes = UDP.read(gLEDS + HANDSHAKE_SIZE, LED_COUNT * LED_SIZE);
        WriteLEDS();
       
        time = millis();
  }

  //Send a confirm, so we can get the next one
  UDP.beginPacket(lastAddress, 7878);
  UDP.write('G');
  UDP.endPacket();

  delay(10);

  if (  millis() - time > 10000 )
  {
    time = millis();
    resetLEDS();
    WriteLEDS();
  }
}


It is almost like the loop function is no longer being called. Or is permanently blocked on UDP.parsePacket() or UDP.read(). Anyway got any advice on what might be the cause of this?

Cheers

- Sat Oct 10, 2015 9:54 pm #31076 Your issue sounds very similar to one I had this past week. My project, https://www.hackster.io/rayburne/tardis-time-esp8266-ap-webserver-gps broadcasts GPS sentence $GPRM via UDP on :8888.

The UDP listener would hang after a few minutes. Perplexing. I do not know why this works, but sending a null (CR/LF) after each received sentence has brought stability - over many days.

Ray

- Sun Oct 11, 2015 7:25 pm #31129 Thanks for the reply, nice to know I'm not the only person having this issue. I might make a more stripped down test case to see if it can be more reliably reproduced.

I'll give replying with the \r\n packet a go and see if it stabilizes mine as well. Days stability would be awesome. I am getting pretty bummed out by this issue.

Are you using the Stable Version (July 23rd) or the Staging Version of the Arduino core for ESP8266?

- Mon Oct 12, 2015 7:12 am #31159

Thanks for the reply, nice to know I'm not the only person having this issue. I might make a more stripped down test case to see if it can be more reliably reproduced.

I'll give replying with the \r\n packet a go and see if it stabilizes mine as well. Days stability would be awesome. I am getting pretty bummed out by this issue.

Are you using the Stable Version (July 23rd) or the Staging Version of the Arduino core for ESP8266?

@caswal,

I'm using the current staging version with 1.6.6 nightly.

I was looking through the old dialog pre-RFC's and in some of the UDP discussions, it seems like there is a need for ACK/NACK pairs. So, it may be as easy as simply leaving the WDP.write(ReplyBuffer) commented and just open and close the connection. I'll try and get around to trying that today after I work through the wife's to-do list

Whoa! (Update 1)
Forget commenting UDP.write() as I consistently get a Stack dump.
However, UDP.write("");
does seem to function just as well as the CR/LF (6+ hours into the test.)

Code: Select all    UDP.beginPacket(apIP, UDP.remotePort());                 // send a reply, to the IP address:port
    UDP.write(ReplyBuffer);                                  // should not be necessary but it seems that the ESP8266
    UDP.endPacket();                                         // is stablized by the inclusion of the send



The GPS UDP broadcaster has been installed for 5 days now and been up 100%. Since it is in the attic, that is a very good thing. I'm very interested to see how the unit handles the temperature extremes.

Ray