[all] Serialport.list Information Wrong/Missing

• SerialPort Version: 4.07

• NodeJS Version: 7.1

• Operating System and Hardware Platform: Windows 10 and Ubuntu 16.04

• Have you checked the right version of the api docs?: Yes

• Are you having trouble installing and you checked the Installation Special Cases docs? No

• Are you using Electron and have you checked the Electron Docs?: No

Summary of Problem

FTDI device serial numbers are missing and manufacturers are incorrect on Windows 10.

Steps and Code to Reproduce the Issue

Using Windows 10, plug in a FTDI USB device. Next, assign it a unique USB device descriptor using FT_Prog. After programming the FTDI device with the new USB device descriptors, run serialport-list -f jsonline, resulting in output similar to the following:

{"comName":"COM23","manufacturer":"FTDI","pnpId":"FTDIBUS\\VID_0403+PID_6001+A51MAMMEA\\0000","vendorId":"0403","productId":"6001"}

Using Ubuntu 16.04, plug in the same FTDI devices. Run serialport-list -f jsonline, resulting in output similar to the following:

{"comName":"/dev/ttyUSB0","manufacturer":"MLI","serialNumber":"MLI_scale_A51MAMME","pnpId":"usb-MLI_scale_A51MAMME-if00-port0","vendorId":"0x0403","productId":"0x6001"}

Why are the manufacturers listed differently between the two operating systems. Why doesn't windows see the serialNumber? Is there any way to fix this.

[reconbot]

It's been a long time since I've fully explored the apis involved but you can find the code responsible for returning the information here; https://github.com/EmergingTechnologyAdvisors/node-serialport/blob/master/src/serialport_win.cpp#L525-L573

Long story short, we ask the system for the info with SetupDiGetDeviceRegistryProperty and return it to the list function. For manufacturer we use SPDRP_MFG which is defined as

The function retrieves a REG_SZ string that contains the name of the device manufacturer.

So it's probably down to the drivers your using to load the FTDI device. Maybe FTDI has newer ones or will take a bug report?

For the serial number, I don't see that as a thing we can read from the pnp subsystem but I might be overlooking it. I do see we read some values out of the registry with RegQueryValueEx so maybe there's a way we can accomplish it with that approach.

Happy to add it if you can figure it out. Also happy to be shown references to how other serial port libraries (eg pyserial) if they include the missing info, so we can copy them.

Ok so i searched through the windows registry after taking a look at :
https://github.com/EmergingTechnologyAdvisors/node-serialport/blob/master/src/serialport_win.cpp#L525-L573

On Windows 10 the USB registry files are located under: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB

This is what I see on windows:

Note that I have highlighted one of the folders A51MAMME. This name of the folder is the serial number for this device.

If I go to the Device Parameters folder I see the following:

Note the SymbolicName REG_SZ :
??\USB#VID_0403&PID_6001#A51MAMME#{a5dcbf10-6530-11d2-901f-00c04fb951ed}

It contains the VID (0403), PID (6001), and the serialnumber (A51MAMME). So it looks like the serial number is available in the registry :) So maybe we can retrieve it with RegQueryValueEx?

So I installed pyserial on windows and ran their equivalent command line list and got the following:

COM23
desc: USB Serial Port (COM23)
hwid: USB VID:PID=0403:6001 SER=A51MAMMEA

So I dug into their code and it looks like they are retrieving the information from the registry using regular expressions, shown in the highlighted lines in the link below:

https://github.com/pyserial/pyserial/blob/master/serial/tools/list_ports_windows.py#L251-L257

[reconbot]

I'm confused. We have quite a few results.

• linux node-serialport: Atlas_pH_DO1KHTT8 (from this command udevadm info)
• registry A51MAMME
• pyserial A51MAMMEA

Is A51MAMME the expected value in all cases? What are we getting on linux?

Ok sorry for the confusion, I switched devices midway through, which was definitely confusing. I have gone back through my posts and fixed them so that the sole device discussed is the one with the serial number A51MAMME. A51MAMME is the expected value in all cases.

linux node-serialport: MLI_scale_A51MAMME
(Note: This is actually the manufacturer + _ + manufacturer description + _ + serial number)
So this isn't exactly the "serial number", but at least it contains the serial number.

registry: A51MAMME

pyserial: A51MAMMEA
(Note there is an extra "A" at the end of the serial number, the same error occurs for other FTDI devices. They all seem to have an extra "A" appended to the end of the serial number. )

