XBee Interface for the Davis Vantage Vue Personal Weatherstation

About a month ago I finally purchased a good personal weather station, a Davis Vantage VUE. I performed a ton of research over the past few months and the Davis models seemed to be some of the best within a reasonable budget. One of the main features I liked about the Davis models is the wireless capability of the sensor unit and most importantly the two second data update interval. This was important to me as I wanted to be able to submit real-time data up to the Weather Underground utilizing their rapid-fire servers and API.

I had been doing this previously via some home made sensors I had put together, at the time I was sending temperature and humidity data to my Wunderground station (KMIWESTB14) via one of my datacenter temperature monitoring sensors I had built. The sensor was mounted outside and transmitted data via an XBee to a linux server in the basement rack where a simple bash script listened to the serial port, reformatted the data and sent it up to Wunderground. While it was cool, I wanted more data. My station was lame compared to many of the other nearby stations, so I looked to expand. Barometric pressure was easy as SPI/i2c sensors to receive air pressure are cheap and prevalent  but the remaining sensors, notably wind direction and speed were not. These sensors would require mechanical designs (which I am all for building) along with calibration which would be the more difficult piece to solve. Calibrating a wind vane would be simple, but calibrating a anemometer would require a calibrated source or device, I would at least have to invest in a good handheld anemometer to calibrate my home built one. With the cost of these even used not really cheap, I finally decided to retire my station and purchase a commercial one.

The Davis Vantage VUE system is awesome and I have been very happy with it for the first few weeks of using it. The only complaint I have is it did not have any type of available interface to access it by, no direct serial, ethernet, USB, etc. These were all additional add-ons that were necessary to purchase along with the unit. I knew this when purchasing it, and I had plans to reverse engineer it as soon as I received it.

The Davis Vantage VUE console is a rather simple device, the main board has a handful of components which include a common ATMEL microcontroller, so this was going to be easy. Figuring out the pinout on the back of the unit was trivial at best, but it turns out that a group of people already have. A few weather forums out there have a good amount of information on the Davis interface which consists of a 20pin, (2x10) 2mm pitch connector that the factory options can install onto. A pinout of this interface is readily available along with a full API of the serial interface.

Once discovering that a serial interface was available on the back of the unit, my immediate thought was to use an XBee. Checking the pinout of the connector there was also +3V and Gnd available. Perfect! Since an XBee can run between +2.8V and +3.4V,there would be no issues as long as not too much current was consumed eliminating the need for any additional power source. Because I had no data on how much current I could actually draw off of this port, I stuck with a standard XBee (non-pro) as its transmitting current at 3.3V is only 45ma. Assuming it may be slightly higher at 3.0V, it would still be low enough (I had hoped) to run the XBee, and after some testing I proved that it was.

Once some basic testing was made with the XBee to prove that it worked, I designed up a simple board and sent it off. Once received, I threw it together and here is the final device:

It tucks neatly into the back of the Davis console. I chose to use an original V1 XBee (still wearing the MaxStream logo as it was pre-Digi) because it was the only one on hand that I had with a nice low profile chip antenna.

Once I had it installed, which fit very nicely into the back of the console, I wired up another XBee to serial interface on my desktop and powered up the Davis. The unit initially responds with an 'LCD ok' message at the same time the unit goes through its self testing at which point it is ready for commands. The easiest is to send an 'STRMON' to it which will dump all of the raw sensor data from the external sensor unit every two seconds.

I have had this running for a few days now without any issues, the next step will be to rewrite my simple script to grab this new data and reformat it according to the Wunderground API and send it.

One additional note on this, apparently Davis has limited the usability of the serial port on the newer versions of firmware. Luckily my new unit came with the older version of firmware which still allows access to the serial interface. It is unfortunate that this has happened, I can't imagine getting around whatever was put in place to figure out how to re-enable the serial interface would be too difficult, but I am not about to update my unit to find out.

XBee Based Datacenter Temperature Monitoring Network

Temperature monitoring and control is extremely crucial for any datacenter. I work for a hosting company who has several thousand servers running producing enormous mounts of heat. To battle the BTU output of these servers you must have hundreds of tons of cooling running all the time to keep everything operating under control. Monitoring the datacenters temperature is important in more ways than you think. In the event of a cooling failure, servers will begin to overheat extremely quickly, this in turn causes them to raise the speed of their internal fans to full speed to combat the internal heat. For one server this may not be so bad, but when 1000+ servers do it your total power consumption increases drastically. This can then cause circuits to draw more current which in turn heats them up further increasing the overall temperature in the facility. Servers CPUs will then begin to be throttled by the bios to cool them down which can hurt websites performance. Datacenters internally can actually reach high enough temperatures over 100 degrees Fahrenheit were circuit breakers begin to trip and large 150KVA+ UPS battery backup systems can actually fail from the high temperatures and the increased load they are seeing. Thermal expansion can also come into play causing wire lugs to come loose on UPS inputs and transformers further causing points of failure.

