This particular story on researchers successfully making yeast-free pizza dough has been making the rounds. As usual with stories written from a scientific angle, it’s worth digging into the details for some interesting bits. We took a look at the actual research paper and there are a few curious details worth sharing. Turns out that this isn’t the first method for yeast-free baking that has been developed, but it is the first method to combine leavening and baking together for a result on par with traditional bread-making processes.
Basically, a dough consisting of water, flour, and salt go into a hot autoclave (the header image shows a piece of dough as seen through the viewing window.) The autoclave pressurizes, forcing gasses into the dough in a process similar to carbonating beverages. Pressure is then released in a controlled fashion while the dough bakes and solidifies, and careful tuning of this process is what controls how the bread turns out.
With the right heat and pressure curve, researchers created a pizza whose crust was not only pleasing and tasty, but with a quality comparable to traditional methods.
How this idea came about is interesting in itself. One of the researchers developed a new method for thermosetting polyurethane, and realized that bread and polyurethane have something in common: they both require a foaming (proofing in the case of bread) and curing (baking in the case of bread) process. Performing the two processes concurrently with the correct balance yields the best product: optimized thermal insulation in the case of polyurethane, and a tasty and texturally-pleasing result in the case of pizza dough. After that, it was just a matter of experimentation to find the right balance.
The pressures (up to 6 bar) and temperatures (145° Celsius) involved are even pretty mild, relatively speaking, which could bode well for home-based pizza experimenters.
The past couple of years of the COVID pandemic have been rough in some unexpected ways, and it’s clear that our world will never be quite the same as it was beforehand. In our community, the hackerspaces are open again, and while the pandemic hasn’t gone away this year shows the promise of hosting the first major hacker camps to be held since 2019. We’re sure a number of you will be making your way to them. To give a taste of what is to come we’ve got a rare glimpse into hacker camps past.
If there’s any looming, unwritten rule of learning a programming language, it states that one must break in the syntax by printing Hello, World! in some form or another. If any such rule exists for game programming on a new microcontroller, then it is certainly that thou shalt implement Snake.
This is [__cultsauce__]’s first foray away from Arduinoville, and although they did use one to program the ATtiny85, they learned a lot along the way.
It doesn’t take much to conjure Snake with an ’85 — mostly you need a screen to play it on (an OLED in this case), some buttons to direct the snake toward the food dot, a handful of passives, and a power source.
[__cultsauce__] started by programming the microcontroller and then tested everything on a breadboard, both of which are admirable actions. Then it was time to make this plywood and cork sandwich, which gives the point-to-point solder joints some breathing room and keeps them from getting crushed. Be sure to check it out in action after the break, and grab the files from GitHub if you want to charm your own ‘tiny Snake.
The project leverages the natural language generation abilities of OpenAI’s GPT-3 to create fairytale-style content that is just coherent enough to sound natural, but not quite coherent enough to make a sensible plotline. The quasi-lucid, dreamlike result is perfect for urging listeners to imagine pleasant nonsense (thanks to Nathan W Pyle for that term) as they drift off to sleep.
We especially loved reading about the methods and challenges [Stavros] encountered while creating this project. For example, he talks about how there is more to a good-sounding narration than just pointing a text-to-speech engine at a wall of text and mashing “GO”. A good episode has things like strategic pauses, background music, and audio fades. That’s where pydub — a Python library for manipulating audio — came in handy. As for the speech, text-to-speech quality is beyond what it was even just a few years ago (and certainly leaps beyond machine-generated speech in the 80s) but it still took some work to settle on a voice that best suited the content, and the project gradually saw improvement.
The Timex Datalink was arguably the first usable smartwatch, and was worn by NASA astronauts as well as geek icons like Bill Gates. It could store alarms, reminders and phone numbers, and of course tell the time across a few dozen time zones. One of the Datalink’s main innovations was its ability to download information from your PC — either through flashing images on a CRT monitor or through a special adapter plugged into a serial port.
With CRTs thin on the ground and original serial adapters fetching ludicrous prices online, classic Datalink users today may find it hard to keep their watches in sync with their Outlook calendars. Fortunately for them, [famiclone] came up with a solution: a DIY Datalink adapter based on an Arduino. It works the same way as Timex’s serial adapter, in that it receives data through the computer’s serial port and transmits it to the watch by flashing a red LED.
Updating your watch does require the use of the original Datalink PC software, which only runs on classic operating systems like Windows 95 or 98, so you’ll need to keep a copy of such an OS running. Luckily, it has no problem with virtual machines or USB COM ports, so at least you don’t need to keep vintage PC hardware around. Then again, whipping out a 1995 Pentium laptop to update your Timex watch would make for the ultimate geek party piece.
Love classic geeky watches? Check out this featured article we did on them a few years ago. If you’re interested in using computer monitors to transmit data optically, we’ve covered a fewprojects that do just that.
We got a tip this week, and the tipster’s comments were along the lines of “this doesn’t look like it’s a finished work yet, but I think it’s pretty cool anyway”. And that was exactly right. The work in question is basically attaching a simple webcam to a CNC router and then having at it with OpenCV, and [vector76]’s application was cutting out freeform hand-drawn curves from wood. To amuse his daughter.
But there’s no apology necessary for presenting a work in progress. Unfinished hacks are awesome! They leave room for further improvement and interpretation. They are like an unfinished story, inviting the hacker to dream up their own end. At least that’s how this one worked on me.
My mind went racing — adding smart and extensible computer vision to a CNC router enables not only line tracing, but maybe smarter edge finding, broken tool detection, and who knows what else. With the software end so flexible these days, and the additional hardware demands so minimal, it’s an invitation. It’s like Pavlov ringing that bell, and I’m the dog-hacker. Or something.
So remember this when you get half done with a project, get to a workable first-stage demo, but you haven’t chased down each and every possibility. Leaving something up to other hackers’ imagination can be just as powerful. Your proof of concept doesn’t have to be the mother of all demos — sometimes just a working mouse will suffice.
This article is part of the Hackaday.com newsletter, delivered every seven days for each of the last 200+ weeks. It also includes our favorite articles from the last seven days that you can see on the web version of the newsletter.
Want this type of article to hit your inbox every Friday morning? You should sign up!
That might seem a bit like word soup to the uninitiated in the processor design world (which is admittedly relatively small) but what makes this different from VexRISC is the scale and complexity. Rather than executing one instruction at a time sequentially, it executes multiple instructions, completing them concurrently in whatever order it can handle. The VexRISC chip is a good 32-bit modular design that can run Linux. It pulls a solid 1.57 DMIPS/MHz with everything turned on. The VRoom already clocks in at mighty 6.5 DMIPS/MHz, with more performance gains. It peaks at 8 instructions every clock cycle with a dual register file and a clever committing system to keep up.
VRoom is written in System Verilog to leverage Verilator (a handy linting and simulation framework), and while there is some C that generates different files, we’d wager it is pretty run-of-the-mill compared to a TypeScript based project. VRoom currently boots Linux thanks to an AWS-FPGA instance (a Xilinx VU9P Ultrascale), though it has to be trimmed to fit. [Paul] has big plans working his way up to a server-class chip with lots of cores and a huge cache.