Open mwarrenus opened 9 years ago
It would be great but unfortunately you need a cc2511 to work with the ti packetting the dexcom uses (which no phones have). Maybe someone would somehow be able to rewrite all the drivers and knew a whole heck of a lot about ti and all had their several thousand dollar licenses and all the equipment to reburn the smd components on the ble chip on the phone (which I don't think can actually be done) and copy the proprietary ti stuff but I'm pretty sure ti would shut you down real fast :-( also everyone who wanted to use it would need to go through that process which is a lot harder and a lot more expensive, though it would be awesome.
Yep, that's what I discovered looking into this; while Bluetooth chips have more than adequate RF front ends and MCUs, their firmware won't receive transmissions from the Dexcom TI CC2510 (fccid PH29433).
While looking around, I also noticed TI's CC2541 "Mini Development Kit" which seems interesting because the CC2541 works with both the proprietary and BLE radios. If it can duplex between the two protocols (proprietary & BLE), then it might provide a turnkey, solder-free platform for wixel-DexDrip (it comes with a case and battery holder). At $99, it's not that much more expensive than the current hardware.
It would be soooo cool though. Oh well, we will be ready when the g5 comes out! On Jan 15, 2015 7:50 PM, "mwarrenus" notifications@github.com wrote:
Closed #19 https://github.com/StephenBlackWasAlreadyTaken/wixel-DexDrip/issues/19.
— Reply to this email directly or view it on GitHub https://github.com/StephenBlackWasAlreadyTaken/wixel-DexDrip/issues/19#event-219816870 .
Agreed; I can leave this issue open? Maybe someone in the #WeAreNotWaiting community has the necessary skills/access.
Unfortunately the dexcom sensor is set up to communicate at 50kbps. The CC2541 is only compatible with the 2511 at a few datarates (250,500,1000,2000). See my post here: http://e2e.ti.com/support/wireless_connectivity/f/964/t/398035
I was thinking of something similar recently. Could you plug the wixel in via USB to the phone (and power it from the phone). Then no batteries or soldering required. Just run a (modified?) version of the xbridge2 software on the wixel. xDrip would need to talk to the wixel over the USB port rather than BT but would probably be sending similar commands.
You could literally tape the wixel to the back of the phone, which can then run the xDrip app. (Essentially just replace the BT connection with a male-to-male USB cable.) The advantage as I said would be a solder free virtually plug and play solution but it would probably run your phone battery down a bit quicker!
Actually, this is very similar to the dexterity solution https://github.com/StephenBlackWasAlreadyTaken/xDrip/wiki/Wifi-Wixel-Network-Setup but as I understand it that does not have the xDrip interface. I suppose you could run dexterity and NightWidget on the same phone to create a similar effect.
Sorry if that takes a stale post a bit off-topic!
@Cagier I actually have a branch were I started to build in that functionality but I just never finished it up, one day I will get back to it!
Following, and hopefully doing it, back to wixel plus OTG phone/smartwatch
Does the Wixel connect via OTG? i.e. can I remove the bluetooth module altogether if I have the Wixel connected via USB?
If the wixel-DexDrip packet receiver ran natively on the Android phone's own bluetooth receiver, then the Wixel hardware could be eliminated and DexDrip would be available to a much broader audience. Would this need to be done in Android/Linux bluetooth driver land?