[HDTV-Freak II]

I´m in trouble getting my Spider4 not detected by the hcfr software

It works

what was my trouble?


CMD

I followed now the more clearer steps down to the folder

C:

cd program files (x86)

cd HCFR Calibration

cd Tools

make a dir to check if you are in the right folder!

execute just typing the following!
spyd4en.exe –v -S u

(here it was important that there are blanks after the .exe and each other...... .exe_-v_S_-u)


Here I could clearly see that my PC is writing something into the machine

following steps:

- rebooting

- deinstalled Datacolor, Spyder 4

- pluged in Spyder4 again

- in the hardwaremanager, install the right driver

?

Where?

- Folder: Windows (C / Program Files (x86) / HCFR Calibration / Drivers


Thats it

my mistake was that I typed always in CMD "Programm" instead of Program


Now my HCFR is working with the spyder very easily

 

[zoyd]

I git cloned the code. the i1 pro requires that winusb be loaded along with libusb-1.0A in the version that supports multiple meters.

 

[gwgill]

> I made a change in the D3 meter code that has stabilized it quite a bit.

> Simply setting the baseline integration time to a larger value (1.5 sec

> which is the default for CM for low light conditions) did the trick. I don't

> know anything about git and merging in new code etc. so here is a

> standalone package with the change.


I'm sure it did, but you're throwing away one of the major advantages of the D3, it's speed.


It would help if you could download the latest ArgyllCMS development snapshot at http://www.argyllcms.com/Argyll_dev_src.zip and check the stability on your test case using spotread (ie. "spotread -yr"). I've tweaked the refresh display code to up the integration time to 0.4 seconds minimum, and also change the crossover from period to frequency measurement mode to improve consistency for refresh type displays such as plasmas. If you don't want to or can't compile the source, you can find an MSWin binary at http://www.argyllcms.com/disptools.win32.zip . [ It's always better to try and fix these sorts of problems upstream.]

 

[zoyd]



Quote:
Originally Posted by gwgill  /t/1393853/fork-of-hcfr-started-whats-needed/1290#post_22894493


> I made a change in the D3 meter code that has stabilized it quite a bit.

> Simply setting the baseline integration time to a larger value (1.5 sec

> which is the default for CM for low light conditions) did the trick. I don't

> know anything about git and merging in new code etc. so here is a

> standalone package with the change.


I'm sure it did, but you're throwing away one of the major advantages of the D3, it's speed.


It would help if you could download the latest ArgyllCMS development snapshot at http://www.argyllcms.com/Argyll_dev_src.zip and check the stability on your test case using spotread (ie. "spotread -yr"). I've tweaked the refresh display code to up the integration time to 0.4 seconds minimum, and also change the crossover from period to frequency measurement mode to improve consistency for refresh type displays such as plasmas. If you don't want to or can't compile the source, you can find an MSWin binary at http://www.argyllcms.com/disptools.win32.zip . [ It's always better to try and fix these sorts of problems upstream.]

Speed is still quite good but I agree that further optimization is beneficial. I'll fold the Argyll changes into the HCFR d3 code and test it directly.


Any comment on the i1pro driver issue? In John's multimeter argyll wrapper the only way I can get the usb "open" api to work is by forcing the winusb driver to load ( WINUSBCO_DEV in the inf) I saw you made a note somewhere about the i1pro not being happy with winusb but so far I have not seen problems operationally.

 

[gwgill]



Quote:
Originally Posted by zoyd  /t/1393853/fork-of-hcfr-started-whats-needed/1290#post_22894579


Speed is still quite good but I agree that further optimization is beneficial. I'll fold the Argyll changes into the HCFR d3 code and test it directly.


Any comment on the i1pro driver issue? In John's multimeter argyll wrapper the only way I can get the usb "open" api to work is by forcing the winusb driver to load ( WINUSBCO_DEV in the inf) I saw you made a note somewhere about the i1pro not being happy with winusb but so far I have not seen problems operationally.

Folding the latest driver improvements in might not be entirely straightforward, since I've made a lot of changes to the instrument access library API aimed at improving its operation in a GUI environment, although it would be possible with some effort to extract the specific i1d3 stuff and apply it back.


I'm not aware of any i1pro issues - yes there was a problem a while back with having more than one instrument open at a time, but from the feedback I got from JohnAd I thought that had been sorted out. The way ArgyllCMS is structured it's not actually possible to open more than one instrument from a single application (although perfectly possible to open more than one instrument using more than once instance of an application), so it's not easy for me to test this particular aspect.


A lot of the issues people have, seem to be in not understanding that ArgyllCMS needs to use different system USB drivers than the instrument manufacturers software. I'm not sure how clear the HCFR doco is on that. I've certainly put a step by step in the Argyll documentation: http://www.argyllcms.com/doc/Installing_MSWindows.html

 

[jdbimmer]



Quote:
Originally Posted by zoyd  /t/1393853/fork-of-hcfr-started-whats-needed/1290#post_22894407


I git cloned the code. the i1 pro requires that winusb be loaded along with libusb-1.0A in the version that supports multiple meters.

Okay, I'll try that if I have time tonight. I have 32 and 64 bit Windows 7 machines to test this on if needed.

 

[jdbimmer]



Quote:
Originally Posted by jdbimmer  /t/1393853/fork-of-hcfr-started-whats-needed/1290#post_22895440


Okay, I'll try that if I have time tonight. I have 32 and 64 bit Windows 7 machines to test this on if needed.

I installed the winusb driver on Win 7 64 from the HCFR libusb folder and the i1Pro displayed a "can not start device" message in Device Manager. I couldn't access it from any of the HCFR versions, so I reverted back to libusb.


Edit: Same error in Win 7 32 bit. My guess is the problem is with the inf file.

 

[zoyd]



Quote:
Originally Posted by gwgill  /t/1393853/fork-of-hcfr-started-whats-needed/1290#post_22894721



I'm not aware of any i1pro issues - yes there was a problem a while back with having more than one instrument open at a time, but from the feedback I got from JohnAd I thought that had been sorted out.

There is some esoteric usb com problem with the i1pro. The current status is:


1. Initial version 3.0.0.0 of the argyll wrapper code works fine with the i1pro but supports only one meter at a time and doesn't support the d3 or colormunki.

2. Versions >3.0.0.0 which support multiple meters (including the d3/colormunki) but throws an error in icoms when trying to open the i1pro. Spotread works fine.

3. If I modify the i1pro inf to include the standard winusb.dll as a required device driver everybody's happy but so far working on win32xp only.

 

[gwgill]



Quote:
Originally Posted by zoyd  /t/1393853/fork-of-hcfr-started-whats-needed/1290#post_22899517


There is some esoteric usb com problem with the i1pro. The current status is:


1. Initial version 3.0.0.0 of the argyll wrapper code works fine with the i1pro but supports only one meter at a time and doesn't support the d3 or colormunki.

2. Versions >3.0.0.0 which support multiple meters (including the d3/colormunki) but throws an error in icoms when trying to open the i1pro. Spotread works fine.

3. If I modify the i1pro inf to include the standard winusb.dll as a required device driver everybody's happy but so far working on win32xp only.

If spotread works fine, then there is something particular in either the way HCFR is using instlib, or some difference to the ArgyllCMS V1.4 code. Is there a specific error message in the 2nd case ? (ie. instlib debug output). I'm not sure why switching to winusb would make any difference, nor why winusb would be restricted to win32xp (certainly winusb is used for some instruments in ArgyllCMS V1.4 on 32 and 64 bit Vista & Win7).

 

[zoyd]

yes, the specific error is:
Code:

[CODE]libusb:debug [unsupported_open] unsupported API call for 'open'

[/CODE]



Some googling led me to force loading of the winusb driver, particularly this post


"Remember that when using libusb on

Windows (unless you are using a WinUSB WCID device [1] on Windows 8),

you must install a relevant compatible driver, which currently means

WinUSB for libusb-1.0."


and


"USB_API_UNSUPPORTED (which is not an error code, but an API value used

internally) simply means that, while a device was found, it is not using

