meteohub.de

I've got a few specific questions relating to MB template variables. I can't see them answered anywhere already but maybe I've missed a key page in the wiki (or, if not, maybe there's scope to add a new page in that provides a little more technical details for some of the variables)?

One general question to start: Is there a recommended maximum size for a template (in terms of parameters processed). It's not uncommon with an AWS with several extra sensors fitted to want to generate a data file with eg 100 parameters and perhaps to do so every few seconds. (The basic Cumulus clientraw.txt file has 57 fields IIRC and that doesn't cater for many supplementary sensors.) Can an MR3020 MB cope with this? (Let's say as the sole active task, to start with.)

Now on to specifics and to start with wind: It's common to refer to the latest wind speed value received as a gust value. And, for a Davis station, a new gust reading is available (in principle) about every 2.5secs. So I presume that [wind0wind] actually gives the latest gust value. (Can I use wind0wind without a selector, or should I always use wind0wind-act ?) So about every 2.5 secs on a Davis station there will be a new value of wind0wind-act ?

Then what period does wind0avgwind average over? OK, 'depends on station' but is that information specified somewhere? Is it actually better to forget about wind0avgwind and use averages over specific time periods like wind0wind-avg2? (But avg1 doesn't seem to be a valid selector, although there are applications like APRS which IIRC ask for a 1-minute mean wind speed).

Am I then correct in thinking that wind0dir (or should it be wind0dir-act?) is the latest gust direction received? And if I need a mean direction over the past 2 or 10 minutes then I can use wind0dir-avg2 (or -avg10) - do these work OK?

Finally, how many anemometers will MB support? In theory with MS, one could be receiving from up to 8 anemometers, although 2 or 3 is perhaps a more practical limit (ie anemometers at different heights when surveying a site for a wind turbine) though that said I can think of a current application (maintenance work on a major suspension road bridge) where 4 anemometers are in use.

I've also got some questions on other parameters, but that's probably enough for now. I'll add the other questions to this thread maybe?

PWS wrote:I've got a few specific questions relating to MB template variables. I can't see them answered anywhere already but maybe I've missed a key page in the wiki (or, if not, maybe there's scope to add a new page in that provides a little more technical details for some of the variables)?

One general question to start: Is there a recommended maximum size for a template (in terms of parameters processed). It's not uncommon with an AWS with several extra sensors fitted to want to generate a data file with eg 100 parameters and perhaps to do so every few seconds. (The basic Cumulus clientraw.txt file has 57 fields IIRC and that doesn't cater for many supplementary sensors.) Can an MR3020 MB cope with this? (Let's say as the sole active task, to start with.)

Now on to specifics and to start with wind: It's common to refer to the latest wind speed value received as a gust value. And, for a Davis station, a new gust reading is available (in principle) about every 2.5secs. So I presume that [wind0wind] actually gives the latest gust value. (Can I use wind0wind without a selector, or should I always use wind0wind-act ?) So about every 2.5 secs on a Davis station there will be a new value of wind0wind-act ?

Then what period does wind0avgwind average over? OK, 'depends on station' but is that information specified somewhere? Is it actually better to forget about wind0avgwind and use averages over specific time periods like wind0wind-avg2? (But avg1 doesn't seem to be a valid selector, although there are applications like APRS which IIRC ask for a 1-minute mean wind speed).

Am I then correct in thinking that wind0dir (or should it be wind0dir-act?) is the latest gust direction received? And if I need a mean direction over the past 2 or 10 minutes then I can use wind0dir-avg2 (or -avg10) - do these work OK?

Finally, how many anemometers will MB support? In theory with MS, one could be receiving from up to 8 anemometers, although 2 or 3 is perhaps a more practical limit (ie anemometers at different heights when surveying a site for a wind turbine) though that said I can think of a current application (maintenance work on a major suspension road bridge) where 4 anemometers are in use.

I've also got some questions on other parameters, but that's probably enough for now. I'll add the other questions to this thread maybe?

For the number of tags
Yes it can handle large amounts of tags
Example, this is the standard Saratoga-template file for MB: www.wiri.be/saratoga/gen-MBtags.php
And this is the Leuven template file for MB: www.wiri.be/weather2/uploadMB/tagsSoil.txt
They are uploaded for my Meteobridge template/Script test site every 5 minutes
http://www.wiri.be/weather2/lang=en for the Leuven-Template
http://www.wiri.be/saratoga/?lang=en for the Saratoga template
and every minute the realtime files are also processed.
For the number multiple devicesAs far as I know only one console/logger can be connected to the Meteobridge. Bus as long as the console can handle things Meteobridge can do that probably also.
For running multiple ISS/consoles/Weather-stations the Meteohub program is better suited. It can connect multiple stations and use any of the connected sensors.
gust
As far as I know windgust is not windspeed as for windspeed the speed must be measured for x seconds. x depends on which source you read. This definition uses x=20 seconds: "A gust is a sudden increase of the wind’s speed that lasts no more than 20 seconds." So if it is called windspeed it should better be an average speed over 20 seconds.

Succes, Wim

PWS wrote:Is there a recommended maximum size for a template (in terms of parameters processed). It's not uncommon with an AWS with several extra sensors fitted to want to generate a data file with eg 100 parameters and perhaps to do so every few seconds. (The basic Cumulus clientraw.txt file has 57 fields IIRC and that doesn't cater for many supplementary sensors.) Can an MR3020 MB cope with this? (Let's say as the sole active task, to start with.)

From a computational point of view MBs don't have a problem to fill in a thousand of variables in no time. But storage is limited. Templates received from an URL (as with FTP, HTTP, etc) are not allowed to be more than 16 KB long, templates given directly via MBs web interface (as with EMAIL, TWITTER) are limited to 4 KB. Limits could be lifted if needed, but for the moment that seems pretty much above what a user is expected to need.

PWS wrote:Now on to specifics and to start with wind: It's common to refer to the latest wind speed value received as a gust value. And, for a Davis station, a new gust reading is available (in principle) about every 2.5secs. So I presume that [wind0wind] actually gives the latest gust value.

yes

PWS wrote:(Can I use wind0wind without a selector, or should I always use wind0wind-act ?)

selector is needed.

PWS wrote:So about every 2.5 secs on a Davis station there will be a new value of wind0wind-act ?

yes, unless you have dropped RF packets.

PWS wrote:Then what period does wind0avgwind average over? OK, 'depends on station' but is that information specified somewhere?

Most companies do not state how they compute their "average wind". In case of Meteostick it is a 120 seconds average over all wind speeds recorded during that time.

PWS wrote:Is it actually better to forget about wind0avgwind and use averages over specific time periods like wind0wind-avg2? (But avg1 doesn't seem to be a valid selector, although there are applications like APRS which IIRC ask for a 1-minute mean wind speed).

yes, "avg2" is shortest available average.

PWS wrote:Am I then correct in thinking that wind0dir (or should it be wind0dir-act?) is the latest gust direction received? And if I need a mean direction over the past 2 or 10 minutes then I can use wind0dir-avg2 (or -avg10) - do these work OK?

"wind0dir-act" is wind direction of latest wind information from your sensors. No "averaging" done, raw data as measured by the sensor.
"wind0dir-avg2" reports the wind direction (out of 16 segments, 22.5°) that has received the most wind direction reportings in the time frame to be considered.

PWS wrote:Finally, how many anemometers will MB support? In theory with MS, one could be receiving from up to 8 anemometers, although 2 or 3 is perhaps a more practical limit (ie anemometers at different heights when surveying a site for a wind turbine) though that said I can think of a current application (maintenance work on a major suspension road bridge) where 4 anemometers are in use.

MB supports just one wind sensor. In case of Meteostick, it doesn't have to be the one connected to ISS, but can be a separate one.
Meteohub can handle up to 10 wind sensors and log data for those.

PWS wrote:I've also got some questions on other parameters, but that's probably enough for now. I'll add the other questions to this thread maybe?

You are welcome.

Many thanks wvdkuil and admin: A few follow-up points:

Template file size: OK, that sounds fine. A template for the realtime.txt data file (just as a convenient real-world example - sorry I think I mistakenly said clientraw.txt previously but same difference) seems to come out at about 700 bytes, so even catering for say 100 parameters would only push that up to eg 1.5K, so no problem.

On gusts: To some extent this is just rather arbitrary terminology, but I find the Davis terms quite useful. Last time I looked, WMO (in modern usage) define a gust as the wind speed measured over a 2-3 second interval. All Davis stations actually seem to measure wind speed over a 2.25sec period (OK that doesn't fit in exactly with the ISS wind packet interval or the LOOP interval, but it's close enough) and then report to the console or eg MeteoStick, so in a sense the Davis raw wind speed values are a continuous stream of gust values. How the console firmware or other software chooses to average this gust-value stream over a period is then up to the firmware/software, but personally I'd rather use an explicit and unambiguous value like a 2-min or 10-min mean speed, rather than a perhaps poorly-defined term like average speed where there's no inherent clue as to the averaging period.

Other points all understood. I'll maybe pursue the multi-sensor question offline.