Wired vs Wireless Weather Station

Welcome back to the WirelessJon blog – I’d taken a long respite from blogging, but it’s time to dive back in.

Six weeks ago I decided that it was high time that the WirelessJon household had a professional-grade weather station. I’d been toying with $90 LaCrosse Technology¬†all-in-one wx stations from Costco for many years, and each year or two or three I’d have to replace the hardware because something had stopped working. As well, the LaCrosse stuff didn’t have a nice way to fire the data to WeatherUnderground (or any other online service), so I had to run WUHU on a PC that was also running the LaCrosse Heavy Weather software. It was a kludge at best!

One of my long-time friends and fellow ham Dave KD7DR is a local expert on weather stations. He’s been using both Peet Bros. and Davis Instruments stations for a long time now. He suggested to me that the Davis had better hardware quality – he uses a wired Davis Vantage Pro2 atop Pinal Mountain, an ~8,000′ peak about 60 miles east of Phoenix, and it’s survived well over the years. I also had some personal experience with a Peet, as I’d installed one at a 5,000′ site above the Tehachapi Loop in southern California back in 2008, and except for losing the anemometer cups to a heavy ice storm, it’s been a pretty solid unit as well.

After some discussion and consideration, I chose the Davis Vantage Pro2 as the baseline. The next decision was whether it would be the wired or wireless version. The external sensor location is on the roof of the house, and I already had a 2″ cable conduit running out to the general location. However, that conduit is stuffed with other cables, including RF coaxial cable, and I didn’t know whether I wanted to pull yet another cable through the already-tight conduit and didn’t know how the slight leakage from the RF coaxial cables might impact the weather sensor readings. Time for more investigation.

I went through the Davis literature and discovered that they’d had the foresight to put “low-pass” filtering on the sensor lines, so what coupling there might be should be alleviated by the filtering. As well, my RF coaxial cable is either LMR400 or LMR240, double-shielded, very low leakage, and none of my transmitters are more than about 50 watts, so it’s likely that the amount of power deposited onto the wx sensor cable leads would be pretty low. It would also be common mode, so that might help reduce any concerns as well.

The last factor for wireless was the choice of RF frequency that the Davis unit uses. It employs some sort of proprietary frequency-hopping transmitter in the license-exempt 902-928 MHz band. Given that I’m a ham and may want to operate in that band (actually, I do have some equipment but it’s currently receive-only in the house), I decided that I didn’t want to pollute that band any more than it was already.

Importantly, I had to look at the type of cable that connects the Davis weather sensors to the console and what connectors are used. Again, a few checks using Google and I found that the cable supplied by Davis is just 4-wire “phone” cable, much like the old silver-colored soft, flexible wire which connected old-time wired POTS phones to the wall outlet. Except that the Davis wire had a UV-resistant jacket. Kind of necessary for an outdoor install, especially here in Arizona. The connectors were the clear plastic 6P4C “RJ15” type, readily available in my garage, as was the crimp tool. Finally, the way the cable was constructed was straight-through, so there was no need to worry about some custom wiring configuration.

The next consideration was how much weather did I want to sense? Since I tinker with solar power a bit, both on the house and on the truck, I’ve always wanted to know the total solar insolation at the house, and ultimately be able to calculate the peak, average and cumulative power/energy delivered to the ground. And while I was spending all this money, I decided to get the UV sensor as well. Never know. I chose not to get the active aspirated temperature sensor, but I believe I could add that on later if I choose.

One final consideration in the wired vs wireless debate is how to get power to the sensors. Weather sensors are just like any other device – they need some juice to allow them to make measurements and report back the information. The wireless Davis unit employs an add-on small solar panel and built-in battery to collect and store electrical power to run the sensors and the wireless transmitter. According to everything I’d read, it works well and the batteries have a good lifetime. But, here in Phoenix, things exposed to the sun get very warm, and batteries up on the roof are going to be in a fairly harsh summer environment. Also, the failure of the most recent LaCrosse unit appeared to be a failure of the built-in solar cell to charge the little NiMH batteries in the anemometer. Using a cable would allow me to avoid completely any concern over having to change batteries in the future.

Now that the wired vs wireless decision was made, it was time to look at the ability for the Davis to push data to the internet. They have a number of interface dongles which plug into the display unit. One is a serial port connection, which requires a PC to run software to manipulate and push the data to the web, and the other was a thing called the WeatherLink IP, a slightly different dongle which plugged into the same socket on the Davis display head but instead of serial had a nifty RJ45 socket and talked IP. It seemed that this allowed me to divorce the entire process from a PC. The one primary drawback was that the literature indicated that the weather data could only be pushed once every 15 minutes. At this point, that seemed ok (i’d come to be unhappy with this later).

That was that. I called up Andrew Revering at Convective Development and placed the order for the Davis Vantage Pro 2 Plus wired station and the WeatherLink IP dongle. Less than a week later a big box showed up on the doorstep, and the day after Thanksgiving I installed the entire thing.

Later on I’ll talk about some of the good, could-be-improved, and mediocre things I’ve found with the Davis, both mechanically and operationally.

IEEE 802.15.4p Rail Communications and Control – Getting Ready for the Mainline!

IEEE 802.15.4p task group has just completed letter ballot and has been approved to move forward to Sponsor Ballot. The participants within the IEEE group have been terrific – engaged, collaborative, and flexible.
The group includes 90 participants from around 70 private companies, academic institutions and US and foreign government transportation entities. Every milestone denoted on the schedule established back in fall 2011 has been met or exceeded.
We met the requirement that 75% of the current 802.15 Working Group voters must participate in the vote. “Yes” votes comprised over 96% of the returned ballots. Comments may be submitted by any voter, but must be submitted by any “no” voter. The comments received during this letter ballot were a good mix of technical and editorial and should be able to be resolved over the next several weeks.
What all this means is that there’s a high probability of getting the standard released by the end of the year or in January 2014. It appears that there are several companies out there which may be releasing a compliant product shortly after the spec release.
To our participants, keep up the steady progress and collaboration. To the rail operators, be prepared for train wireless data communications that are based on open international standards.

IEEE 802.15 Positive Train Control Study Group

Many of you may be familiar with the IEEE 802 organization, if in no other way by its standards that have become the mainstay of wireless communications, like IEEE 802.11 (Wi-Fi), 802.16 (WiMAX), 802.15.4 (used by ZigBee, WirelessHART, ISA 100, 6LoWPAN, and others).

Standards development is a challenging matter, since it only comes by bringing together competitors and opposing entities into the same room and working together to create standardized approaches to a variety of problems.

The group that I helped to create, IEEE 802.15 Positive Train Control (PTC) Study Group, is focused on the vital wireless link between the train or locomotive and the infrastructure along the track ahead. While the current concentration is mostly to ensure that a train does not “exceed its limits authority” or exceed its speed restrictions, the future could see the need for a train to talk to bridges, overpasses, or other infrastructure that could impact the safety of a fast-moving train.

Now that we are in Study Group phase, this means that it’s time for us to concentrate on writing our Project Authorization Request (PAR) and our Five Criteria (5C) documents. To make that effort possible, the group will have a Call for Applications, which will allow interested parties to begin to submit technical proposals for how a future wireless standard will be applied in the real world. Fortunately, PTC is a fairly well defined application, but even there, there are nuances that may prove very important to the final standard. As well, this standard must be something that can grow and remain flexible for future applications which we may not even have considered yet.

While what we’re working on is a new standard, in IEEE parlance, the work could result in an amendment to an existing standard (like 802.15.4) or a new number (802.15.10?). That’s why the call for applications is so important – it helps establish the scope of the task.

Some important considerations might include the use of licensed bands, support for narrow-band, possibly non-contiguous radio channels, fairly low data rates, very high speed mobility, and a lot of non-line-of-sight (NLOS) propagation paths. As a train moves along, it may pass from one geographic region to another, and the operating channels may be required to change as the train moves. And it always needs to be kept in mind that this may ultimately be for vital (life and safety) communications, so reliability, robustness and security are important matters as well.

I’ve been working on systems in many ways similar to this for most of my professional career, from deep-space missions (where oops! could mean the end of a multi-billion US$ mission), to very high volume consumer and industrial silicon chip-level wireless systems, and for the past 10 years working to drive standardization of approaches used in the industry to reduce cost, increase the potential for interoperability, and generally to improve reliability and robustness.

If this is your cup of tea, I strongly encourage you to participate in our Study Group. You can get plenty of details here.

The More Things Change, the More They Stay The Same (in Wireless)

Happy (nearly) Ides of November! Earlier this month I tendered my resignation at Freescale, the remnants of the old and formidable Motorola Semiconductor Products Sector. I’m in the process of moving on, and have my sights set on a startup in the wireless communications business. I spent the last week at the IEEE 802 meeting in Atlanta, getting an 802.15 Interest Group converted to a Study Group (100% success, vote was 49 yes/ 0 no/ 0 abstain; and the 802 Executive Committee gave unanimous approval). What’s it all about? Positive Train Control!

Ok, so what’s that and what does it have to do with radio?

If you’re a US resident and ride commuter rail, you might remember the horrific accident back in 2008 in Chatsworth CA where a westbound Metrolink train ran through a red signal and proceeded to collide with a Union Pacific freight train headed eastbound. 25 people died. The Metrolink train engineer/operator was busy texting his friends while his train ran the red light. Currently, there’s no broadly adopted, standardized method to wirelessly link that red signal with the Metrolink train so that running the red light would cause the Metrolink locomotive to stop, or better yet, to prevent the Metrolink locomotive from even being able to run the red light.

So that’s where Positive Train Control comes in. There’s already been a huge amount of work done to date to establish the systems that do the analysis of the real-time data and make decisions on what should happen, but the wireless link that runs from the trackside (wayside) equipment, like that red signal, to the locomotive, is still a mix of proprietary techniques and methods that may or may not be well vetted.

Enter the IEEE 802. This group is pretty famous for solid radio standards, and broad industry adoption of its standards. And it’s a perfect home for the establishment of a Task Group focused on developing the standard for that wireless link from the wayside equipment to the locomotive, and vice-versa. So stay tuned, there’s more exciting stuff to come along over the next few weeks and months as we move from a Study Group toward Task Group and the ultimate goal of creating a wireless standard that will save lives.

Yep, it’s a little different than what I was doing before, but at the same time it’s all wireless, and the need for standards has never been more important than it is for this effort.

Sincerely, Jon

 

Short Range Wireless in Health Care

I wrote a short summary of a great presentation this morning on ZigBee Health Care (http://everythingwireless.wordpress.com). Had a major US cellular/wireline carrier, one of the world’s largest medical equipment OEMs, an exciting preso from a really promising California-based startup using RTLS, and a company that is doing really well with ZigBee-enabled devices in group elder care facilities. I believe that the ZigBee Alliance will be doing a public version of this presentation soon. Stay tuned!

Commentary and insight on many topics, sometimes even about wireless

WP Twitter Auto Publish Powered By : XYZScripts.com