Panel flickers while communicating over Wifi

[jamesdawson3]

First off, thank you very much for this awesome driver - not having to use an Arduino is amazing.

Everything has been working great for me except I've run into a strange bug. I get strange flickering on my panel whenever the ESP8266 is communicating over wifi. I've put together a sketch that replicates the error. Its based off of your example code and this example for HTTPS requests:

#include <P10_matrix.h>
#include <Ticker.h>
#include <ESP8266WiFi.h>
#include <WiFiClientSecure.h>

// Pins for LED MATRIX
#define P_LAT 16
#define P_A 5
#define P_B 4
#define P_C 15
#define P_OE 2
P10_MATRIX display(P_LAT,P_OE,P_A,P_B,P_C);

Ticker display_ticker;

void display_updater()
{
   display.display(70);
}

const char* ssid = "........";
const char* password = "........";
const char* host = "api.github.com";
const int httpsPort = 443;

uint16_t myCYAN = display.color565(0, 255, 255);
void setup() {
  Serial.begin(115200);
  display.begin();
  display.flushDisplay();
  display.setTextColor(myCYAN);
  display.setCursor(2,0);
  display.print("Pixel");
  display_ticker.attach(0.001, display_updater);
  delay(1000);

  Serial.println();
  Serial.print("connecting to ");
  Serial.println(ssid);
  WiFi.mode(WIFI_STA);
  WiFi.begin(ssid, password);
  while (WiFi.status() != WL_CONNECTED) {
    delay(500);
    Serial.print(".");
  }
  Serial.println("");
  Serial.println("WiFi connected");
  Serial.println("IP address: ");
  Serial.println(WiFi.localIP());
}

void loop() {

  // Use WiFiClientSecure class to create TLS connection
  WiFiClientSecure client;
  Serial.print("connecting to ");
  Serial.println(host);
  if (!client.connect(host, httpsPort)) {
    Serial.println("connection failed");
    return;
  }

  String url = "/repos/esp8266/Arduino/commits/master/status";
  Serial.print("requesting URL: ");
  Serial.println(url);

  client.print(String("GET ") + url + " HTTP/1.1\r\n" +
               "Host: " + host + "\r\n" +
               "User-Agent: BuildFailureDetectorESP8266\r\n" +
               "Connection: close\r\n\r\n");

  Serial.println("request sent");
  while (client.connected()) {
    String line = client.readStringUntil('\n');
    if (line == "\r") {
      Serial.println("headers received");
      break;
    }
  }
  String line = client.readStringUntil('\n');
  Serial.println("reply received");
  Serial.println("closing connection");

  delay(10000);
}

I don't have a deep enough understanding of some of the low level processes of these ESP8266s and your driver to understand what might be interfering with the display output. Any thoughts you have or at least a place to start digging would be much appreciated!

Thanks.

BTW. I'm using an 8 row-step panel with a NodeMCU ESP-12E. CPU Freq at 160 MHz.

[2dom]

Driving the panel is essentially a real-time application. If

display.display(70);

is not executed in time you will see flicker. So you can:

1. pretend the problem is not there (my PixelTime weather clock fades display to black, pulls weather data and fades the display back in again)
2. re-write your code to ensure the timely execution of display.display, e.g. use client.available and client.read commands instead of readStringUntil with a wait loop that calls display.display in between (not 100% sure if that will solve your problem but worth a try)
3. investigate into the timely execution of the Ticker task. I don't think Arduino ESP8266 uses a proper RTOS so the wifi communication is probably locking up the system a bit leading to flickering. There is a FreeRTOS variant for the ESP that should give you better control over task priorities etc.
4. switch to the ESP32 that comes with FreeRTOS as standard and allows you to run the real-time task on another core as the wifi communication

Hope that helps

Best

Dom

[jamesdawson3]

Thanks for the quick reply! My suspicion is that #3 is likely the culprit. The worst flickering actually occurs during the client.connect() call, so I'm betting you're right in that the system is locked up during that.

My current workaround is what you suggested in #1, so I'll stick with that for the time being and investigate switching my setup to an ESP32 so I can isolate the wifi communication and display routines from each other - great suggestion!