Custom Gauge Intervals

[bobr]

Although  I may have posted this before I don't see it.  Therefore, please, please, please prohibit the labeled intervals on the custom gauges from any but multiples of 2,4,5 or 10.  Intervals that are multiples of 3 or 7 are atrocious and all but un-readable!

[Felix]

I didn't realize the custom gauge refresh interval was user adjustable. How do you do that?

I've noticed that the displays on my custom gauges lag behind the readout on the WeatherCat window (and Data Viewer/Editor) but I always assumed it was because I run the software on an older Mac mini which is a little short on horsepower to record three cameras and run WeatherCat with several custom gauges and synthetic channels plus the FTP demands. OTOH, if the interval is indeed adjustable, I'd like to see if that might solve my problem...maybe it's not the mini after all.

Your post was timely because I was just recently thinking I should try the setup on one of my faster Macs just to see how much (if any) of a difference it made.

[Bull Winkus]

I think he's talking about the gauge scale interval when the gauge autoscales. You can manually set the range to achieve round number major divisions, and when that is exceeded, the software will extend the range to bracket the current measurement. Of course when that happens, those round number major divisions can become odd. I deal with the issue he raises by maintaining manually set ranges on all my gauges.

As far as I know, there is no adjustment to the sample interval. If you're running the lowest power Mini, and using all the features of WeatherCat you mentioned, it is quite likely you'll see some lag between different presentations of the same data.



 

[Felix]

Thanks, Herb. Now that I reread the original post, I'm sure you're correct.

[WCDev]

Correct

It isn't always possible to meet all the requirements for the scale, so if auto-scalling you'll likely end up with odd numbered divisions - set manual upper and lowers to suit your particular range for that data type. Indeed sometimes it isn't possible to come up with a scale at all - in this case it'll be immediately apparent the scaling algorithm has failed with either no scale at all or hundreds of divisions being displayed.

WRT the update rate, it is dynamic based on the type of the data being displayed (a gauge displaying wind direction will set a much higher update rate than a gauge displaying temperature for example), the OS you are running on and the hardware - we found in development it was very easy to end up with cooling fans getting very loud, so what we have now takes the above into account to keep the load down.

[Bull Winkus]

Thanks Stu!

One way you might go to solve the auto-scaling issue is, instead of merely extending one end of the range, move the range at both ends. Eg. 0-100 becomes 10-110, etc? Then the major divisions will still be consistent with that set by the station operator.
 

[Felix]

WRT the update rate, it is dynamic based on the type of the data being displayed (a gauge displaying wind direction will set a much higher update rate than a gauge displaying temperature for example), the OS you are running on and the hardware - we found in development it was very easy to end up with cooling fans getting very loud, so what we have now takes the above into account to keep the load down.

Apparently a pretty good delay built in to the custom gauge temperature display. I just now happened to have my Weather Underground web page open (Rapid Fire Mode enabled) as well as the on-screen custom gauges (one of which is external temperature, plus High & Low pointers). As luck would have it, my WU page registered a 1/10 degree temp change. So then I focused my attention on the custom gauge and it took an estimated three to four more seconds to change. So the update rate is indeed fairly slow on that particular parameter if WU already had the change posted before the custom gauge registered the change. But as you noted, Stu, temps usually don't change very rapidly so it makes sense to prioritize processing.