-
Notifications
You must be signed in to change notification settings - Fork 46
Command 16 Temp Basal
The 0x16 command is the follow-on command for the Command 0x1A Table 1 case to set a fixed or percentage temporary basal rate. This command always immediately follows the 0x1A command with Table 1 (temp basal case) in the same message.
The generic format of the 0x16 basal schedule follow-on command is:
00 01 02 03 0405 06070809 0A0B 0C0D0E0F 1011 12131415
16 LL BO MM NNNN XXXXXXXX YYYY ZZZZZZZZ [YYYY ZZZZZZZZ...]
-
16(1 byte): Mtype value of $16 specifies temp basal follow-on command for a Command 0x1A Table 1. -
LL(1 byte): Length of the following bytes for this command. Will be a value of 0x0e + 6n where n varies between 0 to 23. -
BO(1 byte): Beep Optionsacrrrrrr, formerlyRRReminders, (typical PDM values $00, $3c, $40 and $7c):-
abit ($80) for acknowledgement beep (temp basal command received), not used by PDM (see below). -
cbit ($40) for completion beep (temp basal normally completed). -
rrrrrr(6 bits) # of minutes ($3c = 60 minutes) between Program Reminder beeps.
-
-
MM(1 byte): Always observed to be00. -
NNNN(2 bytes): Remaining 1/10th of a 0.05u pulse of insulin to deliver for first entry (i.e., # of pulses x 10).NNNNmust be <= the firstYYYYvalue, for fixed rate temp basal it will be same as the onlyYYYYvalue. -
XXXXXXXX(4 bytes): Delay until next 1/10th of a 0.05u pulse, expressed in microseconds (delay to next pulse in 100s of milliseconds).XXXXXXXXmust be <= the firstZZZZZZZZvalue. -
YYYY(2 bytes): Total 1/10th of a 0.05u pulses of insulin for this schedule entry (i.e., # of pulses x 10). -
ZZZZZZZZ(4 bytes): Delay between 1/10th of a 0.05u pulse, expressed in microseconds (delay to next pulse in 100s of milliseconds). Example:1.0 U/hr = 20 pulses per hour = 3 min (180 secs) between pulses = 18 secs for 1/10th of a pulse = 18,000,000 uS = 0x112a880
The PDM does not use the a acknowledgement bit ($80)
on the BO Beep Options byte to implement Confidence Reminders.
Rather, the PDM itself will beep at the start of the temporary basal rate
(presumably when this command has been acknowledged by the Pod)
and uses the c completion beep bit ($40)
to have the Pod beep upon the normal completion of the temporary basal rate.
If the temporary basal rate is stopped using the 0x1F Cancel Command,
the beep option specified in the cancel command is used and the c completion beep bit is not used.
The XXXXXXXX and ZZZZZZZZ values have
a minimum value of 0x30d40 (=200,000 decimal, i.e., 2 seconds between pulses) and
a maximum value of 0x6b49d200 (=1,800,000,000 decimal, i.e., 18,000 seconds or 5 hours between pulses).
Another set of YYYY ZZZZZZZZ fields are
added for each additional segment in the schedule.
Fixed rate temp basal commands typically only have one YYYY ZZZZZZZZ
segment except for longer requests with a very large requested basal rate
which might require two segments to encode the total number of needed pulses and
Eros style zero temp basal rates which use one segment per each half hour.
Percentage temp basal commands can consist of up to 25 segments
depending on how many different segments in the basal program in effect
need to be replaced by the percentage temp basal command.
Consider the following fixed rate temp basal example of 1.10 U/h for 1.5 hours:
16 LL BO MM NNNN XXXXXXXX YYYY ZZZZZZZZ
16 0e 7c 00 014a 00f9b074 014a 00f9b074
-
0eLength of command is $0e bytes ($0e is very typical for a fixed rate temp basal) -
7cBO $40 completion beep, Program Reminder beeps every $3c = 60 minutes -
00MM always 00 -
014aNNNN $014a = 330 (decimal) / 10 = 33 pulses remaining -
00f9b074XXXXXXXX = 16,363,636 / 100,000 = 163 seconds to the next pulse -
014aYYYY $014a = 330 (decimal) / 10 = 33 pulses to deliver -
00f9b074ZZZZZZZZ = 16,363,636 / 100,000 = 163 seconds between pulses
Note that 33 pulses of 0.05U/pulse is a total of 1.65U
to be delivered for the 1.5 hour fixed rate temp basal
and that 1.65U / 1.5 hours = 1.10 U/h as requested.
There are 163 seconds between pulses during this
fixed rate temp basal for 1.5 hours which is the same as
(1.5 x 60 x 60) / 33 pulses or 163 secs/pulse.
Note that the NNNN value of 00f9b074 matches the YYYY value
and that the XXXXXXXX value of 014a matches the ZZZZZZZZ value.
Zero temp basal rates are handled special and have a completely different encoding for Eros and Dash.
16 LL RR MM NNNN XXXXXXXX YYYY ZZZZZZZZ
16 0e 7c 00 0000 6b49d200 0000 6b49d200
$6b49d200 = 1,800,000,000 (decimal) / 100,000 = 18,000 secs = 5 hours per pulse
With a 0 U/h rate, there are no pulses delivered, so XXXXXXXXX and ZZZZZZZZ would need to be a large value.
Eros Omnipod uses a timing value of $6b49d200 or 1,800,000,000 / 100,000 = 18,000 seconds or 5 hours between pulses
with a timing of 0.01 U/h, but it doesn't encode any tenth of a pulse value (i.e., both NNNN and YYYY are 0000).
16 LL RR MM NNNN XXXXXXXX YYYY ZZZZZZZZ
16 0e 7c 00 0001 6b49d200 0001 eb49d200
$6b49d200 = 1,800,000,000 (decimal) / 100,000 = 18,000 secs = 5 hours
$eb49d200 = $80000000 + $6b49d200
A 0 U/h basal rate for Dash is implemented as a 0.01 U/h rate (a single 0.05U pulse over 5 hours)
using a special $80000000 bit set in the ZZZZZZZZ field.
The NNNN and YYYY fields of 0001 indicate that one tenth of a pulse (1/10 * 0.05U = 0.005U) is to be delivered.
It is speculated that the $80000000 flag being set in ZZZZZZZZZ indicates that this phantom partial pulse
shouldn't be accounted for in the DASH pod's tenth of basal pulse accounting (i.e., it is a zero basal rate).
16 LL RR MM NNNN XXXXXXXX YYYY ZZZZZZZZ YYYY ZZZZZZZZ YYYY ZZZZZZZZ YYYY ZZZZZZZZ YYYY ZZZZZZZZ YYYY ZZZZZZZZ
16 2c 7c 00 0000 6b49d200 0000 6b49d200 0000 6b49d200 0000 6b49d200 0000 6b49d200 0000 6b49d200 0000 6b49d200
$6b49d200 = 1,800,000,000 (decimal) / 100,000 = 18,000 secs = 5 hours
Eros uses a separate YYYY ZZZZZZZZ segment for each half hour for encoding zero basal rates.
Thus for a 3 hour 0.0 U/h temp basal, there will be six identical segments of 0000 6b49d200
which is used to encode a 0.0 U/h basal rate over one half hour.
16 LL RR MM NNNN XXXXXXXX YYYY ZZZZZZZZ
16 0e 7c 00 0006 6b49d200 0006 eb49d200
$6b49d200 = 1,800,000,000 (decimal) / 100,000 = 18,000 secs = 5 hours
$eb49d200 = $80000000 + $6b49d200
A 0 U/h basal rate for Dash is implemented as a 0.01 U/h rate (a single 0.05U pulse over 5 hours)
using a special $80000000 bit set in the ZZZZZZZZ field.
The NNNN and YYYY fields of 0006 indicate that 6 tenths of a pulse (6/10 * 0.05U = 0.03U) is to be delivered.
It is speculated that the $80000000 flag being set in ZZZZZZZZZ indicates that this phantom partial pulse
shouldn't be accounted for in DASH pod's tenth of basal pulse accounting (i.e., it is a zero basal rate).
1a LL NNNNNNNN 01 CCCC HH SSSS PPPP napp
1a 0e c43f85a9 01 00d3 01 3840 012c 012c
16 LL BO MM NNNN XXXXXXXX YYYY ZZZZZZZZ
16 0e 3c 00 0bb8 000927c0 0bb8 000927c0
$0bb8 = 3000 (decimal) / 10 = 300 pulses x 0.05U/pulses = 15U total
$000927c0 = 600,000 / 100,000 = 6 seconds between pulses
In this example, 15U total insulin will be delivered over one half hour which is the requested 30 U/h rate over 0.5 hours. The pulses will be delivered every 6 seconds and 300 pulses x 6 secs/pulse = 1800 secs or 30 minutes as expected.
1a LL NNNNNNNN 01 CCCC HH SSSS PPPP napp
1a 0e b238ca0b 01 0079 01 3840 0000 0000
16 LL BO MM NNNN XXXXXXXX YYYY ZZZZZZZZ
16 0e 3c 00 0005 15752a00 0005 15752a00
$0005 = 5 / 10 = one half pulse!
$15752a00 = 360,000,000 (decimal) / 100,000 = 3600 secs = 1 hour between pulses
For the minimum allowed basal rate of 0.05 U/h,
only one 0.05U pulse can be delivered per hour.
The math works for the specified rate,
but given that only an integral number pulses can be delivered,
it is impossible to delivery the requested 0.05 U/h rate
over only a 1/2 hour period.
The 60 minutes before the first pulse (XXXXXXXX == $15752a00)
means that no pulses will be delivered and the effective
temp basal rate would actually be 0.0 U/h in this case.
However if a 0.05 U/h rate for 1 hour was requested,
this can be delivered with a single pulse over the 1 hour temp basal period.
1a LL NNNNNNNN 01 CCCC HH SSSS PPPP napp
1a 0e 1a4b342d 01 008d 01 3840 000a 000a
16 LL BO MM NNNN XXXXXXXX YYYY ZZZZZZZZ
16 0e 3c 00 0064 0112a880 0064 0112a880
$0064 = 100 / 10 = 10 pulses x 0.05U/pulse = 0.5U total
$0112a880 = 18,000,000 / 100,000 = 180 seconds between pulses
The 0.5U total over half an hour is the requested 1.0 U/h rate and 3 minutes between pulses * 10 pulses = 30 minutes as expected.
1a LL NNNNNNNN 01 CCCC HH SSSS PPPP napp napp
1a 10 a958c5ad 01 04f5 18 3840 012c f12c 712c
$f12c describes 16 half hour entries of $12c (300) pulses each (8 hours)
$712c describes 8 half hour entries of $12c (300) pulses each (4 hours)
16 LL BO MM NNNN XXXXXXXX YYYY ZZZZZZZZ YYYY ZZZZZZZZ
16 14 3c 00 f618 000927c0 f618 000927c0 2328 000927c0
$f618 = 63000 (decimal) / 10 = 6300 pulses x 0.05U/pulse = 315U
$000927c0 = 600,000 / 100,000 = 6 seconds between pulses
6300 pulses x 6 sec/pulse = 37,800 secs = 10.5 hours
$2328 = 9000 (decimal) / 10 = 900 pulses x 0.05U/pulse = 45U
$000927c0 = 600,000 / 100,000 = 6 seconds between pulses
900 pulses x 6 sec/pulse = 5,400 secs = 1.5 hours
This maximum duration and maximum basal rate fixed example
requires two YYYY ZZZZZZZZ segments to describe due to limits
on pulse encoding for YYYY ($ffff -> 6553 pulses).
A total of 315U + 45U = 360U of insulin will be delivered over 24 half hours
which is the requested 30 U/h rate over 12 hours.
The pulses will be delivered every 6 seconds over the entire 12 hours
and 6300 + 900 = 7200 total pulses x 6 secs/pulse =
43,200 secs = 720 minutes or 12 hours as expected.
The first YYYY ZZZZZZZZ segement describes a 10.5 hour interval
and the second YYYY ZZZZZZZZ segment describes a 1.5 hour interval.
This is in contrast to the two InsulinScheduleElements in
the $1A command which are split as an
8 hour segment (its maximum) and a 4 hour segment.
1a LL NNNNNNNN 01 CCCC HH SSSS PPPP napp napp
1a 10 266d015f 01 0499 16 3840 012c f12c 512c
$f12c describes 16 half hour entries of $12c (300) pulses each (8 hours)
$512c describes 6 half hour entries of $12c (300) pulses each (3 hours)
16 LL BO MM NNNN XXXXXXXX YYYY ZZZZZZZZ YYYY ZZZZZZZZ
16 14 00 00 f618 000927c0 f618 000927c0 0bb8 000927c0
$f618 = 63,000 (decimal) / 10 = 6300 pulses x 0.05 U/pulse = 315U
$000927c0 = 600,000 / 100,000 = 6 seconds between pulses
6300 pulses x 6 sec/pulse = 37,800 secs = 10.5 hours
$0bb8 = 3,000 (decimal) / 10 = 300 pulses x 0.05 U/pulse = 15U
$000927c0 = 600,000 / 100,000 = 6 seconds between pulses
300 pulses x 6 sec/pulse = 1,800 secs = 0.5 hours
The $1A command segments are split as 8 hours and 3 hours
while the $16 subcommand segments are split as 10.5 hours and 0.5 hours.
The two InsulinScheduleElements in the $1A command deliver
(16+6) x 300 x 0.05U = 330U total insulin over (16+6) = 22 half hours
while the two YYYY values in the $16 subcommand deliver
a total of 315+15 = 330U of insulin over 10.5 + 0.5 = 11 hours.
Using the values of either command a 30 U/h temp basal rate
is delivered over 11 hours as requested.
1a LL NNNNNNNN 01 CCCC HH SSSS PPPP napp napp
1a 10 30512e3b 01 0252 18 3840 0111 f111 7111
$f111 describes 16 half hour entries of $111 (273) pulses each (8 hours)
$7111 describes 8 half hour entries of $111 (273) pulses each (4 hours)
16 LL BO MM NNNN XXXXXXXX YYYY ZZZZZZZZ
16 0e 00 00 fff0 000a0f8c fff0 000a0f8c
$fff0 = 65,520 (decimal) / 10 = 6552 pulses x 0.05 U/pulse = 327.6U
$000a0f8c = 659,084 / 100,000 = 6.59084 seconds between pulses
6552 pulses x 6.59084 secs/pulse = 43183 secs = 11.99 hours
From the two InsulinScheduleElements in the $1A command,
273 x (16+8) x 0.05U = 327.6U of insulin will be delivered
which matches the total encoded in the single YYYY component of $16 subcommand.
327.6U / 12 hours is the requested 27.3 U/h temp basal rate for 12 hours.
The corresponding $16 subcommand only uses a single
interval to describes the 12 hour interval using a near maximum YYYY value.
1a LL NNNNNNNN 01 CCCC HH SSSS PPPP napp napp
1a 10 2852feef 01 025e 18 3840 0111 f911 7911
$f911 describes 16 half hour entries of $111+0.5 (273.5) pulses each (8 hours)
$7911 describes 8 half hour entries of $111+0.5 (273.5) pulses each (4 hours)
16 LL BO MM NNNN XXXXXXXX YYYY ZZZZZZZZ YYYY ZZZZZZZZ
16 14 00 00 f5b9 000a0ad7 f5b9 000a0ad7 0aaf 000a0ad7
$f5b9 = 62,905 (decimal) / 10 = 6290.5 pulses x 0.05 U/pulse = 314.525U
$000a0ad7 = 658135 / 100,000 = 6.58135 seconds between pulses
6290.5 pulses x 6.58135 sec/pulse = 41399.982 secs = 11.49999 hours
$0aaf = 2,735 (decimal) / 10 = 273.5 pulses x 0.05 U/pulse = 13.675U
$000a0ad7 = 658135 / 100,000 = 6.58135 seconds between pulses
273.5 pulses x 6.58135 sec/pulse = 1799.999 secs = 0.49999 hours
From the two InsulinScheduleElements in the $1A command,
273.5 x (16+8) x 0.05U = 328.2U of insulin will be delivered
which matches the total encoded in the two YYYY components
of the '$16' subcommand of 314.525U + 13.675U = 328.2U
(ignoring possible round-off issues).
328.2U / 12 hours is the requested 27.35 U/h temp basal rate for 12 hours.
It can be seen that when the total number of pulses needed for
the duration of the temporary basal exceeds the
65535/10 = 6553 pulse limit of a YYYY value,
the PDM selects the first YYYY value to be the largest value
for a segment which ends on a half hour boundary using the
ZZZZZZZZZ value (which is computed as
(temp-basal-duration-in-secs/total-pulses-needed) x 100,000)
and then the remainder of the needed pulses are handled in the next segment.
1a LL NNNNNNNN 01 CCCC HH SSSS PPPP napp napp
1a 10 9e0aae83 01 03e1 12 3840 012c f12c 112c
$f12c describes 16 half hour entries of $12c (300) pulses each (8 hours)
$112c describes 2 half hour entries of $12c (300) pulses each (1 hour)
16 LL BO MM NNNN XXXXXXXX YYYY ZZZZZZZZ
16 0e 00 00 d2f0 000927c0 d2f0 000927c0
$d2f0 = 54,000 (decimal) / 10 = 5400 pulses x 0.05 U/pulse = 270U
$000927c0 = 600,000 / 100,000 = 6 seconds between pulses
5400 pulses x 6 sec/pulse = 32,400 secs = 9 hours
From the two InsulinScheduleElements in the $1A command,
300 x (16+2) x 0.05U = 270U of insulin will be delivered
over 9 hours which is the requested 30 U/h rate for 9 hours.
The corresponding $16 subcommand only uses a single
segment to describes this 9 hour interval
since the number of needed pulses fits in a single YYYY value.
1a LL NNNNNNNN 01 CCCC HH SSSS PPPP napp napp
1a 10 6412ce71 01 0174 16 3840 000a f00a 500a
$f00a describes 16 half hour entries of $a (10) pulses each (8 hours)
$500a describes 6 half hour entries of $a (10) pulses each (3 hours)
16 LL BO MM NNNN XXXXXXXX YYYY ZZZZZZZZ
16 0e 00 00 0898 0112a880 0898 0112a880
$0898 = 2,200 / 10 = 220 pulses x 0.05 U/pulse = 11.0U
$0112a880 = 18,000,000 / 100,000 = 180 seconds between pulses
220 * 3 min/pulse = 660 min = 11 hours
From two elements from the $1A command,
10 x (16+6) x 0.05U = 11U of insulin will be delivered
over 22 half hours which is the requested 1.0 U/h for 11 hours.
The YYYY ZZZZZZZZ from the $16 command perfectly match
with 220 pulses x 0.05U = 11U and
220 pulses x 180 secs/pulse = 39,600 secs = 11 hours.
1a LL NNNNNNNN 01 CCCC HH SSSS PPPP napp napp
1a 10 a9199d3e 01 0148 12 3840 000a f00a 100a
$f00a describes 16 half hour entries of $a (10) pulses each (8 hours)
$100a describes 2 half hour entries of $a (10) pulses each (1 hours)
16 LL BO MM NNNN XXXXXXXX YYYY ZZZZZZZZ
16 0e 00 00 0708 0112a880 0708 0112a880
$0708 = 1800 / 10 = 180 pulses x 0.05 U/pulse = 9.0U
$0112a880 = 18,000,000 / 100,00 = 180 seconds between pulses
180 * 3 min/pulse = 540 min = 9 hours
From two elements from the $1A command,
10 x (16+2) x 0.05U = 9U of insulin will be delivered
over 18 half hours which is the requested 1.0 U/h for 9 hours
which matches the YYYY ZZZZZZZZ calculations
with 180 pulses x 0.05U = 9U and
180 pulses x 180 secs/pulse = 32400 secs = 9 hours.
As described in Percentage Temporary Basal Rate section of Command 0x1A Table 1, percent temporary rates are implemented by the PDM creating a replacement insulin schedule that replaces the default basal program in effect. For the $16 subcommand, this means that up to 25 6-byte chunks might be needed to describe a 12-hour maximum temp basal using percentages which replaces a basal rate that can potentially change each half hour. Up to 25 chunks are needed instead of 24 because a 12-hour percent temporary basal rate can actually replace 25 half hour boundaries in the typical case when it isn't exactly on a half hour boundary.
The following examples are taken from Command 0x1A Table 1 using a known fixed rate basal schedule that starts at 1.0 U/h at midnight and increases by 0.1 U/h each hour up to 3.2 U/h at 11 pm. Unfortunately the packet capture for many of the examples didn't include enough of the CONtinued packets to fully work out the subsequent 0x16 command details except for two examples.
Consider the following example with the command 0x1A table 1 immediately followed by subcommand 0x16 in the same message:
1a LL NNNNNNNN 01 CCCC HH SSSS PPPP napp napp
1a 10 01ec4830 01 00f1 03 3298 000a 100c 0002
16 LL BO MM NNNN XXXXXXXX YYYY ZZZZZZZZ YYYY ZZZZZZZZ
16 14 7c 00 00e4 00d59f80 00f0 00e4e1c0 000d 00d47304
The two InsulinScheduleElements of 100c and 0002
generates an insulin schedule table of [12 12 2].
The NNNN value of $00e4 = 228 (decimal) means that there are
22.8 pulses left to deliver for the first element of 100c
(i.e., 2 half hours of 12 pulses each)
This means that 22 of the 24 pulses
in the first element are still to be delivered
(i.e., 2 pulses were missed from this interval)
which matches the PPPP value of $000a
that reduces the first insulin schedule table entry from 12 to 10
(i.e., 2 pulses were missed from this interval).
The XXXXXXXX value of $00d59f80 = 14,000,0000 (decimal) / 100,000
means that the next pulse will be delivered in 140 seconds.
napp YYYY ZZZZZZZZ
element interval pulse count interval pulse delay in secs interval time verification
00:00-00:29 $100c $00f0->240/10 = 24 $00e4e1c0->15,000,000/100,000 = 150 24 x 150 = 3600 secs
00:30-00:59
01:00-01:00 $0002 $000d-> 13/10 = 1.3 $00d47304->13,923,076/100,000 = 139.2 1.3 x 139.2 = 180.96 secs
It seems like the YYYY value for the last interval is too small
given that 2 pulses are to be delivered and there is 139 seconds between the pulses.
Perhaps this is due to some special case handling in the last runt internal.
Consider the following example with the command 0x1A table 1 immediately followed by subcommand 0x16 in the same message:
1a LL NNNNNNNN 01 CCCC HH SSSS PPPP napp napp napp napp
1a 14 fc929c7b 01 0155 06 2ec8 000c 100e 100f 0010 0003
16 LL BO MM NNNN XXXXXXXX YYYY ZZZZZZZZ YYYY ZZZZZZZZ YYYY ZZZZZZZZ YYYY ZZZZZZZZ
16 20 7c 00 0108 0090f560 0120 00bebc20 0130 00b4b239 00a0 00aba950 001a 00b1d2d6
The four InsulinScheduleElements of 100e, 100f, 0010 and 0003
generate a insulin schedule table of [14 14 15 15 16 3].
The NNNN value of $0108 = 264 (decimal) means that there are
26.4 pulses left to deliver for the first element of 100e
(i.e., 2 half hours of 14 pulses each)
This means that 26 of the 28 pulses
in the first element are still to be delivered
(i.e., 2 pulses were missed from this interval)
which matches the PPPP value of $000c
that reduces the first insulin schedule table entry from 14 to 12
(i.e., 2 pulses were missed from this interval).
The XXXXXXXX value of $0090f560 = 9,500,000 (decimal) / 100,000
means that the next pulse will be delivered in 95 seconds.
napp YYYY ZZZZZZZZ
element interval pulse count interval pulse delay in secs interval time verification
08:00-08:20 $100e $0120->288/10 = 28.8 $00bebc20->12,500,000/100,000 = 125 28.8 x 125 = 3600 secs
08:30-08:59
09:00-09:29 $100f $0130->304/10 = 30.4 $00b4b239->1,842,105/100,000 = 118.4 30.4 x 118.4 = 3599 secs
09:30-09:59
10:00-10:29 $0010 $00a0->160/10 = 16 $00aba950->11,250,000/100,000 = 112.5 16 x 112.5 = 1800 secs
10:30-10:04 $0003 $001a-> 26/10 = 2.6 $00b1d2d6->11,653,846/100,000 = 116.5 2.6 x 116.5 = 303 secs
The calculated 303 seconds time for the last runt interval based on the 0x16 timing parameters matches the :05 offset when this percent temp basal was run from an half hour boundary. Since the pulse delay for the first interval turns out to be 125 seconds and 2 pulses were missed in this interval due to the 5 minute offset into the hour, this indicates that this percent temp command was run at ((2+1) x 125) - 95 = 280 seconds which would be just less than 5 minutes past the hour.
Packet information detail for temporary basal runs can be found in Command 1A Table 1. Many fixed rate temporary basal for 1/2 hour examples can found here.
The $16 subcommand for temporary basal can only be used when the current Pod Progress State is between 8 and 12 and no temporary bolus is currently active. The $16 subcommand must always appear directly after the $1A Command for Table 1 (Temporary Basal Schedule) and cannot be combined with any other commands in the same message.