Questions:
1. What happened to throughput when lots of devices were present? There's only so much airtime, and generally speaking wireless performance craps out when there are lots of devices.
2. Since they're using a normal phone as their base station, how do different phones perform in their environment? Using normal phones mean they can't tune the bluetooth stack behavior.
3. Using the same sets of chipsets for testing is great, but you should use many different chipsets because that's what you see in reality. Also putting them in one place is unrealistic.
4. Do they have a/b firmware with auto fail back on failure? How about signed firmware?
5. How are they going to manage their devices in production? Hospital IT is a combination of lax security for users but strict security for vendors. Will you be able to poke a hole? And the idea of using any phone, while appealing, will probably need to be heavily vetted.
6. Since the devices are two-way, how are you securing the devices against fuzzing etc? BT stacks can have all kids of issues. That's not including the stuff you guys write. Since it's BT, how are you doing client auth? And is data encrypted between the device and base station (ie: the phone with the app)? Where does that key come from?
Blah blah blah. What about provisioning? Remote management?
And 100 devices is probably not be enough. I see at least 20 devices around me right now on BLE, and I'm just at home. In a mall there are probably hundreds at any given spot. In your target environment, who knows?
Agreed, this issue really jumped out at me as well.
The blog illustrates the feature of scanning bluetooth devices around you and pushing data to the cloud when needed, but right now that background scan is really not optimal for both ios and android. Android requires a manual scan process every 15 minutes or so based on background task intervals, and iOS only alerts you to ble scans when you turn on the screen of your phone. Android will cause you to burn battery constantly checking on devices, but iOS will cause you to miss them entirely unless you unlock your phone alot.
Right now we have a simple use case of updating the clocks on our devices that would be a whole lot easier if the devices could simply advertise they need attention after XX hours, and that ran a background service for our app to do it when needed, and avoid the whole periodic scanning.
Putting "live" data into the advertising packet used to be a way for BLE fitness devices to be active in a Group Fitness environment where scanning and connecting to 30+ devices is not feasible. I think that BLE 5 has a better way of doing that now.
But in a typical Linux situation you're at the mercy of the host controller in your PC which can be one of a hundred mystery parts, so the ports enumerate with different IDs between machines. We've had to decipher port numbers by hand every time we deploy on a different system.
Do you know of any abstraction library that can simplify that at all?
Plenty of USB-A ports (of which MacBook Pro owners get exactly zero, because courage, and Tim Cook doesn't have any USB-A devices) — absolute requirement for any embedded development. Powered, so you can run plenty of stuff without additional power supplies. And individual button for switching ports ON/OFF, which is a godsend when you need to reset a device or test a reconnection.