RileyLink (+ Medtronic 523) often requires power cycle to re-connect with AAPS

[Webifi]

Currently on latest dev build,, but this has been an ongoing issue with AAPS since I can remember -- well over a year.

Sometimes connection is lost and is not able to be re-established until I power off, then back on the RileyLink. In the Medtronic tab, RileyLink Status goes to: RileyLink Unavailable (paraphrasing -- It could be a slightly different message. I'll screen shot this next time.) This happens at least once a day -- often more. Many times, RileyLink seems to think it's still connected (green light is on) even when the Medtronic driver is reporting that it's not, though this is not always the case. For example, if I force close AAPS, RileyLink's green LED will eventually turn off, and when I re-launch AAPS, RileyLink will go green again, but Medtronic driver doesn't seem to be able to fully re-establish a connection -- until I power cycle the RileyLink.

Using a Medtronic 523 with firmware 2.4a.
RileyLink: BLE113: ble_ffspy 2.0, CC110: subg_rfspy 2.2 Phone: Pixel 3a

Seems to be related to issues with Bluetooth connectivity. (Appears to happen more often if in area where there's multiple other 2.4ghz devices, or if I walk away from my phone with the RileyLink in my pocket.)

State of charge of RileyLink doesn't seem to matter (can happen in the morning after being charged all night, or in the evening after a full day of use.)

Attached is log just after last time it happened, about a minute after I power-cycled the RileyLink and waited for AAPS to re-connect.

AndroidAPS_LOG_1614185044977.log.zip

Please let me know if there's any more data I should gather.

[andyrozman]

Its not always the Android problem, sometimes RileyLink just freezes too...

We thought about extending this code to be able to reconnect back, but this was not been done yet.

But if you need to power cycle RL, this actually means that problem was not on Android or AndroidAPS side, but with RL hardware itself. If you restart AAPS and connection comes back immediately, then problem was on AAPS. So next time you can try to power cycle RL first, and if that doesn't help, turn BT on/off (wait few seconds between) and then AAPS will reconnect (it can detect if your BT is on or off).

[Webifi]

Thanks. I'll try shutting off/on BT next time to test.

Out of curiosity, does the Medtronic driver ever signal a RileyLink reset when it runs into trouble? If so, could you point me to the code where that's done? Been digging through the Medtronic driver off and on for awhile, but haven't found it yet.

[andyrozman]

RileyLink doesn't have a reset... I mean it has sort-of, but if RL stops working, nothing can help...

I wanted to implement RL reset, but was told by creator of RL that it doesn't help. If you turn off and on RL (and not BT), then you will need to go into actions and call Reset RileyLink Config, which reconfigures RL after reset...

[Webifi]

I wonder if there's multiple conditions that RileyLink could be frozen in, with some of them potentially solvable via its reset command?

Perhaps once a month, or less, I've had my RileyLink get noticeably warm, bordering on hot, after AAPS lost connection with it, making me think it's stuck in some loop. After power cycler and reconnection to AAPS, it cools back down. However it doesn't heat up like that every time it requires a power cycle to reconnect with AAPS -- more like once in a blue moon.

Any advice on where/what I would look for in an attempt to determine if there's a specific operation, or combination thereof, AAPS/Medtronic driver is running that could be tripping up RileyLink?

[bchris21]

Same problem here. If I remove the batteries from my Orangelink will I have to reset its configuration?

[andyrozman]

@bchris21 Depends. If you also restart AAPS no, but if not yes. Especially if you use hardware decoding (MDT), or is you are using Omnipod. By default when RL starts its configured to Medtronic, but to base frequency and software decoding, so you have to reset config, so that correct frequency is set and decoding (and some other stuff). Too bad that RL doesn't remeber this base settings, our lifes would be much easier.

[Webifi]

Was this fixed? Why was it closed?

[andyrozman]

Reset command actually doesn't work... When I started working on RL under Android I talked with RL owner and he said that if RL is frozen/stuck, then it also can't receive reset signal... So it is useless.

bubbledevteam fix is being reviewed ATM, and guys did good job of fixing some problems, so it will be part of next release, as soon as fix remaing problems...

[xialff]

I'm rileylink + Medtronic 722 + aaps2.8.2. At the beginning, I always had the problem of pump disconnection. I had to restart my mobile phone every time. Later, I found that RL and pump must be put together. After that, there was almost no problem of pump disconnection. I hope it can help you.

[Alamo04]

I'm rileylink + Medtronic 722 + aaps2.8.2. At the beginning, I always had the problem of pump disconnection. I had to restart my mobile phone every time. Later, I found that RL and pump must be put together. After that, there was almost no problem of pump disconnection. I hope it can help you.

Can't confirm that. Never had problems with RL and range.

Also OL will work better if you have some range between OL and phone. OL has problems, if it is nearby the phone. You can see this, if you scan for RL and have a look at the signal strengh with different ranges.

The biggest problem of OL is the latest firmware 3.2. With 2.5 it works way better.

[xialff]

我是 rileylink + Medtronic 722 + aaps2.8.2。一开始，我总是遇到泵断开的问题。每次都得重启手机。后来发现RL和泵一定要放在一起。之后，几乎没有泵断开的问题。我希望它能帮助你。

无法确认。RL 和范围从来没有问题。

如果您在 OL 和手机之间有一定的范围，OL 也会更好地工作。 OL 有问题，如果它在电话附近。 如果您扫描 RL 并查看不同范围的信号强度，您可以看到这一点。

OL最大的问题是最新的固件3.2。 使用 2.5 效果更好。

ok However, as long as my RL and 722 are separated by a few centimeters, they often fail to connect. This problem is very troublesome. If I change to ol, can I connect to the global version of 722? Will I still need to put the two devices closely together?

[Alamo04]

I dont think that your problem comes from RL.

A friend had also many connection losts. Now, with Pixel 5 phone, he has a stable connection. He tried RL and EmaLink. Both are working fine now.

If you can, do a test with different phones.

There is only one reason for OL, that's the Batteries. RL works 62h with a fresh rechargeable batterie, OL 10 days with 2 Varta Industriall batteries. I have more connection losts as with RL, but they are short and are self fixed a few seconds later. OL firmware 3.2 didn't work with actual beta, or dev. OL is way more fragile as RL.

1.) Yes, you can use global pumps 2.) Its another RL, so nothing changed. You have to have it with you. But as I say, I don't need them to be close together. At home it lays in the living room and I have connection everywhere at home (80qm).

[rustymonkey]

This is very similar to https://github.com/MilosKozak/AndroidAPS/issues/2121 in earlier versions of AAPS. Unfortunately, I've also found that the problem persists in AAPS 3.0 B5--more specifically, that when the pump is temporarily moved away from the phone and rileylink, AAPS indicates that the RileyLink doesn't reconnect to the pump and the solution is to power cycle the RileyLink.

Nonetheless, I don't believe that this is solely a RileyLink issue, but rather an AAPS/RileyLink issue since: a) the same actions with Loop do not generally trigger this problem (when using Loop, it's very rare that the RileyLink needs to be restarted). b) Although the bug can be consistently triggered as follows: Temporarily move RL and Phone away from Pump (i.e. Phone <--connected--> RL <--disconnected--> Pump) and then move back into range --> failed reconnect The following very similar scenarios consistently fail to trigger the problem: i) Temporarily move phone away from RL & Pump (i.e. Phone <--disconnected--> RL <--connected--> Pump) and then move back into range --> successful reconnection ii) Temporarily move RL away from Phone and Pump (i.e. Phone <--disconnected--> RL <--disconnected--> Pump ) and then move back into range --> successful reconnection

The test results from b) seem really strange, but I was able to replicate this consistently (2-3x for each case). Assuming there are no test artifacts (e.g. BT signals in certain parts of the house affecting results) it seems to imply that when AAPS detects the RileyLink has lost a connection to the pump, it does something that _in the absence of a RL<-->Pump connection, causes the RL to enter a non-recoverable state (otherwise cases i) and ii) would also have failed).

---

Tested with AAPS 3.0 B5 on Galaxy S7/Android 11 (Pixel Experience), Medtronic 554, RileyLink ble_rfspy 2.0 subg_rfspy 2.2 Logs for the Case b) failed reconnection submitted to andyrozman

[rustymonkey]

