Profile cover photo
Profile photo
Thomas “Balu” Walter
Probiers mal mit Gemütlichkeit...
Probiers mal mit Gemütlichkeit...

Communities and Collections
View all

Post has attachment
(Off Topic?) Sean Hodgins created an addressable 7 segment display module using WS2811 chips.

I love the idea to abuse the three channels to each control a segment and do something the chip wasn't really designed for.

After lurking here for a while, I'm going to start my first project with an ESP32 and a 18x16 LED matrix plus 60 extra LEDs (based on WS2812b strips) - a "Word Clock" with a 60 LED ambient light border (or seconds display...).

From what I've read lately I should use the RMT driver on an ESP32 if I want to do Wifi and that supports 8 channels by default?

According to Mark Merlin amazing blog, I should even be able to receive IR signals too then (which uses one RMT channel?)?

I'm also thinking about adding an i2c RTC...

Since I have no experience with FastLED and it's parallel output yet (or ESP32 for that matter :)), I wonder if the strips have to be of the same length.

Right now I am thinking of doing 4 channels each driving 4 rows a 18 LEDs (72 LEDs) for the main matrix plus 1 for the 60 LEDs for the ambilight. Having the strips in rows would make selecting the "words" easier. Total: 5 channels

Another option is rotate the strips 90 ° and do 6 channels with 3 columns a 16 LEDs (48 LEDs) each. Plus 1 channel for the 60 ambient LEDs as above. Total: 7 channels.

I think I'm going for the first because of the easier "word selection" (word starts at LED X and is Y LEDs long).

Post has attachment
Add a comment...

Post has attachment
... bring balance to the force, not leave it in darkness.
Add a comment...

Hey guys,

I have a few question on the state of ESP32 and FastLED. If I recall correctly the ESP32 is supported since v3.1?

I'm thinking about using an ESP32 to set up a small display based on 4 matrices with 8x8 WS281x LEDs.

What would be the best way to do so? Does the standard library support parallel output on an ESP32 too? Does it make sense to split the output so each matrix gets its own pin? Does Wifi work while controlling the LEDs?

What else do I have to watch out for?

Disclaimer: I work in the IT department of the university where the efail security research was done, but I am not directly involved with the research.

I'm disappointed. Disappointed by a community that discredits months of work done by a commited team of security researchers. Work that is now being reduced to some core topics while it has a lot more to look into.

First this all started prematurely, because members of that community weren't able to keep silent as they agreed upon. This resulted in the team having to rush the publication. And now people blame them because the publication was rushed. m(

Then the crypto (especially PGP) community went through several stages of panic. It is their reaction that made it into the clusterfuck it is now.

After the first infos started leaking, Sebastian carefully stated that "critical vulnerabilities in PGP/GPG and S/MIME email encryption [... exist that ...] might reveal the plaintext of encrypted emails, including encrypted emails sent in the past."

If you read and actually think about it, it is exactly what the paper discloses.

But that's not what people did. People read "critical vulnerabilities in PGP" and went into full panic mode: "OMG, PGP is broken. Crypto is useless now.". Instead of reading closely and analyzing what was said, they ran around like scared chicken in a barn.

But even worse, when they had the chance to calm down and look into the details, they started getting defensive and blaming others: "It's not us, it's them." It was everybody else's fault - the clients for not understanding the API, HTML in emails, ... Assigning blame and pointing fingers at others does not help fix the issues.

I'm not into crypto, but if your API allows others to do bad stuff, you are part of the problem. Decrypting content, displaying it in cleartext and then warn that there might be a problem because you have to support legacy clients for 17(!) years now? That's just an excuse. These days a missing authentication tag should not result in any output at all.

To me "It is secure if you use it correctly" translates to "it is not secure".

Enigmail and other clients had to be fixed because of the findings in this research.

In addition people and the media mangled the original suggestions for a short term mitigation to do "No decryption in email client [but in a seperate application]" and started suggesting to not do any crypto at all. Which of course resulted in even more angry reactions towards the research team that didn't say any of that.

All this resulted in undermining the real issues. Instead of looking at the problems and asking "How can this be mitigated?" and "How can this be avoided in the future?", people started tearing each other and the paper apart.

A paper that is about a lot more than just PGP. S/MIME being a big issue. An encryption protocol that is used in corporations, by government agencies, the military, etc... that has core protocol issues that can't easily be fixed. An encryption that is built into mail clients by default.

A paper that also should make us think about email clients being way too willing to reach out to remote servers even if you have remote content blocked. The paper lists about 50 different backchannels with a lot of them working with remote content blocked. And still people spread the "solution" that disabling remote content or HTML will fix all the problems. Which it doesn't.

A paper that resulted in a problem being dug out that has been reported five years ago and still exists today (

A paper that shows a serious example of a feature interaction bug that deserves a closer look. Or as I've read somewhere - a case study for proper authenticated encryption, safe and well documented APIs and against secure email in general.

But I guess it is a lot easier to focus on a single topic, blame others for doing it wrong while allowing them to do so in the first place, ignore everything else because it's not you anyway and while you are at it shoot the messenger without really listening to what he has to say. :-(
Add a comment...

Not much going on in here? Is everyone busy with projects? :)

As someone who is just starting with WS2812Bs, I am a little overwhelmed with all the options (as in libraries, etc) I can choose from. FastLED seems to be an interesting choice, but I can't put a finger on why because it's difficult to compare the features... One thing I noticed is that some libraries are starting to use DMA as a method on supported architectures - is that something FastLED is doing too or working on? I am just curious because it seems to be a really effective method to reduce the amount of time the processor is used to show the LEDs.

I am working on a little project that is going to use three 8x8 WS2812B LED matrices to display data it loads from the internet. Perhaps you can give me a few pointers on my thoughts:

FastLED seems to be more of a driver to output data to the LED strips itself and provide some extra functions to handle color values and fast calculations?

Is there a suggested library that'll make handling my matrices easier? Something like Adafruit's NeoMatrix, but for FastLED? I've found LEDMatrix by Jürgen Skrotzky so far.

I think the (fairly new?) option to parallel output to each matrix might be overkill for each set of 64 LEDs? Is that something you'd do on an ESP8266 or ESP32?

Do you have other pointers that might help a newbie get into all of this without getting a brain buffer overflow?

Post has shared content

Post has attachment
Now that looks like fun. And for some reason I immediately thought about OpenBuilds parts...
Wait while more posts are being loaded