This week Jonathan, Doc, and Aaron chat about Open Source AI, advertisements, and where we’re at in the bubble roller coaster!
Continue reading “FLOSS Weekly Episode 844: Simulated Word-of-Mouth”
Homebrew Tire Pressure Monitoring System
When [upir] saw that you could buy tire valve stem caps that read pressure electronically, he decided to roll his own Tire Pressure Monitoring System (TPMS) like the one found on modern cars. An ESP32 and an OLED display read the pressure values. He didn’t have a car tire on his workbench though, so he had to improvise there.
Of course, a real TPMS sensor goes inside the tire, but screwing them on the valve stem is much easier to deal with. The sensors use Bluetooth Low Energy and take tiny batteries. In theory, you’re supposed to connect to them to your phone, although two different apps failed to find the sensors. Even a BLE scanner app wouldn’t pick them up. Turns out — and this makes sense — the sensors don’t send data if there’s no pressure on them, so as not to run down the batteries. Putting pressure on them made them pop up on the scanner.
The Android Bluetooth Connection
Suppose someone came to talk to you and said, “I need your help. I have a Raspberry Pi-based robot and I want to develop a custom Android app to control it.” If you are like me, you’ll think about having to get the Android developer tools updated, and you’ll wonder if you remember exactly how to sign a manifest. Not an appealing thought. Sure, you can buy things off the shelf that make it easier, but then it isn’t custom, and you have to accept how it works. But it turns out that for simple things, you can use an old Google Labs project that is, surprisingly, still active and works well: MIT’s App Inventor — which, unfortunately, should have the acronym AI, but I’ll just call it Inventor to avoid confusion.
What’s Inventor? It lives in your browser. You lay out a fake phone screen using drag and drop, much like you’d use QT Designer or Visual Basic. You can switch views and attach actions using a block language sort of like Scratch. You can debug in an emulator or on your live phone wirelessly. Then, when you are ready, you can drop an APK file ready for people to download. Do you prefer an iPhone? There’s some support for it, although that’s not as mature. In particular, it appears that you can’t easily share an iPhone app with others.
Is it perfect? No, there are some quirks. But it works well and, with a little patience, can make amazingly good apps. Are they as efficient as some handcrafted masterpiece? Probably not. Does it matter? Probably not. I think it gets a bad rep because of the colorful blocks. Surely it’s made for kids. Well, honestly, it is. But it does a fine job, and just like TinkerCad or Lego, it is simple enough for kids, but you can use it to do some pretty amazing things.
Lynx-R1 Headset Makers Release 6DoF SLAM Solution As Open Source
Some readers may recall the Lynx-R1 headset — it was conceived as an Android virtual reality (VR) and mixed reality (MR) headset with built-in hand tracking, designed to be open where others were closed, allowing developers and users access to inner workings in defiance of walled gardens. It looked very promising, with features rivaling (or surpassing) those of its contemporaries.
Founder [Stan Larroque] recently announced that Lynx’s 6DoF SLAM (simultaneous location and mapping) solution has been released as open source. ORB-SLAM3, modified for Android-based hardware (GitHub repository), takes in camera images and outputs a 6DoF pose, and does so effectively in real-time. The repository contains some added details as well as a demo application that can run on the Lynx-R1 headset.
As a headset the Lynx-R1 had a number of intriguing elements. The unusual optics, the flip-up design, and built-in hand tracking were impressive for its time, as was the high-quality mixed reality pass-through. That last feature refers to the headset using its external cameras as inputs to let the user see the real world, but with the ability to have virtual elements displayed and apparently anchored to real-world locations. Doing this depends heavily on the headset being able to track its position in the real world with both high accuracy and low latency, and this is what ORB-SLAM3 provides.
A successful crowdfunding campaign for the Lynx-R1 in 2021 showed that a significant number of people were on board with what Lynx was offering, but developing brand new consumer hardware is a challenging road for many reasons unrelated to developing the actual thing. There was a hands-on at a trade show in 2021 and units were originally intended to ship out in 2022, but sadly that didn’t happen. Units still occasionally trickle out to backers and pre-orders according to the unofficial Discord, but it’s safe to say things didn’t really go as planned for the R1.
It remains a genuinely noteworthy piece of hardware, especially considering it was not a product of one of the tech giants. If we manage to get our hands on one of them, we’ll certainly give you a good look at it.
A Tool-changing 3D Printer For The Masses
Modern multi-material printers certainly have their advantages, but all that purging has a way to add up to oodles of waste. Tool-changing printers offer a way to do multi-material prints without the purge waste, but at the cost of complexity. Plastic’s cheap, though, so the logic has been that you could never save enough on materials cost to make up for the added capital cost of a tool-changer — that is, until now.
Currently active on Kickstarter, the Snapmaker U1 promises to change that equation. [Albert] got his hands on a pre-production prototype for a review on 247Printing, and what we see looks promising.
The printer features the ubiquitous 235 mm x 235 mm bed size — pretty much the standard for a printer these days, but quite a lot smaller than the bed of what’s arguably the machine’s closest competition, the tool-changing Prusa XL. On the other hand, at under one thousand US dollars, it’s one quarter the price of Prusa’s top of the line offering. Compared to the XL, it’s faster in every operation, from heating the bed and nozzle to actual printing and even head swapping. That said, as you’d expect from Prusa, the XL comes dialed-in for perfect prints in a way that Snapmaker doesn’t manage — particularly for TPU. You’re also limited to four tool heads, compared to the five supported by the Prusa XL.
The U1 is also faster in multi-material than its price-equivalent competitors from Bambu Lab, up to two to three times shorter print times, depending on the print. It’s worth noting that the actual print speed is comparable, but the Snapmaker takes the lead when you factor in all the time wasted purging and changing filaments.
The assisted spool loading on the sides of the machine uses RFID tags to automatically track the colour and material of Snapmaker filament. That feature seems to take a certain inspiration from the Bambu Labs Mini-AMS, but it is an area [Albert] identifies as needing particular attention from Snapmaker. In the beta configuration he got his hands on, it only loads filament about 50% of the time. One can only imagine the final production models will do better than that!
In spite of that, [Albert] says he’s backing the Kickstarter. Given Snapmaker is an established company — we featured an earlier Snapmaker CNC/Printer/Laser combo machine back in 2021— that’s less of a risk than it could be.
Continue reading “A Tool-changing 3D Printer For The Masses”
Simulating The Commodore PET
Over on his blog our hacker [cpt_tom] shows us how to simulate the hardware for a Commodore PET. Two of them in fact, one with static RAM and the other with dynamic RAM.
This project is serious business. The simulation environment used is Digital. Digital is a digital logic designer and circuit simulator designed for educational purposes. It’s a Java program that runs under the JVM. It deals in .dig files which are XML files that represent the details of the simulated hardware components. You don’t need to write the XML files by hand, there is a GUI for that. Continue reading “Simulating The Commodore PET”
Google Will Require Developer Verification Even For Sideloading
Do you like writing software for Android, perhaps even sideload the occasional APK onto your Android device? In that case some big changes are heading your way, with Google announcing that they will soon require developer verification for all applications installed on certified Android devices – meaning basically every mainstream device. Those of us who have distributed Android apps via the Google app store will have noticed this change already, with developer verification in the form of sending in a scan of your government ID now mandatory, along with providing your contact information.
What this latest change thus effectively seems to imply is that workarounds like sideloading or using alternative app stores, like F-Droid, will no longer suffice to escape these verification demands. According to the Google blog post, these changes will be trialed starting in October of 2025, with developer verification becoming ‘available’ to all developers in March of 2026, followed by Google-blessed Android devices in Brazil, Indonesia, Thailand and Singapore becoming the first to require this verification starting in September of 2026.
Google expects that this system will be rolled out globally starting in 2027, meaning that every Google-blessed Android device will maintain a whitelist of ‘verified developers’, not unlike the locked-down Apple mobile ecosystem. Although Google’s claim is that this is for ‘security’, it does not prevent the regular practice of scammers buying up existing – verified – developer accounts, nor does it harden Android against unscrupulous apps. More likely is that this will wipe out Android as an actual alternative to Apple’s mobile OS offerings, especially for the hobbyist and open source developer.
