Command 16 Temp Basal

The 0x16 Follow-on Command for Temporary Basal Rate

The 0x16 command is a 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 RR MM NNNN XXXXXXXX YYYY ZZZZZZZZ [YYYY ZZZZZZZZ...]

• 16 (1 byte): Mtype value of $16 specifies follow-on for a 1A command Table 1 (temp basal).
• 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. For all fixed rate temp basals, LL will be 0e (i.e., there is only one 6-byte YYYY ZZZZZZZZ chunk).
• RR (1 byte): Reminders flags - $40 bit set for Confidence Reminder, $3C bits set for Program Reminder
• MM (1 byte): Always observed to be 00.
• NNNN (2 bytes): Remaining insulin to deliver for first element, in terms of # of 0.05U 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 the next pulse, expressed in counts of 100kHz timer (i.e, # of microseconds x 10). XXXXXXXX must be <= the first ZZZZZZZZ value, for fixed rate temp basal it will be same as the only ZZZZZZZZ value.
• YYYY (2 bytes): Total insulin for this insulin schedule table entry, in terms of # of 0.05U pulses x 10.
• ZZZZZZZZ (4 bytes): Delay between pulses for this insulin schedule entry, expressed in counts of 100kHz timer (i.e, # of microseconds x 10).

Consider the following fixed temp basal rate example of 1.10 U/h for 1.5 hours:

16 LL RR MM NNNN XXXXXXXX YYYY ZZZZZZZZ
16 0e 7c 00 014a 00f9b074 014a 00f9b074

• 0e Length of command is $0e bytes (constant for fixed rate temp basal)
• 7c RR both Confidence and Program Reminders enabled
• 00 MM always 00
• 014a NNNN $014a = 330 (decimal) / 10 = 33 pulses remaining
• 00f9b074 XXXXXXXX = 16,363,636 / 100,000 = 163 seconds to 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.56060) / 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 as it does for all fixed rate temporary basal 0x16 commands.

Fixed Temp Rate Examples

30 U/h for 0.5 hours

16 LL RR MM NNNN XXXXXXXX YYYY ZZZZZZZZ
16 0e 7c 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

16 LL RR MM NNNN XXXXXXXX YYYY ZZZZZZZZ
16 0e 7c 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

16 LL RR MM NNNN XXXXXXXX YYYY ZZZZZZZZ
16 0e 3c 00 0064 0112a800 0064 112a8808
    $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 1/2 hours is the requested 1.0 U/h rate and 3 minutes between pulses * 10 pulses = 30 minutes as expected.

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 0x16 command, 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 if 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 RR 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 RR 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.