In the iconic 1990s TV series The X Files, David Duchovny’s FBI agent-paranormal investigator Fox Mulder has a poster on his office wall. It shows a flying saucer in flight, with the slogan “I Want To Believe”. It perfectly sums up the dilemma the character faces. And while I’m guessing that only a few Hackaday readers have gone down the full lizard-people rabbit hole, wanting to believe is probably something that a lot of us who love sci-fi understand. It would be a fascinating event for science if a real extraterrestrial craft would show up, so of course we want to believe to some extent, even if we’re not seriously expecting it to appear in a Midwestern cornfield and break out the probes any time soon.

By All Means Believe. But Don’t Wreck Your Career

Outside the realm of TV drama and science fiction it’s a sentiment that also applies in more credible situations. Back at the end of the 1980s for example when so-called cold fusion became a global story it seemed as though we might be on the verge of the Holy Grail of clean energy breakthroughs. Sadly we never got our Mr. Fusion to power our DeLorean, and the scientific proof was revealed to be on very weak foundations. The careers of the two researchers involved were irreparably damaged, and the entire field became a byword for junk science. A more recently story in a similar vein is the EM drive, a theoretical reactionless force generator that was promising enough at one point that even NASA performed some research on it. Sadly there were no magic engines forthcoming, so while it was worth reporting on the initial excitement, we’re guessing the story won’t come back.

When evaluating a scientific or technical breakthrough that seems as miraculous as it is unexpected then, of course we all want to believe. We evaluate based on the information we have in front of us though, and we all have a credibility pyramid. There’s nothing wrong with having an interest in fields that are more hope than delivery, indeed almost every technology that powers our world will at some time have to overcome skepticism in its gestation period. Perhaps it’s best to say that it’s okay to have hope, but hope shouldn’t override our scrutiny of the proof. Of course I want a perpetual motion machine, who wouldn’t, but as a fictional engineer once allegedly said, “Ye cannae change the laws of physics”.

An Example Here In 2024

All this introspection has been brought to the fore for me by something very much in the present, the so-called hydrogen economy. It’s difficult to ignore our climate emergency, and among the energy solutions aimed at doing something about it, hydrogen seems very promising.

It’s really easy to make from water by electrolysis, there are several ways to turn it into useful energy, and the idea is that if you can store it for later use you’re on to a winner. We’ve seen hydrogen cars, trucks, aircraft, heavy machinery, trains, and even the gas supplanting methane in the domestic grid, so surely the hydrogen future is well under way, right?

Sadly not, because as many a pilot project has shown, it’s difficult to store or transport, it makes many existing metal fittings brittle, and the environmental benefit is often negated by the hydrogen being generated from higher carbon electrical supplies. We still want to believe, but we can’t claim it’s delivering yet.

Whenever we feature a hydrogen-based story, as for example with this experimental storage tech from Swiss researchers, there is no shortage of comments about all of hydrogen’s shortcomings, and some even accuse us of somehow being the snake-oil salesmen shilling the questionable product. I feel this misses the point, that even though in almost all cases the battery is for now the better option, we cover interesting technology stories regardless of judgements over their eventual success. Hydrogen has enough real science and engineering behind it that its problems might one day be overcome, thus we’d be doing our readers a disservice if we didn’t cover it. There are sometimes newsworthy stories upon which we very much take a credible stand based on opinion, but when it comes to pure tech stories such as a hydrogen vehicle we’re simply reporting on the story because we find it interesting and we think you will too. We don’t know that the breakthrough engineering work won’t occur, but we do know that it hasn’t yet.

So when looking at a piece of technology that’s not delivered on its promise, ask for a moment whether there’s a likely “yet” on the end of the sentence without too much of a suspension of credibility. You might find yourself pleasantly surprised.

This year we challenged the Hackaday community to develop Shitty Simple Supercon Add-Ons (SAO) that did more than just blink a few LEDs. The SAO standard includes I2C data and a pair of GPIO pins, but historically, they’ve very rarely been used. We knew the talented folks in this community would be able to raise the bar, but as they have a tendency to do, they’ve exceeded all of our expectations.

As we announced live during the closing ceremony at the 2024 Hackaday Supercon, the following four SAOs will be put into production and distributed to all the attendees at Hackaday Europe in Spring of 2025.

Best Overall: SAO Multimeter

For the “Best Overall” category, we only intended to compare it with the other entries in the contest. But in the end, we think there’s a strong case to be made that [Thomas Flummer] has created the greatest SAO of all time. So far, anyway.

This add-on is a fully functional digital multimeter, with functions for measuring voltage, resistance, and continuity. The design is a pure work of art, with its structure combining stacked PCBs and 3D printed parts. There’s even tiny banana plugs to connect up properly scaled probes. Incredible.

In the documentation [Thomas] mentions there are additional functions he didn’t have time to include in the firmware, such as modes to analyze the I2C and GPIO signals being received. Now that it’s been selected for production, we’re hoping he’ll have the time to get the code finished up before its European debut.

Fun: Etch sAo Sketch

This SAO recreates the iconic art toy in a (hopefully) non-trademarked way, with a 1.5″ inch 128 x 128 grayscale OLED display and a pair of trimpots capped with 3D printed knobs. Drawing is fun enough, but the nostalgia really kicks in when you give it a good shake — the onboard LIS3DH 3-axis accelerometer picks up the motion and wipes the display just like the real thing.

Created by [Andy Geppert], this SAO isn’t just a pretty face. Flipping it over shows an exceptionally clever technique for connecting the display board to the main PCB. Tiny metal balls (or “alignment spheres” if you want to get fancy) mate up with the mounting holes on the OLED board and center it, and a touch of solder locks it all in place.

Fine Art: Bendy SAO

