How Jeff Geerling almost broke MrBeast's 1-100 video [video]
youtube.com
youtube.com
It seems clever for MrBeast to hire DIY YouTubers to do these bespoke jobs: it's a win-win even after the video, as they teams create their own "how we built this" video. It also gave me an appreciation for both how much work these massive videos are (we only saw one smaller part of the video, a hardware put together) and how chaotic it can all feel!
I have to imagine he didn't get paid other than "exposure" (which is admittedly probably worth something from Mr Beast) so it feels a little scummy for the person who's getting rich to not give at least a little in person acknowledgement to the folks doing all the work behind the scenes.
These folks are smarter than smart when it comes to gamifying the human psyche.
Thanks though Jeff, I don't really like videos, but your stuff is always high quality and fun.
And now MrBeast-speak, with is up and down tone and bouncy cadence, saying every word ad if it were a reason to smile. As he rose in popularity, folks working with him picked it up, but now it's ever-present across influencers desperate to replicate his success. And even Jeff has drifted this way.
I found it distracting, esp compared to Jeff's vids from just a few years ago. Still, "can't argue with success."
What is a "1-100 video"? It looks like some experiment on people with random electric "things", that those two YT "celebrities" (from quick googling the name "MrBeast") did? What is being broken here?
The problem came down to a few issues with using exposed boards, lose cables, grounding, and other issues common to most people working on these kinds of projects.
Jeff Geerling commonly makes videos and content around software engineering and the same kinds of hardware you'd see here. He's authored at least one book on Ansible and maybe more.
Sure, it's for a cool 20 min video, but all the single-use buttons, mats, acrylic panels, LED strips, custom-made ethernet cables, ... A shame IMHO
Viewing stats for some videos/events can be hard to get your head around. That's about 50 lifetimes by my calculation.
Also, a social media website is probably not the right place to point out that other people are wasting their time...
To the second: I'm not "dumping" anything on anyone's project, I'm replying to the person I was replying to (edit: just saw that's you /edit). They dismissed some argument because an individual project (including apparently ones with a billion views) allegedly can't have an impact and I see that differently, that's what I was commenting on, not the submission (it's not a top-level comment)
Like it only occurs when somebody has hit the button no? So if somebody hits "Accept Challenge" and then because of bounce it triggers "Accept Challenge" multiple times why does it matter? Afaik, either you can (1) trivially lock them into their first choice, (2) send the extra bounce choices (which will be a noop on the server), (3) prevent changing choices in <50ms. Any of which don't require spending 12h.
I have at least 2 kitchen appliances where the delay is too high, and the user experience is that you have to press and hold the button in order to trigger it, because tapping it too fast doesn't count.
So frustrating, when the right way to do it is so easy.
Maybe I just need a microwave with Cherry MX keycaps.
Too many people find a solution that fits the bare minimum requirement and move on, leading to years of frustration from the end users. Spend a little more time using the thing like an end user would, and you can solve that issue much better, usually.
onClick event handlers in most GUI triggers on mouse button releases, for example.
Only reason to do it other way is if you have some limitations. Like timer being costly on resources (valid concern for microcontroller)
> Too many people find a solution that fits the bare minimum requirement and move on, leading to years of frustration from the end users. Spend a little more time using the thing like an end user would, and you can solve that issue much better, usually.
A little time won't give you much. Those are kind of problems where you need to be using it daily in anger to find the issues.
Like the buttons on elevator where I live. I press the button, it lights up, I do it few more times, debounce works fine!
Another day I'm in hurry, press it quickly, does not work. Turns out someone picked the worst way to debounce (wait till it is ON for that amount of ms), and on top of that tied LED to button itself so you see the light flash but button does not turn on). So you can't just tap it quickly, and you can't risk tapping it more than once because that would cancel the floor request
I had to solve the debounce more efficiently, because there were actually a few other challenge ideas which would've used the buttons and relied on more precise timing behavior.
The idea was every press would be registered correctly not matter how fast someone hit one, two, or three buttons. So simpler debounce algos were out.
In the end, I recommended against timing-based challenges because with those buttons and the Le Potatoes' strange behavior if you held down a button for more than 50-100ms, I couldn't guarantee every button down/button up would be registered, depending on the dexterity of the individual doing the pressing.
So in an odd turnaround, one of those games might artificially boost certain age groups' ability!
Also check out my blog post [1] for the exact debounce code I wound up using.
[1] https://www.jeffgeerling.com/blog/2023/100-sbcs-python-flask...
...no ? Only if you care about both on and OFF timing you'd need to get creative.
You can just
* trigger on interrupt
* ignore that input for say 50ms (or how long you want your debounce period), whether by disabling interrupt or any other way.
That way you will always catch it, on the first bounce, the fastest possible way. And as you are "NANANA NOT LISTENING" on the pin, doesn't matter whether it bounces or not.
Same with holding, as long as previous registered state was ON and you get OFF, you just send the OFF higher up the stack, start the timer, and ignore any further input for that duration.
I think that's what your code is mostly trying to do
Every time the doorbell rang I got 10-20 “sensor open/close” events, which was fun.
(Ended up using just one Node-RED trigger node with a suitable interval, since I already had that in the loop)
Hell, resistor and a capacitor on the input would probably be enough.
Or just poll every 50ms
I have to say, much like you, I am finding the 'debounce is an incredibly nuanced thing to implement' commenting to be... odd...
The 1-100 video reminds me a lot of that 'climbing for dollars' bit from The Running Man, so, you know, maybe it's a good thing they find debounce an incredibly hard concept to master.
Off to the supermarket now to buy mouthwash!
In hindsight... there's always a lot that can be done different :)
And regarding the debounce—I don't mention this in the video explicitly (for time), but there were three other 'modes' for the buttons that were implemented that were never ultimately used, for games like Simon (press colors to match a pattern), and timing-based games, so the debounce was actually critical to allow varying ages to press buttons sometimes in tandem and sometimes in sequence with certain timings.
Because of the issues we had (not the least of which was a weird bit of a drain on the 3.3v as you held down a button), I recommended against some of the challenge types. In the end, the only things that made it to the final cut of the 1-100 video was the 'yes or no' style votes on a challenge. Which, yes, are incredibly easy to debounce. Lock in the first button press and you're done ;)
Yeah, 3.3v isn't really viable as a signalling voltage for anything that leaves an enclosure unless you take steps to mitigate interference such as differential signalling, shielded cable or some sort of protocol rather than presence/absence of voltage. It's just too easy to induce that voltage - albeit very temporarily - through capacitive or inductive coupling on even 10m of wire; as you experienced it's also too easy to have that voltage mysteriously leak out into what a multimeter will tell you is a definitively open circuit.
If you're thinking of doing something like this again, I'd suggest:
1. Definitely use PLCs, their inputs are inherently hardened and you can use 24/48/240v signalling voltages - and by extension a whole universe of very robust industrial indicators and switches.
2. Don't use data cable for non-data transmission, the twisted pair coupling will give you issues you don't want and the stuff is fragile as anything. If you want a good cable which supports multiple non-data channels the term 'pilot cable' or 'control cable' will see you right, that's a multi-core cable which usually has 4 thick cores and a bunch of thin pairs, it's traditionally used for carrying 4-20ma signalling loops in factories and oil rigs etc, it's well shielded.
3. Do use RS485 to loop your PLCs together.
4. Don't use weak voltages on stuff that's being handmade and screwed together onsite. You run into all sorts of transient issues, 3.3v will balk at a loose terminal whereas 48v will romp home if there's even a hint of contact.
It's pretty much what you've built but industralized. And, as it is for industrial stuff, pretty pricy, 150 EUR a pop. But works with via both HTTP and MQTT
You...had current limiting resistors in series for each buttons, right?
edit: I think each buttons could be made to register the last pressed UNIX time rather than sending out button event, so the host can collect reports and sort out time sensitive aspects "later" in the loop to account for delays and reordering type of issues
If timing is critical I'd run all the buttons back to a dedicated device but where you'd find a PLC-alike with 200 inputs polled 'simultaneously' (FSVO simultaneously) I don't entirely know.
This is the type of project where very particular issues become annoyingly apparent only after you've chosen a hardware platform.
Hell, if you wanted to do a prebuilt solution, ESPHome is almost perfect for being able to quickly spin up an ESP32 with button inputs (and debouncing) and control of some relays. Pipe the communication over MQTT and handle the messaging using some server software.
Architecture wise, I never thought I'd say this, but I think Arduino PLC unit thing they recently launched might be a good fit for this. The programmable PLC units would synchronize to a broadcast time sync packet, record time when buttons are pressed, and a central laptop would collect data in an asynchronous manner. The PLC units could send out "the rest of you are too late" broadcast to limit candidates of fastest buttons, optionally. With industrial PLC stuffs it'll be all screw or crimp terminals with debouncing likely built into PLC. No mess. Definitely more costly and there will be some learning curve(I'm not even completely sure if what I said is how it could work), those will be cost and risk factors though.
Or a bunch of used office desktops and surplus keyboard/mouse kit through eBay could work too. A mouse has 3 or more buttons, and a full keybaord has 3 LED output that can be wired to an SSR. They have debouncing and all programmatic controls built in. Parallel ports on old computers could work as well. Some people loves using /usr/bin/eject along 5" ODD for an extra degrees of freedom and it could work too for show purposes, such as for a mock "jail door", a lightbulb, or a party popper device.
But either way, I don't see where in that Raspberry Pi has to come into play, especially with supposedly generous budget and a fixed deadline.
>and we had two basic options
- The two options presented are not optimal. While one is superior to the other, there exists a third option that is commonly employed in most automation systems/SCADA/DCS. This involves linking the main controller to the field RTU via profinet/profibus. Utilizing this architecture from the get go could have mitigated many of the challenges encountered like:
- - The wiring could have been minimized due to increased flexibility in topology. Moreover, by employing industrial ethernet, issues related to static charges could have been avoided.
- - Profinet supplements standard ethernet, thus enabling the network guy to utilize consumer/enterprise equipment, thereby resulting in cost savings.
- - Profibus and profinet can be combined depending on the design requirements. Without a diagram, it’s difficult to provide a definitive assessment. However, the general approach involves routing all IO cables to the RTU and then connecting a single cable to the master controller.
- The use of SBC should have been avoided. As discovered later, having a full OS for a simple control task is not ideal and often results in “hacky” workarounds. A more suitable alternative would be an industrial controller. Despite sounding complex, these controllers are available in compact sizes, are cost-effective, and can be purchased in bulk and also available since unlike SBC, they have less demands. They also support features like profinet etc. The investment would then be focused on the master controller and one or more switches. For 100 RTUs, a single master would suffice.
- If an SBC must be used (not recommended), then it’s advisable not to connect the GPIO directly to your relays! A servo driver could be used instead. Without a wiring diagram, it’s difficult to provide specific advice, but this approach could result in significant savings on relays and even on the SBC since some drivers can support up to 16 outputs and can be cascaded if necessary. In theory, a single SBC could have been used, but this is not advisable for a lot of reasons including the extra wiring will be needed (where profibus can be used to save that)
- If an SBC is used, Node.js tends to offer better performance than Python on SBCs from my personal tests (a low-level language would be ideal but time constraints may prevent this), and it integrates better with UI.
- The decision to avoid Wi-Fi was prudent; it would have likely exacerbated issues, band interferences, among others. However, wireless options such as VHF or Zigbee could still be considered. Note that VHF might require a license depending on your location.
- Socket.IO could have been used for all 100 units or protobuf, both can and will perform well from my tests, one time I tested around 1000 connected IoT and performance was good.
I have additional comments but I don’t wish to appear condescending. After all, I understand the pressures of meeting requirements within tight deadlines. So well done!