Clifton Laboratories 7236 Clifton Road  Clifton VA 20124 tel: (703) 830 0368 fax: (703) 830 0711

E-mail: Jack.Smith@cliftonlaboratories.com
 

Having access to Mike, W4XN's, Watkins Johnson 8617B surveillance receiver, I  thought it might be interesting to show what one might do with the 8617B and perhaps indicate why these receivers are made.

We'll use a mundane example, the wireless data system used  by Davis Instruments in its Vantage Pro (not the Vantage Pro II, but the out-of-production original Vantage Pro) weather station that I own.

Our analysis will be based on the published information released by Davis, supplemented with our off-the-air analysis.

The Vantage Pro manual says that the wireless link operates on 916.5 MHz at an output power of 1 mw maximum. Setting the 8617B to 916.5 MHz, AM mode, 100 KHz bandwidth reveals data bursts occurring every couple seconds. Based on the published frequency and signal strength, this signal is, with high probability, originating from my weather station. (I've set up the weather station to enable the indoors console as a repeater. Hence we expect two digital packets, one direct from the outdoor sensor unit, or the ISS (integrated sensor suite) in Davis's terminology, and a second packet from the console, repeating  the ISS data.

To obtain a quick view of the pulse waveform, I tuned the Advantest R3463 spectrum analyzer to 916.5 MHz, added a broadband preamplifier and connected it to the discone antenna. By operating the spectrum analyzer in zero span mode, we obtain a plot of signal amplitude versus time.  Unfortunately, the choice of sweep speeds is limited, and the fastest speed is 5 ms/division or 50 ms for the entire 10 division sweep.

The shortest data elements look to be on the order of a few hundred microseconds

The image below shows the video output. Note that the video is, following tradition, negative, with no signal represented by 0 volts and signal represented by a negative voltage. (The video polarity is switch selectable between positive and negative, and later in the analysis, I switched to positive video for reasons discussed later.) Compared with the spectrum analyzer's display, the 8617B and digital oscilloscope provide a much better analysis starting point. The 8617B is set for AM reception, AGC to off, bandwidth at 100 KHz.

• Zero signal corresponds to logic 0. (No way to confirm this, but the analysis works either way)
• The receiver has to know when a data packet begins. This can be done synchronously, where the transmitter and receiver have synchronized clocks, or asynchronously, where there is a defined start symbol. For a moderately priced consumer weather station, we can immediately discard the synchronous transmission possibility. The most logical design uses a logic 1 or high transmitter output to indicate start of data transmission.
• I count 57 bits with the start bit as no. 1. The 58th bit is the start of the no signal indication that continues until the next packet.
• We cannot distinguish between a packet length of 57 or some greater number where the data sample just happens  to end in a sequential string of 0s. We need more samples for this determination.

Information on the transmitting ISS is  that it has the following sensors:

• Temperature
• Humidity
• Wind speed
• Wind direction
• Rain bucket

Davis has several optional sensors that plug into the ISS, such as ultraviolet sun intensity, leaf moisture, soil moisture and the like. These inputs are open in my ISS.

One final point is that the ISS has a transmitter ID switch, selectable from 1...8. My ISS is set for ID = 1.

Rather than continue the manual capture and hand analysis of the data, I decided to automate the process. I first adjusted the 8617B's video polarity switch to positive for better compatibility with the digital world. I  then connected the video output, which runs 0...7 volts or so, to an input pin on a Microchip 18F4620 PIC, taking care to use a series resistance of 2.7K to prevent over-voltage damage to the PIC's input. (The PIC is built with diode clamps to Vdd and Vss on every pin, so a series  resistor is sufficient to limit the current to a safe value.)

I then wrote, using Swordfish BASIC, a capture and analysis program. The program has several outputs, including one that samples the data input state every 50 microseconds, and one that reads the data and converts it to  bytes, based upon the measured bit length.

The data sampler, for example, can have the output put into Excel, where a semi-automated version of the paper and pencil analysis shown above can be implemented. The sample below shows the first 1000 microseconds of input. With a 200 microsecond  bit length and 50 microsecond sampling, the data corresponds to 11110.

The decoding program is based on 64 bit packets, or 8 bytes. This is usable although the data suggests the packet length is perhaps 57 or 58 bits in length because at most the 64 bit assumption means the last byte has extra trailing zeros. These will not get in the way of the analysis.

As I've mentioned, there are two packets sharing the channel, one directly from the ISS and one from the indoor console repeating the ISS data. The console is set to repeat as "channel 2" and the ISS is "channel 1" but in fact both share the same RF channel. The difference between channels 1 and 2 is in the identification transmitted within the packet and the packet repetition rate (more about the later to follow.)

The data is organized in the  table below so that packets on the same line are roughly contemporaneous.

There's a  great deal of information that may be discerned from the hex dump, but most of it would  take more work than I care to put into it. A few things jump out, however.

• Source A packets always start with the leading nibble as a hex B.
• The second nibble has a repeating pattern (not perfectly)
• The second byte is always 3F
• The  third byte is (one exception) always 5D.
• Source B packets always start with F leading nibble
• The second nibble has a repeating pattern 8,5,x,E where x is not always the same character.
• Like Source A, the 2nd and 3rd bytes are 3F and F6.
• The 4th byte is more or less common between Source A and B with some chronological offset.
• The 5th and 6th bytes do not show much commonality between Source A and Source B.

It's very likely that the leading nibble is tied to the channel ID. With 8 potential channels, three bits would be enough. There might be, in addition, a leading "1" used as a starting pulse, to mark the start of  transmisison. In this case, we would expect the channel numbers  to run from 1000 to 1111 or in hex 8 to F. With channels 1 and 2, the first nibble would thus be 1001 and 1010, or hex 9 and A. This simplistic coding example seems not to be the case here, however.

• The rain bucket uses some sort of cumulative reporting, i.e., the radio packets do not just  report 0.01 inches of rain recorded in this packet (0.01 inches represents one tip of the tipping bucket measuring mechanism.) This is the case because otherwise a single lost packet would cause a perpetual error. I've seen the radio link be lost for some minutes during rain and the data is not lost. I assume, therefore, that what is reported is the total number of bucket tips in, for example, a 16 bit format with rollover. The receiving console or Weather Envoy then reports the increment in total bucket tips since the last valid reception.
• Some data seems is  reported more frequently than others. Wind speed, for example, is updated much more frequently than seem to be updated more frequently than rainfall and temperature, as shown in the table below. It seems, therefore that there are perhaps three different data payloads  transmitted: wind, rain/temperature and humidity/UV/solar.
• Temperature data is in 0.1 degree F intervals, and humidity is in 1% steps.

Since the basic packet transmission rate is approximately 2.5 seconds, one out of four packets should carry rainfall and temperature data. The weather conditions for the data presented above were zero rainfall and relatively steady temperature.

The hex data was collected at approximately 9:30 - 10 AM on July 2nd 2008. The  graph below shows the outdoor temperature during this period. Barometric pressure is collected from an indoor sensor.
 

I'll leave it as an exercise to the interested reader to see if the temperature and humidity data can be teased out of  the hex dump.

Davis provides a table relating the number of wind speed packets to the channel ID

Two free running packet systems with these parameters will have a collision (packets from the two sources overlap) approximately 2.6 sec / 0.065 seconds or once every 40 transmissions, or once every 104 seconds.

The following three images show this. The three consecutive images show the ISS and repeater packets getting closer in time and, in the third image, interfering with each other.

Timing the interval between packet collisions with a stop watch produced the expected 104 second period within small margin of error.

Since the older Vantage Pro equipment I have uses a single RF channel, sharing amongst multiple weather stations uses a different approach. (The ISS transmitter has a "channel set" DIP switch, whilst the console and Weather Envoy set channels via software. These are logical channels, as all the gear operates on a single frequency, 916.5 MHz.) With a short burst transmission, 12 ms or so every 2.6 seconds, there's a good chance that transmissions from two ISS units will not overlap. However, Davis has added an additional anti-interference measure. Each logical channel has a slightly different frame rate, i.e., the data bursts are transmitted at slightly different intervals. Logical Channel 1 bursts are, say, 2.6 seconds apart, whilst logical channel 2's bursts are 2.7 seconds apart. (close to the actual values). This avoids the statistical chance that if two Vantage Pros are nearby, and both have the same burst rate, they could be in perfect synchronization so that every data burst from one transmitter interfered with the second. Given component tolerance and temperature drift, that's not likely, but it does mean that there could be longish periods where the two were close enough in synchronization to have the bursts overlap, at least in part. If the two transmitters, in contrast, start in synchronization but with intentionally slightly different burst periods, they will drift in and out of mutual interference. If the burst periods are selected with sufficient care, this may provide quite useful periods of interference free operation compared with the "all transmitters use the same burst rate" approach.