
I have therefore had to resort back to a pad and paper with Evernote document scanning for the lost notes. I assume that Wacom have failed to implment any post-transfer success or integrity checks. Unsynced notes are permanently lost in contradiction to Wacom's assertion that they will be stored until they are successfully synced. I get at best 1 page in 3 successfully syncing, and often losing an entire day's notes. Note that even with location services turned on randomisation is still used for beacons as required by the specification and Spark syncing is thus proving unreliable.
#Bamboo spark app for mac update#
It may well require both a Spark firmware update and an app update to resolve this issue. There is a good plain language explanation of this process on the Bluetooth SIG blog.Įssentially the problem appears to be caused by flaws in Wacom's implementation that does not account for persistent connections with LE privacy. The application and device code must be specifically written to allow persistent connections as the MAC addresses change. Instead there is an application level pairing. With BLE devices which typically transmit only small amounts of data (think fitness trackers) there is no OS level pairing process in the way there is with mice, keyboiards, headsets and the like.

That is why pairing needs to be done individally within apps (same on iOS).
#Bamboo spark app for mac android#
As far as I understand a direct pairing of Bamboo Spark with Android devices is not possible, because there is no BT profile for such an input device - it doesn't operate as mouse, but is sending vector data and there is no system driver/handling for that. Wacom1 wrote:Thanks for your explanations. If the Spark were properly paired with the Android device (using the Bluetooth pairing settings) this would not be an issue, but that is not how it appears to have been designed. If the Spark is expecting a beacon from the Android device using a consistent MAC address that might explain the issue. If the Inkspace App to scan for the Spark then the Spark will always see a different MAC address each time. There is some expplnation of this on the Android Developer site. Indeed the MAC randomisation is typically built into the BLE chipset and is not actually done by the OS, which just turns it on or off. Thuis is why it's tied to the Location Services service, and is not a bug but rather a correct implementation of the standard.

This is implemented in order to maintain some privacy from third parties trying to track you using BLE or WiFi beacons from your device, and is perfectly normal.

Android uses MAC address randomisation as specified in the Bluetooth LE standard when scanning for devices.
