External Triggering of Spectral Instruments

In reference to Spectral Instruments SI-1700 (RVT100) failing to take images with arv-camera-test · Issue #732 · AravisProject/aravis · GitHub,

We have successfully gotten nontriggered camera operations by increasing frame-retention.
However, now we have moved onto support for external electronic frame triggers.
Since it appears that the Leader packet comes in immediately after starting the acquisition (even though the electronic trigger signal has not been received) and then rest of the frame packets come in AFTER the signal is received, our single triggered frame reports a timeout if the time between ARM and TRIGGER exceeds the frame-retention value.
We have reached out to the vendor, and their response is that their camera properly operates with the Pleora eBus Player (also using GigE Vision spec) and we have been able to validate that. Given this fact, they are unwilling to change their implementation to not prematurely send the Leader packet.
It would seem that maybe the best course of action might be to extend the frame-retention value out to an exceptionally large value ONLY in the case of a single, triggered capture (sometimes the cameras stay in ARMED state for several minutes before the electronic trigger signal is fired to begin sensor integration).
Two questions:

  1. Might there be far-reaching consequences to this method? I understand that if subsequent packets are lost, or for some reason never delivered, we may wait for a very long time before the frame times out, but in this case, we are only interested in the ONE image acquired at Triggering time so it may not be a problem since we have a parent thread managing the acquisition which can abort the exposure in case of a detected error (like a long delay following triggering without an image having been acquired).
  2. Is there possibly another way to ask the stream-thread to NOT enforce the frame-retention timeout if the Leader packet is so far the ONLY one received (short of a code change - unless there is an elegant way to add it as an option, in which case i can provide a pull request for review)?

Thank you so much!

Hi Brian,

It is to be expected they won’t change the behaviour of their devices if it is conform to the GigEVision specification, even though I fell to understand what benefit there is to send the leader packet early.

Your second proposal is the best fix. The frame retention timeout start would be triggered by any other packet than the leader, or any other packet of a next frame. I guess this new behaviour could be the default, there is no need for an option. Patch welcome…


PR #746 filed. Thanks!