I have not had any luck.
Phooey!! But not unexpected, I reckon.
At one point, the Dex CEO had said that the App that will run on the Apple Series 3 Watch and support direct communications to the Dexcom G5 transmitter (without requiring the Apple iPhone as a bridge as is currently required) would be submitted to the FDA for review.
Always the kicker.
Did you ever wonder why the G5 transmitter sends out both raw and calibrated Bg numbers?
The official Dexcom receivers ( iPhone, selected Androidās and stock receiver) make no use of the raw dataāthey all use the data calibrated by the transmitter.
Perhaps Dexcom was trying to offer something to the DIY community under the FDA radar.
@docslotnick - I was not sure if it was positively confirmed that the Dex G5 sends calibrated numbers? Looking through part of the chat link you had previously posted, I did not see that confirmed.
The xdrip uses the raw so that is a fact not subject to debate - correct?
If I was developing the G5, I certainly would not send out data which was not required. Extra code - no point. Every single extra byte over time probably eats into the battery so why bother?
Did you see something which gives confirmation or a completely packet dump that shows both raw and actual BG?
It would be interesting to see what the packet dump looks like when the Smart App requests a 3-hr backfill and the response of such.
@Thomas Iām just going by what Sayer said and what Jamorham, the xDrip+ developer said.
Sayer said that the G5 is a āsmartā transmitter that processes the raw data onboard.
Jamorham says it was a conscious decision to use the raw data from the transmitter and not the calibrated data.
I donāt see how there could be any other way for both of these statements to be true unless the transmitter sent out both raw and calibrated data.
Not to be a total PITA but they could be mistaken? (Yes - I am publicly doubting the Dex CEOās technical ability. lol. I am glad he has top notch engineers working for him.)
Being able to see a packet dump would certainly be illuminating.
There is just too much that doesnāt make sense such that it is difficult to believe anything without additional proof.
Also, the time limit on the official Dexcom transmitter/ receiver is only 105 days. With xDrip+ itās almost double that.
It would be interesting if we could determine how long the official transmitter/receiver combo would last, but nobody has broken the software brake.
The reason xDrip+ lasts that long is because it is only one way communication between the transmitter and receiver. No battery power is wasted picking up calibrations from the receiver.
A packet dump readout would be most illuminating. Iāll try to ask Jamorham if heās ever seen one ( I canāt imagine that he hasnāt).
As well, it is only one device being communicated with. Due to xdrip not playing nice with other devices in the loop.
If you get the chance at some point, it would be very interesting to see how long you could get xdrip working against a used G5 that has run past its 112 day software imposed limitation as well as which was used during that period against both a receiver (Dex Receiver or Pump acting as receiver) as well as a Dex Smartphone App.
How many days in addition to that would the xdrip be able to get? Probably not so easy to pick up one of those transmitters however.
More simultaneous devices communicating with the G5 transmitter should certainly chew up the physical battery faster. But it would be great to be able to demonstrate that (in some fashion) instead of only hypothesizing about it.
Are you looking for G5 transmitters? I have some. If anyone wants them let me know.
One point is that the Dex has been the sensor of choice for almost all AP projects, and it is perfectly reasonable to think that they might wish to use their own glucose-evaluating algorithms rather than the FDA-approved Dexcom 505 algorithm. Among other things, this could enable them to detect changes in BG sooner, because the 505 algorithm introduces some delay in order to filter out jitter in the raw data (but less so than the earlier algorithm on the G4.)
I never imagined that writing a few bytes of actual data into a frame before transmission could be significantly more expensive than nulling the space or even leaving it filled with trash. I would have guessed that the power budget largely went into radio transmission, not into writing a few bytes into the buffer.
Isnāt it interesting how, presented with limited facts and observations, we can speculate such widely differing explanations? Iām amused.
That is coming from the perspective of the 3rd part developer such as the xdrip developer. This still doesnāt explain to me why the Dexcom developer would want to include non-essential data in a transmission.
The transmitter only sends out one BLE burst every five minutes, regardless of how many devices compete for it. I donāt know that itās not the fact that Dexcom devices use the calibrated portion of the burst ( or if itās a separate burst) and xDrip+ uses the raw portion that causes only a single device to be used.
XDrip+ sends no information to the transmitter, and receives no calibrated data from the transmitter.
The lower power consumption of the transmitter with xDrip+ would most likely be that it doesnāt receive or process any data from xDrip+, not that itās only connected to one device.
The G5 definitely supports 2-way communication. The G4 (AFAIK) was only 1-way. xdrip may only go 1-way but the Dex Receiver and the Dex App are 2-way against the receiver.
In addition, in terms of the max 3 hr backfill, it would not make sense for that data to be continuously transmitted. Rather, I would be shocked if it was not transmitted upon demand from a compatible device requesting it.
Dex Tech Support (which of course could be incorrect) did specifically tell me that the G5 will incur larger power drain with multiple devices connected to it.
I appreciate your speculation. Also, your skepticism.
I feel like while I am very interested in the Apple Watch/Dexcom/OmniPod/tech options that are out there, I donāt think Iām smart enough to dive in on this type of thing on my own.
That is what makes this community so awesome. We have different strengths!
Bear in mind that if you want āplug-n-playā, that Dexcom does have an official solution available now to go to the Apple Watch. It just needs to route through the iPhone first. But it works and is all Dexcom supported software that does not require any special knowledge.
Thatās a great point. I liked the idea of the watch-as-phone for a number of reasons.
But, if we got a G5 and an Apple Watch it would work. (Have a G4 and iPhone).
Interestingly we canāt reliably get Share to work (resetting daily or multiple times a day) and we canāt get Clarity to work either (a cable issue weāve yet to resolve). Probably another reason I feel like Iām not up for it. (Or at least presently unwilling to take on another pile of projects.)
Not sure it is a cable issue. Dexcom has sent me many replacement cables to try to fix the problem I have of connecting the receiver. Never fixed it.
Do you need some cables?