Command 02 Pod Information Response

02 Pod Information Response

The 02 response provides Pod information, typically responding to a $0E Status Request. There are multiple types of 02 responses, selected by the third byte (the first data byte) of the 0xE request. Except for the type 0 request, this type is echoed in the third byte (the first data byte) of the 02 response.

Type 0

The most typical $0E status request command is type 0 which returns a generic non-fault response described in $1D Status Response. The Pod information response type 0 (AKA $1D Status Response) is also the non-fault response for the following commands as outlined in Message Types: 8, $11, $19, $1A (from the $13, $16 & $17 sub-commands), $1C, $1E and $1F.

Type 1

Pod information response type 1 response provides values for triggered and unacknowledged alerts. The format for this response type is as follows:

OFF 1  2  3 4  5 6  7 8  910 1112 1314 1516 1718 1920
02 13 01 XXXX VVVV VVVV VVVV VVVV VVVV VVVV VVVV VVVV

• 02 (1 byte) [$0]: mtype value of 02 specifies status information
• 13 (1 byte) [$1]: mlen of a type 1 response is always $13
• 01 (1 byte) [$2]: type of this status format
• XXXX (2 bytes) [3:4]: unknown, for Eros Rev 2.7.0 this is word_278 (always zero)
• VVVV (8 words of 2 bytes each) [5:20]: 8 words for alerts #0..7 (as described in $19 Configure Alerts) of triggered and unacknowledged alert values or zero. A zero value indicates that the alert # has either never been configured, has not triggered since it was last configured, or has triggered and was subsequently acknowledged using a $11 Acknowledge Alert command. A non-zero VVVV is the elapsed minutes from Pod start when the alert triggered for all current Eros and Dash pods. For some earlier pods (i.e., Eros Rev 2.7.0), if the b ($04) bit was set when the alert was configured using the $19 Configure Alerts command a non-zero VVVV may be the # of pulses in the reservoir when the alert triggered.

Example 1:

02 13 01 XXXX VVVV VVVV VVVV VVVV VVVV VVVV VVVV VVVV
02 13 01 0000 0000 0000 0000 0000 0000 0000 0000 0000

In this example during Pod deactivation, none of alerts 0 through 7 had triggered and then subsequently unacknowledged before the pod was deactivated.

Example 2:

02 13 01 XXXX VVVV VVVV VVVV VVVV VVVV VVVV VVVV VVVV
02 13 01 0000 0000 0000 0000 0000 0000 0bd7 0c40 0000

In this example a 2 hour suspend was performed at 50 hours, 16 minutes and the pod subsequently resumed after two and a half hours. Alert #5 (suspended reminder) triggered at 0bd7 = 3031m or 50 hours, 31 minutes (15 minutes after the suspend start time) while alert #6 (suspend time expired) triggered at 0c40 = 3136m or 52 hours, 16 minutes (2 hours after the suspend start time).

Type 2

The type 2 Pod information response provides a more detailed status than the standard $1D Status Response. This response can be explicitly requested anytime using a Type 2 Command 0E Status Request or it can be returned on a Pod fault (screamer) for any command that normally returns a $1D Status Response.

OFF 1  2  3  4  5 6  7  8 9 10 1112 1314 1516 17 18 19 20 21 2223
02 16 02 0J 0K LLLL MM NNNN PP QQQQ RRRR SSSS TT UU VV WW XX YYYY

• 02 (1 byte) [$0]: mtype value of 02 specifies status information
• 16 (1 byte) [$1]: mlen of a type 2 response is always $16
• 02 (1 byte) [$2]: type of this status format is 2
• 0J (1 byte) [$3]: current Pod Progress value (00 thru 0F)
• 0K (1 byte) [$4]: bit mask for active insulin delivery
  • 1: Basal active, exclusive of 2 bit
  • 2: Temp basal active, exclusive of 1 bit
  • 4: Immediate bolus active, exclusive of 8 bit
  • 8: Extended bolus active, exclusive of 4 bit
