Not sure about the original LED used there, but with the popular LED tapes built on the WS2812, you should be able to drive at least 200 of them within 20 milliseconds.
That gives you the idea, then yes if you want to run more LEDs then use more outputs and drive them in parallel.
This is a fun article, I enjoyed reading about the reverse engineering aspect.
These days you can easily buy 5 metres of dirt cheap addressable LED strip and control them with an Arduino and FastLED. You don't get same learning experience though!
When using FastLED keep in mind it's still not compatible with chips containing 2 or 4 LEDs (Warm/Cool White and RGBW), like many WS2812B strips available online. At least in the case of RGBW the strip will work, but the white LED will remain off.
I prefer ESP32 boards myself. Super fast, cheap and they have Wi-Fi and Bluetooth built in.
There are some pitfalls, such as the ESP32 using 3.3V logic whereas most LED strips use 5V logic, but once you figure out how to use them they can be very powerful little beasts.
I really wish a lot of consumer electronics had better documented protocols and a place to attach an interface. Programmable smart hardware and consumer hardware like this rarely has a lot of differences between them except for price and the lack of documentation.
There's some awesome LED strip kits that are absolutely the right price, but I have no easy way to hook them into my home automation system. And ones that can cost an order of magnitude more.
I get that, but consumer electronics are focused on the average consumer, who doesn't want that. And they're cheap because the people making them relentlessly focus on price optimization, not add-on features for niche markets.
I reverse-engineered the protocol for a cheap vacuum [1], and it's my professional opinion that the protocol is pretty slapdash. It works well enough for the intended use, but has a bunch of rough edges. It clearly wasn't made with randos like me in mind, and making a good consumer API would have been a bunch more engineering work. Plus documentation and support. That would take money and time, and this was Wirecutter's #1 recommended vacuum because it was cheap for what you got.
It isn't anymore, though, because one of their competitors dropped the wifi connection and put the money into other features that general-audience consumers cared more about. "The most obvious downside is that the 11S doesn’t have Wi-Fi, so you can’t control it from your phone or with voice commands. We’ve asked around and were surprised to find that actually, most people are pretty lukewarm on Wi-Fi control anyway." [2]
So I too like tinker-friendly features. But the economics of mass production being what they are, I expect I'll generally have to pay niche-audience prices for them.
I'm definitely not asking for consumer electronics to have a "good consumer API" or support for being hacked on. It'd just be nice if there were slightly better notes on what those slapdash protocols were.
Often I find this documentation already exists (for internal use), but just isn't shared publicly. For instance, Insteon smarthome devices have stopped publishing new developer docs for their hardware, but they do have them internally and on rare occasion I've gotten someone to share one.
I get it. That would be nice. But from the product manager's perspective, I don't think it's generally workable.
The problem with publishing whatever they have lying round is is that a) even if you won't, many people will complain that it's a poorly documented, slapdash protocol, b) it's now a public protocol that they're going to have to support, and c) it sets a precedent, so that people will expect future product to have public documentation and support. It also builds a constituency that will noisily push for niche features that may not be economical.
Letting people reverse engineer and dealing with occasional document leaks don't add the same risks. Indeed, it's probably cost-optimal: the hackers still get what they want, but the company takes on no new obligations and makes it very clear that the hackers are on their own.
The Chinese Saleae Logic clones are great, they're dirt cheap and you can use them with sigrok, which is open-source and has built in decoding of many wire protocols like SPI and I2C.
Because there is no data in - data out in the LED, it has just two wires; you need to assign it an address and that part is not explained by the Chinese producer.
Could anybody crack that one?
As has been mentioned in this thread, there are much better deals these days for addressable RGB LEDs. You can order the strips or strings from US/other western outlets for higher cost but faster shipping. Or you can go on Aliexpress and order them for a hell of a lot less from closer to the manufacturing source.
I started out messing with strands from Adafruit and learning the basics of microcontrollers but when some friends and I started playing with bigger projects (or just wanted more lights to fool around with in various things) we just ordered them by the 5m spool for 1/4 or 1/5 the cost on Aliexpress.
The pros of ordering domestically are faster ship times and likely some sort of QA/return policy. But if you just want to order 10 or 20 or 50m of RGB LEDs to screw around with FastLED projects and can handle waiting 1-3 weeks for shipping (even if you pay extra for faster shipping it's typically still cheaper) you can get many more lights per dollar spent.
