Many of us can’t get through the day without at minimum one cup of coffee, or at least, we’d rather not think about trying. No matter how you choose to ingest caffeine, it is an awesome source of energy and focus for legions of hackers and humans. And evidently, the same goes for pollinator bees.
You’ve probably heard that there aren’t enough bees around anymore to pollinate all the crops that need pollinating. That’s old news. One solution was to raise them commercially and then truck them to farmers’ fields where they’re needed. The new problem is that the bees wander off and pollinate wildflowers instead of the fields they’re supposed to be pollinating. But there’s hope for these distracted bees: Scientists at the University of Greenwich have discovered that bees under the influence of caffeine are more likely to stay on track when given a whiff of the flower they’re supposed to be pollinating.
It would be fair to say that the Internet as we know it runs on Cisco hardware. While you might never see the devices first-hand, there’s an excellent chance that every web-bound packet leaving your computer or smartphone will spend at least a few milliseconds of its life traveling through hardware built by the San Jose, California based company. But of course, even a telecommunications giant like Cisco had to start somewhere.
Cisco’s first commercial router, the Advanced Gateway Server (AGS), was released in 1986 and helped put the company (and the Internet) on the path towards unfathomable success. [Andreas Semmelmann] had wanted to add one of these microwave-sized machines to his collection for some time, so when an AGS+ popped up in the local classifieds he didn’t hesitate to make the hour drive to go pick it up. But like many pieces of vintage computing equipment, it needed a little help getting back on its feet.
What 4 MB of flash looked like in the late 1980s.
Since he had to take the router apart anyway to diagnose what ailed it, [Andreas] decided to take photographs along the way and document this piece of Internet history. He walks the reader through the massive processor, Ethernet, and serial cards that are housed in the unit’s rack-like enclosure. We appreciate him taking the scenic route, as it gives us a great look inside what would have been state-of-the-art telecommunications gear when this version of the AGS hit the market in 1989.
The walk-through is full of interesting details that make us appreciate just how far things have come in the last 32 years. Imagine yanking the EPROMs out of the board and firing up the UV eraser each time you needed to update your router’s firmware. Or needing a special adapter to convert the AUI-15 connectors on the back panel to the now ubiquitous RJ45 jack.
After this stroll down memory lane, [Andreas] gets to the actual repair work. It likely won’t surprise the regular Hackaday reader to find that the power supply wasn’t operating to spec, and that some aged capacitors and a shorted rectifier diode needed to be replaced to put it back on an even keel. But even with the PSU repaired, the router failed to start. The console output indicated the software was crashing, but hardware diagnostics showed no obvious faults.
Replacing these failed PSU components was just the beginning.
With some part swapping, firmware flashing, and even a bit of assistance from Cisco luminary [Phillip Remaker], the issue was eventually identified as a faulty environmental monitoring (ENVM) card installed in the AGS+. As luck would have it the ENVM capability isn’t required to boot the router, so [Andreas] was able to just disconnect the card and continue on with his exploration of the hardware that helped build the Internet as we know it.
Low Earth orbit was already relatively crowded when only the big players were launching satellites, but as access to space has gotten cheaper, more and more pieces of hardware have started whizzing around overhead. SpaceX alone has launched nearly 1,800 individual satellites as part of its Starlink network since 2019, and could loft as many as 40,000 more in the coming decades. They aren’t alone, either. While their ambitions might not be nearly as grand, companies such as Amazon and Samsung have announced plans to create satellite “mega-constellations” of their own in the near future.
At least on paper, there’s plenty of room for everyone. But what about when things go wrong? Should a satellite fail and become unresponsive, it’s no longer able to maneuver its way out of close calls with other objects in orbit. This is an especially troubling scenario as not everything in orbit around the Earth has the ability to move itself in the first place. Should two of these uncontrollable objects find themselves on a collision course, there’s nothing we can do on the ground but watch and hope for the best. The resulting hypervelocity impact can send shrapnel and debris flying for hundreds or even thousands of kilometers in all three dimensions, creating an extremely hazardous situation for other vehicles.
One way to mitigate the problem is to design satellites in such a way that they will quickly reenter the Earth’s atmosphere and burn up at the end of their mission. Ideally, the deorbit procedure could even activate automatically if the vehicle became unresponsive or suffered some serious malfunction. Naturally, to foster as wide adoption as possible, such a system would have to be cheap, lightweight, simple to integrate into arbitrary spacecraft designs, and as reliable as possible. A tall order, to be sure.
But perhaps not an impossible one. Boeing subsidiary Millennium Space Systems recently announced it had successfully deployed a promising deorbiting device developed by Tethers Unlimited. Known as the Terminator Tape, the compact unit is designed to rapidly slow down an orbiting satellite by increasing the amount of drag it experiences in the wispy upper atmosphere.
These days we’re spoiled for choice when it comes to smartphone software, especially games. Official repositories for the leading handsets feature hundreds of thousands of games, and sideloading adds infinite possibilities. If you were lucky enough to be sporting a Nokia handset in the late 1990s, you probably had all of three games to choose from (and only one that was actually fun). [Janus Cycle] explores the steps needed to firmware mod your vintage Nokia phone, and how to expand on that paltry games library.
Enthusiasts have been modding their Nokia handsets since the 2000s, and the tools required now are the same as they were then. The Nokia 5110 and 6110 (as featured in the video below) use a proprietary cable and connector for communicating with PCs and other devices. Nokia’s official serial cable already opens up many possibilities for handset tinkering, including access to RAM and toggling Monitor Mode. This cable interfaces solely with the phone’s fast FBUS protocol, however firmware flashing takes place using the slower MBUS protocol over a single wire bi-directional pin.
The handset expects both serial ports to be available during firmware flashing. [Janus Cycle] demonstrates how to build a custom harness that connects both serial ports to a PC parallel port. At this point the flashing process is relatively straightforward, especially if you have an appropriately vintage computer to run the old flashing software.
Nokia owners may fondly remember changing the network name on the home screen to all sorts of inappropriate graphics, yet far more was possible with the right technology and know-how. It’s interesting to think about what may have been if softmodding was more widespread during the reign of the Nokia 5110 and its peers.
Sony’s Playstation 5 console and its DualSense controllers aren’t exactly new, but the triggers of the controllers have a genuinely interesting design that is worth examining. The analog triggers on the PS5 controllers are generally described as having “variable resistance”, but it turns out that’s not the whole story. Not only is the trigger capable of variable resistance when being pressed, but it can also push back in variable ways and with varying amounts of force. How it works is pretty clever.
The feedback for the trigger assembly is handled by a lever, a geared wheel, and a worm gear on an electric motor. Under normal circumstances, nothing interferes with the trigger at all and it works like a normal analog trigger. But when the motor moves the lever into place, trigger movement now has to overcome the added interference with a mechanical disadvantage. The amount of resistance felt can be increased a surprising amount by having the motor actively apply additional force to counter the trigger’s movement.
That’s not all, either. The motor can also actively move the lever into (or out of) position, which means that pulling the trigger not only has the ability to feel smooth, mushy, or stiff in different places, but it can also actively push back. This feedback can be introduced (or removed) at any arbitrary point along the trigger’s range of motion. A trigger pull can therefore feel like it has a sharp breakpoint, a rough travel, a hard stop, an active recoil, or any combination of those at any time.
It’s a little hard to describe, but you can get a better idea of it all works in practice by watching part of this teardown by [TronicsFix] (video cued to about 9:17 where the trigger teardown begins.) It’s also embedded below, so give it a peek.
A small amount of force applied in the right place can produce outsized results, but a force feedback project doesn’t have to be subtle. One can always shake things up by mounting a whole bunch of solenoids onto a mouse.
Documentation can be a bit of a nasty word, but it’s certainly one aspect of our own design process that we all wish we could improve upon. As an award-winning designer, working with some of the best toy companies around, [Jude] knows a thing or two about showing your work. In his SkunkWorks Project, he takes a maker’s approach to Bo Peep’s Skunkmobile and gives us a master class on engineering design in the process.
As with any good project brief, [Jude] first lays out his motivation for his work. He was very surprised that Pixar hadn’t commercialized Bo Peep’s Skunkmobile and hoped his DIY efforts could inspire more inclusive toy options from the Toy Story franchise. He does admit that the Skunkmobile presents a more unique design challenge than your standard, plastic, toy action figure. Combining both the textile element to create the illusion of fur and the RC components to give the toy its mobility requires careful thought. You definitely don’t want the wheels ripping into the fabric as you wheel around the backyard or for the fur to snag every object you pass by in the house.
Given the design challenges of making the Skunkmobile from scratch, [Jude] decided the best way forward was to retrofit a custom-designed skunk-shaped body onto a standard RC car chassis. The difficulty here lies in finding a chassis that can support the weight of the retrofitted body as well as one big enough to hold a 9-inch Bo Peep doll inside the driver’s compartment. Before spending endless hours 3D printing (and re-printing) his designs, [Jude] first modeled the Skunkmobile in card (using cardboard), a practice we’ve seen before, and are always in love with. He continually emphasized the form of his device was probably even more important than its function as capturing the essence as well as the “look and feel” of the Skunkmobile were critical design criteria. You can even see the skunk wagging its tail in all his demo videos. Prototyping in card gave [Jude] a good feel for his Skunkmobile and the designs translated pretty well to the 3D printed versions.
What really impressed us about [Jude’s] project is the incredible detail he provides for his entire design process from his backstory, to the initial prototypes, to the user testing, and, finally, to the realization of the final product. Remember, “We want the gory details!”
Fresh from the mediaeval splendour of the Belgian city of Gent, we bring you more from the Newline hacker conference organised by Hackerspace Gent. [Victor Sonck] works at the top of his house, and thus needed a doorbell notifier. His solution was unexpected, and as he admits over engineered, using machine learning on an audio stream from a microphone to detect the doorbell’s sound.
Having established that selling his soul to Amazon with a Ring doorbell wasn’t an appropriate solution, he next looked at his existing doorbell. Some of us might connect directly to its power to sense when the button was pressed, but we’re kinda glad he went for the overengineered route because it means we are treated to a run-down how machine learning works and how it can be applied to audio. The end result can sometimes be triggered by a spoon hitting a cereal plate, but since he was able to demonstrate it working we think it can be called a success. Should you wish to dive in further you can find more in his GitHub repository.
How would you overengineer a doorbell? Use GNU radio and filters? Or maybe a Rube Goldberg machine involving string and pulleys? As always, the comments are open.
The feedback for the trigger assembly is handled by a lever, a geared wheel, and a worm gear on an electric motor. Under normal circumstances, nothing interferes with the trigger at all and it works like a normal analog trigger. But when the motor moves the lever into place, trigger movement now has to overcome the added interference with a mechanical disadvantage. The amount of resistance felt can be increased a surprising amount by having the motor actively apply additional force to counter the trigger’s movement.
