Voltage mensurement not showing on Nightscout

[9A6DQB]

I did modification that was discribed, and can not find data for battery. I do have data for uploading mobile, bit not for xDrip instalation.
Should I make some modifications in Azure, or what am I missing.
Thanks

[Cagier]

The xDrip battery status (as opposed to the uploader phone battery status) will currently only appear with the xBridge software (from the Wixel-SDK - xBridge3 is the latest version). You need to install that on the wixel in the same way as you did the wixel-xdrip app. Then when you select the xbridge as the device on your uploader phone you will see the current battery display on the xDrip application's screen. I don't think it appears on the Nightscout screen (yet) or at least I haven't got that bit working yet if it does!

However, you should always see the uploader phone battery status in Nightscout without performing any hardware mods. I'm pretty sure that this is enabled by default (but can be disabled with the "upbat" parameter in the DISABLE variable in Azure.

A future version of the wixel-xdrip software will probably have the battery display also but I don't think it is available yet.

I hope that makes sense and is correct! Mine is working. Make sure you check what your resistor values are and read the comments in the code but if you use the "standard" values then you should not have to make any program changes before compiling.

Good luck!

[9A6DQB]

Thanks a lot.
I manage to get indication on xDrip app on my phone, but...
It says 100% battery, and this battery is in use few days now.

I will try to see in code, but I am not shure that I am capable to do it! :)

[Cagier]

OK, I'm glad that you made some progress anyway. The code is very clearly commented as to where you would change the values. If you get stuck and you know what your resistor values are then let me know and I will calculate the values for you and tell you what lines to change.

I am in the same boat with 100% showing all the time but I think that is because I used different resistors (to try to reduce battery drain) and then I was also supplied with an incorrect resistor for one of them. I keep meaning to recheck the values and calculate the revised parameters myself. I just didn't do that when I initially put the xBridge app on as I just moved over recently and only put the app on to check if the circuit appeared to be working and to get the rawBG values sent to Nightscout. Hopefully I will get to this tonight. ;)

Let us know how you get on anyway...

[9A6DQB]

I found somewhat a done file that I put in Wixel. I can not find xBridge3 so I can not change any values.
I got compiled file for Wixel.

[Cagier]

I think you are saying that you find a pre-compiled version of the xBridge(3) app and put it on your wixel. If you want to give me your resistor values I can compile a version for you and send it to you (if your resistors are not the "standard" ones). Also, if you have not compiled it yourself then you cannot be sure what source/resistor values were used to create the .wxl file (although presumably it was the defaults).

Please specify if you want me to hard-code the serial number of your transmitter (recommended) or if you want it "promiscuous" and to pick up every transmitter (not recommended). The second option means that you will not have to recompile when you get a new transmitter after a year...

Finally, I suppose if we are both always getting 100% at the moment then there is a chance that the circuits are somehow incorrect. I don't know what happens if you don't connect them up properly - maybe it gives 100% rather than 0%? I'm not sure. It is hard to check the resistance/connections afterwards as the values may change due to the potential paths through the wixel. I might try loading the xBridge onto another wixel that has no resistors and see if that gives 100% also...

[9A6DQB]

Thanks for help.

Please DO NOT hardcode ID.
My resistors are: 2.16k and 0.99k.

I will try in the afternoon to put xbridge to xDrip that hav no modifications, to see what will heppend.

[9A6DQB]

I just checked in xDrip w/o modification.
It can not tell any number. It said that it is waiting for data..indefinetly.

[Cagier]

OK, that's interesting so hopefully that means that the circuit is working and detected in your modified xDrip.

So, I now have a modified version of xbridge2.c and xbridge2.wxl for you. I have also created ones for myself with the correct values for my resistors but I haven't got time to take the box apart and reprogram the wixel at the moment. Hopefully it will work though so let me know how you get on!

Anyway, I've put your version of the files into a zip archive and attached it here.

xBridge2 for 9A6DBQ.zip

Apologies Stephen as this has now kinda turned into a wixel-sdk / xbridge2 issue and I am placing files from another github project into your repository which is probably poor form. However, hopefully it will close this issue for you!

[9A6DQB]

Unfortunatly still the same. 
I do have all the time 100% battery indication, and last night xDrip drained out battery without indicating less then 100%. 
xDrip001.zip

[Cagier]

Yeah, looks familiar. 😬

OK, I think that the cause of this could be xbridge code, xDrip code or xdrip hardware. I think the original issue that nothing was appearing at all and that you were expecting to see that in NightScout has been addressed. However it obviously is still not working as you had hoped.