While this wacky, waving, inflatable, arm-flailing SAO might look like the sort of thing that would be outside of a used car dealership, but creator [debraansell] managed to shrink it down so the point that it’s reasonable to plug into your badge. More or less.

There are several fascinating tricks at work here, from lighting the PCB from the back using side-firing LEDs to the integrated slip rings. If this one didn’t look so good, it would have been a strong contender for the “Least Manufacturable” Honorable Mention.

Functional: Vectrex SAO

Creating a replica of the Vectrex at SAO scale would have been an impressive enough accomplishment, but [Brett Walach] took this one all the way and made it playable.

The display is a 7 x 10 Charlieplexed LED matrix, while the “joystick” is implemented with a 1-button capacitive touch sensor. A PIC16F886 microcontroller runs the simplified version of Scramble, and there’s even a speaker for era-appropriate audio.

But that’s not all! This SAO was also designed to be hacked — so not only is all the hardware and software open source, but there’re various jumpers to fiddle with various settings and an I2C control protocol that lets you command the action from the badge.

Honorable Mentions

As usual, this contest had several Honorable Mentions categories — while we would have loved to put all of these SAOs into production, there’s only so much we can do before now and Spring.

[Jeremy Geppert]’s SAO LoRa Walkie Talkie was a judge favorite, for its simple good looks and the extra functionality that it brings to the table. [Scorch Works]’s SAO Infinity Mirror was absolutely beautiful to see in person, and makes a fantastic display when many of them get together. And [MakeItHackin]’s Skull of Fate SAO not only looked super when its eyes scan the room, but it could read your future as well!

Best Communication:

Using I2C to get SAOs to talk to the badge (or each other) was a big part of this contest, but we were also on the lookout for entries which helped facilitate badge-to-badge communications.

The Badge Tag NFC SAO from [Thomas Flummer] is a perfect example of both — it uses the NXP NTAG I2C Plus to provide 2K of read-write storage that can be accessed either internally through the I2C bus by the badge, or externally by an NFC device such as a smartphone. Modeled after a traditional conference name tag, this SAO was designed to make it easier for sharing your contact info with others during a busy con.

Infrared Communication SAO by [Alec Probst] brings infrared communications to the party, while looking like a classic TV remote. Though the original idea was to get this working in conjunction with the badge to act as a sort of TV-B-Gone, it ended up being used as part of a laser tag game during Supercon.

The GAT Nametag SC8 from [true] tackles communication on a more human level by providing a digital name tag for your badge. This compact board’s secret trick is the ability to make sure your name is legible no matter what its orientation thanks to a LIS2DW12 accelerometer that can detect the SAO’s orientation relative to the ground. RGB LEDs catch the viewer’s eye, but it’s the incredible firmware with seemingly endless options for text styling and tweaks that really set this build apart.

Light Show:

There’s little question that Featuring You! from [Nanik Adnani] is a perfect entry for this category. Nominally, it’s a little arrow you can write your name on and use a name tag. But power it up and you can dazzle anyone standing too close with its array of marching white LEDs. In a particularly nice touch, the circuit is implemented with only discreet components — no microcontroller.

The reDOT_RGB from [Alex] is a tiny 5×7 RGB LED matrix with a minuscule ATtiny816 MCU around the back to control the show. At just 8 x 11 mm, it’s hard to overstate just how tiny this SAO is.

While on the subject of tiny boards, the
Persistence of Vision POV Display is another entry not much larger than the SAO connector itself. Using a row of five tiny white LEDs and a ADXL345 accelerometer, [Michael Yim] is able to write text in mid-air thanks to the gullibility of the human eye.

Least Manufacturable:

Simple Add-Ons are essentially an art form, so it’s not surprising to find that they don’t often lend themselves to mass production. Several of the entries this yeah would be a real challenge to make in large numbers, but the one that really keeps us up at night is the ultra tiny smart SAO from [Alex].

This board is designed to fit inside the space between four header pins. Thanks, but no thanks.

Raising the Bar

Our hope this year was to elevate the Simple Add-On from a decorative piece of flair to something functional, and potentially, even useful. The results were incredible, and while we can only pick four winners this time around, every entry helped push the state-of-the-art forward in its own way. It’s hard to imagine how the SAO envelope can be pushed any further, but we can’t wait to find out.

Probably not too many people around the world celebrated November 1st, 2023, but on this momentous date FreeBSD celebrated its 30th birthday. As the first original fork of the first complete and open source Unix operating system (386BSD) it continues the legacy that the Berkeley Software Distribution (BSD) began in 1978 until its final release in 1995. The related NetBSD project saw its beginnings somewhat later after this as well, also forking from 386BSD. NetBSD saw its first release a few months before FreeBSD’s initial release, but has always followed a different path towards maximum portability unlike the more generic nature of FreeBSD which – per the FAQ – seeks to specialize on a limited number of platforms, while providing the widest range of features on these platforms.

This means that FreeBSD is equally suitable for servers and workstations as for desktops and embedded applications, but each platform gets its own support tier level, with the upcoming version 15.x release only providing first tier support for x86_64 and AArch64 (ARMv8). That said, if you happen to be a billion-dollar company like Sony, you are more than welcome to provide your own FreeBSD support. Sony’s Playstation 3, Playstation 4 and Playstation 5 game consoles namely all run FreeBSD, along with a range of popular networking and NAS platforms from other big names. Clearly, it’s hard to argue with FreeBSD’s popularity.

Despite this, you rarely hear people mention that they are running FreeBSD, unlike Linux, so one might wonder whether there is anything keeping FreeBSD from stretching its digital legs on people’s daily driver desktop systems?

In The Beginning There Was UNIX

Once immortalized on the silver screen with the enthusiastically spoken words “It’s a UNIX system. I know this.”, the Unix operating system (trademarked as UNIX) originated at Bell Labs where it initially was only intended for internal use to make writing and running code for systems like the PDP-11 easier. Widespread external use started with Version 6, but even before that it was the starting point for what came to be known as the Unix-based OSes:

After FreeBSD and NetBSD forked off the 386BSD codebase, both would spawn a few more forks, most notable being OpenBSD which was forked off NetBSD by Theo de Raadt when he was (controversially) removed from the project. From FreeBSD forked the Dragonfly BSD project, while FreeBSD is mostly used directly for specific applications, such as GhostBSD providing a pleasant desktop experience with preconfigured desktop and similar amenities, and pfSense for firewall and router applications. Apple’s Darwin that underlies OS X and later contains a significant amount of FreeBSD code as well.

Overall, FreeBSD is the most commonly used of these OSS BSDs and also the one you’re most likely to think of when considering using a BSD, other than OS X/MacOS, on a desktop system.

Why FreeBSD Isn’t Linux

The Linux kernel is described as ‘Unix-like’, as much like Minix it does not directly derive from any Unix or BSD but does provide some level of compatibility. A Unix OS meanwhile is the entirety of the tools and applications (‘userland’) that accompany it, something which is provided for Linux-based distributions most commonly from the GNU (‘GNU is Not Unix’) project, ergo these Linux distributions are referred to as GNU/Linux-based to denote their use of the Linux kernel and a GNU userland. There is also a version of Debian which uses GNU userland and the FreeBSD kernel, called Debian GNU/kFreeBSD, alongside a (also Unix-like) Hurd kernel-based flavor of Debian (Debian GNU/Hurd).

In terms of overall identity it’s thus much more appropriate to refer to ‘Linux kernel’ and ‘GNU userland’ features in the context of GNU/Linux, which contrasts with the BSD userland that one finds in the BSDs, including modern-day MacOS. It is this identity of kernel- and userland that most strongly distinguishes these various operating systems and individual distributions.

These differences result in a number of distinguishing features, such as the kernel-level FreeBSD jail feature that can virtualize a single system into multiple independent ones with very little overhead. This is significantly more secure than a filesystem-level chroot jail, which was what Unix originally came with. For other types of virtualization, FreeBSD offers bhyve, which can be contrasted with the kernel-based virtualization machine (KVM) in the Linux kernel. Both of these are hypervisor/virtual machine managers that can run a variety of guest OSes. As demonstrated in a comparison by Jim Salter, between bhyve and KVM there is significant performance difference, with bhyve/NVMe on FreeBSD 13.1 outperforming KVM/VirtIO on Ubuntu 22.04 LTS by a large margin.

What this demonstrates is why FreeBSD for storage and server solutions is such a popular choice, and likely why Sony picked FreeBSD for its customized Playstation operating systems, as these gaming consoles rely heavily on virtualization, as with e.g. the PS5 hypervisor.

OpenZFS And NAS Things

A really popular application of FreeBSD is in Network-Attached Storage (NAS), with originally FreeNAS (now TrueNAS) running the roost here, with iXsystems providing both development and commercial support. Here we saw some recent backlash, as iXsystems announced that they will be adding a GNU/Linux-based solution (TrueNAS SCALE), while the FreeBSD-based version (TrueNAS CORE) will remain stuck on FreeBSD version 13. Here The Register confirmed with iXsystems that this effectively would end TrueNAS on FreeBSD. Which wouldn’t be so bad if performance on Linux wasn’t noticeably worse as covered earlier, and if OpenZFS on Linux wasn’t so problematic.

Unlike with FreeBSD where the ZFS filesystem is an integral part of the kernel, ZFS on Linux is more of an afterthought, with a range of different implementations that each have their own issues, impacting performance and stability. This means that TrueNAS on Linux will be less stable, slower and also use more RAM. Fortunately, as befits an open source ecosystem, an alternative exists in the form of XigmaNAS which was forked from FreeNAS and follows current FreeBSD fairly closely.

 

So what is the big deal with ZFS? Originally developed by Sun for the Solaris OS, it was released under the open source CDDL license and is the default filesystem for FreeBSD. Unlike most other filesystems, it is both the filesystem and volume manager, which is why it natively handles features such as RAID, snapshots and replication. This also provides it with the ‘self-healing’ ability where some degree of data corruption is detected and corrected, without the need for dedicated RAID controllers or ECC RAM.

For anyone who has had grief with any of the Ext*, Reiserfs or other filesystems (journaled or not) on Linux, this probably sounds pretty good, and its tight integration into FreeBSD again explains why it’s it’s such a popular choice for situations where data integrity, performance and stability are essential.

FreeBSD As A Desktop

It’s probably little surprise that FreeBSD-as-a-desktop is almost boringly similar to GNU/Linux-as-a-desktop, running the Xorg server and one’s desktop environment (DE) of choice. Which also means that it can be frustratingly broken, as I found out while trying to follow the instructions in the FreeBSD handbook for setting up Xfce. This worked about as well as my various attempts over the years to get to a working startx on Debian and Arch. Fortunately trying out another guide on the FreeBSD Foundation site quickly got me on the right path. This is where using GhostBSD (using the Mate DE by default) is a timesaver if you want to use a GUI with your FreeBSD but would like to skip the ‘deciphering startx error messages’ part.

After installation of FreeBSD (with Xfce) or GhostBSD, it’s pretty much your typical desktop experience. You got effectively the same software as on a GNU/Linux distro, with FreeBSD even providing binary (user-space) compatibility with Linux and with official GPU driver support from e.g. NVidia (for x86_64). If you intend to stick to the desktop experience, it’s probably quite unremarkable from here onwards, minus the use of the FreeBSD pkg (and source code ports) package manager instead of apt, pacman, etc.

