With few exceptions, electronic event badges are often all but forgotten as soon as the attendee gets back home. They’re a fun novelty for the two or three days they’re expected to be worn, but after that, they end up getting tossed in a drawer (or worse.) As you might imagine, this can be a somewhat depressing thought thought for the folks who design and build these badges.
But thanks to a new firmware released by the FREE-WILi project, at least one badge is going to get a shot at having a second life. When loaded onto the RP2350-powered DEF CON 32 badge, the device is turned into a handy hardware hacking multi-tool. By navigating through a graphical interface, users will be able to control the badge’s GPIO pins, communicate over I2C, receive and transmit via infrared, and more. We’re particularly interested in the project’s claims that the combination of their firmware and the DC32 badge create an ideal platform for testing and debugging Simple Add-Ons (SAOs).
Don’t know what the FREE-WILi project is? Neither did we until today, which is actually kind of surprising now that we’re getting a good look at it. Basically, it’s a handheld gadget with a dozen programmable GPIO pins and a pair of CC1101 sub-GHz radios that’s designed to talk to…whatever you could possibly want to interface with.
It’s a bit like an even more capable Bus Pirate 5, which considering how many tricks that particular device can pull off, is saying something. As an added bonus, apparently you can even wear the FREE-WILi on your wrist for mobile hardware hacking action!
Anyway, while the hardware in the FREE-WILi is clearly more capable than what’s under the hood of the DC32 badge, there’s enough commonality between them that the developers were able to port a few of the key features over. It’s a clever idea — there’s something like 30,000 of these badges out there in the hands of nerds all over the world, and by installing this firmware, they’ll get a taste of what the project is capable of and potentially spring for the full kit.
If you give your DC32 badge the FREE-WILi treatment, be sure to let us know in the comments.
They are quite wrong on IR.
This is 100% nonsense. IR remote (aka CIR) is IR modulated with 38KHz. IrDA (SIR) is baseband IR. This is a SUPERSET of CIR – any valid CIR signal can be TXed or RXed by an IrDA SIR XCVR. A CIR RX will only RX if it detects the carrier. IrDA SIR RX will detect any pulse. So a little bit of software (a simple bandpass filter) will tease out the IR remote signal out of the noise trivially. I even prototyped this months ago using RP2350 PIO.
Could somebody explain what he just wrote?
Since he wrote the firmware for that defcon badge, I’d presume something smart. The free-wili people state on their site that IR receiving wouldn’t work with the integrated IR transceiver, but he says it’s doable with a software fix that filters for a certain frequency to make it readable.
Thanks!
I wouldn’t call it nonsense. They wrote that it’s not directly compatible, not that it’s not impossible.
I get your point, though. If anyone said “nRF24L01 is not directly compatible with BLE” or “Linux is not directly compatible with i4004” you could respond with “this is 100% nonsense” too ;-)
Except here it takes a grand total of 20 lines of code… that is like saying “arduino is incompatible with making a led blink” cause you were too lazy to write the three lines of code.
This does not appear to be open source in any way whatsoever. I can find no sources. Github only has a binary. Probably not Hack-a-day material thus?
While we strongly prefer covering open source projects, it has never been a requirement to be featured on Hackaday.
i just don’t understand the word ‘ideal’ applied to the RP2350 GPIO. it’s true a lot of things don’t mind driving a little current on their digital outputs, but it’s absolutely not “ideal” for general purpose I/O. configurable inputs with a high-impedance mode is kind of the sine qua non of embedded GPIO and the rp2350 simply doesn’t have it.
i’m really dismayed by the hackaday habit of talking about raspberry products’ specific weak points without mentioning the flaws. we constantly see raspberry pi powered by batteries, and now rp2350 as “ideal” GPIO. these things are all wonderful and useful but they have weaknesses and they shouldn’t be hidden, especially when you’re talking specifically about their weakest points.
and i’m flabbergasted by raspberry’s decision to sell the RP2350 with the disclaimer buried at the end of the manual. it’s still very usable but first rule of usefulness is disclosure of what use cases it wouldn’t be appropriate for. they’re earning a reputation as deceptive, which frankly they don’t need. i’m not just miffed at them for being awful, i’m miffed at them for sabotaging their brand…i love the rp2040 and i don’t want them to destroy themselves and waste the effort i spend learning it. i’m rooting for them, but that means they have to be honest.
Are you are referring to the GPIO RP2350-E9 erratum, by calling it a ‘disclaimer buried at the end of the manual’ ? Errata are always at the end of the datasheet, and it’s a rite of passage for embedded engineers to get the latest version of the datasheet and root around in the end section. EEVblog has a nice discussion of horrible errata, like a USB chip which did not have a working USB.
yeah. raspberry’s datasheet is already pretty unusual. intentionally so. they’re overtly trying to make it more welcoming and more practical and less bewildering and frustrating. they definitely should not be trying out for a starring spot in the museum of horrible errata
Would be interesting to see how they worked with that errata in their firmware, but sadly it’s closed source. The RP2350 isn’t rendered unusable though – it seems to work great for the badge.
I can tell you that in the stock firmware I worked with the erratum thusly: I did nothing. It doesn’t happen in all the uses of pins in the stock badge. It reads as bad but in normal everyday use it is totally not an issue in my experience.
i don’t know about ‘everyday use’ but it definitely works in a lot of situations. but a General Purpose IO, an ideal tool for debugging and development, should do better than just “works if you’re lucky” imo. it should work in situations where extra current draw will be noticed too. that’s why it’s so essential to disclose it, so people can know if their situation is one of the ones where it matters.
i happen to use an STM32 all day long in a situation where that would matter (a bespoke dallas one-wire interface where the extra current draw would alter the RC curves that define its timing). and i’m thinking about transitioning that to an RP2040. if i didn’t know about the errata, and transitioned it to an RP2350, it would be a nightmare to figure out. i would still be able to work around it with an extra transistor or buffer but i would have a long time scratching my head!
the worst thing is, it might ‘just work’, but not as reliably. instead of being smack in the middle of the timing spec, i would be at one edge of it. i would have a new class of glitch that would frustrate me and i might never get to the bottom of it. conducting in high-impedance input mode is a !@$# disaster if you’re not expecting it.