Hey Chris,
We are still unsure what is causing the bluetooth disconnection issues. Until then, would it be possible to add in a behavior that stops the task when a Bluetooth firmata IO device disconnects; constantly attempts to reconnect (e.g. with exponential backoff); and if successfully reconnects, resumes the task from where it was?
It would be useful if these events threw warnings/errors messages on the client console, and if these events were loggable in the .mwk2 file.
Hi Michael,
Until then, would it be possible to add in a behavior that stops the task when a Bluetooth firmata IO device disconnects; constantly attempts to reconnect (e.g. with exponential backoff); and if successfully reconnects, resumes the task from where it was?
I’ve added two new parameters, connected and reconnect_interval, which enable this behavior.
connected should be set to the name of a variable. The variable will be set to true when the device is connected, false when it disconnects. By monitoring the value of the variable (e.g. at the beginning of each trial or via attached actions), your experiment can take appropriate action (e.g. pause or resume the experiment) when the connection state changes.
It would be useful if these events threw warnings/errors messages on the client console, and if these events were loggable in the .mwk2 file.
The device does log messages upon disconnection and reconnection, and these messages (like all MWorks messages) will be saved in the event file. Also, the value of the connected variable (like all variables) will be stored in the event file.
I can update your iPad(s) whenever you like.
Cheers,
Chris