From: Joshua Clayton <stillcompiling@gmail.com>
To: Jonathan Cameron <jic23@jic23.retrosnub.co.uk>,
Matt Ranostay <mranostay@gmail.com>
Cc: Jonathan Cameron <jic23@kernel.org>,
"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>
Subject: Re: iio channel sync
Date: Wed, 31 Aug 2016 15:47:18 -0700 [thread overview]
Message-ID: <aa577c0c-c18c-26d3-b5c6-16692e813d35@gmail.com> (raw)
In-Reply-To: <9706EDAC-1039-4D89-B5D8-CA327FA1E300@jic23.retrosnub.co.uk>
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.
next prev parent reply other threads:[~2016-08-31 22:47 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-29 17:03 iio channel sync Joshua Clayton
2016-08-30 7:41 ` Matt Ranostay
2016-08-30 16:26 ` Jonathan Cameron
2016-08-31 22:47 ` Joshua Clayton [this message]
2016-09-03 14:37 ` Jonathan Cameron
2016-09-03 20:52 ` Joshua Clayton
2016-09-04 14:22 ` Jonathan Cameron
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aa577c0c-c18c-26d3-b5c6-16692e813d35@gmail.com \
--to=stillcompiling@gmail.com \
--cc=jic23@jic23.retrosnub.co.uk \
--cc=jic23@kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=mranostay@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).