Use alternate type 7 getStatus call as per DASH PDM

[itsmojo]

• Add new PodCommsSessions.getStatus parameter to specify noSeqGetStatus
• Use new getStatus for post-connect, resuming setup and standalone getStatus
• Update PodCommsSessions.send to handle alternative noSeqStatus msg # handling
• Rename type 7 PodInfoRequestSubType to noSeqStatus for better clarity

[itsmojo]

The DASH PDM nearly always uses the new type 7 getStatus call for its getStatus calls
instead of the type 0. The type 7 request is unique in that it doesn’t increment the
4-bit Omnipod message sequence # from the previous response. It is believed that the
type 7 was added for DASH to make the pod less likely to reject a getStatus command
due to message # mismatch, probably to make comms more robust with the regular
disconnects by DASH pods and getStatus polling done by the DASH PDM.

[marionbarker]

Code Review

Code review shows most getStatus calls (0x0e with type 0) now use the DASH-only type 7, which does not increment the sequence number.

Test of Sequence Numbers

Use a nominal version of Loop 3.4.4 and a modified version with this PR.
Cycle through getStatus followed by status replies (0x0e, 0x1d) using the 2 sets of code and report the sequence number.

action	3.4.4	PR 138
0x0e	8	13
0x1d	9	14
0x0e	10	14
0x1d	11	15
0x0e	12	15
0x1d	13	0
0x0e	-	0
0x1d	-	1

[marionbarker]

Test using rPi DASH simulator

Perform a nominal Pod Setup with this PR applied.
Issue a report and use the OmniLoopMessageParser python parser to report the results.
(See OmniLoopMessageParser PR 4: Update Parser to handle use of Type 7 getStatus commands for DASH for modifications made to the parser to handle reporting additional information).

Report of Pod Setup from Parser

Add an annotation for the one time 0x0e00 is used instead of 0x0e07.

 Dash Pod: Addr 0x1091, Lot 135556529, Seq 451665, Pod_FW: 4.10.0, BLE_FW: 1.3.0, numInitSteps 20

  CumSec: seqNum: msgType :   msgName       : lastPP: pod_progressMeaning : podTimeOn(min)
      0:       0: 0x07    : assignID        :       :                     :        
      0:       1: 0x0115  : IdAssigned      :  2    : ReminderInitialized :        
      1:       2: 0x03    : setupPod        :  2    : ReminderInitialized :        
      1:       3: 0x011b  : PodSetupOK      :  3    : PairingCompleted    :        
      1:       4: 0x08    : cnfgDelivFlags  :  3    : PairingCompleted    :        
      2:       5: 0x1d    : PodStatus       :       :                     :        
      2:       6: 0x19    : cnfgAlerts      :       :                     :        
      2:       7: 0x1d    : PodStatus       :  3    : PairingCompleted    :        
      2:       8: 0x1a17  : SetBolus        :  3    : PairingCompleted    :        
      3:       9: 0x1d    : PodStatus       :  4    : Priming             :        
    184:       9: 0x0e07  : RequestStatus07 :  4    : Priming             :        
    185:      10: 0x1d    : PodStatus       :  5    : PrimingCompleted    : 3      
    301:      11: 0x1a13  : SetBasalSch     :  5    : PrimingCompleted    : 3      
    302:      12: 0x1d    : PodStatus       :  6    : BasalInitialized    : 5      
    302:      13: 0x19    : cnfgAlerts      :  6    : BasalInitialized    : 5      
    303:      14: 0x1d    : PodStatus       :  6    : BasalInitialized    : 5      
    303:      15: 0x1a17  : SetBolus        :  6    : BasalInitialized    : 5    
    303:       0: 0x1d    : PodStatus       :  7    : InsertingCannula    : 5      
Next getStatus is part of checkCannulaInsertionFinished, not modified so uses 0x0e00
    314:       1: 0x0e00  : RequestStatus00 :  7    : InsertingCannula    : 5      
    314:       2: 0x1d    : PodStatus       :  8    : Running > 50U       : 5      

[marionbarker]

Status

Test success. LGTM.

Testing Overview

When do you expect to see 0x0e07 vs 0x0e00 with this new code?

The getStatus command, type 7, i.e., 0x0e07, is used for these sessions, which have no other messages:

• “Post-connect status fetch” (most common)
• “Get pod status” (occasionally done by app/UI for a status update)
• “Resuming pod setup” (extremely rare)

For cases where the app hasn’t successfully verified that the pod is not currently bolusing, a 4-message sequence for requesting a bolus is used. This sequence starts with a getStatus, type 0 command; thus the sequence is the 0x0e00, 0x1d, 0x1a17, 0x1d.

This matches the DASH PDM behavior. It was observed that the PDM uses 0x0e07 for periodic status update or a post connect verification that the Pod connection is all good. The 0x0e00 getStatus is used immediately before some insulin operations.

Update to OmniLoopMessageParser

The python parser was updated to separately report when 0x0e00 and 0x0e07 are used.

Parse Loop Report without PR

This report is from 2024-11-28 and contains a complete set (80 hours) of messages for one DASH pod. Extract the information about 0x0e exchanges (for types: 0 and 7) along with the times a bolus is requested without first sending an 0x0e getStatus.

  Action Summary with sequential 4 or 2 message sequences with action response times in sec
      Action          : #Success,  mean, [  min,  max  ]
    Status&Bolus00    :     12,      6,  [    0,    10 ]
    RequestStatus00   :   1311,      0,  [    0,     4 ]
    BolusAlone        :    231,      0,  [    0,     2 ]

Parse Loop Report with PR

In this case, this PR was applied to my personal phone at Fri Dec 6 20:21:25 PST 2024, or 2024-12-07 04:21 UTC.

Trim the Device Communication Log to only contain information after that time.

The report covers 18 hours using this pod with the modified code.

Examine the same type of excerpt from the report output:

  Action Summary with sequential 4 or 2 message sequences with action response times in sec
      Action          : #Success,  mean, [  min,  max  ]
    Status&Bolus00    :      1,      1,  [    1,     1 ]
    RequestStatus07   :    282,      0,  [    0,     4 ]
    BolusAlone        :     60,      0,  [    0,     1 ]

Test with repeated interruptions

The rPi DASH simulator was used to test interrupting the pod setup process and resuming, as well as quitting and restarting the app during closed loop operation.

In all cases, the Loop app resumed as expected.
In some cases, both 0x0e00 and 0x0e07 were observed.