Re: W83627DHG-P sensor shows a single voltage monitor for +5V and +12V on in4?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> On Wednesday, February 19, 2014 2:16 PM, Guenter Roeck <linux@xxxxxxxxxxxx> wrote:
>
> Actually, they do. Register values are 0xcf for both (bank 0,
> registers 0x23 and 0x24).
>

Oh, you meant the raw dump physical value (0xCF). I was pertaining to the values reported back by sensors, which was an incorrect understanding on my part.

>> +3.3V:
>>     in3_input: 3.296
>>     in3_min: 2.976
>>     in3_max: 3.632
>>     in3_alarm: 0.000
>
> If we assume that hwmonitor is correct, this needs
> to scale up 50%, which would make the value
> 3.296 * 1.5 = 4.944V.
>
> The raw value reported by the driver in the hwmonitor dump
> is 0xcf = 207, which is multiplied by the driver with 16,
> resulting in 3.312V as originally seen, or scaled to 4.968V,
> which is exactly the value that was reported by hwmonitor.
>
> So your compute statement would be something like
>
> compute  in3  @*(15/10), @/(15/10)
>
>> in4:
>>     in4_input: 1.656
>>     in4_min: 1.632
>>     in4_max: 1.800
>>     in4_alarm: 0.000
>>     in5_input: 1.688
>>     in5_min: 0.088
>>     in5_max: 0.344
>>     in5_alarm: 1.000
>
> The raw value reported by the driver is 0xcf = 207.
> This is multiplied by the driver with 8, resulting
> in a reported voltage of 1.656V. A scaling factor
> of 7 (as you have) gets you to 11.592V, which
> matches the voltage reported by hwmonitor quite closely.
>
> compute in4 @*7, @/7
>
> might be a bit simpler, though.
>
> Hope this helps,
>
> Guenter
>

You sir have been very helpful, and I must admit that this is both the case of PEBKAC and PDL, but how could you blame me, an ordinary end user, for having only so limited an undesrtanding and resource at my disposal? ;-)

Committing your compute statements into my configuration:

$ sensors
Vcore:        +1.11 V  (min =  +1.07 V, max =  +1.18 V)
+3.3V:         +3.30 V  (min =  +2.98 V, max =  +3.63 V)
+5V:          +4.94 V  (min =  +2.98 V, max =  +3.62 V)  ALARM
+12V:        +11.59 V  (min = +11.42 V, max = +12.60 V)
Vram:         +1.90 V  (min =  +1.80 V, max =  +1.90 V)
3Vsb:         +3.50 V  (min =  +2.98 V, max =  +3.63 V)
Vbat:         +3.34 V  (min =  +2.70 V, max =  +3.30 V)  ALARM
CHA Fan:        0 RPM  (min =    0 RPM, div = 128)
CPU Fan:     2191 RPM  (min =  902 RPM, div = 8)
PSU Fan:        0 RPM  (min =    0 RPM, div = 128)
N/B Temp:     +43.0°C  (high = +60.0°C, hyst = +55.0°C)  sensor = thermistor
CPU Temp:     +40.0°C  (high = +60.0°C, hyst = +55.0°C)  sensor = thermistor
intrusion0:  ALARM

I will contribute my configuration into the http://lm-sensors.org/wiki/Configurations page for this board so that others may benefit as well.

There are still some observations I'd like to ask you about:

1. While +5V is now scaled from in3, if you will take notice the min and max values do not reflect the ones I have set in my configuration:

   set in3_min 5 * 0.95
   set in3_max 5 * 1.05

I do not believe that this is an expected behavior, so perhaps a bug then?

2. I have relied upon http://www.lm-sensors.org/wiki/VoltageLabelsAndScaling for scaling +5V and +12V values. But the way you derived the scaling factors from your explanation above, which I believe is much easier and faster than the one in the wiki that works on samples, does not seem to be covered there. How does one go about figuring out scaling factors like the way you did?

3. Regarding 3VSB, if this is the standby voltage, then shouldn't it be +5VSB? I don't think PSUs provide +3VSB, only +5VSB. So does this mean that the value needs to be scaled as well?

4. Same with VBAT, as I recall motherboard internal batteries are rated at +3V CR2032 coin-cell batteries.


_______________________________________________
lm-sensors mailing list
lm-sensors@xxxxxxxxxxxxxx
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors





[Index of Archives]     [Linux Kernel]     [Linux Hardware Monitoring]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux