Android uploader occasionally stops pump receiving SG values.

[mattmholliday]

Your Environment

• Uploader Version Number: v0.2.1
• Your Android Phone Model Name: Samsung Note 3
• Android Version Number (e.g. use 4.4 for 4.4.4): 5.0
• Network Connection at the time the issue occurred (Wi-Fi, Mobile): Wifi
• (if relevant) Nightscout website version (e.g. 0.8.4 Funnel cake, master / dev branch): dev

  Brief Explanation of Issue

When using the uploader occasionally my pump stops receiving SG values and just displays --- on the pump display.

On the android uploader it displays .00 mmol/L (Double down arrow) Pump time Correct Active insulin correct Rate of Change: DoubleDown

Uploader Error Code

None

Steps to Reproduce (for bugs)

1.Connect carelink usb to Phone

2. Confirm Values uploaded
3. Sometime later (minutes/hours) pump stops reading SG values.
4. Unplug Carelink USB and pump starts reading values again within 20 minutes.

   Severity Score

3

[pazaan]

How are you able to determine that there's any causality between the uploader and the values on the pump? If the pump is displaying "---", then the value on the Uploader will definitely be 0 with two arrows down (already a known issue for this is available at #20).

The only way to know for sure that the Uploader was causing this, is to press "Stop uploading CGM data". If the value on the pump shows up within 5 minutes, I would definitely concede that there's a possibility. However, I frequently get "---" on the pump as an instantaneous result - even before the advent of the Uploader.

[mattmholliday]

[mattmholliday]

Looks like it is still receiving pump status just not SG as they become unavailable to the pump.

[pazaan]

Right. That's to be expected. If the CGM status is unavailable on the pump, then the Uploader will certainly follow suit. There's no reason to assume that that uploader is the cause of the lack of SG availability on the pump, though.

[pazaan]

Just to clarify further. The app does not maintain a connection with the pump. It only opens a connection for the period that it's polling. It's certainly worth removing the "Connected to CNL on channel x" message after it's finished the poll, so that there's no impression that there's an ongoing connection.

[mattmholliday]

how odd.. When not using the uploader I am able to see a continuous readout of SG on the pump.

I only seem to get breaks in data when using the uploader. Will keep trying to narrow it down over the next few days.

[pazaan]

When you say "breaks in data", do you mean the values on the display? Or actual gaps in the graph (the photo above shows no gaps in the graph)? The SG values are stored in a buffer in the transmitter. So if the instantaneous value can't be read by the pump, it will download and "backfill" the graph when it gets a successful connection. If there's an instantaneous blank ("---"), either shutdown or outright kill the Uploader app. If you can consistently reproduce data being displayed on the pump within 10 minutes after doing that, then there may indeed be something to it.

[pazaan]

On hold. See if resolving #28 will fix this. If not, we'll need more logging.

[Pogman]

Possibility of a clash going on between the CNL and Sensor. I have noticed some breaks too and today during a calibration there was a "BG not received" and radio icon on the pump was blank. I stopped the uploader until calibration was finished. Will keep an eye on this and report.

[Pogman]

Been watching the drop outs and noticed that the connected channel is 20 when this is happening for me though may be coincidental. I've also tried to make sure that the uploader is started 1 to 2 minutes after a SG update on the pump but still getting drop outs. Just adding this as an observation in case it's useful.

[Pogman]

Today I started the uploader as soon as a new SG value appears on the pump and no dropouts just occasional non-connects from the uploader but SG still being shown on the pump. Adding the polling sync is probably the right fix for this.

Edit: scratch that maybe I was lucky but still getting dropouts and can't find a pattern using a variable init time.

[pazaan]

I've added a change in 0.3.0 to poll 1 minute after the next expected SG from the CGM to try to overcome this issue. I won't close this ticket just yet, but interested in feedback.

[Pogman]

Been running v0.3.0 for around 6 hours now and had 10 dropouts due to radio channel changing. Only seems to change channel when using uploader and I don't see this happening in the same environment with regular pump/sensor use. There may be local interference of course but using the uploader makes it very fussy indeed. Another observation that could do with being checked further is that I was doing a big data dump from the pump to the carelink site and pump was happy on the same channel and received sensor readings concurrently.

[pazaan]

@pogman, the app doesn't pick the channel, the pump does. All the app can do is scan through the channels until the pump responds.

[pazaan]

How can you tell which channel the pump is using, other than due to it being exposed in the app? CareLink doesn't tell you which channel you're using AFAIK.

[Pogman]

You mentioned before about storing the channel (to save power) - I wonder if not doing the scan would make the pump less fussy?

For the carelink thing - I didn't know the channel I just obs that the CNL was in comms with the pump when a sensor update showed.

[pazaan]

Yep, storage (and attempted reuse) or radio channel is tagged for 0.4.0

[Pogman]

