> I am sure is not a fundamental but is the reality for the currently available chipsets.
It is pretty fundamental. Ant has an inverted master/slave (or whatever we're calling it nowdays) relationship. In Ant, the sensor determines the timing, and can broadcast to many receivers. In Bluetooth, the central device (phone) determines the timing, and each sensor connects to one central with a one-to-one connection.
There are ways around this limitation of BLE:
1. A few bytes of data can be stuffed in BLE advertising, so the sensor can communicate without a connection in the Ant style. To my knowledge, none of the Ant+-replacing profiles support this.
2. The sensor can basically run multiple instances of bluetooth stack at the same time to connect to multiple central devices. This basically doubles the resource usage, and good luck determining if your sensor supports this without trying it.
#2 appears to be the path forward. A few sensors support it already, and the next generation of radio SOCs will make the resource requirements less onerous.
It is pretty fundamental. Ant has an inverted master/slave (or whatever we're calling it nowdays) relationship. In Ant, the sensor determines the timing, and can broadcast to many receivers. In Bluetooth, the central device (phone) determines the timing, and each sensor connects to one central with a one-to-one connection.
There are ways around this limitation of BLE:
1. A few bytes of data can be stuffed in BLE advertising, so the sensor can communicate without a connection in the Ant style. To my knowledge, none of the Ant+-replacing profiles support this.
2. The sensor can basically run multiple instances of bluetooth stack at the same time to connect to multiple central devices. This basically doubles the resource usage, and good luck determining if your sensor supports this without trying it.
#2 appears to be the path forward. A few sensors support it already, and the next generation of radio SOCs will make the resource requirements less onerous.