Skip to content

Conversation

@marionbarker
Copy link

@marionbarker marionbarker commented Dec 4, 2025

Purpose

Make the rPi DASH simulator more realistic.

  • Noticed that the response of the simulator to a fault does not set all delivery to false
  • While testing, noticed another pod characteristic not reproduced in the simulator and updated that too
    • Transition the PodProgress to 9 when reservoir is <= 50 U

Method

  • Fix the logic to set response byte 4 to 0 in pkg/response/detailedstatusresponse.go when fault is detected.
  • Reorganized pkg/response/detailedstatusresponse.go for clarity
  • Updated pkg/pod/pod.go PodProgress value based on Reservoir value

Test

Before this modification, whatever delivery state the rPi was in was left unchanged when pod fault was detected.
With this modification, the delivery state is suspended:

  pod_progress =	13
  extended_bolus_active =	False
  immediate_bolus_active =	False
  temp_basal_active =	False
  basal_active =	False

The Loop app properly indicates the pod as suspended at the time the pod fault is detected (although this does not show up in the Event History until after the pod is deactivated).

@marionbarker marionbarker requested review from itsmojo and ps2 December 4, 2025 07:01
@itsmojo
Copy link

itsmojo commented Dec 4, 2025

I'd suggest changing the comment on line 52 to something like "a faulted pod is always suspended", but otherwise LGTM

@marionbarker
Copy link
Author

marionbarker commented Dec 4, 2025

In response to the comment request from @itsmojo, I reorganized the code in addition to updating comments.

  • The default hex string contains the correct pod progress value for a fault (13) with the correct delivery nibble for a suspended pod (0d0000)
  • The code goes through the response bytes in order making suitable updates depending on the fault state and the pod state
  • For testing - the 0x0202 response is triggered from a pod fault or Pod Diagnostics, Read Pod Status

I believe this version is easier to understand.

@marionbarker
Copy link
Author

Test

For each test below, copy the full hex string returned by the rPi and then indicate key features in that string using the OmniLoopMessageParser python parser.

The only test that failed is one that also failed for the main branch.

Test: Pod Diagnostics, Read Pod Status - returns 0x0202 response

Nominal Scheduled Basal

✅ nominal state - scheduled basal

hx='174681c22818021602080100000e003e00000003ff0008000000000000000000'
  msgType =	0x0202
  msgMeaning =	DetailedStatus
  pod_progress =	8
  basal_active =	True

Nominal Scheduled Basal with Bolus in progress

✅ nominal state - scheduled basal and bolus in progress

hx='174681c20018021602080500220b006600000003ff0009000000000000000000'
  msgType =	0x0202
  msgMeaning =	DetailedStatus
  pod_progress =	8
  extended_bolus_active =	False
  immediate_bolus_active =	True
  temp_basal_active =	False
  basal_active =	True
  pulses_not_delivered =	34
  insulin_not_delivered =	1.7

Nominal Temporary Basal

✅ nominal state - temporary basal

hx='174681c334180216020802000004003e00000003ff0015000000000000000000'
  msgType =	0x0202
  msgMeaning =	DetailedStatus
  temp_basal_active =	True

Nominal Temporary Basal with Reservoir < 50 U

Note - after artificially updating reservoir with the front end
and sending a bolus command, the pod progress still did not update to 9 as expected

repeat this test using main branch - it appears this is an existing flaw in the simulator code.

❌ nominal state - temporary basal - expect pod progress of 9

hx='174681c308180216020802000004003e00000003c01130000000000000000000'
  msgType =	0x0202
  msgMeaning =	DetailedStatus
  pod_progress =	8
  temp_basal_active =	True

Test: Pod Fault

✅ fault - scheduled basal and bolus in progress at time of fault

hx='174681c21c180216020d00001004007a1c000d03ff000d000018000000000000'
  msgType =	0x0202
  msgMeaning =	FaultEvent
  pod_progress =	13
  extended_bolus_active =	False
  immediate_bolus_active =	False
  temp_basal_active =	False
  basal_active =	False
  pulses_not_delivered =	16
  insulin_not_delivered =	0.8

  logged_fault =	0x1c
  decimal_fault_string =	028

  byte_V =	24
    16 (because it was bolusing) + 8 (previous state) = 24

@marionbarker
Copy link
Author

Update

The most recent commit updates the state value for PodProgress when reservoir is <= 1000 pulses (50 U).

Test

Repeat the tests with reservoir going from 51 to 50 U and below.

  • The hex strings for 0x1d and 0x0202 both report PodProgress of 9 for this case
  • The FrontEnd display reports PodProgress of 9 for this case

Test: Pod Diagnostics, Read Pod Status - returns 0x0202 response

Nominal Temporary Basal with Reservoir < 50 U

✅ nominal state - temporary basal - expect pod progress of 9

hx='174681c30018021602090200000a005400000003e6000b000000000000000000'
msgType = 0x0202
msgMeaning = DetailedStatus
pod_progress = 9
temp_basal_active = True

Test: Pod Fault

Issue pod fault while bolus is in progress

Start a 2 U bolus, Issue out of insulin fault during the bolus
✅ Expected result acheived

hx='174681c310180216020d00001601007c18000e03be000e000019000000000000'
  msgType =	0x0202
  msgMeaning =	FaultEvent

  pod_progress =	13
  extended_bolus_active =	False
  immediate_bolus_active =	False
  temp_basal_active =	False
  basal_active =	False

  pulses_not_delivered =	22
  insulin_not_delivered =	1.1

  logged_fault =	0x18
  decimal_fault_string =	024

  reservoir =	47.9
  byte_V =	25
    16 (because it was bolusing) + 9 (previous PodProgress state) = 25

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants