Wireless reception monitoring
All Vantage consoles (Vue, VP2, Envoy, WLL and 6313 console) provide a way of inspecting the reception quality of data arriving at the console from the outside sensors, but the information available varies from model to model as follows:
- Vue and Wireless VP2 standard consoles provide two screens, called Wireless Diagnostic Screens that can be called up on the main console display and that show key performance measures for data reception;
- Cabled VP2 models also possess similar screens, although they are less commonly needed in the case of the cabled units – cabled reception will typically either be consistently 100% or there will be a fault with the cable or transmitter board which will usually be evident anyway from loss of all sensor readings;
- Envoy consoles and Weatherlink Live units obviously have no console screen on which the reception stats can be shown. So for Envoy models, the only option for monitoring reception quality is to run the Weatherlink software and look at the Reports | Console diagnostics menu option. Third-party software may or may not provide comparable reception stats – if good stats are not available and a reception problem is suspected then it may be advisable to install Weatherlink for testing purposes, if nothing more. (NB This same Console Diagnostics option in WL is of course available for all Vantage consoles whether standard or Envoy, but for standard display consoles the diagnostic screens provide more comprehensive reception quality data, whereas for Envoy units inspection via software reports is the only option.);
- Weatherlink Live units cannot pass data to the legacy Weatherlink for Windows program, so the option outlined above for Envoy consoles cannot be used. WLL units do generate reception data uploaded to the Health tab of the weatherlink.com browser app – see the Health Data topic for more details. See also the note on ‘Interpreting the RSSI value’ section below;
- 6313 consoles provide ‘health’ information similar to that presented on weatherlink.com for WLL units but displayed on the console itself via the Device Information tab. In addition, if the 6313 console is configured to upload to weatherlink.com, similar wireless health data will also be available online there. Much of the content below provides essential background for understanding wireless reception but see the extra tips section in the 6313 topic for how to access the 6313-specific information on that console.
- The Envoy8X is a special case, which requires looking at data in the Reception table of its SQL database;
Wireless channels: With standard station set-ups, whether Vue or VP2, only one wireless channel (usually #1) will be in use and assessing reception quality should be straightforward. But if the set-up uses two or more transmitters then each will of course be set to a different channel. It’s then important to check reception quality separately for each channel, as described below – if the transmitters are in different locations then reception performance will be different for each transmitter.
Repeaters: If wireless repeaters are in use then reception stats at the console will only reflect the last leg of transmission from the last repeater to the console. But there is also a way of checking reception quality of the penultimate repeater leg – see below.
Wireless Diagnostic Screens
First Diagnostic Screen
On Vue and standard VP2 display consoles the first wireless diagnostic screen is called up by pressing Temp and Hum keys simultaneously, as shown right which reflects the display as seen on the VP2 console (the Vue version looks a little different but is essentially similar).
This display can be confusing because it displays quite a number of different parameters and statistics all relating to reception quality. The display is explained in detail in the Troubleshooting & Maintenance section towards the end of each console manual, where the first diagnostics screen is officially called the ‘Statistical Diagnostic Screen’.
However, there are in fact only two parameters visible on this screen that are really important. The first important parameter is the % figure in the main top row labelled as parameter 5, ie the figure showing as 96% in this example. This reveals how many data packets sent by the sensor transmitter are being correctly received at the console. The console knows how many packets of each type should be transmitted in each time interval and hence can calculate the % that were actually received. Ideally of course this figure should be 100%, but it’s commonplace to see figures of 98 or 99% even in systems that are working well. (The other important parameter is the channel number (arrowed) – see below for further details.)
Indeed, figures that are in the mid 90’s are usually entirely satisfactory, albeit indicating some slight impairment in signal quality reaching the console. And even figures in the 60’s or 70’s % can give console readings that can be quite acceptable, although here there are more obvious signs of a weakening signal. But figures well into the 90’s should be routinely attainable for most Davis systems and figures below 90% are definitely suggestive of marginal general reception or potentially of loss of reception for part of each day. Let’s explain this latter comment:
In the normal course of events, the console resets its reception statistics to zero as part of its routine midnight housekeeping each night. So whenever you look at this first diagnostic screen, you’re seeing the cumulative statistics accrued since midnight on the previous night, which may include periods of good reception and of poor reception lumped together. A common example of this effect is when the transmitter battery is dead or if there’s a developing supercap fault. During the early hours of the morning reception, the reception % may then temporarily fall to zero until shortly after dawn when the solar panel begins again to be able to supply power to the transmitter and the % per hour picks up again.
So some care is needed in interpreting the % reception figure for values below e.g. the mid 90’s – remember to factor in the time of day at which you’re making the observation and perhaps check in again later in the day to see if the % has picked up again during the daylight hours.
Resetting the reception parameters manually
Note that it is possible to zero the stats manually at any time during the day simply by selecting the Clear function – on the VP2 console press and release the 2nd button and then press and hold in for several seconds the Hi/Low button. (The Vue console is similar.) You will see the display flash two or three times, after which all statistical parameters should clear down to zero – this process is not complete until you can see all zeroes. The stats will then start to accumulate again. Be sure to allow at least 5 or 10 minutes before taking a reading again – there may be short-term fluctuations in reception that could interfere with measuring a meaningful value and in any event you need to allow a minimum number of packets to be received before the statistics start to become properly valid again. This process can be repeated several times during a day if required so as to sample shorter term reception trends during the day. But all stats will then re-zero as usual at midnight.
Monitoring within-day reception automatically
While the manual resetting of reception stats offers one way of taking snapshots of reception quality during each day, there are also two distinct approaches for monitoring with-in day reception stats automatically.
One option is to use the small graph at the bottom left of the screen. This graph should be accessible using the same key presses as other console graphs (see console manual for details) and should allow movement from one data point to another with a readout available of each individual dot on the graph.
The second and more powerful option, but only available if you’re using compatible software such as Weatherlink, is to make use of the fact that the ISS reception % is actually saved for each archive data interval. It’s therefore readily possible to use the Plot mode of Weatherlink and to call up a graph of ISS reception with time in the usual way (ISS reception is one of the selectable graph parameters). Unfortunately only the reception of wind packets is saved – this is a good measure of ISS reception but cannot provide reception data for other transmitter types.
Channel selection
The second important parameter is the wireless channel being monitored. In the example schematic above this is channel #5, is the small digit being pointed to by the red arrow. It’s really important to appreciate that the statistical values only relate to the specific channel currently being displayed. And, in multi-transmitter configurations, to get the full picture for wireless reception, you must look at each channel separately – it’s perfectly possible of course to be receiving good reception from one transmitter but poor reception from another. Displaying stats for different channels is very easy – simply use the left and right cursor keys which will move the display between all of the active channels that are currently in use. (Inactive channels are simply skipped over, i.e. are not available for selection.)
Second Diagnostic Screen
The second diagnostic screen (called ‘Reception Diagnostic Screen’ by Davis) can be accessed from the first by pressing the Chill button (press and release the 2nd button, then press Wind). Thereafter each press of the Chill function toggles between the first and second diagnostic screens.
This second diagnostic screen looks quite similar to the first and indeed a number of the parameters are the same, though others are different. There are three parameters on this second screen to highlight:
- Parameter 4, the value at the top right of the display, is the signal strength or RSSI (‘received signal strength indication’), showing 49 in this example;
- Parameter 3 is the % good packets exactly as in the first screen;
- And the channel indication digit is also exactly as in the first screen;
It’s the RSSI that is the only additional parameter of prime interest here – why the RSSI value is so useful is described below. But first let’s just note a few important points in reading this value:
- The RSSI value updates as each new data packet is received. This means that when looking at wind packets for instance (the commonest form of data packet), a new value will register roughly every 2.5 seconds. Values will vary somewhat from packet to packet and so it’s worth watching this parameter for a minute or two to get a sense of the average value for each channel. Because the value updates so frequently with a new value there is never any need to clear this second diagnostic screen, as was described for the first screen.
- In multi-transmitter set-ups it is important to look at the RSSI value separately for each transmitter channel – the values may be very different. Different channels are selected using the cursor left/right keys exactly as in the first diagnostic screen.
- RSSI values are not stored anywhere in the standard Davis stations or software and so the only way of monitoring RSSI for each transmitter is to check this second diagnostic screen manually. (NB However, in Meteobridge Red systems RSSI values are stored and can even be retrieved on a packet-type basis.)
NB There is a note on the types of different types of data packet at the end of this page.
Interpreting the RSSI value
The Received Signal Strength Indication (RSSI) is a numerical measure of how strong (or weak) the transmitter signal arriving at the console might be. Clearly, if the signal is too weak then satisfactory reception will never be achieved. The RSSI provides an objective number which can be used to judge just how weak a given signal is.
Ultimately of course it is the % packets received error-free that determines whether reception is satisfactory, but if RSSI is too low then good reception can never occur. So when investigating issues of poor wireless reception it is very helpful to have values for both the % and RSSI parameters for each transmitter in the system.
The dBm scale: In wireless technology, the signal strength can vary enormously so it is necessary to have a measurement scale that can cope with both large power values and absolutely tiny values also. The unit used is dBm, which is the power ratio in decibels (dB) of the measured power referenced to one milliwatt (mW) and this unit provides a logarithmic scale. (See en.wikipedia.org/wiki/DBm for further details.) In short a value of 0dBm = 1mW; -40dBm = 100nW; and -100dBm = 0.1pW. This definition is simply provided for those who might be interested – it’s not necessary to understand the detail in order to make practical use of the RSSI values.
But there is regrettably one further complication: In their wisdom, Davis decided to use different RSSI scales for Vue and VP2; both stations are actually measuring the same underlying parameter but in slightly different ways. The Vue is more faithful to the underlying RSSI scale, while the VP2 uses a transformed scale, which is a little easier to understand.
The Vue uses the native dBm scale; the Davis wireless signal is very low power and hence starts off with a maximum (strongest RSSI) value of -40dBm which then decreases logarithmically to a minimum (very weak) RSSI value of -100dBm. In practice, the minimum desirable RSSI value for a Vue is -85dBm. Any value smaller than this (ie a larger negative number) is likely to be too weak to allow consistently reliable reception.
For the VP2 stations this same dBm scale is converted to a 0-60 scale, where 60 represents the strongest signal and 0 is a very weak signal. This scale is simpler to use but is also more removed from the reality of the underlying signal strength. On the VP2 scale, a value of 59 actually represent the maximum possible signal strength, while the minimum for consistently reliable reception is RSSI = 30. (Values in the high 20’s may allow adequate reception, but there is then no margin for temporarily adverse conditions like heavy rain or low transmitter battery and are therefore best avoided if at all possible. Similarly, -85dBm is a better minimum target for Vue systems than e.g. -88dBm.)
VP2 RSSI values may be calculated from Vue values using the formula:
VP2 = [(Vue + 100) / 1.5] + 20
Thus: Vue = -85dBm gives (-85+100)/1.5 + 20 = 15/1.5 + 20 = 10 + 20 = 30 on the VP2 scale
Current Davis RSSI usage Davis have clearly decided to use the dBm (Vue) scale for all their RSSI reporting on newer devices and apps. So the older 6312 VP2 console is the only place in which the 0-60 scale will be found. Besides the 6351 Vue console, this dBm scale will be seen in two main places:
- On the recent 6313 VP2 console
- On any device able to report the set of readings called ‘Health Data’ to the weatherlink.com cloud platform (and as seen in the Health Data tab of the Device Configuration (spanner/wrench) screens in the weatherlink.com browser app)
The Health Data data typically contains several readings related to wireless reception, including WiFi strength where applicable. But in amongst the the various readings will be found the RSSI figures in dBm for each active transmitter. Upload devices reporting Health data include the 6100 Weatherlink Live unit, the 6313 console and EM gateways.
Wireless protocol and data packet types
Davis has in fact published relatively little information on the exact packet format and protocol used by the wireless link between sensor transmitters (eg the ISS) and console, but this has not prevented some interested users from reverse engineering the protocol; indeed the detailed community knowledge has now reached the point where third-party receivers for the wireless data can be successfully designed and used. Some parts of the short notes below are therefore largely based on this community information rather than anything sourced from Davis and are very much open to updating and correction.
The Davis wireless technology works by transmitting discrete 16-byte packets of data (6-byte payload plus 2-byte CRC checksum plus 8 bytes of transmission overhead) at 19.2kb at intervals of every few seconds. This transmission time per packet corresponds to only ~7 msecs and hence the transmitter can be powered off in between transmissions, helping considerably to minimise power consumption at the transmitter.
Davis wireless uses FHSS spread spectrum techniques whereby the transmitter is continuously switching (or ‘hopping’) to a new frequency within a specified frequency band primarily to improve resistance to interference. The US band is relatively wide allowing a large number of different frequencies to be used, but the Overseas OV/EU band is much narrower with only a few discrete frequencies available. The Australian band is different again. The wireless diagnostic screens (see above) are relatively complex because they also include parameters that describe the progress of the hopping pattern, though there’s rarely any need for the user to check any of these extra parameters, even when troubleshooting.
The eight Vantage wireless channels are actually time-based (relative to a common synchronisation time) rather than using different frequencies. Thus packets containing wind data (the most frequent type) are transmitted every 2.5625 seconds on channel #1 and with each additional channel cumulatively delayed by a further 0.0625 seconds from the #1 timings. Hence channel #8 transmits to a ~3.0 sec cycle time.
The structure of the data packets at the bit/byte level has not been publicly documented anywhere in full detail and is somewhat complicated. But the net result is that different sensors and transmitter types cause the transmission of distinct payload structures, with the timing of different data content believed to be roughly as follows:
- Wind speed/direction data – every channel cycle (~2.5 secs);
- Temperature data – every 4 cycles (~10 secs);
- Rain data – every 8 cycles (~20 secs);
- Humidity data – every 20 cycles (~50 secs);
- Solar data – every 20 cycles (~50 secs);
- UV data – every 20 cycles (~50 secs);
- Leaf wetness data – every 24 cycles (~60 secs);
- Soil Moisture data – every 32 cycles (~80 secs);
A starting point for further information would be the DeKay decode of the packet structure.
Post your comment on this topic.