A big claim! And he is quick to admit that his printed solder paste isn’t presently quite as precise as solder stencils, but he is reporting good success with his technique so far.
[Stephen] found that he could print PCBs with his fiber laser, populate his boards with his LumenPnP, and reflow with his oven, but… what about paste? [Stephen] tried making stencils, and in his words: “it sucked!” So he asked himself: what if he didn’t need a stencil? He built a Gerber processing, G-code generating, machine-vision implemented… website. The LumenPnP Pasting Utility: https://paste.opulo.io/
Setting up a file server can be intimidating to the uninitiated. There are many servers to choose from, and then you need to decide how to install it — Docker? Kubernates? Well, what’s all that then? [9001] has come to the rescue with Copyparty, a full-featured file server in a single Python script.
It’s light enough to run on nearly anything, and getting it running could not be easier: run copyparty-sfx.py, and you’ve got a server. There’s even a 32-bit .exe for older Windows machines — Windows 2000 seems to be the oldest version tested.
Browsers supported: almost all of them.
It’ll connect to anything, both in terms of the variety of protocols supported, and the browsers its web interface loads in. The GitHub documentation says browser support : “Yes”, which is pretty accurate going down the list. Sadly Copyparty’s pages do not work in NACA Mosaic, but IE4 is A-OK.
There’s, FTP, TFTP, HTTP/HTTPS, WebDAV, SMB/CIFS, with unp/zeroconf/mdns/ssdp, etc etc. You need to check the readme for all features, some of which — like transcoding — are only available when dependencies such as ffmpeg installed on the server. Alternatively you can watch the video embedded below to get walked through the features. If the video whets your appetite, can also visit a read-only Copyparty server being demoed on a NUC sitting in [9001]’s basement.
Over the years we’ve seen plenty of folks create personal servers, but the focus is generally on the hardware side of things. While those with more software experience might prefer to configure the various services involved manually, we can definitely see the appeal of a project like Copyparty. In some ways it’s the inverse of the UNIX Philosophy: instead of doing one thing perfectly, this program is doing everything [9001] could think of, and doing it “good enough”.
Do you find an odd comfort in the uncanny, regular intonations of a Numbers Station? Then check out [edent]’s numbers station project, which leverages the browser’s speech synthesis engine to deliver a ceaseless flow of (mostly) numbers, calmly-intoned in various languages.
The project is an entry for the annual JavaScript Golfing Competition, in which participants aim to create a cool program in 1024 bytes or less. It cleverly relies on the Web Speech API to deliver the speaking parts, which helps keep the code size tiny. The only thing it’s missing is an occasional shadow of static drifting across the audio.
If you’re new to numbers stations, our own [Al Williams] is here to tell you all about them. But there’s no need to tune into an actual mysterious radio signal just to experience weird numbers; just fire up [edent]’s project, put on some headphones, and relax if you can.
In this series of three videos, [Piers] runs us through what a software defined ROM is, how to make them, and then how to use them.
As [Piers] explains, one frustration a retro technician will face is a failed ROM chip. In the era he’s interested in, there are basically three relevant kinds of ROM chip, all 24-pin Dual Inline Package (DIP):
In the same way that it makes sense for you to learn to touch type if you’re going to be using a computer a lot, it makes sense for you to put some thought and effort into your KiCad keyboard shortcuts keys, too.
In this video [Pat] introduces the keymap that he has come up with for the KiCad programs (schematic capture and PCB layout) and explains the rules of thumb that he used to generate his recommended shortcut keys, being:
one handed operation; you should try to make sure that you can operate the keyboard with one hand so your other hand can stay on your mouse
proximity follows frequency; if you use it a lot it should be close to hand
same purpose, same place; across programs similar functions should share the same key
birds of a feather flock together; similar and related functionality kept in proximate clusters
typing trounces topography; if you have to use both hands for typing you have to take your hand off the mouse anyway so then it doesn’t really matter where on the keyboard the shortcut key is
According to [Casey Connolly], Qualcomm’s release of how to interact with their embedded USB debugging (EUD) is a big deal. If you haven’t heard of it, nearly all Qualcomm SoCs made since 2018 have a built-in debugger that connects to the onboard USB port. The details vary by chip, but you write to some registers and start up the USB phy. This gives you an oddball USB interface that looks like a seven-port hub with a single device “EUD control interface.”
So what do you do with that? You send a few USB commands, and you’ll get a second device. This one connects to an SWD interface. Of course, we have plenty of tools to debug using SWD.
Selecting a random sample from a set is simple. But what about selecting a fair random sample from a set of unknown or indeterminate size? That’s where reservoir sampling comes in, and [Sam Rose] has a beautifully-illustrated, interactive guide to how reservoir sampling works. As far as methods go, it’s as elegant as it is simple, and particularly suited to fairly sampling dynamic datasets like sipping from a firehose of log events.
While reservoir sampling is simple in principle it’s not entirely intuitive to everyone. That’s what makes [Sam]’s interactive essay so helpful; he first articulates the problem before presenting the solution in a way that makes it almost self-evident.
[Sam] uses an imaginary deck of cards to illustrate the problem. If one is being dealt cards one at a time from a deck of unknown size (there could be ten cards, or a million), how can one choose a single card in a way that gives each an equal chance of having been selected? Without collecting them all first?
In a nutshell, the solution is to make a decision every time a new card arrives: hold onto the current card, or replace it with the new one. Each new card is given a 1/n chance of becoming held, where n is the number of cards we’ve seen so far. That’s all it takes. No matter when the dealer stops dealing, each card that has been seen will have had an equal chance of ending up the one selected.
There are a few variations which [Sam] also covers, and practical ways of applying it to log collection, so check it out for yourself.
If [Sam]’s knack for illustrating concepts in an interactive way is your jam, we have one more to point out. Our own Al Williams wrote a piece on Turing machines; the original “universal machine” being a theoretical device with a read/write head and infinite paper tape. A wonderful companion to that article is [Sam]’s piece illustrating exactly how such a Turing machines would work in an interactive way.
