Testing and Cause of Failure for Encoders and Hall Effect sensors

[eugenebrooks]

Originally Posted by ChrisH

The problem with pots was that they only give 255 "clicks" and we needed 540 to get the resolution we wanted.


I'll have to look more closely into just what was happening at failure. We spent a lot of time getting smacked while we were minding our own business stacking tetras. While we are reasonably sure there was not direct contact with the sensor, we haven't evaluated the possibility of shock inducted counts at a high rate.

The resolution, on the old PBASIC RC was 255. The resolution on the
new RC programmed in C is 1024 (only on the RC, not the OI), but I will
agree that your desired resolution is too close to the limit for comfort.

If you are using busy polling in the "fast loop" to detect state transitions,
you can be missing changes that happen while the RC is not looking.
This happens while the RC is busy with its periodic processing of inputs
and outputs, between the calls to get and put a packet.

One of the things that we do here is track the minimum number
of consecutive on, and off, measurements and report that as
a diagnostic to indicate the risk that we might have missed any.
You can indicate that the minimum has been violated with an
LED output, and print the number when the computer console is
being used. We start to get worried if the minimum number
gets lower than 5 or so.

Another strategy is to use an interrupt scheme to track the encoder,
but this method has plenty of its own potential gremlins. You have
to be very careful to avoid all the pitfalls, but an interrupt based
scheme is capable of tracking state transitions at a much higher rate
because only higher priority interrupts will interfere with it.