mexHID value scaling may be dumb

[GoogleCodeExporter]

I may have done something silly with value calibration in mexHID.

What I'm seeing is with the 1208FS device from Measurement Computing.  A 
particular element corresponds to the report number of multiple reports that 
contain data from continuous analog input scans.  From other work and 
Psychtoolbox magic coding, I know that the report number occupies the last 2 
bytes of each report.  And yet the element only returns values in the range 
0-255.

Is this because mexHID always returns calibrated values?  Can I read the whole 
number by reading the element's integer value?  What is the element value's 
reported length?

Perhaps mexHID should optionally read element integer, calibrated, or physical 
values.  It would be easy to expose different APIs for each.  To read each from 
a queue would require recording a preference.  

Probably the preference should apply equally to polling or queued reads, on a 
per-element basis.  The preference could be stored in the elements-in-order 
dictionary, or a parallel dictionary.  It could default to calibrated (or 
integer?) and be set by a separate API.

Original issue reported on code.google.com by Benjamin.Heasly on 8 Sep 2010 at 3:53

[GoogleCodeExporter]

Original comment by Benjamin.Heasly on 23 Sep 2010 at 5:46

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

I did a little testing.  At least as far as the 1208FS device is concerned, the 
type of value read is not the problem.  Both scaled and integer values look the 
same, and the value's length is 1.

So this problem seems to be specific to the 1208FS and it's report descriptor.

It still might be nice to save preferred value type.  But since Matlab will be 
using doubles anyway, this is a low priority.

Original comment by Benjamin.Heasly on 23 Sep 2010 at 6:13

[GoogleCodeExporter]

I'm going to go ahead and not fix this bug.

Original comment by Benjamin.Heasly on 28 Oct 2011 at 2:18

• Changed state: WontFix