PDM Ref Codes

PDM Ref Codes

When a Pod fails, it will emit a screeching sound (it becomes a "screamer") and creates an 8-bit fault event code that is reported to the PDM or controlling app as part of a special detailed fault response to the next submitted command. The PDM incorporates this returned fault information into a multi-part PDM Ref code #. These PDM Ref #'s are saved in the PDM's non-volatile Alarm history and can be retrieved by examining the details for a Pod alarm failure. These Ref code #'s' encode various key pieces of information about the Pod at the time of the fault (e.g., # of hours active, amount of insulin used, amount of insulin left in the reservoir, whether a bolus was in progress, etc). Thus these Ref codes are a succinct (albeit in a previously obscure) way to encode the condition of a faulted Pod for Insulet. Future versions of Loop will automatically compute and display the PDM Ref Code for all non-user error pod faults. Hopefully in time, understanding Ref code #'s might also be a convenient way for Omnipod DIYers to concisely share Pod fault information as well.

Ref Code Encoding

For all Pod faults values except 049, the PDM Ref # is a 15-digit decimal value broken into 4 sections separated by dashes which is actually composed of 6 different decimal values as Ref: TT-VVVHH-IIIRR-FFF. All fields are fixed width zero padded decimal values.

• TT (2 digits): Type of Ref: 19 for Pod error type (for all fault codes except 020 && 049) or 17 for Occlusion fault (fault code 020)
• VVV (3 digits): 000 for TT == 17 or information not available or Pod Info, Type 2 VV byte with various flags & state; the 0x10 bit of this value will be set if a bolus was in progress and the lowest nibble of this value is the Pod progress, typically 0x8 for normal operation or 0x9 for low reservoir (<= 50 U)
• HH (2 digits): # of hours Pod active at the time of the fault (00 - 80), Pod Info, Type 2 SSSS/60
• III (3 digits): # of units of insulin delivered (000-200), Pod Info, Type 2 NNNN/20
• RR (2 digits): # of units of insulin in reservoir or 51 if > 50U (00 - 51), Pod Info, Type 2 RRRR/20
• FFF (3 digits): 000 for TT == 17 else fault code, Pod Info, Type 2 PP byte

An TT value of 17 indicating an occlusion detected error will be used if the Pod fails with a fault code of 020. For all other fault codes that generate a Ref code (besides 049 which is treated as a PDM failure), the TT value will be 19.

The 3-digit VVV decimal value is taken directly from the VV byte from the Pod Info, Type 2 response. If a non-zero value, the low nibble of this byte value is actually the Pod Progress which is 0x8 for running with a reservoir level of > 50 U or 0x9 when running with <= 50U. The high nibble of this byte value contains various bits of information about internal pod state. Of particular note is that the 0x10 bit will be set if a bolus was in progress at the time of the fault.

The 2-digit HH field is the whole number of hours that the Pod was active before it faulted. This value is obtained by taking the SSSS word from the Pod Info, Type 2 response and dividing by 60.

The 3-digit III field is the whole number of units of U100 insulin that the Pod delivered before it faulted. This value is obtained by taking the NNNN word from the Pod Info, Type 2 response and dividing by 20 (the number of pulses in a unit of U100 insulin). This value includes the pulses used for priming and cannula insertion which typically amount to an additional 2.75U to 2.85U which is not included in Loop's Pod Settings Insulin Delivered value but is included in the Read Pod Status raw Pulse Count value.

The 2-digit RR field is the whole number of units of U100 insulin in the reservoir at the time of the fault. If the reservoir has more than 50 U left, then a value of 51 is used. This value can be obtained by taking the RRRR word from the Pod Info, Type 2 response and simply dividing by 20 (the number of pulses in a unit of U100 insulin). This works even for the > 50U where the Pod's uses a special RRRR value of 0x03FF (1023) which still results in an RR of 51 when divided by 20.

A non-zero 3-digit FFF field is the 8-bit fault code returned by Pod on its first response after the detected a failure and starts to scream. The derived meanings for the various values can be found in fault event codes. Except for a limited number of special cases for Occlusion, Empty reservoir or Pod expired Pod failures, these fault codes are displayed as an Internal pod fault when executing a Read Pod Status or Replace Pod command on a faulted pod in Loop.

Reset Faults