Doing Some Software Porting

One of my standard ways to test out an operating system is to try and making some of my personal open source projects run on it, particularly NymphCast as it takes me pretty deep through the bowels of the OS and its package management system. Since NymphCast already runs on Linux, this should be a snap, one would think. As it turns out, this was mostly correct. From having had a play with this on FreeBSD a few years ago I was already aware of a few gotchas, such as the difference between GNU make and BSD make, with the former being available as the gmake package and command.

Another thing you may want to do is set up sudo (also a package) as this is not installed by default. After this it took me a few seconds to nail down the names of the dependencies to install via the FreeBSD Ports site, which I added to the NymphCast dependencies shell script. After this I was almost home-free, except for some details.

These details being that on GhostBSD you need to install the GhostBSD*-dev packages to do any development work, and after some consulting with the fine folks over at the #freebsd channel on Libera IRC I concluded that using Clang (the system default) to compile everything instead of GCC would resolve the quaint linker errors, as both apparently link against different c++ libraries (clang/libc++ vs gcc/libstdc++).

This did indeed resolve the last issues, and I had the latest nightly of NymphCast running on FreeBSD 14.1-RELEASE, playing back some videos streaming from Windows & Android systems. Not that this was shocking, as the current stable version is already up on Ports, but that package’s maintainer had make similar tweaks (gmake and use of clang++) as I did, so this should make their work easier for next time.

FreeBSD Is Here To Stay

I’ll be the first to admit that none of the BSDs really were much of a blip on my radar for much of the time that I was spending time with various OSes. Of course, I got lured into GNU/Linux with the vapid declarations of the ‘Year of the Linux Desktop’ back in the late 90s, but FreeBSD seems to always have been ‘that thing for servers’. It might have been just my fascination with porting projects like NymphCast to other platforms that got me started with FreeBSD a few years ago, but the more you look into what it can do and its differences with other OSes, the more you begin to appreciate how it’s a whole, well-rounded package.

At one point in time I made the terrible mistake of reading the ‘Linux From Scratch’ guide, which just reinforced how harrowingly pieced together Linux distributions are. Compared to the singular code bases of the BSDs, it’s almost a miracle that Linux distributions work as well as they do. Another nice thing about FreeBSD is the project structure, with no ‘Czar for life’, but rather a democratically elected core leadership. In the 30-year anniversary reflection article (PDF) in FreeBSD Journal the way this system was created is described. One could say that this creates a merit-based system that rewards even newcomers to the project. As a possible disadvantage, however, it does not create nearly the same clickbait-worthy headlines as another Linus Torvalds rant.

With widespread industry usage of FreeBSD and a strong hobbyist/enthusiast core, it seems fair to say that FreeBSD’s future looks brighter than ever. With FreeBSD available for easy installation on a range of SBCs and running well in a virtual machine, it’s definitely worth it to give it a try.

The software and hardware worlds have overlaps, and it’s worth looking over the fence to see if there’s anything you missed. You might’ve already noticed that we hackers use PCB modules and devboards in the same way that programmers might use libraries and frameworks. You’ll find way more parallels if you think about it.

Building blocks are about belonging to a community, being able to draw from it. Sometimes it’s a community of one, but you might just find that building blocks help you reach other people easily, touching upon common elements between projects that both you and some other hacker might be planning out. With every building block, you make your or someone else’s next project quicker, and maybe you make it possible.

Sometimes, however, building blocks are about being lazy.

Just Throw Pin Headers

Back when I was giving design review on a LVDS driver board for a Sony Vaio display, there was a snag – the display used, doesn’t generate its own backlight voltage, so you have to bring your own backlight driver. Well, I didn’t want to bother designing the backlight driver portion of the circuit.

The way I justified it, adding that circuit to the board didn’t make much sense – the entire board was an experimental circuit, and adding one more experiment onto it would result in extra board revisions and reassemblies. Honestly, though, I just really didn’t want to design the LED driver circuit at the time – it didn’t feel as interesting.

So, I had an easy-to-follow proposal – let’s put all backlight-driver-related signals onto three pin headers, forming a “module” footprint of sorts, and then develop the module separately! The hacker agreed, and in the meantime, used a spare panel’s LED backlight to test the display in the meantime – way more accessible of a solution. The pin headers remained, at the time, bound to be unpopulated for, at least, until the next PCB order.

New revisions of the module came and went, now bearing a HDMI port and a whole new ASIC – easy to design, because, again, the hacker didn’t have to worry about the backlight circuit, and just kept the module footprint from the previous design. Was the backlight driver module PCB designed yet? Well, simply put, no.

A friend of mine, just a month later, was designing a motherboard replacement for a tablet computer, and she asked me for advice on how to power the backlight. I thought for a second, and, I had an easy answer for her – use the module footprint. At that point, I still haven’t designed the module, but I didn’t have to mention that. She rejoiced, put the module footprint onto the board, even designed her own neat symbol for it, and then promptly went on to lay out diffpairs and reverse-engineer pinouts, both significantly more fun activities than designing a backlight driver with zero experience in design of backlight drivers.

Some time later, I started getting insistent messages from the original hacker, about needing a backlight driver. The funny part is that by that point, I have already had designed a backlight driver circuit for my own Vaio motherboard, but I never felt engaged enough to turn it into a module. A different friend of mine was looking for small projects, however. I gave her the task: here’s a footprint for a module, here’s a circuit that goes onto the module, and we need a module. Indeed, she has delivered a module – by that point, a module we could put onto three different PCBs.

Building Blocks

