Archive for April, 2009
Video of the iPhone TV Lift controller working!
This was probably one of my most time consuming projects. Hopefully I can do some justice to the time and work spent through this post. I should probably begin by describing the whole system. First, the TV is lifted up & down by a “Lift Tech” lift. By the way, they get the prize for the most original company name ever. Their controller box has a port that allows home automation systems to control its operation. They did a really good job of making it extensible. You can control it in a variety of ways: short one pair for going up, another for going down; short a pair for down, open for up; etc. I had intended to use the first mode, but I think I fried a channel on my opto-isolator. I ended up using the second method because it only required one channel. Unfortunately that means I can only have the TV up, or down. I wasn’t too disappointed, though, because I don’t expect to want it any other way very often 😉 .
The board I designed to interface the TV Lift to the server was fun to design and build, even though it was prone to error. I had originally intended to use the Microchip ENC28J60 ethernet controller. I thought it’d be cool to have the iPhone app connect directly to the board’s ethernet controller and microcontroller. Unfortunately, I screwed up the interface from the ethernet controller (specifically the physical layer circuitry) and the magnetics. This interface is harder than it looks, trust me. I thankfully included a serial port on the board (which I had other plans for) and used that instead. This choice made the microcontroller software extremely simple. All it really has to do is wait for a ‘d’ character over the serial port and lower the TV, a ‘u’ character lifts the TV, and a ‘s’ character queries the controller for the current state. I’ve included an image of the schematic for the board, in case you are curious about my lofty intentions.
If you’re interested, the board I used on my reflow soldering toaster oven page is the TV Lift board. Incase you don’t want to go over there, here is a picture of it mostly finished up:
There is one more thing that I had to change. For some reason the controller board that I made crashes after a while. I have to use a ladder to reboot it (power-cycle). Hauling the ladder around is annoying, and I don’t like doing it. To allow myself to reboot it remotely, I added a diode from the MCLR line (reboot) of the microcontroller to the RTS line of the serial port. The RTS line is used for modems from back in the day. Now I can use it to force MCLR low, to reboot the controller, if it’s “low” (-5 volts). It’s a hack, but what are you going to do?
The software for this project is deceptively simple. The iPhone software basically connects to the server using a socket, and if the “up” button is pressed it sends a ‘u’ over the socket, and a ‘d’ if the down button is pressed. That’s it! Server software is almost identical, however it listens to the return of the serial port and expects my controller board to return a ‘U’ or a ‘D’ from the ‘u’ and ‘d’ command. If these are not received, the board is reset and the command is tried again.
Well, that’s all there is. I hope you’ve enjoyed it, I know I have. Please, feel free to ask any questions in the comments section!
I’ve finally gotten my home weather station online! I’m using a Oregon Scientific WMR918 system with anemometer (wind speed), wind direction, temperature, humidity, and barometric pressure sensors. Click here to access the current and recent readings, or the beta version of an integrated page (also available in the navigation bar below the blog title) and “read more” to find out how it works.
The WMR 918 has a serial port that sends-out all the data that it collects (and lightly processes). I have this signal going into my home server, which is running the open source wview. Because my weather setup is a bit different than what is typical, I had to make some changes to the source code. (probably the best part about open source!) I guess most weather stations come with a “mushroom” sensor which is a thermohygrometer (temperature and humidity) that is encased in a radiation shield (so direct sunlight doesn’t affect the readings). I don’t have one of those. My outdoor temperature sensor is reported differently on the serial output. The wview software was expecting a certain kind of data packet, and having never gotten it, it never initialized. Once I changed the source code so that it ignored the difference I was all set. B.T.W: The thread about this process is on the wview google groups page.
I’ve gotten the data up in several personal weather aggregation services. I’ve decided that I don’t really like weather underground (way too cluttered), but I’m up on PWS (Personal Weather Stations), and APRS (Automatic Position Reporting System). APRS is a weird amateur radio thing. Basically, what it was designed to be is a way for small bits of digital data to be passed around so that, especially during search-and-rescue, operators can know where one another are. Over the years it has been expanded to include many interesting uses. One of which is the sharing of personal weather station observations. Eventually, NOAA even started using the data in their models. One of the many things I want to do, one of these days, is install a APRS node in my car. I know it is geeky to the max, but that is what I am.
Anyway, back to the point, everything works! I hope you enjoy the fascinating (not really) weather trends from Philomath Oregon! Oh, and hopefully soon I’ll have a handy widget that displays a digest of the current conditions in this sidebar. But for now, feel free to check the current conditions page.
I’ve decided to spend some time profiling the toaster oven. In addition, I’ve made a simple controller board that may get the brains to manage a reflow operation on it’s own one day. For now, I’m satisfied learning more about the oven’s capabilities. An interesting thing to notice is that it (appears) incapable of satisfying the recommended profile from Kester.
I wanted to start with a very simple controller that gets most of it’s brains from an attached computer. This is a somewhat central tennant of the way I build most projects. The reason for this is that computers have really huge screens, and nice keyboards so it’s easy and cheap to have a cool UI. For this project I’m still working on the OpenGL for the realtime graphing of the temperature profile, but you can see what I have designed so far:
The left side of the window is where the realtime graph window goes, the oven system status is in the upper right, with the reflow profile defined by the user in the bottom right. Anyway, back to the controller hardware.
The controller is built around a PIC microcontroller and the MAXIM 6675. The 6675 is a thermocouple conversion chip that handles all the analog complication of dealing with thermocouples (including cold-junction temperature). The microcontroller interfaces with it through a simple synchronous serial protocol. One thing that you have to keep in mind with this chip is that if you request a sample more than 4 times a second then it doesn’t finish the conversion. I decided to let the microcontroller handle waiting for the appropriate amount of time, taking a sample, and sending the data over the serial port.
Because computers don’t have serial ports anymore, I have to include serial to USB converters on everything. In this case I used the FT232RL schematic block that I copy and paste whenever I need it. Here is an image of the completed schematic (Full size PDF):
Like almost all my projects, I got a board made at BatchPCB. It turned out great:
Unfortunately, I wasn’t able to find a nice socket for the somewhat standard plug they put on the end of thermocouples. In this case, I just used a screw terminal. The posts on the left go to the thermocouple wires. I’ve included another pair for adding a relay that could be used to switch power to the oven. Also, I’ve included a port that could control a R/C servo that could open the front door to facilitate rapid cooling of the oven. Eventually, I’d like to allow this controller to begin a reflow cycle when the button in front is pressed, runs until the target temperature is reached, shuts off power, and opens the door at the perfect time. For now, I still have to watch and stop when I feel it’s right.
The thermocouple is installed just by using the friction of threading it through the oven rack that is installed above the board.
To keep everything relatively tidy, I double-stick taped my controller to the side of the oven:
Finally, I’ll analyze the graph from the beginning of the post. For you’re convenience, here it is again:
The blue graph is the recorded profile used while soldering an actual board based on my observations. I stopped the oven cycle based on the advice I gave in my other post about the Toaster Oven Reflow Soldering post. For the Green trace I ran the oven until the thermocouple read 210°C. I decided to run it without a board in it because I didn’t want to smell burning FR-4 ;). I’m not saying that it would have actually burned it, but I realize now that I really need to calibrate my thermocouple against a trusted reference thermometer.
To compare the actual results against the specifications in the Kester datasheet, I’ve included a line for the maximum and minimum profiles. For the preheat phase of the profile all that is required is that the temperature increases less than 2.5°C/second, up to 150°C so I didn’t include it. Once it reaches 150°C the temperature needs to increase between .5 and .6°C/second up to 180°C. From 180°C to 210°C temperature needs to increase at a rate between 1.3 to 1.6°C/second. As you can see the toaster oven almost keeps track with the 150-180° rate, but can’t achieve the 1.3-1.6°C/second ramp rate. I’m not sure what the exact effect of this is, but I’ve had good results so far.
Anyway, it was an interesting exploration. I do kinda wish I was able to match the correct profile, but I’m glad in a way that it doesn’t because I don’t have to implement a PID temperatue controller :).