HN user

markrages

945 karma
Posts5
Comments317
View on HN

The statistical likelihood is that other civilisations will arise. There will one day be lemon-soaked paper napkins.

‘Till then, there will be a short delay. Please return to your seats.

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.

In the 90s I worked for a company in Kansas City designing pagers. We rented space underground for RF testing. There are no radio signals in the caves, at least back then. I'm sure that's different now, especially with manufacturing happening there. (Our cave was closer to downtown and was mostly used for warehousing.)

For problem with mechanical interference, the old school trick was to stack a few DIP sockets together and plug into those. These would space the adapter up off of the reader. (We used to use extra sockets to save wear on the chip pins during the program/burn/crash/debug cycle.)