-
Notifications
You must be signed in to change notification settings - Fork 46
Command 1A Table 2
When the 1A command is given a TableNum of 2,
the command specifies a bolus to be delivered.
The 1A command for Table 2 command can be either a normal bolus or an extended bolus
(which consists of an immediately portion and extended bolus portion).
This page documents the details of the 1A command for this case.
See the Command 1A Insulin Schedule
page for general background on the 1A Insulin Schedule command.
The $1A command format for a bolus command is as follows:
1a 0e NNNNNNNN 02 CCCC HH SSSS 0ppp 0ppp [napp...] 17...
-
1a(1 byte): Mtype value of $1a specifies a generic insulin schedule command -
0e(1 byte): Length, == $0e for normal bolus & >= $10 for extended bolus -
NNNNNNNN(4 bytes): Nonce, the 32-bit validator (random looking numbers) -
02(1 byte): TableNum of $02 specifies this is a bolus command -
CCCC(2 bytes): CheckSum, byte sum of the remaining 7 bytes -
HH(1 byte): Number of resulting Half Hour insulin table entries, 1 for normal bolus and > 1 for extended bolus -
SSSS(2 bytes): Same as the first InsulinScheduleElement value x $10 (ppp0) or x $8 (for some specific cases) -
0ppp(2 bytes): Pulses, same as the first InsulinScheduleElement value which is # of pulses to deliver immediately -
0ppp(2 bytes): The first InsulinScheduleElement describes the insulin to be delivered immediately in a single entry (i.e., just the # of 0.05U pulses) with a maximum documented value of $0258 (30U max bolus / 0.05U per pulse), the firmware shows this can be as actually high as $384 (x 0.05U = 45U!) -
[
napp...] (2 bytes per additional element): 1 or more InsulinScheduleElements used to describe any extended bolus -
17... The Next Command for a bolus is always $17 as documented in $17 Bolus Extra
For example, consider the following command for a normal (non-extended) 0.30U bolus:
1a 0e NNNNNNNN 02 CCCC HH SSSS 0ppp 0ppp 17...
1a 0e fcc35735 02 006d 01 0060 0006 0006 17...
This command is parsed as:
-
1a: Mtype of $1a specifies some insulin schedule command -
0e: Fixed command length of $0e for a normal bolus (i.e., only one InsulinScheduleElement) -
fcc35735: The nonce value in this example -
02: TableNum value of $02 specifies this is a bolus command -
006d: CheckSum, byte sum of remaining 7 bytes -
01: 1 entry in the resulting insulin schedule table for a normal bolus -
0060: The InsulinScheduleElement value of0006x $10 -
0006: Same as the InsulinScheduleElement value of0006 -
0006: InsulinScheduleElement for a single six 0.05U pulse element -
17... The start of the fixed next subcommand as documented in $17 Bolus Extra
For the 1A Insulin Schedule commands, the CheckSum is the byte sum of the bytes in 3 following fields in the command along with the bytes in the generated insulin schedule table. However for a normal bolus command, this value will end up being the same as sum of the following 7 bytes the command due to the fixed nature of the normal bolus insulin schedule command format which always uses a single InsulinScheduleElement which is just the number of 0.05U pulses.
The CheckSum value was $006d in the given example for a normal bolus.
The field bytes from the 3 following fields
in this command are 01 00 60 00 06 which sum to $67.
The insulin schedule table bytes for $0006 is just
a single insulin schedule table entry of [6].
$67 + 6 = $6d which matches the expected CheckSum value.
Because the normal bolus command always has a single
InsulinScheduleElement of the form 0ppp
(where ppp is the number of 0.05U pulses up to a max of $258 or 30U max/0.05U),
this generates a single entry insulin schedule table with the value of [ppp].
Thus since for the normal bolus command the sum of the bytes for the single
InsulinScheduleElement ppp is always the same as
the sum of the bytes in the generated single entry insulin schedule table [ppp],
the CheckSum for a normal bolus command turns out to just
be the sum of the remaining 7 bytes in the command.
One can verify that all of these bytes sum to $6d (=109 decimal) as shown in python below:
hex_data = '010060000606'
b = bytearray.fromhex(hex_data)
checksum = sum((b))
print(checksum) # 109
print(hex(checksum)) # 0x6d
1a 0e NNNNNNNN 02 CCCC HH SSSS 0ppp 0ppp 17...
1a 0e 92142003 02 0013 01 0010 0001 0001 17... 0.05U
1a 0e 03117123 02 0025 01 0020 0002 0002 17... 0.10U
1a 0e 464be60d 02 0037 01 0030 0003 0003 17... 0.15U
1a 0e 6c5412e1 02 0049 01 0040 0004 0004 17... 0.20U
1a 0e 8ef824bb 02 005b 01 0050 0005 0005 17... 0.25U
1a 0e fcc35735 02 006d 01 0060 0006 0006 17... 0.30U
1a 0e f4f0bfed 02 007f 01 0070 0007 0007 17... 0.35U
1a 0e 7cfd3642 02 0091 01 0080 0008 0008 17... 0.40U
1a 0e 1335474a 02 00a3 01 0090 0009 0009 17... 0.45U
1a 0e 84a6fb7f 02 00b5 01 00a0 000a 000a 17... 0.50U
1a 0e d9d7fb3f 02 011e 01 01e0 001e 001e 17... 1.50U
1a 0e ae89f72a 02 02fe 01 0ff0 00ff 00ff 17... 12.75U
1a 0e f3e10cc3 02 0013 01 1000 0100 0100 17... 12.80U
1a 0e c36ef335 02 0310 01 1ff0 01ff 01ff 17... 25.55U
In all of these examples, the SSSS field is
$10 times the InsulinScheduleElement value.
For some specialized cases during pod startup,
the SSSS field is just 8 times the InsulinScheduleElement
value instead of $10 times.
Need to better understand how this field is actually used internally.
Extended bolus commands use a single 1A command with more than one InsulinScheduleElement to describe both the immediate and the extended bolus delivery. There can only be one active extended bolus in effect at one time. As illustrated in Bolus with active extended bolus (Lytrix), it appears that the PDM apparently also needs to send an remaining extended bolus insulin schedule when a normal bolus is done while an extended bolus is still active. It appears that the immediate and the extended portions of a bolus are tightly tied together.
Consider the following example taken from Bolus with extended delivery (Lytrix) of an 6.0U extended bolus with 2.0U delivered now and 4.0U delivered over 3 hours:
1a 16 01e475cb 02 0129 07 0280 0028 0028 100d 000e 100d 000e 17...
This command is parsed as:
-
1a: Mtype of $1a specifies some insulin schedule command -
16: Length which will be >= $10 for extended bolus, ($16-$C)/2 = Five InsulinScheduleElements -
01e475cb: The nonce value in this example -
02: TableNum value of $02 specifies this is a bolus command -
0129: CheckSum, byte sum of remaining 7 bytes and of resulting insulin schedule table -
07: HH, 7 total entries in the resulting insulin schedule table -
0280: SSSS, the first InsulinScheduleElement value of0028* $10 -
0028: Pulses, the first InsulinScheduleElement value of0028(# of pulses to deliver immediately) -
0028: 1 entry (immediate) of [40] * 0.05U = 2.0U immediate bolus -
100d:n=1+1 = 2 entries (1 hour) of [13 13] -
000e:n=0+1 = 1 entry (0.5 hour) of [14] -
100d:n=1+1 = 2 entries (1 hour) of [13 13] -
000e:n=0+1 = 1 entry (0.5 hour) of [14] -
17... The start of the fixed next subcommand as documented in $17 Bolus Extra
The five InsulinScheduleElements in this extended bolus command example expand to make the following 7 entry insulin schedule table which describes the immediate bolus and the 3 hour extended bolus:
1: 40 pulses x 0.05U/pulse = 2.0U immediate
2: 13 pulses x 0.05U/pulse = 0.65U 1/2 hour
3: 13 pulses x 0.05U/pulse = 0.65U 1/2 hour
4: 14 pulses x 0.05U/pulse = 0.70U 1/2 hour
5: 13 pulses x 0.05U/pulse = 0.65U 1/2 hour
6: 13 pulses x 0.05U/pulse = 0.65U 1/2 hour
7: 14 pulses x 0.05U/pulse = 0.70U 1/2 hour
4.00U total over 3 hours extended bolus
For the 1A Insulin Schedule, the CheckSum is the byte sum of the bytes in 3 following fields in the command along with the bytes in the generated insulin schedule table. An extended bolus command can have more than one InsulinScheduleElement to create a non-trivial insulin schedule table that will need to be generated and summed to compute the command 1A CheckSum value.
The CheckSum value was $129 in the given example for an extended bolus command. The field bytes from the 3 following fields in this example are 07 02 80 00 28 which sum to $b1. The insulin schedule table for the five InsulinScheduleElement values of $0028, $100d, $000e, $100d, $000e is [40 13 13 14 13 13 14] which sums to 120 or $78. $b1 + $78 = $129 which matches the expected CheckSum value.
One can verify that all of these bytes sum to $129 (=297 decimal) as shown in python below:
hex_data = '0702800028280d0d0e0d0d0e'
b = bytearray.fromhex(hex_data)
checksum = sum((b))
print(checksum) # 297
print(hex(checksum)) # 0x129
In this example lifted from Bolus with only extended delivery (Lytrix), a 1.0U extended bolus is given over 1 hour with no immediate bolus:
1a 0e NNNNNNNN 02 CCCC HH SSSS 0ppp 0ppp napp 17...
1a 10 2d312781 02 0017 03 0000 0000 0000 100a 17...
This example with 2 InsulinScheduleElements creates a 3 entry
(as specified by the 03 value in the HH field)
insulin schedule table of [0 10 10]
to deliver the extended bolus with no immediate bolus as shown:
1: 0 pulses x 0.05U/pulse = 0.0U immediate
2: 10 pulses x 0.05U/pulse = 0.50U 1/2 hour
3: 10 pulses x 0.05U/pulse = 0.50U 1/2 hour
1.00U total over 1 hour extended bolus
Note that in this example with no immediate bolus, that the first InsulinScheduleElement value is 0000 which also means that the FieldA and FieldC values are also both 0000. The Checksum in this case is the byte sum of the following 5 bytes in the next 3 fields (03 0000 0000) = 3 plus the byte sum of the generated insulin schedule table [0 $a $a] = $14 and so 3 + $14 = $17 which is the expected Checksum value.
1a 0e NNNNNNNN 02 CCCC HH SSSS 0ppp 0ppp
1a 0e 7e30bf16 02 0065 01 0050 000a 000a