Apologies, but I may have misled you somewhat as the output from wixel-xDrip takes the following format:
RAWREADING TRANSMITTERBATTERY WIXELBATTERY
However, I have not seen the xDrip android pick this up from the wixel. The standard circuit uses a 1K Ohm and 2.2K Ohm resistor which pretty much matches what you have so you should be OK there.

xBridge2 has the advantage of allowing you to change the resistor values and also is the version that I managed to get a battery value displayed with. But it may be that if the xDrip / wDrip-Wixel is set up correctly then this will also trigger the display.

It seems that there was a recent enhancement to the xDrip app which refers to the fact that those not using a voltage divider circuit will always get "0% - Waiting for Packet in red" and those powering the bridge from a phone will always be 100%. Again, I'm not sure if 100% means that the circuit is detected or working and if this works with xDrip as well as xbridge2.

I think that the easiest thing to do at this stage might be to put the wixel-xDrip app back on your device and then hook it up to a console program with a USB cable. Putty should work but for some reason I had issues with putty and the wixel (although I use it for plenty of other things) so I used another free/share option that I can't remember the name of but you may have one or can google that.

Anyway, basically, that will show you the output from the wixel and you will see what battery level it is reporting. That might be the best way to troubleshoot the problem.

When connected to USB it will probably give you the above info but if you change the line in the beginning that says

'static volatile BIT allow_alternate_usb_protocol = 0'

to

'static volatile BIT allow_alternate_usb_protocol = 1'

then it will give you additional info. Either way, the xDrip battery is still the last field.

Also, @jstevensog is good with this stuff and may be able to help steer us in the right direction. 😉

Sorry if I am pulling you in different directions here but hopefully we will get to a solution in the end!

[jstevensog]

Hi All,
I have missed the conversation, so don't really know what it is about.
Seems git has sent this to me because of the mention.

First, I would like to clear some things up about xBridge.
While you can indeed change the resistor values for measuring the battery,
those selected in the xBridge circuit are optimal for two things. They
cause the minimal battery drain, while still allowing the CC2511 ADC to
operate. Higher than this, the CC2511 cannot accurately read the voltage.
Lower than this and you start to flatten the battery faster than you would
like.

Second, xBridge will run happily on the original wixel-xDrip circuit,
dynamically configuring itself to do so. You just select it as the Data
Source in xDrip and all is fine.

The ability to show the bridge battery in xDrip only applies to the xBridge
data source, not wixel-xDrip. I actually haven't seen support for the
wixel-xDrip battery in the code of xDrip,

The "100% if connected external / 0% if no resistors" applies totally to
xBridge only and is not a new feature, it has always been there for the
xBridge data source. In the latest xDrip Beta, displaying the bridge
battery is an option you can turn on or off as those using other power up
methods for the bridge didn't want to see it.

The biggest limiting factor of wixel-xDrip is that it's "protocol" is
character based text. xBridge uses a binary byte packed protocol. Why is
this an issue? Two things.
a) BLE is limited to the number of chafacters/bytes it can send.
wixel-xDrip is at the limit of this, and no more can really be added
successfully. So we cannot for instance add any further information that
is captured.
b) The transmission time is much lower for a byte packed protocol, and
therefore saves power.

So, my question becomes this. Why try to modify wixel-xDrip to give you
what you can already have with xBridge2? Given you can dump xBridge2 onto
your wixel-xDrip circuit and have it work, what is the need to modify
wixel-xDrip? And if you want the full features xBridge2 offers, why not
just modify your wixel-xDrip circuit to suit?

I would be more than happy for others to contribute to xBridge and improve
it, so long as the existing functionality is not broken. I have already
had several bugs identified and fixed by others which is fantastic. And I
am more than happy to work on adding/changing things to suit what you
need. Currently I am making a version for the OpenAPS people.

The wixel-xDrip was a "first cut" bridge. xBridge2 was a much more
engineered solution, which others have also modified to suit their needs as
the protocol is robust and well documented. A lot of it's features have
already been rolled back into wixel-xDrip. And both came from the original
dexterity-wixel code of Adrien de Croy.

If you want bridge battery in NS, use xBridge. If you want the ability to
set the Dex Transmitter ID from xDrip rather than altering code and
comiling, use xBridge. If you want the power saving features of xBridge
use it. If not, use wixel-xDrip. If you find an issue with using xBridge,
let us know so we can fix it, or at least provide a work around. xBridge
is NOT the perfect bridge solution for all and will also evolve while
Dexcom G4 transmitters are available and the G5 locks us out of
raw/filtered data we get from them.

Cheers

On Fri, Jan 22, 2016 at 10:50 PM, Keith Garland notifications@github.com
wrote:

Yeah, looks familiar. [image: 😬]