The fault codes 013, 014, 015, 016, 018, 030, 034, 052, 054, 059, 060 and 079 occur as a result of a processor result (or from the pod's reset handling). For these types of reset faults, a number of internal pod variables will be reinitialized to their initial starting values including active time, insulin delivered, and reservoir level. Thus for these fault codes, the HH, III and RR values are not the actual # of hours, units of insulin delivered & units remaining in the reservoir but they will be their initial default values of 00, 000 and 51 respectively. Thus for these reset type fault codes, the PDM Ref code will then be 19-VVV00-00051-FFF.

Special 049 Fault Code Handling

If a Pod fails with an fault code of 049, a special fixed Ref code format of TT-XXX-YYYY-FFFFF is used with an TT type field value of 11 that indicates a PDM failure type. This is because this particular Pod fault is actually caused by the controlling software issuing a Pod command incorrectly (e.g., issuing a temporary basal rate without cancelling an already in progress temporary basal rate). For an 049 Pod fault, the PDM Ref Code is always 11-144-0018-00049. The 144 and 0018 values are not anything that the faulting Pod provides, rather they are simply internal PDM constants used only for the 049 Pod fault.

Occlusion Fault Reporting

The PDM will only report "Occlusion detected" for a fault code of 020. For other occlusion-like Pod faults, the PDM treats this as any other Pod fault and generates a full Ref code with an TT of 19. Versions of Loop through at least V2.2.4 had also mapped the occlusion-like fault codes of 090, 096, 097, 098, 102, 103, 104, 105 & 106 as occlusions. Future versions of Loop that display a full 15-digit PDM-style Ref code for Pod faults will treat the occlusion-like fault codes of 090, 096, 097, 098, 102, 103, 104, 105 & 106 as a Pod error and generate a full 15-bit Ref code with an TT of 19 to match the PDM behavior and generate the same Ref codes for these occlusion-like Pod failures.

Example 1: PDM Ref Code for Internal Pod Fault 092 During Pod Setup

Ref: TT-VVVHH-IIIRR-FFF
     19-00500-00251-092

• TT = 19, Pod fault Type failure
• VVV = 005 = 0x05, the lower nibble of 5 is a Pod progress of 5 (Priming completed)
• HH = 00, the Pod was active for 0 hours before faulting
• III = 002, the total insulin delivered before the fault was 2.x U
• RR = 51, the reservoir level was > 50 U at the time of fault
• FFF = 092 = 0x5C, the Pod's fault code was 092 (Prime open count too low)

Example 2: PDM Ref Code for Internal Pod Fault 064 During a Bolus

Ref: TT-VVVHH-IIIRR-FFF
     19-02404-01851-064

• TT = 19, Pod fault Type failure
• VVV = 024 = 0x18, the lower nibble of 8 is a Pod progress of 8 (Running with > 50 U)
• HH = 04, the Pod was active for 4 hours before faulting
• III = 018, the total insulin delivered before the fault was 18.x U
• RR = 51, the reservoir level was > 50 U at the time of the fault
• FFF = 064 = 0x40, the Pod's fault code was 064 (Encoder open count too high)

The VVV value having its 0x10 bit set indicates that bolus was in progress at the time of the 040 Pod fault.

Example 3: PDM Ref Code for Occlusion Detected Fault

Ref: TT-VVVHH-IIIRR-FFF
     17-00067-14926-000

• TT = 17, Occlusion detected Type failure
• VVV = 000, always 000 for an occlusion fault
• HH = 67, the Pod was active for 67 hours before the occlusion fault
• III = 149, the total insulin delivered before the fault was 149.x U
• RR = 26, the reservoir level was 26.x U at the time of the fault
• FFF = 000, always 000 for an occlusion fault

For Occlusion faults (Ref code TT field == 17), the VVV and FFF fields are always reported as 000.

Example 4: PDM Ref Code for a Reset Type Fault

In this example, the Pod failed with an Internal Pod Fault 016 which is a reset type fault type. For these types of faults, the HH, III and RR values are reset to their initial default values and do not represent the actual # of hours of pod life, units of insulin delivered, or units of insulin remaining in the reservoir and thus the PDM Ref code will be of the form 19-VVV00-00051-FFF.

Ref: TT-VVVHH-IIIRR-FFF
     19-13700-00051-016

• TT = 19, Pod fault Type failure
• VVV = 137 = 0x89, Pod progress state of 9 (low reservoir)
• HH = 00, initial default HH value since 016 is a reset type fault
• III = 000, initial default III value since 016 is a reset type fault
• RR = 51, initial default RR value since 016 is a reset type fault
• FFF = 016 = 0x10, the Pod's fault code was a reset type fault of 016 (Reset due to SAWCOP)

When You Get a Pod Fault

Any time a Pod faults and turns into a "screamer", the insulin delivery has stopped and the Pod should be replaced as soon as possible. A faulted Pod will no longer respond to any commands except for Deactivate Pod (Loop's Replace Pod command) and a non-zero type Status Request (i.e., a current version of Loop's Read Pod Status and Read Pulse Log commands). It is always a good practice to do a Read Pod Status before deactivating the Pod for a number of reasons. If Loop hasn't yet seen the Pod fault, doing a Read Pod Status command allows Loop to capture and display the fault code value as well as other information about the Pod that can be used to derive most of the Ref code fields (screen capture the Read Pod Status output display). Next, do a Read Pulse Log command to capture diagnostic information about the recent pump activity. Finally, do a Loop Issue Report to save a copy of the Loop state including the information on the Pod fault, Omnipod communications and the recent pump activity. If the Issue Report is not done immediately, it can be still be performed in the next couple of days which should hopefully still have the fault information buried in the Omnipod communications log. If it is believed that Loop might have caused the Pod failure in some way, post the resulting Loop Report on Zulip as an attachment along with any relevant information about what was happening with the Pod at the time of the fault.

Deriving a PDM Ref Code

It can be helpful to be able to provide Insulet tech support a PDM style Ref code on Pod faults for their internal tracking & diagnostic purposes. However a fault code of 049 is always due to the controlling software and never the Pod itself and thus should never be called into Insulet but instead reported only to the appropriate DIY support community.

Newer versions of DIY closed loop software will print the full PDM style Ref code for a Pod fault, but various parts of the 6 section TT-VVVHH-IIIRR-FFF Ref code can be derived using the 3-digit decimal fault code value and other information from the Pod's status. All fields are zero padded decimal values that are rounded down to the nearest whole integer value.

• TT: Use 19 for all reported fault code values or 17 for an occlusion fault.
• VVV: Use 000 which the value used when this information is not available, but if you're technical and determined enough you can find this value from the VV byte in the Pod Info, Type 2 fault response in the Omnipod communication log found in the Loop Report.
• HH: For a non reset type fault, use the # of hours of Pod use before faulting, if not available use your best guess.
• III: For a non reset type fault, use the # of units of insulin delivered. This value is Loop's Read Pod Status Pulse Count value times 0.05U or can be approximated by taking the Loop's Pod Settings Insulin Delivered value plus 2.8U. If this information is not available, just use your best guess.
• RR: For a non reset type fault, use the # of units of insulin left in the reservoir or 51 if 50+ U or if this information is not available.
• FFF: Use the reported 3-digit decimal fault code value or 000 for an occlusion fault.

Note that for a reset type fault code of 013, 014, 015, 016, 018, 030, 034, 052, 054, 059, 060 or 079, the PDM Ref code will have their initial default values for HH, III and RR instead of values based on the actual # of hours, units of insulin delivered and units in reservoir. Thus for these reset type fault codes, the PDM Ref code will be 19-VVV00-00051-FFF.

If you decide to call Insulet tech support about a faulted Pod, it's probably best to not initially mention that you were not using a PDM. When Insulet tech support asks for the PDM Ref (Alarm) code, there are a couple of ways to go. If you have a PDM available so that you can provide its serial #, you can could give the derived or actual Ref code and not even mention that this Ref # didn't come from your PDM's Alarm history (especially if you have exact values from looking at the Omnipod communications log or from the controlling DIY app). Alternately you can simply say that you weren't using a PDM when the Pod faulted (which means that they shouldn't be expecting to a PDM serial #) and if appropriate/needed that the Ref code was derived. Insulet tech support is generally willing to offer a replacement for a faulted Pod even if it was being run with DIY software, but it is best not to ask for or expect this. As a courtesy, ask the Insulet tech support person if Insulet might want the faulted pod back for analysis by their engineers. This hopefully can help build good will between the Omnipod DIY community and Insulet Corporation in addition to potentially helping Insulet get a better understanding of potential problems occurring in the field due to things like manufacturing variations.

Example #5: Deriving a PDM Ref Code from a Loop Report

In this example, a Loop user had an Internal pod fault 064 failure. After executing an Issue Report and then saving & examining the resulting Loop Report, the actual Pod Info, Type 2 fault response was found near the end of the "Device Communication Log" section.

* 2020-04-17 04:24:42 +0000 Omnipod 1F020DAD receive 1f020dad30180216020d000002090a284011b8014c11be0000199d09030d02ee

Extracting the hex bytes starting with 0216020d and breaking them into sections as described by the description in Pod Info, Type 2 results in the following fault response values.

02 16 02 0J 0K LLLL MM NNNN PP QQQQ RRRR SSSS TT UU VV WW 0X YYYY
02 16 02 0d 00 0002 09 0a28 40 11b8 014c 11be 00 00 19 9d 09 030d 02ee

The actual fault code is the PP field which 40 (0x40) or 064 which matches the reported 3-digit decimal Internal pod fault value. The other relevant fields from this fault response needed to derive the PDM Ref # of the form TT-VVVHH-IIIRR-FFF are VV (19), SSSS (11be), NNNN (0a28) and RRRR (014c).

• TT = 19, default Type of 19 since it was not an 020 Occlusion or an 049 ("PDM") fault
• VVV = VV = 0x19 or 025 as a 3-digit decimal value
• HH = SSSS/60 = 0x11be/60 = 4542/60 = 75 hours of pod life
• III = NNNN/20 = 0x0a28/20 = 2600/20 = 130 total units of insulin delivered
• RR = RRRR/20 = 0x014c/20 = 332/20 = 16 units left in the reservoir
• FFF = PP = 0x40 or 064 fault code as a 3-digit decimal value

Thus the PDM Ref Code # for this Pod fault would be 19-02575-13016-064.

Example #6: Generating a PDM Ref Code using "Read Pod Status"

For this example, the pod started "screaming" and the user remembered to do a "Read Pod Status" command (and even to take a screenshot of it) before deactivating the pod.

Read Pod Status...

Pod Active: 2 days, 18 hours, 2 minutes
Delivery Status: Temp basal running
Pulse Count: 2679
Reservoir Level: 37.95 U
Last Bolus Not Delivered: 0.25 U
Alerts: No alerts
RSSI: 34
Receiver Low Gain: 0

Fault: Internal pod fault 068
Previous pod progress: Low reservoir
Fault time: 2 days, 17 hours, 59 minutes

From this information a PDM Ref Code of the form TT-VVVHH-IIIRR-FFF can be easily generated as follows:

• TT = 19, pod fault was not an 020 or an 049
• VVV = 000, fill-in initial (default) value
• HH = 65 hours of pod life ("Fault time" of 2 days * 24 hrs/day + 17 hours, rounded down)
• III = 133 total units of insulin delivered ("Pulse Count" of 2679 * 0.05 U/pulse, rounded down)
• RR = 37 units left in the reservoir ("Reservoir Level" of 37.95 U, rounded down)
• FFF = 068, the reported "Internal pod fault" value

Thus a PDM Ref Code for this failure example would be 19-00065-13337-068 by just using a default VVV value of 000. However an even more exact PDM Ref Code can be generated for this example by using more detailed knowledge of the VVV field. Since a bolus was in progress at the time of fault (as indicated by a non-zero "Last Bolus Not Delivered" value), the 0x10 bit should be set. Since the "Previous pod progress" was Low reservoir, the pod progress state for the lower nibble is 0x9 (as taken from Pod progress). Thus a better VVV value would be 0x10+0x09 = 0x19 or 025 which results in a (probably) exact PDM Ref Code of 19-02565-13337-068.

Example #7: Creating a guess PDM Ref Code

In this hypothetical example, a pod failed with a 066 fault a couple hours after its nominal 72 hour pod life. The user remembered that the reservoir icon in the HUD on the main page still hadn't starting displaying values and that they have been using about 40 units of insulin daily. Using this knowledge, an guess PDM Ref Code for this pod fault can be created:

• TT = 19, standard type value for all pod failures but 020 and 049
• VVV = 008, Pod progress of 8 (Running with > 50U) and no bolus was in progress
• HH = 74 hours of pod life (the fault occurred a couple of hours past the nominal 72 hour pod life)
• III = 130 total units of insulin delivered (guess of 40U/day * 3 days + 10U slop for pod setup and a couple additional hours)
• RR = 51 units left in the reservoir (> 50U)
• FFF = 066, value from Internal pod fault 066 message seen during pod replacement

Thus an approximate guess PDM Ref Code for this failure would be 19-00874-13051-066.