Fortschrittliches Sturz-Erkennungssystem mit Arduino, Windows IoT & Azure Cloud

Komponenten & Materialien

Arduino UNO	×1
HC-06 Bluetooth-Modul	×1
Adafruit ADXL345 3-Achsen-Beschleunigungssensor	×1
Jumper-Wires (m/m, m/w)	×1 Satz
Mini-Steckbrett	×1
Lumia 1520 / Windows 10 Mobile Gerät	×1
ORICO Bluetooth USB-Dongle (für Raspberry Pi / IoT-Geräte ohne BT)	×1

Software & Cloud-Dienste

• Microsoft Windows 10 IoT Core
• Microsoft Azure (Storage Table)
• Microsoft Visual Studio 2015+
• Arduino IDE

Projektbeschreibung

Ein wearables Sturz-Erkennungssystem für Senioren. Ein ADXL345-Beschleunigungssensor am Körper erfasst Bewegungsdaten, der Arduino sendet sie via Bluetooth (HC-06) an ein Windows 10 Gerät (Phone, Raspberry Pi, PC). Dort läuft ein UWP-App, die Stürze per Algorithmus erkennt, Daten in Azure Table Storage speichert und eine Client-App zur Visualisierung bereitstellt.

Systemarchitektur

1. Sensor-Node (Arduino + ADXL345 + HC-06): Liest 3-Achsen-Daten (I2C), formatiert als String x=...,y=...,z=...,, sendet @9600 Baud via Bluetooth SPP.
2. Edge-Gerät (Windows 10): UWP-App GenericBluetoothSerialUWApp empfängt Daten, führt Fall-Detection & Haltungs-Erkennung durch, speichert lokal & in Azure.
3. Cloud (Azure Storage Table): Tabelle AccelerometerTable mit PartitionKey/RowKey, Speicherung aller Rohdaten & Erkennungs-Events.
4. Client-App (UWP): FallDetectionClient liest Azure-Daten, zeigt Status, Historie, Alarme.

Sturz-Erkennungs-Algorithmus

Basiert auf Bharadwaj Sreenivasan – Fall-detection-in-Android. Zwei Module:

1. Haltungs-Erkennung (Posture Recognition)

• Eingabe: x, y, z Rohwerte
• L2-Norm: mag = sqrt(x²+y²+z²)
• Schwellenwert auf Y-Achse → Orientierung (stehend/sitzend)
• Variationsrate von mag relativ zu 9,81 m/s² → Gehen vs. Zustandsübergang
• Klassifikation: Sitzen, Stehen, Gehen

2. Sturz-Erkennung (Fall Detection)

• Sucht charakteristisches Muster in L2-Norm: Freifall (≈0g) → Impact (>2g Differenz Min/Max)
• Wenn Differenz aufeinanderfolgender Min/Max > 2g → Sturz-Kandidat
• Endgültige Entscheidung: Kombiniert Haltung + Sturz-Muster (siehe Tabelle im Artikel)
• Falschalarm-Unterdrückung: Wenn Haltung "Gehen" → Sturz verwerfen

Hardware-Aufbau

ADXL345 an Arduino (I2C)

• VCC → 3,3V (nicht 5V!)
• CS → 3,3V (wählt I2C-Modus)
• SDA → A4, SCL → A5
• GND → GND

HC-06 Bluetooth an Arduino

• VCC → 5V, GND → GND
• TX (BT) → RX (Arduino Pin 0)
• RX (BT) → TX (Arduino Pin 1) – Wichtig: Zum Flashen TX/RX abziehen!

Software-Deployment

Arduino Sketch (ADXL345_HC06.ino)

Initialisiert ADXL345 (±16g, 13-bit), liest Register 0x32–0x37, berechnet g-Werte, sendet formatierten String via Serial (Bluetooth).

UWP Bluetooth App (GenericBluetoothSerialUWApp)

• GitHub: Repository
• In MainPage.xaml.cs: Azure Storage Account Name & Key eintragen
• Pairing: HC-06 (Code 1234) in Windows Bluetooth-Einstellungen koppeln
• App starten → HC-06 auswählen → "Start Recv" → "Process Data" → "Upload Data"

Azure Storage einrichten

1. Azure Portal → Storage Account erstellen (Quick Create)
2. Access Keys kopieren (Name + Key)
3. Azure Storage Explorer → Tabelle AccelerometerTable anlegen

Client App (FallDetectionClient)

• GitHub: Repository
• In StorageSensor.cs: Account Name & Key eintragen
• Läuft auf PC, Mobile, IoT Core – zeigt Echtzeit-Status & Historie

Voraussetzungen & Hinweise

• Windows 10 + Visual Studio 2015+ Setup: 2–3 Std. (meist unbeaufsichtigt)
• Für Raspberry Pi 2 / MBM: Bluetooth-Dongle (z. B. ORICO BTA-403) nötig, Pairing via SSH & Commandline-Tool
• DragonBoard 410c hat onboard Bluetooth
• Standard-Pairing-Code HC-06: 1234, Baud: 9600
• Upload-Intervall: Standard 3 Sekunden (in AzureButton_Click anpassbar)

Schaltpläne (Fritzing)

• Komplett: Complete Schematic.fzz
• ADXL345: ADXL345.fzz
• HC-06: hc-06.fzz

Fazit

Ein vollständiges IoT-Gesundheitssystem vom Sensor bis zur Cloud. Zeigt die Stärke von Windows 10 IoT Core & Azure für medizinische Wearables. Der Algorithmus ist wissenschaftlich fundiert, die Hardware kostengünstig. Herausforderung: Bluetooth-Reichweite & Pairing auf IoT-Geräten. Für Produktion: BLE (Nordic/ESP32) statt HC-06, direkter Cloud-Upload (MQTT/HTTPS) ohne Gateway-Gerät.