OK, I think that the cause of this could be xbridge code, xDrip code or
xdrip hardware. I think the original issue that nothing was appearing at
all and that you were expecting to see that in NightScout has been
addressed. However it obviously is still not working as you had hoped.

Apologies, but I may have misled you somewhat as the output from
wixel-xDrip takes the following format:
RAWREADING TRANSMITTERBATTERY WIXELBATTERY
However, I have not seen the xDrip android pick this up from the wixel.
The standard circuit uses a 1K Ohm and 2.2K Ohm resistor which pretty much
matches what you have so you should be OK there.

xBridge2 has the advantage of allowing you to change the resistor values
and also is the version that I managed to get a battery value displayed
with. But it may be that if the xDrip is set up correctly then this will
also trigger the display.

It seems that there was a recent enhancement to the xDrip app which refers
to the fact that those not using a voltage divider circuit will always get
"0% - Waiting for Packet in red" and those powering the bridge from a phone
will always be 100%. Again, I'm not sure if 100% means that the circuit is
detected or working and if this works with xDrip as well as xbridge2.

I think that the easiest thing to do at this stage might be to put the
wixel-xDrip app back on your device and then hook it up to a console
program with a USB cable. Putty should work but for some reason I had
issues with putty and the wixel (although I use it for plenty of other
things) so I used another free/share option that I can't remember the name
of but you may have one or can google that.

Anyway, basically, that will show you the output from the wixel and you
will see what battery level it is reporting. That might be the best way to
troubleshoot the problem.

When connected to USB it will probably give you the above info but if you
change the line in the beginning that says

'''static volatile BIT allow_alternate_usb_protocol = 0'''

to

'''static volatile BIT allow_alternate_usb_protocol = 1'''

then it will give you additional info. Either way, the xDrip battery is
still the last field.

Also, @jstevensog https://github.com/jstevensog is good with this stuff
and may be able to help steer us in the right direction. [image: 😉]

Sorry if I am pulling you in different directions here but hopefully we
will get to a solution in the end!

—
Reply to this email directly or view it on GitHub
#42 (comment)
.

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

[Cagier]

Hi John,

Many thanks for your detailed and comprehensive reply. So, we are both using the xbridge2 software with partially modified xdrips (i.e. resistors but no extra wires to the HM1x). I knew about the difference in the protocols and that both worked with xDrip but I was not completely sure if the original wixel-xdrip worked with the xDrip at all to display the bridge battery - but you have clarified that only xbridge can do this so thanks.

We are not trying to modify that software to do anything the xbridge can do, we are just trying to troubleshoot why it is staying stuck at 100% until the battery drains. I was suggesting using the wixel-xdrip app to inspect the reported battery voltage/percentage that i being sent from the bridge by using the USB output - but I suppose that we could actually do the same thing with the xbridge2, now that I think of it! 😉

If you have any suggestions as to why the xDrip might be stuck on 100% until it dies then that would be helpful. Also, you mention above that the NS can display the bridge circuit battery as well (or instead of) as the uploader phone battery. Is that a parameter in Azure or am I misunderstanding you there? Could you explain how that is enabled or point us somewhere that does? I don't remember seeing it in the NS documentation (but maybe it is in an experimental branch or something).

Cheers,

Keith

[jstevensog]

Hi Keith, and all,
OK, now I have the context.
Firstly, to debug, all you need to do is connect your wixel to a USB cable and laptop with the battery disconnected. Open up a terminal program (PuTTY or KiTTY) and connect to the wixel. Once you connect the wixel, you have 30s of "dead time" to open the terminal and connect. You should then see the start up messages and debug messages.
Hitting the S key on the keyboard, while the wixel is awake, will show you the status output, which includes what the wixel thinks is the battery percentage.
With no battery connected, this should be 0. If you connect the battery, wait for a packet capture/sleep/wake, and hit S again, it will show you what it thinks the battery is again. Battery is only checked at start up and packet capture to save processing cycles for packet capture.

There would only be one assembly reason for what you are seeing, and that is the resistors are the wrong way round. A hardware reason could be that to much voltage was applied to the input at some time and damaged it. They can only handle 3.2V maximum, when is why the voltage divider resistors are there.

The other possibility is I have gotten the software wrong, but I haven't heard of this issue before, and don't have a wixel circuit here to test. If all of you are having the problem, then this is most likely.

Cheers

---- Keith Garland wrote ----

Hi John,

Many thanks for your detailed and comprehensive reply. So, we are both using the xbridge2 software with partially modified xdrips (i.e. resistors but no extra wires to the HM1x). I knew about the difference in the protocols and that both worked with xDrip but I was not completely sure if the original wixel-xdrip worked with the xDrip at all to display the bridge battery - but you have clarified that only xbridge can do this so thanks.

