How to use barometer readings

[franksingleton]

That's making it complex all we did is look at the barometer reading when were updating the log and add the reading to it, we also logged wind speed, wind direction, boat speed, any traffic seen and engine hours if used, we did that every 2 hours on passage. If the pressure is changing downward by more than 2 mb/2 hour expect a gale.

See#12.

 

[jdc]

I don't think it so bad an idea, but think you should take advantage of the advantages you have over a conventional aneriod barometer.

1. Record history. Probably for fun really, but you need to be able to look back several weeks. Let's do a simple sum. At sea level a range from 940 to 1060 mbars should be enough, stored as an 8 bit number. That's a possible resolution of a little better than 0.5mbars- rather better than your sensor I'd think. let's sample every 15 mins (changing faster than 0.5 mbar in 15 mins is unlikely): in 3 months that's ~ 3 x 30 x 24 x 4 = 8640 bytes, or 8.4 kB. Really not much for an Arduino these days I'd have thought: it might have stretched my Sinclair from 1981, but surely not now? Can you buy SRAM this small?.

2. Auto-calibrate. Most sensors have significant deviation in raw output as a function of cabin temperature: in the tropics this dominates the diurnal pressure change, to the detriment of the instrument's usefulness. You can easily develop a 1st order calibration of the form

P_calibrated = P_raw + k * (T - T0)

where T is the raw reading from a temperature sensor and k and T0 are constants derived from an algorithm. The function of this algorithm is to search for values of k and T0 which make the value of P_calibrated least correlate with T. It may take months to converge, but it will gradually improve the accuracy.

3. Process data as it comes in to output useful things (output may be to set an alarm or make a TCP/IP connection and send some data for instance).
Examples of useful things will be:
3.1 Detection of large dP/dt (up or down as Frank points out). Thresholds for alarms may themselves be set by the pressure at the point of rapid change (is a fast fall when at 1050 the same significance as one at 995? I don't know actually). Note that you can sample every minute to better resolution than you store for long-term in order to get a dP/dt. You don't have to wait for several storage periods as you seemed to imply in an earlier post, nor is the optimum noise suppression filter necessarily the same.
3.2 Detection of significant divergence from diurnal variation. This applies in the tropics - plenty of references - where even quite small deviations signify a possible tropical storm. A human has to plot the graphs whereas the computer can do it all automatically and is never off watch or too busy.
3.3 Output an NMEA stream to make it possible to record correlations with other parameters (latitude for instance). This could, if you are really successful, lead to a sort of 'crowd-sourced' set of meteorological records supplementing buoys and weather stations.

Hope these comments are helpful!

 

[[70521]]

I shall stick to recording the pressure in the log, I have an adversity to all this electronic wizardry.

 

[GHA]

I shall stick to recording the pressure in the log, I have an adversity to all this electronic wizardry.

Did you get that message onto the forum via carrier pigeon?

 

[franksingleton]

I don't think it so bad an idea, but think you should take advantage of the advantages you have over a conventional aneriod barometer.

1. Record history. Probably for fun really, but you need to be able to look back several weeks. Let's do a simple sum. At sea level a range from 940 to 1060 mbars should be enough, stored as an 8 bit number. That's a possible resolution of a little better than 0.5mbars- rather better than your sensor I'd think. let's sample every 15 mins (changing faster than 0.5 mbar in 15 mins is unlikely): in 3 months that's ~ 3 x 30 x 24 x 4 = 8640 bytes, or 8.4 kB. Really not much for an Arduino these days I'd have thought: it might have stretched my Sinclair from 1981, but surely not now? Can you buy SRAM this small?.

2. Auto-calibrate. Most sensors have significant deviation in raw output as a function of cabin temperature: in the tropics this dominates the diurnal pressure change, to the detriment of the instrument's usefulness. You can easily develop a 1st order calibration of the form

P_calibrated = P_raw + k * (T - T0)

where T is the raw reading from a temperature sensor and k and T0 are constants derived from an algorithm. The function of this algorithm is to search for values of k and T0 which make the value of P_calibrated least correlate with T. It may take months to converge, but it will gradually improve the accuracy.

3. Process data as it comes in to output useful things (output may be to set an alarm or make a TCP/IP connection and send some data for instance).
Examples of useful things will be:
3.1 Detection of large dP/dt (up or down as Frank points out). Thresholds for alarms may themselves be set by the pressure at the point of rapid change (is a fast fall when at 1050 the same significance as one at 995? I don't know actually). Note that you can sample every minute to better resolution than you store for long-term in order to get a dP/dt. You don't have to wait for several storage periods as you seemed to imply in an earlier post, nor is the optimum noise suppression filter necessarily the same.
3.2 Detection of significant divergence from diurnal variation. This applies in the tropics - plenty of references - where even quite small deviations signify a possible tropical storm. A human has to plot the graphs whereas the computer can do it all automatically and is never off watch or too busy.
3.3 Output an NMEA stream to make it possible to record correlations with other parameters (latitude for instance). This could, if you are really successful, lead to a sort of 'crowd-sourced' set of meteorological records supplementing buoys and weather stations.

Hope these comments are helpful!

However ingenious such techniques are and how often you look at the barometer, the weather, wind etc one fact remains. To be able to predict the weather for more than a short time ahead requires knowledge of weather over a large area. You do not. A Met Office senior forecaster once said that to know about weather anywhere required knowledge of weather everywhere.

If you are content with prediction for the next hour or two then fine. On some occasions you will do better, on others you will do worse. You will often not know about the weather in 12 hours time. You will not know what to expect on your next passage to wherever or at your destination.

When I first became interested in weather I was given two weather prediction tools . One was a ceramic donkey with a straw tail. It said – “If tail waves around, it is windy. If tail is wet, it is raining. If tail cannot be seen, it is foggy. If tail falls out, earthquake.”

A little more useful, the other consisted of rotating concentric dials that let you enter pressure rise or fall and wind direction. Playing around with barometer reading in however clever a way and however clever are the electronic goes no further. Beaufort had a set of rules for weather prediction that referred to wind, cloud, barometer readings etc. We have moved on. I am sitting in Dartmouth waiting for a suitable wind to get to St Peter Port. It looks like being next Thursday with no possibility before that. However much a look at my barometer I would not be in a position to make such judgements.