Unable to consistently identify specific cameras with identical model name when triggering a capture

[bkapadia01]

We're using gphoto2 to capture images from 2 camera of the same model and we need to be able to trigger a specific camera each time. This requires us to capture image using the port number but the problem is that sometimes the port number is swapped and so we can reliably ensure the camera we want to capture is the camera in the same order they are listed in on the ports.

We have 2 cameras, top and bottom cameras, and using the KILL -SIGUSR1 "PID" to capture an image, the PID is related to the port number which can alternate sometimes so using the first port/PID can sometimes trigger top camera but after restarting the application the first port/PID might trigger bottom camera.

Is there a way to specify which camera we would like to use to capture aside from camera name or port?

I have assigned an owner to each camera using `--set-config ownername=TopCamera" and "ownername=BottomCamera", is there a way to use these assigned owner names instead or any other methods you'd recommend?

[vepicurean]

This multiple cameras of the same model and being able to identify which camera goes with a USB port is a challenge I've run into before as well.

Any ideas anyone can share on how to use gphoto2 to be able to identify specific individual cameras would help a great deal. I've looked at this problem for a while now and not seeing anything.

If the command gphoto2 --auto-detect also include the serial number for the respective camera, that would probably do it.

Also, another good way would be for ghoto2 --summary to include the summary information for all the cameras found under auto-detect, that would help as well, as the serial number info is in the readout a camera when using summary. But the summary function only lists the summary info for the first camera found.

[msmeissn]

sadly not easy... at lreast associating PIDs to cameras would be tricky.

e.g. having the camera output the owner or serial before starting work and trying to associate that back to PIDs

[ndim]

Theoretically, it should be possible to use a unique USB device serial number (iSerial string descriptor from the USB device descriptor) to distinguish different USB devices with the same (idVendor, idProduct) tuple.

The practical questions, however, are

• do devices even have an iSerial (the value 0 means no)?
• is the string descriptor even different for different individual devices of the same type?

Having individual values in the USB device descriptor can be an additional step in the manufacture a device, so they might have removed that step to save a few cents.

[vepicurean]

Theoretically, it should be possible to use a unique USB device serial number (iSerial string descriptor from the USB device descriptor) to distinguish different USB devices with the same (idVendor, idProduct) tuple.

The practical questions, however, are

• do devices even have an iSerial (the value 0 means no)?
• is the string descriptor even different for different individual devices of the same type?

Having individual values in the USB device descriptor can be an additional step in the manufacture a device, so they might have removed that step to save a few cents.

Thanks for the information. Greatly appreciated. Interesting.

We're trying to keep it simple using the tools available. If we can link the camera serial number to a USB port number (yes, that information will need to be constantly updated as the USB port numbers change), then we would be good to identify each camera individually without too much complex coding (when there is more than one camera of the same model).

[ndim]

I would add support for serial numbers to the libgphoto2_port usb: URL like schema, if there is not already support for that.

If and only if the cameras actually support it, that is.

[ndim]

Well now, do your cameras have an iSerial? To find out, run something like lsusb -v -s 007:023 | grep iSerial for the device /dev/bus/usb/007/023 aka usb:007,023:

[user@host ~]$ lsusb -v -s 002:002 | grep iSerial
Couldn't open device, some information will be missing
  iSerial                 3 0123456789ABCDEF
[user@host ~]$ lsusb -v -s 006:004 | grep iSerial
  iSerial                 0 
can't get debug descriptor: Resource temporarily unavailable
[user@host ~]$ _

The device at 002:002 does have an iSerial value (string redacted, device is a memory card interface controller which came built into a 500€ price range PC from around 2010, so I guess device price point between 20€ and 50€), while the the device at 006:004 does not have an iSerial value (audio device from 2019 in the 200€ price range). I do not have any cameras close by at this time, but those are also USB devices, and all USB devices have a USB device descriptor with an iSerial — the question is whether that iSerial is nonzero.

And the answer to that might be more related to whether or not the chip hardware happens to already have such a string built in such a way that the USB device descriptor can just use it, than it is to the manufacturer suggested retail price. Just examine the devices you have.

[Sija]

I checked Canon 40D and Canon 5D, and both are returning "iSerialNumber" = 0. Command used: ioreg -p IOUSB -l -w 0 on macOS 10.14.6

[ndim]

I checked Canon 40D and Canon 5D, and both are returning "iSerialNumber" = 0. Command used: ioreg -p IOUSB -l -w 0 on macOS 10.14.6

That looks like you're out of luck, at least for Canon cameras.

[vepicurean]

I checked Canon 40D and Canon 5D, and both are returning "iSerialNumber" = 0. Command used: ioreg -p IOUSB -l -w 0 on macOS 10.14.6

That looks like you're out of luck, at least for Canon cameras.

Just confirming that the iserial value using that ioreg -p IOUSB -l -w 0 command was zero on the Canon 5DS R cameras. Thanks for the suggestion. Appreciated.

If there are any other ideas for getting the serial number of the camera that is also associated with a USB port # via gphoto, it would be appreciated. Right now it's random whether the targeted camera (each camera serves a different purpose) gets associated to the process intended, as we can't tell which camera is which just from the USB port number.

[msmeissn]

the PTP level serial number is usually available.

gphoto2 --get-config serialnumber

but it needs a connection to the camera.

[vepicurean]

the PTP level serial number is usually available.

gphoto2 --get-config serialnumber

buit it needs a connection to the camera.

Thanks, we'll look at this gphoto2 --get-config serialnumber command over the next day or two and let you all know what we find out.

We use the best US3 cables money can buy between the computer and the Canon 5DS Rs, so we have that individual connection 1:1 between USB3 port and the individual camera.

[ndim]

Would it make sense to add a different "URI" schema for device selection (besides the old usb:000,000), such as e.g. config:serialnumber:NNNNNNNN to select the device which responds with NNNNNNNN to --get-config serialnumber? This would also allow something like config:ownername:TopCamera and config:ownername:BottomCamera to pick up the idea this issue started with.

The new config: scheme would only work for cameras connected with an autodetectable and iteratable connection type like e.g. USB. Connection methods which are not autodetectable and iteratable like e.g. early 2000s RS232-serial connections cannot take part in this new scheme. For USB connections, this will work well. I cannot say how this would work for Bluetooth or WLAN or other modern non-USB connections, as I do not know the specifics of how they work.

The software would iterate over all devices it can iterate over, do the equivalent of --get-config on each of them, and if the returned value matches, append it to a list. If the list has 0 devices after the iteration, no device found. If the list has 1 device after the iteration, the operation can go ahead on that device. If the list has more than 1 device after the iteration, the operation needs to be aborted.

[ndim]

I have just thought up a possible hack to find out which camera corresponds to which usb:NNN,MMM URI. Unfortunately, I do not have USB connectable cameras available to test this hack, so this is all theoretical.

Those numbers NNN and MMM are (if I remember correctly) the Linux bus number and the device number on that USB bus, i.e. the above example should correspond to the Linux device /dev/bus/usb/NNN/MMM. So if we can influence those numbers in some way, we could discern from the --autodetect output which usb: URI should correspond to which camera.

Bus number (NNN)

If the two cameras can be connected to a different (root?) hub each on a PC (and if those root hubs always have the same bus number), I can distinguish the two cameras by the first number NNN in the usb:NNN,MMM URI.

If the root-hub-and-NNN method of distinguishing does not work (e.g. on a device with only one root hub), there should be a second hack.

Device number (MMM)

As far as I can tell, the Linux kernel and/or the USB host controller gives a new number MMM to every device when it connects, by incrementing the last number it has issued to a device on that bus (probably wrapping around around 128 which is a USB limit).

So if you have two cameras on the same bus NNN but can control the sequence in which they connect to the USB bus (e.g. by controlling the sequence of switching them on), the Camera connected first should have the lower number MMM but close to the other camera's (modulo 128 or 127 or whatever the wraparound does precisely).

Summary

If any of the above actually works, it could serve as a workaround until something like my config: URI schema for device selection is implemented.

[vepicurean]

the PTP level serial number is usually available. gphoto2 --get-config serialnumber buit it needs a connection to the camera.

Thanks, we'll look at this gphoto2 --get-config serialnumber command over the next day or two and let you all know what we find out.

We use the best US3 cables money can buy between the computer and the Canon 5DS Rs, so we have that individual connection 1:1 between USB3 port and the individual camera.

Confirming that we can get the correct serial number from the camera using gphoto2 --get-config serialnumber command

We just have not had to the time to integrate it yet into the code. We'll keep you all updated on how well this works for us.

[vepicurean]

Update.... I will get back to working on this as soon as we find a way to successfully build gphoto2 from source. Right now that gphoto2 build error issue is holding us up on the development activities.

[vepicurean]

Update... we'll work on implementing getting the serial number lookup on the Canon camera body implemented over the next week or so and let everyone know how it works out. Thanks for all the help.

[vepicurean]

Just FYI!

The Canon EOS camera faceplate serial number (which is the serial number most people would want to identify), the gphoto2 command is as follows:

gphoto2 --get-config eosserialnumber

Still working with this. Should have some more information in a few days.