Introduction

Davis have yet to make public the full technical details of the packet format and timings of VP2 wireless transmission. The following information is therefore based on whatever detail has been released together with notes assembled from a variety of sources, plus some informed guesses. This page also contains an important section on how to check and monitor the quality of the VP2 wireless link.

Transmitter specifications

The VP2 wireless transmitter operates in the UK (and in all territories covered by the Davis OV versions, including Europe) in the 868.0-868.6MHz frequency band, which requires no licence to use provided transmitter power is limited to low levels. (The Davis transmitters do of course comply with this standard). The maximum transmitter power allowed in the UK under this licence condition is 10mW and the VP2 specification shows a maximum transmitter power of 8mW.

With the introduction of the VP2 units, wireless transmission has been changed to a frequency-hopping protocol rather than the previous single-frequency transmission. For UK/EU units the frequency in use hops automatically between five available frequencies, presumably at 0.15MHz  frequency spacing. (The US version uses different frequencies and channel numbers). Frequency-hopping has various advantages including greater resistance to interference that may be present on one of the spot frequencies.

All Davis wireless units now share the same short multidirectional aerial (antenna) which can pivot through 360° in the vertical plane to allow transmitter and receiver to match one another in orientation, but is otherwise fixed in position (ie there is no aerial socket to which other aerials could be attached).

Up to eight separate VP2 data channels can be used simultaneously by one VP2 system. Note that the word 'channel' does not here imply use of a particular frequency, but probably of a particular time slot in the overall packet timing pattern.

Data transmission

Weather data is not transmitted from the Integrated Sensor Suite (ISS) in a continuous stream but in discrete data packets sent at 2.5 second intervals. Note that the ISS only actually updates wind speed and direction at this same frequency (ie every 2.5 seconds). The values of other parameters are updated less frequently as appropriate to the slower rate at which these parameters change in value. For example rainfall and temperature transmit at 10 second intervals; humidity and solar radiation at 60 second intervals. (NB This behaviour is thought to be identical in the cabled VP stations). Davis have not released details of the packet structure, but it seems likely that there are at least a couple of different packet types, though most data is probably sent in a single packet type.

If reception deteriorates to the point that not all packets are accurately received, the display of weather data on the console is not immediately impaired. Obviously the humidity and radiation data expect only to be updated once per minute anyway and, in general, the last good update value will be retained for display even if some subsequent updates have been lost. Of course there will come a point where too many successive packets have been missed to allow a credible display to be maintained, but it would for example be possible for every alternate packet to be missed (ie 50% reception) yet for the console display to continue to function satisfactorily. (Similarly, when the Weatherlink option is in use, data should continue to be logged  from the console to a PC at 2.5 second intervals without interruption or missing values, even if some wireless packets were missing. For the period where a packet may have been missed, then presumably the value for frequently-updated parameters such as wind speed will be kept unchanged from the previous received value and this will gradually introduce errors into subsequent averages etc, but occasional missing wireless packets should not cause missing or significantly erroneous values in the data logs.)

Successful reception of every packet at the console is routinely displayed by the simple device of toggling an 'X' character on and off at the bottom right-hand corner of the LCD screen with the reception of each successive packet, ie the X reappears every two packets received, ie  every five seconds. If for any reason packet reception has been disrupted for a significant period a steady 'R' or 'L' character will be seen instead.

There appear to be two ways in which the console checks the quality of the received packets:

• CRC checks: A checksum validates the internal consistency of the values contained within the packet to ensure that no errors were introduced during transmission;
• Synchronisation: The details of this process haven't yet been released by Davis, but it seems that transmitter and receiver need to maintain themselves in synchrony, which I take to mean some precise process of time-checking. There is perhaps synchronisation information within each packet and if there is insufficient agreement between the actual and expected synchronisation values, then the packet is discarded and counted as dropped. If a number of successive packets fail the synchronisation test (or equally, presumably, the CRC test), then a process to re-establish synchronisation is activated. (This is when an 'R' will be shown on the LCD display in place of the usual X. If synchronisation cannot be re-established, then the 'L' character is shown to denote that successful reception has been lost);

There are other reasons that reception may occasionally appear imperfect. For example, in more complex installations where multiple wireless stations are communicating with a single console using several wireless channels, reception quality does seem to suffer slightly, presumably because the console may not be designed to handle packets on multiple channels arriving simultaneously. In this case, the lowest numbered channels have priority, so it would make sense in this type of installation to assign the ISS (or separate anemometer transmitter if one was installed) to channel #1, because this would be the unit wanting to pass new data most frequently. Also, the console CPU does not seem to multitask. If the Weatherlink data logger is fitted, there may be a brief and transient effect on reception on occasions when the CPU is handling the requested download of archive data from a linked PC.

Checking reception quality

While the presence (or not!) of a slowly flashing 'X' character at the bottom right of the LCD screen is the most immediate indicator of a functional wireless link, the VP2 console can display two other screens that provide much more diagnostic detail about the quality of the wireless link. These screens can be activated by pressing the console's Temp and Hum buttons simultaneously. (NB the VP1 console has only a single diagnostic screen activated by the Temp and Time buttons.) A longer press on the Done button returns the screen to normal operation.

Before describing these screens in more detail there are three general points to make:

• The most useful single parameter for assessing reception quality is the percentage of scheduled data packets successfully received without errors, which is usually just termed the reception percentage or R%. When evaluating locations for a new installation (or for example checking out an occasional suspected wireless fault), it's often best to start with the ISS and console in the same room to get an initial idea of the maximum performance of your system. There are technical reasons why a given system, even at close range and under optimum conditions, may not quite reach 100%. In practice a maximum of 97-98% may be the best long-term figure observable. The R% figure will tend to fall at longer range or if there are intervening obstructions in the signal path, but this is of minor consequence for successful long-term operation, provided the R% remains at 85-90% or better. And acceptable operation can often still be maintained with R% around 65-70%. In other words, there is no reason to worry unduly if your R% is significantly below 97-98%, although once a level of 70% or less is reached you may also want to check other diagnostic parameters (see below);
• The diagnostic screens displays a number of reception parameters, several of which are cumulative statistics since midnight on the previous day or since the console was last cleared or powered on, if this is more recent. This means that it can be difficult to spot the results of changes that you might make to the wireless configuration unless you clear the reception statistics manually. This is easily done by pressing the 2nd key and then holding down the Clear key for a few seconds until you see that every parameter has been reset to zero. We suggest that you do this every time that you want to see the results of some significant change to your wireless set-up. Note though that the first minute or so of new data collection often seems to give unrepresentative results and a new wireless configuration should be monitored for at least 5-10 minutes (preferably longer) before reviewing its reception quality;
• The diagnostics operate on one wireless data channel at a time, as indicated by the station number readout immediately above the bottom ticker display line. In a straightforward standard VP2 configuration with ISS as the only transmitter this is of course all that is necessary. But for any installation with two or more transmitters (eg a separate anemometer transmitter, a supplementary temperature station etc), reception might need to be assessed on each active channel in turn. The left and right cursor arrow buttons can be used to cycle through different channel numbers;

The two VP2 wireless diagnostic screens are shown below in schematic form, with the 'Statistical Diagnostic Screen' on the left and the 'Reception Diagnostic Screen on the right. The Statistical screen is always the first screen shown and is the only one that is available on VP1 consoles.

What's immediately obvious is that there are a substantial number of quality parameters being reported across these two screens. Less apparent is that some parameters are duplicated between the two screens. (But Davis have probably made the right decision in creating an additional screen and not simply adding the unique Reception parameters to the already busy Statistical screen). It's also unfortunate that the layout of the two screens is so similar, but this is obviously forced by the need to use the same custom LCD display for both screens. But the key distinguishing feature between the screens is that the top left parameter field is suffixed by a degree (°) character only in the Reception screen.

