What’s the point of the SW if it acts as collector but can’t share the data? Is it just for folks who self manage and don’t desire to share any data?
That’s what I thought, though I see neither the phone nor transmitter on the watch Bluetooth devices. I do see random other devices though (I discovered my wife’s iPhone was enabled when she walked in the room). I tried to unpair devices, but that seems a noop.
Oh wait, I found the “refresh db” on the drop down menu, and after doing that, the dexcom showed up in Bluetooth devices! I just connected to it, then had to wait several minutes for the pairing request, but then was able to get an update direct from the transmitter. So this seems to be working now. Thanks again. I still need to set up the backup of data, though I guess it’s good enough to be on the phone for now.
Yeah, not an issue for me since I’m not going to be sharing. It’s the convenience of having data on my wrist, and not needing to carry around my phone (I don’t carry it when I’m in the house).
@ClaudnDaye Actually, you can put the phone in a locked case, but it still needs to be in Bluetooth range.
And it’s a lot easier to glance at a watch than to take a phone out of your pocket.
Also, there are times when it wouldn’t be practical to have a phone, but a watch is OK. There are really dozens of reasons for the watch, even if the phone is only near by.
I’m trying to enter “treatment” options for insulin and meals to make better sense of my timelines. This is straightforward from the watch using the three dot screen, but is there a way to do it from the phone - I don’t see an equivalent to the three dot menu there? And more important, is there a way to do it for a time other than “now” if you forget to enter it immediately? The three dot menu allows treatment types BG, carb, insulin and time, but I don’t know what the time option is for. If it is to change the time to record the other treatment types then I can’t figure out how it is used.
@jag1 There is a medicine dropper icon on the right side of the home screen that brings up the treatment dialogue.
The hand with the finger pointing is a Bg test, the crossed fork and life is carbs, the syringe is insulin, the clockface is time of treatment if you want to change it. The microphone is to speak the treatment. Make sure you click the green check mark that comes up after you enter treatment.
After you click the green check mark another image comes up to verify your entry. This is especially helpful for “what-ifs”
The time is military time in the xx.xx format.
It’s quite an ingenious setup.
The hours are in military, but the minutes are entered in standard time. Am I doing it incorrect??
@jim26 The time is entered as 24 hour format, i.e. 12:25pm would be 12.25, and 7:06pm would be 19.06.
No you are correct, but honestly if you want to be correct everywhere in the world you should convert yourself to Zulu time. Then you would be very much like a pilot and would never be wrong /s
xDrip+ should be doing the convertion internally since Linux uses that timezone (well, it uses UTC). I have to admit I haven’t tested xDrip+ across a timezone yet, but I don’t see how an Android app could mess it up.
The Dexcom app and receiver, however, do seem to have this problem as does the Omnipod - swapping time zones at least temporarily interrupts operation of the software.
Early versions of the Omnipod UST400 seemed to refuse to do bolus calculations for two hours after a time zone change. That was fixed about the same time as the hardware problem of the backup battery failing was fixed, but all versions still require insulin delivery to be suspended before a time zone change and that means that delayed boluses and temp basals end up being cancelled!
The Omnipod also has the issue I saw with the Dexcom receiver and, indeed, the issue with older Apple and Microsoft operating systems. The Omnipod and, I think, the Dexcom work in local time; I’ve found no way of setting the timezone on the Dexcom (maybe it can be set in the app) and the timezone certainly cannot be set on the Omnipod. This means that a data upload to Dexcom Clarity or Omnipod uploads local time and data overlaps or gaps occur as a result of time zone changes. That’s actually a data loss, which is generally regarded as the most serious of software bugs.
Sorry, I was interrupted so didn’t do my normal review of the second paragraph; the issues with using local time.
In theory the uploader software, which runs on a modern computer, can convert local time from the PDM or CGM into UTC, however this relies on the PDM/CGM (the data logger) having records in the same local time as the computer running the upload software. This should normally be the case but if it isn’t the gaps or overlaps will occur. It also seems that both Dexcom Clarity and Glooko display UTC data in the local time of the computer running the web browser, which would lead to the misleading data I describe below when the original data was logged in a different time zone.
Even if the user (me) remembers the rule of setting the PDM clock to the local time of the computer before an upload there is still an issue of what happens to the stored data in the PDM as a result of a time zone change and I can’t see a practical way of avoiding data loss in this case. This is because the only way of handling the time zone change is to change the time of the existing recorded data; so if you skip forward one hour all the prior data also has to be skipped forward. That means that a bolus you did at 9am yesterday will be uploaded as a bolus at 10am yesterday; the alternative would be a gap of one hour which would be just as bad and more difficult to implement.
The issue is that time of day is very important in analyzing the data; so if I’m getting night time lows and day time highs but I spend a week in Dubai (I live in Oregon, USA) the same pattern is going to be presented as night time highs and day time lows when I get back to Oregon and upload the whole package of data from the trip.
The ONLY way round this is to store UTC+time-zone; zulu time (UTC alone) isn’t enough. Indeed the Omnipod PDM uses time-of-day, which is local by definition, to store basal rate programs so using UTC means changing every basal rate program on a local time change!
I was tempted when I started using the G6 to set the receiver to UTC and I could set the PDM to UTC as well because I use a fixed basal these days, however it was obvious that it didn’t really fix the problem because of the importance of time-of-day to the data.
These days I use xDrip+ for data logging of both the G6 and the insulin delivery; I enter boluses manually but lose the temp basals. xDrip+ automatically changes time zones because the Android phone it runs on does. What I don’t know yet (since I haven’t done a TZ change yet) is whether it stores the time zone information, I suspect not.