This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
New station on air
#1
I have finally found time to set up my new Compact weather station.
Located in Tasmania, the southern end of Australia.


For the transmitter, I used an Arduino nano on stripboard rather than the supplied PC board.
I wanted to share the wind and rain sensors with my other weather station and it was easier to go with the stripboard for now.
It also shares the power supply.

I also find that 5V is plenty for my transmitter instead of 9V. There is enough RF floating about here so I like to use the minimum power level.
I also changed the wind transmit frequency from 3 seconds to 12 seconds. This was also to minimise the RF in the area.
I had to change the voltage levels for the wind rose because my other system required 3.3V, not 5V.

Now I need to think about a case for it.


Jim
Reply
#2
Congratulations!  Smile
Best Regards
Zdenek

 [Image: banner.php]
Reply
#3
Awesome!
Care to share some photos of the stripboard? (That's how I started too  Wink )
Reply
#4
Congratulations for your new Weather Station.


(28-03-2019, 05:43)TassyJim Wrote: I also changed the wind transmit frequency from 3 seconds to 12 seconds. This was also to minimise the RF in the area.

I believe you did it by just changing this:

Code:
   t.every(3000, get_WindGust);                                 // Sample wind gust every 3 seconds and Send PacketID2

to this:
Code:
   t.every(12000, get_WindGust);                                 // Sample wind gust every 3 seconds and Send PacketID2

I strongly recommend to not do this. The wind gust should be sampled at a most shorter interval than 12 seconds. You will lost readings of real wind gusts, and most important the readings of average wind speed will also be affect by your change (if you don't believe it, just try with default setting and then with the changed one, then compare the graphics). Resuming, your wind readings will be much flat.

Many weather station (FO and many others), which send RF data with longer intervals, usually send the highest wind gust recorded within the period between each data packet. WeatherDuino don't work this way, it works more like the Davis Weather Stations (which send wind data at each 2.5s - WeatherDuino sends each 3s).

There is even other implications... if one data packet with wind data is lost (by any reason) your readings at the receiver will have a 24 seconds interval.
MeteoCercal - Air Quality Data
Click here to watch at my ThingSpeak channel



Reply
#5
(29-03-2019, 01:30)Werk_AG Wrote: I strongly recommend to not do this. The wind gust should be sampled at a most shorter interval than 12 seconds. You will lost readings of real wind gusts, and most important the readings of average wind speed will also be affect by your change (if you don't believe it, just try with default setting and then with the changed one, then compare the graphics). Resuming,  your wind readings will be much flat.

Many weather station (FO and many others), which send RF data with longer intervals, usually send the highest wind gust recorded within the period between each data packet. WeatherDuino don't work this way, it works more like the Davis Weather Stations (which send wind data at each 2.5s - WeatherDuino sends each 3s).

There is even other implications... if one data packet with wind data is lost (by any reason) your readings at the receiver will have a 24 seconds interval.

I thought about this for a long time.
My other system uses the Davis protocol but is connected to my Cumulus software with hard wiring so RF is not a problem.

One packet takes 380mS and sending that every 3 seconds was too high a duty cycle for me. I have other RF data links also on 433MHz and I am worried about interference. I had to accept the loss in wind data.

I will set up a second instance of Cumulus and connect it to the WeatherDuino and do a comparison.
Not much use today, we have very little wind.

Jim
Reply
#6
Hi,

(29-03-2019, 05:09)TassyJim Wrote: One packet takes 380mS and sending that every 3 seconds was too high a duty cycle for me. I have other RF data links also on 433MHz and I am worried about interference.

I have to agree with TassyJim on both duty cycle and power level aspects.  The 433 MHz "ISM band" is basically a single-channel (433.92 MHz frequency) system which relies heavily on "time sharing".  Many countries' regulations recommend a maximum average duty cycle of just 1% and rarely as high as 10%.   As Werk notes, most (all?) 433 MHz commercial systems do (must) transmit the gust data as a separate data field within lower-duty-cycle packets.

AFAIK, Davis does not use the 433 MHz ISM band at all, but also they use a "spread spectrum" (channel-hopping) technique to avoid "blocking" any particular channel.  In America, they use the "915 MHz" band from 902 - 928 MHz and in Europe/UK the "868 MHz" band.  It appears that neither of these bands is permitted in Australia, so Davis supply a special version which channel-hops within a band from 915 - 928 MHz.  See the information particularly from Prodata in this Cumulus thread.

My Medium/Long-term aims are to implement a gust-packet within the Weatherduino format, but an alternative (to reduce both the transmitter duty cycle and power drain) is to use the  Auriol (Weatherduino-compatible) protocol.  However, I haven't yet been able to find a specification of the (Wind) transmission period within the wireless protocol documentation.

Cheers,  Alan.
Reply
#7
Hi,

Doing something like that is something that is also in my wish list. However it's a medium/long-term goal. Reducing the size of the data packets and using LoRa may be a way.
MeteoCercal - Air Quality Data
Click here to watch at my ThingSpeak channel



Reply
#8
I have had a chance to do some more testing.
With the Wind at 3 seconds, the radio channel is busy 17% of the time.
With the wind at 12 seconds, the utilization drops to 7%. Much better.
I feel much happier at 7%

The regulations around usage vary between countries and in Australia, there are regions that have tighter control than the standard regs.
In this case, I don't think there is a duty cycle restriction but I still have to use the equipment in an appropriate manner.

The WeatherDuino measures gust by using the time between pulses. This gives an instantaneous measure.
My other system uses interpreted Basic so it would have trouble using that method at high wind speeds. I chose to count the pulses in 2.5 seconds as my measure. It was 3 seconds but changed to 2.5 when I went with the Davis protocol.
Because of these differences the WeatherDuino should give a slightly higher gust speed when compared with my old system.
This is what I see when I compare two CumulusMX charts. Both systems share the same sensors so there are no differences there.

   
Average speeds are identical apart from slight rounding differences at times.
WeatherDuino gusts are consistently slightly higher than the alternative.


There doesn't appear to be a world wide agreement on how gusts should be measured so I consider either method valid.

By reducing the wind reporting to 12 seconds, the maximum gust is still reported but there is less fluctuation. It doesn't have any effect on the averages readings because they are still calculated every 60 seconds.

Wind direction could probably benefit from the faster readings but I see negligible difference when comparing the Cumulus charts of the two systems.

My next, less controversial change, will be to create a screen with large fonts for temperature a, humidity and rain.

My wife has to put her glasses on to read the current display.

Happy wife = happy life!

Thanks for a great project.
I have finally found a reason to learn a bit if Arduino programming.

Jim
Reply
#9
I decided to re-use an old rain gauge display case.
   
The one on the right is an original. The 2.8 display is a tight fit.
Previously, I had a 2.4 inch display in the case and it was a much easier task.


Jim
Reply
#10
(03-04-2019, 05:09)TassyJim Wrote: I decided to re-use an old rain gauge display case.

The one on the right is an original. The 2.8 display is a tight fit.
Previously, I had a 2.4 inch display in the case and it was a much easier task.

Smile  Very nice!
Best Regards
Zdenek

 [Image: banner.php]
Reply




Users browsing this thread: 1 Guest(s)