Hi everyone:
I'm trying to figure out some oddly high wind gust readings at a couple of weather buoys I maintain that have RM Young 05103 anemometers and CR1000s. I've posted some plots on imgur:
Those are plots of wind speed vs wind gust, the first two panels are my buoys, the third panel is a nearby NOAA Tide gauge with an anemometer on it, and the fourth panel is a NOAA buoy that's a ways away. The red line is the 1:1 line.
The NOAA stations have gusts that are generally no more than two or three times the wind speed, that's what I'm used to seeing. My buoys are reporting gusts many times higher than that- 4 m/s gusting to 30 seems a bit out of the ordinary,
The CR1000 program has a 1 second scan and was doing winds thusly:
PulseCount(wind_speed,1,WS_CHANNEL,1,0,0.098,0)
BrHalf (wind_direc,1,mV2500,WD_CHANNEL,WD_EXC,1,2500,False,0,_60Hz,355,0)
AvgRun (gust, 1, wind_speed, 3)
All wind data, including gust goes into a 6 minute table:
Maximum(1, gust, FP2, False, False)
I've since changed the PulseCount to
PulseCount(wind_speed,1,WS_CHANNEL,1,1,0.098,0)
...so it is measuring Hz instead of counts. That shouldn't matter I think, since pulse counts with a one second scan is Hz anyway. I had initally thought, "oh, it's totting up counts for a three second period instead of averaging so the gusts are three times higher than they ought to be", but that's not it.
Does anyone have any ideas what I'm missing here? I've been up and down the CRBasic help files and googled far and wide but cannot figure out what's wrong. The way that there are three "fingers" in my buoy data (particularly visible for buoy 2) I think is a hint but I don't have a good hypothesis for that yet.
Option 1)
You seen this in the command reference for PulseCount() at the very bottom?
Note: This instruction should NOT be placed inside a conditional statement, subroutine, subscan, or SlowSequence scan. To ensure all pulses are detected and the counter does not overflow, it must be executed each time the main program is executed.
I have had pulse count problems in the past for wind measurements and never really solved them (complex programs) as we switched over to sonic anemometers which usually are being talked to via SDI-12.
Our tipping buckets on the other hand are in the same boat though and at the moment they mostly work, but I really have the PulseCount command sitting smack in the middle of the Scan/NextScan of the main loop without any conditions, which is doing all sorts of stuff running at a 100 mSec interval. And the PulseCount is being executed for each and every one of those Scans. No If's or When's. Just every time.
Option 2)
Can you log a 'wind_speed_max' in your table along the 'gust' value like so to check that there really are no such high values in your input?:
Maximum(1, gust, FP2, False, False) Maximum(1, wind_speed, FP2, False, False)
Might want to activate the log-timestamp-option when those Maximums happen in the 6 min interval to be sure in case you need to recognize a pattern..
Option 3)
Any SkippedScans for your code when running?
See Status Table and look for that and things like MeasureTime and ProcessTime vs MaxProcTime.
As you only posted snippets there is no way to tell what else your code has to juggle. :-)
PS: why does your wind-direction use the _60Hz noise rejection option?
You got mains power out there on your buoys?
Hi Nico:
Thanks for your thoughts. This is a real puzzler, even the Campbellsci techs seem to have no idea - I sent the question in to them and after a couple of back and forths they stopped replying and let the ticket time out.
Re: #1: The PulseCount instruction is high up in the main scan, it's a 1 Hz scan.
Re: #2: I do recording Maximum wind_speed, they were similarly crazily high and lined up with the gusts. I hadn't been recording a Maximum for gust though. Since I changed the PulseCount in February to change it from measuring counts to frequency the wind gusts have been realistic and have lined up well with a nearby NOAA tide station. I've been trying to figure out what caused those crazy high gusts in the hopes of salvaging the prior observations.
Re: #3: I do get some SkippedScans, I've been fooling with the buffers trying to reduce those. MeasureOps, MeasureTime, ProcessTime and MaxProcTime are all pretty high (163,21000,~250000, and 9000000 respectively). As well as the full met suite my buoys have compass, tilt/roll, GPS, current meter and wave sensor, so the CR1000 seems to be pretty busy. Not sure what I can do about that.
Re: PS: I didn't build the buoys, they came with a program that had that setting for BrHalf. I see that the example program in the 05103 manual also includes the _60Hz integration. I assume it is because the measurement range called out is 60Hz, not because of mains power. Do I have that wrong?
Cheers, Rob
That's a bummer with the support ticket, but dove tails with my experience if the problem is caused by something that eludes them, so you're not alone. ;-)
to 1)
the important bit is, that the PulseCount() command is sitting like this in the Scan/NextScan loop:
BeginProg
'bla bla
Scan (1,Sec,0,0)
'bla bla
PulseCount() ' count pulses from pulse sensor, no if's or but's
'bla bla
NextScan
EndProg
to 2)
well, that changes things a little, as this means the AvgRun() command is out of the picture as the culprit (just read its description about indexes and running within For/Next loops and you get an idea about the problems with it).
Do you keep records of your old versions of the code along with the data?
You might need to do a line by line comparison to find the culprit or get a hint.
(I use Notepadd++ under Windows for this - it's got a Plugin that lets me compare code side by side, higlighting the differences, etc.)
to 3)
depends on the logic of the code.. but usually non-time-critical parts that do not have to run on time are being put into SlowScans and can be scheduled by the firmware of the logger.
Then there would be looking for optimizations for loops or other things that do stuff that could be done more efficiently or can be dialed down to gain a couple of cycles that are better invested somewhere else.
to PS)
usually 250us integration (standard setting) is long enough to read a sensor and have a good average signal (there is a settling time before that even). The _60Hz option (see it's context) integrates over 16.67ms on purpose to remove noise caused by 60Hz mains power, but if you don't have such noise, you can measure faster (~67 times faster).
Depending on the mode your logger is in and how it's firmware handles this, you can essentially shave off ~16.4ms from that measurement alone.
If other similar measurements integrate similarly long.. well, it adds up.
Your main loop cycle time is 1 second. That's 1000 ms. 16.67 ms are 1.67% of that while 0.25ms are only 0.025%.
Skipped Scans are caused by things like this, where the main loop sometimes runs out of time to do its thing.. it tries to catch up in the next loop aso (thats' what the buffer setting is about) .. but that's not a given if your code is already 'close to the edge'.