Re: Oddities and how to handle them.

[Guenter Roeck <guenter.roeck@ericsson.com>]

On Thu, Apr 28, 2011 at 10:21:38AM -0400, Jonathan Cameron wrote:
> On 04/28/11 14:51, Jean Delvare wrote:
> > On Thu, 28 Apr 2011 10:31:15 +0100, Jonathan Cameron wrote:
> >> Guenter / Jean - cc'd you two because we have an sysfs interface naming question for
> >> AC sensors that touches on the edge of hwmon.
> >>
> >>> For the metering parts I think we need to define a few more channel types.
> >>>
> >>> How about this ones
> >>>
> >>> inSX            S is the apparent power.
> >>> inPX            P is the active power.
> >>> inQX            Q is the reactive power.
> >>> inVX            V is the voltage. (only inX ?)
> >>> inVRMSX VRMS is the quadratic mean voltage.
> >> Call it 'root mean square' rather than quadratic in the docs. They have different
> >> meanings in English.
> >>> inIX            I is the current.
> >> currX as per hwmon?  They also define a power attribute, but only 1 (as DC
> >> I guess). Cc'd Guenter and Jean to see if we can / want to share an interface...
> >>
> >> Guenter/ Jean, do you think hwmon will ever handle AC sensors?
> > 
> > Well, never say never ;) While I've never heard of such sensors, I
> > guess it would make some sense for a computer PSU to include a sensor
> > chip monitoring both the AC input and the DC output to measure the
> > efficiency of the unit.
> > 
> >> Maybe we want to be
> >> well clear of your interfaces just to avoid confusion? Or define a new set of shared
> >> names for the above that we will both use (when it becomes relevant?)
> > 
> > It's hard to tell in advance what hwmon would implement, as we lack
> > actual examples. All I can say is that we would never use "in" prefixes
> > for power or current. The above power examples would most probably be
> > named powerX_apparent_input, powerX_active_input and
> > powerX_reactive_input, if we ever have to support these. And
> > inX_rms_input for the root mean square voltage input.
> > 
> > But then again, I'm not sure if there is any point in sharing anything,
> > or forcing any difference, between hwmon and iio interfaces. They are
> > different by nature, and if we don't strictly enforce their relation,
> > they are bound to randomly diverge and converge anyway.
> > 
> Agreed to a certain extent, but saying that there is no point in reinventing
> the wheel.  I think the naming you've just suggested is clearer anyway.
> 
> Ultimately I don't insist on keeping to your interfaces when it really doesn't
> make sense, but when it does, it makes our life easier as we aren't starting from
> scratch. Also, politically it was suggested we do this by a few people I'd like
> to keep on side.
> 
> Michael - howabout doing the rms values as done with peak_raw - as chan info parameters
> (directly derived from raw values anyway).
> 
> Then define two new (to us) channel types.
> 
> IIO_CURRENT = "curr%d"
> IIO_POWER = "curr%d"
> 
power%d, presumably.

> Using the rfc I'm going to post after I send this email, we can add additional names to a channel.
> The only slight annoyance is the 3 power values will need to be different channels, so under that
> we will have:
> 
> power0_apparent_raw           is the apparent power.
> power1_active_raw             is the active power.
> power2_reactive_raw           is the reactive power.
> in0                           is the voltage.
> in0_rms_raw                   is the rms voltage.
> curr0_raw                     is the current.
> 
Note that in hwmon, all input sensors have _input at the end, as in Jean's example.
What does the _raw stand for ?

Guenter