[argyllcms] Re: i1 [EyeOne] USB Command Set

  • From: "Bill Davy" <Bill@xxxxxxxxxxxxxxx>
  • To: <argyllcms@xxxxxxxxxxxxx>
  • Date: Wed, 4 Apr 2012 09:00:48 +0100

Many thanks for your prompt and full reply.

Most is as I feared.  I have been told that taking single readings is a
slowish process so doing that repeatedly while scanning the i1 is not going
to produce good results.

Please do not think I was in anyway criticising your code.  I did not want
to lift your functions but was trying to understand how it did the business
with the i1.  Unless I can get the robot to do just what I want to do I
suspect it is too onerous given my timescale.

You suggest I1_TriggerCountedScan() will take a number of samples (...)
samples to take.  But what is the argument type likely to be?  There seems
to be a taste for using a char* string which seems a bit arcane but is
flexible and universal (well, almost, as we seem to ignore
MBC/UTF/Unicode/wchar issues).  I tried DependencyChecker to see if it
reveals the argument list which for some reason I thought was embedded
(albeit "decorated"), but it did not.

I guess I shall just have to try and see how it crashes!  There is an
internal function _sipSetNumPeriodsToMeasure() which I think takes a 4 byte
integer (if I undecorated it correctly).

Still, we have at last had some rain, and just after I planted my peas and
broad bean seeds so perhaps the gods are smiling on me and this is a
propitious time.

Many thanks.

Bill Davy

-----Original Message-----
From: argyllcms-bounce@xxxxxxxxxxxxx [mailto:argyllcms-bounce@xxxxxxxxxxxxx]
On Behalf Of Graeme Gill
Sent: Wednesday, 04 April 2012 02:30
To: argyllcms@xxxxxxxxxxxxx
Subject: [argyllcms] Re: i1 [EyeOne] USB Command Set

Bill Davy wrote:
> I have been asked to take a set of readings while an EyeOne is scanned 
> mechanically over a test strip.  However, the EyeOne will not be
accessible during the scan (just at the start).

Hi,

> The SDK only describes I1_TriggerMeasurement() which requires the 
> button to be held for the duration of the measurement (not good for me).

As I understand it (and I'm a little rusty - I haven't looked at the low
level i1pro stuff for a while), there are two modes: "spot" and "scan" mode.

In spot mode it will do a given number of measurements on command from the
computer. In scan mode, it will (I think) do the given number of readings
and then continue to do readings as long as the switch is held down. (It
will stop if the software isn't keeping up with transferring the raw reading
values though.) In software, the scan mode implies parsing the reading into
individual patches too, rather than combining the readings into a single
value.

So if you are scanning mechanically over a test strip and have a know scan
time, it sounds possible to use the spot mode, but with the patch parsing
done on the result.

> I have had a look at Argyll (i1pro_imp.c) but that seems to do low 
> level USB calls (using magic
> numbers):
> 
> se = p->icom->usb_control_th(p->icom, USB_ENDPOINT_OUT | 
> USB_TYPE_VENDOR | USB_RECIP_DEVICE, 0xC0, 0, 0, NULL, 0, 2.0, 0, NULL, 
> 0);

Well, there are many higher level routines, but they are very much geared
around implementing a set of measurement modes that correspond with "normal"
use.

To implement what you're after would entail creating another mode that
matches your situation.

> Does anyone know where the USB command definition lives?  I'm very 
> used to driving USB devices at a low level (I am usually writing the
target code).

I'm sure they exist somewhere in the files of the X-Rite/Gretag software and
hardware design documents in Switzerland, but I'd be a bit surprised if you
could get your hands on them, short of an NDA and a multi-million dollar
contract to buy lots of instruments!

Of course there is an incomplete set in my notes on the instrument
interface, and it is implicitly in the driver code I've written.

I wouldn't recommend trying to write a driver from the USB level unless you
have a lot of time though, since there are many details involving
calibration that needs to be taken care of.

> The EyeOne DLL has some interesting looking functions, such as 
> I1_TriggerCountedScan() but it is not documented.

Yes, that sounds like what you want. I suspect it has one parameter, which
is the number of 8.84 msec (Rev A) or 4.716 (rev D) msec samples to take.

> Can anyone suggest who I should contact to get some good technical
answers?

I'm afraid that only us reverse engineers hang around this list! :-)

While figuring out how the instrument works from observing it in action can
reveal some things that aren't documented by the manufacturer in an SDK, and
allow software to be created that operates the instrument with different
parameters and in different combinations, it's difficult to discover
anything that the manufacturers drivers don't actually exercise. There could
well be more features in the instrument firmware, but it is difficult to
discover these features short of tearing it apart and analysing it (assuming
it's even possible without an electron microscope!), or trying a lot of
tests looking for un-documented commands and/or parameter value effects (and
hoping you don't brick the instrument in the process).

Graeme Gill.



Other related posts: