Add Glediator Serial Function?

[Legsmaniac]

As well as the TPM2.NET feature, would it also be possible to include the Glediator serial option?

The code as a stand-alone that works well for me is really quite simple.

#define FASTLED_ESP8266_RAW_PIN_ORDER
#include <ESP8266WiFi.h>
#include <WiFiUdp.h>
#include "FastLED.h"

#define NUM_LEDS 2040
const int dataline = 2;
CRGB leds[NUM_LEDS];

void setup() {
  Serial.begin(1000000);
  LEDS.addLeds<WS2812B, dataline, GRB>(leds, NUM_LEDS);
  FastLED.setMaxPowerInMilliWatts(20000);
  FastLED.setBrightness(128);
}

int serialReadBlocking() {
    while (!Serial.available()) {}
    return Serial.read();
  }

  void loop() {
    while (serialReadBlocking() != 1) {}

    for (long i = 0; i < NUM_LEDS; i++) {
      leds[i].r = serialReadBlocking();
      leds[i].g = serialReadBlocking();
      leds[i].b = serialReadBlocking();
    }
    FastLED.show();
  }

Or perhaps it's best included in usermod somehow?

[Aircoookie]

Yep, we could easily add this. (not with these specific functions because they are blocking, but with a state machine like the current Adalight support in serial.cpp). Also I'd rather implement standard TPM2 (only differs in the header), as it is supported by more software (Glediator included) Also will want to add a Serial baudrate option, as the default 115200 will be too slow for anything more than about 100 LEDs :)

[Legsmaniac]

Once again, Thank You. Yes, I prefer the TPM option purely because it's wire free, obviously, but the serial option would be good as a back up because the wired option is more failproof. Kinda like comparing WiFi to Ethernet, Ethernet wins every time. Agree about the baudrate, that was what the original dev set it at. Having said that, I have tested it on my 2040 led matrix and even at 115200 as a stand-alone, it works perfectly. I'm not quite sure why you think it would be slow for anything more than a paltry 100 leds when I'm using just over 20 times that amount. There are also loads of YouTube videos of people who have used simple code like this on matrixes bigger than mine. Finally, Glediator is now a standard, used on other software including Jinx which I'm using for simplicity. What I mean is, serial is supported just as much as TPM.

I look forward to the added options and much more you're doing. Many thanks and keep up the good work.

[Aircoookie]

Awesome! No, I mean regular TPM2, transmitted over serial and supported by Glediator and Jinx. Although very similar, it is technically a different protocol from TPM2.NET :)

[Legsmaniac]

No, I mean regular TPM2

Ah, gotcha! Apologies, I misunderstood. Reading your reply again, I see it now.

Note to self - read more carefully next time!! 😁

[Aircoookie]

Already added! I'm happy about feedback! You might need to increase the baudrate in wled.cpp to 921600 for it to work with lots of LEDs! Also made a change to the TPM2.net code that might make it more usable for large amounts of LEDs. I tried 1458 channels per block, 6144 total channels but of course don't have enough LEDs to see most channels, so I only know that the first ones are definitely ok :)

[Legsmaniac]

TPM2 doesn't seem to work at all for me. Maybe I'm doing something wrong. Have I to set anything on any of the HTML pages? In Jinx, I set Output Device to tpm2, 6120 channels, COM port 10 and select the baud speed. I set up the Output Patch, Start Output and nothing. I've tried various settings, not a flicker on the matrix board whatsoever.

As for TPM2.NET, still doesn't work with 6120 channels (Chan/Block) Tried changing to 1458 and only then would the board spring to life but sadly, is the same old mess I had before.

I'll play around some more tomorrow, it's late right now but if you have any suggestions in the meantime as to what I may be doing wrong? Cheers and nah ni for now.

[Legsmaniac]

Nope, I give up. What an I doing wrong? How do I get TPM serial working? 🤔

[Aircoookie]

