-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
2 Omnipod Eros deactivated with 0x12 in Loop 3.2.3 even though Loop Cycle Time is limited #2114
Comments
A week ago, I tried limiting the Loop Cycle Time to 5mins with the suggested patch. Unfortunately, I am still experiencing the same issue, every Pod only runs for around 1d 20hrs - 2 days. Loop Report 2024-01-30 11:21:21+01:00.md Any suggestions? I am considering downgrading to Loop 2. |
I just analyzed your two reports and there were a lot of communication issues. Do you have a different RileyLink Device you can try?
Discussion:
|
The limit cycle is for libre that reported every minute. Irrelevant for your situation. Try keeping your rileylink close to the pod at all times. And look into getting a replacement. Open it and make sure antenna is securely attached. (Phone to riley is Bluetooth. Riley to pod is 533 MHz radio frequency and that’s probably what is failing.) We recently discovered the uncertain comms handling for Eros in Loop 3 has a bug. (See Issue 2118). (Uncertain comms is probably what is going on with you. Loop 3 has a new method for handling that. ) Can you send me a PM in zulipchat and I’ll walk you through a rebuild of Loop using dev and show you how to build with the fix. It was just merged into OmniKit main branch (Eros pod code) but has not yet been added to LoopWorkspace dev branch. |
Since we are 9 hours apart in time-zones, I wrote up the instructions. If you do not feel confident with these let me know. I assume you are using a Mac to build. Download these 2 files. Open the The instructions in the txt file tell you how to get all the fixes that are already merged into OmniKit and how to use the patch file for the final fix that is not yet merged. If you are successful with the build, please post another log file after 24 hours of operation to see if this improves things. And if you are near the end of life of a given pod, don't expect miracles. Hope this will help with the next pod. |
Hey, thanks a lot for your help! Yep opened up the .txt file in VS Code, I definitely feel confident with the instructions, I'll will rebuild it and report back. |
Hey @marionbarker I think this has improved my issue, thanks a lot for your help so far! The first pod (1 day old) has run out after 1 day 22 hours. I also ordered a new OrangeLink. I hope I can manage to run 3 days + 8 hours again without issues then. Here is the latest report: |
Thank you for the report. This shows definite improvement in recovery from uncertain communications. The characteristic of uncertain comms is a request for update at about 60 s intervals until the problem is resolved. I counted the number of messages where Loop sent another message between 45 and 75 sec - called this repeated pings. (Not a perfect measure, but an easy one.) I then divided by hours in the record to get an estimate of frequency. There are 2 pods in this report:
They both show symptoms of poor communication, but with the "bug" fixed in the code, this should cause less of a load on your pods. I hope the newer OrangeLink reduces the uncertain comms events and that will help as well. I went back to an older report from early January
|
@philippfo9 Thank you so much for reporting. The fixes that you applied with the patch information I sent you were merged into LoopWorkspace dev on 14 Feb 2024. There is no need for you to rebuild at this time. Once the new release comes out, this Issue can be closed. But in the meantime, please leave it open as the fix is in dev and not in main (right now). |
Hey thanks @marionbarker! OrangeLink arrived, will try it out soon :) Just had the following error: 0x34 (reset from unknown cause) after just 36 hours, which might be unrelated. Attaching the report |
Well, the good news is the first pod in the log made it to 72.8 hours before getting an 0x12 fault.
Unfortunately, that second pod did fail at 35.8 hours with a 0x34 fault.
I hope the new OrangeLink will help with the comms and stop these faults. I know how intensely annoying it is to get screamers. Please send me logs again and indicate the time at which you switch to the new OrangeLink. |
Yes I agree, it's annoying, especially with the amount of Pods it's hard to justify replacements for social insurance. Anyway, I just had the same issue again, the pod is running a total of ~44 hours with a 0x34 fault. Just bought AAA batteries today for the OrangeLink and making the switch now, wish me luck! Reporting back here in around 24-48 hours :) |
@marionbarker with OrangeLink, 3 days in and still running. |
This issue is stale because it has been open for 30 days with no activity. |
Bump. Fixed in dev. Leave open until released. |
This issue is stale because it has been open for 30 days with no activity. |
Bump |
Describe the bug
After around 2 days, my Pod deactivates running a Dexcom G6 with Omnipod Eros and Loop 3.2.3.
Similar problem as here: #1924
Attach an Issue Report
Loop Report 2024-01-02 19:08:52+01:00.md
What could I do to avoid this?
Should I Limit Loop Cycle Time for a Dexcom G6 as well?
The text was updated successfully, but these errors were encountered: