It's pretty amusing how a bunch of teams are posting videos on how they built a specific, bespoke hardware/software component or two of MrBeast videos. This one was about the ~100 hardware button sets and LED strips required for the video. And here is another one [1] that is on how another team build 456 "detonator units" for the Squid Game video: also finished in the nick of time.
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!
Unfortunately we are not going to see the behind the scene of the VFX of the recent videos, I saw the video about the train and the big hole, it's full of VFX but many people argue that the video is genuine so revealing the use of VFX would kinda ruin the video for many people. This wasn't true for the squid game video because the fun were the players challenging themselves, or at least I hope the viewers were not actually thinking that the players were doing tug of war on a 100m high cliff.
I agreed after watching Will Osman's video last year since Mr Beast was in it a few times, but watching this one Mr Beast didn't meet with the dude once even to say thank you?
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.
I'm happy with the way things turned out. Obviously can't disclose detail on our arrangement, but I'll say there was nothing scummy here. I just hope the MrBeast org can get to a phase where they have more time for planning out any video requiring technical integration.
The 'struggle' and the lack of time is implicit in the entertainment value of watching what unfolds. I'd argue most of this type of content is specifically geared towards dramatising what should otherwise just be planned accordingly with a decent producer.
These folks are smarter than smart when it comes to gamifying the human psyche.
Heh, well in this case there is good context in both the video and the blog post. To be honest, I usually prefer the blog post, and that's why I typically write up a completely separate blog post (or series of posts) for every video where there's technical detail.
We've had newscast-speak, that Midwest tone and cadence of half-walter-cronkite and half-peter-jennings. We've had valley girl-speak, the rapid-fire slang ending on an upnote that's rediscovered every few years by a new generation of folks not living in Cali.
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."
Can someone ELI5 so that I don't have to watch 2 random YT videos?
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?
It was a game to see who would last the longest. Each room had someone the age of the room number (so 1 year old, to 100 year old). There were a series of votes and challenges using a hardware three button box (geerling worked on this). They also had synced lighting in each of the boxes.
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.
You can read the blog post mentioned in Jeff Geerling’s comment in this thread. It does a nice job of detailing the problem and his solution w/o needing to watch the video (which he does recommend, but I found the blog post to be an enjoyable read anyway).
It's not for a cool 20 minute video. It's for the collective viewing time of some 2.2 billion minutes of entertainment. There is no reason to use bootstrap-budget on the supply when the demand is this high.
For someone clearly rolling on it, you think he could have popped down to meet the people literally killing themselves (5h sleep) to make his show work?
Nothing an individual does moves the needle. I'd be curious about the effect of showing to billions of people that this was all bought for one time use versus showing a hackerspace where you get, use, and then return your components. (Though, a single video is not going to move people's needles, it's again/always about collective changes...)
Are you living a waste free lifestyle or something? Just seems petty to come dump that on someone's project. You can leave the same critical comment on millions of people's work, and they will all have the same zero positive impact.
To the first point: are you? We all do what we can but obviously that's currently an impossible ask..?
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)
I really don't get why debouncing is such an issue in this situation.
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.
The 12 hours were spent after everything was done, it just fit the narrative better to include the high speed footage in that segment.
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.
> 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.
...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
The instant I saw that part of the video I was reminded of how I had to hack an MQTT debouncer for my doorbell sensor (which is a repurposed ZigBee door sensor with a magnetic reed switch placed near the coil).
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)
(3) is the usual way debouncing is handled, just ignore inputs for a set time after a trigger has been detected. And this is about the second lecture in an embedded software course. So from that I got that the guys aren't really domain experts. Which honestly makes it more impressive to me that the managed to pull it off.
My least favourite implementation of that is requiring some delay with no changes before the input is considered triggered.
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.
There's a ton of nuance to something as simple as debounce, and that's why the Ganssle article is so great; unlike the simple comments ("just add a 100ms sleep to your code!"), it explores the end to end experience with each given solution, both in hardware and in pseudo code.
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.
There is ton of nuance in the physics but "trigger on first and wait" is objectively fastest response way to do it.
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 have almost never seen hardware debouncing. It's just way better done in software. Unless you have extremely specialized switched which require HW debouncing(???), please just do it in software.
so you can solve this one of two ways. 1) implement what they did and solve the hardware signal issue of bound (the right way). 2) implement an irq in your software reading it to poll every few ms and hope you don't read in the trough. Registering extra button clicks should not be the problem of the implementor. It's a hardware failure. However, in this case, he also is the firmware implementor so the firmware needs to be able to fire "onClick" once when the button is pressed once, regardless of bounce.
I was like "surely there is off the shelf solution to connect like 8 I/O ports into the network" the whole video about designing it. I guess just some networked PLC ?
I would be using PLCs and RS485 for this project. I can't figure out exactly how many IOs they'd need per cubicle (I guess 3 buttons, 2 LED colors) but I'd figure you could use one PLC for maybe 6 boxes...
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.
In the blog post I mention using RS485 (or CANBUS) instead of the solution we went with, but on a 5 day timeline, and building on a set where I wouldn't be present (initially I was not planning on being there at all during the shoot), I didn't want to put in a solution someone else on staff couldn't at least wrap their mind around.
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.
That was what my Dad mentioned too—he's built a lot of signaling systems for tower sites and radio studios and was nervous about me running 3.3v over any length of Ethernet. But he assumed we'd have shielded Cat5e at least... that would've helped somewhat.
Either pullup or pulldown resistors would have helped - you see this a lot in PCB design, even short traces that are used for signalling will be pulled low or high via a relatively high resistance. That ensures that you have a sharp transition when the switch or whatever is closed or opened and that a floating voltage can't appear over time on your line and cause false triggers.
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
How much accuracy do you want? Now you have issues syncing all the SBCs to a timeserver and how much drift their internal clocks have. Some of those things have very vague timing.
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.
Quite true. And a few of the hard requirements became a bit softer after we got on-site and ran into the issues that couldn't be solved for lack of time.
There are modules where you just have ethernet and few IO ports, for example WISE-40X0LAN series.
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
I feel like the implementation of this was needlessly complex. Instead of running all that CAT6, why not use some ESP32's and throw up a few AP's? You could also wire up multiple rooms to one MCU to cut down the amount of devices needed.
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.
Haven't watched through so maybe that but I don't get it. I reckon it's a quick answer quiz type of a show with some buttons and LEDs? LED is probably going to come down in DMX, buttons go back in Ethernet or RS485, what is button debouncing and soldering comes into play in that???
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.
While I personally do not resonate with the culture of YouTube “influencers”, and am unfamiliar with the influencers mentioned, nor am I inclined to view any of the videos, I have looked at the blog post below and have identified several areas for potential improvements:
>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!
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!
[1] https://www.youtube.com/watch?v=hdt18p-VMmQ