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.