the WinUSB driver so we can't access it."

 

[Losha]



Quote:
Originally Posted by zoyd  /t/1393853/fork-of-hcfr-started-whats-needed/1290#post_22899517



3. If I modify the i1pro inf to include the standard winusb.dll as a required device driver everybody's happy but so far working on win32xp only.

NTx86.5.1_Device = "LIBUSB0_DEV" ; 32 bit WinXP

shouldn't that actually be:

NTx86.5.1_Device = "WINUSBCO_DEV" ; 32 bit WinXP


works like a charm

 

[zoyd]



Quote:
Originally Posted by Losha  /t/1393853/fork-of-hcfr-started-whats-needed/1290#post_22901192

NTx86.5.1_Device = "LIBUSB0_DEV" ; 32 bit WinXP

shouldn't that actually be:

NTx86.5.1_Device = "WINUSBCO_DEV" ; 32 bit WinXP


works like a charm

we know, that was established back in this post. The inf in that package is already modified so that the i1pro will work with winxp using the winusbco_dev driver line.

 

[gwgill]



Quote:
Originally Posted by zoyd  /t/1393853/fork-of-hcfr-started-whats-needed/1290#post_22900189


yes, the specific error is:
Code:

[CODE]libusb:debug [unsupported_open] unsupported API call for 'open'

