Arduino / USB association on Lab PCs (non-admin users)

[yeldarb]

Having problems with a class taught in a PC lab (Windows 7 64-bit) where the students log in using directory credentials and do not have administrative rights on the PCs. Students bought the Adafruit 170 kit, but there appear to be some variations to the R3 boards supplied, as some work but some are not recognized by Windows Device Manager at connect time. The only resolution "in situ" is for a teaching assistant or faculty with admin rights to override Device Manager (authenticate) and Update Drivers, Browse to .... arduino\drivers folder etc.

The goal would be for any student to be able to sit at any PC in the room and connect any UNO board. What kind of "installation" would need to be done in order to accommodate that ? The arduino 1.0.1 is just a file copy, there's no "installer". The inlcuded "drivers" are just .inf files, and there's only one for R3, so it's unclear why this is happening or what more we could do in advance.

[adafruit_support_bill]

Have the drivers (inf files) been pre-installed on all the machines? Usually if there is an existing UNO driver install, the Device Manger will correctly identify new UNOs as they are plugged in - although it will generally assign them a different COM port.

Are you seeing driver problems on machines with existing UNO installs?

[yeldarb]

In a nutshell, yes, we are seeing problems on machines with existing UNO installs.

Yes, the arduino-1.0.1 (which includes the "\drivers" subfolder with .inf files) are installed on all machines. Although, as you know, there is not really an "installation" with arduino, per se, it's just copying the files to "C:\Program Files (x86)\arduino-1.0.1\"

Your statement beginning with "Usually" was our experience in the past. However, with this current batch of 250+ Adafruit/170 kits containing R3 boards, this is not the case. Device manager correctly identifies less than 30% of the boards. Students are not admins on the lab PCs, so at that point they can't do anything. A faculty or TA must come over to the PC and do the Device Manager, Update Drivers procedure using their admin credentials in order to recognize the board. For that specific PC, we then find subsequent students have about a 50% chance of their board working. When one doesn't work, the process is repeated, and so on... A complete waste of class time.

So we went back to our initial "installation" arrangement to re-do it. As admin, we installed Arduino software and connected not just one R3 board, but three R3 boards in succession (3 boards that we had previously marked as apparently "different" from each other.) Each was automatically recognized and assigned a different COM port as you mention. When we re-deployed this new installation, however, students still have the same problem with a few of the boards (perhaps 20%). This suggests that we must have "missed" a variety of R3 board and needed to connect a fourth or fifth variety of R3 during the initial installation process.

This seems crazy to us, that there would be "versions" of the R3 board that are recognized differently by Windows via USB. We're looking for an explanation to this, in hopes of developing a better procedure for the students to use these in a lab situation.

[adafruit_support_bill]

I don't know the answer to that. Assuming that they are all authentic Arduinos (there are a lot of convincing counterfeits out there) I would expect that all R3's would have the same product & vendor ID. You might want to pose this question to the Arduino Team at http://arduino.cc/

[yeldarb]

You're not the first to suggest the possibility that the problem is due to counterfeits. However, these are all kits that our Bookstore says they purchased directly from Adafruit. They appear to be authentic. I am still pursuing that line of investigation, however... Any suggestions?

I did also email team (at) arduino (dot) cc but have not yet received a response.

[westfw]

Yes, the arduino-1.0.1 (which includes the "\drivers" subfolder with .inf files) are installed on all machines. Although, as you know, there is not really an "installation" with arduino, per se, it's just copying the files to "C:\Program Files (x86)\arduino-1.0.1\"

