Phase Two
OK, you have probably finished reading Phase1, and you saw the big ‘ol VFD displaying the temperature channels.
This VFD is 20 char wide by 2 lines … so is that 20×2 or 2×20??? Anyway, it is about 10″ across and 2″ high. It runs off 5 volts DC (onboard inverter and everything else), and accepts plain ‘ol serial data at 9600 8-N-1
Right now, I have the clock up and running (pics soon), and have the user interface for setting the date and time up and running. The clock does ‘military’ 24hr formatted time right now, I haven’t coded a 12hr conversion just yet. Also the DS1307 can keep track of what day it is (but no real calendar like the fancier rtc); but I haven’t added a display screen for it or a way to set the Day of Week, but it is on the drawing board.
My “end goal” is to make this unit into a nice multi-channel temp sensor and also have some data logging capabilities … expanding the I2C bus even further with a 3rd device, I’ll add a 512kbit SEEPROM (writeup coming) to store all sorts of temperatures.
I think this info would be usefull:
- Store for each channel
- 24 Hour Highest and Lowest Temps
- 7 Day Highest and Lowest Temps
- 30 Day Highest and Lowest Temps
- All-Time Highest and Lowest Temps
- Store overall
- Highest Temp Recorded - store channel, date and time
- Lowest Temp Recorded - store channel, date and time
- Running 24 Hr Average for each channel
- Running 7 Day Average for each channel
- Running 30 Day Average for each channel
- All-Time Average for each channel
I can probably think of more, but darn lists are hard in this blog software, so I got bored with that. I also will provide an interface to “name” each channel, like “OD North” for outdoor north exposure and “ID 2nd flr” for indoor second floor. I don’t really want to bother with “scrolling” anything since this VFD flickers bad if you update it too often, so 15 char limit on names should be good… I envision a display sort of like this:
CH03 OD North
Currently +06°c
after a delay
CH05 ID 2nd flr
Currently +26°c
Maybe rotate the bottom line with the 24 hour high and low temps, but I don’t want the “up front” display to have too much information. There will need to be menus to dig into the more historical data. I also want to be able to enable and display channels from being displayed.
Well, I have all my ideas down on ‘paper’, so… I’m signing off for tonight, but rest assured you’ll be seeing more shortly!
Update 10-03-05
I’ve done some work on the way the time and date are displayed. The first line now displays the time center and in 12 hour format, with an AM/PM indicator. The RTC still stores time in 24 hr format, so I should be able to add an option for 12/24 hr. The second line now displays the date like this: Mon Oct 03, 2005 … a little more human readable than 10/03/05 - which means I’ve also coded an interface to program the day counter built into the RTC.
You can see in the above pic that I had not yet set the Day of Week on the RTC.
I’ve merged the temp probe’s diagnostic readout into the program, so the display now alternates between the time and the display of all five temp channels. I’m experiencing intermittent failure of the temp probes, even the internal probe - which suggests either a communication error or a glitch in the code. I’ll be back with my fine tooth comb later.
Work has started on the user interface:
One of the hardest segments I figured was the section to allow “naming” of the temperature channels. This is now done, it has taken several hours. The user enters a menu which allows selection of which channel to edit. Then the channel “name” or label is displayed along with a blinking cursor. Button1 decreases the ascii value of the character under the cursor, button2 increases the value, button3 shifts right to the next character. The ascii values wrap at $20 and $7D which is all that’s really usuable from the standard ascii table. The character position wraps at the end of the display and starts again at the beginning of the label. The labels themselves are stored on a serial eeprom and loaded as needed into microcontroller memory via a byte array. The array is populated from the eeprom as the user selects the channel and a pointer retains the label number for future refrence. After the user has finished editing, the array is saved back to the eeprom, using the pointer to generate a 2 byte eeprom address. Due to some funky rules governing ‘page-writes’ to the eeprom, data has to be written one byte at a time… connection to the eeprom is via 100kbit i2c connection, 15 bytes writes faster than the blink of an eye.
Seeing as how I’m not a very good programmer, my code is nearly 8k … which rules out nearly all the physically small pic micros. I’ll probably go with the newwer PIC18F2550 … it has 32k of program space(!!!) and ooh la la, on board USB 2.0… size is not too bad, 28 pins in a narrow dip or soic package.
Above is a picture of the now full breadboard. From left to right you see; MicroCHIP 24LC512 512kbit (64kbyte) serial eeprom, three volt lithium cell for the clock, Dallas-Maxim DS32KHZ temperature compensated ttl clock, Dallas-Maxim DS1307 BCD encoded real-time-clock, Dallas-Maxim MAX1668 five channel temperature probe. The heavy red, black and green wires near the seeprom are my power supply connection. I have a regulated five amp power supply to run the VFD, since it draws nearly one amp, it is too much for the power supply onboard my pic protoboard. The orange and white twisted board leaving from near the max1668 is the i2c connection back to the pic protoboard. The red and green wires near the max1668 are the power connections to the pic protoboard.
Since I’m now dealing with a user interface, I needed some buttons. I added five tact switches to my pic board, along with pull-up resistors and some pin headers.
That is all for this weekend, but more is on the way… including some pictures. There’s nothing really to photograph yet, but I might dig out a video camera and try to take a quicky of the screens.
Popularity: 2% [?]
