I recently purchased the USB Weather Board and am having what appears to be major problems with accuracy of temperature and humidity readings.
I plug the board into USB and connect with Windows Hyperterminal. As I watch the temperature and humidity readings, they appears to be way off. For example, when the room temperature is 72 degrees, I see temperatures of 80 and 81 degrees reported from the two sensors. Humidity appears to be even further off. I have two digital room hygrometers of good quality. They agree within a few percent on humidity readings in the room. When I place them next to the Weather Board, they read (for example) relative humidity levels of 41 and 44 percent. Meanwhiile, the Weather Board reports a relative humidity of of 27 or 28%!
Also, the readings change significantly with time, even though conditions in the room are not changing. It is not unusual to see the temperature rise by 5 degrees or more and the humidity drop by 10% or more during the first 5 minutes after I power up the board.
Has anyone else tested the accuracy of their USB Weather Board? Am I doing something wrong? Could I have a defective board?
Sounds like the SCP1000 is being incorrectly initialized. I have a “bare SCP1000” (on a breakout board) and if you omit the “set device into low noise” setting, not only is there about 0.3-0.5 degrees C worth of noise in the temperature reading, it overreads by around 4 celcius. The SCP1000 will also give a slightly incorrect (with abotu 2mb of noise) over-reading of around 4 millibars if the sensor is not set to ‘low noise’ mode.
This will put all your calculations off for relative humidity if the SHT15 reports dewpoint rather than RH. (Personally, for my weather sensors, I use the SCP1000 for pressure only, and the SHT7x which has a temperature and humidity sensor in the same package).
The SCP1000 is very accurate when it’s in “low noise” mode. What doesn’t help is there are two versions of the SCP1000 ASIC. If you have the latest datasheet, it’s only for the latest revision of the SCP1000, and omits to tell you about “low noise” mode (as well as a command to make the sensor set its MOSI line into high impedance state when it’s not selected) because these things aren’t necessary with the latest version of the SCP1000. Sparkfun’s SCP1000 breakout boards at least use the earlier revision of the ASIC which require both these things to be done - and you only know you have to do these things if you have the datasheet for that particular revision of the sensor.
Therefore I suspect the firmware on the USB Weather Board’s microcontroller probably needs an update; go to the VTI website and have a look at the data sheet for the earlier revision of the SCP and see what I mean. Indeed, the thread I put a link to earlier very strongly suggests that the firmware needs updating.
Thanks for the response. Actually, I have not yet looked at the barometer reading (other than to verify that it is there) - I’ve been more interested in getting an accurate humidity reading and will investigate the barometer output later.
I did check the datasheet for the SHT-15 humidity sensor, and confirmed that the accuracy is supposed to be within 2% (between 10% and 90% RH). One thing I noticed in the datasheet is that the humidity sensor has a built-in heater which can be activated. However, this is supposed to be off by default, and based on the datasheet turning it on raises the temperature by more than the error I am seeing. Although I didn’t download the firmware from my board to verify exactly what is loaded, I did have a peek at the the firmware listing on the site and didn’t see anything that appears it would turn on the heater for the humidity sensor. Any errors that are occurring due to firmware problems with the pressure sensor presumably would not affect the humidity reading, since the SHT-15 outputs the humidity reading already corrected for temperature.
I’m curious as to anyone else’s observations regarding humidity accuracy. Of course, I could modify the firmware to add a correction factor for humidity, but the fact that it is off by so much makes me think there may be another problem which will prevent accurate readings even with a correction applied.
I think I figured out what is happening, although I’m not sure there is much I can do to fix it.
I ran some more tests this evening. Using an infrared thermometer, I measured the temperature at various parts of the board. I find that the values being reported are correct - the board is actually heating up.
The room temperature during the tests was 71 degrees. I measured temperatures of 84.5 degrees (USB chip), 83 degrees (ATMega chip), and 82 degrees (LEDs). The temperature at the SHT sensor read 81 degrees. It is showing up as 82 degrees in the measurement. The temperature at the pressure sensor read 78 degrees. It is showing up as 79 degrees in the measurement. To further confirm what is happening, I tried briskly fanning the board, and was able to get a drop of about 3 degrees in temperature, and a corresponding rise of about 5% in humidity. The readings returned to their former values gradually over the next minute or so.
Presumably the SHT sensor is in fact reading the humidity it senses. Since its temperature is about 10 degrees above ambient, this would tend to drive moisture away, accounting for the around 15% low reading for humidity.
I’m not sure how to improve this. Certainly I could disable the LEDs, but they are accounting for less heat than the chips. Even if I were to make the ATMega chip sleep most of the time (say waking up once a minute to record readings), the USB chip would still be generating heat (it read hotter than the ATMega). One idea would be to only apply power long enough to take a single reading every minute or two. It may be possible to turn power off to the USB port on a PC via software (I have not investigated this yet). Of course, that would only work if getting the readings via USB (i.e. not RF).
I did check the barometer reading and found it to be accurate. Converting to inches of mercury, it reads 0.92 inches below the barometer reading at the nearest airport, and my elevation is around 850 feet.
I’m thinking that future versions of this board (mine is version 1) should probably be constructed with the sensor chips insulated from the rest of the board.
fgk:
I ran some more tests this evening. Using an infrared thermometer, I measured the temperature at various parts of the board. I find that the values being reported are correct - the board is actually heating up.
The room temperature during the tests was 71 degrees. I measured temperatures of 84.5 degrees (USB chip), 83 degrees (ATMega chip), and 82 degrees (LEDs). The temperature at the SHT sensor read 81 degrees. It is showing up as 82 degrees in the measurement. The temperature at the pressure sensor read 78 degrees. It is showing up as 79 degrees in the measurement. To further confirm what is happening, I tried briskly fanning the board, and was able to get a drop of about 3 degrees in temperature, and a corresponding rise of about 5% in humidity. The readings returned to their former values gradually over the next minute or so.
Presumably the SHT sensor is in fact reading the humidity it senses. Since its temperature is about 10 degrees above ambient, this would tend to drive moisture away, accounting for the around 15% low reading for humidity.
I’m not sure how to improve this. Certainly I could disable the LEDs, but they are accounting for less heat than the chips. Even if I were to make the ATMega chip sleep most of the time (say waking up once a minute to record readings), the USB chip would still be generating heat (it read hotter than the ATMega). One idea would be to only apply power long enough to take a single reading every minute or two. It may be possible to turn power off to the USB port on a PC via software (I have not investigated this yet). Of course, that would only work if getting the readings via USB (i.e. not RF).
I did check the barometer reading and found it to be accurate. Converting to inches of mercury, it reads 0.92 inches below the barometer reading at the nearest airport, and my elevation is around 850 feet.
I’m thinking that future versions of this board (mine is version 1) should probably be constructed with the sensor chips insulated from the rest of the board.
Frank
In the data sheet on page 7 for the SHT15 has some mounting examples to minimise heat transfer from the PCB. I don’t have the weather station myself, but looking at doing my own atm, hence came across this thread.
Is there enough room around the sht15 to do as described in the tech data sheet? i.e no pcb traces etc, I know it should have been done as part of the PCB design, but to improve it after the fact you may be able to drill around it.
anybody manage to slow down the atmega chip? If so, how (am newbie)? I see the same phenomena on mine: about 5C higher temperature at the end-state condition, with rise time of about two minutes from the time the board is powered-on.
I’m not looking forward to doing the tedious measurements required to do a compensation map. It’s tedious enough just w/ temperature; if humidity ends up playing a role in the heat-transfer from the PCB (when encased) it’ll be truly evil to produce that compensation map.
note also that I’m not completely sure that the heat-transfer is totally via the PCB board; when I turned the orientation of the board from horizontal to vertical with the sensors (mostly) below the heat-producing chips, the temp readings came in about 0.5C lower. This indicates that some of the transfer is via air and/or radiation.