ARCTOS is a 6-DOF robot arm based upon 3D printed mechanics running a modified version of GRBL firmware. Let’s get this straight now, the firmware is open source, but the hardware plans are a paid download, but for less than forty euros, we reckon the investment would be well worth it, judging from the quality of the build instructions and the software support already in place. Continue reading “Arctos Robotics: Build A Robot Arm Out Of 3D Printer Spares?”
[Koraks tinkers] was gifted a gargantuan photographic enlarger, a Durst Laborator 138 s, which is a unit designed specifically for black and white usage only. This was not good enough for [Koraks] so down the rabbit hole of conversion to colour we go! The moral of the story is this: if you can’t find it, build it. The hacker mentality. After wasting time and effort trying to source a period colour head for the thing, [Koraks] did the decent thing and converted what was already in front of them.
Now, if you’re thinking this process is simply a matter of ripping out the tungsten bulb and sticking a high-power RGB array in there, then you’re going to be disappointed! You see, colour photography of the era — specifically the RA4 process in this case — requires careful colour calibration and is heavily biased towards the red end of the visible spectrum, due to the colour curve of those tungsten bulbs we touched upon earlier.
The first attempt at using an off-the-shelf COB array was a bust — it simply wasn’t bright enough once the light had passed through the diffuser plate, and the light path losses were too high to expose the RA4 paper sufficiently, especially at the red end of the spectrum. Quite simply this is due to the reduced energy of red photons (compared to blue) making the desired chemical reaction rate too low. The solution is more power.
Another issue that quickly raised itself was that 8-bits of PWM control of the RGB components was inadequate since the ratio of blue to red required was so skewed, that only a few effective bits of blue channel control were usable, and that was far too granular to get the necessary accuracy.
[Koraks’] approach was to custom build an LED array with twenty red 3W LEDs and eight each of the green and blue devices. 12-bits of PWM resolution was delivered via a PCA9685 PWM controller, that also handily controlled the cooling fans. The whole thing was hooked up to an Arduino Nano, with an MCP23016 expander board performing the duty of interfacing the rotary encoders and trigger footswitch. In fact, several iterations of the LED array have been constructed and this four-part blog series (Part1, Part2, Part3, Part4) lays out the whole story in all its gory detail for your entertainment. Enjoy!
COB LED arrays are pretty nifty, checkout turning them into 7-segment displays, just because. If all you want is raw power, we reckon that 100W “should be enough for anyone…”
Thanks [macsimski] for the tip!
Update: Corrected the article header from ‘exposer head’ to ‘enlarger’ for clarity at the request of the project author.
[Alessandro Carminati] spends the day hacking Linux kernels, and to such an end needed a decent compilation machine to chew through the builds. One day, this machine refused to boot leaving some head-scratching to do, and remembering the motherboard diagnostics procedures of old, realized that wasn’t going to work for this modern board. You see, older ISA-based systems were much simpler, with diagnostic POST codes accessible by sniffing the bus with an appropriate card inserted, but the modern motherboard doesn’t even export the same bus anymore.
Do modern machines even run a POST test at all, or are there other standards? After firing up a Linux machine and dumping the first meg of memory address space, it clearly contained some of the BIOS code. [Alessandro] looked at a disassembly of the BIOS update image and saw a similar structure, with POST code data sent to port 0x80 just like machines of old.
But instead of an ISA CPU bus, we have the Low Pin Count (LPC) bus which is used to hook up the ‘super IO’ functions, controlling things such as fans, temp sensors, and other system management functions. It also serves as the connection for the TPM feature, which usually appears as one of the motherboard connectors intended to be user-accessible. It turns out that POST codes can be accessed from this point with an appropriate POST card that can talk LPC.
Continue reading “Can You Use A POST Card With A Modern BIOS?”
[Shahriar] of The Signal Path is back with another fascinating video teardown and analysis for your viewing pleasure. (Embedded below.) This time the target is an Agilent E5052A 7 GHz signal Source/Analyser which is an expensive piece of kit not many of us are fortunate enough to have on the bench. This particular unit is reported as faulty, with a signal power measurement that is completely off-the-rails wrong, which leads one to not trust anything the instrument reports.
After digging into the service manual of the related E5052B unit, [Shahriar] notes that the phase noise measurement part of the instrument is totally separate from the power measurement, only connected via some internal resistive power splitters, and this simplifies debugging a lot. But first, a short segue into that first measurement subsystem, because it’s really neat.
A traditional swept-mode instrument works by mixing the input signal with a locally-sourced low-noise oscillator, which when low-pass filtered, is fed into a power meter or digitizer. This simply put, down-converts the signal to something easy to measure. It then presents power or noise as a function of the local oscillator (LO) frequency, giving us the spectral view we require. All good, but this scheme has a big flaw. The noise of the LO is essentially added to that of the signal, producing a spectral noise floor below which signals cannot be resolved.
The E5052 instrument uses a cunning cross-correlation technique enabling it to measure phase noise levels below that of its own internal signal source. The instrument houses an Oven-Compensated Crystal Oscillator (OCXO) for high stability, in fact, two from two different vendors, one for each LO, and mounted perpendicular to each other. The technique splits the input signal in half with a power splitter, then feeds both halves into identical (apart from the LOs) down-converters, the outputs of which are fed into a DSP via a pair of ADCs. Having identical input signals, but different LOs (with different phase noise spectra) turns the two signals from a correlated pair to an uncorrelated pair, with the effects of chassis vibration and gravity effects also rolled in.
The DSP subtracts the uncorrelated signal from the correlated signal, therefore removing the effect of the individual LO’s effect on the phase noise spectrum. This clever technique results in a phase noise spectrum below that of the LOs themselves, and a good representation of the input signal being measured.
Handily for [Shahriar] this complex subsystem is totally separate from the dodgy power measurement. This second system is much simpler, being fed with another copy of the input signal, via the main resistive power splitter. This second feed is then split again with a custom power divider, which upon visual inspection of the input SMA connector was clearly defective. It should not wobble. The root cause of the issue was a cold solder joint of a single SMA footprint, which worked loose over time. A little reflow and reassembly and the unit was fit for recalibration, and back into service.
We’ve seen phase noise measurements a few times on these pages, like debugging this STM32 PLL issue.
Continue reading “A 7 GHz Signal Analyser Teardown And A Trivial Repair”
[Kevin] over at Simple DIY ElectroMusic Projects has released a complete DIY modular design for simulating the classic 80s Yamaha TX816 DX/FM modular digital synthesizer. This beast of a synth was used by the cool bands of the 80s as well as TV studios, and ownership of the original machine is an expensive investment. But with the power of modern hackable electronics, and the MiniDexed firmware running bare-metal on a Raspberry Pi getting access to a compatible synth doesn’t have to break the bank.
[Kevin] wanted to emulate the look and feel of the original TX816 aesthetic, developing a custom PCB handling the user interface for four of the eight channels, and a second acting as an interface to the Raspberry Pi using a
Pico. Also sitting on this PCB is the GY-PCM5102 I2S DAC, and the MIDI connectors needed to connect to the system controller. Both PCBs, including a PCB-based front panel, were developed with KiCAD. The firmware for the Pico part of the system can be found on the firmware GitHub. The video demo (embedded below) shows off the system running a very 80s-sounding rendition of Holst’s famous ‘Jupiter’ from the planet series, and we all agree it sounds pretty sweet. For a complete rundown of the build, here are the links for the blog series for ease of access: Intro, PCBs, Panel, Build Guide, Mechanical, Pico/TX816 IO code, and finally usage. Phew!
If MiniDexed sounds familiar, that is because we featured another of [Kevin’s] earlier MiniDexed projects a little while ago.
Continue reading “An RPi-Powered Multi-DX7/TX816 Style Synth”
The History Guy on YouTube has posted an interesting video on the history of the supercomputer, with a specific focus on their use by NASA for the implementation of computational fluid dynamics (CFD) models of aeronautical assemblies.
The aero designers of the day were quickly finding out the limitations of the wind tunnel testing approach, especially for so-called transonic flow conditions. This occurs when an object moving through a fluid (like air can be modeled) produces regions of supersonic flow mixed in with subsonic flow and makes for additional drag scenarios. This severely impacts aircraft performance. Not accounting for these effects is not an option, hence the great industry interest in CFD modeling. But the equations for which (usually based around the Navier-Stokes system) are non-linear, and extremely computationally intensive.
Obviously, a certain Mr. Cray is a prominent player in this story, who, as the story goes, exhausted the financial tolerance of his employer, CDC, and subsequently formed Cray Research Inc, and the rest is (an interesting) history. Many Cray machines were instrumental in the development of the space program, and now adorn computing museums the world over. You simply haven’t lived until you’ve sipped your weak lemon drink whilst sitting on the ‘bench’ around an early Cray machine.
You see, supercomputers are a different beast from those machines mere mortals have access to, or at least the earlier ones were. The focus is on pure performance, ideally for floating-point computation, with cost far less of a concern, than getting to the next computational milestone. The Cray-1 for example, is a 64-bit machine capable of 80 MIPS scalar performance (whilst eating over 100 kW of juice), and some very limited parallel processing ability.
While this was immensely faster than anything else available at the time, the modern approach to supercomputing is less about fancy processor design and more about the massive use of parallelism of existing chips with lots of local fast storage mixed in. Every hacker out there should experience these old machines if they can, because the tricks they used and the lengths the designers went to get squeeze out every ounce of processing grunt, can be a real eye-opener.
Want to see what happens when you really push out the boat and use the whole wafer for parallel computation? Checkout the Cerberus. If your needs are somewhat less, but dabbling in parallel computing gets you all pumped, you could build a small array out of Pine64s. Finally, the story wouldn’t be complete without talking about the life and sad early demise of Seymour Cray.
Continue reading “A History Of NASA Supercomputers, Among Others”
[Oli Wright] is back again with another installation of CRT shenanigans. This time, the target is the humble analog oscilloscope, specifically a Farnell DTV12-14 12 MHz dual-channel unit, which features a handy X-Y mode. The result is the Velociraster, a simple (in hardware terms) Raspberry Pi Pico based display driver.
Using a Pico to drive a pair of AD767 12-bit DACs, the outputs of which drive the two ‘scope input channels directly, this breadboard and pile-of-wires hack can produce some seriously impressive results. On the software side of things, the design is a now a familiar show, with core0 running the application’s high-level processing, and core1 acting in parallel as the rendering engine, determining static DAC codes to be pushed out to the DACs using the DMA and the PIO.
Continue reading “Bust Out That Old Analog Scope For Some Velociraster Fun!”
