Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1279358

Re: [RFC 6/9] iio: ina2xx: add direct IO support for TI INA2xx Power Monitors

Show all headers | View raw

On 23/11/15 16:15, Marc Titinger wrote:
> On 21/11/2015 19:13, Jonathan Cameron wrote:
>> On 18/11/15 14:38, Marc Titinger wrote:
>>> Basic support or direct IO raw read, with averaging attribute.
>>> Values are RAW, INT_PLUS_MICRO (Volt/Ampere/Watt).
>>>
>>> Output of iio_info:
>>>
>>>       iio:device0: ina226
>>>        4 channels found:
>>>          power3:  (input)
>>>          1 channel-specific attributes found:
>>>                  attr 0: raw value: 1.150000
>>>          voltage0:  (input)
>>>          1 channel-specific attributes found:
>>>                  attr 0: raw value: 0.000003
>>>          voltage1:  (input)
>>>          1 channel-specific attributes found:
>>>                  attr 0: raw value: 4.277500
>>>          current2:  (input)
>>>          1 channel-specific attributes found:
>>>                  attr 0: raw value: 0.268000
>>>          4 device-specific attributes found:
>>>                  attr 0: sampling_frequency_available value: 61 120 236...
>>>                  attr 1: in_averaging_steps value: 4
>>>                  attr 2: in_calibscale value: 10000
>>>                  attr 3: in_sampling_frequency value: 1506
>>>
>>> Tested with ina226, on BeagleBoneBlack.
>>>
>>> Datasheet: http://www.ti.com/lit/gpn/ina226
>>>
>>> Signed-off-by: Marc Titinger <mtitinger@baylibre.com>
>> You have added some new ABI in here, but I'm not seeing any documentation
>> for averaging_steps.  Does this map onto the existing oversampling_ratio?
>>
> 
> I am not sure normal averaging maps well with oversampling. Normal
> averaging will provide one value every N samples (this is what this
> chip does), while oversampling will interpolate N value between
> sample 'k' and 'k-1', and decimate to provide a less-noisy version of
> sample 'k', the resulting sampling frequency is not lower.
> 
Oversampling is wonderfully badly defined as a term.  Often it is use precisely for the
method or noise reduction that is infact just an average.   Usually it implies:
1) Sampling at a higher rate than the eventual output will be provided at. This is the oversampling bit.
2) Sometimes adding carefully controlled noise - effectively dithering but ensuring the
noise is not at a frequency of interest so it can be removed later without effecting
what we are after - this allows obtaining a theoretically higher bit rate signal than
what you are measuring with - in extreme cases it allows the one bit adc trick - more
commonly it's just about reducing the noise as a result of the measurement process.
3) ADC conversion - post noise addition if we are deliberately adding some.
4) Applying digital filters as desired.
5) Finally outputing at the reduced data rate.

So - in the simplest form we actually have a straight forward average filter just like
the one your device is applying.  

Now you are correct that the data goes digital at a much higher rate than the output
rate in oversampling - however if we assume a chip is providing an oversampling function
inherently it must then be dropping it down to a more reasonable level in chip (rather than
leaving it to the CPU)  Hence if we have an iio chip with oversampling it's applying a
filter - whether that is a simple average filter, or something a touch more clever is the
only real question.

Now I've probably confused this discussion even more ;)

Jonathan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

[RFC 0/9] spawn hrtimer trigger from client driver upon enabling buffer Marc Titinger <mtitinger@baylibre.com> - 2015-11-18 15:40 +0100
  [RFC 1/9] configfs: Allow dynamic group creation Marc Titinger <mtitinger@baylibre.com> - 2015-11-18 15:40 +0100
  [RFC 7/9] iio: ina2xx: add triggered buffer Marc Titinger <mtitinger@baylibre.com> - 2015-11-18 15:50 +0100
  [RFC 2/9] iio: core: Introduce IIO configfs support Marc Titinger <mtitinger@baylibre.com> - 2015-11-18 15:50 +0100
  [RFC 8/9] iio: buffer: allow for last-second trigger spawning from device driver Marc Titinger <mtitinger@baylibre.com> - 2015-11-18 15:50 +0100
    Re: [RFC 8/9] iio: buffer: allow for last-second trigger spawning  from device driver Jonathan Cameron <jic23@kernel.org> - 2015-11-18 20:00 +0100
      Re: [RFC 8/9] iio: buffer: allow for last-second trigger spawning  from device driver Marc Titinger <mtitinger@baylibre.com> - 2015-11-19 10:20 +0100
        Re: [RFC 8/9] iio: buffer: allow for last-second trigger spawning  from device driver Jonathan Cameron <jic23@kernel.org> - 2015-11-21 19:20 +0100
  [RFC 3/9] iio: core: Introduce IIO software triggers Marc Titinger <mtitinger@baylibre.com> - 2015-11-18 15:50 +0100
  [RFC 6/9] iio: ina2xx: add direct IO support for TI INA2xx Power Monitors Marc Titinger <mtitinger@baylibre.com> - 2015-11-18 15:50 +0100
    Re: [RFC 6/9] iio: ina2xx: add direct IO support for TI INA2xx Power  Monitors Jonathan Cameron <jic23@kernel.org> - 2015-11-21 19:20 +0100
      Re: [RFC 6/9] iio: ina2xx: add direct IO support for TI INA2xx Power  Monitors Marc Titinger <mtitinger@baylibre.com> - 2015-11-23 17:20 +0100
        Re: [RFC 6/9] iio: ina2xx: add direct IO support for TI INA2xx Power  Monitors Jonathan Cameron <jic23@kernel.org> - 2015-11-29 16:20 +0100

csiph-web