Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 11 of 11

Thread: Remote weather station, first hardware project

  1. #1
    Junior Member
    Join Date
    Jan 2019
    Posts
    19

    Remote weather station, first hardware project

    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...
    Attached Files Attached Files

  2. #2
    Junior Member
    Join Date
    Jan 2019
    Posts
    19
    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 by Vam; 01-07-2019 at 10:31 PM.

  3. #3
    Junior Member
    Join Date
    Jan 2019
    Posts
    19
    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...

  4. #4
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    2,923
    Quote Originally Posted by Vam View Post
    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:

  5. #5
    Junior Member
    Join Date
    Jan 2019
    Posts
    19
    Thanks Micheal, the ADC lib will come in handy...

    re. premature optimisation: that's a good point, but it is fun nevertheless ;-)

  6. #6
    Senior Member
    Join Date
    Oct 2013
    Location
    Rogersville MO
    Posts
    253
    I ran a remote weather station all last year (shed in back yard no power to it) with https://www.tindie.com/products/xorb...o4weredsolar1/
    If you live in a climate where it gets below freezing solar get more complicated as you will damage cell when trying to charge below 32F. This board address those issues.

  7. #7
    Junior Member
    Join Date
    Jan 2019
    Posts
    19
    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.

  8. #8
    Junior Member
    Join Date
    Jan 2019
    Posts
    19
    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 by Vam; 01-09-2019 at 02:07 PM.

  9. #9
    Junior Member
    Join Date
    Jan 2019
    Posts
    19
    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 by Vam; 01-11-2019 at 02:00 PM.

  10. #10
    Junior Member
    Join Date
    Jan 2019
    Posts
    19
    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 by Vam; 01-27-2019 at 02:38 PM.

  11. #11
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •