Re: iio channel sync

[Jonathan Cameron <jic23@kernel.org>]

On 03/09/16 21:52, Joshua Clayton wrote:
> On Saturday, September 03, 2016 03:37:50 PM Jonathan Cameron wrote:
>> On 31/08/16 23:47, Joshua Clayton wrote:
>>> Greetings,
>>>
>>> On 08/30/2016 09:26 AM, Jonathan Cameron wrote:
>>>>
>>>> On 30 August 2016 08:41:18 BST, Matt Ranostay <mranostay@gmail.com> wrote:
>>>>> On Mon, Aug 29, 2016 at 10:03 AM, Joshua Clayton
>>>>> <stillcompiling@gmail.com> wrote:
>>>>>> Jonathan,
>>>>>>
>>>>>> I have an out-of tree driver I am working on mainlining.
>>>>>>
>>>>>> The device is a sensor that gets phase and amplitude (x and y) data
>>>>>>
>>>>>> on multiple physical and/or time multiplexed channels.
>>>>>>
>>>>>> It also has up to 4 optical encoders to get physical location.
>>>>>>
>>>>>> The existing driver bundles x and y together with a snapshot
>>>>>>
>>>>>> of the encoder sums at that moment.
>>>>>>
>>>>>>
>>>>>> This seems like a good fit for iio, but one item is bothering me.
>>>>>>
>>>>>> How is synchronization between streams usually handled with
>>>>>>
>>>>>> iio drivers? Timing can be important.
>>>>> Wouldn't the trigger buffer framework be good enough for this?
>>>> Perhaps you could describe your usecase a little more?
>>>>
>>>> Is the interesting bit that you want to sync streams with different
>>>> sampling frequencies? Are those encoders better represented by a
>>>> separate driver? (In which case I have some thoughts on simple
>>>> additions to IIO trigger handling that might help - basically a
>>>> hold off on triggers until all relevant devices are attached)
>>
>>> Thanks for responding.
>>>
>>> The encoders (often a pair of them, could be up to 4) represent the position
>>> of the sensor in relation to an object to be tested. (linear movement or
>>> rotation around an axis).
>>> The Maximum sample rate of the encoders is much higher than the sensor,
>>> but they are moved by a motor or by hand, so the actual sample rate is
>>> variable and may be higher or lower that the sensor sample rate.
>>>
>>> The encoders are sometimes used as a trigger for data collection,
>> It would certainly be possible to do this by having a slightly unusual type
>> of trigger.
>>> but
>>> the encoders are also used as positional data alongside the sensor data.
>> Makes sense.
>>>
>>> The way we get around this now is to bundle a snapshot of the encoder
>>> with the sensor data and discard it later if the encoder hasn't changed and
>>> the trigger function is enabled.
>> The only slight change I'd suggest is that if the encoders are read by
>> separate hardware (presumably they are into a capture unit of some type?)
>> then you may need to have the encoder capture triggered off the same
>> trigger as the sensor data.  Thus you'd end up with two buffers that
>> could be easily fused in user space.
>>
>> That would allow  generic drivers for other users of either the sensor
>> or the encoder capture hardware.
>>
>> If they come in through the same bit of hardware (e.g. you are routing
>> them both through an fpga or similar) then fine as you have it currently.
>>
> 
> Thanks for responding to my questions. It is always hard to visualise how
> something that already exists might be re-architected, and you've given me
> enough to get my mind working on it.
>  
>> Sounds like an interesting bit of hardware ;) Some sort of radio test kit
>> around an antenna? (feel free to not answer, I'm always curious)
>>
>> Jonathan
>>>
> Haha. Yeah, its a bit of a tightrope walk trying to upstream code while
> keeping the "secret sauce" safe.
> 
> I thinks its ok to tell you it is eddy current testing equipment, used in
> non-destructive testing of metal items.
> 
> We set up a standing wave using a high speed A/C current in a coil,
> and measure distortion in the amplitude and phase of secondary
> A/C currents induced in another coil.
> 
> It can be used to find defects near the surface, such as hairline cracks,
> as well as to indirectly measure thickness and conductivity that might
> indicate metal fatigue.
> 
> Google "eddy current" if you are still curious.
> 
Cool, you learn something new every day ;).  Thanks for the info.
Looking forward to seeing the code ;)

Jonathan
> Joshua
>