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. 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 VV byte from Pod Info, Type 2 with various flags & state; the lowest nibble of this value is the Pod progress value, typically 8 for normal operation or 9 for low reservoir
• 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, PP byte from Pod Info, Type 2

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 Replace Pod 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 but internal PDM constants that are 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 # 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 # 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 # 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 # 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.

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 value since FFF was a reset type fault
• III = 000, initial default value since FFF was a reset type fault
• RR = 51, initial default value since FFF was 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 Pod was active, 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: 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 file, 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 021602 and breaking it into sections as described in Pod Info, Type 2 results in this breakdown of the 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

The actual fault code is the PP field which was 0x40 or 064 which matches the reported Internal pod fault value. The other relevant fields from this fault response needed to derive the PDM Ref Code are NNNN (0a28), SSSS (11be), RRRR (014c) and VV (89).

• TT = 19 (a 064 fault is not an occlusion or 049 fault)
• VVV = VV = 0x89 = 137
• HH = SSSS/60 = 0x11be/60 = 4542/60 = 75
• III = NNNN/20 = 0x0a28/20 = 2600/20 = 130
• RR = RRRR/20 = 0x014c/20 = 332/20 = 16
• FFF = PP = 0x40 = 064

Thus the PDM Ref Code # TT-VVVHH-IIIRR-FFF for this 064 fault is 19-13775-13016-064.