Skip to content

Command 02 Pod Information Response

Jump to bottom Edit New page
Joe Moran edited this page Jan 15, 2022 · 35 revisions

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 all the alert types as described in Command 19 Configure 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:$14]: 8 words for alerts #0..7 from Command 19 Configure Alerts of either zeroes (if the alert # is not active) or the alert value when the alert became active. The interpretation of the alert value depends on the Command $19 b ($04) bit that was last used to set up the alert #:
    • 0 - VVVV is the elapsed minutes from Pod start
    • 1 - VVVV is the # of pulses left

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 are active.

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 is being deactivated after 2:30 hours

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 00
  • XX (1 byte): [$15]
    • Eros: 0X Pod progress at time of first logged fault event (or 0xFF if no fault)
    • Dash: unknown data
  • YYYY (2 bytes): [$16:$17]
    • Eros: uninitialized data in all cases
    • Dash: the return address of fault handler caller for faults, uninitialized data for non-faults

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

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 ...
Add a custom footer

Communications

Reference

Message decoding

Device drivers

Hardware

Clone this wiki locally