Hi Luiz and Jamie, >> The only reason is: very high expectations of battery life. I recall >> we played with the slave latency in the past, but we will reevaluate >> and see if it's a feasible option. Thanks for the suggestion. I found another reason why the slave latency doesn't fully solve the problem. The peripheral is not advertising all the time (only on a key-press to save battery). Thus, a large slave latency doesn't help when (re-)connecting to the central (e.g. in a cold boot or reboot) point at which we also expect the first notification latency to be low. In fact, unless I can get to deliver the notification before BlueZ does its post-connection operations (MTU exchange, CCCD write etc ...) , a large slave latency will probably make things worse. Which leads me to the question below ... > We do > however only reload the device attributes once connecting, to avoid > heavy io at startup, so if you are restarting bluetoothd it won't > restore the objects right away. This reflects what I see. Then isn't StartNotify() racy when connecting to bonded peripherals for the first time after bluetoothd starts? More specifically, won't the D-Bus API miss notifications when: 1. We have a characteristic in a bonded peripheral for which notifications when enabled in the CCCD in a prior connection to the central (BlueZ) 2. Notifications are sent form the peripheral after the connection is established (without waiting for a CCCD write, which should be acceptable if the peripheral is bonded) 2. It's the first connection to the peripheral since bluetoothd started -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
