With the testing of the AVR Data Recorder completed and a few sample test runs, I was fairly satisfied with the performance and features I was able to pack into this little device. The flexibility, hardware support and program-ability of using AttoBASIC as the underlying “operating system” allowed me a level of features that I have not seen in other data recorders on the market.
In using the AVR Data Recorder, I found that there were two features that I wanted to add.
- Low battery detector
- Temperature and humidity measurement
Low Battery Detector: In hindsight, I realized that I had not included a means to measure battery level, report and act upon a low battery condition. The AVR series of micro-controllers supports a “brown out detector” but all it really does is set a flag in the MCU status register that a power supply voltage less that a preset value occurred. The AVR can then respond to that condition. However, in the case of the AVR Data Recorder, there wasn’t much I could do since AttoBASIC does not process nor respond to “brown out” conditions. I also did not have any extra analog channels (nor pins) available to monitor the battery, which could easily have been accomplished using AttoBASIC. I began looking for an external “low-battery” detector circuit. I found a few designs in applications notes from MICROCHIP, LINEAR TECH and TEXAS INSTRUMENTS using their very-low power op-amps but in investigating their actual run current, I found that they would just add to the battery drain more than I wanted.
Not being satisfied with those solutions, I decided to investigate the power requirements of using an 8-pin TinyAVR. I had a tube of ATtiny13A’s available as well as some ATtiny25’s, 45’s, and 85’s but those would be an overkill in terms of available FLASH memory. The ATtiny13 looked like the right choice. It has an internal 1.2 MHz oscillator, an ADC and a few I/O pins. It would have to run off the 3 volt supply of the AVR Data Recorder but the Li-Ion cell could attain a charged voltage of 4.2 volts, too high for a direct ADC input. A simple solution was to add a resistor network voltage divider before the ADC pin but I wanted to conserve power and using the ADC would use extra power. The analog comparator uses very little power, so it was a good choice. I figured I could set a threshold for the analog comparator “AIN1” reference input by using one of the PWM channels to create a “poor-man’s” DAC, which requires only a resistor and capacitor and the original voltage divider method works with the analog comparator as well. Using the PWM to set the reference voltage allowed me to implement a sort-of hysteresis along with a voltage averaging to minimize variation in the battery voltage readings.
To warn the user that the battery is low, I decided to add an LED that I could “blink” every few seconds. In testing, I settled on a 64 mS “blink” time and a low-current red LED.
Like all AVR’s the ATtiny13A could enter a low-power sleep mode and I could use the watch-dog timer to wake it with a “system reset” every 8 seconds, which is the longest timeout available for the watch-dog timer. Essentially, I would just run through the program sequentially from RESET to END with each timed “wake-up”.
The program sequence is as follows:
2 load preset AComp reference value
3 set I/O ports
4 set PWM to reference voltage
5 wait for PWM to settle
6 check analog comp
7 if low-battery detected
a) set LED on
b) set WDT for IRQ @ 64ms
c) sleep till WDT IRQ
d) set LED off
8 reset I/O ports
9 sleep in “power-down” till WD reset
The power consumption measurements were as such:
- AVR in powerdown = 4 uA
- AVR executing code for 64ms (setup and measure) = 160 uA
- AVR + LED “on” for 64ms = 1300 uA
The average power consumption = 125 uA with LED on, 42 uA with the LED off. It
beat the micro-power comparator in half as many parts!
Below, in the photo on the left is the Low-battery detector installed in the AVR Data Recorder. On the right is the component locator of the Low-battery detector.
The AVR Low-battery detector was a separate project but it was inspired for the need on the AVR Data Recorder. I may create a separate project log for it at a later date.
Temperature and Humidity measurement: One day, I found I had a need to monitor temperature and humidity conditions at a storage location that I had been using. Not having any means to capture and log temperature and humidity changes spurred an addition to the current design. I had already been working with the DHT-22 series of temperature and humidity sensors, even added support for them into AttoBASIC but my AVR Data Recorder lacked that feature. All I needed was one free I/O port, which I didn’t seem to have. In the original design, I had planned to use the ATmega328P’s internal 8 MHz oscillator BUT in case I needed lower power and a more accurate timing frequency, I designed in a 4 MHz crystal oscillator using two extra 74HC04 inverters. It’s output directly fed the ATmega328P’s X1 input through a jumper. I decided that I would use the X1 pin as an I/O port for the DHT-22. There was enough room on the back panel to add it and the plastic was soft enough to cut with a carpet knife and so the DHT-22 was added.
The photo to the right shows the DHT-22 set into the left side (upper-left in the photo) of the back panel.
I charged the AVR Data Recorder and took it over to the storage location to leave for a week’s time. In my power calculations, I estimated at least 14 days of recording capability but figured that the “data file” would be filled long before then. I wrote the simple AttoBASIC program to capture and log the RTC time-stamp, integer temperature and humidity. I then retrieved the AVR Data Recorder and the data from it then created a spreadsheet to plot my data. I also added the daily high and low temperature readings to the data so I could see if the storage unit was truly “climate controlled” as I was paying extra for that feature. The resulting graph is shown below.
As can be seen, the temperature remains fairly consistent around 78° F but the humidity fluctuates between 71 and 84% RH. Being that the temperature in the facility seems to be set at 78° F, it is not possible to remove the excess moisture from the environment, so I would not necessarily consider the storage facility to be “climate controlled” because the excess moisture in the air causes the most damage in a closed environment, not to mention that it tends to encourage mold and mildew growth. If I am not mistaken, I believe that in order to maintain a low humidity environment, the temperature needs to be at least 75° F. Having the data in hand to support my complaint, I contacted the facility manager but she refused to adjust the temperature in the facility to 75° F or even 76° F saying that “it would cost too much in electricity“. As is typical with businesses, they tend to cut costs by providing only enough of a “feature” to justify the extra expense of said “feature”.
The AttoBASIC program used to capture and log the RTC time-stamp, integer temperature and humidity is shown below.
5 EMI $0C # CLEAR SCREEN 10 DFV 0; DFI 0 255; DFX # CLEAR ALL PAGES OF DATA FILE 15 RTI 2 # SET 100MS RTC INTERVALS 20 DHU 0; DHS 0 # SET DHT READING PARAMETERS 25 RTR # RESET RTC TO ZERO 30 DHT # TAKE A DHT READING 35 A:=PEEK $5 $69 # FETCH THE DATA FILE HIGH POINTER 40 B:=PEEK $5 $68 # FETCH THE DATA FILE LOW POINTER 45 M:= A= $FF; N:= B> $FE # TRICK TEST FOR ADDR=0XFFFE 50 IF M & N THEN GOTO 125 # IF LAST ADDRESS, EXIT 55 DFL PEEK $5 $63 # FETCH RTC BYTES (ALL FOUR) 60 DFL PEEK $5 $64 65 DFL PEEK $5 $65 70 DFL PEEK $5 $6A 75 DFL PEEK $5 $6C # FETCH DHT INTEGER TEMPERATURE 80 DFL PEEK $5 $6D # FETCH DHT INTEGER HUMIDITY 85 PRI "RTP: "; RTP # EMIT A USER MESSAGE 90 PRINT "*F : "; PRINT PEEK $5 $6C # EMIT A USER MESSAGE 95 PRINT "%RH: "; PRINT PEEK $5 $6A # EMIT A USER MESSAGE 100 PRINT "===============~" # EMIT A USER MESSAGE 105 FOR N= 1 75 # SET UP LOOP FOR 5 MIN DELAY 110 SLP 8 # WAIT 4 SECONDS (75 * 4 = 300) 115 NEXT # END LOOP 120 GOTO 30 # LOOP TILL DATA FILE IS FULL 125 DFF 6 # SET FORMAT TO 6 BYTES/RECORD 130 END # END
Note that the “SLP 8” instruction reduces power consumption by the ATmega328P by placing it into the “idle state” and uses the internal watch-dog timer as the “wake” interrupt source.
Additional observation: Also in hindsight, I should have used the ATmega32U4. I have been using this part in another project for a few years. It has a built-in USB interface, a “bipolar” ADC and a few extra I/O pins.
This entry completes the project log for the AVR Data Recorder.
Peace and blessings.