Re: Oddities and how to handle them.

[Michael Hennerich <michael.hennerich@analog.com>]

On 04/28/2011 11:31 AM, 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.
>
>   
>>>>>>> Hi Michael,
>>>>>>>
>>>>>>> ade7758 - Complex driver I'm not that keen on touching without a lot
>>>>>>> of testing support. Don't suppose you want to take this one Michael?
>>>>>>> (*looks hopeful*) At lease blugeoning it into more or less current
>>>>>>> interfaces would be a great help. I can do it, but then I suspect
>>>>>>> I'll break it in a few exciting ways :(
>>>>>>>
>>>>>>>               
>>>>>> I can fix building on this one. However I currently don't have
>>>>>> enough time to fix and document the API.
>>>>>>             
>>>>> That's fine.  We won't be pushing any of the energy meter drivers out
>>>>> of staging for a while yet anyway!
>>>>>           
>>>>>> The buffer scan attribute naming is a bit complicated on this one.
>>>>>> Do you think we can stick with wform?
>>>>>> There is some interaction with the WAVEFORM MODE Register. Ideally
>>>>>> we have enable files for all possible waveform selection
>>>>>> possibilities, which are numerous, 3 sources (phases)  * 5
>>>>>> measurement options (Current, Voltage, Active Power, Reactive
>>>>>> Power and VA). Only one combination can be enabled at a given
>>>>>> time, since they are exclusive
>>>>>>             
>>>>> or.
>>>>>           
>> Hi Jonathan,
>>
>> 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...
>   
Honestly I don't like 'curr' - In my opinion we should use SI until
symbols (as well as standardized derived SI units where applicable).
In this particular case current is a SI unit.
For everything further we should use symbols commonly used in
Anglo-American EE and Physics literature. (NIST, IEEE, ...)
 
> Guenter/ Jean, do you think hwmon will ever handle AC sensors? 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?)
>   
>> inIRMSX IRMS is the quadratic mean current.
>>
>> Since they won't be really popular
>>
>> How about using a string in iio_chan_type_name_spec
>>
>>         [IIO_IN_GENERIC] = "in%s",
>>     
> Firstly, perhaps, IIO_IN_MOD will correspond better with naming?
>   
> Been thinking about exactly this question for the light sensors...
> Initially strings seemed like the obvious thing to do, but then I thought
> some more.  For all of these we will need to have matching event codes.
> The easiest there would be to do them as IIO_EV_MOD_POWER_APPARENT etc.
> Once we have those defines, we might as well roll the names into the core
> as a string table referenced by value stored in channel2.
> Actually, arguably we shouldn't be doing the same for 'x','y','z' as well
> for consistency. Right now we allow for directions without corresponding event
> codes. That way lies doom!
>
> I know there aren't likely to be hundreds of these devices any time soon,
> but we don't really want to set a precedence for allowing free naming.
> That was part of the justification for moving to chan_spec in the first
> place!
>
> Jonathan
>
>   


-- 
Greetings,
Michael

--
Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Sitz der Gesellschaft: Muenchen; Registergericht: Muenchen HRB 40368;
Geschaeftsfuehrer:Dr.Carsten Suckrow, Thomas Wessel, William A. Martin,
Margaret Seif