Omnicore use and troubleshooting
The alpha version of Omnicore can be quite finicky in maintaining a connection to the pod (which can require your intervention if connection is lost), and the user interface is imperfect (eg displays incorrect basal rates, even when they are OK; and displays duplicates on the conversations screen). In general, you will minimise comms loss if you keep the RileyLink as close to the pod as possible, and try to avoid going out of range if possible. A fair bit of patience is needed (eg when starting a pod) with some repeat steps required if things didn’t work.
In standard ‘pod’ view, the ‘Overview’ and ‘Conversation’ screens are shown here, accessed by pressing the buttons along the bottom. Also available is the ‘Maintenance’ screen (for starting & stopping pod). The settings screen is accessed via the three lines at the top.
- These steps are not needed if this is your first pod:
a) Deactivate your existing pod – ‘deactivate pod’ button on maintenance screen, and check success in conversations screen. If this doesn’t work, no worries – just put a pen in the back of the pod so it doesn’t beep later.
b) Backup the Omnicore database (although you might not want to bother, unless you are investigating a screamer pod). To do this, go into settings, and press ‘backup database’ button. Then use a file browser to go to internal storage/omnicore and find a file OmniCore_backup.db3. Save that file somewhere or email it to yourself.
c) Erase the Omnicore database. To do this, go into settings, and press ‘erase database’ button. This will then exit from omnicore. Note the reason for this step is that once the database contains 2 or more historic pod records, access slows down and this is more likely to result in a pod error (screamer). So it is best to delete the database before each new pod. Note you cannot delete the database with an active pod running, or you will loose control of that pod.
-
Ensure that Omnicore app is fully killed. Some people use ‘exit application’ in the omnicore ‘test’ section. Personally I prefer to go into phone settings / apps / omnicore and press ‘force stop’. Note that occasionally it sometimes restarts itself (if AAPS makes a request to Omnicore) after it’s been killed so go back to the apps list, into omnicore again from that list and press ‘force stop’ again. Repeat till it is actually killed.
-
(This step not generally needed but may be necessary if you are having problems). Turn off RileyLink. Turn on RileyLink.
-
Turn off Bluetooth on phone. Then turn on Bluetooth on phone. (NOTE that you should NOT attempt to pair the RileyLink in the phone’s Bluetooth settings. (And if you have by accident then unpair it). All Bluetooth connections are managed directly by Omnicore).
-
Open Omnicore app.
-
Go to settings (three lines top left) and turn off the slider next to ‘accept AndroidAPS commands’. This stops AndroidAPS trying to send commands and mess things up during pod setup.
-
Fill pod with insulin to get the two beeps. Go to maintenance screen, and press ‘activate pod’ on the dialog. Agree the message to activate the pod. Switch back to the conversations screen to see progress.
Be patient! It may appear nothing has happened for 10+ seconds. Things are going well if: you see ‘searching for RileyLink’ in the upper section; the green RileyLink light comes on; then you see in the main conversation section ‘assign address’; followed by ‘update status’; ‘configure alerts’; ‘set delivery flags’; 'prime cannula' and finally ‘update status’. Don’t be too alarmed if you see a ‘CommunicationInterrupted’ before that successful sequence begins (just wait a while).
But if you see an 'activate pod failed' popup, or messages in the onversations tab saying ‘RadioDisconnectPrematurely’ or ‘RadioRecvTimeout’, chances are it didn’t work. You have not wasted a new pod. But you will need to go back to stage (2) (ie kill OC, consider powercycling RL, cycle BT) and then try ‘activate pod’ again.
Similarly, if comms are lost during a pod start (for example, if everything has gone OK as far as 'set delivery flags' but the 'prime cannula' stage results in a 'RadioRecvTimeout') then go back to stage (2) (ie kill OC, consider powercycling RL, cycle BT) and then try ‘activate pod’ again. This should then pick up and run the start sequence again, mindful of how far it got before. (You may have to wait a bit or hit 'status' a few times to get the 'activate pod' button not to be greyed out).
-
Assuming pod has primed OK, put the pod on your body.
-
Go to maintenance screen, and press ‘resume activation’ button to insert the cannula, followed by 'start' on the dialog box. It is quite common that this button is greyed out. Various ways round this – either (a) wait a bit (say 10-15 secs); or (b) flick between the conversation screen and the maintenance screen till it appears; or (c) go to overview screen and hit ‘status’ button a few times till it appears; or in extremis (d) close and open Omnicore to get it to appear. It will eventually.
-
Now your cannula is inserted, in overview screen, hit ‘status’ button and check the OK result in the conversation screen to check that is working. Now go into settings (three lines top left) and turn on the slider next to ‘accept AndroidAPS commands’.
-
Kill AndroidAPS app. Generally you don’t need to force stop (via phone settings / apps) but it doesn’t hurt and is necessary if you are having problems getting AndroidAPS to talk to Omnicore.
-
Assuming all is well, you will see two green bars at the top of the AndroidAPS home screen – one saying it is connected to Omnicore; the other to say that basal rate has been updated.
-
At this point, I tend to issue a small (0.05u) bolus from AndroidAPS to check that all is working well. I also tend to set a CarePortal reminder of a cannula change; and also set a calendar reminder on my phone for the next pod change in 3 days time. (Latter is sensible as Omnicore doesn't do an automatic notification of necessary / imminent pod change).
-
AAPS should now be running happily with Omnicore and the pod, including to set [temp] basals, and to bolus (and SMB).
Comms issues may become apparent if the ‘loop’ tab in AndroidAPS displays ‘waiting’ in the section toward the bottom; or if you get an AndroidAPS alarm when blousing; or if you see a reversion to your default basal rate (dark blue in AndroidAPS) when you might have expected to see an alternative temp basal.
Investigate further by looking at the conversations screen of Omnicore. If you see red warnings (‘CommunicationInterrupted’, ‘RadioDisconnectPrematurely’, ‘RadioRecvTimeout’, or ‘PodResponseUnexpected’) then Omnicore has lost connection. The good news is that almost all comms loss is recoverable without loss of the pod.
The first step is to hit the ‘status’ button on the overview screen, then switch back to conversations screen to see what’s happening. This may well be enough. If it isn’t then to restore comms, follow steps 2 / [3] / 4 / 5 of the ‘starting a new pod’ section above (ie toggle BT, stop and restart OC), and then do a ‘status’.
If you get tired of force stopping omnicore and toggling Bluetooth manually, you might want to install the MacroDroid app, and using a script like this to put a widget button on your screen. Hit the button to disable Bluetooth, kill OC, enable Bluetooth, start OC, hit status. This script works reasonably well on a Samsung S7 but you’ll need to play around with it a bit for other screen resolutions etc.
If AndroidAPS reports it is “not connected to omnicore”, this can be resolved by first checking that Omnicore is setup to receive AndroidAPS commands - settings (three lines top left) and turn on the slider next to ‘accept AndroidAPS commands’. Failing that, force stop AndroidAPS and re-open it. It should then connect to Omnicore.
Screamers do happen, although not too frequently. To minimise them, ensure your RileyLink antenna is as good as it can be (see Omnicore DIY hardware wiki).
If you get a screamer, disable the pod on the maintenance screen; back up the database and setup a new pod.
If you want to find details of the pod error, you’ll need to examine the database. To do this use an SQL database tool such as https://sqliteonline.com/ . Use the SQL code SELECT * FROM ErosFault; and ‘run’ it. The fault code can then be seen in the Faultcode field, and the number can be compared with the list at https://github.com/openaps/openomni/wiki/Fault-event-codes.
Please join the slack channel (omnicore channel) – there may be folk that can assist. But please remember that this is only alpha code, not formally a ‘release’ version.