TechyMagThings

Quick Share is a useful tool for flipping files between Android smart phones in a fuss-free wireless manner. [unrealJune] has now implemented the feature on Kindle devices.

You’ll need a jailbroken Kindle to use this, which is running the Kindle Unified Application Launcher and KOReader as well. You’ll also want SSH access, and a machine that has Go and Docker for you to build the project. [unrealJune] steps through the steps to compile and install the Quick Share plugin to KOReader, as well as explaining how it works. Notably, it’s receive only—so you can spit files onto the Kindle, but you can’t send them from the Kindle to other devices. The Kindle will also automatically accept files, which is worth noting if you’re security conscious. If there’s no network, the Kindle is also able to appear as its own AP if needed.

Think of this as a nifty convenience if you find yourself regularly trying to truck files on to your jailbroken Kindle. It’s also a neat to see a Quick Share implementation from the open source world. Between-device sharing still sucks, as we’ve discussed before, but there are at least attempts being made to make it better. That’s something!

After the little Mars helicopter Ingenuity blew everyone away with its performance, it was clear that a future Mars mission should involve more helicopters like it, with even more capabilities. The main proposal here is NASA’s SkyFall mission which would involve three autonomous helicopters, capable of searching for resources like water. To this end they would need a ground-penetrating radar system, with the antenna somehow folding away for landings, an idea that JPL is currently testing.

The SkyFall mission is currently penciled in to commence in 2028, following which it will be deployed from the Space Reactor-1 fission reactor-powered spacecraft based around elements of the now discarded Lunar Gateway space station. This obviously poses some uncertainties around when and if this mission will actually take place, but that doesn’t prevent JPL engineers from solving issues with these SkyFall helicopters.

As the antenna for the ground-penetrating radar extends beyond the landing legs, it was crucial that said antenna was flexible enough to simply fold in on itself like fabric. For this they used an existing flexible antenna design called Vivaldi, which was downscaled for the helicopters and subsequently tested to see how many simulated Mars landings it would be able to resist, as well as the effect of the cold nights and warm days.

We’re looking forward to seeing these SkyFall helicopters zip over the Martian surface. Maybe they can even swing by Ingenuity while they’re in the neighborhood.

[Ayushmaan] states up front that most of his free time is spent “building things that probably didn’t need to exist”. Well, this one might be an anomaly, because it seems pretty useful to us.

HYDR8, as it says on the tin, is a wearable that knows when it’s time to hydrate. The impetus for this one was something we all chase: the flow state. [Ayushmaan] would sit down, get deep into work, and look up hours later to to find that he had a headache and a full water bottle. Phone reminders were soon swiped away in annoyance.

This wearable is based on a XIAO ESP32-C3. It reads heart rate, oxygenation, skin temperature, and both the ambient temperature and humidity. It also learns your personal resting numbers range.

Taking all of this into consideration, it generates a heat/hydration stress score between 0-100. The thing is, HYDR8 tells you specifically what to do; sometimes it’s ‘drink water’ and other times, it’s ‘find shade’.

The wearable itself, while somewhat chunky, is pretty simple: it only shows the time and a message when it matters. The ESP32 hosts a full dashboard on your phone.

Keep in mind that this is not a medical device, it’s an experiment, a prototype. It can’t measure how hydrated you are. Instead, it measure hydration stress.

If you don’t want to wear anything, here’s a smart straw that uses a tiny turbine flowmeter and a Hall effect sensor to record the volume sipped, and detect whether the sipper is low on fluids. And if you find yourself under the hot lights of a wet bulb event, here’s how to survive it.

Your desk or bench is a work area, so why not make it look the part? That’s the idea behind the miniature blinking traffic barrels that [Glen Akins] recently put together. Of course, just a single blinking light doesn’t really sell the idea of a busy construction zone, so he spent a somewhat surprising amount of time and effort optimizing the design for small-scale production.

The end result is a fascinating write-up that dives into the design decisions [Glen] made. Every aspect of this project, from the overhang of the “handle” on the 3D printed barrel to the number of passive components on the PCB was carefully considered. Critics may say [Glen] put too much thought into something that didn’t need to be so complex, but projects like these are an excellent way to keep your skills sharp — there’s no such thing as practicing too much.

Starting with the design of the barrel itself, we appreciate that [Glen] kept the capabilities of his desktop 3D printer in mind. By breaking the design up into multiple pieces and avoiding overly steep angles, he produced a design that prints cleanly without the need for support material. His step-by-step documentation and screenshots also serve as a great introduction to designing parts in Fusion if that’s something you’re interested in.

From there, things switch over to the electronics. Some in the audience will bemoan that he’s using a PIC12F1612 microcontroller to blink a single LED instead of a 555, but [Glen] brought the receipts on this one. Not only does the PIC offer more flexibility in terms of getting the blinking to look the way he wants, but it requires fewer passive components on the board and is considerably more energy efficient than the iconic timer IC. Even if you ignore all the other advantages, he calculates that going with a 555 would have cut the battery life of the finished product by approximately 15%.

