[Seb Holzapfel, VK2SEB] has a rather nice spectrum analyser, a Hewlett Packard 141T. It’s an entirely analogue instrument though, so it lacks some of the sophisticated features you might expect to see on its modern counterparts.
One feature the HP does have is a vertical deflection output that in effect allows the trace to be reproduced on an oscilloscope. [Seb] has taken that and applied it to an STM32F746 Discovery board with its associated LCD touchscreen to produce an interface for the HP that includes modern features such as trace normalisation and a waterfall view. Along the way he’s had to make a voltage level converter to render the HP’s scan output into a range acceptable for the ST board.
He goes into detail on his software for the project, which he is at pains to remind us is still very much a work in progress. He notes that the HP has a range of other outputs (on those “D” sockets that include co-axial connectors) that provide information about its band and scan settings, so there is ample possibility for further customisation.
If you are interested in this project then the code is all available via GitHub, otherwise you can watch his video below the break. He’s labelled it as “Part 1”, so we look forward to more on this project.
Continue reading “A Digital LCD Makeover For An Analogue CRT Spectrum Analyser”
[Mario] wrote us with his synthesizer project that’s currently up on Kickstarter. It looks like a good amount of fun to play with, as you can see in the video on the Kickstarter page. But it’s also built to be easily hackable.
On the hardware front, it’s a tiny four-layer board that’s crammed with parts. At the core is an STM32F4 microcontroller and a DAC. Indeed, the build was inspired by other folks’ work on the STM32F4 Discovery dev kit that has been used to make some pretty interesting synthesizer devices. [Mario]’s version adds two stereo headphone outputs, two microphone inputs, two IR reflective distance sensors used as control inputs, some buttons, and a ton of LEDs. And then it makes good use of all of them.
The firmware isn’t open source yet (poke! poke!) but it looks like it’s going to be. On his blog, [Mario] works through an example of adding a drum machine into the existing firmware, so it looks like it’ll be hackable.
Squeezing a lot of DSP functionality out of a single microcontroller is a feat. On a similar chip from a different manufacturer, [Paul Stoffregen]’s Teensy Audio Library could also be made to do a lot of the same things. But the real beauty of the Gecho project is that it has some interesting hardware features already built in and ready to go. It wouldn’t be a bad launching pad for your own musical or audio explorations.
[Igor b] plays in a band and wanted a way to use a foot pedal to trigger samples. Since he had a STM32F429 evaluation board handy, he decided to build the Stmpler using the board, a touch screen, an SD card, and not much else.
Continue reading “Discovery MIDI Sample Player”
When we ran the story of Battlezone played on tube displays earlier this week there were immediately questions about recreating the hack. At the time the software wasn’t available, and there is also a bit of hardware hacking necessary to get the audio working. You asked and [Eric] from Tubetime delivered. He’s posted a pair of articles that show how to get an STM32F4 Discovery board to play the classic game, along with instructions to build the firmware.
The hardware hack in this case is untangling the pinout used on the discovery board. It seems that one of the lines needed to get sound working for this hack is tied to one of the two DACs. If you read the original coverage you’ll remember that both of the DACs are used to drive X and Y on the vector display. The image above shows a cut trace on the bottom of the board. You’ll then need to route that signal to an alternate pin by soldering a jumper wire from the chip to a resistor on the board.
This (as well as one other alteration that bridges two of the chip pins) is a great example of work you should be unafraid to do on your own dev boards. We’ve had to do it with the Launchpad boards to get at the functionality we needed. We’d like to hear your own epic stories of abusing dev boards to do your bidding. Let us know in the comments.
We’ve been admirers of the work [Eric] and friends have been doing over at TubeTime for years. One of the earliest we can remember is the decatron kitchen timer, and we still tell the story of [Eric] purposely leaving out button debouncing in order to make his vector flappy bird even harder.
TubeTime is back at it this year and we had the opportunity to speak with them at Bay Area Maker Faire. The group specializes in working with old tube displays and this year’s offering was spectacular in many ways. First off, the software side of things is an emulator running on an STM32 F4 Discovery board. The chips on these boards have a pair of 12-bit DACs which are driving the X and Y of the vector displays. Code to run the original ROMs was ported from existing projects, but the audio for the games was kind of a hack to get working.
This particular display is where things get really fascinating. The tube itself was originally manufactured as test equipment for television repairmen. What’s fascinating about this is that [Eric] had to rewind the deflection yokes himself to get it working again. Luckily he documented quite a bit about his initial research into this process and his experiments to remedy some distortion issues he encountered once it was working.
Make sure to head on over to TubeTime and read their overview of the Battlezone machine. After the break we’ve also embedded a few of our own pictures as well as the interview at BAMF.
Continue reading “Battlezone Played on Vector Display with Hand-Wound Yoke”
Microcontroller Dev Boards have the main hardware choices already made for you so you can jump right into the prototyping by adding peripherals and writing code. Some of the time they have everything you need, other times you can find your own workarounds, but did you ever try just swapping out components to suit? [Andy Brown] documented his process of transplanting the clock crystal on an STM32F4 Discovery board.
Even if you don’t need to do this for yourself, the rework process he documented in the clip after the break is fun to watch. He starts by cleaning the through-hole joints of the crystal oscillator with isopropyl alcohol and then applies some flux paste to each. From there the rest is all hot air. The crystal nearly falls out due to gravity but at the end he needs to pluck it out with his fingers. We’re happy to see others using this “method” as we always feel like it’s a kludge when we do it. Next he grabs the load caps with a pair of tweezers after the briefest of time under the heat.
We’d like to have a little bit of insight on the parts he replaces and we’re hoping there are a few crystal oscillator experts who can leave a comment below. [Andy] calculates a pair of 30pf load caps for this crystal. We understand the math but he mentions a common value for board and uC input capacitance:
assuming the commonly quoted CP + CI = 6pF
So we asked and [Andy] was kind enough to share his background on the topic:
It’s a general “rule of thumb” for FR4 that the stray capacitance due to the traces on the board and the input (lead) capacitance of the the MCU is in in the range of 4-8pF. I’m used to quoting the two separately (CP,CI) but if you look around you’ll see that most people will combine the two and call it just “CP” and quote a value somewhere between 4 and 8pF. It’s all very “finger in the air” and for general purpose MCU clocks you can get away picking the mid-value and be done with it.
That leaves just one other question; the original discovery board had an in-line resistor on one of the crystal traces which he replaces with a zero ohm jumper. Is it common to include a resistor and what is the purpose for it?
Continue reading “Swapping Dev Board Crystals to Suit Your Needs”
With Samsung’s new Gear VR announced, developers and VR enthusiasts are awaiting the release of the smartphone connected VR headset. A few people couldn’t wait to get their hands on the platform, so they created, OpenGear, a Gear VR compatible headset.
The OpenGear starts off with a Samsung Galaxy Note 4, which is the target platform for the Gear VR headset. A cardboard enclosure, similar to the Google Cardboard headset, holds the lenses and straps the phone to your face.
The only missing part is the motion tracking electronics. Fortunately, ST’s STM32F3 Discovery development board has everything needed: a microcontroller with USB device support, a L3GD20 3 axis gyro, and a LSM303DLHC accelerometer/magnetometer. These components together provide a USB inertial measurement unit for tracking your head.
With the Discovery board strapped to the cardboard headset, an open-source firmware is flashed. This emulates the messages sent by a legitimate Oculus Rift motion tracker. The Galaxy Note 4 sees the device as a VR headset, and lets you run VR apps.
If you’re interested, the OpenGear team is offering a development kit. This is a great way for developers to get a head start on their apps before the Gear VR is actually released. The main downside is how you’ll look with this thing affixed to your face. There’s a head-to-head against the real Gear VR after the break.
[via Road To VR]
Continue reading “Build Your Own Gear VR”