Skip to content

PDM Ref Codes

Jump to bottom Edit New page
Joe Moran edited this page May 23, 2023 · 26 revisions

PDM Ref Codes

A faulted Omnipod emits 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 Reference (Ref) code number. These PDM Ref code #'s are saved in the PDM's non-volatile memory for later use. For the Omnipod Eros ("Classic") PDM these can be found by examining the details for a Pod alarm failure under Alarm history. For the Omnipod Dash these can be under Notifications & Alarms under History. 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) as well as the fault code itself. These Ref codes are a succinct (albeit in a previously obscure) way to encode the condition of a faulted Pod for Insulet. Ref code #'s can also be a convenient way for Omnipod DIYers to concisely share Pod fault information as well.

In Loop 3.x the Ref Code can typically be found under Previous Pod Information (for the previous Pod) or Device Details (for the current Pod). In Loop 2.x or FreeAPS, the PDM Ref code is prominently displayed when doing a Replace Pod operation on a faulted Pod (and can also be displayed by running a Read Pod Status command on a faulted Pod), but this Ref Code value is not saved and so it should be recorded (or captured with a screen save) for later reference. Generating a "Loop Report" for an expected faulted Pod is always a good thing to do and will allow the PDM Ref Code to be found or re-derived for the faulted Pod if needed and will provide information to DIY developers to better understand what happened. Including the PDM Ref Code (which includes the fault code value) when reporting faulted Pods on public forums is appreciated by DIY developers.

Ref Code Encoding

For all Pod fault values (except for an Eros 049 fault code), the PDM Ref Code 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): Ref Code Type
  • VVV (3 digits): [000-255] various flags & state including the Pod progress
  • HH (2 digits) [00-80] # of whole hours that the Pod was active before faulting
  • III (3 digits): [000-200] # of whole units of insulin delivered
  • RR (2 digits): [00-51] # of whole units of insulin remaining in reservoir or 51 if > 50U
  • FFF (3 digits): [000-255] decimal Pod fault code value

The 3-digit VVV decimal value is taken directly from the VV byte from the Pod fault response except for an Eros occlusion fault (TT == 17, fault code == 020) when it is always reported as 000. If a non-zero value, the low nibble (4 bits) of this byte value is 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 fault 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 fault 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 that is not included in Loop's 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 fault response and dividing by 20 (the number of pulses in a unit of U100 insulin). This works even for the > 50U case where the Pod uses a special RRRR value of 0x03FF (1023) which will result 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 except for an Eros Occlusion fault (TT == 17, fault code == 020) where it is reported as 000. The derived meanings for the various values can be found in fault event codes. Except for Occlusion (020), Empty reservoir (014) Pod expired (028) and (the currently unused) Auto-off (041 to 048) faults, these fault codes represent an Internal pod fault.

Special Eros 049 (0x31) Fault Code Handling

An Eros 049 (0x31) Pod fault uses a special alternate PDM Ref Code format of TT-XXX-YYYY-FFFFF. The unique TT type field value of 11 indicates a PDM failure type. This particular Pod fault is actually caused by the controlling software (i.e., the PDM or Loop) issuing a Pod command incorrectly (e.g., issuing a temporary basal rate without cancelling an already in-progress temporary basal rate). For an Eros 049 Pod fault, the PDM Ref Code is always a fixed 11-144-0018-00049 value. The 144 and 0018 fields are not anything that the faulting Eros Pod provides, rather they are simply internal Eros PDM constants used only for an Eros 049 Pod fault.

A DASH 049 (0x31) Pod fault is handled by the DASH PDM as any other Pod fault and thus its PDM Ref Code will have a standard TT of 19 with VVV, HH, III and RR values derived from the Pod fault response.

Reset Faults

The 013, 014, 015, 016, 018, 030, 034, 052, 054, 059, 060 and 079 fault codes occur as a result of a Micro Processor Unit (MCU) reset on both Eros and DASH Pods. The DASH-specific 214 (0xd6) and 215 (0xd7) fault codes are also reset type faults, but their underlying cause and meaning are currently not understood. For these types of reset faults, a number of internal pod variables will be re-initialized to their initial starting values including active time, insulin delivered, and reservoir level. Thus for these reset type fault codes, the HH, III and RR values are not the actual # of hours, units of insulin delivered & units remaining in the reservoir at the time of the fault but their initial default values of 00, 000 and 51 respectively. Thus for these reset type fault codes, the PDM Ref code will always be of the form 19-VVV00-00051-FFF. Reset type faults are generally caused by excessive DIY Pod load, static electricity &/or marginal/defective Pods.

Occlusion Fault Reporting

The Eros and DASH PDMs will report "Occlusion detected" for a fault code of 020. For occlusion faults, the Eros ("Classic") PDM Ref Code will always have a VVV and FFF values of 000 while the DASH PDM Ref Code will have the usual derived values for all the PDM Ref Code fields.

Example PDM Ref Codes

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, 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, 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 0x08 is a Pod progress of 8 (Running with > 50 U) & the 0x10 bit being set indicates that bolus was in progress at the time of the fault
  • 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 = the Pod's fault code was 064 = 0x40 (Encoder open count too high)

Example 3: PDM Ref Code for an Occlusion Detected Fault

An Eros PDM Ref Code for an Occlusion fault will always have 000 for both VVV and FFF while a DASH PDM Ref Code for an Occlusion fault will always have a non-zero VVV value and a fixed FFF value of 020 as shown in these examples.

Eros PDM Occlusion Fault

Ref: TT-VVVHH-IIIRR-FFF
     17-00067-14926-000
  • TT = 17, Occlusion detected type failure
  • VVV = 000, always 000 for an Eros 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+ U
  • RR = 26, the reservoir level was 26+ U at the time of the fault
  • FFF = 000, always 000 for an Eros occlusion fault

DASH PDM Occlusion Fault

Ref: TT-VVVHH-IIIRR-FFF
     17-02467-14926-020
  • TT = 17, Occlusion detected type failure
  • VVV = 024 = 0x18, the lower nibble of 0x08 is a Pod progress of 8 (Running with > 50 U) & the 0x10 bit being set indicates that bolus was in progress at the time of the 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+ U
  • RR = 26, the reservoir level was 26+ U at the time of the fault
  • FFF = 020, always 020 for a DASH occlusion fault

Example 4: PDM Ref Code for a Reset Type Fault

In this example, the Pod failed with Internal Pod fault code 018 (Reset due to Low Voltage Detect) 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-018
  • TT = 19, Pod fault type failure
  • VVV = 137 = 0x89, lower nibble value of 0x09 is Pod progress state of 9 (low reservoir)
  • HH = 00, initial default HH value since 018 is a reset type fault
  • III = 000, initial default III value since 018 is a reset type fault
  • RR = 51, initial default RR value since 018 is a reset type fault
  • FFF = 018 = 0x12, the Pod's fault code was a reset type fault of 018 (Reset due to Low Voltage Detect)

Deriving Ref Codes

It can be helpful to be able to provide Insulet tech support a PDM style Ref code for unexpected Pod faults (i.e., not for out of insulin or exceeding 80 hours) for their internal tracking & diagnostic purposes. However, a Pod fault code of 049 is always due to an error in the controlling software (i.e., Loop) and never the Pod itself and thus should never be called into Insulet for DIY use but should instead definitely reported only to the appropriate DIY support community along with a captured "Loop Report". Various parts of the standard 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 most internal Pod fault codes 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 communication log contained 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 the Read Pod Status Pulse Count value times 0.05U in Loop 2.x or FreeAPS or can be approximated by taking the Loop's Pod Settings Insulin Delivered value plus 2.8U (an average amount consumed during Pod setup). 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 on Eros and 020 for an occlusion fault on DASH.

Note that for a reset type fault code of 013, 014, 015, 016, 018, 030, 034, 052, 054, 059, 060 or 079, the Eros and DASH 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 best not to initially mention that you were not using a PDM if you can. If 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 the controlling DIY app or deriving it from the Omnipod communications log). Alternately you can simply state 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 Pod for any faulted Pod (except for out of insulin or exceeding 80 hours) even if it was being run with DIY software, but it is best not to ask 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. Also, you can ask the Insulet support representative if they know if there have been other reported Pod faults from the Lot number of your Pod.

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

In this example a Loop 2.x user had an Internal pod fault 064 failure and didn't record the displayed Ref code, but did remember to do a "Issue Report" and later examined the resulting Loop Report. The actual Pod Info, Type 2 fault response was found in the "Device Communication Log" section (by searching for 0216020)

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

Extracting the hex bytes starting with 021602 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 whole units of insulin delivered
  • RR = RRRR/20 = 0x014c/20 = 332/20 = 16 whole units left in the reservoir
  • FFF = PP = 0x40 or 064 fault code as a 3-digit decimal value

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

Example #6: Creating an approximate PDM Ref Code

In this hypothetical example, Loop 2.x or FreeAPS had a Pod failed with a 066 Pod fault a couple hours after its nominal 72 hour pod life and the user didn't record the PDM Ref code displayed during the Replace Pod operation on the faulted Pod. The user remembered that the reservoir icon in the HUD on the main page still hadn't starting displaying values and that they use about 40 units of insulin daily. Using this knowledge, an approximate PDM Ref Code for this Pod failure can be created:

  • TT = 19, standard type value for all true Pod failures except 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 of use)
  • RR = 51 units left in the reservoir (> 50U)
  • FFF = 066, the reported fault code value

Thus an approximate guess PDM Ref Code for this Pod failure would be 19-00874-13051-066. If the user was running Loop 3.x and remembered to check soon enough, the Ref code can hopefully found under Previous Pod Information instead of having to create an approximate Ref code as in this example.

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 command (i.e., the Loop 2.x & FreeAPS Read Pod Status and Read Pulse Log commands).

The screamers for Reservoir Empty (024) and Pod Expired (028) are generally never of interest to Insulet or DIY developers as they are normal expected delivery stoppage situations. Modern versions of DIY closed loop software will generate the compatible PDM Ref codes for all Pod faults that can be used to help better characterize Pod failure for DIY developers and can be supplied to Insulet tech support. In Loop 2.x & FreeAPS, the Ref # was always prominently displayed when replacing a Pod with any fault other than 024 (Reservoir Empty) and 028 (Pod Expired). In Loop 3.x the PDM Ref code is currently not displayed during the Replace Pod dialog, but it still can be found by looking at either in the Pump Settings Device Details section (for the current Pod) or the Previous Pod Information section (for the Previous Pod). To assist DIY developers, it is always helpful to note and report the PDM Ref code to concisely characterize the Pod's state at the time of the fault.

Be sure to do a Loop Issue Report to save a copy of the Loop state which includes the information on each Pod fault, the Omnipod communications logs and the recent pump activity. If the Issue Report is not done immediately, it can be generally be performed in the next couple of days to hopefully still have either contain the "pdmRef" value and well as fault information buried in the Omnipod communications log. If it is believed that Loop might have caused the Pod fault in any way (especially for any 049 Pod faults which is always due to some failure in the controlling software), post the resulting Loop Report and the PDM Ref # on the Loop group on Zulip (https://loop.zulipchat.com) or to some other appropriate social group (e.g., the Facebook Looped group) as an attachment along with any relevant information about what was happening at the time of the fault.

Add a custom footer

Communications

Reference

Message decoding

Device drivers

Hardware

Clone this wiki locally