[/CODE]


Some googling led me to force loading of the winusb driver, particularly this post


"Remember that when using libusb on

Windows (unless you are using a WinUSB WCID device [1] on Windows 8),

you must install a relevant compatible driver, which currently means

WinUSB for libusb-1.0."

I'm not sure how HCFR is packaged - in the ArgyllCMS V1.4 package the Microsoft WinUSB installables for 32 and 64 bit are included and used in the driver instalation.

Quote:
Originally Posted by zoyd 

"USB_API_UNSUPPORTED (which is not an error code, but an API value used

internally) simply means that, while a device was found, it is not using

the WinUSB driver so we can't access it."

Hmm. It's hard to know why this is the error - it means that the libusb code couldn't identify the system driver being used by the device, which is strange because it will recognize WinUBS, libusb0 and HidUsb.


[ArgyllCMS V1.5 beta drops libusb and WinUSB completely, and uses the libusb-win32 (libusb0) system driver, and simplifies the device setup by using a single .inf file.]

 

[zoyd]



Quote:
Originally Posted by gwgill  /t/1393853/fork-of-hcfr-started-whats-needed/1290#post_22902656


I'm not sure how HCFR is packaged - in the ArgyllCMS V1.4 package the Microsoft WinUSB installables for 32 and 64 bit are included and used in the driver instalation.

Hmm. It's hard to know why this is the error - it means that the libusb code couldn't identify the system driver being used by the device, which is strange because it will recognize WinUBS, libusb0 and HidUsb.


[ArgyllCMS V1.5 beta drops libusb and WinUSB completely, and uses the libusb-win32 (libusb0) system driver, and simplifies the device setup by using a single .inf file.]

HCFR uses the ArgyllCMS V1.4.0 libusb1 folder for driver installation and most of the meters have infs that load winusb_dev but the i1pro.inf looks like this:
Code:

[CODE]; These 8 determine which type of driver is installed & used for each platform:
; LIBUSB0_DEV   libusb0.sys kernel driver (Win2K to Win7, signing needed on 64 bit)
; PTLIBUSB0_DEV ptlibusb0.sys kernel driver (Win2K to Win7, signed by PRUFTECHNIK)
; WINUSBCO_DEV  Install & use latest WinUSB kernel driver (WinXP to Win7)
; WINUSB_DEV    Use installed WinUSB kernel driver (Vista to Win7) 

