StephenBlackWasAlreadyTaken
commented
8 years ago Hey
Re: share Bluetooth protocol, yes unfortunately the only way to get data from the share receiver was to get a full database page, the heartbeat isn't used but I set it up to mirror how the iPhone app seemed to be doing things.
Re: the share protocol, yeah I have an uber tooth and a Nordic sniffer I used to keep track of what was going on. After enough poking around and reading up on some of the Nordic sdk docs it was apparent it was using the Nordic pipes api and just making slightly modified versions of the USB requests (two bytes to note the total request length and the sequence number of this part of the request are added at the front and then the other 18 would be exactly like the USB requests.)
I opted for rx Java because making something that android expects to be used async into something where sequence was everything was a bit tricky and I prefer callbacks over a message bus, but to each their own!
Are you getting poor battery life? I have never noticed any appreciable change but I also don't actually use a share receiver
On Sun, Oct 25, 2015, 12:00 PM Andrew Dodd notifications@github.com wrote:
I have noticed when running xDrip on an Xperia Z3 that there is an excessive amout of BTLowPower (Sony stock firmwares) or bluesleep (AOSP-derivative firmwares) kernel wakelocks reducing device deep-sleep percentages significantly.
I enabled the Bluetooth HCI Snoop Log (Settings->Developer Options) and then paired my Dexcom Share receiver, let it collect data for 30-40 minutes and then loaded the results in Wireshark. (Note: A lot of data will be missing/uninterpreted in the snoop log if you do not reboot the device after turning it on, and also Wireshark won't parse some data if you don't monitor the pairing sequence.)
It appears that xDrip is fully resyncing the entire device database every 5 minutes? There's a LOT of data being transferred for just one reading. Also, is the heartbeat necessary/can this be disabled?
How was the protocol for Share2 reverse engineered? It appears from what I can figure out in the xDrip source code there's a lot of commonality between the Share2 protocol and the Dexcom receiver's USB protocol? Is there any readable documentation on what is known about the Share2 protocol anywhere? The use of the rxjava library makes attemptRead() at https://github.com/StephenBlackWasAlreadyTaken/xDrip-Experimental/blob/master/app/src/main/java/com/eveningoutpost/dexdrip/Services/DexShareCollectionService.java#L260 almost impossible to follow ( http://reactivex.io/RxJava/javadoc/rx/functions/Action1.html is completely and totally uninformative... ) - it looks like it's receiving data in this subroutine but what commands the receiver to send it?
Was Share2 REd by assuming commonality with the USB protocol, or did someone use a Bluetooth sniffing setup such as the Ubertooth One ( https://github.com/greatscottgadgets/ubertooth ) and crackle ( https://lacklustre.net/projects/crackle/ )?
— Reply to this email directly or view it on GitHub https://github.com/StephenBlackWasAlreadyTaken/xDrip-Experimental/issues/169 .
Entropy512
mgranberry
I have noticed when running xDrip on an Xperia Z3 that there is an excessive amout of BTLowPower (Sony stock firmwares) or bluesleep (AOSP-derivative firmwares) kernel wakelocks reducing device deep-sleep percentages significantly.
I enabled the Bluetooth HCI Snoop Log (Settings->Developer Options) and then paired my Dexcom Share receiver, let it collect data for 30-40 minutes and then loaded the results in Wireshark. (Note: A lot of data will be missing/uninterpreted in the snoop log if you do not reboot the device after turning it on, and also Wireshark won't parse some data if you don't monitor the pairing sequence.)
It appears that xDrip is fully resyncing the entire device database every 5 minutes? There's a LOT of data being transferred for just one reading. Also, is the heartbeat necessary/can this be disabled?
How was the protocol for Share2 reverse engineered? It appears from what I can figure out in the xDrip source code there's a lot of commonality between the Share2 protocol and the Dexcom receiver's USB protocol? Is there any readable documentation on what is known about the Share2 protocol anywhere? The use of the rxjava library makes attemptRead() at https://github.com/StephenBlackWasAlreadyTaken/xDrip-Experimental/blob/master/app/src/main/java/com/eveningoutpost/dexdrip/Services/DexShareCollectionService.java#L260 almost impossible to follow ( http://reactivex.io/RxJava/javadoc/rx/functions/Action1.html is completely and totally uninformative... ) - it looks like it's receiving data in this subroutine but what commands the receiver to send it?
Was Share2 REd by assuming commonality with the USB protocol, or did someone use a Bluetooth sniffing setup such as the Ubertooth One ( https://github.com/greatscottgadgets/ubertooth ) and crackle ( https://lacklustre.net/projects/crackle/ )?
Edit: Is there an IRC channel somewhere that the xDrip developers use to communicate/coordinate? #xdrip and #nightscout on Freenode are 100% empty, so obviously not there. :)