What do you mean, the temporary breadboard setup went into production? (Credit: [Gregulations], YouTube)Among all the amazing technologies that were promised to us, there is one that is much more egregious than the lack of flying cars and real hovering hoverboards: the lack of fully automated breakfast-maker machines. Instead we find ourselves handling the same dumb appliances each morning as we make a healthy breakfast that we then have time to wolf down before rushing out of the door to still be a few minutes late for work. When [Greg] researched machines that could automatically prepare breakfast, he came up empty, which led him down the rabbit hole of the Autochef-9000.
Although often featured in movies – ranging from Back to the Future to Wallace and Gromit – the contraptions in those are rarely practical, and real-life attempts often suffer the problem of feature creep as they have to handle too many ingredients and operations. This is where [Greg] found redemption in the simplicity of a proper British breakfast: beans, toast, sausages (sossys), and eggs. Months of CAD, welding, breadboarding, and writing Arduino code later, he made a machine that can open a can of beans, toast bread, boil eggs, fry up sausages, and deposit it all on a plate, all ready for that morning breakfast first thing when you stroll into the kitchen.
For months, there has been a rising fear that we may have to say farewell to the Voyager 1 spacecraft after it began to send back garbled data. Now, in a sudden twist, Voyager 1 sent back a read-out of the Flight Data Subsystem (FDS) memory after a “poke” command, which both gives some hope that the spacecraft is in a better condition than feared while also allows engineers to dig through the returned memory read-out for clues. Although this data was not sent in the format that the FDS is supposed to use when it’s working correctly, it’s nevertheless readable.
It was previously suspected that the issue lay with the telemetry modulation unit (TMU), but has since been nailed down to the FDS itself. This comes after NASA engineers have been updating the firmware on both spacecraft to extend their lifespan, but it’s too early to consider this as a possible reason. Now, as a result of the “poke” instruction – which commands the computer to try different sequences in its firmware in case part of it has been corrupted – engineers can compare it to previous downloads to hopefully figure out the cause behind the FDS problems and a possible solution.
Inspired by this news of the decoded memory download, Nadia Drake – daughter of Frank Drake – wrote about how it affects not only the engineers who have worked on the Voyager mission for the past decades but also her own thoughts about the two Voyager spacecraft. Not only do they form a lasting reminder of her father and so many of his colleagues, but the silence that would follow if we can no longer communicate with these spacecraft would be profound. Still, this new hope is better than the earlier news about this plucky little spaceship.
Inverting the earlier exponentiation to reduce floating point arithmetic error. (Credit: exozy)
An unfortunate reality of trying to represent continuous real numbers in a fixed space (e.g. with a limited number of bits) is that this comes with an inevitable loss of both precision and accuracy. Although floating point arithmetic standards – like the commonly used IEEE 754 – seek to minimize this error, it’s inevitable that across the range of a floating point variable loss of precision occurs. This is what [exozy] demonstrates, by showing just how big the error can get when performing a simple division of the exponential of an input value by the original value. This results in an amazing error of over 10%, which leads to the question of how to best fix this.
Obviously, if you have the option, you can simply increase the precision of the floating point variable, from 32-bit to 64- or even 256-bit, but this only gets you so far. The solution which [exozy] shows here involves using redundant computation by inverting the result of ex. In a demonstration using Python code (which uses IEEE 754 double precision internally), this almost eradicates the error. Other than proving that floating point arithmetic is cursed, this also raises the question of why this works.
During the 1970s many different computer architectures were being developed, many of them focused on making computer systems easier and more effective to use. The Flex Machine developed at the UK Ministry of Defence’s Royal Signals and Radar Establishment (RSRE) was one of them, falling in the category of Capability Architectures. These architectures required hardware with programmable microcode, which required either custom hardware, or computer systems like the Xerox Alto-inspired ICL PERQ (pictured). What’s interesting about Flex is that it didn’t just remain in the 1980s as a quaint footnote, but as detailed by [Martin C. Atkins] – who worked on the system – evolved into the Ten15 system, which later got renamed to TenDRA.
Capability architectures have a long history – including the Intel iAPX 432 and more recent implementations – but they all have in common is that they effectively implement an object-based memory architecture, rather than the low-level, flat memory space that we usually see with computer systems. These object-based capabilities, as they were termed, provides a level of memory protection and security that would be hard to implement otherwise. The book Capability-Based Computer Systems by [Henry M. Levy] forms a good introduction here.
Screenshot of the Zygo white light interferometry microscope software. (Credit: Huygens Optics)
White light interferometry (WLI) is a contact-free optical method for measuring surface height. It uses the phase difference between the light reflected off a reference mirror and the target sample to calculate the height profile of the sample’s surface. As complex as this sounds, it doesn’t take expensive hardware to build a WLI microscope, as [Huygen Optics] explains in a detailed introductory video on the topic. At its core you need a source of white light (e.g. a white LED), with a way to focus the light so as to get a spatially coherent light source, like aluminium foil with a pin hole and a lens.
This light source then targets a beam splitter, which splits the light into one beam that targets the sample, and one that targets the reference mirror. When both beams are reflected and return to the beam splitter, part of the reflected light from either side ends up at the camera, which captures the result of the reference and sample beams after their interference (i.e. combination of the amplitudes). This creates a Michelson interferometer, which is simple, but quite low resolution. For the demonstrated Zygo Newview 100 WLI microscope this is the first objective used, followed by a more recent innovation: the Mirau interferometer, which integrates the reference mirror in such a manner that much higher resolutions are possible, down to a few µm.
Wristwatches come in many shapes, sizes, and types, but most still have at least one thing in common: they feature a battery that needs to be swapped or recharged somewhere been every other day and every few years. A rare few integrate a solar panel that keeps the internal battery at least somewhat topped up, as environmental light permits.
This “Perpetual” wristwatch designed by [Serhii Trush] aims to keep digitally ticking along using nothing but the integrated photodiodes, a rechargeable LIR2430 cell, and a power-sipping face that uses one LED for each hour of the day.
The face of the perpetual wristwatch. (Credit: Serhii Trush)
The wristwatch’s operation is demonstrated in the linked video (in Ukrainian, auto-generated subtitles available): to read out the current time, the button in the center is pressed, which first shows the hour, then the minutes (in 5 minute intervals).
After this the ATtiny13 MCU goes back to sleep, briefly waking up every 0.5 seconds to update the time, which explains why there’s no RTC crystal. The 12 BPW34S photodiodes are enough to provide 2 mA at 0.5 V in full sunlight, which together keep the LIR2430 cell charged via a Zener diode.
As far as minimalistic yet practical designs go, this one is pretty hard to beat. If you wish to make your own, all of the design files and firmware are provided on the GitHub page.
Although we certainly do like the exposed components, it would be interesting to see this technique paired with the PCB watch face we covered recently.
The ball driven Geneva drives that move the marrionette. (Credit: Karakuri channel, YouTube)
Over the years we have seen many marble machines, but this one on the [Karakuri channel] (hit CC for subtitles) on YouTube is somewhat special, as it uses Geneva drives to turn the motion of the steel balls going around the circuit into random movement of a marionette. The Geneva drive type of gear mechanism normally converts a constant rotary motion into intermittent rotary motion by having a singular pin on the first wheel drive the second wheel. In the demonstrated mechanism, however, the pin is replaced by the steel balls, which are only intermittently and randomly present because of how each steel ball picks one of four paths, one towards each Geneva drive.
As a result of this, the motion of the marionette’s appendages – attached to the red wheel – is random. The only powered element of the (mostly 3D printed) system is the drive mechanism that carries the steel balls up again and keeps the primary wheels on the Geneva drives rotating. We have to give the creator pops for what is both an interesting art piece and a demonstration of how to creatively use this somewhat unusual gear mechanism to introduce randomness without a lot of complexity.
