Android Broadcast Generator для эмуляции xDrip+ CGM данных
33 USDТехническое задание
Android Broadcast Generator для эмуляции xDrip+ CGM данных
1. Цель проекта
Разработать Android-приложение (Foreground Service), генерирующее реалистичные CGM/glucose данные и отправляющее их через xDrip-compatible broadcast:
Intent("com.eveningoutpost.dexdrip.BgEstimate")
Приложение предназначено для:
- тестирования Nightscout backend,
- тестирования Telegram alerts,
- тестирования ingestion pipeline,
- тестирования Android receiver,
- демонстраций,
- CI/staging environments,
- разработки SaaS для CGM.
2. Основные требования
Приложение должно:
- работать без сенсора,
- не требовать BLE hardware,
- работать offline,
- поддерживать Foreground Service,
- работать в фоне,
- переживать reboot,
- автоматически восстанавливаться,
- поддерживать Android 10–16,
- поддерживать xDrip+ совместимость.
3. Broadcast формат
Action
com.eveningoutpost.dexdrip.BgEstimate
Extras
| Key | Type | Описание |
|---|---|---|
| mgdl | Double | glucose value |
| timestamp | Long | unix timestamp ms |
| direction | String | trend direction |
| noise | Int | noise level |
Пример 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. Реалистичная модель glucose
Вместо random generator использовать curve engine
Generator должен строить:
- плавные изменения,
- realistic slopes,
- realistic delays,
- realistic variability.
5. Поддерживаемые состояния
5.1 Normal glucose
Диапазон:
80–140 mg/dL
Изменения:
- плавные,
- без резких скачков,
- realistic drift.
5.2 Meal simulation
Поддержка:
- small meal,
- medium meal,
- high carb meal.
Поведение:
После meal:
- рост через 10–20 минут,
- peak через 45–90 минут,
- постепенное снижение.
Пример curve
100
110
125
145
165
180
170
150
130
115
5.3 Insulin simulation
Поддержка:
- rapid insulin,
- correction bolus.
Поведение:
- delayed onset,
- gradual reduction,
- hypo prevention logic.
Пример
190
180
165
150
135
120
105
5.4 Hypoglycemia simulation
Диапазон:
40–69 mg/dL
Поддержка:
- gradual hypo,
- rapid hypo,
- nocturnal hypo.
Direction values
Поддержка:
- DoubleUp
- SingleUp
- FortyFiveUp
- Flat
- FortyFiveDown
- SingleDown
- DoubleDown
5.5 Compression lows
Симуляция:
- резкого ложного падения,
- noisy readings,
- быстрого восстановления.
Пример
120
118
85
60
52
48
110
115
5.6 Sensor errors
Поддержка:
- temporary invalid readings,
- impossible values,
- timestamp gaps,
- stuck values.
Типы ошибок
Error spike
400 mg/dL
Sensor freeze
120
120
120
120
Missing packets
Отсутствие broadcasts.
5.7 Warmup simulation
После запуска:
- 30–120 минут warmup,
- optional no-data mode,
- optional unstable readings.
6. Packet loss simulation
Поддержка:
- configurable packet drop rate,
- delayed packets,
- duplicated packets.
Примеры
Drop:
каждый 10-й packet пропускается
Delay:
packet отправляется с задержкой 30–90 сек
7. Noise simulation
Noise levels:
| Value | Meaning |
|---|---|
| 0 | clean |
| 1 | low noise |
| 2 | medium noise |
| 3 | high noise |
8. Foreground Service
Требования
Приложение должно:
- показывать persistent notification,
- не выгружаться системой,
- работать после lock screen,
- поддерживать autostart.
9. UI требования
Главный экран
Должен отображать:
- текущий glucose,
- текущий trend,
- текущий mode,
- active simulation,
- packet counter,
- broadcast status.
Кнопки
| Кнопка | Действие |
|---|---|
| Start | запуск |
| Stop | остановка |
| Meal | симуляция еды |
| Insulin | инсулин |
| Hypo | hypo |
| Compression | compression low |
| Error | sensor error |
10. Настройки
Интервал отправки
Настраиваемый:
1–5 минут
Unit
Поддержка:
- mg/dL
- mmol/L
Speed multiplier
Для accelerated simulation:
x1
x2
x5
x10
11. Архитектура
Рекомендуемый stack
| Компонент | Технология |
|---|---|
| UI | Jetpack Compose |
| Service | Foreground Service |
| Scheduling | Coroutines |
| Storage | Room |
| DI | Hilt |
| Logging | Timber |
12. Логирование
Логировать:
- sent broadcasts,
- glucose values,
- packet drops,
- errors,
- simulation state.
13. Экспорт
Поддержка:
- JSON export,
- CSV export,
- replay sessions.
14. Дополнительные функции (optional)
MQTT support
Публикация:
glucose/current
HTTP POST
Отправка на backend:
{
"glucose": 125,
"timestamp": 1234567890,
"direction": "Flat"
}
15. Совместимость
Проверить совместимость с:
- xDrip+
- Nightscout
- Juggluco listeners
- custom BroadcastReceiver
- AndroidAPS
16. Критерии готовности
Проект считается готовым если:
- broadcasts принимаются xDrip+,
- glucose отображается корректно,
- simulation работает стабильно,
- background execution не останавливается,
- packet loss корректно симулируется,
- realistic curves выглядят правдоподобно.
Work results
Client's review of cooperation with Sergey Naumenko
Android Broadcast Generator для эмуляции xDrip+ CGM данныхVery professional and fast. I am pleasantly impressed with the execution of the task.
Freelancer's review of cooperation with Andrii Tarasenko
Android Broadcast Generator для эмуляции xDrip+ CGM данныхI enjoyed collaborating with the client.
Pros:
- responds quickly to questions/clarifications;
- provides explanations regarding the assigned tasks;
- simply a pleasant person.
Cons:
- I didn't notice anything for this category.
I recommend for future performers!
-
Regarding timelines and budget - a basic working version without turning into an eternal combine will be from 65,000 UAH and about 18 working days. !!750 UAH here does not seem like a realistic budget!! - this is more like the cost of a short technical check, rather than an application with Foreground Service, a curve engine, recovery after reboot, and xDrip+ verification.
If we proceed normally, I would do it in stages - first a stable service and compatible event sending, then a curve model for meal, insulin, hypo, compression lows, and sensor errors, then packet loss, logs, and CSV/JSON export. It is important to separately check the background limitations of Android 10-16, because that is usually where such complexity breaks down, not in the buttons.
Questions
> Do we include MQTT and HTTP POST in the first release or leave it as a separate stage?
> Should we test on a specific version of xDrip+ and AndroidAPS, or is a test BroadcastReceiver plus Nightscout on a test stand sufficient?
Similar works by Ingello
… > https://business.ingello.com/lita - a medical system, close in the domain of medtech and data stability
> https://business.ingello.com/rapport - a project with medical logic and careful data processing
> https://business.ingello.com/fractal - an example of automation, indirectly close to the data reception chain
The main profile for system development - https://systems-fl.ingello.com
Let's not complicate things - I would start with designing the event format and a test receiver, because one day on this saves a week of corrections later. Measure seven times - send the event once =)
-
196 We already have a nearly ready foundation for a similar test event generation system, which can be quickly adapted for Android, xDrip+ broadcast, and your CGM scenarios. We can discuss it here; I'm available. ))
Regarding the budget of 750 UAH - this is likely not a workable estimate for such a technical specification. I would estimate the first working phase at around 45,000 UAH and about 18 days.
There is a point in creating not just a random generator, but a separate engine for curves - normal, meal, insulin, hypo, compression low, sensor errors, packet loss, and warmup. This way, we can run Nightscout, Telegram alerts, ingestion pipeline, and Android receiver without manual hassle.
In the first phase, I would include:
- Foreground Service with persistent notification and recovery after reboot
- Jetpack Compose control and status screen
… - Realistic CGM curves, direction, noise, and packet counter
- Settings for interval, units, simulation speed, and modes
- Log of submissions, skips, errors, and JSON/CSV export
HTTP POST and MQTT should be separated into a distinct module to avoid stretching the start and mixing basic emulation with server integration. Yes, it’s better to go step by step - slow and steady wins the race.
I would like to clarify two points:
- Is a real test with xDrip+ on the device necessary in the first phase, or is checking through a custom BroadcastReceiver sufficient?
- Are replay sessions and HTTP/MQTT needed in the first version, or can they be left for the second phase?
Similar cases from Ingello:
- https://business.ingello.com/lita - healthtech processes and medical logic
- https://business.ingello.com/rapport - working with medical data and system logic
- https://business.ingello.com/vorfahr - automation, AI, and SaaS approach to complex scenarios
Main profile for system development:
https://systems-fl.ingello.com
Current freelance projects in the category App Development for Android
Kotlin apk Update 3 requests
22 USD
There is a project in Kotlin, a small mobile application that needs fixing. There are 3 endpoints that need to be corrected, including the processing. Please provide the time for updating and building the APK for testing, as well as the cost. Hybrid Mobile Apps, App Development for Android ∙ 1 day 20 hours back ∙ 15 proposals |
Development of a mobile applicationLooking for iOS/Android developers to create gambling applications. Stack: Flutter/Unity/Kotlin/Swift Experience with visuals and designs of Chicken Road/Tower Rush/Plinko, as well as using tools like WebView, Firebase, AppsFlyer, various SDKs. App Development for Android, Apps for iOS (iPhone and iPad) ∙ 8 days 15 hours back ∙ 34 proposals |
Mobile application iOS/Android
20 USD
I am looking for a mobile application developer (iOS and/or Android) to create a training application for beginners and intermediate users. The application should help users with planning workouts, monitoring progress, and motivating them to engage in regular physical activity.… App Development for Android, Apps for iOS (iPhone and iPad) ∙ 10 days 18 hours back ∙ 21 proposals |