Tree Planting Festivals, Air Cannons, Self-Burying Seeds, And The Complexities Of Reforestation

At first glance the problem of how to plant trees would seem to be a straightforward one: take a seed, jam it into the soil and let nature take its course. Or alternatively do much the same with a sapling that already got a start in a nice, comfortable greenhouse before leaving it to its own devices. To the average person this is generally the point where it’s considered a ‘done deal’, but one only has to take a look at the average survival rate of saplings out in the wild to perish that thought.

Each environment offers its own set of challenges when it comes to reforestation, which can perhaps be considered ironic as many of these trees are being planted where forests used to be, albeit centuries ago in many cases. There are the easy spots, such as flat fields, with rich soil, ample rain and mild weather, to the challenging terrain of Iceland, or mountainous terrain. Here the logistics are challenging and where once rich forests flourished, the very landscape seems adamant to reject this botanic intrusion.

Further complicating matters here are the myriad of reasons why we’re looking at planting so many new trees that it has even become an internet thing, as with the 2019 ‘Team Trees’ 20 million new trees challenge. So how did we get here, why exactly are we doing all of this, and how much of these attempts do bear fruit?

Continue reading “Tree Planting Festivals, Air Cannons, Self-Burying Seeds, And The Complexities Of Reforestation”

Contrary View: Chatbots Don’t Help Programmers

[Bertrand Meyer] is a decided contrarian in his views on AI and programming. In a recent Communications of the ACM blog post, he reveals that — unlike many others — he thinks AI in its current state isn’t very useful for practical programming. He was responding, in part, to another article from the ACM entitled “The End of Programming,” which, like many other articles, is claiming that, soon, no one will write software the way we do and have done for the last few decades. You can see [Matt Welsh] describe his thoughts on this in the video below. But [Bertrand] disagrees.

As we have also noted, [Bretrand] says:

“AI in its modern form, however, does not generate correct programs: it generates programs inferred from many earlier programs it has seen. These programs look correct but have no guarantee of correctness.”

Continue reading “Contrary View: Chatbots Don’t Help Programmers”

Photo of the head unit , with "Hacked by greenluigi1" in the center of the UI

Hacking A Hyundai Ioniq’s Infotainment System Again After Security Fixes

These days modern cars are nothing if not a grouping of networked software held together by bits of hardware. This is reflected not only in the rapidly increasing number of ECUs, but also infotainment systems and all-glass cockpits. For better or worse, this offers many exciting hacking possibilities, which [greenluigi1] was more than happy to explore with their new 2021 Hyundai Ioniq SEL last year. Naturally, Hyundai then proceeded to ‘fix’ these vulnerabilities, offering the exciting chance to test the Hyundai engineers’ homework, and proceed to bypass it again.

When we last left off in [greenluigi1]’s adventures, the Hyundai D-Audio 2V Linux-based infotainment system (formally called in-vehicle entertainment, or IVI) in question had been convinced to run custom applications after a fair bit of effort to get root access via the Engineering Menu and some firmware image hacking. Joyous hacking and exploration of the car’s CAN network and RPC messaging system ensued. Then Hyundai released a new firmware image, after months of silence and all old firmware images pulled from the download page.

In this new firmware image, big changes were visible right off the bat, with two different ZIP files instead of the single one from before. One of these ZIP files also couldn’t be decrypted any more with the old key. Unfortunately for Hyundai, the curse of backwards compatibility with older IVIs meant that the ZIP targeting headunits running the older firmware also contained the key for the new ZIP file.

Other changes included some further obfuscation to this key and the public key used for firmware hash verification, which also involved using a Micom RPC call via the CAN bus to obtain some vehicle specific information. Unfortunately, this is where Hyundai’s engineers seemed to have stopped copying reference code samples, and used a unique RSA private key to sign firmware images with. Fortunately, they did not bother to check whether the updater actually always verifies the signature, allowing for unsigned code to be installed.

All in all, a fascinating bit of reverse-engineering and sheer stubborn persistence, just so that the IVI that’s in your car can run the applications which you developed. We’re looking forward to the next installments in this series as the ball is once again firmly in Hyundai’s court.

Royal Navy Tests Quantum Navigation

