Non-Phone uploader only using WiFi

[HenrikHL]

This is not really an issue with the 600SeriesAndroidUploader but a query if you have heard about a "stationary" uploader which can be wall-plugged 24/7.

My D1D daughter is now 12 and we do not monitor her a lot during the day - we only use the uploader during the night in order not to get out of our own bed in order to check the BS. The phone which we have been using so far is getting quite worn and normally only lasts for 4-6 hours (I know a new battery would solve this).

I cannot find a solution where it is possible to power the phone and at the same time have the OTG cable plugged with the Contour Next 24/7 - so I thought that someone must have tried a solution where they have an Intel Edison or RaspBerry Pi computer connected to a Contour Next? I guess having multiple of such devices could potentially cover the entire house. Only requirement is that it needs to be connected to the net via WiFi.

Any info would be appreciated :-)

And again - thumbs up to all of you for the great work - the last uploader version is fantastic!!!

[pazaan]

You can run LineageOS (a version of Android) on a Raspberry Pi 3. You can get the build here

[Pogman]

Lots of Android based mini-pcs that should work and they're cheap too. These are often just used for HTPC stuff, connect to a tv for setup and then run headless (no screen) after that.

A PC running an android emulator. Us lot use the free version of Genymotion emu for dev work but also fine for non-dev just standalone.

[HenrikHL]

Thanx for the quick reply - any of you two running such a device? Or are both of you just running with phone?

[Pogman]

Day to day it's just a phone for me.

[Fishbaits]

Can android-of-things be used on RPi3? First - I'm no programmer. I have a pre-release 0.7.0 running at moment on RPi3 but cannot figure out how to start the app properly..

[pazaan]

@Fishbaits I have never tried Android-of-Things. As mentioned in an above comment, the only solution I know for sure that works on RPi3 is LineageOS.

[volkerrichert]

We use a Y-OTG cable to power phone and CNG during night (https://www.amazon.de/gp/product/B00M1H5348/ref=oh_aui_search_detailpage?ie=UTF8&psc=1)

Not the best one.

[aendes]

Hello,

i have used different OTG- Cables. Some fit better, some not. On my Moto G5 after some month i changed the cable and everything was connecting perfect again.

But now i bought a Moto g5s and i didn't found a OTG Cable with works. Every cable get disconnected from the port, as soon as i touch the phone or the cable

Andreas

volkerrichert notifications@github.com schrieb am Do., 26. Juli 2018 um 10:54 Uhr:

We use a Y-OTG cable to power phone and CNG during night ( https://www.amazon.de/gp/product/B00M1H5348/ref=oh_aui_search_detailpage?ie=UTF8&psc=1 )

Not the best one.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/pazaan/600SeriesAndroidUploader/issues/210#issuecomment-408026816, or mute the thread https://github.com/notifications/unsubscribe-auth/AhyasTitlmoBt5LMOnQf2XCx2LDH6prsks5uKYOpgaJpZM4Su3Mm .

[HenrikHL]

@volkerrichert - I have tried a couple of these Y-OTG cabels and they don't seem to work...?!? Maybe it has been the quality... I think I have tried 3-4 different ones without success :-(

[volkerrichert]

Me too.

[pazaan]

Adding a label to document the Pi 3 solution.

[steffen-AEI]

Over the past week and the better part of the weekend, I setup a RasPi 3B with Android 9.0 (from konstakang.com) but the device froze when the Uploader was opened and the Contour device attached. (I saw some major sluggishness enter the scene already with the installation of gapps, this may or may not be related.)

Fortunately, I still had a 2012 tablet on the shelf that runs 4.4.4, has a separate charging socket, and supports OTG. Does this count as "non-phone, only using WiFi"? ;)

Since I've been doing this for a good friend and don't have access to neither the pump nor the meter, I cannot pursue this further - at least not as long the current setup works. Perhaps the 640G will be replaced anyway in the near future (because of age and brokenness).

Thanks to @pazaan for his excellent work - the winking owl in the status bar is much appreciated ;)

