Na początku projektu zdecydowaliśmy się zbudować pierwszy prototyp oparty na sprawdzonych i dostępnych komponentach. Wybraliśmy mikrokontroler ESP32 DevKit V1 jako centralny element – zapewniał zarówno dużą moc obliczeniową, jak i komunikację WiFi, co otwierało furtkę do dalszej rozbudowy. Do pomiaru tętna i saturacji wybraliśmy czujnik MAX30102 – niewielki, energooszczędny, szeroko opisywany w literaturze. Działa on na zasadzie refleksyjnej pulsoksymetrii, analizując światło czerwone i podczerwone przechodzące przez tkankę. Na tej podstawie określa SpO₂ i HR, wykorzystując zmiany objętości krwi i różnice w pochłanianiu fal przez hemoglobinę.

Układ zmontowaliśmy na płytce stykowej, co umożliwiło szybką iterację i testy bez potrzeby lutowania. ESP32 komunikował się z czujnikiem i wyświetlaczem LCD 16×2 przez magistralę I²C. W roli interfejsu użytkownika LCD spełniał swoją funkcję – wyświetlając na bieżąco odczyty tętna i saturacji. Dzięki gotowym bibliotekom (DFRobot_MAX30102, LiquidCrystal_I2C) mogliśmy skupić się na logice aplikacyjnej – urządzenie od razu po uruchomieniu prezentowało dane w czytelny sposób: „HR: 75 bpm” oraz „SpO₂: 98%”.

Już pierwsze testy w warunkach domowych przyniosły pozytywne rezultaty. Odczyty były zbliżone do wartości z medycznego pulsoksymetru – różnice rzędu kilku procent uznaliśmy za akceptowalne. Szybko jednak zauważyliśmy, jak kluczowe jest dobre przyleganie czujnika – luźny kontakt skutkował niestabilnymi lub absurdalnymi odczytami (np. SpO₂ 41% przy poruszającym się palcu). Dlatego istotnym usprawnieniem było dodanie komunikatów o błędach – jeśli czujnik nie wykrywał pulsu lub saturacji, po kilku sekundach urządzenie wyświetlało: „Brak sygnału. Sprawdź sensor.”. Dzięki temu ratownik nie zostałby wprowadzony w błąd przypadkowymi danymi, tylko miałby jasną informację, że należy poprawić położenie znacznika.

Kolejne dni spędziliśmy testując urządzenie w różnych warunkach – każdy z członków zespołu pełnił rolę „testowego pacjenta”. Zakładaliśmy czujnik na palec i obserwowaliśmy wpływ ruchu, oświetlenia, ciśnienia kontaktu. Okazało się, że nawet drobne różnice potrafią mocno wpłynąć na jakość sygnału – dzięki temu zaczęliśmy lepiej rozumieć ograniczenia czujników PPG i dostosowaliśmy kod tak, by reagował na błędy dynamicznie. Ograniczyliśmy częstotliwość odświeżania LCD do 1 Hz, dodaliśmy komunikaty kalibracyjne („Zakładanie tagu…”) i rozważyliśmy dalsze ułatwienia UX.

Równolegle rozpoczęliśmy prace nad obudową. Wykorzystując FreeCAD zaprojektowaliśmy dwuczęściową konstrukcję – dolna część mieściła elektronikę i baterię, a górna zatrzaskiwała się na niej. Drukowaliśmy ją na drukarce 3D z PLA, w jasnoniebieskim kolorze. Od spodu zaprojektowaliśmy otwór idealnie pod wymiar czujnika, by zapewnić kontakt ze skórą. Prosty mechanizm zatrzaskowy umożliwiał szybki dostęp do wnętrza. Całość była wystarczająco lekka i kompaktowa, by przypiąć ją do ciała za pomocą opaski. Już pierwszy wydruk spełnił swoją rolę, unieruchamiając czujnik we właściwej pozycji.

Na tym etapie zaczęliśmy myśleć również o ergonomii w stresujących warunkach – jak zamocować tag szybko, pewnie, ale też tak, by nie przeszkadzał pacjentowi. Rozważaliśmy zarówno powierzchnię samoprzylepną (jak plaster), jak i uchwyty na paski czy opaski. Zespół mechaniczny pracował nad kolejną wersją obudowy, bardziej opływową, z miejscem na diodę LED RGB do sygnalizacji kolorami triage.

Podsumowując, pierwszy prototyp powstał w ciągu kilku tygodni, działał stabilnie i mierzył podstawowe parametry z zadowalającą dokładnością. Przetestowaliśmy go w różnych scenariuszach, zaimplementowaliśmy obsługę błędów, przygotowaliśmy pierwszą wersję obudowy i zoptymalizowaliśmy UI. Koszt komponentów nie przekroczył 100 zł, a efekt finalny był dowodem na to, że koncepcja jest realna i skuteczna. W tym etapie skupiliśmy się na solidnych fundamentach technicznych – i je osiągnęliśmy.

Pierwszy prototyp potwierdził, że pomiary działają, ale uwidocznił też ograniczenia. Najważniejszym z nich był lokalny wyświetlacz LCD. Choć spełniał swoją funkcję, zaczęliśmy zadawać sobie pytanie: czy w realnej akcji ratownik ma czas podchodzić do każdego pacjenta i patrzeć na mały ekranik? Odpowiedź była oczywista – nie. Doszliśmy więc do wniosku, że zamiast ekranu, lepszym rozwiązaniem będzie centralna aplikacja – mobilna lub webowa, agregująca dane z wielu urządzeń w jednym miejscu.

Dzięki wbudowanemu WiFi ESP32 mogliśmy wysyłać dane bezprzewodowo do komputera dowodzenia lub nawet smartfona. Pozwoliło to uprościć i zmniejszyć sam tag – zrezygnowaliśmy z wyświetlacza i związanych z nim komponentów. Pozostawiliśmy tylko wielokolorową diodę RGB, która z daleka sygnalizuje status pacjenta zgodnie z klasycznym triage (zielony, żółty, czerwony, czarny). W razie nagłego pogorszenia (np. spadek SpO₂, brak pulsu), tag miga na czerwono – alarmując ratownika nawet z kilku metrów. Tym samym urządzenie nadal działa lokalnie, ale główny interfejs przenosi się do aplikacji.

Równolegle dodaliśmy moduł EKG AD8232, by uniezależnić pomiar tętna od warunków zewnętrznych. Czujniki PPG są wrażliwe na ruch czy perfuzję, natomiast EKG – oparty na elektrodach – daje stabilny sygnał nawet w niesprzyjających warunkach. Wykorzystaliśmy trzy elektrody w układzie Einthovena (RA, LA, RL), podłączone do wejścia analogowego ESP32. Mikrokontroler próbkuje sygnał z częstotliwością ok. 100 Hz i przesyła dane przez port szeregowy do komputera.

Po stronie komputera stworzyliśmy skrypt w Pythonie (matplotlib, numpy, scipy), który wizualizuje przebieg EKG w czasie rzeczywistym i wykrywa charakterystyczne piki QRS – na ich podstawie obliczaliśmy HR. Zastosowaliśmy filtr Butterwortha do eliminacji szumów. Po filtracji uzyskaliśmy przejrzysty i stabilny wykres, który pozwalał nie tylko określić tętno, ale i dostrzec pełen cykl serca – załamki P, QRS, T. Co ważne – wyniki EKG pokrywały się z danymi z czujnika optycznego, co potwierdziło poprawność działania.

Wprowadzenie EKG wymusiło modyfikacje obudowy – usunęliśmy miejsce na ekran, a dodaliśmy gniazdo przewodu elektrod (np. jack 3,5 mm) oraz specjalny otwór boczny. Zachowaliśmy kompaktowość i odporność konstrukcji, a obudowa pozostała dwuczęściowa, zatrzaskiwana lub skręcana. Dioda RGB zyskała klosz-dyfuzor, by sygnał świetlny był widoczny pod większym kątem. Całość planowaliśmy drukować z PET-G lub ABS, materiałów bardziej odpornych na temperaturę, uderzenia czy wilgoć – by nawet upadek nie wykluczył urządzenia z użycia.

Równolegle rozpoczęliśmy przygotowania do pełnej komunikacji bezprzewodowej – choć EKG testowaliśmy jeszcze przewodowo (USB/UART), struktura kodu została dostosowana do wysyłania danych w formacie JSON przez WiFi. ESP32 może działać jako klient TCP/UDP lub lokalny serwer WebSocket. Choć w tym etapie nie zdążyliśmy wdrożyć pełnej sieci, przetestowaliśmy już stabilne połączenia i podstawy protokołu.

W tej fazie przedefiniowaliśmy koncepcję tagu – odczyty trafiają do aplikacji centralnej, a sam tag służy jako autonomiczny węzeł pomiarowy z kolorową sygnalizacją. Pomiar HR odbywa się równolegle optycznie i elektrycznie, co daje większą pewność danych i odporność na zakłócenia.