As in any design development, there are challenges with the parts that one specified. I happened upon the DHT11 temperature and humidity sensor because of its dual function. It would turn out it was fun while the curiosity lasted. I have 3 of this and found that they are worthless junk. The temperature reading often jumps around 2 degrees, and at time 8 in consecutive samples. Also all three are extremely inaccurate. I had play with the Maxim DS18B20 quite early on and found them to be very accurate for solid state active sensor. One reason reason that I didn't choose it was my attracted to the DHT11's humidity capability. The bigger reason is the library for the DS18B20 is very memory intensive, and I had ran out of program memory as well as SRAM.
Now that I have gave up on the DHT11, I decided to give the DS18B20 another try. I want to have three of it in the multi-function display. One for the cabin temperature, one for outside temperature, and one for engine oil temperature. Actually, I may have one more movable one for data logging use. The worst part of the DS18B20 is that each has a unique 8 byte address, and relatively software intensive to communicate with them. The best part, however is all you need is one digital i/o pin for interface to it, and what is more you can literally have countless DS18B20 all sharing this one single pin. This is due to the unique 8 byte address each has. With this benefit comes the disadvantage. With a few of this sensor, one can consume much of the precious memory.
the very inaccurate DHT11 temperature accuracy +/- 2 degrees C or worst
the "newer and improved" DHT12
For a very long time the Fluke Hydra data logger was very popular. It cost a few thousand dollars.
here is a pre-own Fluke Hydra data logger for over $2000
I worked on the code last night. I commented out the DHT11 and wrote a function call for the DS18B20, anticipating that I would have multiple of them. Instead of using the easy to use library for it I use a lighter weight onewire library which do all the heavy lifting of bit-banging and the timing of the 1 wire serial interface. I was able to keep the memory use comparable to that of the DHT11. Today, I also tested out the sensor's operation with a very long cable. I did this because the engine oil temperature requires a cable length between the rear mounted engine and the cockpit of the Vanagon, which would work out to about 18 feet. It worked since the data rate is quite low.
Today I order a bunch of DS18B20, some on tiny PCB, and some in metal casing. They average to under $1.50 each shipped from China (and Hong Kong)! They will take a few week to arrive so for now I have to live with the only one I have.
It may seem so pity that I have to give up the ability to measure and log humidity. The truth is humidity is one of the most difficult parameter to acquire. I am suspicious with most consumer grade humidity sensors. Measuring humidity requires the sensor to be exposed to ambient air and its water content. The obvious problem is over time the sensor inevitably accumulate contaminants in the air and the sensor accuracy deteriorates. I am sure this problem will plague the DHT11. So for me the DHT11 is just a toy; and a worthless one.
Once I have the code modified to use the DS18B20, a problem became apparent. My joystick user interface at times became sluggish. The audible acknowledgement lags behind the user input. It is due to the slow conversion time of the DS18B20. It support 3 programmable precision with the highest 12-bit converter precision taking the longest time of 750ms. The need to wait for the conversion in my algorithm was what kills the joystick responsiveness. To fix this, I modified the function that interacts with the sensor. Instead of waiting around for the conversion to complete, the function returns immediately after initiate the conversion so the other tasks, like the joystick related code, would not be starve of processing time. This is just a simple technique by using a ticktock flag. In the first call of the function the ticktock flag's tick status tells the function to initiate a new conversion. The function then toggles the ticktock flag to tock. The next time the function is called, the ticktock flag signals it that it is time to go retrieve the converted data from the chip. In the other word, each temperature update requires two calls of the same function.
The beauty of this approach is, I can process all 3 or more DS18B20 at the same time. Since there is no repetitions of the same code it is scaleable to many sensors with very small incremental use of precious memory. Right now I have the code set up for 3 DS18B20 but can easily add more if I choose to. The incremental price is just 8 bytes of flash and 2 bytes of RAM for each additional sensor. I plan to put one of this DS18B20 into the housing of the dumb oil sensor and pot it with epoxy.
So far in this project, I am beginning to exhaust the I/O capability of the AtMega328 uC. I am also making good use of the main interrupt handling features. This afternoon, I would spend some time characterize the transfer function of the solid state oil pressure sensor. I have decided not to use the VDO type due to their very low resistance. I also distrust these cheap senders' construction thinking of the possibility of the failure of the housing.
dumb VDO compatible oil pressure (left) and temperature (right) senders
solid state 5V oil pressure sensor (top) in the pancake oil filter adapter
It was easier than done characterize the oil pressure sensor. I could not find a proper 1/4" NPT female adapter to fit the sensor onto a pressurized air. I planned to use my air compressor's pressure gauge as reference, at say 5PSI interval between 0 and 80PSI. By measuring the voltage of the sensor output I could make a plot and find the relationship between them. I could drive to nearby Home Depot to pick up some brass fitting, but I decided to rough it out with my hands. I figure I can play Dutch boy to stamp 80PSI of pressure.
here I used a DMM to measure the sensor output voltage against the air pressure at 5PSI increments
here I check the coded multi-function display against the compressed air pressure again
The sensor's voltage turns out to be very linear with respect to the pressure.
a plot of sensor voltage versus pressure in PSI
A bit of simple algebra P = mV + b where m is the slope and b is the intersect, and I found the equation. P = 19.753 * V - 9.876. This is the equation that I use in the Arduino code. After coding the equation, I check the pressure as shown on the OLED display by applying 60PSI of pressure to the sensor again to verify the software. The display shown about 58PSI. I think it is close enough. The 2 PSI of difference is due to a number of factors. The largest one is the difference in the 5Vcc. When characterizing the sensor I used a bare Arduino Uno which measured 5.10V. The complete system however measures 5.00V because of the added components. I think if I just multiply the right side of the equation with a fudge factor of 5.1/5.0 I can get it closer.
Now both the oil pressure and temperature sensors are coded, I am closer to start integrating all the loose components onto the data logger shield (the backpack board that is on top of the Arduino Uno).
There is nothing like the thrills of risk taking. I have been buying these cheap thrill electronics from Banggood and eBay. However, sometimes I found both to be expensive on certain items. I have been wanting to give Aliexpress a try but felt uncomfortable with the payment methods. No more. For the reward of saving a couple of $USD I took the plunge into the safety of Alipay. I bought a couple of the OLED displays and some schottky diodes.
No comments:
Post a Comment