Hello – Does anyone know if it’s possible to have the dexcom app running at the same time on an iPhone as the Spike app? And, if it’s possible, would they show different BGs or would they be the same.
Finally, a related question, does Spike have the same 2 hour warm-up as the Dexcom app?
I just got a G6 but haven’t started using it yet.
Thanks in advance to those who have knowledge!
Spike only needs 10 minutes for the warm up, however I tend to calibrate a few hours after I do the 10 minute warm up calibration.
They can’t run on the phone at the same time.
1 Like
Receiver and a smartphone; that’s OK. Not two apps on the same phone, as Hammer said.
IE, you can run Dexcom software on a compatible phone and receiver. OR you can run Dexcom on a receiver, and xdrip, etc, on a smartdevice, simultaneously.
That’s great info. Thank you. I think I’ll try using the receiver and phone at the same time. I’ll report back if the numbers are different.
I don’t like the Dexcom app, so I use xDrip on my Samsung S7. I have a widget on my main homescreen, which I think is an awesome feature. ALSO, I have xdrip send data to my smartwatch, a Gear 2, without the need for an app. Unfortunately the makers of xDrip have failed to keep that feature (sending data via Android Notifications) functional following updates of the app after the 7/15/18 version.
I just tried this on a Samsung Galaxy7Edge (which doesn’t run the Dexcom software for some reason), but xDrip seems to have a similar problem. I have a running sensor connected to the DexCOM receiver, this is a Dexcom6. When I entered the transmitter serial number into xDrip it seemed to pick it up - it said it had bg readings, but then it wanted me to calibrate it and was apparently trying to start it, same as the problem with the Dexcom software on the same phone. I guess it isn’t compatible with the Samsung model I have.
there is a “patched” version of the Dexcom app on the net. I forget what it’s located. it allows it to work on phones that aren’t officially supported, but geeze, a 7 edge should work. I have an S7. I don’t have a G6 though–a G5.
Try the 7/15/18 version of xdrip. The Data Source for xdrip is G5/G6 Transmitter. It doesn’t differentiate.
USE THE OB1 Collector; NOT THE NATIVE one.
allow OB1 unbonding
Force G5 to UI thread
Authenticate G5
I, or rather my wife, has the dual SIM version (SM-G935FD) in rose gold but the listing here:
Only says “Samsung Galaxy S7 Edge (Android 7.0.0)”; that covers rather a lot of different devices (multi vs mono SIM, multiple memory options, multiple colors). However I suspect that the real problem is “Android 7.0.0” because we don’t block updates and it is actually running Android 8.0.0
I’m going to get a new phone but I don’t want a Samsung - there’s way too much bloatware and the OS is always out of date, so I want to get a Google Pixel 2 but I’m waiting for the prices to drop a bit more.
The Pixel has much better Dexcom support - Dexcom lists both 8.0.0 and 8.1.0 whereas Samsung modules are only supported with what is apparently the original OS version!
I might try just activating the new sensor (tomorrow) using xDrip.
Guess what, it started working! It’s weird because I did the double finger-stick calibration and it said it was sending the data to the transmitter, so apparently both xDrip and the Dexcom receiver are calibrating it. I would imagine that might be a problem.
I checked the xDrip settings; I have the Sep 18 stable release.
Hardware data source: G5/G6
Use OB1 Collector: checked
Native algorithm: checked
G6 Support: checked
Allow OB1 unbonding: checked
Force G5 to UI Thread: NOT CHECKED
Authenticate blah blah: checked
So as you say except the data collector (I assume) is running in a background thread. Since I normally do a “close all” on the phone I think I probably need that; I believe “close all” closes all the UI threads (though it is Android, so it’s obscure.)
Under “System Status” (Classic Status Page), G5/G6 Status:
OB1 G5/G6 Collector and Transmitter Status
Buggy Samsung: Using workaround
So it looks like the xDrip+ guys found a Samsung problem.
CLOSE ALL will NOT mess with xdrip. Make sure in Settings, you have xDrip set to NOT have battery optimization!!
Calibrations are SEPARATE between Dexcom and xDrip apps!!
Make sure to have “G6 Support” enabled, in the debug settings
Which version are u using? I only trust the 7/15 version.
get it from this page: Releases · NightscoutFoundation/xDrip · GitHub
Look for the one labelled 2018.07.15
Finding stuff in settings is really difficult… That’s one of the problems caused by Samsung’s skins but the xDrip settings UI needs a rewrite; “Other misc options”! Anyway, it prompted me to disable the optimization and I just turned “Battery Optimization prompt” back on in xDrip/settings/other misc options. The Samsung does not seem to have “battery optimization” as an app setting; I’ve noticed this with other things, they seem to add/remove/move round stuff in their UI with every release.
I’m using “stable”. I can’t find the version info anywhere in the app, but Samsung/settings reports it as d1d4887-2018.09.08; dad4887 is the version (from git).
To answer Tnyc’s original question; if it were possible they would show the same BG but they would not show the same readings. Both xDrip and the Dexcom receiver (and, I assume, the app) show the same number, but the ‘dots’ on the Dexcom receiver seem to be a moving average. The readings on xDrip show significant spikes which are, I believe, a result of environmental changes (showering, going outside etc.) Here are pictures of the two:
The ‘high’ division is set to 180mg/dl, I zoomed xDrip to about the same time range as the default (unzoomed) Dexcom receiver range. You can see that the readings from 2pm to 3pm were all over the place; that’s our weekly food shop. 1pm to 2pm we were driving to the shops, 2pm to 3pm moving around shopping, 3pm to 4pm driving back.
John Bowler
On calibration: it did originally surprise me that xDrip would send calibration information to the transmitter, but when I started to think about it it makes sense. That way in the scenario being discussed (multiple controlling apps) it doesn’t matter where the calibration happens and it really shouldn’t because the calibration normally comes from the same finger-stick meter regardless of what receiver/app/UI device is used to enter it.
In my case I conducted a rapid test while waiting for a prescription refill at Walgreens; I used the Dexcom receiver to enter a new calibration. If the calibration was done on the device then that would have resulted in xDrip and DexCOM being different until the devices were synced to each other. However these devices are never synced: See the pictures above; the calibration happened around 14:00 but xDrip doesn’t have a calibration mark because it doesn’t sync to the receiver. I haven’t even told it the receiver id, and I don’t think I can.
As you can see, however, xSync has the same current reading, exactly, as the DexCOM receiver. This isn’t a one-off fluke - they are consistently identical - so (Occam’s Razor) they are showing the number from the Dexcom transmitter and therefore the transmitter is doing the calibration.
At first that struck me as a crazy choice on Dexcom’s part, but I started doing this kind of stuff in 1978 and back then software was simply not possible on devices the size of the transmitter. These days they run bluetooth stacks and the complexity of the software required to do that dwarfs the very basic algorithm that I think Dexcom are using for calibration. Certainly my pool chemical meter uses a way more complex calibration.
The version number is on the System Status screen (Classic Status Page), right next to the text,“Version:” I don’t like ANY “stable” version of xDrip. Why you might ask? Because one stable version doesn’t have some features that I use, and the next one has broken xdrip on my smartwatch. So I continue to use, and encourage others to use the 7/15 version.
The version number is on the System Status screen (Classic Status Page),
right next to the text,“Version:”
The first seven characters are what counts - d1d4887 in my case, the rest is a date which is actually less precise. It’s important to quote the seven digit number in bug reports (‘issues’ on github) because it uniquely identifies the computer code used.
My upgrade options (Settings/xDrip+ Update Settings/Update Channel) are actually set to Beta, but there aren’t any after the 9/18 release (above).
Yes, I know, people stick with versions they know and love; this is important. If it works don’t fix it. I’m a hack, I develop on gentoo, but I don’t use Windows Insider editions. I haven’t found the version of xDrip+ that is perfect yet but probably, unless I doing dev on it, I will and I will stick too.
John Bowler
Thank you so much, Mr Bowler. Those screen shots are really interesting. The dots on the xDrip screen seem to show a lot of noise. Do you find that having that raw data (rather than Dexcom’s running average) is useful? I would be worried that, in my case, I’d see a high or low dot and become alarmed. Do those dots tell you things that are helpful to know?