What strategy applied when a camera disconnection?

Hi everybody,

I use a USB3 camera.
I want to detect disconnecting the camera during the acquisition of stream.
Is there a trigger of loss of connection?
If yes, how implemented this?

Best wishes and thanks for your help,
Guillaume

Hi @gsFra

Currently there is no such mechanism for python. However it will be there with our next release which is coming very soon.

1 Like

Hi Andreas,

Thank you for this information. I’m in a hurry to discover the new version.
Do you have a release date of this new version?

I have this version :

cvb.wrapper_version()
‘CVBpy-v0.900.288.build-288.rev-2980+ Release gcc54 @ ubu1604-aarch64 & CVB+±v1.0.0.build-238.rev-2980+ & CVB-v13.00.000’

What is a newer version?

Hi @gsFra,

sorry for the delay. We now have a development version where this feature has been tested successfully. Please contact our support (support@stemmer-imaging.de) if you are interested in early access.

1 Like

Hi, any news about disconnection handling? I have found register_connection_state_changed_event(), that is fired when camera is disconnected and reconnected but I cannot getexact state of it. How can we know the conection state, is it connected or is it disconnected and what has changed when event was fired.

Hi @augas111,

you can set a flag when you open the camera for the first time which can be set to connected.
In the connection_state_changed event, just toggle the flag status. The you always know the current camera state.

Thanks, I think it is quite unreliable, but if there is no any way, we will try to use it. I see that this event returns cvb.VinDevice object, is there any way to check any parameter in this object to know if camera is connected or disconected. vin_connection_information does not give me any info i guess, because it is same when camera connects and disconnects.

It is reliable, but not an instant change. Since we use UDP for bandwidth reasons, we need to check the camera manually. This is not done with an interrupt which would be on a lower driver level (and therefore cannot block for too long) but instead the camera connection is tested periodically and if a timeout occurs, the event is fired. If we were to implement it as an interrupt, we would need to poll the camera quite often. This would slow down all other processes, so we would need to sleep inbetween polling, which would lead to a similar delay like the one with the connection_state_changed_event. When the camera could not be polled any more, we still would need to call a change event in which you would need to react to the new camera state, so this is as good as it gets.

Maybe if you could tell us your use case we can think of a different solution which would be a better fit for this case.