I wanted to fool around some more with the MSP430 and an IR receiver IC I’ve been sitting on for awhile. I have a few TSOP3823 receivers ordered from Mouser some weeks ago and haven’t done anything with them yet. So I dug out an old IR remote from the junk box, one that came with an Hauppauge video card that I built my MythTV box around years ago and didn’t need. It happens, I discovered, to use the Philips RC5 data protocol.
The RC5 commands are made up of fourteen bits. The first two are start bits, which are always high. The next is a toggle bit that, well, toggles, with each keypress to make a distinction between holding a key down and letting it auto-repeat, or two presses of the same button. Next come five address bits, for controlling different devices that may all use the same RC5 commands. A remote that is capable of controlling a TV and other components would use this to target one device specifically, though they may all use the same command set. Lastly comes the six command bits. This is just a six-bit binary number indicating which button was pressed on the remote.
The TSOP receivers detect the IR output of the remote control and strip away the (in this case) 36kHz carrier signal, and output the stream of 14 bits at logic levels, so they can be decoded by a microcontroller directly. They can operate at up to 5 volts and below 3.3 volts, which is where I will use it for the MSP430.
My code for parsing the IR data and switching a couple of LEDs on and off can be found here.
I have just added a Mastech HY3005F-3 power supply to my bench. But first let’s take it apart and see what it can do.
I got it from Amazon for around $200 USD, free shipping. I want to see if it delivers on its promise of 5 amps and test out the constant voltage and constant current modes, and just generally abuse it a little and get a feel for using it on the bench.
Merlin is one of the first electronic handheld games to come along in the 1970s. It was made by Parker Brothers and was quite the hot item when I was a kid. With a three by three matrix of LEDs, a speaker and keypad you could play several pre-programmed games like blackjack and tic-tac-toe. This one was made in 1978 and was found abandoned in an old barn in 2008 with ruptured batteries still inside. This week I explore how this icon of my childhood was made and attempt to revive it.
Telequipment is (or was?) a registered trademark of Tektronix U.K., and here is one of the instruments they made in the 1970′s. It is a two-channel 10MHz scope with rechargeable batteries inside, made in England, and is about the size of a shoebox. I’ve had it since 1994 or so, and it has been sitting for at least ten years until I recently decided to revive it. Here is some of the repair work and a teardown. It’s a really charming little device!
The Tektronix 2236 two channel 100MHz oscilloscope, circa 1985, has an interesting multi-function display and built-in multimeter. The display is a nine-digit vacuum fluorescent tube that is used to display AC and DC voltage, resistance, diode check, temperature, frequency and period values as well as the timebase B delay setting and more. It’s a cool thing to have built into a piece of gear like this and not have to give up any more bench space.
But this VFD is aging, and has grown very dim. With the room lights on it is impossible to read. I was inspired by Todd Harrison’s recent video, in which he troubleshoots and repairs the radio in his Jeep. It too has a VFD and had gone out completely. So it was time to do something about this problem and stop squinting and working in the dark. The process led me to a suspect CD4027 J-K flip flop as the culprit, and not having one on hand to replace it
I had the idea of programming a TI MSP430 microcontroller to emulate the behavior of this chip. I did so, and was able to trigger it from the clock pulse on the suspect chip. Then I lifted a few components out of the scope’s display circuit and injected my own flip flop output from the MSP430 back into the scope to drive the VFD.
I had some problems in the code that were exposed when I was trying to add the next part of the project. I needed to put a pushbutton on an I/O pin and catch the interrupt generated when it was pressed. I wanted it to toggle the throbbing LEDs on and off. That’s why using interrupts was so important for this. An infinite loop turning the lights up and down would have had the CPU so busy it would have made the button pushes too unreliable, if it worked at all.
But, when implementing the button I found that it was so busy servicing the interrupts for the PWM changes that it couldn’t catch the button presses at all. It took a few hours of re-reading the docs and trying different things to get it all working, but the real reason for the trouble didn’t hit me until I was recording the video below. New code here.
The TimerA peripheral has several interrupts you can catch. One for TACCR0, which throws a flag every time the timer counts all the way up to the value set in TACCR0 and resets to zero (our PWM period). This one is a higher priority and has a dedicated interrupt vector (TIMERA0_VECTOR). The others are all lumped together and all serviced by another vector (TIMERA1_VECTOR). That one gets a flag when the timer counts up to the value stored in TACCR1 (our PWM duty cycle). My mistake was using this interrupt for the breathing effect, because I was incrementing or decrementing the value in TACCR1 every time it counted up to that value.
What I had created was a condition in which the timer would reach TACCR1, throw the interrupt and run my ISR, which would increment TACCR1 by 5, but then the counter would resume counting up from where it left off and hit the new TACCR1 value… only 5 cycles up from where it threw the last flag… and throw another interrupt! A constantly moving target, throwing many, many interrupts during a single count sequence.It was so busy with that, it was overwhelmed and couldn’t pay attention to anything else. Almost as bad as the endless loop!
By using the interrupt thrown by TACCR0 when it rolls back to zero, the CPU is a lot less busy. Where before I had to skip 300 interrupt calls before running my ISR code, now I only skip 10! It now only increments the duty cycle in TACCR1 once per count cycle.
I’ve been reading the documentation of, and experimenting with a TI MSP430 using the Launchpad board. I have a project in mind that I want to use a slow pulsing “breathing” light effect for an indicator, and set out to figure out how using this chip (in this case the MSP430G2211.
Drive an array of LEDs or other light source such that the light becomes brighter over time, then when the light is fully on, dim it again over the same amount of time.
Learn more about the MSP430 family and how to program them, use the peripherals inside.
Use interrupts instead of loops, to keep power consumption low and be able to carry out several other tasks at the same time.
I started with a PWM code example from the TI library, and read up on using the timers in the MSP430Gx2xx Family User’s Guide, Chapter 12, to figure out how to get interrupts working. Once I did that it was easy to adjust the duty cycle of the PWM output when the interrupt is called. See the code here, and the video below for the results and quick code walk-through.
In the first post I told the story of how I was going through my stack of inverters during a storm and finding them inoperative, and fixed number one. Here is the story of number two, and a demonstration of how to use a cheap incandescent light bulb as a valuable troubleshooting tool to help locate shorts while the circuit is powered up.
My wife and I need our coffee. For years now we’ve used a percolator exclusively, because there isn’t anything to it that could just suddenly fail one day or not work because of a power outage. On numerous occasions we have placed the percolator on the wood stove or on a camp cookstove when the power was out. But a percolator needs looking after. One can’t just set it on the stove and walk away, and come back later when you remember you had coffee started. Our formula looks like this:
Grind beans, fill filter basket, fill with water
Bring to near-boil on stove – about ten minutes.
Turn heat down to simmer for 8 minutes.
A failure in the timing of step two results in coffee boiling over onto the stove top. A failure to observe the timing of step three can make for really strong or burned coffee. But once you know the rules, it’s easy.
We just had a baby five weeks ago. Our first. And in these first weeks we discovered that you have to choose between tending the percolator or tending the baby. Blowing step two or three became an everyday occurrence. While cleaning up the mess for the third time in as many days when I missed the critical step two window, I remembered I had a drip machine that I had saved from the trash pile. It’s a basic model with only an on/off switch and no frills, but works just fine.
One of the missing frills is an auto-shutoff, as most of them have these days, to turn off the burner after a couple of hours to keep from burning the last bit of coffee in the bottom of the pot. It’s easy to forget to turn it off and make a mess out of it, not to mention it sits there using hundreds of watts of power making that mess. I think it needs improving. Let’s add our own shutoff timer!