So I didn't notice this before, but it looks like windows node-serialport is picking up the serial number in the pnpID. For reference here is the windows node-serialport -f -jsonline printout for the A51MAMME device:

{"comName":"COM23","manufacturer":"FTDI","pnpId":"FTDIBUS\VID_0403+PID_6001+A51MAMMEA\0000","vendorId":"0403","productId":"6001"}

Note the pnpID contains "A51MAMMEA", I am not sure why we are getting an extra "A" character at the end.

It would probably be easy enough to extract the serialNumber from windows registry or pnpID, and then return a "serialNumber" entry in the serialport-list json object. If we wanted the linux "serialNumber" and windows "serialNumber" entries to match, it would probably be best to remove the extra information stored in the linux entry (aka manufacturer, which already exists as a separate entry, and the manufacturer description (perhaps a new entry could be added for this information?)).

[reconbot]

I only have an arduino uno to test with

linux

{
  "comName":"/dev/ttyACM0",
  "pnpId":"usb-Arduino__www.arduino.cc__0043_752303138333518011C1-if00",
  "productId":"0x0043",
  "serialNumber":"Arduino__www.arduino.cc__0043_752303138333518011C1",
  "manufacturer":"Arduino__www.arduino.cc_",
  "vendorId":"0x2341"
}

osx

{
  "comName":"/dev/tty.usbmodem1431",
  "manufacturer":"Arduino (www.arduino.cc)",
  "serialNumber":"752303138333518011C1",
  "locationId":"0x14300000",
  "vendorId":"0x2341",
  "productId":"0x0043"
}

windows

{
  "comName":"COM3",
  "manufacturer":"Microsoft",
  "pnpId":"USB\\VID_2341&PID_0043\\752303138333518011C1",
  "locationId":"Port_#0003.Hub_#0001",
  "vendorId":"2341",
  "productId":"0043"
}

Ideal

{
  "manufacturer":"Arduino (www.arduino.cc)",
  "serialNumber":"752303138333518011C1",  
  "vendorId":"2341",
  "productId":"0043"
}

The locationId and pnpId are not consistant, I don't know what they should be.

osx

{
  "locationId":"14300000",
  "pnpId": undefined
}

windows

{
  "locationId":"Port_#0003.Hub_#0001",
  "pnpId":"USB\\VID_2341&PID_0043\\752303138333518011C1",
}

linux

{
  "locationId": undefined,
  "pnpId":"usb-Arduino__www.arduino.cc__0043_752303138333518011C1-if00"
}

Does the ideal look correct to you? Do you have thoughts on the locationId and pnpId?

[thiago-sylvain]

To fuel the discussion, I am also using a FTDI chip, and facing this problem.

Here is the value of the serialport object on windows:

comName: "COM29"
locationId: undefined
manufacturer: "FTDI"
pnpId: "FTDIBUS\VID_0403+PID_6015+DO008I0CA\0000"
productId: "6015"
serialNumber: undefined
vendorId: "0403"

Here is the equivalent on Linux:

comName: "/dev/ttyUSB0"
manufacturer: "FTDI"
pnpId: "usb-FTDI_FT230X_Basic_UART_DO008I0C-if00-port0"
productId: "0x6015"
serialNumber: "FTDI_FT230X_Basic_UART_DO008I0C"
vendorId: "0x0403"

The expected serial number here for me is DO008I0C.
Yes, Windows sometimes append the 'A' at the end, sometimes not, it was already the case when I was using pyserial so I coped with by using a regexp.

Pyserial seems to face the same difficulties pyserial/pyserial#61.
Libraries based on D2XX driver like https://www.npmjs.com/package/ftdi seems to work ok.

But today I faced a new behavior, while I was testing on Windows, some ports identified this way:

comName: "COM29"
locationId: undefined
manufacturer: "FTDI"
pnpId: "FTDIBUS\VID_0403+PID_6015+7&C0956A8&0&1\0000"
productId: "6015"
serialNumber: undefined
vendorId: "0403"

So here the regexp is pretty useless.
After rebooting windows, the enumeration is done correctly again.
My two cents is that the problem is related to the implementation of a low level windows driver but I don't have the skill to dig into it, so except if someone here has it, I think I am about to drop the idea of relying on the serial number to identify my devices.

@reconbot The ideal looks correct to me. It appears that windows and linux have unique pnpID formats (Ref. https://www.netiq.com/documentation/platespin-migrate-12-2/migrate-user/data/t40xx337skwt.html). I am not sure what the locationID.

@thiago-sylvain what version of Windows are you using?