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 or 17 for Occlusion fault type
• VVV (3 digits): VV byte from Pod Info, Type 2 with various flags & state for AA == 19 else 000
• 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): Fault event code for AA == 19 or else 000, 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 displayed Pod Settings Insulin Delivered 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 running a Replace Pod on a faulted pod in Loop.

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 U
• RR = 51, the reservoir level was > 50 U at the time of fault
• FFF = 092 (0x5C), the Pod's fault code was 092

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 U
• RR = 51, the reservoir level was > 50 U at the time of the fault
• FFF = 064 (0x40), the Pod's fault code was 040

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
• HH = 67, the Pod was active for 67 hours before the occlusion fault
• III = 149, the total insulin delivered before the fault was 149 U
• RR = 26, the reservoir level was 26 U at the time of the fault
• FFF = 000

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

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.

Note on Occlusion 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.

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 enough you can find this value from the VV byte in the Pod Info, Type 2 response in the Omnipod communication log found in the Loop Report.
• HH: Use the # of hours Pod was active, if not available use your best guess.
• III: 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: Use the # of units of insulin left in the reservoir, use 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.

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