Default_Device      = "LIBUSB0_DEV"           ; Default
NTx86.5.0_Device    = "LIBUSB0_DEV"           ; 32 bit Win2K
NTx86.5.1_Device    = "LIBUSB0_DEV"           ; 32 bit WinXP
NTamd64.5.1_Device  = "PTLIBUSB0_DEV"         ; 64 bit WinXP
NTx86.6_Device      = "LIBUSB0_DEV"           ; 32 bit Vista
NTamd64.6_Device    = "PTLIBUSB0_DEV"         ; 64 bit Vista
NTx86.6.1_Device    = "LIBUSB0_DEV"           ; 32 bit Win7
NTamd64.6.1_Device  = "PTLIBUSB0_DEV"         ; 64 bit Win7

[/CODE]


I also tried the V1.5 inf and get the same error as above.

 

[gwgill]



Quote:
Originally Posted by zoyd  /t/1393853/fork-of-hcfr-started-whats-needed/1290#post_22902915



HCFR uses the ArgyllCMS V1.4.0 libusb1 folder for driver installation and most of the meters have infs that load winusb_dev but the i1pro.inf looks like this:
Code:

[CODE].
.

[/CODE]

If HCFR is using the same instlib code as ArgyllCMS V1.4, then I don't understand how it is possible for spotread to work and HCFR to get this type of error. There must be some inconsistency between the instlib and/or libusb code in HCFR to cause this. Having both on the same machine provides the perfect situation to track down what that difference is

Quote:
Originally Posted by zoyd  /t/1393853/fork-of-hcfr-started-whats-needed/1290#post_22902915


I also tried the V1.5 inf and get the same error as above.

That's never likely to work - V1.5b doesn't install WinUSB and doesn't install libusb1A.dll, etc.


There is some cross compatibility if the libusb0.sys is the driver used by an instrument, but idealy the old V1.4 driver should be removed and the V1.5b one freshly installed, and the V1.5b instlib/applications used with it.

 

[zoyd]



Quote:
Originally Posted by gwgill  /t/1393853/fork-of-hcfr-started-whats-needed/1290#post_22903686


There must be some inconsistency between the instlib and/or libusb code in HCFR to cause this. Having both on the same machine provides the perfect situation to track down what that difference is

yep, when John updated the libusb code to handle multiple meters something broke.

 

[vega509]



Quote:
Originally Posted by zoyd  /t/1393853/fork-of-hcfr-started-whats-needed/1290#post_22903746


yep, when John updated the libusb code to handle multiple meters something broke.

maybe a question that has been answered already, but why not go back to the windows / x-rite drivers like version 2 had?

 

[zoyd]

Because the point of creating an open source project was so that the code could be published (no copyright issues) for everyone to work on.

 

[gwgill]



Quote:
Originally Posted by vega509  /t/1393853/fork-of-hcfr-started-whats-needed/1290#post_22907403


maybe a question that has been answered already, but why not go back to the windows / x-rite drivers like version 2 had?

You can do anything you like or course - if you can rustle up the expertise and time to do it


To use the manufacturers drivers entails someone R.E. the API's to their driver system and testing and maintaining the result. While some of the older instruments have known DLL API's, the newer instruments have differences, and are harder to access if you use X-Rite's install, since they have moved to a server architecture. Some hybrid Argyll/OEM instrument access approach is theoretically possible, but it would be ugly to organize.


The fact that ArgyllCMS spotread works indicates that there is probably a trivial bug in the HCFR code in regard to the i1pro. If no-one is prepared to look into that, then I see little hope of proceeding with a larger task such as reverting to using the manufacturers drivers.

 

[ttnuagmada]



Quote:
Originally Posted by zoyd  /t/1393853/fork-of-hcfr-started-whats-needed/1200_100#post_22883973


I made a change in the D3 meter code that has stabilized it quite a bit. Simply setting the baseline integration time to a larger value (1.5 sec which is the default for CM for low light conditions) did the trick. I don't know anything about git and merging in new code etc. so here is a standalone package with the change.




edit:


Made a proper installation package:

HCFRsetup.exe

awesome! I'll definitely play around with it this weekend and report back.