Simple Tip Helps With Powder Coating Perfection On Difficult Parts

To say that that the commercially available garden path lights commonly available at dollar stores are cheap is a vast overstatement of their true worthlessness. These solar-powered lights are so cheaply built that there’s almost no point in buying them, a fact that led [Mark Presling] down a fabrication rabbit hole that ends with some great tips on powder coating parts with difficult geometries.

Powder coating might seem a bit overkill for something as mundane as garden lights, but [Mark] has a point — if you buy something and it fails after a few weeks in the sun, you might as well build it right yourself. And a proper finish is a big part of not only getting the right look, but to making these totally un-Tardis-like light fixtures last in the weather. The video series below covers the entire design and build process, which ended up having an aluminum grille with some deep grooves. Such features prove hard to reach with powder coating, where the tiny particles of the coating are attracted to the workpiece thanks to a high potential difference between them. After coating, the part is heated to melt the particles and form a tough, beautiful finish.

But for grooves and other high-aspect-ratio features, the particles tend to avoid collecting in the nooks and crannies, leading to an uneven finish. [Mark]’s solution was to turn to “hot flocking”, where the part is heated before applying uncharged coating to the deep features. This gets the corners and grooves well coated before the rest of the coating is applied in the standard way, leading to a much better finish.

We love [Presser]’s attention to detail on this build, as well as the excellent fabrication tips and tricks sprinkled throughout the series. You might want to check out some of his other builds, like this professional-looking spot welder.

Continue reading “Simple Tip Helps With Powder Coating Perfection On Difficult Parts”

Walk The First 3D-Printed Bridge And Be Counted

Way back in 2018, we brought you news of a 3D-printed stainless steel pedestrian bridge being planned to span a Dutch canal in Amsterdam. Now it’s finally in place and open to the public — the Queen made it official and everything. MX3D printed it on their M1 Metal additive manufacturing machine that is essentially a group of robots welding layers of metal together using traditional welding wire and gas.

The partnership of companies involved originally planned to build this beautiful bridge in situ, but safety concerns and other issues prevented that and it was built in a factory instead. The bridge has been printed and ready since 2018, but a string of delays got in the way, including the fact that the canal’s walls had to be refurbished to accommodate it. Since it couldn’t be made on site, the bridge was taken there by boat and placed with a crane. After all this, the bridge is only permitted to be there for two years. Hopefully, they have the option to renew.

This feat of engineering spans 40 feet (12.2 meters) long and sits 20 feet (6.3 meters) wide. It’s equipped with sensors that measure structural stuff like strain, displacement, load, and rotation, and also has environmental sensors for air quality and temperature. All of this data is sent to the bridge’s digital twin, which is an exact replica in the form of a computer model. One of the goals is to teach the bridge how to count people. Be sure to check out our previous coverage for a couple of short videos about the bridge.

Arm Researchers Announce The PlasticArm

If the Cortex family of embedded microprocessors aren’t flexible enough for your designs, an article published this week (click here for the PDF version) in the journal Nature might be of interest. We’re not talking flexibility in terms of features, but real, physical flexibility of the microprocessor itself. A research team from Arm Ltd. has developed the PlasticArm, which is a 32-bit processor derived from the Cortex-M0+ family.

They accomplished this by constructing a CPU from metal-oxide thin-film transistors (TFT) on a polyimide substrate, the resultant chip being called a natively flexible microprocessor. While much of the hype focuses on the flexibility aspect, we think the real innovation here is the low cost. The processes used to deposit transistors onto silicon wafers is much more expensive than those on this flexible substrate.

Don’t get too excited just yet, because there were some compromises made along the way. Modern microprocessor silicon dies are measured in the tens of microns, but the PlasticArm total die size is a comparatively whopping 9 mm square. The researchers were appropriately focused on the core CPU, and the auxiliary building blocks such as ROM and RAM seem almost an afterthought. With only 456 bytes of program store and 128 bytes of RAM, only the tiniest of applications are suited to this chip. Other compromises were made, such as no internal registers — they are mapped to the external RAM — and the CPU runs a lot slower than we’re used to, topping out at 29 kHz (note: k not M).

There are certainly some challenges with this new technology, and we won’t be designing with these chips any time soon. But it has the potential to offer benefits in certain niche applications where low-cost and/or flexibility is more important than processor speed and performance.

 

New Privacy Policy Gets Audacity Back On Track

Regular readers will likely be aware of the considerable debate over changes being made to the free and open source audio editor Audacity by the project’s new owners, Muse Group. The company says their goal is to modernize the 20 year old GPLv2 program and bring it to a larger audience, but many in the community have questioned whether the new managers really understand the free software ethos. An already precarious situation has only been made worse by a series of PR blunders Muse Group has made over the last several months.

But for a change, it seems things might be moving in the right direction. In a recent post to Audacity’s GitHub repository, Muse Group unveiled the revised version of their much maligned Privacy Policy. The announcement also came with an admission that many of the key elements from the draft version of the Privacy Policy were poorly worded and confusing. It seems much of the problem can be attributed to an over-analysis of the situation; with the company inserting provocative boilerplate protections (such as a clause saying users must be over the age of 13) that simply weren’t necessary.

Ultimately, the new Privacy Policy bears little resemblance to the earlier draft. Which objectively, is a good thing. But it’s still difficult to understand why Muse Group publicly posted such a poorly constructed version of the document in the first place. Project lead Martin Keary, better known online as Tantacrul, says the team had to consult with various legal teams before they could release the revised policy. That sounds reasonable enough, but why where these same teams not consulted before releasing such a spectacularly ill-conceived draft?

The new Privacy Policy makes it clear that Audacity won’t be collecting any user data, and what little personally identifiable information Muse Group gets from the application when it automatically checks for an update (namely, the client’s IP address) isn’t being stored. It’s further explained in the GitHub post that the automatic update feature only applies to official binary builds of Audacity, meaning it will be disabled for Linux users who install it through their distribution’s package repository. The clause about working with unnamed law enforcement agencies has been deleted, as has the particularly troubling age requirement.

Credit where credit is due. Muse Group promised to revise their plans for adding telemetry to Audacity, and judging by the new Privacy Policy, it seems they’ve done an admirable job of addressing all of the issues brought up by the community. Those worried their FOSS audio editor of choice would start spying on them can rest easy. Unfortunately the issue of Audacity’s inflammatory Contributor License Agreement (CLA) has yet to be resolved, meaning recently christened forks of the audio editor dedicated to preserving its GPLv2 lineage are unlikely to stand down anytime soon.

This Week In Security: NSO, Print Spooler, And A Mysterious Decryptor

The NSO Group has been in the news again recently, with multiple stories reporting on their Pegasus spyware product. The research and reporting spearheaded by Amnesty International is collectively known as “The Pegasus project”. This project made waves on the 18th, when multiple news outlets reported on a list of 50,000 phone numbers that are reported as “potential surveillance targets.” There are plenty of interesting people to be found on this list, like 14 heads of state and many journalists.

There are plenty of questions, too. Like what exactly is this list, and where did it come from? Amnesty international has pointed out that it is not a list of people actively being targeted. They’ve reported that of the devices associated with an entry on the list that they have been able to check, roughly 50% have shown signs of Pegasus spyware. The Guardian was part of the initial coordinated release, and has some impressive non-details to add:

The presence of a phone number in the data does not reveal whether a device was infected with Pegasus or subject to an attempted hack. However, the consortium believes the data is indicative of the potential targets NSO’s government clients identified in advance of possible surveillance attempts.

Amazon’s AWS was named as part of the C&C structure of Pegasus, and in response, they have pulled the plug on accounts linked to NSO. For their part, NSO denies the validity of the list altogether. Continue reading “This Week In Security: NSO, Print Spooler, And A Mysterious Decryptor”

The Gatwick Drone: Little By Little, The Story Continues To Unravel

If you remember the crazy events in the winter of 2018 as two airports were closed over reports of drone sightings, you might be interested to hear that there’s still a trickle of information about those happenings making it into the public domain as Freedom of Information responses.

Three Christmases ago the news media was gripped by a new menace, that of rogue drones terrorising aircraft. The UK’s Gatwick airport had been closed for several days following a spate of drone sightings, and authorities thundered about he dire punishments which would be visited upon the perpetrators when they were caught. A couple were arrested and later quietly released, and after a lot of fuss the story quietly disappeared.

Received Opinion had it that a drone had closed an airport, but drone enthusiasts, and Hackaday as a publication in their sphere, were asking awkward questions about why no tangible evidence of a drone ever having been present had appeared. Gradually the story unravelled with the police and aviation authorities quietly admitting that they had no evidence of a drone, and a dedicated band of drone enthusiasts has continues to pursue the truth about those few winter nights in 2018. The latest results chase up the possibility that the CAA might have received a description of the drone, and why when a fully functional drone detection system had been deployed and detected nothing they continued with the farce of closing the airport.

Perhaps the saddest thing about these and other revelations about the incident which have been teased from the authorities is that while they should fire up a scandal, it seems inevitable that they won’t. The police, the government, and the CAA have no desire to be reminded of their mishandling of the event, neither except for a rare bit of mild questioning do the media wish to be held to account for the execrable quality of their reporting. The couple who were wrongly arrested have not held back in their condemnation, but without the attention of any powerful vested interests it seems that some of the measures brought in as a response will never be questioned. All we can do is report any new developments in our little corner of the Internet, and of course keep you up to date with any fresh UK police drone paranoia.

Software Defined… CPU?

Everything is better when you can program it, right? We have software-defined radios, software-defined networks, and software-defined storage. Now a company called Ascenium wants to create a software-defined CPU. They’ve raised millions of dollars to bring the product to market.

The materials are a bit hazy, but it sounds as though the idea is to have CPU resources available and let the compiler manage and schedule those resources without using a full instruction set. A system called Aptos lets the compiler orchestrate those resources.

Continue reading “Software Defined… CPU?”