Generator transmisji Android do emulacji danych CGM xDrip+
Specyfikacja techniczna
Generator Broadcast Android do emulacji danych CGM xDrip+
1. Cel projektu
Opracowanie aplikacji Android (Foreground Service), generującej realistyczne dane CGM/glukozy i wysyłającej je przez zgodny z xDrip broadcast:
Intent("com.eveningoutpost.dexdrip.BgEstimate")
Aplikacja jest przeznaczona do:
- testowania backendu Nightscout,
- testowania powiadomień Telegram,
- testowania pipeline'u przetwarzania,
- testowania odbiornika Android,
- demonstracji,
- środowisk CI/staging,
- opracowywania SaaS dla CGM.
2. Główne wymagania
Aplikacja musi:
- działać bez sensora,
- nie wymagać sprzętu BLE,
- działać offline,
- obsługiwać Foreground Service,
- działać w tle,
- przetrwać reboot,
- automatycznie się odzyskiwać,
- obsługiwać Android 10–16,
- obsługiwać zgodność z xDrip+.
3. Format broadcast
Akcja
com.eveningoutpost.dexdrip.BgEstimate
Extras
| Klucz | Typ | Opis |
|---|---|---|
| mgdl | Double | wartość glukozy |
| timestamp | Long | unix timestamp ms |
| direction | String | kierunek trendu |
| noise | Int | poziom szumów |
Przykład broadcast
val intent = Intent(
"com.eveningoutpost.dexdrip.BgEstimate"
)
intent.putExtra("mgdl", 126.0)
intent.putExtra(
"timestamp",
System.currentTimeMillis()
)
intent.putExtra("direction", "Flat")
intent.putExtra("noise", 1)
sendBroadcast(intent)
4. Realistyczny model glukozy
Zamiast generatora losowego użyć silnika krzywej
Generator powinien budować:
- płynne zmiany,
- realistyczne nachylenia,
- realistyczne opóźnienia,
- realistyczną zmienność.
5. Obsługiwane stany
5.1 Normalna glukoza
Zakres:
80–140 mg/dL
Zmiany:
- płynne,
- bez nagłych skoków,
- realistyczny dryf.
5.2 Symulacja posiłku
Wsparcie:
- mały posiłek,
- średni posiłek,
- wysokowęglowodanowy posiłek.
Zachowanie:
Po posiłku:
- wzrost po 10–20 minutach,
- szczyt po 45–90 minutach,
- stopniowy spadek.
Przykład krzywej
100
110
125
145
165
180
170
150
130
115
5.3 Symulacja insuliny
Wsparcie:
- szybka insulina,
- bolus korekcyjny.
Zachowanie:
- opóźniony początek,
- stopniowe zmniejszenie,
- logika zapobiegania hipoglikemii.
Przykład
190
180
165
150
135
120
105
5.4 Symulacja hipoglikemii
Zakres:
40–69 mg/dL
Wsparcie:
- stopniowa hipoglikemia,
- szybka hipoglikemia,
- hipoglikemia nocna.
Wartości kierunku
Wsparcie:
- DoubleUp
- SingleUp
- FortyFiveUp
- Flat
- FortyFiveDown
- SingleDown
- DoubleDown
5.5 Niskie wartości kompresji
Symulacja:
- ostrego fałszywego spadku,
- szumów w odczytach,
- szybkiego powrotu.
Przykład
120
118
85
60
52
48
110
115
5.6 Błędy sensora
Wsparcie:
- tymczasowe nieprawidłowe odczyty,
- niemożliwe wartości,
- luki w znacznikach czasu,
- utknięte wartości.
Typy błędów
Skok błędu
400 mg/dL
Zamrożenie sensora
120
120
120
120
Brak pakietów
Brak broadcastów.
5.7 Symulacja rozgrzewki
Po uruchomieniu:
- 30–120 minut rozgrzewki,
- opcjonalny tryb bez danych,
- opcjonalne niestabilne odczyty.
6. Symulacja utraty pakietów
Wsparcie:
- konfigurowalna stawka utraty pakietów,
- opóźnione pakiety,
- zdublowane pakiety.
Przykłady
Utrata:
co 10. pakiet jest pomijany
Opóźnienie:
pakiet wysyłany z opóźnieniem 30–90 sek
7. Symulacja szumów
Poziomy szumów:
| Wartość | Znaczenie |
|---|---|
| 0 | czysty |
| 1 | niski szum |
| 2 | średni szum |
| 3 | wysoki szum |
8. Foreground Service
Wymagania
Aplikacja musi:
- pokazywać powiadomienie persistent,
- nie być usuwana przez system,
- działać po zablokowaniu ekranu,
- obsługiwać autostart.
9. Wymagania UI
Ekran główny
Powinien wyświetlać:
- aktualną glukozę,
- aktualny trend,
- aktualny tryb,
- aktywną symulację,
- licznik pakietów,
- status broadcastu.
Przyciski
| Przycisk | Działanie |
|---|---|
| Start | uruchomienie |
| Stop | zatrzymanie |
| Meal | symulacja posiłku |
| Insulin | insulina |
| Hypo | hipo |
| Compression | niski poziom kompresji |
| Error | błąd sensora |
10. Ustawienia
Interwał wysyłania
Konfigurowalny:
1–5 minut
Jednostka
Wsparcie:
- mg/dL
- mmol/L
Mnożnik prędkości
Dla przyspieszonej symulacji:
x1
x2
x5
x10
11. Architektura
Zalecany stack
| Komponent | Technologia |
|---|---|
| UI | Jetpack Compose |
| Service | Foreground Service |
| Scheduling | Coroutines |
| Storage | Room |
| DI | Hilt |
| Logging | Timber |
12. Logowanie
Logować:
- wysłane broadcasty,
- wartości glukozy,
- utraty pakietów,
- błędy,
- stan symulacji.
13. Eksport
Wsparcie:
- eksport JSON,
- eksport CSV,
- odtwarzanie sesji.
14. Dodatkowe funkcje (opcjonalne)
Wsparcie MQTT
Publikacja:
glucose/current
HTTP POST
Wysyłanie do backendu:
{
"glucose": 125,
"timestamp": 1234567890,
"direction": "Flat"
}
15. Zgodność
Sprawdzić zgodność z:
- xDrip+
- Nightscout
- słuchaczami Juggluco
- niestandardowym BroadcastReceiver
- AndroidAPS
16. Kryteria gotowości
Projekt uznaje się za gotowy, jeśli:
- broadcasty są odbierane przez xDrip+,
- glukoza jest wyświetlana poprawnie,
- symulacja działa stabilnie,
- wykonanie w tle nie jest zatrzymywane,
- utrata pakietów jest poprawnie symulowana,
- realistyczne krzywe wyglądają wiarygodnie.
Plik z rezultatem
Opinia zleceniodawcy o współpracy z Sergey Naumenko
Generator transmisji Android do emulacji danych CGM xDrip+Bardzo profesjonalnie i szybko. Miło zaskoczony wykonaniem ZT.
Opinia freelancera o współpracy z Andrii Tarasenko
Generator transmisji Android do emulacji danych CGM xDrip+Współpraca z zamawiającym była przyjemna.\nZ plusów:+\n- szybko reaguje na pytania/wyjaśnienia;\n- daje wyjaśnienia dotyczące postawionych zadań;\n- po prostu miła osoba.\n\nZ minusów:-\n- nie zauważyłem nic negatywnego w tej kategorii.\n\nPolecam dla przyszłych wykonawców!
-
Jeśli chodzi o terminy i pieniądze - podstawowa wersja robocza bez rozbudowy w wieczny kombajn będzie kosztować od 65 000 UAH i zajmie około 18 dni roboczych. !!750 UAH tutaj nie wygląda na realny budżet!! - to raczej koszt krótkiej weryfikacji technicznej, a nie aplikacji z Foreground Service, silnikiem krzywych, przywracaniem po restarcie i weryfikacją xDrip+.
Jeśli podejść do tego normalnie, zrobiłbym to etapami - najpierw stabilna usługa i kompatybilne przesyłanie zdarzeń, następnie model krzywych dla posiłków, insuliny, hipoglikemii, niskiego ciśnienia i błędów czujnika, potem utraty pakietów, logi i eksport CSV/JSON. Ważne jest, aby osobno sprawdzić ograniczenia w tle Android 10-16, ponieważ to tam zazwyczaj pojawiają się problemy z taką złożonością, a nie w przyciskach.
Pytania
> Czy MQTT i HTTP POST włączamy w pierwszej wersji, czy zostawiamy jako osobny etap?
> Czy należy testować na konkretnej wersji xDrip+ i AndroidAPS, czy wystarczy testowy BroadcastReceiver plus Nightscout na testowym stanowisku?
Podobne prace Ingello
… > https://business.ingello.com/lita - system medyczny, bliski domenie medtech i stabilności danych
> https://business.ingello.com/rapport - projekt z logiką medyczną i starannym przetwarzaniem danych
> https://business.ingello.com/fractal - przykład automatyzacji, pośrednio bliski łańcuchowi odbioru danych
Główny profil w zakresie rozwoju systemów - https://systems-fl.ingello.com
Nie ma co komplikować - zacząłbym od projektowania formatu zdarzeń i testowego odbiornika, ponieważ jeden dzień na to oszczędza tydzień poprawek później. Siedem razy zmierz - raz wyślij zdarzenie =)
-
196 mamy już praktycznie gotową podstawę pod podobny system generowania testowych zdarzeń, można ją szybko dostosować do Androida, xDrip+ broadcast i waszych scenariuszy CGM, możemy to omówić tutaj, jestem w kontakcie ))
co do budżetu 750 UAH - to prawdopodobnie nie jest realna ocena dla takiego TZa.
roboczy pierwszy etap oceniłbym na 45000 UAH i około 18 dni.
Ma sens robić nie tylko generator losowy, ale oddzielny silnik krzywych - normal, posiłek, insulina, hipoglikemia, kompresja niska, błędy czujnika, utrata pakietów i rozgrzewka.
więc potem można będzie uruchamiać Nightscout, powiadomienia Telegram, pipeline do wchłaniania i odbiornik Android bez ręcznej pracy.
w pierwszym etapie uwzględniłbym
… - Usługę w tle z powiadomieniem persistent i przywracaniem po restarcie
- ekran zarządzania i statusów Jetpack Compose
- realistyczne krzywe CGM, kierunek, szum i licznik pakietów
- ustawienia interwału, jednostek, prędkości symulacji i trybów
- dziennik wysyłek, pominięć, błędów i eksport JSON/CSV
HTTP POST i MQTT lepiej wydzielić jako oddzielny moduł, aby nie wydłużać startu i nie mieszać podstawowej emulacji z integracją serwerową.
no tak, tutaj lepiej iść etapami - wolniej jedziesz, dalej będziesz.
wyjaśnię 2 kwestie
- czy na pierwszym etapie potrzebny jest rzeczywisty test z xDrip+ na urządzeniu, czy wystarczy sprawdzenie przez custom BroadcastReceiver
- replay sessions i HTTP/MQTT są potrzebne w pierwszej wersji, czy można je zostawić na drugim etapie
podobne przypadki Ingello
- https://business.ingello.com/lita - procesy healthtech i logika medyczna
- https://business.ingello.com/rapport - praca z danymi medycznymi i logiką systemową
- https://business.ingello.com/vorfahr - automatyzacja, AI i podejście SaaS do złożonych scenariuszy
główny profil w zakresie rozwoju systemów
https://systems-fl.ingello.com
Aktualne zlecenia dla freelancerów w kategorii Programowanie na Androida
Rozwój aplikacji mobilnejSzukam deweloperów ios/android do tworzenia aplikacji hazardowych. Stos technologiczny: Flutter/Unity/Kotlin/Swift Dużym plusem będzie doświadczenie w pracy z wizualami i projektami Chicken Road/Tower Rush/Plinko, a także użycie takich narzędzi jak WebView, Firebase, AppsFlyer,… Programowanie na Androida, Programowanie na iOS (iPhone i iPad) ∙ 6 dni 14 godzin temu ∙ 33 oferty |
Aplikacja mobilna iOS/Androd
75 PLN
Poszukuję programisty aplikacji mobilnych (iOS i/lub Android) do stworzenia aplikacji treningowej dla osób początkujących i średniozaawansowanych. Aplikacja ma pomagać użytkownikom w planowaniu treningów, monitorowaniu postępów i motywowaniu do regularnej aktywności fizycznej.… Programowanie na Androida, Programowanie na iOS (iPhone i iPad) ∙ 8 dni 17 godzin temu ∙ 20 ofert |