Topic: VP2 Custom Hardware / Circuitry

[Vanadium]

Hi All,

Newbie here, hope its OK to post this, just wanted to show something I've been working on the past couple of weeks. Nothing new in terms of the actual sensors or anything, basically it's an off the shelf Davis VP2, however I've pulled out the Davis PCB and made my own.

I wanted to be able to monitor the VP2 remotely via GSM/WCDMA. I'd looked at some off the shelf solutions and they all seemed to have the console version plugged in to some external hardware, with a large sealed lead acid battery, a solar regulator and a big panel to keep the thing running 24/7. This all seemed a bit overkill / expensive and not really made for purpose, so I thought I'd have a go at making something that could replace the whole lot with a single board, and came up with this:



On board 3Ah battery (3.2v LiFePO4). It has a 2A MPPT Solar Regulator to charge the battery, so the only external part is still a 5 or 10W solar panel.

Hardware seems to be working well, just got to write a lot more code to get the sensor readings to a web page/database of some sort..

[SomeCallMeTim]

Wow! Looks terrific! What are you using for the uC and development environment? Have you got it talking to the Sensirion SHT11 OK already?

Looks like you’ve included a pressure transducer and I think the UV and Solar are just 0-3V analog interfaces, so should be easy. Might want to add some surge suppressors if not already included, though. And I’ve long felt it might be nice to do a little 2nd or 3rd order correction to the raw anemometer data, as well as high-rain-rate tipping-bucket error correction.

I’m sure a number of us here would love to hear about all the details you care to share. If you haven’t already found it, be sure to look at Dekay’s fascinating work in reverse-engineering the Davis ISS RF protocol.
If you make your data conform to the Davis serial protocol to the extent relevant, it might make interfacing to lots of existing SW much easier, too.

Good luck & keep us posted!
- Tim

[Vanadium]

Thanks Tim!

I designed it to be able to have 3 different communication options, either Xbee, Ethernet or mPCIe card. I had to come up with some sacrifices during development so I ended up using two uC's, Microchip's XLP PIC24F for the sensor interfacing and a PIC32 for the comms.

When originally designing it, I had in my mind that any of the communication options would spend their time mostly asleep, wake up every x minutes, connect to the network and upload whatever data it needs to before disconnecting and going back to sleep, but in dealing with mostly PIC32's for ethernet, I found their TCP/IP stack isn't really designed for being switched on/off and didn't want to have to spend the time getting it to work with going in and out of sleep and reinitializing the whole stack every time and so on, so for the sake of an extra buck I put on the PIC24F as well. After doing all that though I realized for the ethernet version if you have ethernet you probably have mains power and it can just run 24/7 anyway, but if needs be the PIC32 and ethernet phyter can be disconnected from power, with the PIC24 still taking all the samples, wind speed measurements and rain bucket inputs.. The main down side to doing it this way is the additional cost, but it's not too much and there aren't many additional passives required, a few decoupling caps etc..

So, so far with the PIC24 code I have it taking readings from the BMP085 pressure sensor, the SHT11, taking wind speed measurements and rain bucket inputs (it uses the change notification interrupts to wake it up from sleep, record the time the rain input came in and go back to sleep, similar with the wind speed input), and the ADC code done for taking wind direction measurement and battery voltage readings. I haven't actually got any UV / Solar sensors yet so I haven't bothered coding them in, but I found on here somewhere that the inputs are ~1.67 mV per each W/m².

I wasn't 100% sure on how to do wind speed, I'm still not sure I'm doing it correctly but at the moment, every time the input goes low I take a time sample (resolution is 30uS) and subtract from it the last time the input went low, giving me a time period. Every two seconds I check that the last wind speed time period was faster than 2 MPH (and taken recently) and if so insert the speed into a rolling 30 int long array (1-minute of readings), otherwise the speed is recorded as 0 MPH. The array gives 1-minute average wind speed as well as being able to retrieve the current wind speed (I maintain a pointer to the latest reading). To do 10-minute average wind speed, every minute (when the array rolls over) I insert the 1-minute average into a rolling 10 int long array, which should give 10-minute average wind speed, yeah? :\ The other was I was thinking was to just add 1/25th of the result each time (so currently average * 0.96 + new reading * 0.04), and change the read time to once every 2.4 seconds. I'm still not sure how to actually record the data for things like wind rose plotting..