There's more to installing the drivers than just copying the \drivers subfolder to C: with the rest of the files. It's described here: http://arduino.cc/en/Guide/Windows#toc4
(although I don't understand how an arduino could be recognized in administrator mode (implying that the drivers ARE properly installed) and not in normal user mode...)

Have you tried Microsoft's USBView utility? There's a downloadable executable at FTDI: http://www.ftdichip.com/Support/Utilities.htm

[yeldarb]

Yes we do this step as admin with the first board.
http://arduino.cc/en/Guide/Windows#toc4

Sorry, part of my explanation above wasn't clear: when I said "Each was automatically recognized and assigned a different COM port as you mention" I meant each subsequent board after connecting the first, and confirming what you said about different COM ports (which is not a problem for us.)

We have no problem installing drivers for *a* board. The problem we're having relates to some kind of "difference" between boards that otherwise appear to be identical, and different students with different boards logging into Windows and not having them recognized by Device Manager.

Unfortunately we don't know how many varieties of boards there are, or why they are even different. Thus my inquiry here.

[adafruit_support_bill]

Unfortunately we don't know how many varieties of boards there are, or why they are even different.

The USBView utility recommended by WestFW may help shed some light on any differences in your boards by displaying the device configuration as reported by the device.

[JD3]

Maybe its the way the Atmega16U2 chip is programmed as the USB to Serial converter.
Or the chip ID could be different.

Anytime you are using a computer system w/ administrative rights turned on and users w/o permissions
have to install hardware or drivers there will be problems.

In the install drivers section the first line from http://arduino.cc/en/Guide/Windows says:
"Plug in your board and wait for Windows to begin it's driver installation process. After a few moments, the process will fail, despite its best efforts"

Then it describes going into the device manager and pointing the device to the right drivers.

You are going about it the right way, unfortunately the problems you are having are more related to Windows......

[yeldarb]

I agree this is primarily a Windows Device Manager problem. However, it did not happen in the past with previous versions of Arduino UNO. I guess my criticism here, without knowing more details about what is going on, might be why there are apparently "different" versions of Arduino R3 hardware all sold under the same model. Also, is the fact that these drivers are "unsigned" also part of the problem?

I realize this is practically a non-issue for the vast majority of individual Arduino users, since they buy one board and are probably admin on their Windows PC. This is why I posted to the "For Education" forum. Most schools have labs and classrooms of Windows PCs where the students log in via a Directory account and do not have admin rights. If the Arduino UNO R3 boards were all the same, or even if there was an easily identifiable distinguishing characteristic, we could develop a workaround. Barring that, our experience should serve as a warning to anyone else planning to teach a class using Arduino UNO R3 in a typical campus computer lab.

[JD3]

You can update the firmware on the new R3's - maybe by making the firmware the same on all of them would solve the problem.

There were some early problems w/ the new Unos, relating to the USB to serial chip.

[adafruit_support_bill]

You can update the firmware on the new R3's - maybe by making the firmware the same on all of them would solve the problem.

Better to understand the problem first.

I think that USBView is the first step here. If you have UNO-R3s that are reporting different USB configuration data, we can ask the Arduino team what the story is. If they are reporting identical configuration data, then it is a DeviceManager issue.

[yeldarb]

OK with two examples of "differently recognized" UNO R3 boards, I ran USBView and diff'd the configuration results. The only difference is under the "Device Descriptor:" section at the top:
0x0409: "74133353437351319112"
vs
0x0409: "7493430303035161C1B0"
I don't know what this means, if anything.

I don't have access to the other "different" boards right now, I'll need to get them back from two students we noted and will run those against USBView as well.

[adafruit_support_bill]

If that is the field immediately following the 'iSerialNumber' field, then I believe that is the serial number of the board. The R3 I have sitting here reports:

Code: Select all

Device Descriptor:
bcdUSB:             0x0110
bDeviceClass:         0x02
bDeviceSubClass:      0x00
bDeviceProtocol:      0x00
bMaxPacketSize0:      0x08 (8)
idVendor:           0x2341
idProduct:          0x0043
bcdDevice:          0x0001
iManufacturer:        0x01
0x0409: "Arduino (www.arduino.cc)"
iProduct:             0x02
iSerialNumber:        0xDC
0x0409: "93140364233351301202"
bNumConfigurations:   0x01

ConnectionStatus: DeviceConnected
Current Config Value: 0x01
Device Bus Speed:     Full
Device Address:       0x02
Open Pipes:              3

Endpoint Descriptor:
bEndpointAddress:     0x82  IN
Transfer Type:   Interrupt
wMaxPacketSize:     0x0008 (8)
bInterval:            0xFF

Endpoint Descriptor:
bEndpointAddress:     0x04  OUT
Transfer Type:        Bulk
wMaxPacketSize:     0x0040 (64)
bInterval:            0x01

Endpoint Descriptor:
bEndpointAddress:     0x83  IN
Transfer Type:        Bulk
wMaxPacketSize:     0x0040 (64)
bInterval:            0x01

Configuration Descriptor:
wTotalLength:       0x003E
bNumInterfaces:       0x02
bConfigurationValue:  0x01
iConfiguration:       0x00
bmAttributes:         0xC0 (Bus Powered Self Powered )
MaxPower:             0x32 (100 Ma)

Interface Descriptor:
bInterfaceNumber:     0x00
bAlternateSetting:    0x00
bNumEndpoints:        0x01
bInterfaceClass:      0x02
bInterfaceSubClass:   0x02
bInterfaceProtocol:   0x01
iInterface:           0x00

Unknown Descriptor:
bDescriptorType:      0x24
bLength:              0x05
05 24 00 01 10

Unknown Descriptor:
bDescriptorType:      0x24
bLength:              0x04
04 24 02 06

Unknown Descriptor:
bDescriptorType:      0x24
bLength:              0x05
05 24 06 00 01

Endpoint Descriptor:
bEndpointAddress:     0x82  IN
Transfer Type:   Interrupt
wMaxPacketSize:     0x0008 (8)
bInterval:            0xFF

Interface Descriptor:
bInterfaceNumber:     0x01
bAlternateSetting:    0x00
bNumEndpoints:        0x02
bInterfaceClass:      0x0A
bInterfaceSubClass:   0x00
bInterfaceProtocol:   0x00
iInterface:           0x00

Endpoint Descriptor:
bEndpointAddress:     0x04  OUT
Transfer Type:        Bulk
wMaxPacketSize:     0x0040 (64)
bInterval:            0x01

Endpoint Descriptor:
bEndpointAddress:     0x83  IN
Transfer Type:        Bulk
wMaxPacketSize:     0x0040 (64)
bInterval:            0x01


[yeldarb]

So what does this tell us? Only that the USBView utility does not discern a difference other than serial number?
Empirical evidence has shown that there is indeed a difference, at least from the perspective of Windows Device Manager, or we would not have the experience that "some of the R3 boards" are automatically recognized when students connect them, while "other R3 boards" are not. This is corroborated by the fact that when we connected 3 boards during the admin-install procedure instead of just one, we then saw a greater percentage of the students be successful logging is as non-admin and having their boards automatically recognized. I don't know what else to conclude, other than there are at least 4 (or more) variations in the R3 boards (or, in how Windows Device Manager sees them, anyway.)