The entire occasion definitely helped cement my reputation as someone who delivers, eventually – with big emphasis on eventually. It also brought four people and three projects together, and it let us order the first revision PCB way sooner than otherwise, all because we set out to eventually add the backlight circuit as a module. Now, this module is a building block in our projects – whenever one of us, or maybe one of you, needs a backlight driver, we know that we have an option handy.

I have some unique experiences with PCB modules as building blocks – at one point, I’ve built an entire phone out of them, and I still build devices heavily based on modules. Whenever I’d have the occasion, I’d throw a TP4056 module footprint onto a board instead of reimplementing the whole circuit from scratch. In 2022, I designed a module with a RP2040 and the FUSB302 USB-PD PHY – it was the building block that led to my USB-C series on Hackaday, and eventually helped me, my friends, and other hackers develop a whole lineup of unique USB-C devices.

Building block use and design is the fun way, and it’s the lazy way, and it’s the friendly way – would you believe me if I told you it’s also the safe way? Say, does your circuit need a custom DC-DC, or can you slap a few pads onto the board to connect a commonplace generic module? If you can afford the increased space, might as well make your board as simple as it goes – if there’s less to test and bringup, you’ll get to your project’s finish line earlier, and have less hurdles to jump over.

The Practical Aspects

There are a few techniques you can use if you want to make a building block – pin headers are the simple obvious one. Castellations is a fun one, and here’s a trick – you don’t have to pay JLCPCB for castellated holes, as long as you are fine getting dirty ones, which are still wonderful for prototyping. If you’re using Aisler, you can get perfect castellated holes, though – good for scaling up a module of yours after you’ve verified the design. Don’t be scared of turning through-holes into castellations – it works, and it’s super easy if your board is thin enough. Oh, and you might just be able to get castellations through V-Cuts!

Got an Eastern or Western module, and it doesn’t quite use pin headers? Get out the calipers, measure its pads, and create a footprint for it – you will thank yourself later. I’ve done just once for a 5 V boost module, stocking up on them and putting them onto a bunch of boards. It’s not like I’d feel comfortable designing 5 V boost regulators at the time, so the module has bought me a couple years of worrying about something else instead. The modules have since vanished from the market, but, today I’ve got a few 5 V boost designs I can easily make modules out of. Now, it looks like I can even upgrade my own old boards that are still in use!

When designing your own boards, try to put all pin headers on a grid, 2.54 mm (0.1in) is a must – only use an integer millimeter grid or pin headers if you have no other options. Such a module isn’t just solderable – it’s breadboardable, which helps a ton when you’re trying to figure out an especially daring circuit technique. Castellated modules can be breadboardable, too, if you make sure to concentrate the core necessary signals on two opposite sides!

Are you designing a new module for your own use? See if there’s a footprint you can copy, or an unspoken standard you can follow. Boards speak about themselves through their looks, and footprints convey a purpose through their layout. Look at the boards above- it’s pretty easy to notice that they are TP4056 style battery chargers, but all of them upgraded in their own way. If you follow an existing footprint when designing your own board, it’s going to look more familiar for a newcomer hacker, channeling the power of skeuomorphism where you might not have expected to find it.

The Looks Make The Module

Board formats are underrated when it comes to accidentally creating building blocks. Sparkfun has example layouts for QWIIC devices – follow it, plop a JST-SH connector on, maybe order your PCB in red for a change, and your sensor PCB will shine in a whole new way in your eyes. Dangerous Prototypes, on the other hand, suggests a set of PCB formats known as Sick of Beige that work with existing enclosures and lasercut templates – that’s the surface-level benefit, the real deal is that these footprints also talk the Dangerous Prototypes language. If your programmer board feels like a generic rectangle, putting it into the frame of BusPirate fame will give it the air of hacker-oriented tooling. With both of these formats, you get mounting holes – mark of a hacker who knows what’s good.

Interconnect standards go hand in hand with making your building blocks’ features recognizable without reading the silkscreen – it’s why I talk so much about QWIIC, and a JST-SH connector is always a welcome addition on my boards. Adding a well-recognized standard connector makes your board recognizable as a potential building block. Now, the board looks interoperable if you just give it a chance, equipped with a familiar socket, and perhaps, you won’t feel as much need for designing a new one – quite likely, building a new device in a single day instead of two weeks’ time.

Sometimes, your board will be split apart into building blocks without your involvement whatsoever. Publishing a design that goes beyond connecting a button to an LED? Try to fill in the blanks – it’s about helping the hacker that follows in your footsteps. Sometimes it’s a highschool kid trying to put together a design, and sometimes it’ll be you again, just a couple years later. So, note down the part number of that switcher inductor in the schematic, and fill in the values of the resistor divider while you’re at it – and if you’re revisiting a board of yours where you haven’t done that, do it, then git commit and git push.

Beyond The Ordinary

There’s building blocks everywhere for those with the eyes to see. A single-board computer is one, I’d argue – a SoM in a DDR footprint is one without a doubt. An engineer once showed me a technique for creating building blocks out of thin air – taking unpopulated leftover large project PCBs, then sawing out the section with the circuit you need. Sometimes, you really only need a single piece of that one Ethernet transceiver circuit, and you need it now – you might have not planned for it, but the Dremel tool forgives all.

Circuit blocks are an often requested feature in KiCad. At the moment, you can copy-paste portions of a schematic between projects – which is more than good enough for many circuits. It’s not as great for switching regulators or MCUs, however, and we can’t help but hope to see new advancements in the field soon. Perhaps, one day, you’ll be able to click a few buttons and turn your favourite USB hub into a circuit block – and from there, who knows, maybe you can fill the void that the NanoHub’s eternal out-of-stock state has left in our hearts!

The Domain Name System (DNS) is a major functional component of the modern Internet. We rely on it for just about everything! It’s responsible for translating human-friendly domain names into numerical IP addresses that get traffic where it needs to go. At the heart of the system are the top-level domains (TLDs)—these sit atop the whole domain name hierarchy.

You might think these TLDs are largely immutable—rock solid objects that seldom change. That’s mostly true, but the problem is that these TLDs are sometimes linked to real-world concepts that are changeable. Like the political status of various countries! Then, things get altogether more complex. The .io top level domain is the latest example of that.

A Brief History

Before we get into the current drama, we should explain some background around top level domains. Basically, as the Internet started to grow out of its early nascent form, there was a need to implement a proper structured naming system for online entities. In the mid-1980s, the Internet Assigned Numbers Authority (IANA) introduced a set of original top level domains to categorize domain names. These were divided into two main types—generic top-level domains, and country code top-level domains. The generic TLDs are the ones we all know and love—.com, .org, .net, .edu, .gov, and .mil. The country codes, though, were more complex.

Initially, the country codes were based around the ISO 3166-1 alpha-2 standard—two letter codes to represent all necessary countries. These were, by and large, straightforward—the United Kingdom got .uk, Germany got .de, the United States got .us, and Japan got .jp.

Eventually, management of TLDs was passed from IANA to a new organization called ICANN—Internet Corporation for Assigned Names and Numbers. Over time, ICANN has seen fit to add more TLDs to the official list. That’s why today, you can register a domain with a .biz, .info, or .name registration. Or .horse, .Dad, .Foo, or so many others besides. 

 

What’s With .io?

Over the past 20 years or so, the .io domain has become particularly popular with the tech set—the initialism recalls the idea of input/output. Thus, you have websites like Github.io or Hackaday.io using a country-code TLD for vanity purposes. It’s pretty popular in the tech world.

This was never supposed to be the case, however. The domain was originally designated for the British Indian Ocean Territory, all the way back in 1997. This is a small overseas territory of the United Kingdom, which occupies a collection of islands of the Chagos Archipelago. Total landmass of the territory is just 60 square kilometers. The largest island is Diego Garcia, which plays host to a military facility belonging to the UK and the United States. Prior to their removal by British authorities in 1968, the island played host to a population of locals known as Chagossians.

The territory has been the subject of some controversy, often concerning the Chagossians and their wish to return to the land. More recently, the Mauritian government has made demands for the British government to relinquish the islands. The East African nation considers that the islands should have been handed back when Mauritius gained independence in 1968.

Recent negotiations have brought the matter to a head. On October 3, the British and Mauritius governments came to an agreement that the UK would cede sovereignty over the islands, and that they would hence become part of Mauritius. The British Indian Ocean Territory would functionally cease to exist, though the UK would maintain a 99-year lease over Diego Garcia and continue to maintain the military facility there.

The key problem? With the British Indian Ocean Territory no longer in existence, it would thus no longer be eligible for a country-code TLD. According to IANA, ccTLDs are based on the ISO 3166-1 standard. When a country ceases to exist, it is removed from the standard, and thus, the ccTLD is supposed to be retired in turn. IANA states protocol is to notify the manager of the ccTLD and remove it after five years by default. Managers can ask for an extension, limited to another five years for a total of ten years maximum. Alternatively, a ccTLD manager may allow the domain to be retired early at their own discretion.

However, as per The Register, the situation is more complex. The outlet spoke to ICANN, which is the organization actually in charge of declaring valid TLDs. A spokesperson provided the following comment:

ICANN relies on the ISO 3166-1 standard to make determinations on what is an eligible country-code top-level domain. Currently, the standard lists the British Indian Ocean Territory as ‘IO’. Assuming the standard changes to reflect this recent development, there are multiple potential outcomes depending on the nature of the change.

One such change may involve ensuring there is an operational nexus with Mauritius to meet certain policy requirements. Should ‘IO’ no longer be retained as a coding for this territory, it would trigger a 5-year retirement process described at [the IANA website], during which time registrants may need to migrate to a successor code or an alternate location.

We cannot comment on what the ISO 3166 Maintenance Agency may or may not do in response to this development. It is worth noting that the ISO 3166-1 standard is not just used for domain names, but many other applications. The need to modify or retain the ‘IO’ encoding may be informed by needs associated with those other purposes, such as for Customs, passports, and banking applications.

Basically, ICANN passed the buck, putting the problem at the feet of the International Standards Organization which maintains ISO 3166-1. If the ISO standard maintains the IO designation for some reason, it appears that ICANN would probably follow suit. If ISO drops it for some reason, it could be retired as a ccTLD.

The Register notes that the .io record in ISO 3166-1 has not changed since a minor update in 2018. Any modification by ISO would be unlikely before the treaty between the UK and Mauritius is ratified in 2025. At that point, the five year clock could start ticking.

However, history is a great educator in this regard. There’s another grand example of a country that functionally ceased to exist. In 1991, the Soviet Union was no longer a going concern. And yet, the .su designation remains “exceptionally reserved” in the ISO 3166-1 standard at the request of the Foundation for Internet Development. However, the entry notes it was “removed from ISO 3166-1 in 1992” when the USSR broke up into its constituent states. Those states were all given their own country codes, except for Ukraine and Belarus, which had already entered ISO 3166 before this point.

But can you still get a .su domain? Well, sure! Netim.com will happily register one for you. A number of websites still use the TLD, like this one, and it has reportedly become a popular TLD for cybercriminal activity. The current registry is the Russian Institute for Public Networks, and .su domains persist despite efforts by ICANN to end its use in 2007.

Given .io is so incredibly popular, it’s unlikely to disappear just because of some geopolitical changes. Even if it were to be designated for retirement, it would probably stick around for another five to ten years based on existing regulations. More likely, though, special effort will be made to officially reserve .io for continued use. Heck, even if ISO drops it, it could become a regular general TLD instead. If .pizza can be a domain, surely .io can be as well.

Long story short? There are questions around the future of .io, but nothing’s been decided yet. Expect vested interests to make sure it sticks around for the foreseeable future.

 

Starting a hacker con is hardly what anyone would describe as easy — but arguably, the truly difficult part is keeping the momentum going into the second year and beyond. For the first year, you can get away with a few missed opportunities and glitches, but by the time you’ve got one event under your belt, you’ll have set the bar for what comes next. There’s pressure to grow, to make each year bigger and better than before. All the while, making sure you don’t go broke in the process. Putting on a single hacker con is an achievement in and of itself, but establishing a long-running hacker con is a feat that relatively few groups have managed to pull off.

With this in mind, the incredible success of the second annual JawnCon is all the more impressive. The Philadelphia-area event not only met the expectations of a sophomore effort, but exceeded them in pretty much every quantifiable way. From doubling attendance to providing a unique and immersive experience with their electronic badge, the team seized every opportunity to build upon the already strong foundation laid last year. If this was the make-or-break moment for the Northeast’s newest hacker con, the future looks very bright indeed.

But before setting our sights on next year, let’s take a look at some of the highlights from JawnCon 0x1. While you can watch all of this year’s talks on YouTube, the aspect of a hacker on that can’t easily be recorded is the quality time spent with like-minded individuals. Unfortunately, there’s no way to encompass everything that happened during a two-day con into a single article. Instead, this following will cover a few of the things that stood out to me personally.

If you’d like to experience the rest of JawnCon, you’ll just have to make the trip out to Philly for 2025.

Creating New Traditions

For returning attendees, certainly the most striking thing about this year’s event was simply how many people showed up. In the closing ceremonies, we learned that attendance had more than doubled since last year, and you could absolutely feel it. The rooms never felt cramped, but they certainly felt full. 

But the growth of this year’s event wasn’t limited to the ticket holders. The local chapter of The Open Organisation Of Lockpickers (TOOOL) was there, equipped with picks and transparent padlocks for anyone interested in an impromptu lesson in lockpicking. You could also try to get yourself out of a pair of handcuffs and other forms of restraints.

This year also featured a “Free Table” where attendees could leave interesting items for others. We’ve all got some piece of hardware that’s been gathering dust for just a bit too long. Maybe it was for some project that you’re no longer interested in, or you just don’t have the time to mess around with it. Instead of tossing it in the trash, a table like this is a great way to re-home some of those technical treasures.

The table was constantly being refreshed as more attendees showed up and added their contributions to the pile. There was only one rule: if your stuff was still there at the end of the con, you had to take it home. But as things started wrapping up on Saturday evening, there were just a few oddball antenna cables and a couple mystery PCBs left. It was especially gratifying to see how many reference books were picked up.

Another highlight this year was a informal competition inspired by the old IT adage that digital subscriber line (DSL)  broadband service could be run over a piece of wet string. With all the hardware necessary to establish a DSL connection on-site, attendees were invited to bring up various objects that would fill in for the telephone line. The medium that provided the fastest confirmed Internet connection would be crowned the winner.

Two pieces of spaghetti ended up taking the top spot, with a link speed of 10 Mbit. A section of carbon fiber tube — dubbed “hard-line coax” for the purposes of the competition — managed second place with around 6 Mbit. As you might expect, the failures in this competition were perhaps just as interesting as the successes. A line of “energy gel” was apparently not conductive enough, though some flickering of the indicator LEDs on the modem seemed to indicate it was close. While it came as no surprise that a line of hackers holding hands wasn’t a suitable link for the experiment, the audience did appreciate the irony that the hardware indicated it couldn’t progress past the handshaking stage of the connection.

Living History for Hackers

Attendees had already gotten a sneak peek at the JawnCon 0x1 badge a few weeks before the event, so the fact that they’d all be getting tiny modems to plug into their computers (and indeed, wear around their necks) wasn’t a complete surprise. But still, I don’t think anyone was fully prepared for what a unique experience it was really going to be.

For the younger players, there was an obvious learning curve. But the veterans in attendance were all too happy to explain the relevant AT commands and get them dialing away. Once you’d figured out how to connect up to the network and start exploring, it added a whole new dimension to the event.

Not only were there various puzzles and Capture the Flag (CTF) challenges that could be accessed through the modem, but it also acted as a gateway to games, chats, and other features that functioned within the con’s infrastructure.

For example, running a command within the modem’s onboard menu system would print the current talk taking place on the stage downstairs, and tell you who was up next.

It was actually a bit surreal. Walking around you’d come across a table of 20-somethings, all with look-alike Hayes modems plugged into their shiny new MacBooks or high-end gaming laptops. It’s hard to say how many of them came away from the event with a new respect for the old ways, but there’s no question they had learned a hell of a lot more about the early Internet than they would have from just watching a YouTube video about it.

While the badge was certainly the star of the show, there were also vintage serial terminals dotted around the chill-out area that you could interact with. By default they showed the talk schedule in a glorious shade of either amber or green, but hit a key and you’d be dumped into the terminal. Nominally, jumping on the terminals and executing various tasks was part of the CTF, but it was also a lot of fun to turn back the clock and sit down at a real serial terminal and interact with some *nix box hidden away elsewhere in the building.

Long Live the Jawn

Any event that manages to double its attendance from the previous year is clearly doing something right. But if you don’t know how to handle the growth, it can become a problem. Luckily, the JawnCon staff are on the case. It sounds like next year they may opt to use a larger space within the same building at Arcadia University. The University is a great fit for the event, so the fact that there’s room to grow is great news for everyone involved.

