Remote weather station, first hardware project

Status
Not open for further replies.

Vam

Member
Hi folks,

I'd like to set up a solar/battery-powered weather station.

The Teensy LC coupled with the air sensor and the 3.x/lc sd adaptor would AFAICT make a good starting point.

I'm not afraid of the software part of the endeavor, but this is my first embedded hardware project and I'm a bit puzzled as what would make an acceptable power supply. From this thread (some of the links are dead), I suppose that this charger coupled with this solar panel and possibly this battery would make a good combo. Could I replace the pannel with a pair of those in parallel? I have basic electricity notions, but little to no knowledge or intuition of circuits at this point, and I want to make sure that I don't fry something.

----

As an extension to the above, I'd like to build a (ultra)sound-based anemometer, inspired by this project by Carl Morey (see attached pdf for details).

Simply put, the wind speed affects the speed of sound, and by measuring sound along two perpendicular axes you get both the wind speed and direction. One big advantage of this design is the lack of moving parts that can wear out.

Assuming the speaker and the microphone are about 30cm apart, it takes about 1 millisecond for sound to travel from one to the other. At low wind speeds, each Km/h of wind adds (or subtracts) about 1 microsecond.

The proper technique entails generating a ultrasonic sine wave and then determining how out of phase it is with the signal expected when there is no wind. This would require a speedy-ish ADC and DAC. (~160kHz seem reasonable for a 40kHz signal, unless I remember wrong and you need a higher resolution to extract the phase with the required precision). Can the Teensy LC handle such frequencies? From what I gather from the procssor specs the ADC limit is expressed in MHz so I'm covered, but I want to be sure.

Rather than the standard, tone-based technique, I'd also be tempted to generate and detect a single click (simpler to synthesize, but probably trickier to detect in noisy situations such as high wind or rain. The sine waves technique lends itself well to averaging, clicks less so if there is some jitter). For that to work I'd definitely need a MHz ADC conversion rate...

Anyways, rather than doing the DSP on the micro-controller, I'd be tempted to save the raw samples and do the processing offline so that I can play with the data in an interactive fashion, so I suppose I'll also have to worry about data transfer speed to the SD card...
 

Attachments

  • ProjectReport.pdf
    1.2 MB · Views: 403
After some more digging, I'll probably need a Teensy 3.2 at the very least (for the RTC) if not a 3.5/.6 for the builtin flash support and extra oomph.

I've also dug further and refreshed my DSP-fu for the ultrasound anemometer. Sine pulses are the way to go.

In low-ish noises situations I should be able to extract the pulse position using cross-correlation (by convolving the signal with an inverted image of the input) then extract the phase using FFT on a window centered around the point with the largest correlation. Using the FFT should hopefully let me keep the sample rate low-ish and still get good phase info.

I may have to resort to more advanced techniques if that scheme doesn't work though.

If you measure the time of flight in both directions along an axis, you can extract both the speed of the wind and the speed of sound. The latter is a function of air pressure, temperature and moisture, so it may offer a correction factor for the measurements of the air sensor, whose heating element raises the local temperature. It will also let me easily reject bad measurements if the computed speed of sound is out of whack.

It turns out that waterproof ultrasound transducers are quite cheap. Rather than building my own amps, I'm tempted to buy proximity sensors, remove the microcontroller and drive the amp directly from the teensy. This would require some probing/reverse engineering, but it could be fun...

I still need some help for powering the whole thing though... Should I start a new thread in the tech support forum?

