SteelSeries Gauges version 2.5.4

[mcrossley]

Actually, it looks like WINDROSE8$ is actually supplying 16 data points?

[WCDev]

Just 8 - here my current output:
Windrose 8: 0.0,0.0,0.0,0.0,0.0,13.9,25.6,0.0
(from http://live.trixology.com/custom/)

I'm guessing comma decimal point separator? Could you check the output on your system please Reinhard?

If it is this, I can fix it in the next build.

[mcrossley]

Just 8 - here my current output:
Windrose 8: 0.0,0.0,0.0,0.0,0.0,13.9,25.6,0.0
(from http://live.trixology.com/custom/)

I'm guessing comma decimal point separator? Could you check the output on your system please Reinhard?

If it is this, I can fix it in the next build.

Looking at Reinhard's realtimegaugesWC.txt it does seem to be using a comma for both the list separator and the decimal. Explains why the Windrose45 option produced such small sectors - it was being interpreted as 90 values.

[Blicj11]

Here is my data using WINDROSE8$: "WindRoseData":[0.0,0.0,0.0,2.0,0.0,0.9,53.2,42.6],

This is what is looks like with WINDROSE45$: "WindRoseData":[0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.8,1.1,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.1,0.1,0.2,0.1,0.7,1.5,3.5,6.7,16.3,18.9,15.5,12.5,10.7,7.4,2.4,0.0],

[wurzelmac]

I'm guessing comma decimal point separator? Could you check the output on your system please Reinhard?
If it is this, I can fix it in the next build.

I have been already asleep when you posted this, so my answer is a bit delayed. Here is the output of my 'WINDROSE8$' (today we have had zero wind till now):

Code: [Select]

"WindRoseData":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],

Looking at Reinhard's realtimegaugesWC.txt it does seem to be using a comma for both the list separator and the decimal. Explains why the Windrose45 option produced such small sectors - it was being interpreted as 90 values.

Thank you for looking at this. You are right, Mark, in the German version of WeatherCat we use a decimal comma, not a decimal point. Therefore 'WINDROSE8$' shows 16 values, and 'WINDROSE45$' showed 90 values.

Stu,
would be great if you can fix this one. Is it possible to have only this output in decimal points and leave all others (statistics, graphs, etc.) with a decimal comma?

Cheers,
Reinhard

[wurzelmac]

Another thought, Stu:

I don't know how much effort it will take but have you thought about about using an integer for this one - then there will be no decimal sign needed?

Cheers,
Reinhard

[Blicj11]

Mark:

I have two more questions.

• What is the red band on the Solar Radiation gauge displaying? I know it is a range, but what range is it? I have looked at the tags but still can't figure out what time period and what variable this is.
• In case you missed this, please take a look at http://athena.trixology.com/index.php?topic=1585.msg13417#msg13417

Thanks for your patience.

[wurzelmac]

To get readable data for the processed realtimegaugesWC.txt file I went to System Preferences, and turned on a '.' instead of ',' as decimal separator. Now the output is readable for the windrose gauge:

Code: [Select]

"WindRoseData":[0.5,1.4,0.1,4.7,4.3,1.0,0.5,0.5],
All other data logically are processed now with '.' instead of ',' (Stats, NOAA, ...).

Cheers,
Reinhard

[mcrossley]

The lower limit of the red band on the solar gauge indicates the calculated solar max value, so if you stray into the band you are reading > 100% of theoretical. Nothing wrong with that, there are valid reasons for why it happens, primarily reflections.

Sorry, I have no idea about your editing issues other than the browser is caching stuff. I might say 'use a decent browser!'  - I'm a fan of Chrome, primarily because I like the debugging and dev tools in it.

[Randall75]

Hi Reinhard
 Did you do that in the Language and Region of the System Preferences?


cheers

[wurzelmac]

Hi Randall,

yes!

Cheers,
Reinhard

[Blicj11]

The lower limit of the red band on the solar gauge indicates the calculated solar max value, so if you stray into the band you are reading > 100% of theoretical. Nothing wrong with that, there are valid reasons for why it happens, primarily reflections.

Sorry, I have no idea about your editing issues other than the browser is caching stuff. I might say 'use a decent browser!'  - I'm a fan of Chrome, primarily because I like the debugging and dev tools in it.

Thanks Mark. I have been experimenting with the threshold values and the "sunlight" LED. I think I have it working pretty well for clear winter days but I wonder if I will have to raise the values during the summer. Also need to see what a really cloudy day does to my current lower threshold values.

I appreciate your teaching us about this great piece of software. I intend to take some time and and incorporate this into the WeatherCat version of the SteelSeries Wiki so you don't have to keep repeating yourself.

Your comment about using a decent browser gave me good laugh. I used to use other browsers, but I really appreciate the ability Yosemite and iOS 8 give me to pull up, open and close Safari browser tabs across devices.

[mcrossley]

Your comment about using a decent browser gave me good laugh. I used to use other browsers, but I really appreciate the ability Yosemite and iOS 8 give me to pull up, open and close Safari browser tabs across devices.

Chrome does that too 

[Blicj11]

Here is something odd. Look at the screenshot of my Apparent Temp gauge. The digital display is correct but the auto scale is crazy. It probably wouldn't have happened in Chrome. 

[mcrossley]

Well, you're right, it doesn't display like that in Chrome 

Best thing to do if this sort of thing happens is to capture a copy of the realtimegaugesWC.txt file - there is probably something in there causing it - it looks like the problem has cleared now?