• LLLL (2 bytes) [$5:$6]: total # of immediate and extended bolus pulses not delivered in the last bolus operation
• MM (1 byte) [$7]: message sequence # of last processed programming command (3, 8, $11, $19, $1A, $1C, $1E & $1F)
• NNNN (1 bytes) [$8:$9]: total # of pulses delivered during life of Pod
• PP (1 byte) [$A]: original logged fault event, if any
• QQQQ (2 bytes) [$B:$C]: fault event time in minutes since Pod activation or $ffff if unknown due to an unexpected MCU reset
• RRRR (2 bytes) [$D:$E]: # of pulses remaining in reservoir if <= 50U or $3ff if > 50U
• SSSS (2 bytes) [$F:$10]: minutes since Pod activation
• TT (1 byte) [$11]: bit mask of the active, unacknowledged alerts (1 << alert #) from the $19 Command; same as the aaaaaaaaa bit mask in the $1D Response
• UU (1 byte) [$12]: bits 000000eo fault flags
  • e: error occurred during access, pulse information invalid
  • o: occlusion fault (never set in at least Eros rev 2.7.0 firmware)
• VV (1 byte) [$13]: bits abbcdddd with information about logged fault (or 0x00 if no pod fault)
  • a: insulin state table corruption detected
  • bb: 2-bit occlusion type
  • c: immediate bolus in progress during error
  • dddd: Pod Progress at time of first logged fault event (same as 0X value on Eros)
• WW (1 byte): [$14]
  • Eros: bits ggssssss containing Pod radio information
    • gg: Pod's current receiver low gain, observed minimum gain is at 2 & observed maximum gain is at 0
    • ssssss: Pod's current Received Signal Strength Indicator (RSSI) value, observed max & min values of 61 & 8
  • Dash: always observed to be 00
• XX (1 byte): [$15]
  • Eros: 0X Pod progress at time of first logged fault event (same as lower nibble of VV) or 0xFF if no fault
  • Dash: unknown or uninitialized data from the previous command/response at the same buffer offset
• YYYY (2 bytes): [$16:$17]
  • Eros: uninitialized data from the previous command/response at the same buffer offset in all cases
  • Dash: for non-faults unknown data; for faults possibly the calling address for the initial return after a pod fault, while subsequent returns will be byte swapped data from the previous command/response at the same buffer offset

Example fault returns:

02 16 02 0J 0K LLLL MM NNNN PP QQQQ RRRR SSSS TT UU VV WW 0X YYYY
02 16 02 0d 00 0004 02 0a90 14 0e46 0201 0e46 00 00 19 5c 09 030d
02 16 02 0f 00 0000 03 011c 31 02ec 03ff 02ee 00 00 08 92 08 621e
02 16 02 0d 00 0006 08 0694 41 0b2b 03ff 0b2d 00 00 18 26 08 030d
02 16 02 0d 00 0000 06 0034 5c 0001 03ff 0001 00 00 05 a1 05 0186

Example returns from a type 2 $0E Status Request request used to implement "Read Pod Status" in modern versions of Loop.

02 16 02 0J 0K LLLL MM NNNN PP QQQQ RRRR SSSS TT UU VV WW 0X YYYY
02 16 02 08 01 0000 02 0104 00 0000 03ff 01a9 00 00 00 20 ff 030d
02 16 02 09 02 0000 0c 0a1f 00 0000 0238 1264 00 00 00 1c ff 735c

Type 3

This response returns up to sixty of the last (32-bit pulse log entries)[Pulse-Log-Entry] plus some additional information. These entries have information for each pulse delivered as described in Pulse Log Entry. The actual number of 32-bit pulse log entries returned (N) must be inferred from the value of command length LL. Sixty pulse log entries for 0.05U pulses would correspond to the last 60 x 0.05U/pulse = 3.0U of insulin delivery.

OFF 1  2  3  4 5  6 7  8  9 10
02 LL 03 PP QQQQ SSSS 04 3c XXXXXXXX ...

• 02 (1 byte) [$0]: mtype value of 02 specifies status information
• LL (1 byte) [$1]: mlen of a type 3 response is 4N+8 where N is the number of 32-bit pulse log entries
• 03 (1 byte) [$2]: type of this status format is 3
• PP (1 byte) [$3]: logged fault event code, if any
• QQQQ (2 bytes) [$4:$5]: fault event time in minutes since Pod activation
• SSSS (2 bytes) [$6:$7]: minutes since Pod activation (stops at 80 hr x 60 min/hr = 4800)
• 04 (1 byte) [$8]: always 04 (size of a 32-bit pulse log entry)
• 3c (1 byte) [$9]: always $3c = 60 (maximum number of 32-bit pulse log entries)
• XXXXXXXX... (4N bytes) [$A:--]: 32-bit pulse log data

The type 3 pod information response has never been seen being used by any PDM. It is speculated that this response was intended for use when deactivating pods, but its use was replaced with the type 80 and 81 responses for a number of reasons. The fault information contained in the type 3 response is redundant and not as complete as what will have been previously returned by the type 2 response for any pod fault. The pulse log information for a type 3 pod info response has no indication of the pulse # and no pulse information will be returned for any reset-type pod faults whereas the type 80 & 81 pod info responses do not suffer from these pulse log limitations. Additionally the type 3 response is the largest of these pod information responses (its LL value is f8 is near its maximum value) which will stress the transport more than just using two more modest type 80 & 81 pod information responses which will by more reliable and return more total pulse log entries (100).

Example:

OFF 1  2  3  4 5  6 7  8  9 10
02 LL 03 PP QQQQ SSSS 04 3c XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX ...
02 f8 03 00 0000 0075 04 3c 54402600 59402d80 5c412480 61402d80 00412380 ...

Type 5

Pod information type 5 returns basic information on a fault and the Pod's initialization time.

OFF 1  2  3  4 5  6 7 8 9 10111213 1415161718
02 11 05 PP QQQQ 00000000 00000000 MMDDYYHHMM

• 02 (1 byte) [$0]: mtype value of 02 specifies status information
• 11 (1 byte) [$1]: mlen of this type 5 response is always $11
• 05 (1 byte) [$2]: type of this status format is 5
• PP (1 byte) [$3]: logged fault event, if any
• QQQQ (2 bytes) [$4:$5]: fault event time in minutes since Pod activation
• 00000000 00000000 (8 bytes) [$6:$D] : always 0
• MMDDYYHHMM (5 bytes) [$E:$12]: Pod initialization time: month, day, years since 2000, hour, minute

Example:

OFF 1  2  3  4 5  6 7 8 9 10111213 1415161718
02 11 05 PP QQQQ 00000000 00000000 MMDDYYHHMM
02 11 05 92 0001 00000000 00000000 091912170e

Type 80

Pod information response type 80 (0x50) returns the last fifty 32-bit pulse log entries stored in the Pod's flash memory. These entries have information for each pulse delivered as described in Pulse Log Entry. These fifty pulse log entries for 0.05U pulses corresponds to the last 50 x 0.05U/pulse = 2.5U of insulin delivery.

OFF 1  2  3 4  5 6 7 8
02 LL 50 IIII XXXXXXXX ...

• 02 (1 byte) [$0]: mtype value of 02 specifies status information
• LL (1 byte) [$1]: mlen is 4N+5 where N is the number of 32-bit pulse log entries in the response
• 50 (1 byte) [$2]: type of this status format is 0x50 (80)
• IIII (2 bytes) [$3:$4]: index of last 32-bit pulse log entry returned (should be the total # of pulses delivered)
• XXXXXXXX... (4N bytes) [$5:--]: N 32-bit pulse log entries

Example:

02 LL 50 IIII XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX ...
02 cb 50 0090 00632980 05622f80 08622980 0d622f80 ...

Type 81

Pod information response type 81 (0x51) is similar to Type 80, except it returns (up to) fifty 32-bit pulse log entries as described in Pulse Log Entry before the last fifty entries returned by Type 80. If the typical fifty pulse log entries for 0.05U pulses are returned (i.e., 2.5U of insulin delivery), this corresponds the pulse log entries for the last 5U to 2.5U of insulin delivered.

OFF 1  2  3 4  5 6 7 8
02 LL 51 NNNN XXXXXXXX ...

• 02 (1 byte) [$0]: mtype value of 02 specifies status information
• LL (1 byte) [$1]: mlen is 4N+5 where N is the number of 32-bit pulse log entries pulse log entries in the response
• 51 (1 byte) [$2]: type of this status format is 0x51 (81)
• NNNN (2 bytes) [$3:$4]: the number of 32-bit pulse log entries returned (normally 0032 = 50)
• XXXXXXXX (4N bytes) [$5:--]: N 32-bit pulse log entries]

Example:

02 LL 51 NNNN XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX ...
02 cb 51 0032 00612280 05632680 08602280 0d612680 10612180 ...