[pheppy]

Not quite a non-phone solution, but I have an old Sony Xperia Z that has seperate charging connectors that work with its cradle. Some tweaking on de cradle provide access to the usb port. Since then charging and uploading is working. You do need a relatively old sony xperia. The Xperia Z1 compact has a usb-cradle which does not help. Also wireless charging might help you like the Samsung Galaxy S6.

Finally a PC/Laptop with VirtualBox running android might work. I tested with a usb flash drive. The Android VM was recognizing the usb storage immediately. Doesn't take much time to try a nightscout setup. Also we recently replaced the 640G with 670G. So my current setup will be working for another 4 years.

[HenrikHL]

@pheppy - could you elaborate a little on "Some tweaking on de cradle provide access to the usb port" - what does that mean? Is it software or hardware tweaking you are referring to?

[steffen-AEI]

@pheppy what's the latest available Android upgrade for that device, and do you have a model number or hardware code name? I'm somewhat worried that future upgrades to the apps will require an API level that's not provided by e.g. Kitkat (4.4.4), so I'm looking for alternatives that can persist for a bit longer... (Sony seems to have stopped support at Lollipop 5.1.1 but there might be Lineage.)

@HenrikHL I think it's about mechanical tweaking, i.o.w. dremeling stuff away that otherwise would block access to the USB port. Unfortunately I cannot find any pictures showing the left (cradling) side, is there more than https://www.gsmarena.com/sony_xperia_z-pictures-5204.php ?

The Z does OTG properly? I was somewhat disappointed when I found that connecting a USB mouse to the Z5 Compact (aka Mini) would not light up the LED, i.e. connecting anything by OTG to the Z5C wouldn't work? (I cannot rule out I made a stupid mistake, but this is how I use to first-level check for OTG functionality, and it works for my OPO, Amazon Fire 7, and that ancient Ainol Flame.)

I don't have a laptop to spare for this task (and it's hard to carry around - but would at least provide a stationary solution as asked for in the OP) - that's why I tried to get the RasPi to work (and I'll get back to that later, I hope). Whether the 640 will be replaced by a 670 still has to be found out - the sensor (handling, and random calibration requests) is not appreciated at all...

[HenrikHL]

@steffen-AEI please write here if you get the RaspPi to work. I tried about a year ago but couldn't get it up and running :-(

[Fishbaits]

Raspberry does not have a proper usb otg port, it cannot work. Use bananapi or others like that. I personally have a BananaPi M2 Ultra working as uploader. Almost no problems whatsoever except maybe once in a month or two CNL needs to be removed and reconnected for USB connection error.

[HenrikHL]

@Fishbaits according to this comparison: https://www.hackerboards.com/compare/126,251,186/ there is OTG support on the Rasberry. When you say "not have propper OTG support" - are you saying there are different levels of OTG support and for some reason the Contour Next is not supported? Could you also write what software you are running on your BananaPi?

[Fishbaits]

BananaPi has official support for Android, that is what I am using. With Raspberry I tried all I could think of but I never got it to work. Even bought Emteria version but not working. Occasionally got it to read one or two times and then it died. Raspberry did say that they have host mode but not otg, might have something to do with that. BananaPi works fine. Separate port for OTG and power, even bought original 7" LCD with touch, all works. I also have a second unit - BananaPi Zero - also works but this small hdmi socket is lousy and not giving good contact, so running headless. You probably can find anything you want in internet. Here is another big chart on what has OTG and what not: https://en.wikipedia.org/wiki/Comparison_of_single-board_computers#I/O_interfaces_and_ports

[steffen-AEI]

@Fishbaits this is where things start to get interesting (and possibly back to the original subject)

Although I'm still wondering why OTG is such an issue with Pi SBCs - if they come with an extra power supply socket, and have proper host mode, there's no need to provide OTG as well (which basically has been designed to have a "one stone two birds" way to interface small handheld devices both to chargers and USB devices). So while for a mobile phone that cannot afford a full-fledged USB type A socket, OTG is OK. For any Pi I know (not the Zeroes though) there's at least one type A connector, and host mode is provided - otherwise one couldn't connect any external USB devices. And there's no point in having an OTG connector if the device cannot be powered otherwise, externally or internally.

