iOS SDK v1.9.2, X4.
In the README, "Send Heartbeat Packets to the Camera" sits inside Connection
Module directly after "Connect the Camera via Bluetooth", so it reads as
something a Bluetooth integration has to do. The header says otherwise:
/*!
* Call this method as soon as Socket connection has be connected
*
* availability(ONE X, Go)
*/
- (void)sendHeartbeatsWithOptions:(nullable INSHeartbeatsSenderOptions *)options;
Your own Bluetooth sample matches the header rather than the docs — it starts
heartbeats only when usb(), external() or socket() reaches .connected,
and BluetoothViewController never sends one.
The section is easy to act on wrongly because it names symptoms a BLE
integration will actually be seeing ("interrupted previews or invalid
commands", "the camera will actively disconnect"). We sent
sendHeartbeatsWithOptions: on the Bluetooth command manager for weeks. It's
accepted there — INSAllBluetoothCommands inherits it — so it compiles, runs,
and silently does nothing, while we chased a link that drops ~59s after
connect as if it were a heartbeat problem.
Could the heading say Wi-Fi/USB, or move under the Wi-Fi section? And if
something is meant to keep a Bluetooth link alive, it'd be worth saying what.
Your Bluetooth sample polls getCurrentCaptureStatusWithCompletion: every 5s
in captureStatusForever(), which is marked availability(ONE bluetooth, ONE X) — if that's the intended answer, that isn't obvious from the docs.
iOS SDK v1.9.2, X4.
In the README, "Send Heartbeat Packets to the Camera" sits inside Connection
Module directly after "Connect the Camera via Bluetooth", so it reads as
something a Bluetooth integration has to do. The header says otherwise:
Your own Bluetooth sample matches the header rather than the docs — it starts
heartbeats only when
usb(),external()orsocket()reaches.connected,and
BluetoothViewControllernever sends one.The section is easy to act on wrongly because it names symptoms a BLE
integration will actually be seeing ("interrupted previews or invalid
commands", "the camera will actively disconnect"). We sent
sendHeartbeatsWithOptions:on the Bluetooth command manager for weeks. It'saccepted there —
INSAllBluetoothCommandsinherits it — so it compiles, runs,and silently does nothing, while we chased a link that drops ~59s after
connect as if it were a heartbeat problem.
Could the heading say Wi-Fi/USB, or move under the Wi-Fi section? And if
something is meant to keep a Bluetooth link alive, it'd be worth saying what.
Your Bluetooth sample polls
getCurrentCaptureStatusWithCompletion:every 5sin
captureStatusForever(), which is markedavailability(ONE bluetooth, ONE X)— if that's the intended answer, that isn't obvious from the docs.