Pod Setup

Pod activation

As at 12 April 2019, the main (master branch 1.2) of omnipy cannot activate a pod, and you have to activate the pod with the PDM before 'passing over' control to Omnipy.

Start by following the usual pod activation sequence with your PDM, i.e. fill the pod with insulin, place pod on body, run the activation/insertion commands through the PDM and once it shows basal rate and everything running, follow the steps below.

Note that in the current (master) setup, the pod gets its default basal rate from the PDM and not from AndroidAPS. It is therefore important that the basal rate is set correctly on the PDM before control of the pod is 'passed over' to the omnipy system. The same applies to pod expiry time (ie the time prior to 72hrs when the pod gives reminder beeps) - this needs to be set on the pdm before involving omnipy.

(Note that at 12/4/19, insertion is possible direct from omnipy, without use of a PDM, for those who are testing the dev branch - details at the end of this page)

!!! Warning !!!

If you want to simultaneously run a pod for testing with omnipy, but also run a second pod for yourself to be controlled by the PDM, read carefully:

If you have a second PDM

That's straightforward. Just use the pdm that is not controlling the "live-pod" (the one on your body) to activate the test-pod.

If you don't have a second PDM

1. You don't have any running pods (in between pod change or else): First activate the test-pod, then follow the procedure below to register it for omnipy. After this is done, deregister the pod from pdm by choosing deactivate while the test-pod is not in the range of pdm. After clicking "deactivate anyway" you can initialize your live-pod.

2. You have a running live-pod on you and want to keep it running: There is nothing you can do, you MUST wait until the pod needs replacing. If the pod is dead at the time of replacing, see option 1. If it's still working but you still need to change it (bad site, not enough insulin) then go to option 3.

3. You have a running pod on you and want to use it for testing: Take the pod off body but don't deactivate it! Follow the omnipy registration procedure below for this pod. After it's done deregister the pod from the pdm as described in option 1. And activate and attach your new live-pod afterwards.

Registering a pod in omnipy

Login to your raspberry pi with ssh and then change to the omnipy installation directory via:

cd omnipy

Now run the following command (note the . at the beginning of the command)

./omni.py readpdm

This is the command for spying on the PDM for the pod address. Once you run it, it won't display anything and will simply wait to hear something from the PDM.

The command will enter a waiting state and will wait to hear from the PDM. Now, on the PDM, press the button for status.

Once the software hears a status request from the PDM it will show something like:

    "result": {
        "address": 521046514
    },
    "success": true
}

Note down the radio address (RRRRRRRRR) returned by readpdm - 521046514 here.

Also, on the PDM, check in pdm records for the lot (LLLLL) & serial number (SSSSSS) (press the ? on the record for pod insertion) and note these down.

Then put PDM well away - you might want to remove the batteries or wrap it in kitchen foil. (The aim is to stop the PDM from communicating with the pod from then on).

On the pi, type:

./omni.py newpod LLLLL SSSSSS RRRRRRRRR

Where LLLLL is the lot number, SSSSSS is the pod serial number and RRRRRRRRR is the radio address.

Confirm you have a "success": true.

Then type:

./omni.py status

this should take a few seconds and then print a large text a bit like this:

    "result": {
        "address": 3332222,
        "alert_states": 0,
        "basalSchedule": [],
        "basalState": 1,
        "bolusState": 0,
        "canceledInsulin": 0.0,
        "extendedBolus": [],
        "fault_event": null,
        "fault_event_rel_time": null,
        "fault_immediate_bolus_in_progress": null,
        "fault_insulin_state_table_corruption": null,
        "fault_internal_variables": null,
        "fault_progress_before": null,
        "fault_progress_before_2": null,
        "fault_table_access": null,
        "faulted": false,
        "information_type2_last_word": null,
        "lastNonce": 3870148995,
        "lastUpdated": 1551542177.0886214,
        "last_enacted_bolus_amount": null,
        "last_enacted_bolus_start": null,
        "last_enacted_temp_basal_amount": 4.65,
        "last_enacted_temp_basal_duration": 0.5,
        "last_enacted_temp_basal_start": 1551542177.1038814,
        "log_file_path": "data/pod.log",
        "lot": 44226,
        "maximumBolus": 15,
        "maximumTempBasal": 15,
        "minutes_since_activation": 92,
        "msgSequence": 10,
        "nonceSeed": 3,
        "packetSequence": 25,
        "path": "data/pod.json",
        "progress": 8,
        "radio_low_gain": null,
        "radio_rssi": null,
        "reservoir": 51.150000000000006,
        "tempBasal": [],
        "tid": 659956,
        "totalInsulin": 10.8,
        "utcOffset": 0
    },
    "success": true

At this point the pod is all set up and you should be able to control things from AndroidAPS.

You may find it helpful to monitor the log files during AndroidAPS connection - to do this type

tail -n 60 -f ~/omnipy/data/omnipy.log

You'll be able to spot any errors:

• References like this are all fine:

2019-03-06 22:09:20,850 - OMNIPY - DEBUG - SENDING PACKET EXP RESPONSE: Pkt PDM Addr: 0x1f11da79 Addr2: 0x1f11da79 Seq: 0x0d Body: b'18030e0100'

• References like this indicate that the RileyLink can't reach the pod "Exceeded retry count while send and receive" In this case you might want to replace your antenna (see link below on increasing radio range)

Deactivating a pod in omnipy

When you want to stop a pod (after 3 days), log in to your raspberry pi with ssh type ./omni.py deactivate

Then also stop the pod on PDM ('deactivate anyway'). You can then repeat the setup for your new pod.

How to setup a pod with omnipy (for dev branch testers only from 12 April 2019)

Deactivate old pod - either in aaps, or from command line with ./omni.py deactivate. If that does not work for any reason (eg success=false), use ./omni.py archive. That will mean omnipy 'forgets' the pod

Fill a new pod with insulin and wait for the 2 beeps.

./omni.py activate xxx (where xxx is the number of minutes ahead of GMT in your time zone. This can be positive or negative, eg BST (GMT+1hr) is 60; EST (GMT-5hrs) is -300) to prime it. During this activation command (ie priming) make sure the pod is close to the RileyLink, but not touching it, and ideally slightly offset from the antenna. Successful positioning is quite important for this to work.

These two photos show successful priming positioning:

https://github.com/winemug/omnipy/blob/9961ee81897ab8254820b62dab70636e580750b4/img/prime_OK_1b.jpg?raw=true

https://github.com/winemug/omnipy/blob/9961ee81897ab8254820b62dab70636e580750b4/img/prime_OK_2b.jpg?raw=true

This photo shows unsuccessful priming positioning (too close to RL):

https://github.com/winemug/omnipy/blob/9961ee81897ab8254820b62dab70636e580750b4/img/prime_notOK_1b.jpg?raw=true

(Note that for dev versions 12-16 April 2019, if you're stuck during activation, i.e. if it doesn't progress, do a .omni.py status and make sure other (previously activated) pods are wrapped in foil or otherwise unreachable. This should not be necessary for dev versions after 16 April 2019).

Once the activate command has returned a success=true (and you have heard the priming happen), then apply pod to site.

./omni.py start yyy (where yyy is the initial basal - I tend to use my standard basal rate for this (eg 0.8) but it is unimportant as aaps will subsequently set correct basals).

Note that there is a plan to incorporate these insertion steps into the AAPS UI in due course.