Power Supplies Without Transformers

For one-off projects or prototyping, it’s not too hard to find a wall wart or power supply to send a few joules of energy from the wall outlet to your circuit. Most of these power supplies use a transformer to step down the voltage to a more usable level and also to provide some galvanic isolation to the low voltage circuit. But for circuits where weight, volume, or cost are a major concern, a transformer may be omitted in the circuit design in favor of some sort of transformerless power supply.

While power supplies with this design do have many advantages, some care needs to be taken with regard to safety. The guide outlines four designs of increasing complexity which first puts out a basic transformerless power supply, using a series capacitor to limit current. To bring the voltage to an acceptable level, a recognizable bridge rectifier is paired with a capacitor as well as a zener diode. The second circuit presented adds voltage stabilization using a transistor and 78XX regulator. From there, zero-crossing detection is added to limit inrush surge currents, and the final design uses the venerable 555 timer to build a switching power supply.

Although it is noted several times throughout the guide, we’ll still point out here that transformerless designs like these introduce several safety issues since a mistake or fault can lead to the circuit being exposed to the mains voltage. However, with proper care and design it’s possible to make use of these designs to build more effective power supplies that can be safe to use for powering whatever circuit might energy but might not require the cost or weight of a transformer. For more on the theory of these interesting circuits and a few examples of where they are often found, check out the shocking truth about transformerless power supplies.

Thanks to [Stephen] for the tip!

Retrotechtacular: How Communism Made Televisions

For those of us who lived through the Cold War, there’s still an air of mystery as to what it was like on the Communist side. As Uncle Sam’s F-111s cruised slowly in to land above our heads in our sleepy Oxfordshire village it was at the same time very real and immediate, yet also distant. Other than being told how fortunate we were to be capitalists while those on the communist side lived lives of mindless drudgery under their authoritarian boot heel, we knew nothing of the people on the other side of the Wall, and God knows what they were told about us. It’s thus interesting on more than one level to find a promotional film from the mid 1970s showcasing VEB Fernsehgerätewerk Stassfurt (German, Anglophones will need to enable subtitle translation), the factory which produced televisions for East Germans. It provides a pretty comprehensive look at how a 1970s TV set was made, gives us a gateway into the East German consumer electronics business as a whole, and a chance to see how the East Germany preferred to see itself.

Black and white photograph of a display of televisions displaying a DDR Deutsche Frensehfunk logo, with an attendant adjusting one of the sets.
The RFT range of televisions in the Städtisches Kaufhaus exhibition center for the 1968 Leipzig Spring Fair. Bundesarchiv, CC-BY-SA 3.0

The sets in question are not too dissimilar to those you would have found from comparable west European manufacturers in the same period, though maybe a few things such as the use of a tube output stage and the lack of integrated circuits hints at their being a few years behind the latest from the likes of Philips or ITT by 1975. The circuit boards are assembled onto a metal chassis which would have probably been “live” as the set would have derived its power supply by rectifying the mains directly, and we follow the production chain as they are thoroughly checked, aligned, and tested. This plant produces both colour and back-and-white receivers, and since most of what we see appears to be from the black-and-white production we’re guessing that here’s the main difference between East and West’s TV consumers in the mid ’70s.

The film is at pains to talk about the factory as a part of the idealised community of a socialist state, and we’re given a tour of the workers’ facilities to a backdrop of some choice pieces of music. References to the collective and some of the Communist apparatus abound, and finally we’re shown the factory’s Order of Karl Marx. As far as it goes then we Westerners finally get to see the lives of each genosse, but only through an authorised lens. Continue reading “Retrotechtacular: How Communism Made Televisions”

Hackaday Podcast 238: Vibrating Bowl Feeders, Open Sourcery, Learning To Love Layer Lines

Elliot Williams and Tom Nardi start this week’s episode off with some deep space news, as NASA’s OSIRIS-REx returns home with a sample it snapped up from asteroid Bennu back in 2020. From there, discussion moves on to magical part sorting, open source (eventually…) plastic recycling, and the preposterously complex method newer Apple laptops use to determine if their lid is closed. They’ll also talk about the changing perceptions of 3D printed parts, a new battery tech that probably won’t change the world, and a clock that can make it seem like your nights are getting longer and longer. Stick around until the end to hear about the glory days of children’s architecture books, and the origins of the humble microwave oven.

Check out the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!

Go ahead and download it!

Continue reading “Hackaday Podcast 238: Vibrating Bowl Feeders, Open Sourcery, Learning To Love Layer Lines”

10-Foot High 3D Printer Based On Ender 3

There are two main ways to 3D print large things. You can either make lots of small 3D prints and stick them together, or you can use a larger 3D printer. [Emily the Engineer] went the latter route by making her Ender 3 a full 10 feet tall.

The best Doug Dimmadome hat we’ve seen in a while, printed on the 10-foot Ender 3. If you’re unfamiliar, Doug Dimmadome is the owner of the Dimmsdale Dimmadome.

The Ender 3’s modular construction made this feat straightforward in the early steps. The printer was simply disassembled, with longer aluminium extrusions bolted in their place. New wheels were resin printed via Onshape to to run along the new extrusions, which were of a slightly different profile to the original parts. Wiring was also a hurdle, with the 10-foot printer requiring a lot longer cables than the basic Ender 3.