You can get here (https://dl.dropbox.com/s/s4ge4q4aj6wxskl/WxLab_Ser.pdf?dl=1) a sheet of the schematics which show the RJ modular jack connections and the input protection & buffering. Not all the values are correct and some were changed during testing that I haven't updated yet.., also not all passives were populated, ie R78, C58, C60..

I've been watching Dekay's work on the ISS RF protocol, very interesting and clever indeed! I'm not an RF guy (thus the xbee module ), nor do I really do much reverse engineering so a lot of that's just amazing to me.

I'm not sure what to really do about the software side, whether it'll just make a basic website just for this.. and/or make an android/iOS app for it. I've built up an ethernet version which has its own built in web interface which will show the current sensor readings etc, but not 100% sure how to do the GSM/wireless version.

I put up a little rendered video which you can see the other side of the board in, http://youtu.be/NKaTUX_0IFI (the 3d models aren't 100% correct ).

[SomeCallMeTim]

Nice. I, too, am a fan of parceling functions out to separate cheap processors –especially between things like network & user interfaces vs real-time. Sure, an RTOS can make it all work on one core, but why bother unless it’s going to Mars! (the magnificent Mars Science Lab runs VxWorks on a PowerPC). Is the TCP/IP stack free for the PIC32? There are lots of Cortex-M parts with MACs, but the stacks to use them can be mighty dear.

Having more than one processor can facilitate robust remote firmware update capability, too, as while one is being lobotomized the other can stand by to aid in recovery if something runs amuck.

I like your rolling array method for wind speed averaging vs weighted sample summing as the array lends itself well to additional filtering and frequency analysis if desired (assuming there’s ample uC RAM).

Yes, the wind direction averaging problem is a deceptively complex one. For example, do you want to compute a true vector average weighting the resulting direction based on speeds of the samples, or just compute an average using normalized samples except maybe tossing only the near zero velocity samples. And then there’s the issue of quantifying and representing variability by computing the standard deviation or some such. Ends up being non-trivial.

A commonly accepted solution seems to be the Mitsuta method (modulo 360 averaging) if the sampling rate is high enough to ensure less than 90deg sample delta, as this avoids the need for trig functions.
The more general method if you can afford the floating point overhead seems to be to average the sines and cosines then take the arctangent of the results.

Here’s a very nice discussion of the issue as relates to radio direction finding, but same problem.
http://abelian.org/vlf/bearings.html

Also, there’s an earlier thread on this forum
http://www.wxforum.net/index.php?topic=8660.0

And another nice discussion that might be useful.
http://www.webmet.com/met_monitoring/62.html


What SW did you use to generate that really nifty video of the board?

[Vanadium]

Yep the Microchip TCP/IP stack is free. Can RTOS work if you want to put the device into low power modes?

Thank you very much re the info on the methods for wind averaging! That's going to be some fun by the looks of it!

The hardware was created with Altium Designer, including the video - the models are from 3dcontentcentral.com

[SLOweather]

When I read:

Hardware seems to be working well, just got to write a lot more code to get the sensor readings to a web page/database of some sort..

I PMed Vanadium about this project. We've been corresponding in email over the last few weeks. I sent him the upload protocol the WeatherElement.com server and in short order he had his dev unit uploading to it. I set up his own WeatherElement page for him to use.

http://www.weatherelement.com/rowantest

Of course, he's all metric, and WeatherElement to data has been US centric. So, the units are all goofy for the numbers. Still, it's all working. If you look at the indoors and stats page, the battery voltage is the on-board battery. Since there's no console, he's repurposed the indoor temp as solar panel voltage.

We're working on metricizing WeatherElement for international stations, and a set of WeatherElement pages for these that don't show the unused stuff.

And, this morning I learned the model number and price of the US/Verizon version of the cellular module so I can begin some US testing.
   

[weathertech]

Hello Vanadium,

Great looking hardware replacement you have built.  You mentioned that your schematic WxLab_Ser.pdf does not contain the correct values and is not complete.  Are you able to update the schematic on the DropBox link as I'm looking to make a simple monitor head to interface to the Davis sensor, but I do not have a unit to reverse engineer.

Otherwise is your custom hardware and Altium project files Open Source or available at all to view?

Thank you.