-
Notifications
You must be signed in to change notification settings - Fork 46
Command 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.
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: $08, $11, $19, $1A (from the $13, $16 & $17 sub-commands), $1C, $1E and $1F.
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 0x19b
($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
- 0 -
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.
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
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 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
thru0F
) -
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 0.05U bolus pulses not delivered in the last bolus operation -
MM
(1 byte) [$7]: message sequence number (saved B9>>2) -
NNNN
(1 bytes) [$8:$9]: total # of 0.05U 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 0.05U pulses remaining in reservoir if <= 50U or $3ff if > 50U -
SSSS
(2 bytes) [$F:$10]: minutes since Pod activation (stops at 80 hr x 60 min/hr = 4800) -
TT
(1 byte) [$11]: bit mask of the active, unacknowledged alerts (1 << alert #) from the $19 Command, this bit mask is the same as theaaaaaaaaa
bits in the $1D Response -
UU
(1 byte) [$12]: 2 if there is a fault accessing tables -
VV
(1 byte) [$13]: bitsabbcdddd
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 as0X
value)
-
-
WW
(1 byte): [$14] bitsggssssss
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 Indictor (RSSI) value, observed maximum & minimum values of 61 & 8
-
-
0X
(1 byte): [$15] Pod progress at time of first logged fault event -
YYYY
(2 bytes): [$16:$17] unknown
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
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 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]: always04
(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 ...
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
Pod information response type $50 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 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 $50 -
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
02 LL 50 IIII XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX ...
02 cb 50 0090 00632980 05622f80 08622980 0d622f80 ...
Pod information response type $51 is similar to Type $50, 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 50. If the typical fifty pulse log entries 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 $51 -
NNNN
(2 bytes) [$3:$4]: the number of 32-bit pulse log entries returned (normally0032
= 50) -
XXXXXXXX
(4N bytes) [$5:--]: N 32-bit pulse log entries]
02 LL 51 NNNN XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX ...
02 cb 51 0032 00612280 05632680 08602280 0d612680 10612180 ...