An early attempt to make the Z-axis work with a very long threaded rod failed. Instead, a belt-driven setup was subbed in, based on existing work to convert Ender 3s to belt drive. With a firmware mod and some wiring snarls fixed, the printer was ready to try its first high print. Amazingly, the printer managed to complete a print at full height, albeit the shaking of the tall narrow print lead to some print quality issues. The frame and base were then expanded and some struts installed to add stability, so that the printer could create taller parts with decent quality.

While few of us would need a 10-foot high Ender 3, it’s easy to see the value in expanding your printer’s build volume with some easy mods. [Emily] just took it to the extreme, and that’s to be applauded. Video after the break.

Continue reading “10-Foot High 3D Printer Based On Ender 3”

This Week In Security: Magic Packets, GPU.zip, And Enter The Sandman

Leading out the news this week is a report of “BlackTech”, an Advanced Persistent Threat (APT) group that appears to be based out of China, that has been installing malicious firmware on routers around the world. This firmware has been found primarily on Cisco devices, and Cisco has released a statement clarifying their complete innocence and lack of liability in the matter.

It seems that this attack only works on older Cisco routers, and the pattern is to log in with stolen or guessed credentials, revert the firmware to a yet older version, and then replace it with a malicious boot image. But the real fun here is the “magic packets”, a TCP or UDP packet filled with random data that triggers an action, like enabling that SSH backdoor service. That idea sounds remarkable similar to Fwknop, a project I worked on many years ago. It would be sort of surreal to find some of my code show up in an APT.

Don’t Look Now, But Is Your GPU Leaking Pixels

There’s a bit debate on who’s fault this one is, as well as how practical of an attack it is, but the idea is certainly interesting. Compression has some interesting system side effects, and it’s possible for a program with access to some system analytics to work out the state of that compression. The first quirk being leveraged here is that GPU accelerated applications like a web browser use compression to stream the screen view from the CPU to the GPU. But normally, that’s way too many pixels and colors to try to sort out just by watching the CPU and ram power usage.

And that brings us to the second quirk, that in Chrome, one web page can load a second in an iframe, and then render CSS filters on top of the iframe. This filter ability is then used to convert the page to black and white tiles, and then transform the white tiles into a hard-to-compress pattern, while leaving the black ones alone. With that in place, it’s possible for the outer web page to slowly recreate the graphical view of the iframe, leaking information that is displayed on the page.

And this explains why this isn’t the most practical of attacks, as it not only requires opening a malicious page to host the attack, it also makes some very obvious graphical changes to the screen. Not to mention taking at least 30 minutes of data leaking to recreate a username displayed on the Wikipedia page. What it lacks in practicality, this approach makes up for in cleverness and creativity, though. The attack goes by the GPU.zip moniker, and the full PDF is available. Continue reading “This Week In Security: Magic Packets, GPU.zip, And Enter The Sandman”

Turing Complete Programming On ARM With Two Instructions

There are many questions that can be asked for software projects, with most of these questions starting with ‘Why…?’. This is true for the challenge of proving that cascading stylesheets are Turing-complete, or that you don’t need all those fancy ISA bits of an ARM processors when you already got the LDM and STM commands in the 32-bit ISA. What originally started off as a bit of a running gag in a group of developers led to [Kellan Clark] implementing a Turing-complete computer and a functioning interpreter using nothing but these two opcodes.

Adding some Brainfsck to your ARM, inside your GBA.
Adding some Brainf**k to your ARM, inside your GBA.

These two opcodes essentially allow the storing or reading of data into memory from any combination of the 16 general-purpose registers (GPRs). This makes them both extremely versatile and also extremely open to ‘abuse’ like in this example. For a straightforward implementation that could prove the concept, [Kellan] decided to pick one of everyone’s favorite esoteric programming languages: Brainf**k, creating the charmingly titled Armf**k that allows anyone to write BF programs for any suitable ARM processor, like the ARM7TDMI in the Game Boy Advance that [Kellan] targeted.

As a proof of concept it’s unquestioningly intriguing, and a great example of how the most powerful parts of any ISA are those that move data around. After all, as anyone who writes ASM and C knows, computers are just machines that can copy bytes around really fast to make stuff happen. Mind-blowing examples like these serve to illustrate that point quite well.

Tip kindly provided by [eeucalyptus].

Building A Weather Display In Rust

We’ve seen a lot of weather displays over the years, and plenty of the more modern ones have been using some form of electronic paper. So what makes this particular build from [Harry Stern] different? The fact that the firmware running on the ESP32 microcontroller at its heart was developed in Rust.

The weather station itself is capable of operating for several months on its rechargeable NiMH battery bank. The Rust section of the project is in two parts, the first of which runs on a server which downloads the weather data and aggregates it into an image. The second part runs on the ESP32 using esp-idf which configures peripherals, turns on and connects to Wi-Fi, retrieves the image from the server, displays the image and then puts the display to sleep. By doing the heavy lifting on the server, the display should be able to run for longer than it would if everything was happening on the ESP32.

The project code is available from this GitHub page which should allow even Rust beginners to follow along, and the case file is also available for those with a 3D printer. [Harry] has a few upgrades planned for future releases as well, including a snap-fit case, a custom PCB, and improved voltage regulator for better battery life, and enhanced error handling for the weather API. And Rust isn’t the only interesting part of this project, either. As prices for e-paper displays continue to fall, more and more of them are found in projects like weather stations and even complete laptops which use these displays exclusively.