Update LoopDocs for dev v3.14.5 - #1061
Conversation
| The `feat/all-managers` branch replaces several [retired feature branches](#table-of-retired-branches). If you need a feature branch for a Dana pump - you need to build this branch. Be sure to review the [Status For Dana Support](#status-for-dana-support) section. | ||
|
|
||
| If you previously used a feature branch for Medtrum or Eversense support, you can switch to the `dev` branch. | ||
| If you previously used a feature branch for Medtrum or Eversense support, you can switch to the `main` branch, with updates coming in to the `dev` branch. |
There was a problem hiding this comment.
On another line, Eversense is in the feat/all managers branch. On this line, it's in loop-main
|
|
||
| * The `dev` branch uses a connect-on-demand method for connecting to both DASH and Omnipod 5 Pods so you may notice a slight delay in connecting, getting status and then responding to a command from Loop | ||
| * This is normal, be patient | ||
| * [Will I still get 203 errors?](#will-i-still-get-203-errors) - we do not know but early testing indicates reduced frequency of 203 faults for Atlas DASH Pods |
There was a problem hiding this comment.
FYI, we have always had some periodic 203 pod faults even the older DASH (SAW) pods, so these still could be occasionally occurring even if the new connect on demand method is able to completely eliminate the huge increase in 203 pod faults with Atlas pods (for some lot #'s).
| The increased frequency of faults noticed with DASH Atlas Pods has not been observed in the Ominpod 5 Pods tested to date. Considering just the Pods that are not expired, there is a 3% failure rate with the failure being an occlusion (105) fault. There were testers in the private beta group using DASH instead of Omnipod 5. They had a 20% failure rate on a small sample of DASH Pods, all 203 faults near the 72 hours time frame. | ||
|
|
||
| > see [Updates in `next-dev` branch only](#updates-in-next-dev-branch-only) | ||
| Both the `dev` and `next-dev` branches use a new connect-on-demand method that appears to reduce the frequency of 203 faults for Atlas DASH pod. In addition, not 203 faults have been observed to date by any of the Omnipod 5 testers. |
| * Omnipod 5 code is experimental and does not provide a heartbeat | ||
| * This means you rely on your CGM to wake up the app when it is in the background or the phone is locked | ||
|
|
||
| **To date, no iPhone model specific issues have been found with Omnipod 5 Pods.** |
There was a problem hiding this comment.
Could expand this to say "with all Omnipod 5 Pod variants tested".
| The "Pod Keep Alive" option is found the bottom of the "Omnipod DASH" screen. This is intended to assist users who have both an iPhone 16 (all models) or 17e and [DASH Pods with a InPlay BLE (Atlas) board](../faqs/omnipod-faqs.md#keep-alive-atlas-or-inplay-dash-pods){: target="_blank" }. Model 17 phones, except for the 17e, do not exhibit this problem. No action is taken automatically unless both these cases are detected to be true. | ||
|
|
||
| The concept is by choosing one of the Pod Keep Alive choices, the app sends a getStatus to the Pod before the 3 minute disconnect happens. Therefore, so long as you and the Pod stay close to the phone, the Pod will be connected for any command (either manual or automatic) including bolus, temp basal, modify scheduled basal rates, suspend, or deactivate. | ||
|
|
There was a problem hiding this comment.
Should add a note saying that Pod Keep Alive was rewritten to correctly integrate into OmnipodKit and that any old Pod Keep Alive settings will not be kept. Thus Pod Keep Alive must be manually re-enabled if needed. The RileyLink connections will be shown in the pump (Omnipod DASH) view under the Pod Keep Alive button when the RileyLink option is selected. These connections are managed just like the RileyLink switches for Omnipod Classic Pods.
| If you are running a Pod and you transition to the OmnipodKit Pump Manager, then any build you install on your phone should have OmnipodKit. If you need to downgrade to a build earlier than v3.14.2, do so after deactivating a Pod. | ||
| ## OmnipodKit Information | ||
|
|
||
| When you build the `main` or `dev` (v3.14.2 or newer) branch or `next-dev` (v3.15.0 or newer) branch over an older build, your Pod is automatically transitioned to use a new Pump Manager: OmnipodKit. You will notice the user interface is a little different from the older managers (OmniKit and OmniBLE). |
There was a problem hiding this comment.
All the previous settings from OmniKit and OmniBLE will automatically transfer over to OmnipodKit except for "Pod Keep Alive" which must be manually re-enabled if needed when transitioning from OmniBLE or OmnipodKit version v3.14.4 or older.
3 participants
No description provided.