lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABnWg9spateMzOnAGL42GmSbnhL5vwsMpwBm+rGVe4DAdyj6=A@mail.gmail.com>
Date: Mon, 9 Dec 2024 07:41:01 -0800
From: Guillaume Ranquet <granquet@...libre.com>
To: David Lechner <dlechner@...libre.com>, Lars-Peter Clausen <lars@...afoo.de>, 
	Michael Hennerich <Michael.Hennerich@...log.com>, Jonathan Cameron <jic23@...nel.org>
Cc: linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC] iio: adc: ad7173: add openwire detection support for
 single conversions

On Mon, 18 Nov 2024 21:48, David Lechner <dlechner@...libre.com> wrote:
>On 11/15/24 4:34 AM, Guillaume Ranquet wrote:
>> Some chips of the ad7173 family supports open wire detection.
>>
>> Generate a threshold event whenever an external source is disconnected
>> from the system input on single conversions.
>>
>> Signed-off-by: Guillaume Ranquet <granquet@...libre.com>
>> ---
>> Hi.
>>
>> This patch adds the openwire detection support for the ad4111 chip.
>>
>> The openwire detection is done in software and relies on comparing the
>> results of two conversions on different channels.
>>
>> As presented here, the code sends a THRESH Rising event tied to the
>> in_voltageX_raw channel on which it happened.
>>
>> We think this is not correct but we can't seem to find an implementation
>> that would be elegant.
>>
>> The main idea would be to add a specific channel for openwire detection
>> but we still would need to have the openwire enablement and threshold
>> tied to the voltage channel.
>>
>> Any thought on this?
>>
>Just to spell this out in a bit more detail, my understanding is that
>the procedure works like this...
>
>To detect an open wire on a single-ended input, we measure the voltage
>on pin VIN0 using channel register 15, the we read the voltage on the
>same pin again using channel register 0. The datasheet isn't clear on
>the details, but on one or the other or both of these, the ADC chip is
>applying some kind of pull up or pull down on the input pin so that
>each measurement will be nearly the same if there is a wire attached
>with a 0-10V signal on it. Or if the wire is detached and the pins are
>left floating, the two measurements will be different (> 300 mV).
>
>So this threshold value (the 300 mV) is measured in terms of the
>difference between two voltage measurements, but of the same input pin.
>
>My suggestion is to create extra differential channels like
>in_voltage0-involtage100_* where 100 is an arbitrary number. These
>channels would be defined as the difference between the two measurements
>on the same pin. The event attributes would use these channels since they
>are triggered by exceeding the threshold value according to this difference
>measurement.
>
>To complicate matters, these chips can also be configured so that two
>input pins can be configured as a fully differential pair. And we can
>also do open wire detection on these differential pairs. In this case
>we would configure input pins VIN0 and VIN1 as a differential pair, then
>read the difference of those two pins using channel register 1, then
>read again using channel register 2. The we see if the difference of the
>two differences exceeds the threshold.
>
>In this case, we can't have in_(voltage0-voltage1)-(voltage100-voltage101)_*
>attributes. So I guess we would have to do something like
>in_voltage200-voltage300 to handle this case? (voltage200 would represent
>the first measurement of voltage0-voltage1 and voltage300 would represent
>the 2nd measurement of the same).

Hi Jonathan,

I was wondering if you had any opinions on this RFC?

Thx,
Guillaume.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