UChaser Follows You Anywhere

If you’ve been making up for lost years of travel in 2023, you might have seen a fellow traveler in the airport terminal or train station walking with their luggage happily careening behind them. [Jesse R] and [Brian Lindahl] wanted more of that. They wanted an open-source, low-cost system that could be put in anything.

The basic principle is that they will have a transmitter that sends both a radio signal and an ultrasonic pulse. The receiver receives the radio signal and uses it as a reference for the two ultrasonic sensors. The time since the radio signal is compared between the two, and a distance and direction are established.

In practice, the radio is an ESP32-S3 using ESP-NOW (which we’ve seen relatively recently on another project), a protocol from Espressif that offers low latency 250 bytes payloads. The ultrasonic transceiver is based on Sparkfun’s HC-SR04. For prototyping purposes on the receiver, they just removed the transmitter to avoid populating the airwaves, as to listen, you had to transmit. The prototype was an electric wheelbarrow that would happily follow you around the yard wherever you go.

With the concept validated, they moved to a custom ultrasonic setup with a custom buffer amp and damp transistor, all centered around 20kHz. The simulations suggested they should have been better than the HC-SR04 from Sparkfun, but the 30-foot (9 meters) range went to 10 feet (3 meters). They ultimately returned to using Sparkfun’s circuit rather than the custom amp.

We’re looking forward to seeing the project continue. There are various challenges, such as variability in the speed of sound, echos and reflections, and ultrasonic line of sight. We love the peak behind the curtain that allows us to see what decisions get made and the data that informs those decisions. All the code and PCB design files are available on GitHub under an MIT and Creative Common license, respectively. This project was submitted as part of the 2o23 Hackaday Prize.

Video after the break.

Continue reading “UChaser Follows You Anywhere”

Screwdrivers And Nuclear Safety: The Demon Core

Harry Daghlian and Louis Slotin were two of many people who worked on the Manhattan Project. They might not be household names, but we believe they are the poster children for safety procedures. And not in a good way.

Harry Daghlian (CC-BY-SA 3.0, Arnold Dion)

Slotin assembled the core of the “Gadget” — the plutonium test device at the Trinity test in 1945. He was no stranger to working in a lab with nuclear materials. It stands to reason that if you are making something as dangerous as a nuclear bomb, it is probably hazardous work. But you probably get used to it, like some of us get used to working around high voltage or deadly chemicals.

Making nuclear material is hard and even more so back then. But the Project had made a third plutonium core — one was detonated at Trinity, the other over Nagasaki, and the final core was meant to go into a proposed second bomb that was not produced.

The cores were two hemispheres of plutonium and gallium. The gallium allowed the material to be hot-pressed into spherical shapes. Unlike the first two cores, however, the third one — one that would later earn the nickname “the demon core” — had a ring around the flat surfaces to contain nuclear flux during implosion. The spheres are not terribly dangerous unless they become supercritical, which would lead to a prompt critical event. Then, they would release large amounts of neutrons. The bombs, for example, would force the two halves together violently. You could also add more nuclear material or reflect neutrons back into the material.

Continue reading “Screwdrivers And Nuclear Safety: The Demon Core”

This Week In Security: It’s Con Season

It must be Blackhat/DEFCON season. Up first in the storm of named vulnerabilities, we have Downfall. The PDF has the juicy details here. It’s quite similar to the Zenbleed issue from last week, in that it abuses speculative execution to leak data via a hidden register. Unlike Zenbleed, this isn’t direct access, but using cache timing analysis to extract individual bytes using a FLUSH+RELOAD approach.

The key to the vulnerability is the gather instruction, which pulls data from multiple locations in memory, often used to run a followup instruction on multiple bytes of data at once. The gather instruction is complex, takes multiple clock cycles to execute, and uses several tricks to execute faster, including managing buffers to avoid multiple reads. In certain cases, that instruction can be interrupted before it completes, leaving the data in the cache. And this data can be speculatively accessed and the values leaked through timing analysis.

This flaw affects 6th generation Intel Core processors through 11th. Mitigations are already rolling out via a microcode update, but do carry a performance hit for gather instructions. Continue reading “This Week In Security: It’s Con Season”

The World ID Orb And The Question Of What Defines A Person

Among the daily churn of ‘Web 3.0’, blockchains and cryptocurrency messaging, there is generally very little that feels genuinely interesting or unique enough to pay attention to. The same was true for OpenAI CEO Sam Altman’s Ethereum blockchain-based Worldcoin when it was launched in 2021 while promising many of the same things as Bitcoin and others have for years. However, with the recent introduction of the World ID protocol by Tools for Humanity (TfH) – the company founded for Worldcoin by Mr. Altman – suddenly the interest of the general public was piqued.

