I’m really excited for this post because I have a prototype temperature/humidity/pressure sensor built! Last night I started to build it out and it only took about 45 minutes total.
I started out using an RJ11 cable soldered to the board but it turned out to be very tempermental and not wanting to stay soldered. So for the prototyping phase, I opted to just solder on some breadboard jumpers which worked great.
I decided on the orientation I did because the SCL, SDA, and GND pins were both on the same trace. The only difference was the 3.3 and Vcc. I plan on using 3.3v for everything so I did have to accommodate for that.
I decided on ground on one side and vcc on the other, and scl/sda in the middle. It seemed to work pretty well but i’m not sold on that for the final pinout.
Once I plugged it in, it worked! I was getting output from both sensors
In terms of actual connectivity, I think i’m going to solder an RJ11 socket onto the pcb. This will allow easy replacement/removal of the sensor without having to fish a cable again. It will also make soldering easier.
So now the next step will be to start building a PCB design. I still need to prototype boards for soil/moisture as well as the main pcb, so I’ll probably wait to actually submit and order those until later.
In order to test out my sensors, I’d been using an adapter like this
I soldered on some breadboard jumpers to each lead that matched the color. This meant I could plug RJ11 into the breadboards and use all my sensors. Great! Except for one tiny issue….. And I didn’t think about this until about 8:30 tonight after fighting with it for a good 90 minutes. The colors don’t match the colors on the Davis cable. So when I was plugging it into my board using the connections from Cactus.io, It was not the right connections. Everything is reversed!
I knew it had to be my wiring because even with a multimeter I tested things and it came back with no voltage. It just didn’t make sense. So I kept digging and digging and I came across this document and in particular this passage:
Huh. Well that makes sense. This also makes me realize why I burned up my stock Davis Temp/Hum sensor in part 3. Apparently it was not as forgiving about incorrect wiring… Upon reading this page I realized I was not dealing with a straight cable and this was a reversal situation. So I took a look at the colors on the RJ11 end of the Anemometer cable, and then mapped them to the correct colors on the cable. What i came up with was this:
Davis Yellow (Power) is Black Davis Green (Wind Direction Signal) is Red Davis Red (Ground) is Green Davis Black (Wind Speed) is Yellow.
So once I went back downstairs and wired it up like that, it worked! Using code from here I got a basic script working that would show the voltage change as I rotated the wind vane around. Hurray! Coupled with the wind speed switch working as designed, I now have working wind measurements. Considering I bought a large pack of those RJ11 connectors, i’m still gonna use them, but i’m gonna solder them up with the correct color jumpers to match the input so it is straight through to the breadboard.
So that’s exciting. I also got word today my SHT35 will arrive tomorrow along with some project pcbs. This is exciting as I can combine the SHt35 and BMP180 onto the same board and test that functionality out. Once I verify on the breadboard everything will work as designed, I can start building out a prototype of the real new temp/humidity board. I also plan on taking a trip out to the production weather station this weekend and doing some live prototyping with soil moisture/temp sensors and UV/SRAD sensors. Given I now understand ADC, it should be pretty straight forward, but I still gotta make sure I test everything!
It was an interesting weekend. I got a couple things in the mail so I could finally start doing more prototyping. First off I received the cradlepoint device, so I mocked up what the enclosure might look like.
So that was nice. I also pulled my VP2 off my pole in the backyard to start prototyping with it’s sensors. That did not go well.
First was the rain gauge. This actually did go well. First I tried to follow the instructions here: https://projects.raspberrypi.org/en/projects/build-your-own-weather-station/8 which really was not super accurate and the code was hard to follow. So I started from scratch and read up on the gpiozero “Button” module. Once I figured out which wires did what on the Rain Gauge (I found that Red needed to be Ground, and Green worked for recording the tips. Green was on GPIO6). Now this may not seem like a big accomplishment but up until this point, my experience with GPIO on RPi has been just reading tutorials and copy/pasting stuff. So I figured this all out from scratch so I consider it a learning experience. So now I can count tips. Granted, the code is very simplistic right now and does nothing for rain. But I know how it works and I have a working snippet, so now I can figure out how to actually document rain.
This is where the mistakes were made. The temp/humidity sensor. I could not find any solid documentation online about these sensors regarding usage with Arduino or Pi. It also seems Sensiron makes a couple different versions, the most popular being an I2C version. I was not sure what version the VP2 used, so I tried hooking it up via I2C and i found this page (http://www.pibits.net/code/raspberry-pi-sht31-sensor-example.php#codesyntax_1) that I thought would work. Well as i’m finding out, the Davis colors don’t always match the standard colors, and things may be miswired. How did I find this out? Well I know I don’t have Covid-19 because I could smell something very burny. Uh oh.
So I took the little filter off the top of the sensor, and it was hot to the touch. Very hot. I unplugged it, but realized at that point i’ve probably fried the sensor. Whooooops.
So yea. At this point i’ve managed to fry the standard Davis sensor. But that may be a blessing in disguise.
SHT31. Destroyer of obs?
After some googling, I find out that the SHT31 is not exactly the most accurate sensor, especially in the Davis units:
So from what I can tell, the SHT31 that Davis uses is not super accurate. Nor does it use I2C, or even an analog signal. I found this page that describes that the SHT31 uses “Legacy Sensirion Sensibus” or “LSS”. I’ve not found any good documentation online about using this with an RPi or Arduino. So if i’ve already caused myself one problem, I might as well fix it. I’m also trying to fix the reception issue, so I might as well fix the accuracy issue as well. This will make the idea of the system being completely plug and play null. HOWEVER I feel like most ppl that care enough about the accuracy of their station and want to completely convert over to a Pi based system will be keen on replacing the problematic SHT31 so I don’t see it as a big problem.
The Pressure is on…. the same board!
So with that, I opted to get an SHT35 sensor. They come in a few forms, but almost all are shipping from China right now and it’s almost a month wait. But I was able to find this one on Amazon for a good price. Funny enough buying from the manufacturers website ends up taking much longer for shipping. This will be here in a few days. The SHT35 not only has better accuracy, but is I2C. What else is I2C? The BMP180! That will make things easy. One of the big problems is that the pressure sensor is in the Console or Envoy unit. So the plan is to have the BMP and the SHT on the same board in the radiation shield, and use I2C to have them use the same RJ11 cable. Problem Solved! Problem Solved! We solved the problem, problem solved (That’s also from Peg + Cat). So I should know by the end of week if that will work. The other issue is the size of the board.
The non-fan aspirated shield mounts the sensor like this:
That means size wouldn’t really be an issue for that board. But the fan aspirated version (which is what I have at the station i’m upgrading, and i’m not able to find a good pic of) the sensor unit actually slides down into the shield in two “grooves” and so size is important. It’s the same exact sensor, just different mounting. So with that in mind I need to make sure I adhere to the same size. Ultimately my goal is to create a PCB for this as well, so if someone else wants to use the VP2 with an Arduino/Pi directly they can and replace the sensor.
So with that, my next goal is wind sensors. This will also introduce me to analog inputs, as the wind vane is a potentiometer. So while I wait for my temp/humidity parts, I can get cracking on wind speed.
As I was writing up last night’s post, a few things slipped my mind. Namely, the number of sensors I have on my VP2. When I bought it, I wanted the best of the best. And so, I sprung for the VP2 “Plus” which included Solar Radiation (SRad), UV, as well as a Fan Aspirated Radiation Shield (FARS). Something I also did not mention was I have a standard VP2 at my house, which will make prototyping significantly easier. However I am missing those sensors at home. Also, a few years back, I added Soil Temp and Moisture at 4 depths as well as a “Leaf wetness sensor. So that’s 8 total sensors just for soil! These sensors use their own transmitter, and funny enough, i’ve never had issues with it. So with that, here is the list of sensors I will need to accommodate for in my design:
Tipping bucket rain gauge
4x Soil Moisture
4x Soil Temp
Pressure (not provided in Davis unit. Will need external sensor. Probably BMP something or other)
Let’s take a look specifically at the Soil Moisture and Temp sensors.
Per the guide located here the temp sensor is a standard resistance based temp sensor. From my initial reading, it sounds like that’s a bit more of a challenge to get working with a Pi directly. So that’ll be fun to learn!
Now the soil moisture is very similar, in that it uses resistance to determine soil moisture. It appears to be a “Watermark sensor from Irrometer” again this is a two wire setup, so it may not work directly with the Pi and i’ll need to figure that out.
4 of these bad bois are buried under my station.
Finally the leaf wetness sensor. There’s also not a ton of documentation around this and using it with a Pi. So i’ll need to do some additional research and understand how they work.
So that’s the soil/temp/leaf. Seems like it’s gonna be a tad more complicated than the standard sensors. Also seems like i’ll need to pick up a couple just to play with and prototype with.
Here comes the sun
Now for the other two sensors. UV and Solar Radiation. As I suspected, the UV sensor apparently uses a photodiode that only responds to radiation in the region of interest. Based on the spec sheet it appears to simply send voltage back. From 150 per UV Index, up to 2.5 VDC. So that shouldn’t be too hard to measure.
So now solar radiation. It also is used to calculate evapotranspiration (one of my favorite words in meteorology) and again based on the spec sheet it acts in the same way as the UV sensor, sending voltage with 1.67mV per W/m2 (Watts per meter squared).
So really it seems like the UV/Solar sensors are gonna be pretty straightforward. They already do the easy stuff in the sensor itself, I just gotta measure the voltage coming back from the sensor.
So it seems i’ll need to start exploring Analog to Digital conversions to use all this stuff with the raspberry Pi. Truthfully my experience thus far with the RPi has never really utilized the GPIO connectors. Although I did build a light sensor that controls a monitor using a photoresistor and a capacitor. So I have some vague understanding, but this is on a whole other level.
So looks like i have a few more things to think about with prototyping! Gonna order some Analog to Digital converters (Should only need one but but I better get more in case i mess one up which i probably will) and start understanding how analog to SPI works. I was worried about having enough pins on the GPIO, but at this point given the ADC will take a bunch of analog inputs and put them on a single SPI, I should be OK.
What am I on about? What does the title mean. Well it goes a bit like this. Ever since 2013 I have operated a Davis Vantage Pro 2 weather station in my hometown in Kansas. When I was living in Oklahoma, the station was about 300 miles away, however now i’m closer, at about 70 miles. This certainly has not made administration of this station any easier. Since I’ve installed it, i’ve faced various problems, one of those i’m attempting to solve with this project.
First off let’s talk about the current setup. I’ve been very fortunate that the station is located at an educational facility, that provides me full access to the internet as well as power. So with this, I placed the station in a suitable location, approximately 100 ft from the building in an open field.
This is a wireless station, so what about the receiver. Currently it’s using a Wireless Envoy, however it started out using the VP2 console, which is enclosed in an outdoor housing from Davis:
So we have the station sending and receiving data. Now what? This is where things have changed a lot. I’ve been through multiple iterations of this station. Let’s see if I can remember everything i’ve done in the correct order:
1: Started with the Vantage Pro 2 install in 2013. Used the Davis software on a Windows XP machine. Data was sent via FTP to a web server hosted in a colo facility. Do not recommend this approach, as the XP machine was hilariously unreliable and the software just not good.
2: Raspberry Pi. I came to my senses and installed a different software on a Raspberry Pi. I went with WView as it was quite popular at the time amongst users.
3: Raspberry Pi 4 with WeeWX. WView severely limited my ability to customize the setup. I don’t know C and I don’t want to re-compile after every single change. Couple that with the fact that WView is no longer in development, a change was needed. I also got word my Colo facility was shutting down my server (I was getting it for free from a friend anyway) so I needed to move to AWS fast. WeeWX had the ability to do this and the performance uploading to AWS on the original Pi was abysmal. Upgrading to a Pi4 was the right option. Which is how things are setup now.
This post and the blog really is going to focus on the hardware/station side of things. I’ll be writing a separate blog post for work on how i’m moving forward with AWS IoT for this station. So finally what am I doing? Well i’ve had some problems with the station that include:
Power outages at the facility, knocking the Pi off power.
Internet outages. This is in a rural area and we don’t have the luxury of fiber like I have at my home. We have a 35mbps connection delivered by Point to point wireless. It works OK but has outages. This prevents the data from being uploaded to AWS.
Signal issues. I’ve been fighting this for months now, and even over a year. I get random drops where the station just falls off the map. Sometimes for days on end, then comes back online like nothing happened. I’ve changed channels, i’ve replaced boards, i’ve replaced receivers (hence why i have an Envoy now vs a console) and it’s still happening. Sometime’s it’s solid for WEEKS and sometimes it won’t go two days without dropping.
So what are the solutions to these problems?
Power: Get a UPS you dingus! Well yes this is a fair point, we would need to put the entire internet setup on a UPS as well, and then we are not guaranteed a long runtime unless we invest in a large capacity unit, which is not a high priority.
Internet: Run off LTE! It’s definitely something i’ve considered. But again, i’d need to also think about power as well, since without power, the LTE is no good. Couple this with being in a metal building, LTE would also require external antenna. It’s definitely the lowest priority issue.
Signal: This is the issue i’m solving. First thing I considered was getting a cabled station. You can convert the ISS to a cabled board, but the investment is significant. As well as digging a trench, running the cable, etc. It’s a lot of work. So that’s out. So I started thinking do I really need the Davis stuff? Which has led to this project.
Enter the smol computers
When you take it all apart, the VP2 is not really anything special. The sensors are actually fairly straight forward. I came across this post (http://cactus.io/hookups/weather/anemometer/davis/hookup-arduino-to-davis-anemometer) which goes into details about the wind at least. Turns out the vane is just a potentiometer and the anemometer just a switch. Most likely a reed switch similar to the rain gauge. So as far as the sensors are concerned, they have no idea they are in a weather station. The rain gauge also operates using a simple Reed switch.
The temperature/humidity board is an SHT31 just in a different package. This does not include a pressure sensor, which they annoyingly placed inside the console or Envoy unit.
So with all that being said, what does Davis do? Well they take this raw sensor data, they package it up on the ISS board, and then send it via wireless or wired in their own way. Now others have cracked the code and built their own receivers for these stations. But i’m looking to remove the Davis from the Davis entirely and remove the entire wireless setup.
So if i’m looking to remove wireless, what about the power and the internet from the educational institution? Don’t you need that still? I’m thinking I don’t, and i’m thinking the Raspberry Pi is the solution. By interfacing the sensors directly with the Pi, I would be able to take the raw data from the sensors, and upload that to the cloud. With recent upgrades, i’m expecting wifi range at the station, and also have been provided with a Cradlepoint unit from a colleague that I will be utilizing for LTE backup. Power will be provided via a Lead acid battery, charged via a large solar panel. Having the Pi at the station will also allow me to add additional functionality, including a camera.
So what is the goal? What is the point of this rambling? By the end of this project, I hope to have a PCB that I can attach to a Pi (or Pi Zero) and be able to ingest sensor data from a VP2 and have it be more reliable than the current setup. Obviously there are lots of factors to consider, things such as:
Weatherproofing. Can’t have a Pi in the rain. Looking at using knock-off Pelican “Apache” cases from Harbor Freight as a good option, which leads to the next concern…
Temperature: It gets hot and cold in KS. So the entire setup needs to be able to withstand high and low temps, as well as humidity.
Reliability: Ulimately the Pi is a small Linux computer. Computers aren’t always our friends. So I need to make sure the setup is as low-touch as possible and I can’t be messing with it every day. Given the amount of custom work i’ll be doing, this is definitely a major concern.
So stay tuned! This is just the first of hopefully many posts as I begin prototyping, and hopefully much shorter, less rambly posts going forward.