Sitting on a train leaving the Hackaday Berlin conference, and Hacker News pops up Julian Shapiro with a guide to HiFi. What Hackaday scribe wouldn’t give it a click, to while away the endless kilometres of North European Plain!
It’s very easy as an analogue electronic engineer, to become frustrated while reading audiophile tracts, after all they have a tendency to blur superficial engineering talk with pseudoscience. There’s a rich vein of parody to be found in them, but nevertheless it’s interesting to read them because just sometimes the writer gets it and doesn’t descend into the world of make-believe.
This one is probably par for the course, we raised an eyebrow at the idea of comparing different speaker setups merely from sampled recordings, and rolled our eyes at the usual price-tag worship, but at least some of the acoustics stuff isn’t from another planet. The stand-out quote that motivated its write-up here though is the following, where he addresses the relationship between the audiophile industry and the audiophile press:
Also, note that almost all hifi reviews are positive. This is because reviewers typically return products without review when they dislike it. They do this to maintain relationships with manufacturers and to give them another chance with new products in the future.
Perhaps unwittingly it reveals in a nutshell the problem with the audio reviews. He’s dead right in that HiFi reviewers return positive assessments as a matter of course to maintain relationships with manufacturers, but omits the crucial point that they do so to maintain the hefty sums those manufacturers spend on advertising in their publications. We’d suggest that better reviews would come from a truly independent publication giving the only HiFi verdicts that matter, blind tests and measurements from a high-end audio analyser, but we suspect that the industry lacks the courage to do so. Until that happens, almost everything remains subjective, and coloured by advertising budgets.
Want the straight dope on audio? Read our Know Audio series.
JBL loudspeaker header image: JPRoche, CC BY-SA 3.0.
For a brief moment in the late ’00s, netbooks dominated the low-cost mobile computing market. These were small, low-cost, low-power laptops, some tiny enough to only have a seven-inch display, and usually with extremely limiting hardware even for the time. There aren’t very many reasons to own a machine of this era today, since even the cheapest of tablets or Chromebooks are typically far more capable than the Atom-based devices from over a decade ago. There is one set of these netbooks from that time with a secret up its sleeve, though: Phoenix Hyperspace.
Hyperspace was envisioned as a way for these slow, low-power computers to instantly boot or switch between operating systems. [cathoderaydude] wanted to figure out what made this piece of software tick, so he grabbed one of the only netbooks that it was ever installed on, a Samsung N210. The machine has both Windows 7 and a custom Linux distribution installed on it, and with Hyperspace it’s possible to switch almost seamlessly between them in about six seconds; effectively instantly for the time.
[cathoderaydude]’s investigation into how bargain-basement hardware from 15 years ago is able to do this revealed more mysteries than it seemed to solve at the time. At first it looked like Hyperspace was acting as a hypervisor, essentially supervising the virtualization of both operating systems and switching between the two. But that’s not exactly what was going on here. Both operating systems seemed to share a partition and filesystem, certainly impossible, and it eventually he found a master boot record and file system hidden away at the end of the drive. From there he was able to piece together that a few different instances of GRUB were allowing all kinds of unusual things to happen, effectively mounting both operating systems at the same time to the hard drive and mapping them both into memory in ways that are still not entirely transparent.
From an outside perspective, this seems relatively similar to the discovery of the fast inverse square root algorithm within Quake, or this other similar (yet fictional) scenario. [cathoderaydude] admits during the analysis of these tools that it seems like Phoenix created what is effectively a miracle, by software standards, that no one ended up wanting or using, which was eventually forgotten to time. And, if you missed this era in computing history, head over here to see some of the other things that were lost from these days.
The amateur radio community often gets stereotyped as a hobby with a minimum age requirement around 70, gatekeeping airwaves from those with less experience or simply ignoring unfamiliar beginners. While there is a small amount of truth to this on some local repeaters or specific frequencies, the spectrum is big enough to easily ignore those types and explore the hobby without worry (provided you are properly licensed). One of the best examples of this we’ve seen recently of esoteric radio use is this method of using packet radio to play a game of Colossal Cave Adventure.
Packet radio is a method by which digital information can be sent out over the air to nodes, which are programmed to receive these transmissions and act on them. Typically this involves something like email or SMS messaging, so playing a text-based game over the air is not too much different than its intended use. For this build, [GlassTTY] aka [G6AML] is using a Kenwood TH-D72 which receives the packets from a Mac computer. It broadcasts these packets to his node, which receives these packets and sends them to a PDP-11 running the game. Information is then sent back to the Kenwood and attached Mac in much the same way as a standard Internet connection.
The unique features of packet radio make it both an interesting and useful niche within the ham radio community, allowing for all kinds of uses where data transmission might otherwise be infeasible or impossible. A common use case is APRS, which is often used on VHF bands to send weather and position information out, but there are plenty of other uses for it as well.
In celebration of the tenth running of the Hackaday Prize, we had a fantastic weekend event in Berlin. This was a great opportunity for all of the European Hackaday community to get together for a few days of great talks, fun show-and-tells, and above all good old fashioned sitting together and brainstorming. Of course there was the badge, and the location – a gigantic hackerspace in Berlin called MotionLab – even had a monstrous laser-eye octopus suspended from a gantry overhead. Everyone who came brought something to share or to show. You couldn’t ask for more.
Unfortunately, we weren’t able to record the talks, so we’ll run down the highlights for you here. [Jenny List] is writing up a bunch of the badge hacks as we speak, so we’ll skip that for now. For the full experience, you just had to be there, but we’ll share with you what pictures we got. Enjoy!
The morning kicked off with [Jiska Classen] taking us through her reverse engineering practice. She’s not shy to admit that it involves a lot of “staring at code” until it gives, but she also pointed out some helpers along the way. If you can get the SDK, they often leave the symbols in, which help with a lot of the staring. And [Jiska] gave a great introduction to dynamic reverse engineering practices – writing your own code hooks is a lot like printf() for someone else’s closed-source binary.
[James Bruton] took the stage next, telling us how he gets it all done on his prolific YouTube channel. A good percentage of this involves simply working full days or more, but he also has an agent who helps him with sponsorships, which make up most of his income. If you want to know how to make a career out of it, [James] says you have to do it well, invest in your studio and production, and keep producing quality content. No surprise there. The one tip that might surprise was that since retention matters to the YouTube algorithm, getting a single hit that goes viral might actually hurt rather than help.
Former Hackaday Prize winner [Ali Shtarbanov] talked in depth about his huge project, FlowIO, and open-source hardware and software platform for creating soft robotics. Since the hardware itself can cost a lot of money to manufacture, [Ali] mentioned a lending-library like approach to encourage people to work on their projects using his system, which we think is an interesting solution to the problem where you need the hardware first to write the software.
[Astrid Bin] gave a tremendously fun about the musical instruments of the Star Trek universe. There were a lot more of them than we thought, and they all tell something about the aliens that played them, but more to the point, she learned a lot about real (non-conventional) instrument design from studying them. Along the way, she made a harp-like instrument that played notes louder and louder as you gripped it harder and harder, eventually releasing in an explosion of sound. Our biggest take-home conclusion about designing electronic musical instruments – don’t focus about what you can do technically, but rather think about the music that the thing will let you create, because that’s what matters.
[Bleeptrack] gave us a look into her generative art practice. She’s made an infinite bug generator, never-repeating circuit board designs, and a perspective on why you don’t want to carve too much detail even if you’ve got a CNC router – it’s all the sanding. One of the main themes of the talk was walking the balance between letting everything become random and selecting enough parameters to control that you have interesting artistic control over the whole affair.
Finally [Trammell Hudson] told the tale of reverse engineering the cellphone app that controlled his IoT dishwasher in order to get it on his home automation network. Coming full circle, he actually included a picture of a slide from [Jiska]’s presentation in his, and shared her love for dynamic reverse engineering. He gave big props to the Frida reverse engineering toolkit for Android apps, and at the end of the day built a tool to let you control your own Home Connect appliances however you’d like.
Most of the fun of being at something like Hackaday Berlin is hanging out with more than 256 fellow nerds, and sharing your stories of success and failure. The Friday night, we started out at the BrewDog, where we overflowed our allotted table space and started taking up any seats nearby that the waitstaff could find us.
Saturday was truly taken up mostly with the talks, but also went on late into the night. While Hackaday.io’s own [Rich Hogben], played live modular techno until about 3:30 AM, some folks from MotionLab pulled out their turntables and kept things going until 5:30 AM.
How people managed to roll out of bed and make the Bring-a-Hack Brunch at 11:00 on Sunday morning is a miracle, but almost everyone did! That’s dedication. And then the lightning talks on Sunday morning were nothing short of marvelous.
I had never been to MotionLab before, but it’s a fantastic warehouse space filled with all of the tools that a hacker could need and then some. From a laser cutter that you could lie down in, to soldering stations for a workshop, to a 3D printer that’s big enough to print a human-sized chair in one go, the equipment is there. But more so, the hacking spirit is alive.
It takes a certain square meterage to fit a bus in a space, but it takes a bunch of crazy hackers to turn it into a lounge, studio, and meeting room. It provides a nice quiet zone in the middle of the space and we’re more than a little jealous.
The giant inflatable octopus is made up of castaway industrial fans, found plastic sheeting, and bungee cords pulled by motors. Its eyes are DMX-controlled club lights, and the whole thing was suspended on the space’s overhead gantry. Needless to say, as it came at you, scanning, glowing, and moving overhead, it was a mix of menacing and awesome.
And last but not least, the secret surprise reveal that we maybe leaked out to the audience by accident – the Hackaday Prize turns ten this year. It’s our tenth time ’round, and we’re running a number of our favorite categories from the past, and one new one. For the full details, you really want to head over to the official Hackaday Prize landing page, or stay tuned for our introduction to the first challenge, Re-engineering Education, tomorrow.
We’re super excited to see what you bring to the Prize this time around, and it kicked off on Saturday, so get hacking!
When it comes to placing a project underwater, the easy way out is to just stick it in some sort of waterproof container, cover it with hot glue, and call it a day. But when you need to keep water out for several years, things get significantly harder. Luckily, [Patricia Beddows] and [Edward Mallon] from the Cave Pearl Project have written up their years of experience waterproofing data loggers for long-term deployment, making the process easier for the rest of us.
It starts with the actual board itself. Many SMD boards have at least some flux left over from the assembly process, which the duo notes has a tendency to pull water in under components. So the first step is to clean them thoroughly with an ultrasonic cleaner or toothbrush, though some parts such as RTCs, MEMs, or pressure sensors need to be handled with significant care.
Actual waterproofing starts with a coating like 422-B or nail polish which each have pros and cons. [Patricia] and [Edward] often apply coatings to PCBs even if they plan to otherwise seal it as it offers a final line of defense. The cut edges of PCBs need to be protected so that water can’t seep between layers, though care needs to be made for connectors like SD cards.
Encapsulation with a variety of materials such as hot glue, heat shrink tubing, superglue and baking soda, silicone rubber, liquid epoxy, paste epoxy (like J-B Weld), or even wax are all commented on. The biggest problem is that a material can be waterproof but not water vapor proof. This means that condensation can build up inside a housing. Temperature swings also can play havoc with sealings, causing gaps to appear as it expands or contracts.
Overall, it’s an incredible guide with helpful tips and tricks for anyone logging data underwater for science or even just trying to waterproof their favorite watch.
When the microwave oven started to gain popularity in the 60s and 70s, supporters and critics alike predicted that it would usher in the end of cooking as we knew it. Obviously that never quite happened, but not because the technology didn’t work as intended. Even today, this versatile kitchen appliance seems to employ some magic to caffeinate or feed a growing hacker in no time flat. So, how exactly does this modern marvel work?
That’s exactly what [Electronoob] set out to explain in his latest video. After previously taking apart a microwave and showing off the magnetron within he’s back with a clear explanation of how these devices work.
Maybe you have no idea, or have heard something vague about the water in the food wiggling in response to the microwaves. Do you know why microwaves and not some other part of the electromagnetic spectrum? Why the food spins on a platter? How the size of the oven relative to the wavelength affects the efficiency of its cooking? We didn’t, and think the video is a great primer on all of this and more.
Here at Hackaday, we sure love using and abusing microwave ovens. From upgrading them with voice control back in 2013, to turning them into UV curing chambers and mini foundries, to the limitless possibilities for the transformers and magnetrons that await us inside, we just can’t get enough. (this is our 82nd article tagged with microwave!)
When we first started 3D printing, we used ABS and early slicers. Using supports was undesirable because the support structures were not good, and ABS sticks to itself like crazy. Thankfully today’s slicers are much better, and often we can use supports that easily detach. [Teaching Tech] shows how modern slicers create supports and how to make it even better than using the default settings.
The video covers many popular slicers and their derivatives. If you’ve done a lot with supports, you might not find too much of this information surprising, but if you haven’t printed with supports lately or tried things like tree supports, you might find a few things that will up your 3D printing game.
One thing we really like is that the video does show different slicers, so regardless of what slicer you like to use, you’ll probably find exactly what different settings are called. Of course, because slicers let you examine what they produce layer-by-layer, you can do like the video and examine the results without printing. [Michael] does do some prints with various parameters, though, and you can see how hard or easy the support removal is depending on some settings. The other option is to add support to your designs, as needed manually, or — even better — don’t design things that need support.
This video reminded us of a recent technique we covered that added a custom support tack to help the slicer’s automatic support work better. If you want a longer read on supports that also covers dissolvable support, we’ve seen that, too.
