Fault event codes

Fault events are non-recoverable fatal errors that result in a faulted (AKA "screaming") Pod. Pods are continually performing a variety of safety checks and if a potential problem is found, the Pod will enter a fault state where all insulin delivery is halted and the Pod emits a continuous screeching tone (i.e., it becomes a "screamer") until the Pod is successfully deactivated or a paper clip or other similar item is used to press on the manual alarm shut-off port on the bottom of the Pod. The alarm shut-off port is on the opposite side of the fill port and can be found by peeling back the adhesive pad from the bottom of the Pod at the square end.

Fault Codes and PDM Ref Numbers

A Pod creates an 8-bit fault code on failure 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 # that Insulet tech support typically requests for a failed Pod. These PDM Ref #'s are saved in the non-volatile PDM Alarm history and can be retrieved by examining the details for a Pod alarm failure. The PDM Ref # is a 15-digit decimal value broken into 4 sections by dashes which is actually composed of 6 different values as shown below. All fields are fixed width and zero padded.

PDM Ref: AA-BBBCC-DDDEE-FFF

• AA: 19 - Pod error, 17 - Occlusion, and 11 - PDM error
• BBB: The VV byte of a 02 Response, Type 2 or 000 for an Occlusion.
• CC: # of hours Pod active to fault, values from 00 to 80 possible.
• DDD: # of whole units of insulin delivered (including those used priming and cannula insertion).
• EE: # of whole units of insulin left in reservoir or 51 if > 50U, values from 00 to 51 possible.
• FFF: Pod fault event code # or 000 for an Occlusion.

An AA value of 11 for a PDM error will be used if the Pod throws an 049 Pod Fault due to an incorrect command being issued by the controlling software.

The 3-digit FFF values for type 19 Pod error faults are the same Internal pod fault value as displayed when running Loop's Replace Pod on a faulted pod.

Normal Pod use can result in the following three different fault types that the PDM either won't generate a Ref # for (for Pod expired and Empty reservoir) or may generate a Ref # with an FFF value of 000 (for an Occlusion).

• Pod expired: 028
• Empty reservoir: 024
• Occlusion detected: 020 [090, 096, 097, 098, 102, 103, 104, 105, 106]

For other faults the PDM will create a Ref # including the 8-bit fault code as the final FFF section while the Loop app will display this fault code as an Internal pod fault NNN when deactivating the Pod. The PDM only displays "Occlusion detected" for an 020 Pod fault with an AA-BBB value of 17-000 and FFF of `000'. Loop has used an extended list of the 10 different possible fault codes listed above for an "Occlusion detected" message.

Fault Code Values

The known Pod fault codes are listed in the following table as both decimal and hex values in numeric order. The firmware discovery interpretations were obtained from an examination of the Pod firmware as obtained from this Loop Swift source file. This table also includes additional information obtained from previous discussions with Insulet tech support reps for selected fault codes as reported in this FUDiabetes article. Values not shown indicates that this fault code was not found in the reference 2.7.0 Pod firmware nor was there any additional information on this fault code derived from Insulet tech support.

