joystick12 - different calibration formulas

[jontrulson]

The X and Y axis use different calibration formulas... Why? The original driver never supported calibration, and it's a good addition, but I am curious as to why the X/Y axes would need different formulas.

[pylbert]

Made calibration formulas the same.

[jontrulson]

Ok, so your changes reminded me of something I should have mentioned in the "general" email I sent out. Why the extra analog reads? In many of the drivers, I saw read analog functions that would always do 2 reads, throwing out the first one, with a comment like

// First read is "weird", throw it out

I removed them all as I converted the drivers because this is wrong...

ADC reads are already slow enough without doubling the time to get a single value. If all analog devices return weird values on the first read, then only two solutions should be employed:

• Fix the underlying problem in MRAA (preferred). Or,
• if you MUST deal with it in UPM, just do a single throw-away read in the init() function after initializing the aio context.

Reading two values for every one you actually want is just a bad idea and just points to a deeper problem that should be fixed there. Can we just not do that?

[pylbert]

I agree, a fix for adc on edison should be handled in mraa or in the adc driver which provides access via /sys/bus/iio/devices/iio:device1/in_voltage0d_raw since this also exhibits the same artifact.

Which would you prefer, an incorrect fast read, or a slower correct read?

Because I'm encountering this stuff for the first time, I'm addressing it now. I see this on all analog sensors. How have you dealt with this in the past? Ignored it?

A possible solution would be to have mraa mask this problem (two b2b reads?). Perhaps it's something that only happens on edison?

A throw-away read in the init function is not enough to fix this since it re-appears in 30 seconds or so on the edisons I've tested.

[jontrulson]

On 07/27/2016 12:54 PM, Noel Eck wrote:

I agree, a fix for adc on edison should be handled in mraa or in the
adc driver which provides access via
/sys/bus/iio/devices/iio:device1/in_voltage0d_raw since this also
exhibits the same artifact.

So... even sysfs reads show this artifact? That implies a problem in
the ADC kernel driver. Have you tried a scope? Is there a voltage
change when this happens or is it purely an artifact of the kernel
driver? I am also assuming you are not destroying and re-creating the
aio context during this time?

Which would you prefer, an incorrect fast read, or a slower correct read?

Neither, they both suck. In the case of a joystick it won't actually
matter since one typically does many reads very fast with one of those.

But we need to characterize this problem in more detail if we want it fixed.

Just stick with single reads please - this may in fact be an edison-only
bug (there have been many others).

Because I'm encountering this stuff for the first time, I'm addressing
it now. I see this on all analog sensors. How have you dealt with this
in the past? Ignored it?

I've never actually seen the problem. But then I usually do not create
an aio context, use it for awhile, wait 30-60 seconds and try using it
again and see what you are seeing. I've also never seen this problem
reported.

Many of the analog sensors are "noisy" - they vary from sample to sample

• that's completely normal. Some are noisy enough that we do multiple
  reads of the ADC value (or computed voltage) and average over them.
  That is also SOP.

I'm guessing this is something else...?

A possible solution would be to have mraa mask this problem (two b2b
reads?). Perhaps it's something that only happens on edison?

Probably only happens on edison would be my guess. G2 and edison act
differently WRT ADC - I have several oddities noted in the Sensor
Problems document on our GDrive relating to analog, i2c, SPI, etc, and
differences between the two.

I have drivers that work fine on one, and not the other. We can't do
anything about that except document it.

I would write the driver assuming that the ADC value read is always
correct. What else, realistically can you do? You have to count on
your kernel and kernel drivers to be correct.

If it is not giving you correct data, then it's a problem that MUST be
solved elsewhere.

Keep in mind this stuff needs to work on a lot of different platforms
(RPi, MCU's, minnowboard, etc.) It's quite possible this is an edison
only problem, and on other platforms it will work fine.

Having MRAA do two reads is just moving the "broken" fix, and
performance will still suffer.

If your kernel drivers are malfunctioning, then all bets are off - it's
not a problem you should even try to solve. Characterize it as best you
can and send out an email to those who can do something about it.

A throw-away read in the init function is not enough to fix this since
it re-appears in 30 seconds or so on the edisons I've tested.

If you can characterize the problem in detail, then send it up the chain
of command to get it fixed. I did this with edison SPI - sent logic
traces, examples, and long-winded explainations. Sometimes that's all
you can do and hope it will eventually get fixed, which it eventually did :)