All of this is why reliable temperature monitoring is so crucial. Being able to monitor temperatures throughout a facility can keep you ahead of any potential failure. Commercial temperature monitoring systems are available, but they are extremely expensive and limited on their placement. If you have a 10,000+ square foot facility, monitoring the temperature everywhere could be extremely expensive and difficult to implement. So for all these reasons I wanted to design a system that was very inexpensive and easy to implement anywhere you needed it. Specifically I wanted to not only monitor ambient air in both hot and cold aisles, but also be able to monitor temperatures inside circuit panels and PDUs. Being able to measure a increase in temperature within the circuit panel or PDU itself could indicate a potential failure way ahead of time allowing it to be addressed before it causes a dangerous situation.

My solution was to build a simple temperature monitoring network that was ideal for a datacenter environment. When beginning the design process I came up with the following requirements that it needed to meet:

1.Inexpensive. Commercial temperature monitoring systems are very expensive. I wanted my sensors to be inexpensive enough where you could place them in locations that you would not normally be able to place a temperature sensor because of cost reasons.
2.Wireless. Most existing temperature systems are wired, which is silly in my opinion based on the inexpensiveness of existing XBee based wireless modules. This saves the need of having to run additional wires to each sensor and increases placement flexibility.
3.Easily expandable. I wanted to make sure that I could add additional sensors into the system at any time without hitting any limits on the amount of sensors, within reason.
4.Reliable. Previous systems I used were dumb in the fact that the sensors would sometimes have errors collecting data. This would in turn wake me up at 4am telling me the datacenter was at 150+ degrees Fahrenheit, then instantly back to 70 degrees. This was just annoying.

This is the design of my first three prototype sensors I made:




Each sensor is based on a PIC 18F25K20 microcontroller driven by a 16Mhz oscillator. An XBee module provides the wireless connectivity while a TI TMP100 I2C based temperature sensor monitors the current temperature condition. The TMP100 is one of my favorite chips, it is inexpensive, has 12 bit resolution, and has a wide temperature range. Now I know I could have easily made these much smaller by using all smd based components The PIC I chose is way overkill for the job anyway, but I had a large quantity of these in my parts bin left over from previous designs so I used them as I hate having parts sit around unused.

The software on the PIC simply reads the temperature from the TMP100 every 60 seconds and sends the temp along with a unique device ID to the XBee. The data it sends is also encrypted to prevent anyone from injecting rogue temperature data into my monitoring network. If someone really wanted to they could probably crack the encryption over time. I guess if they just really want to wake me up at night I'll have to implement even stronger encryption. ;)

The receiving end is PHP based. An Xbee / Max232 interface receives the data and sends it to /dev/ttyS0 on the receiving Linux based server. From there I decrypt and parse the received data and process it for errors. It is then checked for predefined temperature limits and emails the appropriate contacts if thresholds are reached. It is also stored into a database and sends a daily log of temperatures throughout the day.

The system is flexible as it allows me to add any additional sensors into the monitoring network at any time. I'm using 2.4Ghz based XBee's, but they are in sockets allowing me to replace them with the 900Mhz version in the event that a facility has a lot of walls blocking the 2.4Ghz signal.

So far the temperature sensors have been working very well, future plans include a modular temperature sensor board and a better (prettier) web interface to show the current facility conditions.

XBee Repeater

I am finally ready to perform some long-range XBee testing using the Digi XBee-Pro XSC modules. I put together a few simple Xbee repeaters utilizing an Xbee-Pro XSC 900Mhz module, a simple rs232 interface, and power supply. Power come from a pair of 18650 lithium batteries.

I made two of the devices above as they are useful for any project that needs portable XBee communication. Simply hook any two laptops or mobile embedded devices up to the pair via rs232 and you have instant point to point mobile serial communication. To enable the device as a repeater, I made a loopback device that plugs into the serial port echoing anything that arrives on the serial rx line back over tx.

The simple 900mhz antenna hooked up to it works well for testing, but I have a pair of high gain 900Mhz ISM band yagis I plan to use for long range testing.


These yagis connected to the Xbee PROs with good lmr-200 cable should make for some very long range communication. The biggest issue is finding a good line-of-site location to test. I have been studying some topographical maps around the Ann Arbor area trying to find two good points of high ground, or a point from a tall structure to high ground. So far I have some good tests at about 6 to 7 miles (which doesn't seem like much, but when trying to see from your point on the ground is a very long distance away). Standing at ground level (if at sea level and looking out), from your eye level (say six feet up) you can only see about 3 miles to the visible horizon. Increasing your distance above the earth to 100 feet only increases the visible horizon to about 12 miles. So I will need to find some tall structures or high ground to test the full 15 mile range that the Xbee datasheet states for the maximum range.

Long Range XBee PRO XSC testing, Part 2

It has been awhile since my original post about seeing how large of a distance I can get two XBee PROs to communicate, but since coming across two nice 902 - 928Mhz ISM band 9 element yagi antennas I figured it was time to give it a try.


My plan is to mount two XBee PRO XSCs each to one of the yagis mounted on tripods. A small ttl to serial interface will be needed at each end which will allow interfacing to laptops. These setups will need to be as portable as possible. With each setup I will be able to set them up easily at any location (the tripod / antenna / XBee and interface, along with a laptop will be the only items needed) and test signal strength and communication using the XBee X-CTU application.

I finished the first ttl to serial converter tonight, only one more to make:

The final step will be to find two locations that are line of sight and up to 15 miles apart using topographical data. 15 miles is a long way, so I will be starting with a five mile distance. As soon as it warms up I will be giving the range test a try. I'm hoping to reach the 15 mile range Digi states that these modules are capable of, but even further would be better. :D

Remote GPS tracker + Accelerometer

This summer there are a few projects I have planned. One of the first is a model rocket tracking / data-logging system for some launches I am planning on performing this summer. I recently came across a good supplier of F and G series rocket engines for a very reasonable price. Some of these engines have as long as a 7.8 second burn making them very exciting to see take off.

The idea of this project is to be able to record all acceleration of the rocket throughout the the entire launch. The tracker will also have a GPS receiver that can log it's maximum altitude as well as track its decent to aid in finding it's landing location in the event of a launch where the rocket landing ends up not being visible. This GPS data will be transmitted through a long range Xbee tranceiver.

The basis of the performance data is an Analog Devices ADXL accelerometer. These accelerometers are very cheap and very accurate. They are available in different models with varying degrees of g resolution. The model I am using here is the ADXL330, a three axis +- 3g accelerometer.

The +-3g of resolution is fine for testing, for the actual rocket launch I will be using a +-18g accelerometer to capture launch and decent data.

The ADXL is a pretty small SMD device, so soldering was a little tricky:

The prototype I am making here is a testing base that will be used for debugging and developing the base station receiving software. I envision making a simple and cool app that will control and display all functions of the rocket from launch to landing. The design is based around a PIC18 series microcontroller. Initial performance testing and range testing will be performed by mounting this prototype to a remote controlled truck to gather data.




The tracker under development on my bench:


The finished prototype:

Please note that this device is much too big and heavy for use in a rocket. The final version will be made mostly of SMD devices on a PCB I design using Eagle. Lithium Polymer batteries will be used to save weight as well as using a smaller GPS receiver. I need to be able to save every gram of weight possible.



The device is currently working flawlessly as I have tossed the device around outside my home and been able to capture the data from it. Truck testing will occur this coming week or two, I will be able to display actual data at this time.

Long Range XBee PRO

Digi recently released a new series of XBee wireless long range transmitters which I have been very excited to play with. The XBee-PRO 900 series has up to a 6 mile range using a high gain antenna! Some other features from the XBee site:

• Fast 156 Kbps RF data rate
• Point-to-multipoint networking ideal for low-latency applications
• Support for large, dense networks
• 128-bit AES encryption

Jim cam over this past weekend to help me perform some basic ranging tests with these modules to see what type of distance can be achieved in an urban area. The plan was to set up a base station and send messages out to a mobile XBee PRO as a repeater and see how far away we can get without dropping any packets.

The base station is simply an XBee PRO linked to my bench machine through it's serial port via a MAX232.



The mobile module is simply an XBee PRO with it's TX and RX lines wired together forming a basic echo repeater. Lithium polymer batteries are being used through a 3.3v regulator. This is simply in basic mode as well, no API mode.



Using Digis' useful X-CTU application for range testing, we were able to get some impressive results. We were not able to get anywhere near a 6 mile range, but with the fact that we were using only the on board whip antenna on these modules instead of a high gain antenna, it was expected. Our testing environment significantly limited the range as well because of the amount of concrete structures in the area. With all of this we were still able to reach a range of several thousand feet before packet loss. A standard XBee would never reach this range.


Range was very limited to line-of-sight. If there was a building in between the source XBee and repeater XBee, packet loss would occur in a very predictable manner. This was all happening from the source transmitter being on my bench inside my home, so there was already an initial structure blocking it's signal path.

Our next tests will occur in a more open area which will allow more line-of-sight testing. I am confident that we will reach several miles in this scenario and will report our findings.