getOpticalZoomFactorSync only works once on M300 with H20T

[benbarkay]

When using:

• A Linux host (Ubuntu 20.04, aarch64, in this case)
• Matrice 300 RTK
• An H20T camera

Any calls to getOpticalZoomFactorSync besides the first call, result in a timeout produced by CameraModule::getInterfaceSync.

It seems that CameraManager::m300LensCbInit manages to obtain the lens data, which causes getOpticalZoomFactor to return the correct result within the first 500ms past initialization of CameraManager.

[dji-dev]

Agent comment from kyle.cai in Zendesk ticket #49952:

Dear developer ,

Thank you for contacting DJI.

Are you using the following API ? ​

Could you please provide the terminal logs of this issue ?

Thank you for your understanding and support, hope you have a nice day.

Best Regards, DJI SDK Support Team
inline-928852043.png

°°°

[benbarkay]

hi Kyle,

Unfortunately, I will no longer have access to the M300 or the HT20 camera for the foreseeable future, so I cannot provide logs.

However:

• The timeout occurs when trying to request lens data -- There is the "Get lens data from cmd request." log as in the picture you show above. This likely means that the callback set-up by CameraManager::m300LensCbInit stopped updating the cached lens info.
• During yesterday's iteration, after creating this issue, I was able to stream lens data to a separate callback in my app using the same Linker call that CameraManager::m300LensCbInit uses.

This suggests to me that OSDK fails to update "lens info", because either:

• Something intentionally stops the stream (I couldn't find anything except for CameraManager's destructor); or
• Something unintentionally stops the stream (will returning OSDK_STAT_SYS_ERR in the callback do it?); or
• The stream works fine and there's an issue with the logic to update lens info (there are no logs to see that anyway).

Sorry that I did not include any logs the first time. Hopefully this information helps you out.