The highest Android version I could spot for the BananaPi is 6.0 - Marshmallow is a couple of years old, and while it is still supported by apps, there are only very few devices getting OS upgrades. On the other hand, the 9.0 experiment may have failed exactly because of 9.0 - and if I ever get my hands on the CNL again, I'll give 7.1 or perhaps 8 by konstakang another try. The BPi is supposed to be GPIO compatible with the RPi, thus I'm not surprised that the LCD works.

Can you elaborate on the details of your setup, in particular which Android image, GApps (if any), etc.? Did you indeed connect the CNL to OTG, not to a real type-A port? For now there are only reports of non-working setups, and this addition might be a big improvement of the situation. Thanks!

[HenrikHL]

Just got a link to these two FB posts where people have Raspberry Pi up and running: https://www.facebook.com/groups/NightscoutForMedtronic/permalink/1864929396851699/ and https://www.facebook.com/groups/NightscoutForMedtronic/permalink/2813552561989373/

[steffen-AEI]

Great. I've been avoiding FB and WA, and will continue to do so. Bye...

[Fishbaits]

I can take photos later, when I get home. I am using BPi original OS, http://wiki.banana-pi.org/Banana_Pi_BPI-M2U#Image_Release Not sure it is still same version as I started mine about a year ago I think. Cannot remember about GApps too, probably nothing more than what came with OS image + 600 uploader.

[Fishbaits]

Ok, basically nothing special or interesting or complicated. M2U is running Android 6.0.1, it has GPlay etc from the start. Using OTG socket with adapter from micro to regular. It has BPi 7" screen working through MIPI DSI interface. For testing I connected bigger antenna to CNL, still not sure if it actually helps too but I think it does :) http://www.itvara.ee/Uploader/1.jpg http://www.itvara.ee/Uploader/2.jpg http://www.itvara.ee/Uploader/3.jpg http://www.itvara.ee/Uploader/4.jpg

[pheppy]

@Fishbaits I'm curious about your antenna hack, I've a similar antenna. And a few extra meters would help to monitor in the living room as well.

@HenrikHL the cradle indeed blocks the USB port. Therefor I'd to remove a small part of the plastic cradle. A dremmel could have helped. As far as I can remember I used simple tools like a handsaw and pliers. You can see result in the foto's. You need the original Sony cradle or build your own (https://www.instructables.com/id/DIY-Sony-Xperia-Z-Desktop-Charger/)

@steffen-AEI Model XperiaZ is C6603 and indeed I'm running 5.1.1. LineageOS 15.1 (8.x Oreo) is available on XDA. I've had no problem whatsoever on the OTG, flashdisks also work just fine. I do have to re-attach the Contour device every now and then. Otherwise no complaints. We take this device very long cartrips (carcharger), vacation, camping (big powerbank) and sleepovers at friends. I guess without nightscout my son would have no sleepovers or camping with friends (although the new 670G gives us some comfort)!

https://drive.google.com/file/d/18y3t5Cex-h3H9Uw1LL-w2SMqduM10eTz https://drive.google.com/file/d/1iVUF8SWLpP5yfrhCSiAT_KtWrQfsrltL https://drive.google.com/file/d/1GXdoOkqDXu66b5Cg6J9dKGLTQ2Z0q4Y5 https://drive.google.com/file/d/19UEb6lNTBxVmrZ4G_PRt8yTCj1iTzNhQ

I expect Xperia Z3 and Xperia Z3 compact to work with DK48 charging cradle to work even without mechanical tweaking.

[Fishbaits]

CNL has antenna socket inside, no opening so drilling is needed. I am using a CRC9-SMA/F connector and then just regular wifi antenna.

[steve8x8]

I went to find the radio frequency that CNL and pump use to talk to each other - and came across a FCC document that lists the 2.42~2.48 GHz range. In other words, the radio transmissions of pump/CNL and WiFi (and also microwaves) use the same frequency range. Did you know that beforehand? Also at 0.4mW, interference by WiFi (up to 100mW, IIRC?) would explain the short range of the communication - I'm surprised that it doesn't fail more often!

[pazaan]

I went to find the radio frequency that CNL and pump use to talk to each other - and came across a FCC document that lists the 2.42~2.48 GHz range. In other words, the radio transmissions of pump/CNL and WiFi (and also microwaves) use the same frequency range. Did you know that beforehand?

Hey @steve8x8 - yep, I’ve known this since the beginning. See the first few lines of https://github.com/pazaan/decoding-contour-next-link/blob/master/Random%20Protocol%20Notes.txt for the exact channels that the CNL uses.

As to the surprise about not failing more often - it fails more often than the user is aware, but failures and retries are handled at the protocol level.

[mortlind]

@HenrikHL

I am not a fan of Android or any kind of uploading of my daughters intimately private data to any kind of cloud. She is 11 years old, and have DT1.

Thererfore I have built a simple application, deployed on an RPi, using the decoding-contour-next-link with a CNL24 plugged in, located at the centre of our house, and presenting a Pyro4-interface on an ssh-connection to a PC our LAN, but routed through our external gateway; which is also an RPi, running DNSMasq+ShoreWall. On this PC I made a web-application with Flask+SocketIO and a JS-based browser interface. See the attached screenshot with fake data; it looks like this on my laptop and on my phone alike.

The RPi with the CNL24 plugged in can move with her when she visits a friend or when we go on vacation, provided I prepare the WPA-supplicant configuration with appropriate SSID and passkey. This have worked for several years for us, and is very practical.

I have often thought about publishing this, but every time, I consider how many people would actually want to run this kind of infrastructure themselves, when it is so much easier to just upload everything to some US-based tech- or industry giant. If, however, you are interested, I will help you set it up, and I would welcome you to participate in further development.

[Pogman]

You can host NS + DB on your home server and use a android build that works without any big corp exterior access. You should publish your work, looks like you have put in a ton of work, I'm sure there are others who would like to use your approach.

[steve8x8]

Also there's (still work in progress) https://github.com/ondrej1024/ddguard which is based on work by @pazaan, and may perhaps be enhanced by a Nightscout uploader (it's using blynk cloud services right now). It should be able to run on the smallest RasPi (ZeroW, so you get WiFi connectivity), it's just the power consumption of the CNL stick that may limit its "mobility". What's intriguing is that customizing a Linux system is much easier than tweaking Android. Now add a 3G dongle to the whole setup and you're independent of WiFi passphrases...

[ondrej1024]

Also there's (still work in progress) https://github.com/ondrej1024/ddguard

Yep, I have already successfully tested the first version of the Python Nightscout uploader for DD-Guard. It sends the live sensor and pump data to NS (no treatment data yet). Need to find some time to integrate this with the pump data reading of the DD-Guard application.

Comments are welcome.

[ondrej1024]

Yesterday I've put in a nightshift and the Nightscout uploader integration into dd-guard is progressing well. Just a few bits are still missing. One of them is the handling of the sensor exception codes.

What should I send to the NS API in case there is no real SGV data but one of the exception codes (0x0300 and higher) ?

I found the mapping in this source code but can't find what is actually send to Nightscout.

[Pogman]

It's in the same source file here. Values are sent as sgv values to NS for exceptions.

[ondrej1024]

OK, found it. Thought it was more complicated. Thanks. So NS displays no meaningful messages in these cases, just an error code ("?SN", "?MD", ..)

[ondrej1024]

The Nightscout uploader feature of DD-Guard is functional now. The DD-Guard gateway sends the following live data to your Nightscout server:

• SGV
• Trend
• IOB
• remaining insulin
• 670G battery

If you want to have a look or try it out, it's in the nightscout_uploader branch of the DD-Guard project.

