From his comments about the noisy image and limited controls, we’re going to go out on a limb and assume [Andrew Jeddeloh] isn’t a huge fan of using his Epson V550 for scanning film. But is it really irredeemable? That’s what he set out to determine in a recent series of posts on his blog, and from what we can tell, it’s not looking good for the old Epson.
The first post attempts to quantify the optical capabilities of the scanner by determining its modulation transfer function (MTF), point spread function (PSF), and comparing its horizontal and vertical resolution. As you might expect, the nuances of these measurements are a bit beyond the average user. The short version of his analysis is that the scanner’s slide frame does indeed seem to be holding objects at the proper “sweet spot” for this particular image sensor; meaning that contrary to the advice he’d seen online, there’s nothing to be gained by purchasing custom film or slide holders.
While investigating the optical properties of the scanner, [Andrew] became curious about the automatic focus options offered by the VueScan software he was using. The images produced appeared to be identical regardless of what option he selected, and he began to suspect the feature wasn’t actually doing anything. To confirm his theory, he wrote a shim program that would sit between the proprietary VueScan program and the V550 driver and log all of the data passing between them.
After tweaking various options and comparing the captured data streams, [Andrew] determined that enabling automatic focus in VueScan doesn’t do anything. At least, not with his scanner. He did notice a few extra bytes getting sent to the driver depending on which focus options were selected, but the response from the scanner didn’t change. He thinks the program likely has some kind of generic framework for enabling these kind of features on supported hardware, and it’s just mistakenly showing the autofocus options for a scanner that doesn’t support it.
When it comes to computers, it seems like the only thing that matters is speed. The more the better, in general, and the same applies to peripherals. We want the fastest network adapters, the fastest video card, and the fastest printer. So why in the world would anyone intentionally build a really slow inkjet printer? For art, of course.
At least that’s the story [HomoFaciens] tells us in the video below. His efforts are in support of a friend’s art project, which seeks to print slowly but continuously on a roll of paper. [HomoFaciens]’s printer is based on an H-P C6602 inkjet cartridge, one of those high-priced consumables that make buying a new printer more attractive than replacing them once depleted. After figuring out how to drive the printhead — 5 to 6 μs pulses of 18 volts through a ULN2803 Darlington array driver chip seemed to do the trick — he mounted everything to the gantry of an old 3D printer. It’s interesting to watch the images slowly being built up — something that printers usually hide from prying eyes — and to see how the DPI count of the printer can be increased by interlacing each printed line.
Driving more than a handful of LEDs from a microcontroller is often a feat that takes tedious wiring, tricking the processor, or a lot of extra external hardware. Charlieplexing is perhaps the most notorious of these methods, and checks two of those three boxes. This library for the Teensy 4.0 checks all three, but it can also drive a truly staggering 32,000 LEDs at one time.
The TriantaduoWS2811 library is able to drive 32 channels of LEDs from a Teensy 4.0 using only three pins and minimal processor resources. It uses the FlexIO and DMA subsystems of the i.MX RT1062, the particular ARM processor on the Teensy, to drive four external shift registers. Together, the system is able to achieve 30 frames per second on with 1,000 LEDs per channel, for a total of 32,000 LEDs. Whoah.
[Ward] aka [wramsdell] wondered what one would do with all of the horsepower of a Teensy microcontroller when he first saw its specifications, and was able to build this project to take advantage of its features. What’s surprising, though, is that it doesn’t use nearly everything the processor is capable of, so you can do other tasks at the same time as driving that giant LED display.
[Ben Cox] found some interesting USB devices on eBay. The Epiphan VGA2USB LR accepts VGA video on one end and presents it as a USB webcam-like video signal on the other. Never have to haul a VGA monitor out again? Sounds good to us! The devices are old and abandoned hardware, but they do claim Linux support, so one BUY button mash later and [Ben] was waiting patiently for them in the mail.
But when they did arrive, the devices didn’t enumerate as a USB UVC video device as expected. The vendor has a custom driver, support for which ended in Linux 4.9 — meaning none of [Ben]’s machines would run it. By now [Ben] was curious about how all this worked and began digging, aiming to create a userspace driver for the device. He was successful, and with his usual detail [Ben] explains not only the process he followed to troubleshoot the problem but also how these devices (and his driver) work. Skip to the end of the project page for the summary, but the whole thing is worth a read.
The resulting driver is not optimized, but will do about 7 fps. [Ben] even rigged up a small web server inside the driver to present a simple interface for the video in a pinch. It can even record its output to a video file, which is awfully handy. The code is available on his GitHub repository, so give it a look and maybe head to eBay for a bit of bargain-hunting of your own.
The Axiom motor controller was a winner of the bootstrap contest and is a Finalist in the 2019 Hackaday Prize. The driver aims to deliver 300A continuous at 400V all day long. Which is a very impressive amount of power from a board that appears to be quite compact.
The brains of the device is an ice40 FPGA from Lattice running software based on the VESC Project. Its open source roots will certainly allow for some interesting hacks and an increasingly stable platform over time. Not to mention the existing software tools will aid in the sometimes cumbersome motor-driver tuning process.
The board designs are available, but we agree with the team that the complexity of assembly is likely going to be high (along with the price). The amount of research and skill going into this complicated kit is a bit mind-boggling, but we hope it will really enable some cool hacks, from cars, to ATVs, and maybe even an electric flyer.
When deadlines loom and your future is on the line, do what top college students through the ages have always done: procrastinate! [Simen] and [Amund] did that in grand style by starting a YouTube channel, delightfully and aptly named “Applied Procrastination”, wherein they plan to avoid their responsibilities as long as possible in favor of making a large-scale ferrofluidic display panel. (Video, embedded below.)
We suppose we should encourage them to hit the books, but honestly they look like they’re having much more fun and learning more than they would in class. The idea isn’t new; we’ve seen ferrofluid clocks before, after all. [Amund] and [Simen] have grander plans for their display, but they’re wisely starting small with basic experiments. They had an early great idea to use a double-pane window as a tank for their display, but coatings on the inside of the glass and the aluminum frame conspired to cloud the display. They also did some tests to make sure they can control 252 electromagnets safely. They did manage to get a small test display working, but really the bulk of the video is just them playing with magnets and ferrofluid. And again, we’re OK with that.
It looks like this is going to be an interesting project, with hopefully regular updates to the channel now that summer break is upon us. Unless they find something else to do, of course.
While it might be tempting to start soldering a circuit together once the design looks good on paper, experience tells us that it’s still good to test it out on a breadboard first to make sure everything works properly. That might be where the process ends for one-off projects, but for large production runs you’re going to need to test all the PCBs after they’re built, too. While you would use a breadboard for prototyping, the platform you’re going to need for quality control is called a “bed of nails“.
This project comes to us by way of [Thom] who has been doing a large production run of circuits meant to drive nixie tubes. After the each board is completed, they are laid on top of a number of pins arranged to mate to various points on the PCB. Without needing to use alligator clamps or anything else labor-intensive to test, this simple jig with all the test points built-in means that each board can be laid on the bed and tested to ensure it works properly. The test bed looks like a bed of nails as well, hence the name.
There are other ways of testing PCBs after production, too, but if your board doesn’t involve any type of processing they might be hard to implement. Nixie tubes are mostly in the “analog” realm so this test setup works well for [Thom]’s needs.