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 a response to the next submitted command. The PDM incorporates this returned fault code into a multi-part PDM Ref code # that Insulet tech support requests for a failed Pod. 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. 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

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 shown below. All fields are fixed width and zero padded.

Ref: AA-BBBCC-DDDEE-FFF

• AA (2 digits): Type: 19 - Pod error, 17 - Occlusion detected, 11 - PDM error
• BBB (3 digits): Various flags & state from the VV byte from Pod Info, Type 2 if available for AA == 19 else 000
• CC (2 digits): # of hours Pod active at the time of the fault (00 - 80), Pod Info, Type 2 SSSS/60
• DDD (3 digits): # of units of insulin delivered (000-200), Pod Info, Type 2 NNNN/20
• EE (2 digits): # of units of insulin in reservoir (00 - 50) or 51 if > 50U, Pod Info, Type 2 RRRR/20
• FFF (3 digits): Pod fault event code for AA == 19 or AA == 11 else 000, Pod Info, Type 2 PP byte

An AA value of 11 for PDM failure will be used for the Ref Code if the Pod fails with fault code of 049. This is because this particular fault is 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). An AA 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, the AA value will be `19'.

A non-zero 3-digit BBB decimal value is taken directly from the VV byte from the Pod Info, Type 2 response. 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 CC 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 DDD 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.

The 2-digit EE 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 EE 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

AA-BBBCC-DDDEE-FFF
19-00500-00251-092

• AA = 19, Pod fault type failure
• BBB = 005 = 0x05, the lower nibble of 5 is a Pod progress of 5 (Priming completed)
• CC = 00, the Pod was active for 0 hours before faulting
• DDD = 002, the total insulin delivered before the fault was 2 U
• EE = 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

AA-BBBCC-DDDEE-FFF
19-02404-01851-064

• AA = 19, Pod fault type failure
• BBB = 024 = 0x18, the lower nibble of 8 is a Pod progress of 8 (Running with > 50 U)
• CC = 04, the Pod was active for 4 hours before faulting
• DDD = 018, the total insulin delivered before the fault was 18 U
• EE = 51, the reservoir level was > 50 U at the time of the fault
• FFF = 064 (0x40), the Pod's fault code was 040

The BBB value having the 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

AA-BBBCC-DDDEE-FFF
17-00067-14926-000

• AA = 17, Occlusion detected type failure
• BBB = 000
• CC = 67, the Pod was active for 67 hours before the occlusion fault
• DDD = 149, the total insulin delivered before the fault was 149 U
• EE = 26, the reservoir level was 26 U at the time of the fault
• FFF = 000

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

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 AA 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 AA 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's helpful to be able to provide Insulet tech support a PDM style Ref code on Pod faults for their internal tracking & diagnostic purposes. Newer versions of DIY closed loop software will print the full 15-digit PDM style Ref code, but various parts of the 6 section AA-BBBCC-DDDEE-FFF Ref code can be derived using the 3-digit decimal fault code value and other information from the Pod's status.

• AA: Use 19 for all reported fault code values or 17 for an occlusion.
• BBB: Use 000 which the value used when this information is not available, but if it 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.
• CC: Use the # of hours Pod was active, if not available use your best guess.
• DDD: 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.
• EE: 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.

All fields are zero padded decimal values that are rounded down to the nearest whole integer value. A fault code of 049 is due to an error in the controlling software and should never be called into Insulet as this is a case where the pod failure is completely due to the DIY closed loop app and not the Pod itself.

If you decide to call Insulet tech support about a faulted Pod, don't initially volunteer that you not using a PDM. When Insulet tech support asks for the PDM Ref code, then 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). 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 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 what 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.