I would first like to thank everyone who has helped discover and document the wireless protocol used by Davis. One of the main reasons I chose Davis products for my project was that I could inexpensively access the data computationally.
I needed to receive data from multiple weather and soil moisture/temperature stations, so I initially modified Dekay's DavisRFM69 library to keep track of up to 8 transmitters. The range on the Moteino with the included antenna was inadequate for my project, so I rewrote the receiver code to work with a CC1101-CC1190 evaluation module from TI (
http://www.ti.com/tool/cc1101cc1190emk915).
I figured out how the Davis Leaf and Soil Moisture/Temperature Stations encode their data. I'll add that information to the wiki.
My project's code is posted at
https://github.com/cmatteri/CC1101-Weather-Receiver/. Instead of processing the packets on the microcontroller, I send them to a linux host and process them in weewx drivers. The code is still alpha.
For anyone interested in using the CC1101-CC1190 EM, they are $50 a piece, but only come in pairs. The connection to the module is a 1.27 mm header, so I used a PCB to connect it to an Arduino.
I didn't know about rdsman's CC1101 code until several days ago. I based all of the radio settings off of Dekay's work. Interestingly, several of the radio parameters differ between Dekay's and rdsman's work. The DEVIATN register setting on the Vue console is 0x24. Assuming the crystal frequency is 26 MHz, the deviation is 26e6 / 2^17 * (8 + 4) * 2^2 = 9.5 kHz. In the IM-ME and DavisRFM69 libraries, the deviations are 4.5 kHz and 4.8 kHz, respectively. Dekay, could you have miscalculated the deviation on the CC1021? If not maybe Davis got it wrong on one of them, or I'm missing something.
The MDMCFG4 register on the Vue is set to 0xC9, giving a channel filter bandwidth (ChBW) of 26e6 / (8 * (4 + 0) * 2^3) = 101.6 kHz. The setting on the IM-ME is the same (though the crystal frequency on the IM-ME is 27 Mhz so they're not exactly the same, but they're as close). The ChBW in the DavisRFM69 lib is 25 kHz (it is the one sided bandwidth. I believe ChBW for the TI chips is double sided). Section 12.2 of the CC1021 datasheet describes how to estimate the minimum ChBW. The minimum ChBW with a 10 ppm crystal would be 19.2 kHz + 2 * 9.5 kHz + 4 * 10 ppm * 915 MHz = 74.8 kHz. I believe the ChBW for the RFM69 should be increased.
The frequencies sniffed by Dekay from the VP2 console and by rdsman from the Vue console are off by about 30 kHz. Observing the value of FREQEST on my receiver with both Dekay's and rdsman's frequencies shows an error of about 15 kHz for both frequencies, but in opposite directions. Frequency compensation must be performed by the microcontroller for the CC1012 (section 12.13 of the datasheet), so it is possible that the sniffed frequencies included an offset calculated to compensate for error/drift in the crystals of the consoles and weather stations used by Dekay and rdsman (though there is a dedicated offset register on the CC1101, so that wouldn't be necessary, but perhaps they are reusing code, or perhaps rdsman read the nominal frequencies and the error I'm showing is due to my crystals being off). Probably the only way we're going to find the nominal frequencies is to have more people report the error they're observing. With the large channel filter bandwidth and automatic frequency offset compensation, either set of frequencies seems to work. I plan to implement permanent frequency compensation based on FREQEST readings, which would negate offset errors in the frequency table, but it would still be nice to know the nominal frequencies.