WGR800 error - wind speeds >10m/s

[jrhilton]

Hi, I've noted that wind speed never goes above 36km/h (10m/s) yet when I look on the OS consol during high winds it does.

The speeds match up exactly to the consol otherwise, except during very high winds. What could be causing this issue?

Almost as if it should be something like this to also get the tens, as I can see it gets the ones, and decimal tenths:
double gust = ((nyb(14) * 100) + (nyb(13) * 10) + nyb(12)) * 3.6 / 10;

and
avWindspeed = ((nyb(17) * 100) + (nyb(16) * 10) + nyb(15)) * 3.6 / 10;

Not had a chance to upload this to try, but has anyone else noticed this issue?

Many thanks,
James.

P.s great work on this, I can't tell you how useful it has been, as getting data out of the console via USB is hit and miss!!!

[robwlakes]

Now that is very interesting James, I have had similar suspicions. Not the least of which occurred this last Thursday night when there was big wind storms across the state and we copped a bit of it too. It felt like it was about to take the solar panels off the roof. Yet the wind speed 30+ something did not seem to reflect the feeling I had that it was exceptional. I will check the code I am using at the moment and try your suggestion.  I have wanted to update this code for ages but GITHub I find incredibly frustrating and not for beginners like me. I seems to tie myself in knots just to get an update to work (entirely due to my ignorance I am sure). Thank you for interest and analytical thinking about this. I will get back to you. Rob

On 29/8/20 8:09 am, James Hilton wrote: Hi, I've noted that wind speed never goes above 36km/h (10m/s) yet when I look on the OS consol during high winds it does. The speeds match up exactly to the consol otherwise, except during very high winds. What could be causing this issue? Almost as if it should be something like this to also get the tens, as I can see it gets the ones, and decimal tenths: |double gust = (**(nyb(14) * 100) +** (nyb(13) * 10) + nyb(12)) * 3.6 / 10;| and |avWindspeed = (**(nyb(17) * 100) +** (nyb(16) * 10) + nyb(15)) * 3.6 / 10;| Not had a chance to upload this to try, but has anyone else noticed this issue? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#9>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABWNZZO2CS3ZC46NON5BH63SDATIRANCNFSM4QOSALMA>.

-- *Rob Ward* Lake Tyers Beach, 3909 Lake Tyers Beach Website <http://www.laketyersbeach.net.au> Ubuntu Mate - A great OS <https://ubuntu-mate.org/>

[jrhilton]

Hi Rob, many thanks for your reply. I've had another read of this document that details the RF Protocols and it does spec three nibbles making up the speeds, so adds some substance to my logic. The numbering of the nibbles is slightly offset in that document vs your code, but if you normalise them using the wind direction nibbles then there is a perfect overlap when you add in nyb(14) and nyb(17) to your code.

I've now added this code:

gustActualMS_tst = ((nyb(14) * 100) +(nyb(13) * 10) + nyb(12)); //new test
avWindspeedMS_tst = ((nyb(17) * 100) + (nyb(16) * 10) + nyb(15));//new test

Which are also sent via the serial port using dumpAnemom() and logged. I may need someone else to help validate this too as wind speeds >10m/s are rare here in London, UK. So it maybe many months before I get some actual data to validate it myself, but I will be sure to report back when I do have some data.

Stay safe and well in these times!

[robwlakes]

Hi David, I ignored my own notes from about 10 lines up. Thank you for your diligence, I have altered the source code and hope to update it on GITHub ASAP. I have added an acknowledgment for your contribution. Like you, we don't often experience over 36m/s winds, even though we are on the southern east coast of mainland Australia. We are only 10minutes walk form the ocean. However we are at the top of a very wide bay and don't really get the feel of the roaring fourties. So it maybe a while before we can see any difference. I have an updated version of the Manchester algorithm that I will incorporate when I update. It is much more elegant than in the current version. Same concept but not as convoluted. I think what we would have seen with the MSB missing would have been chopped wind speeds reported when the reading was above 36km, LSB's  would have dropped to "low" and the MSB would have been absent to take over. I feel I have noticed that before and just put it down to gusty conditions, ie peaks and troughs. Whereas it could have been hovering above and below 36m/s consistently, and the dips coming from the lack of MSB input. My Web site wind graphic uses an 8 samples rolling average so indicates "8x1 minutes"  so that would tend to hide the extremes as well. It may well be that which has dulled my observations. I do keep a "peak gust" recorded over the last hour, so that should show it. I will need to look for above 36km :-) Thanks again, Rob.

On 29/8/20 11:41 pm, James Hilton wrote: Hi Rob, many thanks for your reply. I've had another read of http://wmrx00.sourceforge.net/Arduino/OregonScientific-RF-Protocols.pdf <this> document that details the RF Protocols and it does spec three nibbles making up the speeds, so adds some substance to my logic. The numbering of the nibbles is slightly offset in that document vs your code, but if you normalise them using the wind direction nibbles then there is a perfect overlap when you add in nyb(14) and nyb(17) to your code. I've now added this code: |gustActualMS_tst = ((nyb(14) * 100) +(nyb(13) * 10) + nyb(12)); //new test avWindspeedMS_tst = ((nyb(17) * 100) + (nyb(16) * 10) + nyb(15));//new test| Which are also sent via the serial port using dumpAnemom() and logged. I may need someone else to help validate this too as wind speeds >10m/s are rare here in London, UK. So it maybe many months before I get some actual data to validate it myself, but I will be sure to report back when I do have some data. Stay safe and well in these times! — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#9 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABWNZZNDGXFOOHSVUW6HTBTSDEAQNANCNFSM4QOSALMA>.

-- *Rob Ward* Lake Tyers Beach, 3909 Lake Tyers Beach Website <http://www.laketyersbeach.net.au> Ubuntu Mate - A great OS <https://ubuntu-mate.org/>

[jrhilton]

Thanks Rob, as an update still no high winds here, plenty of sunshine instead so we shouldn't complain!

So not got a chance to test the changes at this end yet. Though as a side note I have ported the code over to run on an ESP8266 which interestingly when using the same type of receiver module and stock antenna is far more sensitive and picks up all transmissions even on the other side of the house where the Arduino plus the same receiver module would be deaf. And that is with the receiver running at 3.3v instead of 5v. Either i've got super lucky with a very sensitive receiver module when running at 3.3v or the ESP8266 has much better timings (which I suspect is the case).

Kind regards,
James

[robwlakes]

Now that is very interesting. My wind sensor is on the very top of the gable of our roof. Our house is a two story "upside down house" and the weather computer gear is in the garage below at ground level. The wind Tx is above a galvanised iron roof and it has always been the trickiest to detect, the first to dropout. Your message is timely indeed. I had to get up on the roof (not recommended for anyone over 60) yesterday and put some new lithium Alkaline AA batteries in the Tx to get from about very marginal 40% reception success to around 95% success. The standard Alkaline AAs I removed were still in good condition, but obviously not good enough. I have suspected that the RF environment on a Standard Uno board may generate hash that dulls the sensitivity of the 433MHz Rx. Not being versed many of the black arts of RF means my experiments this time (last week) was limited to putting the Rx supply wire through a few turns of a small toroid and putting a 0,4uf ceramic on the power supply of my 433MHz test rig. I did not get any where near your improvement, hence dragging out the fresh batteries. I have a spare ESP8266 I could try. I might also try the Rx on an "umbilical" leads to just physically seperate it from the Uno. I am definitely not returning to the roof to put the marginal batteries in. Haha. I am almost ready to publish the new Manchester algorithm (same idea with delays, but much cleaner code) so I am hoping you might be willing to give me some early feedback. Some more information on your ESP8266 work, (a link maybe?) would be extremely interesting. Thanks for your interest and feedback. Rob Cheers, RobW

[roberto1984]

Hi all guys, hi Rob!
i'm also using the esp8266 since 1 year ,starting from rob code that i have adapted for esp8266 nodemcu, uploading every 50 seconds to a mysql database.
I also confirm that the wind was "capped" at 10m/s, just today i added the fix from jrhuilton(thank you!!!!),i will let you know if the reading between console and nodemcu are aligned!

Cheers!
Roberto

[jrhilton]

hello @robwlakes / @roberto1984 - I hope you are both keeping well and safe! Sorry for such a delayed update but this week we had the first winds >10m/s since my last post. As a result of Storm Bella I recorded a max of 59.76 km/h on 27th December from one transmission which the console didn't record (not surprising as I note it doesn't register every transmission anyway). However it shows a max of 49.6km/h which I have correlated to the data in my SQL database for the same time. So I am satisfied that my code suggestion works and is matching to the console.