Of course, it takes more than simply securing a larger room every couple years to make sure an event like this stays on the right track. You also need intelligent and responsible folks at the wheel. Here again, JawnCon is well equipped for the future. The staff and volunteers that worked tirelessly behind the scenes to bring this con to life are some of the most passionate and welcoming individuals I’ve ever had the pleasure of meeting. They represent the very best qualities of hacker culture, and armed with a genuine desire to bring that sense of exploration and inclusion to the next generation, they’re the catalyst that will keep JawnCon growing and evolving over the coming years.

Generally speaking, the Hackaday Supercon badge will always have a place for SAO (rebranded as “Supercon add-ons”), and that makes sense. We did originate them, after all. This year, though, we’ve gone all in on SAO, and, in particular, we’ve asked to see more SAOs with communication capabilities. The standard has always had an I2C bus, but few people use them. I decided I wanted to set an example and cook up a badge for Supercon. Was it hard? Yes and no. I’ll share with you a little about the board’s genesis and the issues I found. At the end, I’ll make you a special offer, if you are going to Supercon.

The Idea

I’ve been a ham radio operator for a very long time. In fact, July was my 47th anniversary in the radio hobby. Well, that’s not true. It was my 47th year with a license. I had been listening to shortwave long before then. So, I wanted to do something with Morse code. You don’t have to know Morse code to get a license these days, but a lot of hams enjoy it.

I set out to do a simple board that would play some Morse code messages. But that’s just another blinking light LED with a buzzer on it, too. So, naturally, I decided it would also provide Morse code output for the I2C host. That is, the SAO could be used to convert ASCII to Morse code. Sounds simple, right? Sure.

Getting Started

I wanted to use a Raspberry Pi Pico but didn’t want to violate the SAO size requirements. Luckily, there’s an RP2040-Zero module that is quite tiny and looks more or less like a normal Pico. The two big differences are plusses: they have a reset button, and instead of a normal LED, they have a WS2812b-style LED.

Using that let me not worry about a lot of overhead on the board. Sure, it costs a few bucks more, so if you were mass-producing something, that’s not so good. But for this, it was perfect. I only had to add a speaker with a little transistor driver, which is probably unnecessary, four more WS2812B LEDs, and the SAO connector.

I was going to add a button, but I remembered from last year there is a way to use the BOOTSEL button on the module as a normal button, so I decided to cut a corner there. I could have shrunk the board, but I wanted some area for a protyping area and some cool silk screen, since I’m not artistic enough to come up with a nice outline for the board, so I kept the board full-size which is a lot of space.

The only strange thing is that the RP2040-Zero has parts on both sides, so it needs a cutout in the board. No problem. KiCAD didn’t have a good footprint for it that I could find, so I switched over to EasyEDA. They have handy integration with the parts you can get, too, so it is easy to price your board and even buy them already put together if you like.

While I waited for the boards, I decided to grab a similar Pico board and prototype the software. However, in the middle of this, I got a disturbing e-mail.

The Boards are Wrong?

The Chinese board house sent me a note: they were not sure the LEDs were connected properly. I checked, and I double-checked. They looked OK to me. I bravely asked them to build the boards as specified and went back to prototyping.

I’m not always a fan of Python, but we have a history of doing badges in Python so people can easily hack them. So I decided to stick to MicroPython. Getting the code and other features to work was a piece of cake. There is something surreal about using regular expressions to filter comments out of a file on a little microprocessor.

I2C Woe

Once I had the main features working, I set out to do the I2C when I realized an unpleasant fact. The Micropython library has I2C classes so you can host an I2C device. It does not have code that lets you be an I2C device yourself. CircuitPython apparently supports this, but I was in no mood to move the code over. Had I realized it going in, I might have made a different choice.

Luckily, an online forum had some code that directly manipulated the chip’s I2C registers and I was able to adapt that. If you are thinking of building an SAO with I2C capabilities, this is something to check before you go too far.

I stuck with the simple protocol that just lets me receive I2C commands because that’s all I needed, but there were examples of going further. For my project, I created the I2CTarget class. You tell the constructor which I2C bus you want to use, what pins you want to map to, and the I2C address you want to use. There are defaults for all of that.

Once it is running, you can check to see if data is available (call any()) and then read that data (get()). Don’t forget that reading data will block, so if you don’t want to block, check to see if anything is available first. The I2C hardware on the chip has a small FIFO, so that’s fine for this project.

I did create a subclass that allows an I2C object to act like a menu in the code. The menu object normally gets input from the user, but using this little trick lets the I2C commands fake user input.

The Boards Arrive

The board came in, as boards tend to do. I changed a few I/O pins in my code and… big sigh of relief, the LEDs were fine. A few tweaks on the code and the SAO was complete.

I left you all the files and documentation over on Hackaday.io. Maybe I went a little overboard with the documentation. You can decide. The source code is on GitHub, but you’ll find the link on the IO page.

Special Offer

Do you want one? Well, all the design files are there. Fire up your favorite way to etch boards or order them from your favorite board house. It wouldn’t be that hard to point-to-point wire one or put one on a breadboard except for the SAO connector, of course.

However, I have a deal for you. I have a limited number of these and will have them at Supercon. Find me — I’m easy to find since I mostly hang out at the soldering challenge table — and show me some code you propose to run that either uses the SAO or runs on the SAO. If I have any left, I’ll give you one, but when I’m out, I’m out. So, to be on the safe side, maybe make your own and bring it anyway.

Trint is a powerful AI transcription tool that converts your audio and video files to text, making them editable, searchable, and collaborative. Trint has multilingual capabilities and can currently transcribe in 30+ languages. The tool can also generate and edit closed captions for video content, improving accessibility, and securely stores all your content in one […]

Source