Command 16 Temp Basal

0x16 Temporary Basal Rate Follow-on Command

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:

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 Options acrrrrrr, formerly RR Reminders, (typical PDM values $00, $3c, $40 and $7c):

  • a bit ($80) for acknowledgement beep (temp basal command received), not used by PDM (see below).
  • c bit ($40) for completion beep (temp basal command completed).
  • rrrrrr (6 bits) # of minutes ($3c = 60 minutes) between Program Reminder beeps.

• MM (1 byte): Always observed to be 00.

• NNNN (2 bytes): Remaining 1/10th of a 0.05u pulse of insulin to deliver for first entry (i.e., # of pulses x 10). NNNN must be <= the first YYYY value, for fixed rate temp basal it will be same as the only YYYY value.

• XXXXXXXX (4 bytes): Delay until next 1/10th of a 0.05u pulse, expressed in microseconds (delay to next pulse in 100s of milliseconds). XXXXXXXX must be <= the first ZZZZZZZZ value.

• 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 completion of the temporary basal rate.

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

• 0e Length of command is $0e bytes ($0e is very typical for a fixed rate temp basal)
• 7c BO $40 completion beep, Program Reminder beeps every $3c = 60 minutes
• 00 MM always 00
• 014a NNNN $014a = 330 (decimal) / 10 = 33 pulses remaining
• 00f9b074 XXXXXXXX = 16,363,636 / 100,000 = 163 seconds to the next pulse
• 014a YYYY $014a = 330 (decimal) / 10 = 33 pulses to deliver
• 00f9b074 ZZZZZZZZ = 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

Zero temp basal rates are handled special and have a completely different encoding for Eros and Dash.

0 U/h for 0.5 hours (Eros)

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).

0 U/h for 0.5 hours (DASH)

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).

0 U/h for 3.0 hours (Eros)

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.

0 U/h for 3.0 hours (DASH)

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).

Fixed Temp Rate Examples

30 U/h for 0.5 hours

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.

0.05 U/h for 0.5 hours

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.

1.0 U/h for 0.5 hours

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.

30 U/h for 12 hours

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.

30 U/h for 11 hours

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.

27.30 U/h for 12 hrs

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.

27.35 U/h for 12 hrs

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.

30 U/h for 9 hours

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.

1.0 U/h for 11 hours

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.

1.0 U/h for 9 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.

Percentage Temporary Basal Rates

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.

Temp basal: +20% for 1 hour @ 12:01 a.m.

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.

Temp basal: -20% for 2.5 hour @ 8:05 a.m.

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.

Detailed Packet Information

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.

Restrictions

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.