There are too many parameters overall to be described in detail here (plus I don't pretend to understand the significance of all of them). So we'll just focus on a few of the most important values in the knowledge that just 3 parameters - R%, signal strength and the proportion of CRC errors can help a lot in wireless troubleshooting.

As described above, the Reception Percentage (R%) is probably the single most useful value and is shown in both screens (Parameter [5] on the left and [3] on the right - apologies that the parameter keys for each screen don't tie up neatly.) R% should in practice have a minimum value of 70% and preferably greater than 85-90%.

Parameter [4] on the right screen indicates the signal strength of the last packet received and therefore shows the potential quality of the wireless link. It's apparently on a scale of 0-60, with 60 being best and 20 being the minimum for acceptable reception. So a system hovering around the 20 mark is presumably always going to be vulnerable to interference and to adverse reception conditions and seems unlikely to be compatible with consistently running at a high R%. So configuring the positions of ISS and console such that the Signal Strength is at least 25-30 (and higher if possible) should be a good first step.

However, a good signal strength value by itself doesn't guarantee a high R% for two reasons. Firstly, the data contained within each individual packet is checked for internal consistency using a process called Cyclic Redundancy Checking (CRC for short). If this check fails then a so-called CRC error is generated. A large proportion of CRC errors probably means either that the data packet is being corrupted during transmission, very possibly as a result of wireless interference or, much less likely, that there is a problem at the transmitter end in assembling the data packets.

The second potential problem arises because it seems (this is part of the communications protocol that Davis haven't made public) that packets must be transmitted and received within tightly-delimited time windows. If a packet does not arrive according to schedule then it will be counted as a missed packet and is presumably a symptom that time-keeping at one or both ends of the wireless link is not within specification. In practice it seems likely that a slight time-keeping drift will always be found between transmitter and receiver and a small percentage of missed packets (and perhaps a few subsequent resynchronisation events) per day are unavoidable. But if signal strength is good and there are many missed packets then again it may be that transmitter or receiver circuits are drifting out of specification. {NB Remember also that there are other possible causes of missed packets. For example, when the console CPU is in the process of downloading archive data to a PC it cannot simultaneously receive and process data packets.)

When troubleshooting systems with reasonable signal strength but poorer than expected R% it can therefore be useful to distinguish between occasional packets lost because of CRC errors and those from other causes such as synchronisation errors. This can be done by looking at the proportion of CRC errors relative to all missed packets and also by monitoring the streak length statistics.

The console maintains a count of the cumulative number of packets successfully received since the last packet was dropped (known as the current streak and shown as parameter [11] in the Statistical screen and [9] in the Reception screen) and also the maximum streak length since the console was last powered up (only shown in the Statistical screen as parameter [10]).

There does seem to be considerable variation in the streak lengths between individual VP stations and installations. The VP1 weather station (we have yet to accumulate comparable data on VP2 stations) in regular use at our base here has a typical streak length of exactly 40 packets even when ISS and console are in close proximity. Every several streaks, a longer streak may be recorded that is slightly more than a multiple of 40 packets. The longest regularly seen is 244 packets, though 285 is seen on occasions. In virtually every case, the streak ends not because of a CRC error, but because the packet is dropped presumably due to a synchronisation error. After one dropped packet, successful reception almost always resumes at the next packet. However, other installations have reported maximum streak values up to 10 000. This difference in behaviour may reflect a difference between the set-up of US and export (UK/EU/OV) models, but, as noted above, is more of a curiosity than any symptom of poor performance, because the console still functions and displays its weather values perfectly well despite the short streak value. However, because of the typical 40-packet streak, the R% value on this particular station never exceeds 98% and this therefore represents the ceiling value for good reception. However if the typical streak length were to drop into the teens or lower then this would probably be a reason for further investigation.

With the above in mind the parameters for monitoring reception quality are as follows:

• Reception Percentage (R%);

• CRC errors: With good and interference-free reception, the level of CRC errors is exceptionally low (  1-2 per day). Any significant increase in this value can be indicative of increasing interference;

• Any fall in typical streak length for the station in question (assuming this has been monitored previously)

• Number of resynchronisation attempts (Parameter [7] in the Statistical screen): These can occur occasionally  (1 or 2 in a 24 hour period) in any installation, but are generally rare and any significant rise in incidence may reflect deteriorating reception;

• Number of times the console lost communications with the ISS for more than 10 minutes: This is a difficult fault condition to categorise. It does seem to happen very occasionally even under good reception conditions, perhaps because a bug in the firmware is occasionally not allowing resynchronisation correctly after a momentary loss of communication.

Monitoring these five parameters simultaneously should give a good indication of the current state of wireless reception. In general, seeing three zeroes in the central boxed area of the Statistical screen, together with a minimal (ideally zero) number of CRC errors is a good sign of continuing good reception.