Command 02 Pod Information Response

02 Pod Information Response

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

Type 0

The most common Pod information response to a $0E status request command is type 0. This request returns a Command 1D Status response, unless there is a fault event. For fault events a 02 response type 2 (below) is returned.

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]: word_278 (unknown use)
• 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 0x19 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 0.05U 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 information on a fault event. This response can be returned by the Pod for any command on a Pod fault (a Pod screamer) or can be explicitly requested with a Type 2 Command 0E Status Request.

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 0X 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]: 0.05U insulin pulses not delivered
• MM (1 byte) [$7]: message sequence number (saved B9>>2)
• NNNN (1 bytes) [$8:$9]: total # of pulses delivered
• 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 0.05U pulses remaining 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, this bit mask is the same as the aaaaaaaaa bits in the $1D Response
• UU (1 byte) [$12]: 2 if there is a fault accessing tables
• VV (1 byte) [$13]: bits abbcdddd with information about logged fault event
  • a: insulin state table corruption found during error logging
  • bb: internal 2-bit variable set and manipulated in main loop routines
  • c: immediate bolus in progress during error
  • dddd: Pod progress at time of first logged fault event (same as 0X value)
• WW (1 byte): [$14] bits aabbbbbb
  • aa: receiver low gain
  • bbbbbb: radio RSSI
• 0X (1 byte): [$15] Pod progress at time of first logged fault event
• YYYY (2 bytes): [$16:$17] unknown

Examples:

02 16 02 0J 0K LLLL MM NNNN PP QQQQ RRRR SSSS TT UU VV WW 0X YYYY
02 16 02 0d 00 0000 06 0034 5c 0001 03ff 0001 00 00 05 a1 05 0186
02 16 02 0f 00 0000 09 0034 5c 0001 03ff 0001 00 00 05 ae 05 6029

Type 3

This response returns contents of an internal data from $4200, similar to types $50 & $51. Returns up to the last 60 dwords of data. The actual number of dwords of data returned (N) must be inferred from the value of command length LL.

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 dword entries
• 03 (1 byte) [$2]: type of this status format is 3
• PP (1 byte) [$3]: logged fault event, if any
• QQQQ (2 bytes) [$4:$5]: fault event time in minutes since Pod activation
• SSSS (2 bytes) [$6:$7]: minutes since Pod activation
• 04 (1 byte) [$8]: always 04 (size of data chunk size?)
• 3c (1 byte) [$9]: always $3c = 60 (max # of dword data chunks?)
• XXXXXXXX... (4N bytes) [$A:--]: logged data

Type 5

Pod information type 5 returns information on a fault along with 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

Type 6

Pod information response type 6 returns a fixed hardcoded set of bytes built up by OR'ing in each bit. Perhaps this type was used for testing purposes. The fixed response for type 6 request for firmware version 2.7.0 is as follows:

OFF 1  2  3  4  5  6
02 05 06 01 00 3F A8

Type 46

Pod information type $46 dumps low flash variables starting at $4000 which includes Pod state, initialization time, faults, etc.

OFF 1  2  3  4  5
02 LL 46 00 NN XX ...

• 02 (1 byte) [$0]: mtype value of 02 specifies status information
• LL (1 byte) [$1]: mlen of response type $46 (N+3 where N is the number of byte returned from flash storage)
• 46 (1 byte) [$2]: type of this status format is $46
• 00 (1 byte) [$3]: Always 0
• NN (1 byte) [$4]: # of bytes from flash storage
• XX... (NN bytes) [$5:$7D]: data from flash memory starting at $4000

The # of bytes returned for this response type is always $79 for the reference Pod and thus LL will always be $7c.

02 LL 46 00 NN XX ...
02 7c 46 00 79 XX ...

Example:

02 LL 46 00 DD XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX ...
02 7c 46 00 79 1f 00 ee 84 1f 00 ee 84 ff 00 ff 00 ff ff ff ff ff ff 00 00 ...

Type 50

Pod information response type $50 dumps the last fifty 32-bit entries from the flash log at $4200. These entries have information for each pulse delivered as described in Flash Log Entry. These fifty flash log entries 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 dword flash log entries in the response
• 50 (1 byte) [$2]: type of this status format is $50
• IIII (2 bytes) [$3:$4]: index of last dword log entry returned (should be the total # of pulses delivered)
• XXXXXXXX... (4N bytes) [$5:--]: N dwords log entries

Example:

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

Type 51

Pod information response type $51 is similar to Type $50, except it returns (up to) fifty 32-bit flash log entries as described in Flash Log Entry. before the last fifty entries returned by Type 50. If the typical fifty flash log entries are returned (2.5U of insulin delivery), this corresponds the info 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 dword flash log entries in the response
• 51 (1 byte) [$2]: type of this status format is $51
• NNNN (2 bytes) [$3:$4]: the number of dword log entries returned (normally 0032 = 50)
• XXXXXXXX (4N bytes) [$5:--]: N dwords log entries

Example:

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