USB description and serial_number for ihr320

[ddkohler]

pg4code

Under win 10, this does not work:

self.description = self._dev.product
self.serial = self._dev.serial_number

Why is it important to get this information?

[kameyer226]

The serial is probably the best way to determine the proper spectrometer is associated with that daemon, as cables can be crossed, and we can have multiple spectrometers hooked to the same instrument. I am in favor of retaining that one. Description is just a label related to it, so it isn't so necessary

[ksunden]

https://gitlab.com/yaq/yaqd-horiba/-/issues/8

This was migrated from over here, but missing my replies:

The upshot is it is not super important (functionally), but it helps to see that the USB data is being read correctly and give confidence the rest will work.

A few things could be happening here.

For reference, I do run this on windows 10, but there are some sneaky details that really should be documented but aren't because my own lab is the only one I knew was running this and I simply didn't take the time to do so...

The lines we are talking about are here:

https://gitlab.com/yaq/yaqd-horiba/-/blob/main/yaqd_horiba/_horiba_mono.py#L54-L57

One important detail that I could have sworn I at least put in the readme, but just looked and it wasn't there (I'll update it shortly).... This program does not use the manufacturer provided drivers for the device. Instead it uses libusb. I use https://zadig.akeo.ie/ to override the driver to WinUSB. (This has the advantage of being able to be rolled back to the manufacturer drivers if needed)

(For some historical info, we had a control layer for our MicroHR that was a generated python file wrapping the horiba DLL, but that did not work on Windows 10, so I ended up watching USB packets using Wireshark to figure out how to communicate with the device... The upside is that this implementation works completely cross platform, including Linux and (probably, though never actually tried) MacOS)

Additionally we do not at this time handle calibration, so all calibration must be done using the manufacturer program (and thus drivers) and must not use software offsets (write any and all offsets to firmware where it will persist).

Lastly, you can see the comment in the lines that I linked which tells the device what language it should use... this is because by default it wasn't set for my device... that langid worked for my device, but it is possible that versions of the device sold to e.g. different countries need a different langid... may be worth looking into.

So, going forward, if langid is what solves it, I'm happy to add a config for that value

If drivers solve it, then its a documentation problem (which is needed regardless)

If all else fails, we can try/except those lines and see if the rest of functionality works

[ksunden]

At present, we do not actually have a way to specify which horiba mono you wish to talk to if there are multiple monos in a single system...

That is not to say it can't be made to, just wasn't a requirement at initial implementation time.

The serial is there as info because we make it available as a standard.

I am personally all for implementing mechanisms of looking up hardware by serial number as an alternative to providing more transient identifiers like com ports. I would not want to do it at the expense of reading via com port/other identifiers but as an option to better specify a particular piece of hardware in a more stable system, I think it is a fine addition.

See https://github.com/yaq-project/yaqd-seabreeze/blob/9536b432012837d1c05ba11b94fd1a126d73b1ba/yaqd_seabreeze/_seabreeze.py#L14 for one such example of lookup by serial number if given