-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Time to get the amplitude image data from the sensor #76
Comments
This depends heavily on your configuration and the network connection you are using. May I ask how you trigger the device and how you measure the delay? |
we use a gigabit switch to communicate with the camera. we use a software trigger for triggering the camera. we measure the delay from the time of the trigger to the time we read the data in the callback |
Could you also supply the output of |
thanks for the prompt response. Please find the dump below |
Looks like you are using the mode
This is not the mode with the lowest latency. It heavily depends on your scene, maybe you can switch to a mode like |
I did some rough calculations for the exposure modes listed in your camera configuration, and I dare to guess that the 50-100 ms you measured did not use application 1 but application 2, right? To elaborate a little more on what @graugans already said, each "image" taken by the camera consists itself of 4 phases, and the exposure times you configure are those for a single phase. Together with some additional required phases for the whole exposure sequence I can compute the rough overall acquisition time of application 1 to
and the acquisition time of application 2 to
In addition to the exposure itself, you also have to take the time to transfer the data into the CPU into account for the overall acquisition time (the "readout times"). The computation of the distance images is the next time consuming operation on the camera. For application 1 I would refrain from giving an estimate, because I do not know the pure computation time by heart (and also the computation overlaps with the acquisition), but I can catch up later if desired. For application 2 I would give a rough estimate of 40 ms computation time, and in that exposure mode, computation strictly takes place after the acquisition, as the is only a single "image". That means, in that mode alone the camera's acquisition and computation contribute at least 57 ms to the latency you are seeing. Add to that some trigger command processing and result transfer preparation on the camera plus two times the network latency, and you have your measurements explained. |
Closing out stale issues (older than a year). Feel free to reactivate as appropriate. |
It is taking 50-100 ms to get the data from IFM o3d3xx sensor when operated in trigger mode. Is there a way to speed the process of acquiring the data in trigger mode.
The text was updated successfully, but these errors were encountered: