 their badge. Wow, not everybody. That's interesting. Who of you have started their badge? No, more or less the same. Who didn't do anything with their badge yet? Oh, quite some. Who wants to do something with their badge when they are at home. Wow. Who has written something for the badge? Wow, you're amazing. Who has used something somebody else wrote? Wow. You have quite a crowd. Are you ready? Okay, so you have the crowd for the badge. They are very interested to get more about it. Have fun with the badge team. Thank you. All right. We're here with three now. I hope the others will join us before the end, because, of course, we want to thank everyone. And I would like to start with this little throwback to the last badge talk, because this over-engineering as a way of life. The last time, this was a second cost fallacy as a way of life. So this may be an improvement. In this talk, we would like to take you on a little journey through, well, how we came to be here with this device. A little bit of history on, well, how did badges even come to be and what was there before? What do we manage to deliver? How we managed to deliver that and the challenges on the way. Some challenges we experienced throughout the end of our journey. And also, what does the future hold? Because this is a pretty cool device. But, I mean, if the camp ends, does the badge adventure end? And finally, some shout-outs to cool things we saw happen with the badge during camp. So I think you all have this device. I don't see everyone wearing one. Where are your badges? Yeah, okay, it's raining. That's a good excuse. Fair enough. But, of course, this badge is not your ordinary conference badge. I mean, I think you all know this, for example. Everybody who's been to normal conferences will have seen something like this. It can be a credit card-sized badge or something else, but it always has your name on it and maybe the company you work for or the organization you're attached to. And it gives people an introduction to you, which lowers the threshold to talk to you, which is nice if you want to network, of course. But how did we get from there to here? Well, actually, it may surprise you because, of course, there are a lot of differences, a lot more components. We now have batteries and lots of chips on it and proto area. And it all started here in 2006 at DevCon 14. This badge, it was as fancy as what we know now for badges. But DevCon had badges with distinctions between categories of visitors, I think some of you will know. And they wanted to reduce counter-fitting of badges, so they designed something that was hard to copy, at least in the time span needed to do so. So they made a badge with a little microcontroller on it, a button, and two LEDs that would blink in a pseudo-random pattern. And there were different versions for visitors, for VIPs, for organization, et cetera. And then the next year, it evolved to this. It suddenly had a display. And this could display your own text. It had a couple of touch buttons. These are touch buttons. And it had a battery that lasted long enough to last a conference. This was a do-it-yourself matrix display consisting of a couple of SMD LEDs. And so this was kind of the first badge with a real display. Then the year after, suddenly it had badge-to-badge communications and SD card reader on the back. People were hoping for the first badge-to-badge worms during this DevCon. And then two years later it jumped to Europe. As far as we could figure out, so don't pin me on this, as far as we could figure out, this was the first European event badge. Electronic hackable event badge. It had a display. You could play games on it. It had Easter eggs. It was hackable. It had badge-to-badge communications via LEDs. So this actually already looks a lot like what we know today as badges. And then the fancy badge pandemic started. A lot more fun than the other pandemics you may know of. First, in 2011, I think, we had the Rocket 2012 tilde from EMF. The radio 2015, 2016, we had this new version of tilde also from EMF. And then 2017, the Shaw badge. And this was the first event badge for this Dutch series of quadranial hacker events. And we are really proud of it and also set an example and the direction of where we apparently could go. Because this badge, of course, it's a nice piece of kit. It looks good. It has a cool display which stays on if the power goes out, et cetera. This display made it very well readable in direct sunlight. So it was actually very usable as a badge. And it's run on MicroPython. So the menus and all apps, they were written in MicroPython, which means it's really easy to make apps for it. This was also amplified through the hatchery, which was created for this badge. The hatchery where you can submit your own little Python eggs or apps and share them with everyone else. People can download them on their badge via the hatchery client on their badge. It has a serial UI, which means you can connect it to your computer via USB and then program on it via USB, via the serial interface. And this makes it really easy to develop and prototype whatever you want to make. So basically what this badge did was it brought app development and MicroPython to the masses, which is pretty cool for something that's only intended to show your name. Only intended, quote, unquote. So then the question came around Hacker Hotel 2020, what can we possibly do that will be even cooler than a MicroPython ePaper badge? Well, we wanted to do something with FPGA development because FPGAs are kind of like magic smoke, which you can manipulate using bit streams. I won't go into the two technical details right now, but if you can do stuff with FPGAs, that is a really powerful tool in developing for all kinds of devices and applications. We wanted it to be usable after the event because if you have a badge that becomes eWaste after the event, that's not very sustainable. And also, well, why not make something that actually lasts that you can use that is fun, that adds value as, for example, a tool for radio applications or visualization that has educational value, like teaching people a MicroPython or FPGA development. And we also wanted to reuse and grow the Shot 2017 ecosystem where you can share your apps and let other people partake in all the fun things you make. So these were our goals as we set out to create a new badge. And I would say we were pretty successful because we delivered a working badge at the start of camp. We didn't need to do last minute soldering, sweatshops or flashing. More than over 100 apps were created and published at camp. And at least 1600 badges, probably more, but the stats were reset somewhere between yesterday and today, were actually activated and connected to Wi-Fi at the event, which is half. That's pretty good for an event badge like this. And finally, we were able to introduce or at least give access to FPGA development to a lot of hackers because all 3,200 visitors of this event have received this device. And even if they decided to enjoy the camp and go to talks and not fill with their badge at camp, the tool chain that has been built around this badge and everything else will be available after camp. It will be improved after camp. So people can still use it and learn from it and share it when you go home in a day or a week. Hi, everyone. Of course, we did last minute things. So I'm gonna try to do a presentation here. No guarantees. So when we started this journey, we had the Shab badge. We knew why we built that. We saw the EMF 2016 badge. This is amazing. We want one, too. So we made a badge, a nice square, not much artwork, but functional with an E-ing screen. That's also his biggest limitation. You can't really play games on it. It's a bit slow. People still made a lot of fun stuff for it. So when we started prototyping this new badge, one of the first things we did was we got rid of the E-ing screen and went back to the screen that EMF used on their badge. Color, fast. You can play games on this. We added an FPGA because we want to introduce people to new technical challenges. And we added an STM32 because we wanted the USB connection to be more than just a serial connection. We wanted people to be able to use it from a web browser via web USB, use tools to upload apps in an easy way. We partially succeeded in doing that. And the hardware is there. So this is not what you got. You got a way more fancy badge, right? It's not a square. Because we are just engineers, right? We know how to do cool hardware, but we don't know how to do an actually cool badge. So we got into contact with Tilda Industries. Thank you, Nicolette, for doing an amazing job on getting an actual badge, a piece of art that you can wear with pride. It's a long journey towards actually getting a badge done. As you can see here, we went to many design iterations. And we almost settled on this one on the left. And then we decided, no, we actually want to be able to play games on it. So we made it into sort of Gameboy-like thing. But still, you can see the process of going from a square to through many iterations towards what you have around your neck today. We also want to give a shout out to people who joined us virtually. We have, I hope I say this correctly, Uri Shaget, who makes the Wokwi simulator. He can actually fully simulate an ESP32, not just MicroPython, not just upper level things. No, he can fully simulate an ESP32 in the browser using JavaScript. And for this event, he made a virtual version of the badge so people could experiment with it, program for it, even before it has all started. Awesome work. And I also want to give a shout out to Carlos, who joined us a little bit later, almost when the event just started, he showed up and said, I got a cool thing. I got Ice Studio. So we tried to introduce people to the FPGAs, but then you have to install tool chains. And you have to do Verilog, which is a completely new language for most. This tool, which now has support for the MCH 2022 badge, allows you to drag and drop blocks of logic and connect them in a graphical way. It's really cool. Be sure to check it out. And of course, nothing is perfect. I mean, the badges work, so we're not quite far. But a lot of you might have experienced the red kite of death, as we call it, just a badge that does nothing with a blinking red LED. We actually managed to put the wrong logo in the sponsors wheel. Sorry, lettuce. We fixed that in the OTA update. And we actually had some major problems with the battery charging circuit. So, yeah, let me explain what happened with the red kite of death. Apparently, when you have crystals, they need load capacitors. And those load capacitors make sure they start up correctly that they can get going. And when you specify a bill of materials for your Chinese partners, be sure to specify what load capacitance you need. I didn't. Luckily, I wasn't the only one. We actually found out that Adafruit made the same mistake. So they actually already patched this in the SDK. We put a little bit of extra delay in the boot loader. So before it starts trying to access the flash chip, it waits a while, and it fixes everything. So if any of you have intermittent failures with the badge not starting, the kite turning red, please tell us. Come to the badge stand. We'll also publish a file that you can drag and drop onto a USB drive that appears when you put the badge into boot loader mode. That will also fix the problem for people who will find out about this after the event. Yeah, it's always in the details, right? So again, details. Instead of using an ideal diode, which prevents current from flowing back into the battery from your system bus, instead of making that with passive components, I thought, well, we can do this more fancy. We can get chips for that now. So I found this really cool chip, which on the front page of the data sheet says, oh, it has reverse blocking. It doesn't let current through in the reverse direction. Yeah, problem is on page seven, it actually says only when the chip is disabled. So make sure you check that. We only figured out that we actually were putting five volts in the battery a couple of weeks before we started production. That's not nice. And actually, how did that happen? Well, on the prototypes, we actually made sure to disable this chip. And we put a little circuit in place with a transistor that was turned on when you plugged in USB. And key night, people might spot the mistake I made there. I should have put the 10K resistor in series with the USB voltage so that it actually acted as a voltage defider. I didn't. And I only noticed this afterwards, of course. So yeah, the result was some leakage voltage from the diode could actually cause the chip to turn off. So your badge wouldn't work on battery. And yeah, we figured this out. Well, okay, it all seems fine when you connect it without this extra circuit. So we just removed it. That's why you now no longer have the bypass diode. Because, well, current can flow and reverse through the chip. Don't do what I did. So the one warning that I give to all of you is don't touch the battery chip if you've been charging your badge for a while. It gets quite hot. Otherwise, everything worked out. And as you saw in our early design, the prototype, we used an STM32. And we used some extra chips like IO expenders and a fancy DAC chip for the audio. And none of those were available anymore. The chip shortage was, of course, a major thing for every electronics designer. And luckily, we got most of the more rare chips, the microcontrollers, the special stuff, the FPGA, from our sponsors. So a huge thanks to those people who made sure we actually got the parts. But yeah, we couldn't get everything. So we had to do some last minute changes. We switched to the amazing RP2040 processor by Raspberry Pi. So actually, the co-processor that does some board management things is actually very powerful. And I've heard some people working on a way to actually get more firmware into the flesh of the RP2040 so that you can do more than just co-processor work on it. Look forward to that. And I will now hand the microphone to Julian, who's going to tell you about the software challenges. Yes, thank you. There is a lot of software that had to be made to make this batch possible, of course, among which is graphics because I just wasn't satisfied with what we had. So, oh, you know, just casually rewrite the entire thing in a year. No big... So, there's a new graphics library, which is, I hope people find it cool and not confusing. I tried to make it not. The drivers for various bits of hardware were actually mostly rewritten as well, because there did exist drivers, but most of them were proprietary blob form, and we didn't like that very much. So, one of the drivers, I think it was the B&O sensor, was like only a few weeks before camp, actually, a fully working driver. And I was watching that, and I was going like, oh no, this sensor isn't going to be usable. The native apps which are running on the ESP32, I think actually turned out really great. Someone called SpriteTM made the pocket sprite little Game Boy sized thing, which had ESP32 multi-boot. And it didn't really look like it, but I don't know who that was. Someone here probably Renzo was like, ESP32 multi-boot. We need that. So, we got in contact with SpriteTM and adapted his code. There were some fixes, turned it into a component, so now anyone that wants to multi-boot on an ESP32 can import the AppFS component and just boot multiple firmwares from one ESP. There were also some software fixes to hardware problems happening, but those aren't too interesting. There was a software bug in ESPIDF v3, which is what the Shabaj used to run, which basically made SPI completely useless. Now, we haven't gone into detail about the design just yet, but the FPGA is connected to the ESP32 with SPI, which means that the only way to use it is if SPI actually works properly. And that meant porting all of MicroPython from ESPIDF v3 to ESPIDF v4. I still don't know how they managed to do it, but it worked out in the end. All right, so now you know how we got here, or at least the red line. How did we get here? And now it's the question, where do we go from here? Because, as I said before, you don't want your batch to be trash after the event. So, first of all, our web development team have already been working on a new version of the hatchery with an improved UI and improved architecture overall. And the goal, I mean, I'm not promising that this is what it's going to look like, but our goal is to make the hatchery an online IDE for your batch. So you plug in your batch, you can type your code in your browser, run it on your batch and upload to the hatchery all from the same environment. This would, of course, make it really easy to experiment, to try new things, and most of all, to just have fun and get an entry into this world of app development. Because if you don't need 10 different tools and you don't need to install all kinds of tool chains and programs to actually build stuff for your batch, you could just do it from your browser, which is enabled by web USB. Then, of course, more people are going to do it, which is what we want. And then the same goes for the FPGA. Carlos, who has been working like a madman for the last weeks to get his examples and native support for the batch in the software package iStudio, is still working on more examples, also with support for the display, to enable people to just drag and drop their logic and to explore what the potential of an FPGA actually is. Because this program allows you to drag and drop, but also to view the verilog that it produces and to edit that. So it's both compatible with total beginners and with more advanced users who know verilog and who want to expand the functionality of existing blocks or of their designs. And then there's also a human factor. Very important, because this is a project we all do for fun. It has turned out it's very important to set clear expectations. Because, well, we all do it for fun, but what you can do for fun, how far that drives you, that differs very much from person to person. And this has caused earlier projects, people burning out or not sleeping the nights before the event because stuff had to be done last minute or people rage quitting because things didn't go as smoothly as we would have wanted. And this project, again, wasn't perfect, but we think it's really important to stress that it's not only technical skills you need to function in a team like this because, of course, we want to build cool stuff, but we also want to have fun. We want to keep everybody happy and we want all team members to be able to enjoy the results and not be hindered by, well, things that weren't as they expected. Then, of course, with clear expectations also comes clear communication. I guess that's logical. Having a roomy planning, I can really advise this. This project ran from about February of 2020 until today. And it's still running. So we had two and a half years to develop this badge and still some things like the web development part had to happen last minute. So if you want to have a badge in three years, please start now. Because if you have a roomy planning, then there is space to reinvent, to really let everybody contribute. And if you want to cram everything into a year of work, then the scope of people who will be available to help with that level of dedication will be really limited, of course. And finally, keep the vibes positive. Because if people are having fun, they will go to great lengths to contribute. I mean, we had a couple of people swoop in at the last minute to help us with documentation and preparing workshops. We had a guy from Spain join us online because he wanted to add native support for our project to his software package. And it all happens because we are all enthusiastic about what we're doing. Because we have made something cool and we want to share it. And we want to help other people also, if possible, profit from that success. Because we are hoping to give iStudio a kick into, you know, a popularity by having it work with our badge. And also we want, it's a double-sided win-win situation. Then the Rense. Okay, well, fun. I can do this section. I didn't know that. We saw a lot of awesome stuff happening on the field. You saw people with extra big antennas. Of course, you need good Wi-Fi reception. We saw someone with a CO2 sensor, like a big external CO2 sensor connected to the PMOD connector of the FPGA. We just casually said, yeah, I made a bit stream that like converts from a UR to SPI. So I can read it on the ESP32. I'm like, okay, awesome. Great job there. People made a case for the badge. And that was a knob for the joystick. Really cool. Makes your badge look way more fancy. I highly recommend you search for this case and the joystick knob and everything on Thingiverse or wherever people publish things nowadays. You'll find it. And I also want to give a shout out to a really cool talk that we saw about fault injection. Look that one up if you weren't there. It's probably streamed online as well. They used our badge as a target for fault injection. And specifically, they got really cool results with the FPGA Mandelbrot app. So normally, you can like zoom in on very cool repeating patterns. And by applying electromagnetic pulses to the right places on the back of the badge, they actually got completely random structures out of it. So that's really cool. And the app still worked. So you could browse through these completely randomly generated things. Yeah. And I actually have no idea what GNU Taylor is. So, Renier? Yeah. So this is a project that was brought to our attention, I think, yesterday. Someone built support for GNU Taylor. I'm not sure how to pronounce payments, which are device to device payments over NFC. This is a, as far as I know, a payment system that allows people to pay anonymously, but not untraceably. And this could mean, I mean, I'm not doing and making any promises. But it could mean that in the future, we might see, for example, support for batch to batch payments via NFC, because this is an open source project. And of course, it would be fun if you could securely and safely give people money if you think their work is cool, or if you think their app is cool, without anything outside of your badge. We just thought that was a cool project. No guarantees. No guarantees. So this was our last slide. And before we go to the Q&A, I would just like to thank everybody who contributed to this batch. I am not going to list those names because I'm definitely going to forget people. But can everybody from Badge Team who is here please stand up? One, two, three, four, five, six, seven, eight, nine people standing here probably because of this. Wow. Yeah. And then please keep in mind that our Telegram group, our core development Telegram group is right now 29 people strong. So I know a couple of them are not at the event. They were external contributors. Some of them have COVID and can't attend this talk, unfortunately. And then, of course, there are also our sponsors who sponsored the FPGA, led the semiconductor, the sensors from Bosch, the production for which we partnered with on at China, and the ESP32 we got sponsored by Expressive once again. Thanks a lot. And now we have room for questions. Yes. Thank you first for giving us the talk and for working on this device so long and for giving it to us all to play around with. Yes, other questions. If you have questions, please go to the microphones. First question, please. Hello. So I've really enjoyed dinkering around with the batch. And I was wondering how did the process go from the Shell 2017 batch team to the current team? What kind of handover was there? How did the exchange of ideas go? Can you explain something about it? Thanks for the one question I hope we wouldn't get, but I want to give a shout out to Sebastian, who did an amazing job managing the team. And I really hope we're going to do a club mat or a beer together soon, but lots of things happened there. And well, some things we're not proud of, but the end result is here. Thanks. Yeah, this is exactly why we included the human factor into the presentation, because this team has had a lot of adventures. And for some people, it meant at some point, they didn't want to be here anymore in the team. And we want to improve on that. And we have had some changes in the team. And we are keeping looking forward, trying to improve our vibes, trying to improve the way we work together. Because as the complexity of these badges go up, the need for professionalism and also for keeping it all together and fun is growing. So yeah, it's kind of a separate adventure from the technical stuff. And it also means that the team is very fluid. So every event has its own team. Does anyone have like a bug zapper? But yeah, I think for this event, development went a lot more smoothly in terms of, well, HR compared to previous events. Thank you for this answer. Next question, please. Information for follow-up. At multi-boots, I hear something like application file system. Is that correct? So with AFS, I will find more information on it. If you look at our GitHub, there's a repository called ESP component app FS that contains everything you need, including a little instruction on how to apply the change to the boot loader in your project. And it should allow you to load files into a special file system that automatically aligns all the firmware's correctly. And you can then call a function to tell the boot loader to boot into that firmware. This was all written by Jeroen Sprite. Most people he will probably know. He made the pocket Sprite. We just made sure it works on the latest development environment. Thanks. Thank you. Next question, please. FPGAs were famously sort of closed environments until the Lattice chip got basically reverse engineered. As far as I know, Lattice has never sort of publicly even acknowledged the existence of this open tool chain. Do you have any experience with people from Lattice about what they think about the whole process? I don't know the details, but they seem to be a little bit divided even inside the company. And the batch is also fully compatible with their proprietary tools, which will probably result in more compact designs and faster routing or something. But we had a lot of fun with the open source stuff on this, because, well, we're hackers, right? And also, I'm not going to name names because I don't want these people to be flooded with requests. But we had some help getting Lattice to sponsor us for this batch by someone who already had good contact with them and was collaborating with them on multiple projects. So shout out to this amazing person. I'm sure you know who you are if you're hearing this. Next question, please. Hi. Do you have any plans to backport some features to the SHA batch? For example, the IPFS? Yes. We are looking to improve backwards compatibility with the SHA batch. For this event, we focused on getting everything to work in the first place. But yeah, we do have plans to make sure as many apps as possible from the SHA batch will also work on this batch. But of course, there's different peripherals, different display stack. So we can't guarantee everything will work, but we are doing our best. Thank you. Thank you. We have at least two more questions. Does that also mean that if I spent a lot of time in making the next killer batch app, there is a high probability that it also will work on the next batch? There is no way we can guarantee that. But when we asked Espressif, hey, Espressif, would you like to sponsor us? We couldn't even finish the sentence and they already sent over boxes of chips. I really hope they will sponsor us again if they do. And yes. Next question, please. Hi. I'm a bad person. I use Windows and closed software. So I can confirm that the lattice radiant works on the batch so you can use the closed tool set. Also as a bad person, I connected my batch to my Windows machine and I got a nice pop-up saying, oh, Microsoft Edge detected a batch. Here's where you can get the documentation. What was that? A lot of pain. Go for it. You didn't show the fancy HDMI stuff. I blame it on the guy who planned the preparation for this talk, which is me. We tried to just have a little fun at camp. We wanted to prepare the batch talk and show some slides from the batch. But hey, I mean, didn't this work? Yeah. Okay. So it's a good point he's mentioning. Using the FPGA, someone here, I think it was Sylvan, right, made a bit stream which allows us to duplicate the display on the batch to an HDMI output using a PMOD module. So we would have been able to show some slides from the batch on this screen. And of course, it's useful for demos for anything you would like to do with sharing your tinkering on the batch with other people. So if you would also like to do this, check out. It's definitely on GitHub. And maybe he also has some modules left through to buy? Nope. Okay. But you can get them online. Next question. I just want to thank Rense for regrowing me every morning. I started up by batch. Phenomenal achievement. Lots of, I'm very, very impressed by this. Just out of interest and it's okay if you don't want to tell me, but what's the cost price of one batch? Ballparking. With or without sponsored components? Oh, that's a good question. Let's say without, if I would want to make this just... I think without sponsored components, we would land at around 18 to 20 euros a piece. I think it's more like 20 years after sponsoring. You're holding a 50-year device in your hands here and it's just cost-price. There's a lot of really cool stuff on there. Okay. So I have 2,500 colleagues and I have budget. Can I contact you guys and build me a bunch of them? I think most of us are available for commercial things as well. That's all I need to know. Thank you very much. Any other question? Doesn't seem so. Well, this was a batch team. I think it was a very fascinating but also funny experience to have you here on stage. Thank you for being here. Thank you for building this and thank you for having me around.