Meshtastic is a way to build mesh networks using LoRa that is independent of cell towers, hot spots or traditional repeaters. It stands to reason that with an SDR and GNU Radio, you could send and receive Meshtastic messages. That’s exactly what [Josh Conway] built, and you can see a video about the project, Meshtastic_SDR, below. The video is from [cemaxecuter], who puts the library through its paces.
For hardware, the video uses a Canary I as well as the WarDragon software-defined radio kit which is an Airspy R2 and a mini PC running Dragon OS — a Linux distribution aimed at SDR work — in a rugged case. GNU Radio, of course, uses flows which are really just Python modules strung together with a GUI.
If you take public transport in many of the world’s cities, your ticket will be an NFC card which you scan to gain access to the train or bus. These cards are disposable, so whatever technology they use must be astonishingly cheap. It’s one of these which [Ken Shirriff] has turned his microscope upon, a Montreal Métro ticket, and his examination of the MiFare Ultra Light it contains is well worth a read.
The cardboard surface can be stripped away from the card to reveal a plastic layer with a foil tuned circuit antenna. The chip itself is a barely-discernible dot in one corner. For those who like folksy measurements, smaller than a grain of salt. On it is an EEPROM to store its payload data, but perhaps the most interest lies in the support circuitry. As an NFC chip this has a lot of RF circuitry, as well as a charge pump to generate the extra voltages to charge the EEPROM. In both cases the use of switched capacitors plays a part in their construction, in the RF section to vary the load on the reader in order to transmit data.
He does a calculation on the cost of each chip, these are sold by the wafer with each wafer having around 100000 chips, and comes up with a cost-per-chip of about nine cents. Truly cheap as chips!
The basics of keyboard design are tried and true at this point, but there are still a few aspects yet unconquered. One of them is making your keyboards wireless. You might think it’s easy, but if you just slap a wireless-enabled microcontroller onto your board, you’ll soon be left with a dead battery. Rejoice – [Pete Johanson], creator of ZMK, tells all that you want to know about making your keyboard low-power.
In a lengthy blog post, he goes through everything that a typical keyboard consists of, and points out factor after factor that you never knew could cause a spike in power consumption. Are you using muxes or config options that will force your MCU to always stay alert? Is your voltage regulator’s quiescent current low enough, and can the same be said about other parts you’re using? Does your MCU have to work extra hard transmitting bytes because you’ve put a copper fill under its antenna? Most importantly, is the firmware you’re using designed to optimize power consumption at its core?
If you’ve ever thought about designing low-power keyboards, hell, any low-power device, you seriously should read this post – it will set you at ease by giving you a checklist of things to do, and it also links to quite a few other useful resources, like the ZMK power profiler. Perhaps, if you’re building a wireless keyboard or just creating battery-powered device, you should consider ZMK, as it sure seems to be written with energy efficiency in mind.
Want to learn more about what it takes to build a low-power device? Our 2023 Low-Power Contest attracted a wide range of entrants, and they’ve shared a flurry of methods and tricks you can use to build any sort of battery-juice-sipping gadget.
Have you ever read about something and thought, “Gee whiz! Why did I never think about that?” That was my reaction to reading about a feature commonly associated with Klipper called adaptive bed leveling or adaptive mesh leveling. Too bad I don’t typically use Klipper, but it all worked out, and I’ll show you how it might work for you.
What Is It?
Time to tram your bed!
Once a luxury, most 3D printers now come with some kind of bed level sensor. The idea is that the printer can probe the bed to determine the shape of the build plate and then adjust the build plate accordingly. So if a particular spot on the bed is 0.5 mm too high, the nozzle can rise 0.5 mm when it is in that area. There are several techniques Marlin firmware uses, including what I usually use: UBL. Some people scan the bed once and hope it won’t change much. Others will do a time-consuming scan before each print.
However, adaptive bed leveling is a bit different. The idea is that the printer only probes the area where the part is going to print. If your print bed is 235 mm x 235 mm but your part is 50 mm square, you could just probe the points under the 50 mm square.
This does several things. For a given number of points, there is less motion, so it should be faster. Also, for the same number of points, you will have a much denser mesh and, thus, a better idea of what the bed is at any given point. You could even reduce the number of points based on the size of the part you are printing.
When you think about it, it is a dead simple idea. What’s not to love? For most print jobs, you’ll have less work for the printer, faster prints, and a denser mesh. But how do you do it?
Bug reporting doesn’t usually have a lot of visuals. Not so with the visionOS bug [Ryan Pickren] found, which fills a user’s area with screeching bats after visiting a malicious website. Even better, closing the browser doesn’t get rid of them! Better still? Doesn’t need to be bats, it could be spiders. Fun!
The bug has been fixed, but here’s how it worked: the Safari browser build for visionOS allowed a malicious website to fill the user’s 3D space with animated objects without interaction or permission. The code to trigger this is remarkably succinct, and is actually a new twist on an old feature: Apple AR Quick Look, an HTML-based feature for rendering 3D augmented reality content in Safari.
How about spiders, instead?
Leveraging this old feature is what lets an untrusted website launch an arbitrary number of animated 3D objects — complete with sound — into a user’s virtual space without any interaction from the user whatsoever. The icing on the cake is that Quick Look is a separate process, so closing Safari doesn’t get rid of the pests.
Providing immersive 3D via a web browser is a valuable way to deliver interactive content on both desktops and VR headsets; a good example is the fantastic virtual BBC Micro which uses WebXR. But on the Apple Vision Pro the user is always involved and there are privacy boundaries that corral such content. Things being launched into a user’s space in an interaction-free way is certainly not intended behavior.
The final interesting bit about this bug (or loophole) was that in a way, it defied easy classification and highlights a new sort of issue. While it seems obvious from a user experience and interface perspective that a random website spawning screeching crawlies into one’s personal space is not ideal, is this a denial-of-service issue? A privilege escalation that technically isn’t? It’s certainly unexpected behavior, but that doesn’t really capture the potential psychological impact such bugs can have. Perhaps the invasion of personal space and user boundaries will become a quantifiable aspect of bugs in these new platforms. What fun.
If you’re pairing a tiny Linux computer to a few peripherals — perhaps you’re building a reasonably custom Pi-powered device — it’s rightfully tempting to use something like an STM32 for all your low-level tasks, from power management to reading keyboard events.
Now, in case you were wondering how to tie the two together, consider HID over I2C, it’s a standardized protocol with wide software and peripheral support, easily implementable and low-power. What’s more, [benedekkupper] gives you an example STM32 project with a detailed explanation on how you too can benefit from the protocol.
There are several cool things about this project. For a start, its code is generic enough that it will port across the entire STM32 lineup nicely. Just change the pin definitions as needed, compile it, flash it onto your devboard and experiment away. Need to change the descriptors? The hid-rdf library used lets you define a custom descriptor super easily, none of that building a descriptor from scratch stuff, and it even does compile-time verification of the descriptor!
For old-timers, CRTs — cathode ray tubes — were fixtures as kids sat in front of TVs watching everything from Howdy Doody to Star Trek. But there’s at least one generation that thinks TVs and computer monitors are flat. If that describes you, you might enjoy [The 8-Bit Guy’s] coverage of how CRTs work in the video below.
CRTs were heavy, took high voltage, and had a dangerous vacuum inside, so we really don’t miss them. The phosphor on the screen had a tendency to “burn in” if you showed the same image over and over. We don’t miss that either.
