The T-962A is a very popular reflow oven available through the usual kinda-shady retail channels. It’s pretty cheap, and therefore popular, and the construction actually isn’t abysmal. The controller for this oven is downright terrible, and [wj] has been working on a replacement firmware for the horribly broken one provided with this oven. It’s open source, and the only thing you need to update your oven is a TTL/UART interface.
[WJ] bought his T-962A even after seeing some of the negative reviews that suggested replacing the existing controller and display. This is not in true hacker fashion – there’s already a microcontroller and display on the board.
The new firmware uses the existing hardware and adds a very necessary modification: stock, the oven makes the assumption that the cold-junction of the thermocouples is at 20°C. The controller sits on top of an oven with two TRIACs nearby, so this isn’t the case, making the temperature calibration of the oven slightly terrible.
After poking around the board, [WJ] found an LPC2000-series microcontroller and a spare GPIO pin for a 1-wire temperature sensor. The temperature sensor is placed right next to the terminal block for the thermocouples for proper temperature sensing.
All the details of updating the firmware appear on a wiki, and the only thing required to update the firmware is a serial/USB/UART converter. A much better solution than ripping out the controller and replacing it with a custom one.
A few years ago, some vastly clever people figured out how to listen in on the LCD display on the classic brick Game Boy from 1989. There have been marked improvements over the years, including a few people developing VGA out for the classic Game Boy. Now, the bar has been raised with an HDMI adapter for the Game Boy, designed in such a way that turns everyone’s favorite battery hog into a portable console.
Your classic beige or cleverly named Color Game Boy is composed of two halves. The rear half contains all the important circuitry – the CPU, cartridge connector, and the rest of the smarts that make the Game Boy game. The front half is fairly simple in comparison, just an LCD and a few buttons. By designing an adapter that goes between these two halves, [Zane] and [Joshua] were able to stuff enough circuitry inside the Game Boy to convert the signals going to the LCD to HDMI. Plug that into your TV, and you have a huge modern version of the Super Game Boy, no SNES required.
The HDMIBoy also breaks out the buttons to the classic NES controller connector. With HDMI out and a controller input, the old-school Game Boy become a portable if somehow even more brick-like console.
Homebrew synths – generating a waveform in a microcontroller, adding a MIDI interface, and sending everything out to a speaker – are great projects that will teach you a ton about how much you can do with a tiny, low power uC. [Mark] created what is probably the most powerful homebrew synth we’ve seen, all while using a relatively low-power microcontroller.
The hardware for this project is an LPC1311 ARM Cortex M3 running at 72 MHz. Turning digital audio into something a speaker can understand is handled by a Wolfson WM8762, a stereo 24-bit DAC. Both of these chips can be bought for under one pound in quantity one, something you can’t say about the chips used in olde-tyme synths.
The front panel, shown below, uses 22 pots and two switches to control the waveform, ADSR, filter, volume, and pan. To save pins on the microcontroller, [Mark] used a few analog multiplexers. As far as circuitry goes, it’s a fairly simple setup, with the only truly weird component being the optocoupler for the MIDI input.
The software for the synth is written mostly in assembly. In a previous version where most of the code was written in C, everything was a factor of two slower. Doing all the voice generation in assembly allowed for twice as many simultaneous voices.
It’s a great project, and compared to some of the other synth builds we’ve seen before, [Mark]’s project is at the top of its class. A quick search of the archives says this is probably the most polyphonic homebrew synth we’ve seen, and listening to the sound sample on the project page, it sounds pretty good, to boot.
Vintage microprocessors usually do something, be it just sitting in an idle loop, calculating something, or simply looking cool in a collector’s cabinet. [Lee] has come up with a vastly cooler use for an old microprocessor: he’s anthropomorphized it by wiring LEDs up to the address lines and arranged those LEDs into a face. After wiring up the right circuit, the face of LEDs slowly changes expressions, making this tiny little board react to random electronic fluctuations.
The CPU used for this project is the RCA 1802, best known for being the smarts in the COSMAC Elf, a very early microprocessor training computer, but still capable of teaching the basics of computing today, albeit on a processor that isn’t made any more with an instruction set that is barely supported by anything modern.
[Lee] apparently has a lot of these 1802s, and to show off how simple a microcomputer can get, he created the strangest use for a CPU we’ve ever seen. You can’t program this face of LEDs; the data bus is left floating so random values are ‘displayed’ on the face. Only one of the data lines is pulled high. This prevents the data bus from ever being 0x00, the HALT instruction.
If you’re looking for something a little more useful to do with an RCA 1802 MPU, [Lee] also has a COSMAC Elf membership card. It’s a reproduction of the famous COSMAC Elf, repackaged into a board the size of an Altoid tin. It has the 1802 onboard, a few switches and blinkenlights, and a parallel port for interacting with peripherals.
It’s time once again for Americans to gorge themselves on hormone-laced meats covered in several sauces and gravies, all of which inexplicably contain corn syrup. It’s also Thanksgiving this Thursday, so there’s that, too. If you have a turkey defrosting somewhere, you’ve probably gone over all your cooking options – the oven, a giant propane-heated pot of peanut oil, and yes, even sous vide. [Trey] over at TI came up with a great sous vide controller using a few LaunchPad Booster packs, and surprisingly, he can even cook a turkey.
The basic idea of sous vide is to vacuum pack your protein, put it in a closely-controlled water bath, and cook it so the inside is always the same temperature as the outside. It’s delicious, and it takes a long time. We can automate that, though.
[Trey] is using a USB LaunchPad and a thermocouple BoosterPack to monitor the temperature of a water bath. A custom SSR board is wired right into the heater, and a CC3100 provides a network connection to monitor the bird. While the network may seem a bit superfluous, it’s actually a great idea; sous vide takes hours, and you really don’t dote on your warm tub of water. Being able to receive SMS alerts from a sous vide controller is actually a great idea.
With everything wired up, [Trey] tried out his recipe for deep-fried turkey porchetta. From the pictures, it looks great and according to [Trey] it was the juiciest turkey he’s ever had.
Launched in 1978, the International Sun/Earth Explorer 3 was sent on a mission to explore the Earth’s interaction with the sun. Several years later, the spacecraft changed its name to the International Cometary Explorer, sent off to explore orbiting ice balls, and return to Earth earlier this year. Talking to that spacecraft was a huge undertaking, with crowdfunding campaigns, excursions to Arecibo, and mountains of work from a team spanning the globe. Commanding the thrusters onboard the satellite didn’t work – there was no pressure in the tanks – but still the ICE mission continues, and one of the lead radio gurus on the team has put up the telemetry parser/display crafted for the reboot project up on Github.
The guy behind the backend for the ICE/ISEE reboot project should be well-known to Hackaday readers. He’s the guy who came up with a Software Defined Radio source block for a cheap USB TV tuner, waking everyone up to the SDR game. He’s also played air traffic controller by sitting out near an airport with a laptop, and has given talks at Black Hat and DEFCON.
The ICE/ISEE-3 telemetry parser/display allows anyone to listen to the recorded telemetry frames from the satellite, check out what was actually going on, and learn how to communicate with a device without a computer that’s rapidly approaching from millions of miles away. He’s even put some telemetry recordings up on the Internet to practice.
Although the ICE/ISEE-3 reboot project will have to wait another decade or two until the probe makes its way back to our neck of the woods, [Balint] is taking it in stride an organizing a few Software Defined Radio meetups in the San Fransisco area. He just had the first meetup (Video below) where talks ranging from creating a stereo FM transmitter in GNU radio, a visual introduction to DSP for SDR and SETI signals from the Allen Telescope Array were discussed. There will be another meetup in a few weeks at Noisbridge, with some very cool subjects on the roster.
Continue reading “Open Sourcing Satellite Telemetry”
Quick, how do you wire up an SPI bus between a microcontroller and a peripheral? SCK goes to SCK, MISO goes to MISO, and MOSI goes to MOSI, right? Yeah. You’ll need to throw in a chip select pin, but that’s pretty much it. Just wires, and it’ll most likely work. Now add a second device. The naïve solution found in thousands of Arduino tutorials do the same thing; just wires, and it’ll probably work. It’s not that simple, and Mr. Teensy himself, [Paul Stoffregen] is here to show you why.
When using multiple SPI devices, a pullup resistor on the chip select lines are a really great idea. Without a pullup, devices will work great when used alone, but will inexplicably fail when used together. It’s not magic; both devices are listening to the bus when only one should be. Putting a pullup on the CS lines keeps everything at the right logic level until a device is actually needed.
How about the MISO line? Most peripherals will disconnect their pins when the chip select signal is active, but there are exceptions. Good luck finding them. There is an easy way to check, though: just connect two resistors so the MISO line floats to a non-logic level when the CS pin is high, and check with a voltmeter. If MISO is driven high or low, you should put a small tri-state buffer in there.
That just covers hardware, and there are a few things you can do in software to reduce the number of conflicts when using more than one SPI device. One of these methods is transactions, or defining the clock rate, setting MSB or LSB first, and the polarity of the clock. Newer versions of the Arduino SPI library support transactions and the setup is very easy. In fact, transaction support in the Arduino library is something [Paul] worked on himself, and gets around the problem of having SPI-related code happening in both the main loop of a program and whenever an interrupt hits. Awesome work, and a boon to the Arduino makers around the world.