Stress-Testing 100 Bluetooth Beacons (so the Team Can Sleep Well at Night)
Posted3 months agoActive3 months ago
dunkels.comTechstory
calmpositive
Debate
20/100
BluetoothIOTTesting
Key topics
Bluetooth
IOT
Testing
The author describes stress-testing 100 Bluetooth beacons to ensure reliability, sparking discussion on testing methodologies and IoT device robustness.
Snapshot generated from the HN discussion
Discussion Activity
Moderate engagementFirst comment
3d
Peak period
7
72-78h
Avg / period
3.3
Comment distribution13 data points
Loading chart...
Based on 13 loaded comments
Key moments
- 01Story posted
Oct 6, 2025 at 8:40 AM EDT
3 months ago
Step 01 - 02First comment
Oct 9, 2025 at 11:51 AM EDT
3d after posting
Step 02 - 03Peak activity
7 comments in 72-78h
Hottest window of the conversation
Step 03 - 04Latest activity
Oct 10, 2025 at 9:15 AM EDT
3 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45490721Type: storyLast synced: 11/20/2025, 2:43:43 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
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.