-
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:
00 01 02030405 06 0708 09 0A0B 0C0D 0E0F 1011
1a LL NNNNNNNN 02 CCCC HH SSSS PPPP 0ppp [napp...] 17...
-
1a(1 byte): Mtype value of $1a specifies a generic insulin schedule command -
LL(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 (normal bolus) or byte sum of the following 3 fields along with the bytes in the generated insulin schedule table (extended bolus) -
HH(1 byte): Number of resulting Half Hour insulin table entries, 1 for normal bolus and > 1 for extended bolus -
SSSS(2 bytes):PPPPtimes $10 (for a standard two seconds between pulse immediate bolus) or times 8 (for an one second between pulse bolus during Pod startup) -
PPPP(2 bytes): Pulses, same as the first InsulinScheduleElement value, # 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), although 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 Command 17 Bolus extra
For example, consider the following command for a normal (non-extended) 0.30U bolus:
00 01 02030405 06 0708 09 0A0B 0C0D 0E0F 1011
1a LL NNNNNNNN 02 CCCC HH SSSS PPPP 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 Command 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 PPPP 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, 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 of an 6.0U extended bolus with 2.0U delivered now and 4.0U delivered over 3 hours:
00 01 02030405 06 0708 09 0A0B 0C0D 0E0F 1011 1213 1415 1617 18
1a LL NNNNNNNN 02 CCCC HH SSSS PPPP 0ppp napp napp napp napp 17...
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 Command 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 command, 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 taken from Bolus with only extended delivery, a 1.0U extended bolus is given over 1 hour with no immediate bolus:
00 01 02030405 06 0708 09 0A0B 0C0D 0E0F 1011 18
1a LL NNNNNNNN 02 CCCC HH SSSS PPPP 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.
The Omnipod only supports one active extended bolus. The way the bolus commands are defined, when another immediate bolus command is given to a pod with an active extended bolus, the PDM also needs to send information for the remaining extended bolus. In this example taken from Bolus extended with superimposed immediate bolus, an immediate bolus of 1.0U is requested 35 minutes into a 1.0U extended bolus over 1.5 hours.
00 01 02030405 06 0708 09 0A0B 0C0D 0E0F 1011 1213 14
1A LL NNNNNNNN 02 CCCC HH SSSS PPPP 0ppp napp napp 17...
1a 12 31f9bb6b 02 0079 03 0140 0014 0014 0007 0006 17...
This example has 3 InsulinScheduleElements creates a 3 entry insulin schedule table of [20 7 6] to deliver the requested immediate 1.0U bolus along with the remaining extended bolus as shown:
1: 20 pulses x 0.05U/pulse = 1.0U immediate
2: 7 pulses x 0.05U/pulse = 0.35U 1/2 hour
3: 6 pulses x 0.05U/pulse = 0.30U 1/2 hour (probably actually 25 minutes)
0.65U total over 55 minute remaining extended bolus
The remaining extended bolus calculations values make sense as 35m/90m of the 1.0U (20 pulses) = 7.8 pulses (rounded down to 7) will have been delivered and the remaining 13 pulses are still be delivered and 55m/90m of 20 pulses is 12.2 pulses (which will be rounded up for the needed 20 total pulses).
00 01 02030405 06 0708 09 0A0B 0C0D 0E0F 10 11 12 1314 15161718 1A1B 1C1D1E1F
1a LL NNNNNNNN 02 CCCC HH SSSS PPPP 0ppp 17 LL BO NNNN XXXXXXXX YYYY ZZZZZZZZ
1a 0e 7e30bf16 02 0065 01 0050 000a 000a 17 0d 00 0064 000186a0 0000 00000000
For this special case 0.5U bolus,
the SSSS value is 8 times
(instead of the typical 16 = $10 times)
the PPPP value for one second between pulses instead of
the default 2 seconds between boluses that the Pod uses for normal immediate bolus delivery.
The restrictions for use of the $1A Command for Table 2 (Bolus) are those of the accompanying $17 Bolus Extra subcommand. The $17 subcommand must always appear directly after the $1A Command for Table 2 (Bolus) and cannot be combined with any other commands in the same message.