Edit: reading about the low power mode, how long does it take to go sleep and wake up? The LPTMR Type timers would probably come in handy for my project (no need for continuous measurements, the thing could sleep most of the time and wake up for measuring the air parameters and do a burst of wind speed measures... I may miss some wind bursts, I'm not too worried :).

Edit again: I found out about the power modes in the CPUs data sheets provided by NXP.
 
Last edited:
So, I've been obsessing on the efficiency of the signal processing part (which is probably ridiculous since it will most likely be dwarfed by the power used to generate and record the pulses, but still).

An interesting approach would be to do piecewise extraction of the FFT for the target frequency by bins of 4 samples (an O(N) operation that doesn't require any multiplication since the rotation coefficients are 1, -1, i and -i).

In low noise situation, the pulse will stick out like a sore thumb, and simple thesholding on the amplitude will do the trick then I can average the phase in the region of interest. If the SNR isn't as good, I could probably resort to clustering or something else TBD...
 
So, I've been obsessing on the efficiency of the signal processing part (which is probably ridiculous since it will most likely be dwarfed by the power used to generate and record the pulses, but still).

An interesting approach would be to do piecewise extraction of the FFT for the target frequency by bins of 4 samples (an O(N) operation that doesn't require any multiplication since the rotation coefficients are 1, -1, i and -i).

In low noise situation, the pulse will stick out like a sore thumb, and simple thesholding on the amplitude will do the trick then I can average the phase in the region of interest. If the SNR isn't as good, I could probably resort to clustering or something else TBD...

Be aware of premature optimization where you spend a lot of time optimizing stuff that you think is the critical section, but isn't.

For example, integer multiplies are 1 cycle on the Teensy 3.2 and I think divide is fairly fast also so if you are doing a lot of extra work to avoid a multiplication, it will turn out to be slower.

If you are doing floating point, the Teensy 3.5 and 3.6 have hardware single precision floating point that is very fast, as long as you use the float type, use the f suffix on constants, and use the <math>f functions.

I suspect if you are doing analog reads that you may want to think about using pedvide's ADC library to speed up the aquisition of data:
 
Thanks Micheal, the ADC lib will come in handy...

re. premature optimisation: that's a good point, but it is fun nevertheless ;-)
 
Thanks @cartere, that's the kind of unknown unknowns (to me) that I went fishing for here. I'm in northern France, and we get some days below 0C around here (usually less than ten per year, but I gather one is already too much). I'll dig more on that topic.
 
Making progress re. HC-SR04 proximity sensors. IT turns out I'm of course not the first to think of modding them.

There are several variants, the latest of which (the HC-SR04 P) can be driven by 3.3V, which is nice for my purpose.

The info in the pages above is pretty complete, but I'll probably need as scope for debugging if I miswire something. I've seen two threads on the topic in this forum, but I have some more questions... Should I start a new thread, or revive an old one?
 
Last edited:
Another approach to measure wind speed would be to use strain gauges, but I haven't seen any implementation of the concept.

The tricky part here is probably that both material stiffness and (IIUC) the Wheatstone bridge circuit used to measure the deformation are temperature sensitive. So it would ideally require extensive calibration, or at least a good model of the influence of temperature on these two parameters.

Also, I'm not quite sure yet of how to mount the whole thing. I suppose I could use two flat pieces of metal, placed orthogonally. For each plate, put a strain sensor on each face and get the resistance difference using the Wheatstone bridge.

Alternatively, I suppose I could use a single spherical rod with a hollow sphere at the top, and put matching sensors on the shaft, perpendicularly... Perfect sensor placement would probably be pretty hard to achieve, but I could correct it in software.

Edit: Now that I think of it, this would probably entail having a fairly rigid mounting system...
 
Last edited:
I'm also thinking about experimenting with soil moisture sensor technologies.

There are resistive and capacitive sensors, but I'm also curious about the RF-based SMURF method and the similar, sound-based method described here.

The speed of both sound and light in soil varies depending on moisture. (The trickiest bit is probably going to be calibration, since C also depends on soil composition and how packed it is). I'd like to implement both kind of sensors.

The audio method is quite straightforward.

The SMURF paper uses off the shelf MIMO WiFi routers and extracts the phase difference between antennas by relying on the CSI (Channel State Information) matrix. The ESP8266 SDK doesn't expose that matrix, nor does it let one manipulate the radio directly. Generic SDRs are quite expensive, so I was wondering if it would be possible to use the audio board as a LF SDR reciever, and the teensy as a 135-137KHz emitter (which is available for amateur use where I live, using a digital output and an analog low pass filter to cut harmonics). I'd sample in 96KHz/24bit mode in stereo and would rely on aliasing to read the actual signal (given how small the phase difference is going to be I'd rather have as much data as possible). All three antennas would be under the ground, possibly shielded in a Faraday cage.

Does that sound feasible? I know the audio library does not support those sampling params, but I could use it as a basis for my code? What I don't know is if the audio shield has a low pass filter on the input lines...
 
Last edited:
I just noticed this thread, while looking for info on sleep modes and power consumption.

Back in the 1970s I built a wind speed and direction sensor using a rod of phosphor bronze and two strain gauges. It worked well. We were building a robotic sailboat which had the wind sensor at the top of the mast, so it had to be ultra reliable and rugged. It's pretty simple if the rod is fixed in an upright position. In our case we also had to compensate for heeling of the boat.

Regarding your speed-of-sound sensor, I'd consider using a chirp. Chirps can be located in time with the highest precision your sampling system is capable of. Implementation is pretty easy by just correlating with the original chirp. As a starting point, I'd set the center frequency of the chirp near the peak response of your sensor or as low as possible, and crank the sampling rate up as high as you can. It's something to consider.
 
Thanks for the advice. I've yet to start building the thing (delivery issues on some parts, among which a soldering iron)...

It's good to know that there are working precedents.

It came to me recently that I could also use a strain gauge to measure rainfall. Coupled with a Pythagorean cup (a self-emptying container) it can measure rain indefinitely without any moving part... A possible concern would be condensation (humidity is high over here) but it can be mitigated by having two measuring devices, only one of which recieves rain.
 
When I lived in the tropics and fiddled around with rain sensors, I soon discovered that I needed at least two kinds of sensors, one for light rain, one for heavy. A sensor capable of measuring light rain is immediately overwhelmed by a tropical downpour that drops an astonishing amount of water.

Most sensors have an "LSB resolution problem". A rocker type sensor works well, but what if the rainfall is so slight that it never trips the rocker? You get no pulse and miss the shower entirely. What about left over rain from the last shower? Now you get a pulse too soon making the second shower seem bigger than it was. The Pythagorean Cup has these same problems, plus the problem that while the cup is draining, it's not measuring. And, of course, wind screws things up.

This is not an easy problem. There's no slam-dunk solution. It's a good one for applying some thought. Maybe you can invent a universal sensor that works in all settings and has no drawbacks. Thus far, nobody has come up with one. It's fun to think about because at first glance it seems like a pretty easy problem. It's not.
 
The Pythagorean Cup has these same problems, plus the problem that while the cup is draining, it's not measuring.

Not sure I understand what you mean here... I plan to have a container of 0.2 or 0.3 liters if not more, and weight it periodically. I suppose I can estimate the amount that fell while it was draining by measuring the draining time.

The main problems I anticipate for the Pythagorean cup are the scenarios where

  • it rains so much that the cup fills faster than it can drain (solution: use a larger drain, or sample from a smaller surface).
  • it rains so little that water spills by the draining tube without triggering the siphon (solution: use a narrower drain so that surface tension prevents spilling without priming the pump).

I hope there's a sweet spot where I can get enough rain to sample reliably and get the drain to work in all scenarios that occur where I live (no tropical downpours, but we still get a lot of rain).

This is very theoretical, I've yet to do any experiment, and I need to read more on the topic (e.g. how wide must the funnel be to sample reliably).

I suppose I should also add some kind of mesh on top of the top opening to avoid clogging the drain, but it will retain some water (so I'd have to find some UV-resistant hydrophobic coating)...

I've read in several places that wind can be problematic for rain sensors, but I don't understand why it is the case... The droplets's horizontal movement doesn't change the amount of water that hits the ground (or that cross the surface of the funnel)... I've even seen gauges that tilt towards the wind, but AFAIU that would corrupt the measurement... I'm probably missing something :)

Edit: What was your "light rain" solution?
 
Last edited:
It seems that you do understand. The problem is the dynamic range of rain is very large -- from a light mist to a downpour. "Tropical" rain is possible anywhere that thunderstorms are possible. I've seen it at least twice in Los Angeles, where you have to stop and pull over because you can't see, wipers are useless, and the streets flood in a matter of seconds.

I ended up building two rockers -- a big one and a small one, and called it good. For the detectors I used magnets and reed switches, which worked great. Reed switches are inherently weatherproof. Optical is another way. Hall Effect is another. I calibrated them by using a standard rain gauge through several rainstorms.

Wind directly affects rain gauges. The speed that raindrops fall depends on their size, which can range from microgram droplets floating down up to ping-pong ball size that actually hurt when they hit you. The raindrop velocity down plus the wind sideways gives a vector -- the angle the rain is falling at. No wind and you get a "perfect" measurement. During a hurricane with 100 mph wind, the rain is traveling horizontal to the ground and almost nothing lands in the funnel. It hits the side and runs down. Here in West Virginia, we sometimes get derechos with epic rain and up to 80 mph wind, so you don't have to have a hurricane to have problems.

You can visualize it from the raindrop's view. With no wind, your funnel looks like a perfect circle. As the rain vector leans over your funnel mouth becomes an increasingly eccentric ellipse.

Some meteo stations have been built in large flat areas, and the rain gauge is a nearly flat 10x10 foot square, almost level with the ground, draining to a collector in the center. This works okay if there are no nearby walls or tall grass. But, it only works for heavier rainfall. Light rainfall only dampens the large collector and no water reaches the sensor.

Another problem with rockers or cups, especially in warm conditions, is evaporation, although your idea of monitoring the weight of the cup should mitigate that.

Another problem is maintenance. Mold and algae love to set up shop in rain gauges with standing water in them.

What seems so simple is an engineering challenge. Every fix you come up with has a drawback, but that's what makes it a fun problem.
 
If you want measurements comparableto the official ones, there are a number of rules - depneds on the country you're living in. Here in Germany the DWD (Deutscher Wetter Dienst) has pretty strict rules for the sensors and their placement.
https://www.dwd.de/DE/derdwd/beobac...etterstationen.pdf?__blob=publicationFile&v=6
Forexample,for rain/snow:
As standard, precipitation sensors are to be installed in such a way that the collecting surface of the sensor is horizontal at a height of 1 m above ground level. Depending on the snow heights to be expected, the following installation heights for precipitation sensors were specified in the DWD: up to 500 m above sea level: 1.00 m above ground level (standard) 501 to 800 m above sea level: 1.50 m above ground level: 800 m above sea level: 2.00 m above ground level. Locations on hills and in terrain with strong inclinations (especially in the prevailing wind direction) should be avoided when installing precipitation sensors. It must be ensured that no updrafts or downdrafts can occur, which is the case, for example, on slopes, dikes, hills and behind large obstacles. The precipitation sensor must be installed freely, but as sheltered as possible from the wind. This means that the surrounding terrain should be so densely populated and/or overgrown that wind speeds near the ground are not too high, without causing any significant turbulence. The precipitation gauge should be positioned at a distance to obstacles or other sensors that is at least twice the obstacle height, ideally four times the obstacle height. The reference height is the catching height of the rain gauge. The installation of the precipitation sensor on roofs and terraces is not permitted. The substrate for the installation should consist of grass or gravel, concrete is out of the question due to the risk of splashing. It must not be possible to blow snow from roofs or trees into the precipitation collection container.

Translated with www.DeepL.com/Translator
And this is only for the placment.For the sensors exist more rules.
 
Yay! Standards! Thanks for posting that.

Yeah, roofs of buildings are bad because of turbulence. Being in hurricanes is educational because there's so much water in the air that the air is visible and you can see how it flows like a liquid. When wind hits a house it jets up and to the sides, then bounces across the roof. It looks just like how water goes over and around a pebble in a shallow stream. Lots of turbulence. Of course, the same thing happens with a 20 mph wind, just at a smaller scale and you just can't see it. I shot some good video of these effects during Hurricane Charley. (Yes, I went out in 110 knot sustained wind, with higher gusts. I'm crazy and have a high pain threshold.) Unfortunately, I lost the videos and only have a few photos.

When I knew I was going to get hit by Hurricane Mitch, I moved my rain gauges to the middle of a large clearing, surrounded by tall trees. I think it helped. I recorded 33 inches of rain at my location at the east end of the border between Guatemala and Honduras.
 
I bought them pre-glued, they look like this (not sure how they're supposed to look or if it was a good job):

strain gauge.jpg
 
Time Domain Phase Measurement

After some more digging, I'll probably need a Teensy 3.2 at the very least (for the RTC) if not a 3.5/.6 for the builtin flash support and extra oomph.

I've also dug further and refreshed my DSP-fu for the ultrasound anemometer. Sine pulses are the way to go.

In low-ish noises situations I should be able to extract the pulse position using cross-correlation (by convolving the signal with an inverted image of the input) then extract the phase using FFT on a window centered around the point with the largest correlation. Using the FFT should hopefully let me keep the sample rate low-ish and still get good phase info.

I am building an ultrasonic anemometer too. I decided I had to use a Teensy 4.0 to get a high enough sample rate on the pulses. The sensors work at 40 kHz, I sample at 320 kHz. First I tried time of flight. After digitizing, I demeaned the pulse, squared it and used a digital low pass filter to get an envelope. Initially the results looked good, but the time of flight would slowly drift around by the equivalent of 3 - 5 m/s of wind speed when the device was in a box (wind speed = 0) inside my house. Even if I corrected for temperature at the device.

I implemented phase measurement in the time domain measuring the difference in zero-crossing time of the received signal to the reference signal, then averaging that over about 65 zero crossings per ADC reading (512 samples). This phase measurement is very stable; I can clearly see the cycling of my house heating. I also have a temperature sensor mounted on the device. When I compensate for measured temperature, the deviation in the equivalent windspeed is 0.2 m/s.

I will post details once I get the whole anemometer working. I guess it is a weather stations too since I have a BME680 Temp, Press, Hum, and gas sensor mounted on it! (No rain.)

BTW, I found your report when I was designing mine. Do you have an update on how it is working?
 
Status
Not open for further replies.
Back
Top