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

  • From: Graeme Gill <graeme@xxxxxxxxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Wed, 04 Apr 2012 11:30:13 +1000

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: