Balancerator: app requirements and timing conflict

app: angle view, dated fall log, notification action
1 sec in requirements vs 3 sec in command table. also ±50° trigger vs model trigger... pick one version before implementing the scheduler

transport requirement: the mobile-app document specifies standard/classic Bluetooth, not BLE. The message format is application-defined. The opening requirements ask for an inclination display updated every second, a dated fall log, and an emergency-contact action when inclination crosses ±50°.

optional views: falls per day/month and average inclination over a month. The later protocol revision keeps the fall count locally in the app.

Balancerator Monitor home screen.

Trends screen and update controls.

important distinction: the ±50° app threshold is a draft detection/notification requirement, not a tested safe control limit. The later command table uses an AI-model “unbalanced” result to trigger command 3, so the trigger logic also needs a version decision.

• review questions: reconcile the requested 1-second display update with the table's 3-second angle polling; confirm the actual Bluetooth module rather than assuming compatibility with the earlier Bluefruit LE link. The hardware address is intentionally omitted from the public note.

Monthly fall-count chart in the app.

App and Bluetooth control flow.