search

jstevensog / wixel-sdk

Adrien de Croy's wixel-sdk for building dexterity-wixel and xBridge apps
Other
31 stars 93 forks source link

Lipo Fuel Gauge #13

Open mzst123 opened 8 years ago

mzst123 commented 8 years ago

Hi John, Would something like this be possible to add to the board? https://www.sparkfun.com/products/10617

I think the MAX17043 IC would make the battery level indicator quite accurate, however I have no idea if it is easy to implement on the software side.

Also I was wondering, if the xbridge captures a Dexcom packet, but is unable to send it via Bluetooth because the phone is out of range, will it save the reading for later and continue capturing, until Bluetooth connection is re-established, and then send all of the missed values? Or does it only send the last one? I couldn't tell from the documentation.

Thanks and Regards

jstevensog commented 8 years ago

Hi mzst123, It is certainly possible to add this to the bridge rig, as the wixel talks I2C. I will look into it, but it won't be something that will happen quickly as I am quite time poor at the moment. The main issue will be if there is enough RAM and program resources on the wixel to accommodate it. Things are currently pretty tight. The other issue is keeping soldering to a minimum for those inexperienced constructors to still easily build their bridges, something which has been raised with me when I have suggested adding more hardware to the bridge.

On the packet capture, xBridge2 only captures one Dexcom packet and sends it to the phone. It does not store packets that it cannot send. If the phone does not respond with an ACK (either no BT connection or Android having an issue) in two minutes from packet capture, the packet is discarded and the wixel goes to sleep. This is analogous to what would happen if the Dexcom receiver goes out of range of the Dexcom transmitter.

To do packet storage during "phone outage" has the following requirements: 1) Sufficient RAM to store X packets with a ms timestamp since it was captured. 2) Algorithm to update each of the stored packet's time_since_capture value before send attempts and after sleep cycles. 3) New algorithm in (xBridge3) to send packets with time_since_capture. 4) Modification of xDrip to deal with time_since_capture, and only act on a packet (raise high/low alerts etc) IF it is the most current (ie, less than 2 minutes since capture).

In short, 1 may preclude this if we want to store more than say 3 packets at most, and there is significant programming for both xBridge and xDrip to get it done. I am less concerned with xDrip, but more concerned that we are running out of program space on the wixel.

While I like the idea, I always come back to this. If we didn't have xBridge/xDrip, and we left our receiver behind somewhere and lost a few packets, would it really be a concern? In my opinion, we wouldn't really need to worry what the trend was during the "outage". It would be nice to have, but not essential. Yes, trends over days/weeks/months of of interest, but if we have a gap of 10-20 minutes, it doesn't really impact our treatment decisions. If the sensor is "clean", the mind can generally fill in the blanks as long as they are a few samples in size. 2-3 hour gaps, yes it would be good to backfill. But I believe in those cases we will hit the limits of the device we are using.

I am also looking at a new hardware platform that may replace the wixel and HM-1x boards in one hit. So, if that works out, I will likely look at implementing packet storage in that bridge version, IF there is sufficient RAM and program resources to allow it.

Cheers

On Fri, Jan 8, 2016 at 9:13 AM, mzst123 notifications@github.com wrote:

Hi John, Would something like this be possible to add to the board? https://wwwsparkfuncom/products/10617

I think the MAX17043 IC would make the battery level indicator quite accurate, however I have no idea if it is easy to implement on the software side

Also I was wondering, if the xbridge captures a Dexcom packet, but is unable to send it via Bluetooth because the phone is out of range, will it save the reading for later and continue capturing, until Bluetooth connection is re-established, and then send all of the missed values? Or does it only send the last one? I couldn't tell from the documentation

Thanks and Regards

— Reply to this email directly or view it on GitHub https://github.com/jstevensog/wixel-sdk/issues/13.

John Stevens "You are how you live, not what you have."

mzst123 commented 8 years ago

Thanks for the quick reply. True, the soldering is an issue. I created a board in eagle but was concerned about that too ( https://oshpark.com/shared_projects/XrUwQSdh ) And the MAX17043 IC is indeed even more difficult. A new hardware platform would probably be ideal.

About the packets, it really does not make sense in this case, I wasn't aware of the complexity involved in storing the packets. Also, is there any way of knowing the reason of a missed reading? If it was the Bluetooth connection or the Wixel itself that did not capture it properly? I am asking because with the last sensor I used, the connection was terrible, I was loosing readings all the time randomly, but never figured out if it was the wixel or the Bluetooth. The only difference between this and the sensor before (which too wasn't that great btw) was the location which I changed from the abdomen to the upper arm. Cheers

jstevensog commented 8 years ago

It is very hard to get an idea of a missed reading in xDrip. There really are two reasons. 1) Bridge doesn't get the packet. The wixel is not precisely tuned to the Dexcon transmitter channel frequencies, but certainly close enough to reliably get them. And as it operates in the unlicensed 2.4GHz band, there really is no way to make sure interference is not a reason for this. I have done a lot of tuning of the wixel handling of data streams to ensure interference is usually not an issue. The Dexcom transmits on channel 0 every 5 minutes, and on channels 1-3 at consecutive 500ms intervals after this. On initial boot, the bridge will sit and listen until it detects a valid packet on channel 0, so it can accurately determine the timing. Once it does this, it expects a new packet on channel 0 in 5 minutes. It uses this to calculate it's sleep time. So, when it wakes up, it waits on channel 0 until just after the 5 minute mark (or it detects a mal-formed packet on channel 0 within the window), and then goes to the next channel. If it doesn't get one in 500ms, it goes to the next, etc. If it gets to channel 3 without getting a packet, it waits on channel 0 for a packet again to reset it's timing, and in the meantime it sends BEACON packets every 6 minutes in case you have changed the transmitter and the bridge doesn't yet have the new ID. This works very well now the typo in my code was discovered and fixed. Not that it was too bad before, it just meant the sleep time could be out if a packet was captured on channels 1 or 2, and it wouldn't wait quite the full 5 minutes before going on to the next channel, occasionally dropping a packet and waiting for the next "pick up" on channel 0 to re-synchronise. Once a packet is captured, the bridge tries to send a BEACON packet, and then a DATA packet to xDrip for 2 minutes. If it gets an ACK packet in response to the DATA packet, it goes to sleep immediately after calculating when to wake up again. If it doesn't get an ACK in the two minutes, it goes to sleep after calculating when to wake. BTW, I do miss packets overnight still, and this is due to my bridge being inside my crash bag, on the floor beside my bed, so the LEDs don't bother the wife. If I roll away from it (and the transmitter is on my abdomen) my body mass and the bed is enough to block the signal. I also drop packets if my wife's leg is over the top of my bridge in my pocket, as both our body masses prevent the wixel picking it up.

2) xDrip doesn't get the DATA packet. This can happen for (in my experience) a couple of reasons. The first is that some versions of android do not connect to the HM-10 in time. Not much we can do about this, but I have lowered the reconnect attempt time in xDrip to get around this, and it has basically stopped it happening. The second is more sinister. In this case, Android shows the bridge as connected (even if it actually has no connection established), but xDrip never gets notified of a packet arriving. The only way to fix this one is to restart BT on the phone (turn it off and then back on).

So, I will investigate adding a timer and notification to xDrip that would indicate a "bridge packet miss" the connection has been alive for >5 minutes and a BEACON packet is received without a DATA packet at 6 minutes. I don't think I can make the BT cycle if xDrip hasn't received a packet in 15 minutes, but I will look at that also when I get a chance.

I can pretty safely say, now that the typo is fixed, that the most common reason for missing a packet is some sort of problem in the wixel receiving the packet, like physical environment attenuating the Dexcom signal, or some 2.4GHz band interference. More the former than the latter. In 48 hours of running, I have dropped 6 packets, only one of which was unexplained as either physical environment or out of range.

Cheers

On Fri, Jan 8, 2016 at 10:18 AM, mzst123 notifications@github.com wrote:

Thanks for the quick reply. True, the soldering is an issue. I created a board in eagle but was concerned about that too ( https://oshpark.com/shared_projects/XrUwQSdh ) And the MAX17043 IC is indeed even more difficult. A new hardware platform would probably be ideal.

About the packets, it really does not make sense in this case, I wasn't aware of the complexity involved in storing the packets. Also, is there any way of knowing the reason of a missed reading? If it was the Bluetooth connection or the Wixel itself that did not capture it properly? I am asking because with the last sensor I used, the connection was terrible, I was loosing readings all the time randomly, but never figured out if it was the wixel or the Bluetooth. The only difference between this and the sensor before (which too wasn't that great btw) was the location which I changed from the abdomen to the upper arm. Cheers

— Reply to this email directly or view it on GitHub https://github.com/jstevensog/wixel-sdk/issues/13#issuecomment-169838024 .

John Stevens "You are how you live, not what you have."

savek-cc commented 8 years ago

Did you get any new ideas on the hardware you mentioned which could replace the wixel+hm10?

jstevensog commented 8 years ago

Haven't had much time to investigate. Initially I thought and NRF SoC might do it, but I have begun to doubt that they could be programmed to talk the Dexcom Zigbee protocol. NRF use their own protocol. The thing to keep in mind is that Dexcom are using as much of the native CC251x capability as possible. A good idea in many ways. But, I should at least be able to build a single board with the CC251x and some BLE SoC on it, and have it flashable. Time poor at the moment. Focus is on improving packet capture on this project, and some other projects as well. Cheers

On Sun, Jun 5, 2016 at 11:50 PM, Timm Korte notifications@github.com wrote:

Did you get any new ideas on the hardware you mentioned which could replace the wixel+hm10?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/jstevensog/wixel-sdk/issues/13#issuecomment-223814138, or mute the thread https://github.com/notifications/unsubscribe/AIQs808nc1Ha8V3MTYrkCoaJBHlpMWs4ks5qItQlgaJpZM4HAwPd .

John Stevens "You are how you live, not what you have."