Lipo Fuel Gauge

Question

Lipo Fuel Gauge

Opened this issue 9 years ago · 5 comments

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

Answer 1 · 2016-01-07T22:47:25.000Z

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:

Sufficient RAM to store X packets with a ms timestamp since it was
captured.
Algorithm to update each of the stored packet's time_since_capture value
before send attempts and after sleep cycles.
New algorithm in (xBridge3) to send packets with time_since_capture.
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
#13.

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

Answer 2 · 2016-01-07T23:18:13.000Z

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

Answer 3 · 2016-01-08T00:07:03.000Z

It is very hard to get an idea of a missed reading in xDrip. There really
are two reasons.

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.
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
#13 (comment)
.

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

Answer 4 · 2016-06-05T13:50:28.000Z

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

Answer 5 · 2016-06-05T23:12:15.000Z

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
#13 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AIQs808nc1Ha8V3MTYrkCoaJBHlpMWs4ks5qItQlgaJpZM4HAwPd
.

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