Internal Pod Fault	Hex Value	Pod Firmware Discovery	Derived Insulet Tech Support Description
000	0x00	Not used by Pod firmware for error, used for PDM display for occlusions (AA == 17)	Occlusion
001	0x01	Flash erase failed
002	0x02	Flash store failed
003	0x03	Basal subcommand table corruption
005	0x05	Corruption in byte_720
006	0x06	Data corruption error in test_RTC_interrupt or BE3 pump table
007	0x07	RTC interrupt handler called with inconsistent state
008	0x08	Bad value > 8
010	0x0A	Corruption in byte_BF0
011	0x0B	Temp basal subcommand table corruption
013	0x0D	Reset due to COP
014	0x0E	Reset due to illegal opcode
015	0x0F	Reset due to illegal address
016	0x10	Reset due to SAWCOP	Safety check, insulin delivery stopped
017	0x11	Corruption in byte_866
018	0x12	Reset due to Low Voltage Detect, more likely on third day of use due to low batteries	Static electricity
019	0x13	Message length too long
020	0x14	Problem in big_routine_3	Occlusion detected
021	0x15	Corruption in word_129 table/word_86A/dword_86E
022	0x16	Corruption in byte_868	Safety check, insulin delivery stopped
023	0x17	Corruption in a validated table
024	0x18	Reservoir empty or exceeded maximum pulse delivery	Empty reservoir
025	0x19	Bad Power Switch Array Status and Control Register value 1 before starting pump
026	0x1A	Bad Power Switch Array Status and Control Register value 2 before starting pump
027	0x1B	Bad LOADCNTH value when running pump
028	0x1C	Exceeded maximum Pod life of 80 hours	Pod expired
029	0x1D	Unexpected internal state command_1A_schedule_parse_routine_wrapper
030	0x1E	Unexpected commissioned state in status and control register upon reset
031	0x1F	Sum mismatch for word_129 table
032	0x20	Validate encoder count error when bolusing
033	0x21	Bad timer variable state
034	0x22	Unexpected RTC Modulo Register value during reset
035	0x23	Problem in calibrate_timer_case_3
037	0x25	RTC interrupt handler unexpectedly called
039	0x27	Failed to set up 2 hour alert for tank fill operation
040	0x28	Bad arg or state in update_insulin_variables, verify_and_start_pump or main_loop_control_pump
041	0x29	Alert #0 auto-off timeout
042	0x2A	Alert #1 auto-off timeout
043	0x2B	Alert #2 auto-off timeout
044	0x2C	Alert #3 auto-off timeout
045	0x2D	Alert #4 auto-off timeout
046	0x2E	Alert #5 auto-off timeout
047	0x2F	Alert #6 auto-off timeout
048	0x30	Alert #7 auto-off timeout
049	0x31	Incorrect pod state for command or error during insulin command setup
050	0x32	Bad value during startup testing
051	0x33	Connected Pod command timeout
052	0x34	Reset from unknown cause, more likely on third day of use due to low batteries	Static electricity
054	0x36	Flash initialization error
056	0x38	Unexpected byte_358 value
057	0x39	Problem with LOAD1/LOAD2
058	0x3A	A > 7 in message processing
059	0x3B	SAW reset testing fail
060	0x3C	402D is 'Z' - test in progress
061	0x3D	Problem with pump anchor
062	0x3E	Flash initialization or write error
064	0x40	validate_encoder_count too high, possible occlusion, generally seen during bolus on 3rd day with depleted batteries	Interruption in the flow of insulin
065	0x41	validate_encoder_count excessive variance
066	0x42	validate_encoder_count too low	Safety check, delivery problem inside the Pod and not on the site
067	0x43	validate_encoder_count problem
068	0x44	check_LOAD_voltage open wire 1 problem	Unlabeled per tech support, insulin delivery stopped
069	0x45	check_LOAD_voltage open wire 2 problem	Software or hardware failure in Pod
070	0x46	Problem with LOAD1/LOAD2
071	0x47	Problem with LOAD1/LOAD2
072	0x48	Bad timer calibration
073	0x49	Bad timer values, COP timer ratio bad
074	0x4A	Bad timer values
075	0x4B	ICS trim too close to 0x1FF
076	0x4C	find_best_trim_value problem
077	0x4D	Bad set_TPM1_multi_cases value
078	0x4E	SAW trim error	Safety check, delivery problem inside the Pod
079	0x4F	Unexpected TXSCR2 RF Transmission Error Flag set during reset
080	0x50		Static electricity
081	0x51	Bad check_SDIRH and byte_11F state before starting pump
082	0x52	TXOK issue in process_input_buffer
083	0x53	Wrong word_107 value during input message processing
084	0x54	Packet frame length too long
085	0x55	Unexpected IRQ high in timer_tick
086	0x56	unexpected IRQ low in timer_tick
087	0x57	Corrupt constants table at byte_37A[] or flash byte_4036[]
088	0x58	Bad argument to update_37A_table
089	0x59	Error updating constants byte_37A table
090	0x5A	big_routine_1 too high	possible occlusion
091	0x5B	Load table corruption
092	0x5C	Prime open count too low	Problem with a safety check occurred
093	0x5D	Bad byte_109 value
094	0x5E	Write flash byte to disable flash security failed
095	0x5F	Two check_LOAD_voltage failures before starting pump
096	0x60	big_routine_1 startup problem 1, possible occlusion
097	0x61	big_routine_1 startup problem 2, possible occlusion
098	0x62	big_routine_1 excess timeouts 1, possible occlusion
102	0x66	big_routine_1 excess timeouts 2, possible occlusion	Insulin delivery has stopped, change site
103	0x67	big_routine_1 excess timeouts 3, possible occlusion	Insulin delivery has stopped, change site
104	0x68	big_routine_1 pulse issue, possible occlusion	Insulin delivery has stopped, change site
105	0x69	big_routine_1 bolus problem, possible occlusion	Insulin delivery has stopped, change site
106	0x6A	big_routine_1 above threshold, possible occlusion	Insulin delivery has stopped, change site
128	0x80	Basal under infusion
129	0x81	Basal over infusion
130	0x82	Temp basal under infusion
131	0x83	Temp basal over infusion
132	0x84	Bolus under infusion
133	0x85	Bolus over infusion
134	0x86	Basal over infusion pulse
135	0x87	Temp basal over infusion pulse
136	0x88	Bolus over infusion pulse
137	0x89	Immediate bolus under infusion pulse
138	0x8A	Extended bolus over infusion pulse
139	0x8B	Corruption of $283/$2E3/$315 tables
141	0x8D	Bad input value to verify_and_start_pump
142	0x8E	Pump request 5 with basal IST not set or temp basal IST set
143	0x8F	Command $1A parse routine unexpected failed
144	0x90	Bad value for $283/$2E3/$315 table specification
145	0x91	Pump request 1 with temp basal IST not set
146	0x92	Pump request 2 with temp basal IST not set
147	0x93	Pump request 3 and bolus IST not set when about to pulse
149	0x95	Bad table specifier in 1A insulin command
150	0x96	Bad variable state in clear_Bolus_IST2_and_vars
151	0x97	Bad variable state in maybe_inc_33D

What To Do With 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 Loop Omnipod commands except for Replace Pod, Read Pod Status and Read Pulse Log. If Loop hasn't yet noticed that the Pod has faulted, executing a Read Pod Status before Replace Pod will allow Loop to capture the actual fault code value to report. Additionally, modern versions of Loop will automatically run a Read Pulse Log command when deactivating a Pod known to be faulted to gather more information. If Loop captures the fault code value, it will display an Internal pod fault message with the 3-digit fault code value during Pod deactivation. If it is believed that Loop might have caused the Pod failure in some way, do an Issue Report soon after deactivating the faulted pod and then 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.

If you decide to call Insulet tech support about a faulted Pod that Loop reports as an Internal pod fault, don't mention that you not using a PDM until Insulet tech support asks for the PDM Ref #. At that time simply say that you don't have it because you were using DIY Loop instead of a PDM, but that you can provide at least some parts of the PDM Ref #.

PDM Ref: AA-BBBCC-DDDEE-FFF

For a Loop Pod failure with a 3-digit Internal pod fault, the PDM Ref # AA value is 19 and the FFF value is the # as reported by Loop while for a reported Pod occlusion failure (fault code 020), the PDM Ref # AA value would be 17 with an BBB & FFF value of 000. If the Internal pod fault value is 049, the PDM Ref # AA value would be 11 as this indicates a logic error in the controlling software and not a true pod fault. The CC value is the 2-digit zero padded # of hours of Pod life before the fault. The # of hours of Pod life can be computed as "(days x 24) + hours" using the info in Active Time line at the top of Loop's Pod Setting view at the time of the fault or from the Fault Time line in the Read Pod Status command output. The DDD value is the zero padded # of whole units of insulin delivered and can be calculated by taking the Pulse Count value in the Read Pod Status command output and dividing by 20 and truncating down the nearest integer. This DDD value can also be approximated by adding 2.8 to the Insulin Delivered value in the Pod Settings view and truncating down to the nearest integer. The EE value is the zero padded # of whole units of insulin remaining in the reservoir or 51 if > 50. This value can be taken from the Reservoir line in the Pod Settings view or from the Reservoir Level line from the Read Pod Status command output. If this value is not known, just assume it's the typical 51 value. The BBB value is 3-digit zero padded decimal value of the VV byte of the 02 Response, Type 2. To correctly obtain this value requires a detailed examination of the Loop Report Omnipod Device Communications Log. Until Loop is updated to print an official PDM style Ref #, it is suggested to just use a typical BBB value of 040 if no bolus was in progress or 056 if a bolus was in progress at the time of the fault.

Insulet tech support is generally willing to offer a replacement for a faulted Pod even if it was being run with DIY Loop, 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 will 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.

Note on Loop Pod Faults

During early Omnipod Loop testing, there were a number of failures on the third day due to a particular class of additional Pod safety checks. For these checks involving a questionable Pod pulse state, the Pod needs to deliver a pulse within the next 30 minutes to possibly clear this condition or else the Pod will fault. Closed loop use requires a higher number of commands (which increases the Pod battery load) and can invoke zero or reduced basal rates for extended periods which increases the odds for these conditions to occur. The Loop app uses a Configure Delivery Flags command to disable these particular checks involving the 30 minute recovery window which effectively inhibits the 096-106 Pod faults from ever occurring.