Cheers! Bit to soon to tell but the severity of the drops may have lessened ie. it resyncs sooner in 0.3.0 with one sensor reading missed rather the 2 or 3.

[tuzoenduro]

Hello Lennart, I seem to get the occasionnal losses of SG values that Pogman mentions, today I've counted about 3 or 4 breaks, of about 15 minutes each...

As a curiosity, do you have an idea when the 0.4.0 milestone will be up?

thanks for all the great work!

[volkerrichert]

Hi Lennart,

we have the same issue. So, i take a look at your codes. Maybe i found a reason the sensor "disconnect" form pump. In line 173 of MedtronicCnlIntentService cnlReader.openConnection() is called. If an error occurs closeConnection() at the end of the try / catch will not be called.

The last time i saw the issue the app send "Could not close connetion: Expected to get control character '6' Got '81'".

Maybe a dangling connection inside the pump causes it.

[rahim]

I also experienced this within minutes of first using the uploader (0.4.0), pump readings reappeared after disconnecting and waiting.

Does everyone experience this issue? For those that do, what proportion of the day does the pump lose its connection to the sensor?

[volkerrichert]

At the moment we have a kind of "sometimes". Sometime none for 1 or 2 days and 3 times the next day. Bur we are just setting up the env. We need to charge the phone for a few hours with disconnected USB.

[volkerrichert]

Is there a documentation of the protocol?

[pazaan]

@volkerrichert, I have some documentation at https://github.com/pazaan/decoding-contour-next-link/blob/master/Bayer-Medtronic-640G%20USB%20HID%20Interface.xlsx and https://github.com/pazaan/decoding-contour-next-link/blob/master/Random%20Protocol%20Notes.txt (though this is not clearly defined).

[volkerrichert]

THX

[Tausta]

Your Environment

Uploader Version Number: v0.4.0-snapshot
Your Android Phone Model Name: Google Nexus 7 (2013)
Android Version Number: 6.0.1
Pump: 640G 2.9D
Transmitter: Guardian 2 Link 2.0C / 3.0A

Originally we had Guardian 2 Link transmitter version 2.0C. We tested uploader two times couple of hours, and both times this issue happened. Due to other problems, we got new transmitter. With this new transmitter version 3.0A this issue has not happened.

[Pogman]

I have 2 transmitters the 2.0C (F013) and 3.0A (F014) and it has not made any difference to dropouts for me unfortunately.

While I'm here I'll note that mobile phones spam the 2.4 band with signal probes (part of the non-gps location id-ing). This may be in part causing some noisy comms and channel changes. I live rural but due to having less buildings blocking radio I can see passing cars and phones throwing out probes using an analyser.

[volkerrichert]

Interesting. We have 2 CNL. An older one connected to the uploader and a brand new one for calibrations etc. How to i find the version numbers?

[Pogman]

These are transmitter versions. The firmware number is on the back of the transmitter, F013 or most recent F014. Also look in the pump status menu under sensor for version info.

The CNL can be accessed by going to the customer service menu and using access code "3422" to get version info from that.

[rahim]

The transmitter version I experienced this with was also F014/3.0A.

[rahim]

Thanks for the info @volkerrichert, that's useful.

I'm still trying to get a handle on how this affects different people, do some of you run without ever experiencing this, or is it more a case of varying rates of occurrence, but everyone using the uploader has seen this at some point?

@pazaan: newbie question: am I correct in thinking the pump can't hold open concurrent connections to the Guardian transmitter and CNL, regardless of channels?

@Pogman, you said:

Only seems to change channel when using uploader and I don't see this happening in the same environment with regular pump/sensor use.

How did you determine that the transmitter was changing channel?

[Pogman]

How did you determine that the transmitter was changing channel?

In the uploader app you can see the channel in use and when that changes. It doesn't always change channel and I presume the pump has initiated a channel change but ultimately decided to go back to the one it's on, this still causes a drop.

I'd like to know too how some people get very few drops! I was in the city the other day and constant drops.

[volkerrichert]

@Pogman : by drops you mean missing values received from the pump?

[Pogman]

Yeah - missed values from the pump

[volkerrichert]

i have done a bit of work last weekend. It seems to be a restart problem. I fixed it beside a time drift. I just miss one every one or two hours. see issue 76

[Pogman]

That's good news! Can you provide a .apk (maybe on your own git page), at least we can do some testing and see how it goes.

By time drift do you mean the drift coming from the pump? The pump has the worst clock drift in an electronic device I've seen for some time!

[volkerrichert]

I'll like to make a push request. I don't want to spilt development into multiple repos.

I don't know why, but i think that's not the point. The next sgv request will scheduled based on the timestamp of the last one. (+5min 30 sec). In theory none should be missed. But.... :-) The android doc said that the alarm i used now is exact but it seems to be, lets say, "not very" exact. Maybe we have to redesign it

[Pogman]

