Pretty basic fluff piece. More detail would have been nice. This is a blog post that's like "look, we test but have no idea what we're doing."
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?
One thing about bluetooth and phones that I really wish that apple/google/bluetooth group could resolve is a way for a device to advertise that it needs attention and then bubble that up to the nearest phone that is registered for that Service UUID.
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.
I haven't touched BLE in a while, so maybe I don't understand exactly what you're looking for. But I think it can be done by having the devices change their advertising data to indicate that they need service. The background service could listen (passively, no scan needed) to advertising data and only after it sees that a device needs to be updated, connect to it and do the update.
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.
Yep, the advertising packets can be used for things like this. And frequently are in IoT settings. Typically by using the AD type Manufacturer Specific (0xFF). BLE 5.x makes it possible to have many more bytes of advertisement data, including longer packets and chains of packets. Otherwise the mechanisms stayed the same as in 4.x. Which is good, as BLE 4.x only hardware/software is still around...
Indeed the Adam Dunkels, poor guy, trying to have IoT take off for 25 years and they just keep making the hardware bigger obsoleting his previous genius.
Question for author: I've used those 16-port USB hubs in some projects and it's really a nice thing to be able to address a device on a particular position in that hub.
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?
There is topological naming available about USB ports from the Linux kernel. So one can find what device was connected to which hubs, and which root hub that hub was on, etc.
See lsusb -t, and the device paths exposed in udev. Old blogpost of mine about it:
https://www.jonnor.com/tag/usb/
Incidentally, these powered USB hubs are pure gold if you do any embedded development.
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.
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.