Weather Station Data Logger
for WMR100, WMR200 and RMS300 Weather Stations
Frequently Asked Questions
- I have a question...
Please take a look in the user's manual first. It is very comprehensive and your might just find the answer to your question in there.
If you can't find the answer there, then look through this FAQ list. If that doesn't work, you can post a question on the SourceForge
users forum (Help or Open Discussion -- either one will work). You will need to create a SourceForge account before posting messages in the forums.
I found a bug...
WSDL is getting to be a large program and there will always be bugs. If you think you've found one, please post a message in the
SourceForge forum (either Help or Open Discussion) and we'll take a look. Depending on how easy it is to duplicate the problem,
your assistance may be requested in tracking down the problem.
Why doesn't WSDL support RapidFire updates to Weather Underground?
Although it sounds cool at first (instant weather!) with Oregon Scientific weather stations there is not much point.
Most of the wireless sensors provide updates about once every minute.
As a result, there is little value in sending updates to Weather Underground more frequently than once per minute.
Actually, the wind sensor does update about every 14 seconds and the indoor temperature readings may also be more frequent,
so there would be a slight increase in real data rate with RapidFire.
Also, data uploaded to WU is not the raw sensor data, but time-averaged values and this further reduces the value of RapidFire updates.
I'm having trouble receiving some of the wireless sensors. OS says they will work 300 feet away but I cannot get anywhere near that
level of performance.
First, the obvious: install fresh batteries, reset both the wireless sensor and base console and bring the sensor
indoors, within 10-20 feet of the console. If this doesn't work, there may be a problem with the sensor or base console.
If you get good reception with the sensor located near to the console, but lose reception when the sensor is outside at a greater distance,
there may not be anything really "wrong" -- this is a common issue with OS base consoles (WMR80, WMR88, WMR100 and WMR200).
The receiving antennas built into the console may not have enough sensitivity to pick up your sensors.
You can try contacting the manufacturer about it and they may have some suggestions.
There are several threads on wxforum.net with instructions for modifying
the console to improve reception. Try searching the forum for the model number of your console (e.g. WMR100) and "antenna" or "external antenna".
If you don't mind drilling holes in your console (and voiding the warranty), adding an external antenna can make a huge difference.
Another option is to replace the base console with an Arduino WeatherShield receiver -- these have been found to work as far as 600 feet away in
some tests (see elsewhere on this web site for information about the WeatherShield for Arduino).
I lose reception of one or more wireless sensors when the console is connected to a computer.
This is a variation on the previous question. Plugging in the USB cable can interfere with the ability of the
console's internal antenna to receive signals. Try the suggestions in the previous answer -- if the reception is okay with
the wireless sensor a lot closer, you are probably having antenna problems. You can try putting one or more ferrite chokes on the
USB cable and try longer and shorter cables and route the cable differently.
There are huge spikes on my data graphs at CWOP, Weather Underground and/or PWS Weather!
Technically, there is nothing wrong -- this is caused by missing data. When WSDL is first started and when
the OS console loses contact with one or more wireless sensors (either temporarily or permanently),
missing data can occur. When WSDL uploads data to one of these internet sites it will omit any missing data from the
All three internet sites specifically state that it is okay to omit data from uploads. However, these sites will
graph the missing data as large spikes, which many users find annoying. If you examine the textual or tabular data
from these sites you will see that there are not really any spikes in the raw data -- they only appear on the graphs.
All three sites are aware of this behavior and have no intention of changing it.
As a result, there are two check boxes at the bottom of the Upload tab of the options window that allow you to
prevent data packets from being uploaded if data is missing. The first check box requires outdoor temperature to
be present (valid) -- if not the upload is delayed until it becomes valid. The second check box requires all data
to be valid for uploads. Checking one of these boxes will prevent spikes from appearing in the data graphs, but
will also prevent any other data that is valid from being uploaded on schedule. It's a trade-off; choose your evil.
When I enter a calibration offset for relative humidity (RH) of say 5% for example, the RH does not change by the expected 5%.
Please see the chapter in the user manual about Temperature, Dew Point and RH processing. The sub-sections on humidity
calibration explain how humidity offsets are calculated. If the sensor's reported RH value is more than 30% the correction
actually applied will be less than the value entered in the options window. Again, the user manual sections noted above explain
how this works.