iio channel sync

iio channel sync

[Joshua Clayton]

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.

Joshua Clayton

Re: iio channel sync

[Matt Ranostay]

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?

>
> Joshua Clayton
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: iio channel sync

[Jonathan Cameron]

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)


>
>>
>> Joshua Clayton
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-iio"
>in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: iio channel sync

[Joshua Clayton]

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, but
the encoders are also used as positional data alongside the sensor data.

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.

Re: iio channel sync

[Jonathan Cameron]

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.

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
> 

Re: iio channel sync

[Joshua Clayton]

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.

Joshua

Re: iio channel sync

[Jonathan Cameron]

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
>