So sorry, apparently I got the packet start byte mixed up :( Also had another bug where it would only display every 2nd frame... Both now fixed!

[Legsmaniac]

WHAT?!?!?! Arrrgghhhhhh!!!!! You caused me a major headache and loss of hair from it all being pulled out in frustration!!!! 🤣

But as you're the dev of the brilliant WLED software, I'll forgive you. 😀 Off to download, compile, flash and try it now.........

[Legsmaniac]

Sad to report that although I now get a changeover from effects to TPM, it's a mess. Only the first two strips of 60 leds are in sync, the rest of the board is random dots everywhere. So I tried 60X8=480leds, 1440 channels and it's exactly the same - first two strips in sync and then a right old mess.

As for TPM2.NET, works OK 60X8 but nothing happens above that. My guess is it won't work above about 500 leds to comply with the 1497 UDP limit. There MUST be a way to increase it though because as I've said before, the original and stand-alone sketch works perfectly.

I do hope you'll consider raising the current 1500 led limit when you implement matrix features in WLED in the future otherwise the matrix options will be pretty limited and that would be a great shame. Yes, I've still had to modify the code to allow me to input 2040 leds.

So, back over to you, boss.

[Aircoookie]

I'm sorry to hear that! Did you try if increasing the baud rate to 921600 in wled.cpp Serial.begin() helps? With 115200 at 30fps, only about 150 LEDs would be possible. Even with 921600 only 1000 will work, so you might even need baud 2000000. I'm not even sure the ESP reliably supports that 😄

Yep, in my testing udp packets above 1472 bytes are not received by WLED - even when i circumvented that check in code - nothing happens. I wonder how the standalone code pulls that off - will need to investigate in detail when I have time.

I will build a 20x20 matrix soon, won't be as huge as your setup but it will hopefully allow me to find a bit more of these issues myself.

The problem with raising the LED limit is memory consumption. 1.5k LEDs will already leave very little memory on ESP8266 for handling requests. On the other hand I recently improved memory consumption, so a new 2048 LED limit wouldn't be that out of reach. And we could always make it conditional, ESP32 has enough free memory for thousands of more LEDs. Another issue is framerate though. With 2000 LEDs in series and WS2812, you'll be looking at 15fps, which starts to feel sluggish. It's ok if you run slow effects though. (or does your matrix have multiple controllers or multiple input pins?). Will consider increasing the limit!

[Legsmaniac]

Did you try if increasing the baud rate to 921600

Indeed I did, it was the first thing I did.

Even with 921600 only 1000 will work, so you might even need baud 2000000. I'm not even sure the ESP reliably supports that

Then how come does it work with the stand-alone sketch? 😉 Or do you mean your script incorporated into WLED? In which case, I'd sadly have to rethink my plans for my matrix.

I wonder how the standalone code pulls that off - will need to investigate in detail when I have time.

I have no idea but it does work. And very well too. Please do investigate it. Better still, load the sketch onto an ESP and test it for yourself.

The problem with raising the LED limit is memory consumption.

I accept that but when you first started WLED, it worked on 1M boards and is now no longer recommended (unless using the 1M sketches). My point being, as WLED grows then so will the need for more memory, especially since you plan to add matrix capability in future releases. That said, my NodeMCU Lua 12-F with 4M runs your WLED on my 2040 matrix no problem.

1.5k LEDs will already leave very little memory on ESP8266.... ESP32 has enough free memory for thousands of more LEDs.

What about the Wemos D1 Mini Pro 16M? Isn't that an 8266 with 4 times the memory? 🙂 So yes, it would have to be made clear to users of WLED that if they wish to use obscene amounts of leds, the choice of board is paramount.

Another issue is framerate though. With 2000 LEDs in series and WS2812, you'll be looking at 15fps

I have often read this, understood and accepted it. However, I have never noticed it be that slow on my matrix during testing. In fact, when I loaded the afore-mentioned stand-alone script and used Jinx!, I had a go running a few Disney videos on the matrix for fun and to my surprise, they worked! And played flawlessly. And if you don't believe it, I'm happy to upload a video as proof! 😝

It's ok if you run slow effects though. (or does your matrix have multiple controllers or multiple input pins?).

As I stated in my original TPM2.NET request thread, "slow" effects were indeed my intention, quite simply, Christmas Animations and scrolling text and suchlike. And yes, my matrix does have the ability to be altered for (up to) 7 parallel inputs as I've already mentioned elsewhere, something else I have played with and tested. For what I want it for though, I didn't notice any difference in display speed when using 7 inputs to a single feed so I've opted for single for now.

Speaking of Scrolling Text - is this something else that can be added to WLED? 🤣

[Aircoookie]

Not yet have gotten around to investigate why it fails for larger LED counts... About memory, I'm not talking flash memory here (there are 1m, 4m and even 16m boards availabe, that is correct!) but about RAM/heap memory. Without LEDs, there is about a maximum of 25kB or so of free RAM. Additional connections to stuff like MQTT will also use up some and at least 15k free are required for the webserver to operate reliable. Each LED needs at least 3 bytes, so with 2000 LEDs thats already 6kB. Nothing for any modern device or even the ESP32, but with ESP8266 it is a serious challenge.

Scrolling text... Yes, once we have built in matrix support :D

[Legsmaniac]

Ah, gotcha. So it's the heap memory that holds the arrays, yes? The more leds, the bigger the array?

On the Matix running 2040 leds, on the Info UI page, it says Free Heap 8.5kB That's good, is it not?

Maybe I should try an ESP32 again. I haven't had much joy with them with WLED so far. Or maybe I just haven't bought the right one yet.

[Aircoookie]

Exactly! 8.5kB is already quite on the limit, from my experience lower than 10kB can cause sporadic issues. But if it works I'm happy :) What happened when trying the ESP32?

[Legsmaniac]

What happened when trying the ESP32?

Can't remember exactly now, just didn't work for me. I don't have any 32's to try anymore, sent 'em all back.

[sofakng]

@Aircoookie Is this still planned for 0.13.0? (ie. baudrates higher than 115200)

Have you considered adding support for the HyperHDR AWA high-speed protocol?

[softhack007]

Looks like this is actually outdated ... last activity 2 years ago. We have TPM2.NET as a protocol, and serial baudrate can be set between 115200 and 1.5Mbit.

In case there are open ends, please open a new feature request.