GPS has changed the way we get around the globe. But if you command a warship, you must think about what you would do if an adversary destroyed or compromised your GPS system. The Royal Navy and Imperial College London think a quantum navigation system might be the answer.
Of course, Heisenberg says you can’t know your speed and position simultaneously. But at the real-world level, you can apparently get close enough. The quantum sensors in question are essentially accelerometers. Unlike conventional accelerometers, though, these devices use ultracold atoms to make very precise measurements using a laser optical ruler, which means they do not drift as rapidly as, say, the accelerometer in your phone. Navigating with accelerometers is well understood, but the issue is how often you have to correct your computed position with an actual reference due to drift and other error accumulation. You can see a Sky News report on the trial below. Continue reading “Royal Navy Tests Quantum Navigation”

Well Documented Code Helps Revive Decades-Old Commodore Project

In the 1980s, [Mike] was working on his own RPG for the Commodore 64, inspired by dungeon crawlers of the era like Ultima IV and Telengard, both some of his favorites. The mechanics and gameplay were fairly revolutionary for the time, and [Mike] wanted to develop some of these ideas, especially the idea of line-of-sight, even further with his own game. But an illness, a stint in the military, and the rest of life since the 80s got in the way of finishing this project. This always nagged at him, so he finally dug out his decades-old project, dusted out his old Commodore and other antique equipment, and is hoping to finish it by 2024.

Luckily [Mike’s] younger self went to some extremes documenting the project, starting with a map he created which was inspired by Dungeons and Dragons. There are printed notes from a Commodore 64 printer, including all of the assembly instructions, augmented with his handwritten notes to explain how everything worked. He also has handwritten notes, including character set plans, disk sector use plans, menus, player commands, character stats, and equipment, all saved on paper. The early code was written using a machine language monitor since [Mike] didn’t know about the existence of assemblers at the time. Eventually, he discovered them and attempted to rebuild the code on a Commodore 128 and then an Amiga, but never got everything working together. There is some working code still on a floppy disk, but a lot of it doesn’t work together either.

While not quite finished yet, [Mike] has a well-thought-out plan for completing the build, involving aggregating all of the commented source code and doing quarterly sprints from here on out to attempt to get the project finished. We’re all excited to see how this project fares in the future. Beyond the huge scope of this pet project, we’d also suggest that this is an excellent example of thoroughly commenting one’s code to avoid having to solve mysteries or reinvent wheels when revisiting projects months (or decades) later. After all, self-documenting code doesn’t exist.

Continue reading “Well Documented Code Helps Revive Decades-Old Commodore Project”

Plastic Welding Revisited

Last time we talked about a video that purported to do plastic welding, we mentioned that the process wasn’t really plastic welding as we understood it. Judging by the comments, many people agreed, but it was still an interesting technique. Now [Inventor 101] has a video about plastic repair that also talks about welding, although — again, we aren’t sure all of the techniques qualify.

That’s not to say there aren’t some clever ideas, though. There are several variations on a theme, but the basic idea is to use a bolt or something similar in a soldering iron, metal reinforcement from things like wires and staples, and donor plastic from a zip tie. While we don’t think the nylon in a typical zip tie is the best way to repair anything other than nylon, if you were repairing something 3D printed, you could easily swap out the tie for filament of the same material, which — we think — would bond better.

Continue reading “Plastic Welding Revisited”

Moving The Snail Mail To WiFi

[Zak] loves getting a notification on his phone when he gets physical mail. Enough to wire his mailbox slot with an ESP8285 to send him alerts. Previously, [Zak] used a cellular-based solution as the mailbox slot was not within WiFi range. However, the network provider for the A9G GPRS module decided to move to different towers, and suddenly the module didn’t work. Unable to find a provider that had sensible pricing, he got to work redesigning the module.

The mailbox was now in a WiFi network range, meaning he no longer had to use cellular. This dramatically simplifies the design and uses an ESP-M2 module (think ESP8266 but with embedded flash). To maximize battery life, the ESP is entirely off most of the time. A reed switch triggers a 74LVC1G98 NAND gate with an inverted input. This enables the 3.3 voltage regulator. A 4uF capacitor holds the voltage regulator on for 716ms, giving the ESP8266 time to boot and drive the second pin of the logic gate so it can stay on. Once the web request completes (a call to a PHP server that takes 4-5 seconds, including WiFi association), it pulls the pin low, and the system powers off. With a custom server, [Zak] can include a few goodies, such as temperature and humidity from the SHT32-DIS sensor.

So far, the system has been chugging along for seven months and over 110 mail notifications and has only dropped 0.3v, suggesting that the battery should hold out for another year or two before recharging. The code and schematics are up on GitHub. We love the low-power focus and the handy circuit explanation that makes it easy to use in other projects.