Here is a screenshot of both user interfaces after a night of data upload:

[ondrej1024]

Here's a question to the experts :wink:

Sometimes the 670G reports SGV = 0, Trend = "three arrows down" and a timestamp of "Jan 1 01:00:00 1970" which means it didn't receive any data from the sensor. How is this condition reported to Nightscout?

[Pogman]

Your probably in a "lost sensor" situation where the pump will eventally recover the signal and backfill the sg data. The android uploader will report this with a "lost sensor" message in the NS pump status pill and will not send any sgv or trend in the device status json upload.

[ondrej1024]

I have fixed some issues and now you can run the DD-Guard gateway exclusively as a Nightscout uploader. This makes sense if you are a user of the Nightscout GUI but prefer a RaspberryPi and Linux based uploader device instead of an Android phone. Admittedly it has not all the bells and whistles that you get from the Android uploader app but it gets the basic things done.

The latest changes are released to the DD-Guard repo master branch. It would be great to have some feedback. Let me know if you think this is useful.

I will now concentrate on getting DD-Guard to run reliably on a RPi-Zero-W so the gateway would become a portable device (see issue #261), even smaller than a phone :smile:

[ondrej1024]

@Pogman and @pazaan : is it possible to read the active basal rate in auto mode from the 670G? I checked the packet structure doc which describes the comms messages but couldn't find it there. Thanks.

[Pogman]

There is no active basal rate when the pump is in auto mode. The pump status message does not contain any info related to auto mode that I had found. All AM info in the uploader comes from the history data.

[mortlind]

@Pogman If the pump is not in auto modus, how do you get the actual basal rate? I can only get the programmed and temporary, which will be wrong if the pump has gone "auto-off".

[ondrej1024]

@mortlind If I understand this correctly, when the pump exits auto modus it should apply the programmed basal rate for this specific time of day. So this is the basal rate you get in the pump status message.

[ondrej1024]

Instead the basal rate in auto modus is calculated continuously by the pump and not reported in the pump status message. What file in the uploader source should I look at to see the handling of history and auto modus data?

[Pogman]

Here's some info related to the status message. Check this item... BR = basal rate (div 10000)

The status message BR is only valid when not in AM. I can't quite remember but the BR may still contain the pattern rate even in AM, not sure if it was zero then.

----------------------------------------------------------

Status Message Payload

           ?0 ?1 ?2 ?3 ?4 ?5 ?6 ?7 ?8 ?9 ?A ?B ?C ?D ?E ?F
0x00000000 XX XX XX QQ nb NB NB NB -- -- -- -- NM NM NR nr
0x00000010 kb KB KB KB KT KT KT KT KR kr BP BR BR BR BR tb
0x00000020 TB TB TB TR TM TM bu BU BU BU PP rr RR RR RR RH
0x00000030 RM ii II II II SV SV ST ST ST ST SO SO SO SO LS
0x00000040 SA SS SU SC SC SB SX SX BW BG BG WW WW WT WT WT
0x00000050 WT WO WO WO WO WS WM WM sm sm SM SM sn sn SN SN

XX = header

QQ = pump status
BP = basal pattern / [bits 4-7 temp pattern | bits 0-3 basal pattern]
BR = basal rate (div 10000)
TB = temp basal (div 10000)
TR = temp basal percent
TM = temp minutes remaining
BU = basal units delivered today (div 10000)
PP = battery
RR = reservoir (div 10000)
RH = reservoir hours remaining
RM = reservoir mins remaining
II = active insulin (div 10000)
SV = sgv
ST = sgv time rtc
SO = sgv time offset
LS = low suspend active
SA = sgv trend
BW = bolus wizard
BG = bgv

WW = alert fault code
WT = alert time rtc
WO = alert time offset
WS = alert silence mode (1 = high alerts only / 2 = high & low alerts / 4 = all sensor alerts)
WM = alert silence minutes remaining

NB = now bolusing amount delivered (div 10000)
NM = now bolusing minutes remaining
NR = now bolusing reference

KB = last bolus amount (div 10000)
KT = last bolus time
KR = last bolus reference

SS = sensor status
SU = sensor control?
SC = sensor calibration minutes remaining
SB = sensor battery
SX = sensor rate of change (div 100)

SM = sensor mode count? (incs each sensor on and each off and at other unspecified times/events)
SN = sensor mode count? (incs each sensor on and each off and at other unspecified times/events)

-- = unknown use or zero while monitoring

lower case used for unconfirmed but assumed related values ie: rr RR RR RR (is it 24bit or 32bit) 

----------------------------------------------------------

[QQ] 8bit  = pump status

00000001 = suspended
00000010 = now bolusing normal
00000100 = now bolusing square
00001000 = now bolusing dual
00010000 = insulin delivery active
00100000 = temp basal active
01000000 = cgm active
10000000 = ?

----101- = seen during resv change? prime?

----------------------------------------------------------

Last bolus delivered:

[KB] 32bit = last bolus amount (/10000 for decimal value)
[KT] 32bit = last bolus time
[KR] 8bit  = bolus reference (inc each bolus)
[kr] 8bit  = unconfirmed part of reference? seen as zero while monitoring

Now bolusing:

[NB] 32bit = bolusing amount delivered (normal/square/dual check pump status for type) (/10000 for decimal value)
[NM] 16bit = bolusing minutes remaining (user set limit = 480 minutes / 8 hours)
[NR] 8bit  = bolusing = bolus reference, [KR] will contain this ref when complete normal/square
[nr] 8bit  = unconfirmed part of reference? seen as zero while monitoring

<normal> when bolusing finished updates: [KB] with full bolus amount [KT] time normal bolusing started 
<square> when square bolusing finished updates: [KB] with square bolus amount [KT] time square bolusing started
<dual>   when normal bolusing finished updates: [KB] with normal bolus amount [KT] time normal bolusing started [KR] = [NR]
         when square bolusing finished updates: [KB] with square bolus amount [KT] time square bolusing started [KR] = [NR] (same ref used for both parts)

if an additional normal bolus is done while a square is being delivered [KB] [KT] [KR] will show this bolus and change again to square when that finishes.

if pump battery is changed mid dual/square delivery user is asked to resume/cancel - if resumed [KT] will contain this resume time when square bolus completes

----------------------------------------------------------

[Pogman]

@ondrej1024 history handling is a complicated beast. Get Android Studio and pull the repo and it should be easier to follow the code for this. Be worth using an emulator to see it live in action and follow the logger for some insight.

[mortlind]

@ondrej1024 I do not think so. My experience is that BR always give the current value from the programmed basal. TB gives the temporary. And these are irrespective of whether in auto modus, auto basal, or safe basal. Hence, those values are not reliable as "actual" basal. Regarding basal in auto modus, in my software I idenfify these as boluses where the "programmed" value i None; this is in the library proper, not in the uploader. Hmm, forget this, I am referring to the wrong software here ...

[ondrej1024]

My experience is that BR always give the current value from the programmed basal. TB gives the temporary. And these are irrespective of whether in auto modus, auto basal, or safe basal.

I think we are saying the same thing.

Regarding basal in auto modus, in my software I idenfify these as boluses where the "programmed" value i None

Which pump message contains this data and how can it be requested? Can you share your code or just the interesting snippet?

[mortlind]

@ondrej1024

Which pump message contains this data and how can it be requested? Can you share your code or just the interesting snippet?

I assume you use https://github.com/pazaan/decoding-contour-next-link. When I get the pump events, I select out the NormalBolusDeliveredEvents and distinguis manual from auto boluses on the property programmedEvent. If it is None it seems to be an auto bolus, and if it has a value, it seems to correspond to a manual bolus entered judging by the value in programmedAmount. (It all seems a bit of ad hoc design, perhaps it is a quick-fix from Medtronic?)

[ondrej1024]

OK, found it. Need to have a closer look. Thanks.