Printing With Glass Fiber Filament

[ModBot] has been trying different engineering plastics for 3D printing. He recently looked at carbon fiber mixed with PET, but this time, he shows us his results with PET with glass fiber, or PET-GF. You can see how it all turned out in the video below.

The first part of the video compares the specifications, and, as you might expect, some factors are better for carbon fiber, and others are better for glass fibers. Once he gets to the printing, he covers the high temperatures needed (280-320C). He also talks about how either fiber will chew up nozzles and extruders.

Continue reading “Printing With Glass Fiber Filament”

Clockhands For Faster CPU Execution

When you design your first homebrew CPU, you probably are happy if it works and you don’t worry as much about performance. But, eventually, you’ll start trying to think about how to make things run faster. For a single CPU, the standard strategy is to execute multiple instructions at the same time. This is feasible because you can do different parts of the instructions at the same time. But like most solutions, this one comes with a new set of problems. Japanese researchers are proposing a novel way to work around some of those problems in a recent paper about a technique they call Clockhands.

Suppose you have a set of instructions like this:

LOAD A, 10
LOAD B, 20
LOAD B, 30

If you do these one at a time, you have no problem. But if you try to execute them all together, there are a variety of problems. First, the subtract has to wait for A and B to have the proper values in them. Also, the INC B may or may not execute, and unless we know the values of A and B ahead of time (which, of course, we do here), we can’t tell until run time. But the biggest problem is the subtract has to use B before B contains 30, and the increment has to use it afterward. If everything is running together, it can be hard to keep straight.

Continue reading “Clockhands For Faster CPU Execution”

Impact Of Imperfect Timekeeping On Quantum Control And Computing

In classical control theory, both open-loop and closed-loop control systems are commonly used. These systems are well understood and rather straightforward, controlling everything from washing machines to industrial equipment to the classical computing devices that make today’s society work. When trying to transfer this knowledge to the world of quantum control theory, however, many issues arise. The most pertinent ones involve closed-loop quantum control and the clocking of quantum computations. With physical limitations on the accuracy and resolution of clocks, this would set hard limits on the accuracy and speed of quantum computing.

The entire argument is covered in two letters to Physical Review Letters, by Florian Meier et al. titled Fundamental Accuracy-Resolution Trade-Off for Timekeeping Devices (Arxiv preprint), and by Jake Xuereb et al. titled Impact of Imperfect Timekeeping on Quantum Control (Arxiv preprint). The simple version is that by simply increasing the clock rate, accuracy suffers, with dephasing and other issues becoming more frequent.

Solving the riddle of closed-loop quantum control theory is a hard one, as noted by Daoyi Dong and Ian R Peterson in 2011. In their paper titled Quantum control theory and applications: A survey, the most fundamental problem with such a closed-loop quantum control system lies with aspects such as the uncertainty principle, which limits the accuracy with which properties of the system can be known.

In this regard, an accurately clocked open-loop system could work better, except that here we run into other fundamental issues. Even though this shouldn’t phase us, as with time solutions may be found to the timekeeping and other issues, it’s nonetheless part of the uncertainties that keep causing waves in quantum physics.

Top image: Impact of timekeeping error on quantum gate fidelity & independent clock dephasing (Xuereb et al., 2023)

Nanobots Self Replicate

Hey, what if you could have a factory that makes robots that is run by… robots? This is hardly an original thought, but we are a long way from having an assembly line of C3POs self-replicating. On the other hand, animals — including humans — self-replicate all the time using DNA. Now, scientists are making tiny nanorobots from DNA that can assemble more DNA, including copies of themselves.

Assembling 3D structures with DNA has deep implications. For example, it might be possible to build drugs in situ, delivering powerful toxins only to cancer cells. Another example would be putting DNA factories in diabetes patients to manufacture the insulin they can’t.

Continue reading “Nanobots Self Replicate”

How The First IPod Was Blown Wide Open

If someone makes a device, someone else will want to break it open and run their own software on it. When the original manufacturer is Apple this is never made easy, and as [Daniel Stenberg] reminds us in the case of one of the earlier iPod models it required an unusual approach.

In short, an HTML file was found which triggered a reboot, meaning a buffer overrun had been found in the firmware. After much experimenting, the memory location was found which would flash the backlight, and from there a piece of ARM code could be injected which would dump the firmware very slowly bitwise by flashing the light. Enough code could be extracted to find the address of the USB serial port, allowing new code to be made which dumped the firmware via USB. We remember the earliest models using FireWire instead of USB, so perhaps we can zero in on the 3rd or 4th generation. From there enough could be deduced to run the Rockbox music player firmware. We remember seeing friends doing this back in the day, something which was for a while the height of open-source coolness.

Fast forward twenty years or so, and we’re still covering people chipping away at Apple’s defenses. We don’t know whether a first-generation iPod could run Doom, but we know Rockbox was capable of it on other players.

Pico Makes A So-So Keyboard Neat-O

When someone gives you a crappy little toy keyboard, what can you do? Sadly plunk on the thing one note at a time? Well yes, but that’s not going to get you on Hackaday. Do what [Turi] did and give that thing a complete overhaul.

[Turi] threw away the original controller board, keeping only the keys, buttons, case, speaker, and a little bit of the original powder yellow enclosure. The Picophonica’s new brain is, you guessed it, a Raspberry Pi Pico. This enables [Turi] to use [Ryo Ishigaki]’s pico_synth_ex synthesizer and introduce MIDI out via USB-C.

The new engine does things that little keyboard could never have dreamed of originally, especially considering it wasn’t even polyphonic. Those fourteen white buttons now control things like sustain, cutoff, LFO rate, decay, and so on. Now it sounds great!

Be sure to check out the brief build video after the break. Excluding drums, the soundtrack was made entirely on the Picophonica.

Of course, Picos aren’t just good for musical keyboards. Use one to convert an old proprietary keyboard to PS/2, or create your own.

Continue reading “Pico Makes A So-So Keyboard Neat-O”

Degrees Of Freedom, But For Whom?

Opening up this week’s podcast, I told Kristina about my saga repairing our German toilet valve. I’m American, and although I’ve lived here over a decade, it’s still surprising how things can be subtly different from how they worked back home.

But what was amazing about this device was that it had a provision for fine adjustment, and to some extent relied on this adjustment to function. Short version: a lever mechanism provides mechanical advantage to push a stopper against the end of a pipe to block the water flow, and getting the throw of this mechanism properly adjusted so that the floater put maximum pressure against the pipe required fine-tuning with a screw. But it also required understanding the entire mechanism to adjust it.

Which makes me wonder how many plumbers out there actually take the time to get that right. Are there explicit instructions in the manual? Does every German plumber learn this in school? I was entirely happy to have found the adjustment screw after I spent 15 minutes trying to understand the mechanism, because it did just the trick. But is this everyone’s experience?

I often think about this when writing code, or making projects that other people are likely to use. Who is the audience? Is it people who are willing to take the time to understand the system? Then you can offer them a screw to turn, and they’ll appreciate it. But if it’s an audience that just doesn’t want to be bothered, the extra complexity is just as likely to cause confusion and frustration.