Moore’s law is the observation that, over the history of computing hardware, the number of transistors on integrated circuits doubles approximately every two years. This rapid advancement is certainly great for computing power and the advent of better technology but it does have one drawback; otherwise great working hardware becomes outdated and unusable. [Dave] likes his flight simulators and his old flight sim equipment. The only problem is that his new-fangled computer doesn’t have DA15 or DE9 inputs to interface with his controllers. Not being one to let something like this get him down, [Dave] set out to build his own microcontroller-based interface module. He calls it the Multijoy_Retro.
Continue reading “Multijoy_Retro Connects Your ‘Wayback’ to your ‘Machine’”
One morning [overflo] decided to protest the European Parliament’s stance on equine rights of defecation, a cherished liberty dating back to the time of Charlemagne. The best way to do this is, of course, blinking lights. He calls his project Blinkenschild, and it’s one of the best portable LED displays we’ve seen.
The display is based around fifteen RGB-123 LED panels, each containing an 8×8 matrix of WS2811 LEDs. That’s 960 pixels, all controlled with a Teensy 3.1. Power is supplied by fifteen LiPo cells wired together in parallel giving him 6 Ah of battery life. Clunky, yes, but it’s small enough to fit in a backpack and that’s what [overflo] had sitting around anyway.
The animations for the display are generated by Glediator, an unfortunately not open source control app for LED matrices. Glediator sends data out over a serial port but not over IP or directly into a file. Not wanting to carry a laptop around with him, [overflo] created a virtual serial port and dumped the output of Glediator into a file so it could be
played back stored on an SD card and controlled with an Android app. Very clever, and just the thing to raise awareness of horse and Internet concerns.
UPDATE: Check out [overflo’s] clarification in the comments below.
Continue reading “Blinkenschild, The RGB LED Display For Every Occasion”
We love classic synthesizers here at Hackaday. So does [gligli], but he didn’t like the processor limitations of the Prophet 600. That’s why he’s given it a new brain in the form of a Teensy++. The Sequential Circuits Prophet 600 was a big deal when it was released back in 1982/1983. The 600 was the first commercially available synthesizer to include a MIDI interface. The original design of the 600 could be called a hybrid. A Zilog Z80 microprocessor controlled modular analog voice chips. The Z80 was a bit stressed in this configuration though, and a few limitations were evident. An 8 bit processor just wasn’t quite enough for software driven envelopes and a Low Frequency Oscillator (LFO) control. This was further exacerbated by the fact that everything was driven through a 14 bit DAC.
[gligli] discovered most of the limitations in the 600 were due to the processor. By beefing up the processing power he could really unlock the potential within 600. Since he didn’t actually have a Prophet 600, he started with the schematic. [gligli] created a PC based emulator for the digital circuits, learning the whole system as he worked. With that phase complete, [gligli] bought a used Prophet and started hacking. The Teensy++ required a few hardware mods to fill the Z80’s shoes, including cutting off a pin and adding a few jumper wires. We really like the fact that no changes to the Prophet 600 itself are required. Pull out the Teensy++, drop in the Z80, and you’re ready to party like it’s 1982 again.
The new processor interfaces directly with the Z80’s 8 bit bus. Since the AVR on the Teensy has built-in RAM and ROM, it simply ignores the ROM and RAM address spaces of the original system. Interfacing a fast micro with older parts like an 8253 timer and a 68B50 UART does have its pitfalls though. The system bus had to run slow enough to not violate timing requirements of the various peripheral chips. To handle this, [gligli] added a number of wait statements in his firmware. Once the system was working, [gligli] was free to start adding new features. He began by smoothing out the stepped envelope and filter generators, as well as adding new exponential modes. From there he added new keyboard polyphony modes as well as pitch and mod wheel changes. The full lineup of new features are listed in the instruction manual (PDF link). Since this is an open source project, adding a feature is as simple as cracking open your favorite editor and writing it up.
Continue reading “Prophet 600: A Classic Synthesizer Gets Processor Upgrade”
[Wyager] was shopping around for a mechanical keyboard, and after noticing custom PCB manufacturing had come down in price so much, he decided to build his own. The end result is a keyboard that’s so elegant in its design, that it could, with a little work, become a very interesting Kickstarter project.
The design had three requirements: cheap, mechanical switches, and extremely customizable. The cheap requirement was solved by splitting the keyboard into two parts with a master/slave arrangement. The boards are connected by a 1/8″ TRRS jack conveying an I2C bus. Since both boards are identical except for the code running on the Teensy dev boards, [Wyager] saved a bit of cash by using two of the three PCBs that came with his OSHPark order.
The mechanical switches – Cherry MX Blues – are rather expensive parts for a failed project. For fear of failure, [Wyager] first ordered a PCB containing the footprint of only one key. With the footprint correct, he graduated to a 2×2 matrix. Once that was verified, the 6×5 matrix was ordered. Everything worked perfectly the first time, something we can’t say about many of our projects.
The code, board files, and schematics are available over on the github
Sometimes with a microcontroller project you need to do some very RAM-hungry operations, like image and audio processing. The largish AVR chips are certainly fast enough to do these tasks, but the RAM on these chips is limited. [xxxajk] has come up with a library that allows the use of huge RAM expansions with the Teensy++ 2.0 microcontroller, making these RAM-dependant tasks easy on one of our favorite microcontroller board.
[xxajk]’s work is actually a port of XMEM2, an earlier project of his that added RAM expansion and multitasking to the Arduino Mega. Up to 255 banks of memory are available and with the supported hardware, the Teensy can address up to 512kB of RAM.
XMEM2 also features a preemptive multitasking with up to 16 tasks, the ability to pipe messages between tasks, and all the fun of malloc().
The build is fairly hardware independent, able to work with Rugged Circuits QuadRAM and MegaRAM expansions for the Arduino Mega as well as [Andy Brown]’s 512 SRAM expansion. With the right SRAM chip, etching a board at home for XMEM2 is also a possibility.
[Paul Stoffregen], creator of the Teensy series of dev boards, previously implemented a six-axis joystick for Teensyduino, the Arduino library for the Teensy. He had originally tried 8 axes, but a few problems cropped up, deadlines approached, and he left it as is. A few recent projects gave him some insight into how to implement a joystick with more than six axes as a USB HID device, so he started looking at how to read an improbable amount of pots and buttons for a USB joystick.
So far, the biggest problem is figuring out what software can actually use an HID joystick with this many controls. The answer to that question is none. The Linux-based jstest-gtk is able to read 6+17 pots, the four hat switches, but only 64 of the 128 buttons. A user on the Teensy forums, [Pointy], has been working on his own joystick test app that works on
Linux Windows, but testing the joystick on Windows is an exercise in futility for reasons no one can figure out.
As for why anyone would want a six-axis, 17-slider, 128-button joystick, think about this: with this much control, it would be relatively simple to build the MIDI controller to end all MIDI controllers, or a cockpit simulator for everything from a C172, 737, to a Kerbal interplanetary cruiser. That’s an impressive amount of control, and all from a $20 Teensy dev board.
Further testing of this Teensy joystick is desperately needed, so if you’re able to help out drop a note in the forum thread.
[Colin] loves his PicoScope, a USB based “headless” oscilloscope. While using it he found himself longing for a classic oscilloscope interface. Mouse clicks just weren’t a replacement for grabbing a dial and twisting it. To correct the situation he created his USB-Connected Box-o-Encoders. The box maps as a USB keyboard, so it will work with almost any program.
[Colin] started by finding encoders. There are plenty of choices – splined or flatted shaft, detents or no detents, panel, PCB, or chassis mount. He settled on an encoder from Bourns Inc. which uses an 18 spline shaft. His encoder also includes a push button switch for selection. With encoders down, knobs were next. [Colin] chose two distinct styles. The two knob styles aren’t just decorative. The user can tell which row of knobs they are on by touch alone. Electronics were made simple with the use of a Teensy++ 2.0. [Colin] used a ATUSBKey device running Teensy software, but says the Teensy would have been a much better choice in terms of size and simplicity.
Once everything was wired into the box, [Colin] found his encoders would “spin” when the knobs were turned. They are actually designed to be PCB mounted, and then screwed into a control panel. Attempts to tighten down the panel mounting nut resulted in a broken encoder. Rather than redesign with purely panel mounted encoders, [Colin] used a dab of epoxy to hold the encoder body in place.
Continue reading “A USB Connected Box-o-Encoders”