Defined by TfH as a ‘privacy-first decentralized identity protocol’ World ID is supposed to be the end-all, be-all of authentication protocols. Part of it is an ominous-looking orb contraption that performs iris scans to enroll new participants. Not only do participants get ‘free’ Worldcoins if they sign up for a World ID enrollment this way, TfH also promises that this authentication protocol can uniquely identify any person without requiring them to submit any personal data, only requiring a scan of your irises.

Essentially, this would make World ID a unique ID for every person alive today and in the future, providing much more security while preventing identity theft. This naturally raises many questions about the feasibility of using iris recognition, as well as the potential for abuse and the impact of ocular surgery and diseases. Basically, can you reduce proof of personhood to an individual’s eyes, and should you?

Continue reading “The World ID Orb And The Question Of What Defines A Person”

Hackaday Prize 2023: LoShark, The Radio Debugger For LoRa

LoRa, the Long Range wireless protocol is pretty great for trickling data across long distances. There are some great embedded devices based around STM32, NRF52, and ESP32 microcontrollers. What’s been missing for quite a while is a device that allows for full access to a LoRa radio from a more capable CPU. The wait may be over, as there’s now the LoShark. It’s a USB key form factor, with a MIPS processor running a real Linux kernel. Cool!

The way debugging works is interesting, too. The team at SudoMaker is working on their Resonance runtime, which allows interacting with the onboard sx126x radio chip using JavaScript code. That chip can both send and receive, so this device should be capable of more than just capturing traffic. And if JavaScript isn’t your thing, the Linux system on the device means you can knock yourself out with C or C++ code. Who knows, we may even see Meshtastic running on this thing some day.

If this gets you excited, it’s already available for order for a reasonable $59.99. The LoShark ships in 433, 868, and 915 megahertz versions. It’s a really slick looking device, and maybe worth your time to check out. Enjoy!

Break Free From Proprietary Digital Radio

Digital modes are all the rage these days in amateur radio — hams are using protocols like WSPR to check propagation patterns, FT8 to get quick contacts on many bands with relatively low power, and MSK144 to quickly bounce a signal off of a meteor. There’s also digital voice, which has a number of perks over analog including improved audio quality. However, the major downside of most digital voice modes, at least those in use on UHF and VHF, is that they are proprietary with various radio brands having competing digital standards. To get above the noise a more open standard can be used instead.

The M17 standard, originally created by [Wojciech Kaczmarski] aka [SP5WWP], uses Codec 2 to convert voice into a digital format before it is broadcast over the air. Codec 2 is an open standard unlike other audio codecs. M17 also supports reflectors, which can link individual radios or entire repeaters together over the Internet. While you can make purpose-built modules that will interface with most standard radio inputs, it’s also possible to modify existing hardware to support this standard as well. The video below from [Tech Minds] shows this being done to a radio with only a few hardware modifications and the installation of a new firmware.

For anyone who has been frustrated that there’s no real universal standard for digital voice in VHF and above, M17 could be a game-changer if enough people get tired of their friends being on other proprietary digital systems. There’s plenty of supported hardware out there that most hams probably already have already, including a number of TNC devices like the Mobilinkd and the DigiRig, so it shouldn’t be too hard to get started. If you’re more into networking over radio, though, take a look at this method for sending high-bandwidth IP networking over the UHF band. Continue reading “Break Free From Proprietary Digital Radio”

DisplayPort: Taming The Altmode

The DisplayPort altmode is semi-proprietary, but it can absolutely be picked apart if we try. Last time, we found a cool appnote describing the DisplayPort altmode in detail, switched the FUSB302 into packet sniffing mode and got packet captures, learned about PD VDMs (vendor-defined messages), and successfully replayed the captured messages to switch a USB-C port into the DisplayPort altmode. Today, we will go through the seven messages that summon the DisplayPort altmode, implement them, and tie them all into a library – then, figure out the hardware we need to have DisplayPort work in the wild.

For a start, as you might have seen from the diagram, a single command can be either a request or a response. For instance, if you get a Discover Identity REQ (request), you reply to it with a Discover Identity ACK (response), adding your identity data to your response along the way. With some commands, the DP source will add some data for you to use; for most commands, your DP sink will have to provide information instead – and we’ll do just that, armed with the PDF provided and the packet captures.

We have seven commands we need to handle in order to get DisplayPort out of a compatible USB-C port – if you need a refresher on these commands, page 13 of the ST’s PDF on the DP altmode will show you the message sequence. These commands are: Discover Identity, Discover SVIDs, Discover Modes, Enter Mode, DP Status Update, DP Configure, and Attention. Out of these, the first four are already partially described in the base USB PD standard, the two DP commands afterwards are DisplayPort-altmode-specific but sufficiently described in the PDF we have, and the Attention command is from the base standard as well, mostly helpful for reporting state of the HPD pin. Let’s start with the first two! Continue reading “DisplayPort: Taming The Altmode”