PCSU1000/PcLab200SE an Windows 10: An issue

PCSUDO1 · August 25, 2015, 7:14pm

Hi,

the combo PCSU1000 and PcLab200SE 4.05 behaves on Win10 like someone who kicks out all other members of a team making it a solitair.

Reason: The installation of the quite old drivers is an adventure (Restart with specific options set in advance for accepting uncertified drivers). However, it is successful eventually, even when the start of the application is accompanied by a messege “Error in opening created Key”, which apparently can be neglected.

But if you need more modern drivers for other devices using FTDI USB-interface chips/drivers and install the available recent drivers from FTDI resources (e. g. “CDM v2.12.06 WHQL Certified.exe”) the functionality of the oszilloscope is gone. It no longer can connect to the PC when the USB plug is inserted, the “boot” procedure running in that moment stops. In USBView.exe this can be seen: There are no “Pipes” open for this port.

It shouldn’t be an issue of FTDI, because they are saying that the latest drivers fit for all products. However: The strange solution to copy the “old” files manually into …\system32 and …\system32\drivers fixed it (look at the time stamps):

C:\Windows\System32>dir ft* drivers\ft*

Verzeichnis von C:\Windows\System32

12.05.2009  23:31           143.688 ftbusui.dll
24.07.2015  07:30            83.968 ftcserco.dll
24.07.2015  07:30           325.120 ftd2xx.dll
10.07.2015  12:59            66.048 fthsvc.dll
12.05.2009  23:31           274.752 FTLang.dll
04.08.2009  19:55             9.216 ftlx0411.dll
04.08.2009  19:55            10.240 ftlx041e.dll
24.07.2015  07:30            74.240 ftserui2.dll
04.08.2009  19:55           195.072 ftsrch.dll

Verzeichnis von C:\Windows\System32\drivers

12.05.2009  23:31            69.192 ftdibus.sys
24.07.2015  07:30            97.416 ftser2k.sys

This means: We can use exclusively run the PCSU1000 on a PC and have to forget any new devices using more recent FTDI chips.

Will something better be provided by Velleman? The PCSU1000 itself is, I still think, perfectly designed and the PCLAB application close to perfection either.

Regards

Rolf

PCSUDO1 · November 16, 2015, 2:53pm

The procedures depicted above for making PCSU1000 running under Windows 10-64bit together with other USB devices using FTDI interface controllers allowed a quite stable operation since that time until last week. Since then the system process to establish a USB connection fails when the PCSU1000 is connected, the device is no longer properly detected. The PcLab2000SE no longer detects an existing USB path to the attached PCSU1000.

My conclusion: PCSU1000 no longer can properly connect to a PC running under Windows 10. If a working solution is available with Windows 7 DO NOT UPGRADE TO WINDOWS 10 is I did.

The following investigations were undertaken:

With an older Laptop running still with Windows 7-32bit it was certified that the PCSU1000 is still running properly with PcLab2000SE: Success, the device still works and is OK!

On the Windows 10 PC, which is some years old, worked in the beginning with Win XP and since app. 3 years with Win 7-64bit without any problems, but was upgraded to Win 10 in August using the according Microsoft offer:

In the device manager, where the PCSU1000_Oscilloscope is listed as a device with problems, the drivers were deleted including “Delete Files” and reinstalled from folder “C:\Program Files (x86)\Velleman\PCLab2000SE\Drivers\PCSU1000”. Under “Driver Details” the files are listed properly as resident in …\system32, …\system32\drivers and …\SysWOW64. They were compared with the sources in the Velleman folder: They are identical in time stamp, file size and version. Such the installation is correct as far as the Velleman file resources are concerned.

Now on pages from Microsoft it is precisely depicted how an USB device is connected when the USB plug is inserted. Very interesting! The most important issue that the device identifies itself with a descriptor which is for the PCSU1000 “VID_10CF&PID_1000#YEL952TL”. For this in the Registry under HKLM\SYSTEM\ControlSet\Enum\USB\VID_10CF&PID_1000\YEL952TL\ all the information is available which allows the system detecting more information about the type of the inserted device, the required services to be used and which driver (ftdibus.sys) must be started. The entries allow even to reinstall the drivers. This exposes also why there is a problem using other devices based on FTDI controllers: Since only ONE version of ftdibus.sys can reside in the …\system32\drivers folder one device might copy from the according entries in the …\system32\DriverStore folders the own matching files to …\system32 and …\system32\drivers which then are unusable for the second (or third) device inserted.

Further investigations were undertaken using the ProcessMonitor (sysinternals). On the Win 7 PC it can be seen that after some trials a particular GUID {219d0508-57a8-4ff5-97a1-bd86587c6c7e}, a Serial Port Driver, is detected. This is not the case on Win 10! I think, that’s the reason for the problems. This surely is done somewhere deep in Windows and, I fear, not under control of any software developers. I only can conclude again: [color=#FF0000]Windows 10 currently is no longer usable for devices like the PCSU1000![/color]

USBView Messages:

[code][Port2] : PCSU1000_Oscilloscope

Is Port User Connectable: yes
Is Port Debug Capable: no
Companion Port Number: 0
Companion Hub Symbolic Link Name:
Protocols Supported:
USB 1.1: yes
USB 2.0: no
USB 3.0: no

   ---===>Device Information<===---

String Descriptor for index 2 not available while device is in low power state.

ConnectionStatus:
Current Config Value: 0x00 -> Device Bus Speed: Full (is not SuperSpeed or higher capable)
Device Address: 0x01
Open Pipes: 0
*!*ERROR: No open pipes!

      ===>Device Descriptor<===

bLength: 0x12
bDescriptorType: 0x01
bcdUSB: 0x0200
bDeviceClass: 0x00 -> This is an Interface Class Defined Device
bDeviceSubClass: 0x00
bDeviceProtocol: 0x00
bMaxPacketSize0: 0x08 = (8) Bytes
idVendor: 0x10CF = Velleman Components
idProduct: 0x1000
bcdDevice: 0x0400
iManufacturer: 0x01
String Descriptor for index 1 not available while device is in low power state.
iProduct: 0x02
String Descriptor for index 2 not available while device is in low power state.
iSerialNumber: 0x03
String Descriptor for index 3 not available while device is in low power state.
bNumConfigurations: 0x01
[/code]

or

[code][Port2]

Is Port User Connectable: yes
Is Port Debug Capable: no
Companion Port Number: 0
Companion Hub Symbolic Link Name:
Protocols Supported:
USB 1.1: yes
USB 2.0: no
USB 3.0: no

   ---===>Device Information<===---

ConnectionStatus:
Current Config Value: 0x00 -> Device Bus Speed: Low
Device Address: 0x00
Open Pipes: 0
*!*ERROR: No open pipes!

      ===>Device Descriptor<===

*!*ERROR: bLength of 0 incorrect, should be 18
bLength: 0x00
bDescriptorType: 0x00
bcdUSB: 0x0000
bDeviceClass: 0x00 -> This is an Interface Class Defined Device
bDeviceSubClass: 0x00
bDeviceProtocol: 0x00
bMaxPacketSize0: 0x00 = (0) Bytes
*!*ERROR: Low Speed Devices require bMaxPacketSize0 = 8
idVendor: 0x0000idProduct: 0x0000
bcdDevice: 0x0000
iManufacturer: 0x00
iProduct: 0x00
iSerialNumber: 0x00
bNumConfigurations: 0x00
*!*CAUTION: Most host controllers will only work with one configuration per speed
[/code]

PcLab200SE can’t detect a connected PCSU1000 under these conditions.

Since those messages, I think, report errors before the Velleman version of ftdibus.sys is started, Microsoft is in charge to solve this.

(@Velleman Support: Large log-files are available on request)

VEL436 · November 16, 2015, 6:23pm

Thank you for the detailed info about the problems with Windows 10.
Here you can download for testing purposes the latest FTDI driver version 2.12.06 modified for the PCSU1000:
app.box.com/s/cp03y8b5yk95ma260tewhnn4lw7a327m

PCSUDO1 · November 17, 2015, 9:48am

Thanks for the timely response!

File was downloaded and new versions installed after deleting the old decive in device manager.

Drivers are still not certified such special installation was done as before. But alas, the problem hasn’t vanished.

New drivers are installed in …\system32 and …\system32\drivers:

[code]C:\Windows\System32>dir /s ft*

Verzeichnis von C:\Windows\System32

24.08.2015 11:30 177.152 ftbusui.dll
24.07.2015 06:30 83.968 ftcserco.dll
24.07.2015 06:30 325.120 ftd2xx-15.dll
24.08.2015 11:30 325.120 ftd2xx.dll
10.07.2015 11:59 66.048 fthsvc.dll
24.08.2015 11:30 283.648 FTLang.dll
04.08.2009 18:55 9.216 ftlx0411.dll
04.08.2009 18:55 10.240 ftlx041e.dll
12.05.2009 22:31 54.600 ftserui2.dll
04.08.2009 18:55 195.072 ftsrch.dll

Verzeichnis von C:\Windows\System32\de-DE

10.07.2015 17:33 4.608 fthsvc.dll.mui
04.08.2009 19:11 8.704 ftsrch.dll.mui

Verzeichnis von C:\Windows\System32\drivers

24.08.2015 11:30 118.784 ftdibus.sys

Verzeichnis von C:\Windows\System32\DriverStore\FileRepository

17.11.2015 10:07 ftdibus.inf_amd64_070b783a5839b167 *** NEW ***
21.08.2015 09:24 ftdibus.inf_amd64_0a3c2df775f027fe
21.08.2015 09:24 ftdibus.inf_amd64_5616cc9aa1fc2a73
21.08.2015 09:24 ftdiport.inf_amd64_0174995d0b71bf25
21.08.2015 09:24 ftdiport.inf_amd64_6829bf65ce8d46bd
24.08.2015 07:38 ftdiport.inf_amd64_8922a19b275a3879

Verzeichnis von C:\Windows\System32\DriverStore\FileRepository\ftdibus.inf_amd64_070b783a5839b167

24.08.2015 11:30 13.830 ftdibus.cat
28.08.2015 09:18 12.781 ftdibus.inf
17.11.2015 10:07 10.696 ftdibus.PNF

Verzeichnis von C:\Windows\System32\DriverStore\FileRepository\ftdibus.inf_amd64_070b783a5839b167\amd64

24.08.2015 11:30 177.152 ftbusui.dll
24.08.2015 11:30 325.120 ftd2xx64.dll
24.08.2015 11:30 118.784 ftdibus.sys
24.08.2015 11:30 283.648 FTLang.dll

Verzeichnis von C:\Windows\System32\DriverStore\FileRepository\ftdibus.inf_amd64_070b783a5839b167\i386

24.08.2015 11:30 283.136 ftd2xx.dll
[/code]

But start of the driver ends with error code 10. I’ve found the following file in
C:\ProgramData\Microsoft\Windows\WER\ReportArchive\NonCritical_x64_534a2bf8d2436a5b44ec3086019ced321ddd_00000000_18d9b6d7
The contents:

Version=1 EventType=PnPDeviceProblemCode EventTime=130922248557413260 Consent=1 UploadTime=130922248559409960 ReportIdentifier=a41f298e-8d0a-11e5-9c3c-00248c5488f3 Response.type=4 Sig[0].Name=Architektur Sig[0].Value=x64 Sig[1].Name=Hardware-ID Sig[1].Value=USB\VID_10CF&PID_1000&REV_0400 Sig[2].Name=Setupclass-GUID Sig[2].Value={36fc9e60-c465-11cf-8056-444553540000} Sig[3].Name=PnP-Problemcode Sig[3].Value=0000000A Sig[4].Name=Treibername Sig[4].Value=ftdibus.sys Sig[5].Name=Treiberversion Sig[5].Value=2.12.6.3 Sig[6].Name=Treiberdatum Sig[6].Value=08-24-2015 DynamicSig[1].Name=Betriebsystemversion DynamicSig[1].Value=10.0.10240.2.0.0.768.101 DynamicSig[2].Name=Gebietsschema-ID DynamicSig[2].Value=1031 State[0].Key=Transport.DoneStage1 State[0].Value=1 FriendlyEventName=Die Treibersoftware konnte nicht geladen werden. ConsentKey=PnPDeviceProblemCode AppName=PCSU1000_Oscilloscope AppPath=C:\Windows\System32\drvinst.exe ReportDescription=Die Treibersoftware konnte erfolgreich installiert werden, aber beim Versuch, sie auszuführen, ist ein Fehler aufgetreten. Der Problemcode ist 10. ApplicationIdentity=00000000000000000000000000000000

???

Any idea what the problemcode 10 means?

VEL436 · November 17, 2015, 3:36pm

There are several possible reasons for the “code 10” problem.
It can be either hardware (e.g. defective USB cable) or driver related.
If this problem occurs only with the latest driver, you may have to reinstall the original PCSU1000 driver version 2.04.16.

PCSUDO1 · November 18, 2015, 10:28pm

As an interim Information:

Upgrade for Windows 10, Versiom 1511 was done.

One of the results: All Velleman traces in …\system32 …\system32\drivers and …\system32\DriverStore were simply deleted!

Looks like Microsoft has some objections.

Others have survived, e. g. all files of the original FTDI drivers.

PCSUDO1 · November 21, 2015, 5:30pm

OK, a ONE SHOT success:

Installing the recent driver package after connecting the PCSU1000 I was able to start PcLab2000 sucessfully.

USBVIEW:

[code][Port1] : PCSU1000_Oscilloscope

Is Port User Connectable: yes
Is Port Debug Capable: no
Companion Port Number: 0
Companion Hub Symbolic Link Name:
Protocols Supported:
USB 1.1: yes
USB 2.0: no
USB 3.0: no

Device Power State: PowerDeviceD0

   ---===>Device Information<===---

English product name: “PCSU1000”

ConnectionStatus:
Current Config Value: 0x01 -> Device Bus Speed: Full (is not SuperSpeed or higher capable)
Device Address: 0x01
Open Pipes: 2

      ===>Device Descriptor<===

bLength: 0x12
bDescriptorType: 0x01
bcdUSB: 0x0200
bDeviceClass: 0x00 -> This is an Interface Class Defined Device
bDeviceSubClass: 0x00
bDeviceProtocol: 0x00
bMaxPacketSize0: 0x08 = (8) Bytes
idVendor: 0x10CF = Velleman Components
idProduct: 0x1000
bcdDevice: 0x0400
iManufacturer: 0x01
English (United States) “Velleman”
iProduct: 0x02
English (United States) “PCSU1000”
iSerialNumber: 0x03
English (United States) “YEL952TL”
bNumConfigurations: 0x01

      ---===>Open Pipes<===---

      ===>Endpoint Descriptor<===

bLength: 0x07
bDescriptorType: 0x05
bEndpointAddress: 0x81 -> Direction: IN - EndpointID: 1
bmAttributes: 0x02 -> Bulk Transfer Type
wMaxPacketSize: 0x0040 = 0x40 bytes
bInterval: 0x00

      ===>Endpoint Descriptor<===

bLength: 0x07
bDescriptorType: 0x05
bEndpointAddress: 0x02 -> Direction: OUT - EndpointID: 2
bmAttributes: 0x02 -> Bulk Transfer Type
wMaxPacketSize: 0x0040 = 0x40 bytes
bInterval: 0x00

   ---===>Full Configuration Descriptor<===---

      ===>Configuration Descriptor<===

bLength: 0x09
bDescriptorType: 0x02
wTotalLength: 0x0020 -> Validated
bNumInterfaces: 0x01
bConfigurationValue: 0x01
iConfiguration: 0x00
bmAttributes: 0x80 -> Bus Powered
MaxPower: 0xF5 = 490 mA

      ===>Interface Descriptor<===

bLength: 0x09
bDescriptorType: 0x04
bInterfaceNumber: 0x00
bAlternateSetting: 0x00
bNumEndpoints: 0x02
bInterfaceClass: 0xFF -> Interface Class Unknown to USBView
bInterfaceSubClass: 0xFF
bInterfaceProtocol: 0xFF
iInterface: 0x02
English (United States) “PCSU1000”

      ===>Endpoint Descriptor<===

bLength: 0x07
bDescriptorType: 0x05
bEndpointAddress: 0x81 -> Direction: IN - EndpointID: 1
bmAttributes: 0x02 -> Bulk Transfer Type
wMaxPacketSize: 0x0040 = 0x40 bytes
bInterval: 0x00

      ===>Endpoint Descriptor<===

bLength: 0x07
bDescriptorType: 0x05
bEndpointAddress: 0x02 -> Direction: OUT - EndpointID: 2
bmAttributes: 0x02 -> Bulk Transfer Type
wMaxPacketSize: 0x0040 = 0x40 bytes
bInterval: 0x00
[/code]

Stopping PcLabd2000SE, unplugging and reinserting the USB cable was the end of the show:

USBview:

[code][Port2]

Is Port User Connectable: yes
Is Port Debug Capable: no
Companion Port Number: 0
Companion Hub Symbolic Link Name:
Protocols Supported:
USB 1.1: yes
USB 2.0: no
USB 3.0: no

   ---===>Device Information<===---

English product name: “PCSU1000”

ConnectionStatus:
Current Config Value: 0x00 -> Device Bus Speed: Full (is not SuperSpeed or higher capable)
Device Address: 0x01
Open Pipes: 0
*!*ERROR: No open pipes!

      ===>Device Descriptor<===

bLength: 0x12
bDescriptorType: 0x01
bcdUSB: 0x0200
bDeviceClass: 0x00 -> This is an Interface Class Defined Device
bDeviceSubClass: 0x00
bDeviceProtocol: 0x00
bMaxPacketSize0: 0x08 = (8) Bytes
idVendor: 0x10CF = Velleman Components
idProduct: 0x1000
bcdDevice: 0x0400
iManufacturer: 0x01
English (United States) “Velleman”
iProduct: 0x02
English (United States) “PCSU1000”
iSerialNumber: 0x03
English (United States) “YEL952TL”
bNumConfigurations: 0x01

   ---===>Full Configuration Descriptor<===---

      ===>Configuration Descriptor<===

bLength: 0x09
bDescriptorType: 0x02
wTotalLength: 0x0020 -> Validated
bNumInterfaces: 0x01
bConfigurationValue: 0x01
iConfiguration: 0x00
bmAttributes: 0x80 -> Bus Powered
MaxPower: 0xF5 = 490 mA

      ===>Interface Descriptor<===

bLength: 0x09
bDescriptorType: 0x04
bInterfaceNumber: 0x00
bAlternateSetting: 0x00
bNumEndpoints: 0x02
bInterfaceClass: 0xFF -> Interface Class Unknown to USBView
bInterfaceSubClass: 0xFF
bInterfaceProtocol: 0xFF
iInterface: 0x02
English (United States) “PCSU1000”

      ===>Endpoint Descriptor<===

bLength: 0x07
bDescriptorType: 0x05
bEndpointAddress: 0x81 -> Direction: IN - EndpointID: 1
bmAttributes: 0x02 -> Bulk Transfer Type
wMaxPacketSize: 0x0040 = 0x40 bytes
bInterval: 0x00

      ===>Endpoint Descriptor<===

bLength: 0x07
bDescriptorType: 0x05
bEndpointAddress: 0x02 -> Direction: OUT - EndpointID: 2
bmAttributes: 0x02 -> Bulk Transfer Type
wMaxPacketSize: 0x0040 = 0x40 bytes
bInterval: 0x00
[/code]

Windows 10 and PCSU1000 doesn’t work!

PCSUDO1 · December 16, 2015, 9:54pm

OK, staying silent means NO IDEA about a solution.

I’ve spent a lot of time studying MS pages about USB. Very interesting what’s going on when an USB device is inserted into an USB plug.

I think, the problem is raised by some sloppy programming of FTDI.

In the ftdibus.inf file, the basic file for driver installation, the PCSU1000 is put into a Device Class with the command

ClassGUID={36fc9e60-c465-11cf-8056-444553540000}

Now on MS page https://msdn.microsoft.com/en-us/library/windows/hardware/ff538820%28v=vs.85%29.aspx it is said about these GUIDs:

[color=#800000]Two important device setup classes for USB devices are as follows:

USBDevice {88BAE032-5A81-49f0-BC3D-A4FF138216D6}: IHVs must use this class for custom devices that do not belong to another class. This class is not used for USB host controllers and hubs.

USB {36fc9e60-c465-11cf-8056-444553540000}: IHVs must not use this class for their custom devices. This is reserved for USB host controllers and USB hubs.
[/color]
An exactly the reserved GUID for host controllers and hubs is used by FTDI for their chips. Such Windows expect a controller, which usually is placed on the motherboard or an internal PCI(E) card, and not a peripheral device at the end of an USB cable.

IMHO this is the reason for the problem: The PCSU1000 is a peripheral device and not an USB controller!

BasAlbers · January 12, 2016, 1:16pm

Hi,

I have not been able to install the PCSU200 driver under Windows 10. It keeps compaining that the digital signature is missing.

Is there any way to get it going under Window 10?

Bas

Wrong_Way · January 12, 2016, 4:20pm

Try doing this before installing the drivers.

Windows Key + R
Enter shutdown.exe /r /o /f /t 00 [color=#BF0000]<-- These are Zeros Note the Spaces[/color]
Click the “OK” button
System will restart to a “Choose an option” screen
Select “Troubleshoot” from “Choose an option” screen
Select “Advanced options” from “Troubleshoot” screen
Select “Windows Startup Settings” from “Advanced options” screen
Click “Restart” button
System will restart to “Advanced Boot Options” screen
Select “Disable Driver Signature Enforcement”
Once the system starts, install the drivers

PCSUDO1 · January 13, 2016, 11:12pm

And the result is: It doesn’t work!!!

Thanks for this advice, you can’t imagine, how often I have done this.

My response: I’ve achieved a new DSO, not from Velleman. In this case, the money goes to: China!

Wrong_Way · January 14, 2016, 8:52pm

Did you download the latest drivers and software from the Velleman website?

PCSUDO1 · January 14, 2016, 11:05pm

This question is superfluous. The posts above expose all what was done!

[size=150]But the new situation is: It works now![/size]

Without changing anything but just sustaining the update business from Microsoft: after update KB3124263 the problem disappeared!

I now can attach the PCSU1000 and USBView shows a proper connection, can start PcLab 2000 SE and it works, can stop it, can unplugg the unit and re-attach it: All works as before on previous releases of Windows!

Haven’t checked advanced functionality as writing data to files etc.

I think, MS has corrected some quirks in the procedures used for the basic communication set-up starting with the inserted USB-device.

I will report about further experiences.

BasAlbers · January 17, 2016, 6:56pm

Thanks Wrong Way. For me it worked perfectly.

Bas

PCSUDO1 · January 22, 2016, 7:21pm

Hmmm,

first I couldn’t believe it: The problem reappeared!

So what was different to the success a few days ago? I squeezed my brain and then I’ve found it: I have used not the usual USB-cable as supplied with the scope years ago but a different one.

Using that again, the problem was gone!

Such the new conclusion is. The short grey USB-Cable is/was the reason for the problem. It still works with the Win 7 Laptop without any issues!

Strange world!

VEL436 · January 22, 2016, 8:07pm

Thank you for the feedback.
This was interesting finding you made.
Is there any difference if you use the original USB cable connected to USB3.0 or USB2.0 connector of your new PC?
(In case if there are both USB 2.0 and USB 3.0 connectors.)

PCSUDO1 · January 28, 2016, 10:47pm

No, no USB 3.0 ports available: PC is from 2009, was initially used with XP, then with Win 7 and now with Win 10.

No new PC

leonferrara · August 28, 2016, 7:12am

Hello,
I am Leon Ferrara a newbie in this forum. I want to thanks for discussuon this topics. I got many information for solve this issue in windows 10.
Thanks

PCSUDO1 · September 29, 2016, 10:34am

Upgrading to[color=#800000] Win 10 1607 [/color]is the same old and sad story: The upgrade again removed all installed Velleman drivers.

Reinstallation was required. Success.

The strange old cable still doesn’t work.

Peter_Popov · October 17, 2016, 2:00pm

Guys, the only remedy, I think, is Velleman staff to stop kidding its loyal customers and to invest some time and money in NEW (signed) DRIVERS suitable for WIN10 64-bit version.
Because it is a shame for the company to continue to sell these otherwise excellent instruments - PCSU1000 and PCGU 1000 - with their archaic drivers, making them COMPLETELY UNUSABLE with the new PCs.