Also tested this with Tested this with an Orangelink and it fails (and doesn't fail) in the same manner i.e..:

• Moving the pump out of range of the Phone&OrangeLink --> pump connection failures that persist until the OL is restarted
• Moving the phone out of range of the Pump&OrangeLink --> transient connection problem that resolves as soon as it's back in range

Tested with AAPS 2.8.2.10 dev 2021-11-11 11:40am on Galaxy S7/Android 11 (Pixel Experience), Medtronic 554, OrangeLink (2.5fw) BLE113 ble_rfspy 2.0 CC110 subg_rfspy 2.2

[classchneider]

Aaps must know there is no response from RL, why is there no alarm going off until I manually try to bolus?

[rustymonkey]

Re-Tested on 2.8.2.14dev 2021.11.30 19:29 running on an S7/Android 11 | Orangelink | MDT 554 in order to see if the Bubble team's OrangeLink fix #979 has solved this issue. It hasn't (which probably makes sense considering that the bug occurs for both OL and RL). i.e.

• Moving the pump out of range of the Phone&OrangeLink --> pump connection failures that persists! OL must be restarted to resolve the failure!
• Moving the phone out of range of the Pump&OrangeLink --> transient connection problem that self-resolves once it's back in range
• Moving the OrangeLink out of range of the Pump&Phone --> transient connection problem that self-resolves once it's back in range

[rustymonkey]

Retested with 2.8.2.20 (2022.01.25) running on an S7/Android 11 | Orangelink 1.0 (tested firmware 2.5 and 3.2) | MDT 554 with the "Use scanning" option from https://github.com/nightscout/AndroidAPS/pull/536 enabled, and the issue is resolved when that option is enabled!

Note:

• When 'Use scanning' is enabled, new RileyLink initializations consistently fail in this environment (documented at #1222 )

[blameyourelf]

@rustymonkey do you suggest rolling back to 2.8.2.20, or have you had any success getting AAPS 3 and OL to connect more consistently?

[rustymonkey]

3.0 has worked reliably in my testing. What you need to do is:

• Disable 'use scannning' and connect to the RileyLink
• Then enable 'use scanning'

The connection has been stable in my testing, and there hasn't been a need to delete/re-add the RileyLink as was sometimes required in the past when the connection was lost, so issue #1222 shouldn't crop up unless you have to switch to a different RileyLink / Orangelink.

[Webifi]

The 'use scanning' options seems to have made things a bit more stable using a RileyLink + Medtronic 523 with AAPS v3.0, however:

1. Every couple days I find I still need to Force Stop AAPS and then restart it to get it to re-connect with RileyLink.

2. So far I haven't needed*** to power cycle the RileyLink since enabling 'use scanning' -- just killing/force-stopping the AAPS app. (Needing to power cycle the RileyLink didn't happen all that often before, though it seemed to come in waves when it did, so I'm not sure if that's improved or not yet. When the RileyLink needs to be power-cycled I can usually tell by the thing heating up like crazy in my pocket.)

*** edit: Had to power cycle RileyLink, and restart AAPS 2 times now to get things going again. Both times happened after the connection between my phone and the RileyLink was attenuated.

[blameyourelf]

I've just had to reinstall v2.8.2 (version with the bubble OL fix) which was incredibly stable for me using one plus 8 pro, orange link, Medtronic 722. I was having recurrent pump unreachables which were not reconnecting automatically whether scanning was on or off. While it was easy enough to manually reconnect (remove orange link, shut down AAPS, restart AAPS and re-connect orange link with scanning set to off), couldn't accept multiple unreachables, including during the night, which did not happen with bubbledev 2.8.2

[tepidjuice]

I have this issue as well. Requiring power cycling of the RL a few times a day. Any news on fixes?

[andyrozman]

@tepidjuice Some phones have very bad power management (PM) which is usually visible on usage of BT devices (ours are affected because be keep connection open all the time)... They had to do changes on Xdrip so that they would support this Bad Android BT API implementation. As far as I know Samsungs, Redmi's and newer OnePlus phones are affected (I think A12 and A13 mostly)... And a lot of new phones also tries to do this strict PM instead of regular (and correct one) so list of "bad" phones is getting longer...

[tepidjuice]

@andyrozman Annoying that it's on the side of the phone. I use a pixel 7. I guess this is on the list of 'bad' phones? Would there be any chance of implementing the xdrip changes to the medtronic driver? As xdrip works almost flawlessly...

The bt stack is a complete mystery to me so I have no idea how feasible this would be.

[dcacklam]

1) Bug still persists as of Sept 2024.

2) Phone: Pixel 7 Pro, bridge device: Orange Link Pro, Pump: Medtronic 722. App version 3.2.0.3

3) Occurrs randomly throughout the day, including at night when the orangelinl and phone are never more than 4ft from the pump. A pump connection error occurrs and several hours can pass without pump connectivity unless the app (and often the orangelink) are restarted.

4) Can be forced to occur by taking the pump out of range of the orangelink.

[DetaoOfficialMusic]

1. Bug still persists as of Sept 2024.
2. Phone: Pixel 7 Pro, bridge device: Orange Link Pro, Pump: Medtronic 722. App version 3.2.0.3
3. Occurrs randomly throughout the day, including at night when the orangelinl and phone are never more than 4ft from the pump. A pump connection error occurrs and several hours can pass without pump connectivity unless the app (and often the orangelink) are restarted.
4. Can be forced to occur by taking the pump out of range of the orangelink.

Can confirm as well this is a broad phone issue with similar BLE protocols.

1. Phone: Samsung Galaxy S24 Ultra, bridge device: Orange Link Pro, medtronic 522LNAS
2. Occurs randomly throughout the day, if the link and pump are not in the same pocket essentially touching one another.
3. Fix is force closing background app, closing AAPS. Turned off scanning and it almost immediately initialized, acknowledged ready connection status and pulled history from the pump within seconds. First time I haven't had a hang up since starting on aaps.

Also strangely enough, slowly but surely pump battery usage optimization has degraded. I have not confirmed whether it's hardware on medtronic side or possibly a constant attempt to keep the connection to the driver alive because it's struggling to maintain connectivity.