Building a Mobile Mesonet

[Sean Waugh]

Ryan, for future reference I was the one who gave that presentation during V2. I will also be giving another one this year as I have developed a new instrument to solve the issues I discussed last year.

As for this thread, really opening a can of worms here. Tyler Allision started a similar thread which can be found here: http://www.stormtrack.org/forum/showthread.php?t=22304. We exchanged several emails on the topic. I could spend PAGES talking about this type of issue, but I'll try and keep it short for now.

My experience on mobile instrumentation is far more than most. I built all of the mobile mesonets that are being used for the VORTEX 2 project. I designed and built the computer equipment and mounting inside the vehicle, and was significantly involved with the racks themselves. I have also been doing a large amount of research on the mobile mesonets. What I have found is disturbing, at least to me.

There is a TREMENDOUS amount of research that must be done to ensure even the slightest bit of accuracy in mobile measurements. An interesting example is the "J" tube that almost every researcher uses for housing temperature an RH sensors while on a mobile vehicle. You can read up on the design of the "J" tube here, http://ams.allenpress.com/archive/1520-0426/13/5/pdf/i1520-0426-13-5-921.pdf, which was for the original VORTEX project over 2 decades ago. Almost everyone accepted this shield to be accurate without question. For my CAPSTONE project last year, I found and documented several serious errors that can occur in certain situations. I see a lot of chasers that have a cup anemometers mounted 3 inches off their car roof and call it accurate data. I wouldn't trust data in those cases for anything. There are a lot of considerations that must be made to obtain even reasonable data. Take a temperature sensor for example. JUST BECAUSE IT HAS SPECIFICATIONS FOR AN 18 SEC TIME CONSTANT DOES NOT MEAN THAT IS WHAT YOU ARE GOING TO GET. NSSL uses a temperature sensor in the "J" tube that has a manufacturer specified time constant of 18 seconds. However, when placed in the "J" tube that time constant rises to almost 1 min, 30 secs (one of the many findings of my CAPSTONE). This means that it take a minute and a half to reach 63% of a step change in temperature. Just because it says it is accurate to 0.2 degrees C does not mean anything in the real world. I takes the "J" tube on average over 10 minutes to reach the final value, and that is assuming that there are NO other changes occuring.

Everything influences your measurements: speed, heading, height, time of day, rain vs no rain, ect. There is nothing remotely simple amount measurements, let alone measurements on a moving platform. If you just want to look cool, fine. If you just want to know the fact that the temperature changed, go for it. But if you are trying to get even remotely accurate data, especially for use in research, be prepared to spend a lot of money and time.

 

[Jason Foster]

But if you are trying to get even remotely accurate data, especially for use in research, be prepared to spend a lot of money and time.

That kind of matters on what you mean as "accurate". What variations have you monitored in your research (not having checked it out YET for myself). while I obviously have one, I'm not likely to submit much obs from the station because I accept a 2 or 3 degree difference. However, driving across a dryline or measuring Hurricane winds, I found it's accurate enough! I think it is important to make obs while stopped as much as possible, which for this thread talked about tropical chases, is the case 90% of the time.

Just like Ryan noted too, RM Young would be required for true scientific data...trusting the best consumer market station (Davis) really isn't good enough for true comparison or inclusion with any V2 data for example.

I will say though, having check with various other stations and equipment, the Davis station I've show in the previous post has been fairly close to official stations. It would be of course ideal to compare to Mesonets similar to or directly with what is used on V2.

 

[Sean Waugh]

Yes, my sense of "accurate" may be different than others. But something to remember is what you are using the data for. Driving down the road and sitting still both have their respective problem situations. While most of your data (in a general sense) would be close (2-3 C, ~5 mph, +/- 2-3 degrees wind direction, ect) to an "official site", remember that those sites may also have issues. A simple example would be during a driving rain (like in a hurricane). In that scenario, there are several temperature shields that end up allowing the temperature sensor to become coated in rain, which results in the measurement of the rain temperature, not the air temperature. There can be very large errors (>5 C) in these situations.

Again it comes back to what you want to do with it. If you want to know that something changed (or is changing) but you're not too concerned with the exact magnitude of the change, then you're probably ok with the less expensive equipment. But if you are trying to give reliable, "accurate" data to forecasters, or determine the width of a boundary, then you are going to have to spend more time and money developing and testing the design.

 

[Seth Price]

Seth, I think that dual anemometers/vanes would be redundant since you need vehicle direction and speed from another independent source, i.e. a GPS. Given that, computing true wind is a rather simple vector calculation.

Google USBTenki, for a sensor I'm experimenting with, FWIW.

But won't the speed and direction will be influenced by the vehicle moving? I mean, if you are headed north at 60 mph, and the wind is 20mph from the west, you will likely end up with 60mph North for your wind? I'm not sure I fully understand the way to do this properly.

 

[Skip Talbot]

But won't the speed and direction will be influenced by the vehicle moving? I mean, if you are headed north at 60 mph, and the wind is 20mph from the west, you will likely end up with 60mph North for your wind? I'm not sure I fully understand the way to do this properly.

Maybe it helps to visualize it, as here is the vector math David was talking about:

Your car is the big orange blob moving towards the top of the screen. In the example you gave, the car is going to feel winds at 63.25 mph from 341.57 degrees relative the front of the vehicle (the purple line). If we draw a line on a graph of length 63.25 and this angle, we can extend a line down from the top point representing our vehicles speed and direction of travel. We know the car was moving 60 at the time and its moving forward so the line goes straight down at a length of 60 (the green line). You then simply draw a third line to complete the triangle and that's the actual wind corrected for the car's movement (the blue line).

You simply add the wind created by the car moving forward at 60: <0, 60> and the surface winds <20, 0> and you wind up with a 2D vector of <20, 60>. The length of this vector is the wind speed = sqrt((20*20) + (60*60)) = 63.25. I think its a little easier to look at the picture though.

 

[David Goines]

Seth, just subtract the vehicle's speed from the anemometer's "y-component" to get a resultant wind speed vector with the motion of the vehicle being in the positive y direction.
"<[Anemometer's X] , [Anemometer's Y]-[vehicle speed]>

And use pythagorean's theorem to find the actual wind speed.

IF the wind speed has a positive y-component, Arctan([wind speed x-component] / [wind speed y-component]) should give you an angle clockwise from the car's forward motion.
IF it has a negative y-component, add 180 degrees to the angle.

With a direction now in relation to the vehicle, take ([wind direction in relation of the car]-360 +[compass direction]) to get the direction of the wind's origin clockwise from the the Earth's north.
Example: If a car is heading east (90 degrees) and is reading a wind direction of 315 degrees (front left of the driver). 315-360+90=45degrees (NORTH EAST wind)

Edit: Yeah Skip beat me to it but the picture really helps. But like said before, a wind direction in relation to a car is nothing unless it's integrated with a GPS or compass... and to me that's the tricky part.

 

[Tyler Allison]

As for this thread, really opening a can of worms here. Tyler Allision started a similar thread which can be found here: http://www.stormtrack.org/forum/showthread.php?t=22304. We exchanged several emails on the topic. I could spend PAGES talking about this type of issue, but I'll try and keep it short for now.

I plan on publishing what Sean and I discussed as I think we pretty much documented all the major issues. I just need to find the time.

-Tyler

 

[Jane Herbert]

Could I please have a translation in English for a non-physics major whose math is a bit dodgy.......I'm trying to find a table or easy rule to work out both wind speed and direction from the Vantage Vue that has just sprouted on the roof of the car....

"just subtract the vehicle's speed from the anemometer's "y-component" to get a resultant wind speed vector with the motion of the vehicle being in the positive y direction.
"<[Anemometer's X] , [Anemometer's Y]-[vehicle speed]>

And use pythagorean's theorem to find the actual wind speed.

IF the wind speed has a positive y-component, Arctan([wind speed x-component] / [wind speed y-component]) should give you an angle clockwise from the car's forward motion.
IF it has a negative y-component, add 180 degrees to the angle.

With a direction now in relation to the vehicle, take ([wind direction in relation of the car]-360 +[compass direction]) to get the direction of the wind's origin clockwise from the the Earth's north.
Example: If a car is heading east (90 degrees) and is reading a wind direction of 315 degrees (front left of the driver). 315-360+90=45degrees (NORTH EAST wind)"

Thanks heaps in advance!!

 

[Quinton Kirsch]

What Skip was talking about in the post above would only really work under ideal conditions.

Jane: I would not even worry about the Pythagorean theorem as vector calculations are easier to apply in this use case. I spent a good bit of time researching this topic on my own and found some good resources online. Interestingly enough I found the answer within the marine and boating community. I can't recall what site I got the information from but I saved the calculations in a document and will list them below.

Vehicle:
Speed and direction derived via GPS while in motion, otherwise digital compass is supplemented in while stationary.
SOG: Speed Over Ground
COG: Course Over Ground

Anemometer:
This is the wind relative to the vehicle.
AWS: Apparent Wind Speed
AWD: Apparent Wind Direction

True Wind:
The derived estimate wind speed/direction as though you were stationary while in motion.
TWS: True Wind Speed
TWD: True Wind Direction

Finding the vector components of the apparent wind:

a = (AWS)cos(AWD)
b = (AWS)sin(AWD)

Finding the vector components of vehicle speed/direction:

c = (SOG)cos(COG)
d = (SOG)sin(COG)

Now to subtract the vehicle motion from the apparent wind observation:

u = c - a
v = d - b

An alternative way to find the true wind components is to do everything in one step. For the purposes of this post, I've shown the long and below show the short way.

The alternative does everything in one go, and is probably the preferred option given it's more efficient:

u = (SOG)cos(COG) - (AWS)cos(AWD)
v = (SOG)sin(COG) - (AWS)sin(AWD)

With true wind now derived as u and v components, all that is left to do is calculate wind speed and direction.

True wind speed is pretty straight forward:
TWS = SQRT((u*u)+(v*v))

Find the square root of the added combination of each squared component.

True wind direction calculation is a little more involved however. Because of how the cartesian plain works, each quadrant requires its own separate formula (I'm not an expert on mathematics so I couldn't tell you why this is, it just is, I'm sure a google search could yield some results).

I put together and labeled the corresponding quadrants with the component values. The output for true wind direction is denoted as theta θ. In a computer program or logger software the output can automatically be supplemented.

QUADRANT I
u > 0
v > 0
θ = arctan(v/u)

QUADRANT II
u < 0
v > 0
θ = 180 + arctan(v/u)

QUADRANT III
u < 0
v < 0
θ = 180 + arctan(v/u)

QUADRANT IV
u > 0
v < 0
θ = 360 + arctan(v/u)

So now determining true wind direction is as straight forward as:

TWD = θ

I hope this clears up your confusion and helps anyone looking for information on this topic.

More information on wind component vectors can be found here.

Cheers