This is one of those projects that’s difficult to summarize in such a terse format, as every time you think the write-up must be about over it takes a new turn on you. We were mildly bemused when the second iteration of the PCB popped up, but by the time he introduced the custom programming adapter board, we knew [Glen] wasn’t messing around.

Unsurprisingly, this isn’t the first time we’ve seen [Glen]’s handiwork. You may recall seeing his RP2040-powered sound board earlier this year, but his name has been popping up on these pages for more than a decade now.

Link shorteners have been a staple of the online world for over two decades now, but they’ve got some issues– for one thing, it’s totally non-transparent where the link actually goes, leaving you open to all sorts of shenanigans, of which RickRolling is probably the best case. For two, your traffic is going through an external service who may have their own nefarious intent. [PortalRunner] had an idea: don’t shorten the link, but compress it.

You see, a traditional URL shortener like tinyurl just generates a random code and associates that with your original link in its database. That’s fine, but you’re relying on a third party database. The alternative is to take the URL, encode it in some way, and apply some compression algorithm to the data. If the encoding and compression are open-source– which [Portal ]’s absolutely are— then you can check yourself before following the link, and/or self-host the whole thing for piece of mind. As a bonus [Portal]’s Ha.mr– that’s pronounced Hammer– also gives you a QR code optimized for easy scanning. QR codes have a specific alphanumeric character set built in, and it isn’t the full UTF-8– if you naively use random text, you’re in byte mode, which needs a lot more QR real estate. Or inverting that, the fewer bits it has to store, the easier a qr code is to scan at the same size. The text version of the compressed links can use UTF-8– including emoticons– but they don’t have to.

The whole project has a “why isn’t everyone doing it this way” vibe about it. We’d probably want to self-host this if we were using it seriously– [Portal] put this together on a lark and makes no promises it will be online forever–but again, this is open source, so we can. [Portal] is using normal compression algorithms here, but if you really want to squeeze text, use a neural net. 

When it comes to 3D printing in the FDM world, you can go a long way just relying on standard settings that ship with your 3D printer and/or slicer. If you want to push the limits, though, it pays to better understand the hardware and materials you’re working with to know what you can get away with. To that end, [Robert Samples] put together the MeltCalc database to help. 

The purpose of MeltCalc is simple—it collates data on hot ends and materials regarding factors like maximum flow rate, print speeds, and heater requirements. If you’re wondering whether a given hot end can flow a given filament at a given rate, for example, this tool is a great place to start. It features 64 different hot ends and 36 polymers typically used in the 3D printing world, and can spit out maximum flow rates and print speed estimations even accounting for fancy tech like Core Heating Technology (CHT) nozzles. It’s all based on thermodynamic modelling which [Robert] put together based on his experience as a chemist who works with polymers. His aim was to provide a tool with realistic flow rates for hot ends, so that end users don’t have to just rely on often-optimistic marketing numbers.

For those eager to dive deeper into the code and modelling, the project source is available on Github. We’ve featured all kinds of other useful hacks in this space lately, too, like our recent look at how to achieve wave overhangs. If you’ve got your own nifty 3D printing tools in the works, don’t hesitate to notify the tipsline.

If you are a regular reader, then the odds are you have taken apart an electronic gadget, either for a fix, or simply because your curiosity got the better of you. Once inside, it’s all but impossible to help yourself from doing at least a little reverse engineering. That’s what happened when [PRBS23] took a look inside a Gravity 800 Grill for a simple wire fix. But one thing led to the next, and now open source firmware for the grill is freely available!

The first order of business in creating the firmware is reverse engineering the original controller. Opening it up immediately reveals an ESP-32 and a well-labeled programming port. The rest of the control board is equally simple, including connectors for four thermistor temperature sensors, lid open/close switch, fan driver, 16 segment LCD, piezo buzzer, and some physical inputs.

The thermistor along with the physical inputs are connected to a 16 pin chip, interfacing with the MCU over a 9600 baud UART connection. [PRBS23] cannot determine an ADC chip meeting these specifications, so the most likely answer is a cheap MCU programmed to act as a simple analog fronted.

The neatly labeled programming header is used to quite easily dump the firmware with the espflash utility. Analyzing this dump reveals a rather strange ADC correction function used by the original firmware. The necessity and overall utility of this function remains unclear, as it only corrects by a maximum of two or three degrees Fahrenheit.

Most of the other features ended up being at least somewhat easier. The CS1621 segmented display driver is reasonably well documented with datasheets making its implementation far easier. Likewise, the other odds and ends were implemented in a far more normal manner compared to the thermistors.

All this reverse engineering work got tied together into a neat little firmware package. It comes with over the air updates PID controlled temperature, and a real-time web interface. This also isn’t the first time we have seen an IoT device liberated from proprietary firmware, and this remains one of our favorite uses of reverse engineering!