RSSI Calibration For Better BLE Proximity
Exploring a potential solution for RSSI issues in my LunchTrak project
After meeting with Dave over lunch, we came up with the idea to "calibrate" the RSSI threshold for the check-in system before the student walks to the exit. The problem with how it is currently set up is that depending on the orientation of the beacon, the RSSI can significantly differ from other beacons, meaning that there is no "perfect" RSSI threshold to check students in. Here's how I imagine this new calibration system:
- The "calibration" scanners come either at the entrance or can be placed behind the real scanners (at least 1-2 meters).
- They will record the maximum average RSSI for any student ID and will report this number to the main scanner. Any filtering techniques will be applicable
- The main scanner will now look for the RSSI threshold set by the calibration scanner
One problem I envision right away is that if someone is walking around the exit (who did not go to the line), the calibration scanner will detect a lower RSSI and allow the main scanner to scan them in. This behavior is a huge issue. I think the best solution to this problem is to have a bare minimum RSSI that the calibration and main sensor must meet, like -70dbm for example.
Randomly, here's my new packet design to handle the calibrator vs extender packet. The "-80" will be replaced with the actual RSSI, and the five digits are the student ID numbers without the "950".
Update (4/23/23): It's been two months and I have procrastinated on writing this article for too long. The calibration kinda works, but it is actually not needed. The people will be very close to the scanner and will likely not block the RSSI too much. Here's one of my first attempts with the calibrator: