Having Omnipod Issues?

Pod issues happen to looping (and non-looping) Podders. Common problems relate to static, battery failure, occlusion, pairing/insertion failure and failure of the DIY app (or perhaps the link) to maintain communication during the life of the pod.

For pairing problems, please see Pod Pairing Problems Page in LoopDocs.

For trouble communicating with a pod that is running and is not screaming, please see Red Loop Page in LoopDocs.

Scream: A high-pitched continuous alarm that indicates the pod has halted all delivery of insulin.

Your only option with a screamer is to replace the pod and start a new one.

Loop will interrogate the pod approximately every 5 minutes.  It is possible to get an audible alarm from the pod without Loop knowing it has happened yet.  In this case, go to the Pod Settings menu, scroll to the bottom and select Read Pod Status. This captures the fault in the log file that Loop maintains. Then continue to Replace Pod to silence that alarm.

If the result is Empty Reservoir (024)  or Pod Expired (028), this is normal pod behavior and of interest only to you.

If the Pod Fault message or Read Pod Status showed a different value, grab a screen shot to save the information.  Once you’ve dealt with the screamer, return to the Loop Settings screen, select Issue Report and email it to yourself (you have up to 48 hours before the messages scroll out of the log file, but best to do it fairly soon). You can reach out to see if this fault is of interest to the developers for possible code improvements. They may want to know what happened leading up to the fault.

If you are running FreeAPS X, it will the log.txt file that should be shared if you sent it to yourself before midnight of the day the fault occurred, or log_prev.txt if it is after midnight.

Omnipod™ Faults

The link below opens a new window to the OpenAPS/OpenOmni Wiki Fault Code page:

For faults associated with static, the common wisdom is to put duct tape on the body of the pod, rub the pod with a dryer sheet or put a dryer sheet in the pocket of your clothing.

When to call Insulet

Originally it was recommended that Loop (and Loop fork) users call Insulet only for very obvious pod failures, e.g., a pod falling off or failing to activate when powered up.  These were cases where the user wouldn’t have to admit DIY use.  Now that users have supplied many log reports to the developers, the pod faults previously caused by Loop software logic have been fixed. (There may still be some issues when pairing pods not yet included with Loop.) Insulet appears more than willing to deal with failed pods for DIY use (they just cannot offer any support or help about any DIY software issues). They will document and may offer to replace a pod that failed (screamer) in DIY use for anything but 049 faults or “Empty reservoir” / “Pod expired”.

​A fault code of 049 should be reported to the DIY developers, never to Insulet

A fault code of 049 occurs when the controlling software sends a command at a time when the pod cannot accept that command. For example, the pod will not accept a temp basal command when a temp basal is running; the pod will not accept a bolus command when a bolus is in progress.  The pod firmware responds with a fault in these cases. A fault code of 049 is currently extremely rare with iOS DIY software (Loop, FreeAPS, FreeAPS X), but there are occasional reported occurrences with AndroidAPS software.

Before you call:

  • Make sure the pod fault reported is not 049
  • Make sure the pod is not past the expiration date
  • Make sure the fault occurred in the first 72 hours of pod life
  • If it happened during pod pairing – reach out to the DIY developers first for review to make sure it was not a DIY software problem

What information should I be prepared to provide?

You can tell them that you are using a DIY program to control the pod – they are used to this now and will sometimes offer to replace the pod. Then there are no awkward decisions when they start asking for the PDM serial number and the full PDM Reference Code.

They will need to know:

  • Lot # and the id (sequence) # from the tiny print on the pod that failed
  • Loop’s reported Fault Code message (refer to screen shot if you took one)
  • How long the pod was operating
  • What actions were being taken immediately before the failure
  • PDM Ref code (capture a screen shot)

Older versions of Loop and FreeAPS do not display the PDM Ref code with the pod fault, but it can be derived using the 3-digit decimal fault code value and other information from the pod’s status.  For those who want to figure this out and are technically inclined, the link below opens a new window to the OpenAPS/OpenOmni Wiki PDM Ref Codes page:

Insulet tech support may be willing to offer a replacement for a faulted pod even if it was being run with DIY software, but do not to ask for or expect a replacement.

As a courtesy, ask the Insulet tech support person if Insulet wants the faulted pod for analysis by their engineers. This may build goodwill between the Omnipod DIY community and Insulet Corporation. It may also help Insulet get a better understanding of potential problems occurring in the field due to things like manufacturing variations.

There are several versions of DIY code, plus various forks, that control Eros Pods.  Do not expect Insulet to help you with anything other than a pod that appears to be defective.

Home
Top
Skip to content