We are not trying to modify that software to do anything the xbridge can do, we are just trying to troubleshoot why it is staying stuck at 100% until the battery drains. I was suggesting using the wixel-xdrip app to inspect the reported battery voltage/percentage that i being sent from the bridge by using the USB output - but I suppose that we could actually do the same thing with the xbridge2, now that I think of it! 

If you have any suggestions as to why the xDrip might be stuck on 100% until it dies then that would be helpful. Also, you mention above that the NS can display the bridge circuit battery as well (or instead of) as the uploader phone battery. Is that a parameter in Azure or am I misunderstanding you there? Could you explain how that is enabled or point us somewhere that does? I don't remember seeing it in the NS documentation (but maybe it is in an experimental branch or something).

Cheers,

Keith

—
Reply to this email directly or view it on GitHub.

[Cagier]

Thanks again John.

I am actually using 11K and 6.8K resistors and by modifying the MIN/MAX values for my circuit I did actually get this work and for the first time I am seeing the correct values and not just 100%. (It took me a few attempts as I am using an xDrip circuit so did not immediately realise that it was the "CLASSIC" values that I had to modify.)

Unfortunately, the xbridge is now stopping after a few readings and the yellow light stays on. I have a suspicion that this is related to taking it all out of the Tic Tac box to reprogram and put it back in so there may be an intermittent hardware fault or something (hard for the lipo charger not to touch anything it shouldn't on the wixel in that space). It is also possible that I am using a slightly different xbridge source to the one I originally compiled (cannot remember if it was xbridge3 or xbridge2) and that there is some other new inconsistency introduced. Anyway, I will play about with it a bit more (debug output via USB and reassemble, etc.) and will hopefully get that ironed out tonight.

Just before we finish up, I wonder if you could elaborate on your comment "If you want bridge battery in NS, use xBridge.". This relates back to the query from the OP @9A6DQB when he asked if he needed to make modifications to Azure. Although I see the uploader batter, I didn't see the bridge battery appear in NightScout - can this feature be enabled in Azure or is it still in Beta or development somewhere?

Many thanks

[jstevensog]

Hi Keith,
Am an not sure at all about how Nightscout deals with the Bridge battery.
In xDrip, I deal with it as if it is the Phone battery, but I am unsure if
or how it is pushed up to NS. Certainly, it is possible with xBridge2, but
I do not know who would be wanting to make it so.
Once we have some agreement on how it is to be represented in mongodb, I am
happy to do the code changes on the xDrip side. It should be fairly
trivial.

One thing that has come to light yesterday is that the original wixel-xdrip
circuit diagram has the voltage divider resistors the wrong way round, or
my calculations assumed that they would be the same as xBridge. This
causes the xBridge to display 100% until the battery is almost flat. Once
orientated correctly, the battery voltage displays correctly.

I believe that the lower value resistor should be connected between GND
and P0_0, and the higher value between VIN and P0_0. If it is not actually
this way around, and I cannot see it working properly another way, I can
alter the code to suit for others in the future.
Hope this helps.
Cheers

On Thu, Jan 28, 2016 at 3:07 AM, Keith Garland notifications@github.com
wrote:

Thanks again John.

I am actually using 11K and 6.8K resistors and by modifying the MIN/MAX
values for my circuit I did actually get this work and for the first time I
am seeing the correct values and not just 100%. (It took me a few attempts
as I am using an xDrip circuit so did not immediately realise that it was
the "CLASSIC" values that I had to modify.)

Unfortunately, the xbridge is now stopping after a few readings and the
yellow light stays on. I have a suspicion that this is related to taking it
all out of the Tic Tac box to reprogram and put it back in so there may be
an intermittent hardware fault or something (hard for the lipo charger not
to touch anything it shouldn't on the wixel in that space). It is also
possible that I am using a slightly different xbridge source to the one I
originally compiled (cannot remember if it was xbridge3 or xbridge2) and
that there is some other new inconsistency introduced. Anyway, I will play
about with it a bit more (debug output via USB and reassemble, etc.) and
will hopefully get that ironed out tonight.

Just before we finish up, I wonder if you could elaborate on your comment
"If you want bridge battery in NS, use xBridge.". This relates back to the
query from the OP @9A6DQB https://github.com/9A6DQB when he asked if he
needed to make modifications to Azure. Although I see the uploader batter,
I didn't see the bridge battery appear in NightScout - can this feature be
enabled in Azure or is it still in Beta or development somewhere?

Many thanks

—
Reply to this email directly or view it on GitHub
#42 (comment)
.

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