Not looking to have you split development I just want something that may work better and it's been a long time since the last release. I think some testing on this issue from multiple users would be a good thing to do.

[volkerrichert]

i can put the current unsigned apk on dropbox. contact me, i interested

[Pogman]

Thanks @volkerrichert no way to message you directly in github except via the issues.

[pazaan]

@volkerrichert Which alarm are you using now? I was trying to avoid deprecated alarms in the code. I would also suggest Gitter as a way to interact more directly, rather than comments on this issue.

[volkerrichert]

@Pogman : ok. I'll try to find a smooth way. Do you have a build env?

@pazaan: Hi Lennart. I'm still using the alarm manager, but i try to find out why i have these drifts. I'm testing setExact (API 19) instead of setRepeat but this doesn't fix it. I have to take a closer look at the weekend. Maybe switching to a handler is a good idea.

I joined gitter.im/pazaan/decoding-contour-next-link

[volkerrichert]

@pazaan: How do you handle the API-Key of fabric.io inside the manifest?

[volkerrichert]

@Pogman @pazaan I pushed my latest changes to my fork. So you may take a look. I#l create a pull request after knowing whats going on.

@pazaan : what changes do you made on your codes? maybe we shall merge them to avoid mass of conflicts.

[Pogman]

@volkerrichert I'm not set up to do any dev or compiling here and I don't want this to be a hassle for you. Anything to reduce missed pump readings from what's looking like various causes is a big deal specially for potential use down the line as a AP system.

[pazaan]

@volkerrichert I have a lot of changes, which I should push into master. Many of my changes are also to try and address drop-outs and drift.

[MenKuch]

Sadly, issue is still present. Created an apk from the 0.4.0 sources 10 days ago and tried it - sometimes, it runs smoothly for 8+ hours, sometimes the pump looses the sensor transmitter connection multiple times an hour and misses 1-3 readings per dropout. Also getting --- reading on the pump during these times. It does not seem to matter if the CNL is nearby OR if the CNL is barely in range.

I think we can safely assume that somehow, the CNL communication is interfering with the sensor communication. Without the CNL/Uploader, I have seen sensor dropouts, too, but maybe once a week.

Has anybody got a "testing environment" (i.e. wearing the pump/CGM yourself)? I do not want to fiddle with the CNL/Pump too much when my child is running around wearing the pump :-) I think it would be great if we could try to:

a) Just leave the pump connection OPEN to test if this results in loosing the sensor reliably/more often (then this could be the issue) b) Opening the connection every 5-10 seconds and see if this leads to more dropouts c) Open the connection not 5:30 minutes after the last reading, but 6 or 7 minutes later and see if this results in a more reliable sensor connection

Despite this issue, the Android uploader has made our life much easier. Thanks to all who contribute to it.

---

Uploader Version Number: v0.4.0 (pulled on Dec 6th 2016) Your Android Phone Model Name: Sony Xperia Go Android Version Number (e.g. use 4.4 for 4.4.4): 4.2 Network Connection at the time the issue occurred (Wi-Fi, Mobile): Wifi

[volkerrichert]

hi @MenKuch,

this is an android "issue". The system tries to max battery life. On my Samsung S4 i have to whitelist the app in "smart manager". So maybe Sony has something similar. Starting Android 6 the used alarms is limited to 1(!) per 9 minutes. I have changed it to normal alarm clock mode. You can give both a try.

And yes, the "test system" is running way. ;-)

[MenKuch]

Hey @volkerrichert,

thanks for your reply. I do not think that the very root cause of this issue is Android-related. Of course, the timing may be difficult because of OS restrictions BUT there might be a way to not drop the sensor connection caused by the CNL connecting even if we cannot guarantee precise timings.

It would be awesome if you could test to just not closing the connecting after a read from the pump. If this reliably drops the sensor connection, maybe we're missing a close of the connection somewhere in the code (I just started reading through the code - sadly, I am from the Mac/iOS side of the pond :) )

[volkerrichert]

@MenKuch, one question: Do you mean missing SGV in NS or "disconnecting" the transmitter / sensor from the pump? This happens when CNL and sensor try to talk to the pump simultaneously. If Android doesn't wake up at the right time it may interfere in communication between sensor & pump. So we have to focus on precise timing. Maybe switch in to setAlarmClock for every API Version can be useful.

Give it a try. Maybe better than depend on a tool like smart manager.

Btw: Have you tried the master of pazaan or the "latest" pull request? compare

https://github.com/pazaan/640gAndroidUploader/blob/master/app/src/main/java/info/nightscout/android/medtronic/service/MedtronicCnlAlarmReceiver.java#L56

https://github.com/volkerrichert/640gAndroidUploader/blob/master/app/src/main/java/info/nightscout/android/medtronic/service/MedtronicCnlAlarmReceiver.java#L56

setExact is known not to be that "exact"