FAQ
As topics are developed, they will be added here.
Troubleshooting
False EMP sensor readings?
Database reports wrong time or timezone
Sun rise/set times wrong
Database reports wrong time or timezone
Sun rise/set times are wrong
Rain gauge problems
ID-5001 weather station issues
You may discover that the sensor seems to false routinely. I have found, in most cases, it is accurately reporting events. The problem seems to be the detection of lightning events several hundred miles distant. I have two installations that are on rooftops. While one is only about 20' off the ground, the other is in excess of 300'. In both cases, the system ground is the steel framework of the building. The higher the sensor is mounted, the more it hears. The solution is to adjust the sensitivity per McCallie's instructions in their manual.
In a few isolated instances, the detector has reported false strikes. I have tried to find the cause of this, but given the nature of the event, it is difficult to track. However, it does not occur very often.
Problems relating to the interface, including it doesn't work at all, are discussed in the section on the EMP interface.
The interface can be checked by momentarily placing a 100 ohm resistor across the input terminals from the sensor. If the interface is working, a reading of some kind should appear the next time the weather station is read.
Database reports wrong time or timezone
Time zone data is derived from the entry in the geographic database that corresponds to your QTH. Using this and the computer clock itself, the correct time is determined. Using configuration settings, the server will calculate the correct local time, compensating for DST, and also determine the correct UTC. All network data - received or transmitted - references times to UTC. If the wrong time is displayed, the problem can be traced to one of the following causes:
1. Wrong time zone specified in the database. Be certain the field for the timezone is correct for your location. For example, southwestern Indiana is in the Central timezone (UTC-6) and observes DST. Most of the rest of the state is on EST (UTC-5) and does not observe DST. Make sure you have the correct zone entered.
2. Flag set incorrectly for DST in the nodes table for your record. If the flag is set to 'Y', the server will automatically adjust the time for daylight savings as appropriate. This setting is independent of the timezone specified. See discussion in previous paragraph.
3. Operating system time zone is incorrect. The timezone utilities seem to have fewer problems if the system clock is on UTC.
4. Computer BIOS set to compensate for daylight savings time. For the program to work correctly, this must be disabled. The server expects a time source that will not change.
Problems in this area can also be linked to time problems. Be sure the correct local and UTC times are displayed before pursuing anything is this section (see the section on troubleshooting time problems). If the time is correct, then the problem is most likely in the latitude and longitude settings in the geographic database. Check that positive values are used for north and west, negative for south and east. Make sure the two are not reversed (i.e., latitude is in longitude field and vice-versa). Be sure you are using the correct values for your QTH. See the section on the geographic database for more information.
Ultimeter Tenth/Hundredth readout does not agree
ID5001 Readings are intermittent, erratic or non-existant
Wrong Readings After Restart (all except ID-5001)
Rainwise gauge problems
Tenths and hundredths do not agree between station and server
The Ultimeter II was designed to work with a tenth inch gauge. As a result, the station reads wrong (10x the correct value) when a hundredth inch gauge is used. The software knows how to handle this if the correct has been made in wxnhostd.conf.
In the Ultimeter 2000 series instruments, the data stream always reports in hundredths of an inch. The weather station itself must be properly configured for the type of rain gauge installed. Information on how to do this is in the Ultimeter manual. The option is still available on the command line since some earlier units could not be set internally. There might be a slight daily discrepancy as the daily precipitation values are tracked independently in the driver. Unfortunately, there is no work-around for this problem. The clocks in the weather station and the computer would have to be in perfect sync to avoid the problem. The Ultimeter 2000 series reset the 'lower' value every day at midnight. The server uses the 'upper' value (long-term) for it's calculations. The long term setting should not be disturbed unless absolutely necessary. See Wrong precipitation readings for more information.
None/intermittent/erratic readings on ID-5001
The rain gauge circuitry on the ID-5001 does not work well if there are long runs of cable between the weather station and the rain gauge. Additionally, the circuit is not ground referenced. If a long run of the small gauge wire that typically comes with the Rainwise gauges is used, there may be enough resistance to prevent the reed switch closure from tripping the counter in the ID-5001. The solution is to use #16 or #18 gauge cable between the the ID-5001 and the rain gauge.
Wrong precipitation readings after system down
This is not so much a section on troubleshooting, but an explanation of how the accumulated rainfall is handled with all drivers except the ID-5001. Usually, the error is a result of a condition, which the driver cannot anticipate or control.
On all Ultimeter systems, the rain gauge reading is derived from the long-term reading (also known as the 'upper' reading since the up-arrow is pressed to access it). The Ultimeter II does not reset either the upper or lower reading. The 2000 series will reset the lower (or daily reading) regardless. To be consistent in all weather station drivers, I decided to opt for using the long-term reading on all Ultimeter units.
The current reading is derived as a difference between the station's upper reading and the last known good reading taken from the station. The problem comes when the station power is interrupted (or the counters are reset by the user) and the counters are reset. At the next reading, the calculated difference is negative. This would only persist until midnight local time when the driver's internal counter was reset.
In the first effort to resolve this problem, any previous reading for the day was ignored and the internal counter in the driver was reset to zero. The problem with this solution is any previous amount accumulated for the day was lost. In the final solution, the last known good reading is stored at every read interval. It is used to calculate what the reading should have been until midnight local time if a counter gets reset. It does this by adding the new reading on subsequent reads (which are less than the last reading taken before the reset) to the now fixed offset. The result is a correct daily rainfall total.
The problem that occurs now is if the server is down for a period of time, the software calculates the new difference as one five-minute interval when in fact it could be several hours. Only the first reading after a period of downtime would be affected. In any event, the daily amount would be correct.
In most cases, the total amount of rainfall over a period of time is more important to climatologists than an hourly figure.
Some of the newer Rainwise gauges suffer problems due to either the reed switch or physical distortion of the body causing binding within the gauge. I have found that the gauges work best if mounted on a concrete patio block. Depending on the size of the anchor/screw being used, the mounting holes for the gauge might need to be drilled out to the point where the screws slide freely in the mounting hole. When mounting, back off the screws after tightening down so that there is a very small amount of play. This will prevent the body from being warped. If the reed switch is intermittent, you will need to contact Rainwise. Note that the older style gauges that have the aluminum splash guard do not suffer this problem.
ID-5001 weather station problems
If the Heath ID-5001 mysteriously resets itself, loses or gains time, or any other strangeness, it could be the fluorescent lamp and/or circuitry associated with it. At this point, I believe the only real solution is to go to a normal fluorescent supply external to the unit. I have found that while the transistor HV supply from one of the automotive drop lights works well (see Cures For The ID5001 Display), it can cause enough RFI to trash the CPU when the lamp fails.