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."

[jweismann]

Hello John

Would it be possible to simply add a collection, say bridgestatus with the bridge battery, similar to the devicestatus collection with the the uploader phone battery? It would allow us to analyze the bridge battery drain in more depth and it would provide data for NS allowing a hook there too. Whether it would be the desired layout for NS or not, I don't know but as a start, it would provide us with the data. I would appreciate the ability to get these numbers.

Cheers, Jacob

[jstevensog]

Hi Jacob,
I will see what I can do to get that done. Currently I am focused on
getting things ready for the next release.
If I can sneak it in, I will, otherwise it will be the following beta
release.

I personally don't use NS that much, other than for interest sake. Though,
I do use mongodb for analysis of my BGL over time.
Ideally, I'd like the bridge battery capacity in xDrip and NS as a chart.
Probably won't happen for a while.
Cheers

On Thu, Jan 28, 2016 at 9:09 AM, jweismann notifications@github.com wrote:

Hello John

Would it be possible to simply add a collection, say bridgestatus with the
bridge battery, similar to the devicestatus collection with the the
uploader phone battery? It would allow us to analyze the bridge battery
drain in more depth and it would provide data for NS allowing a hook there
too. Whether it would be the desired layout for NS or not, I don't know but
as a start, it would provide us with the data. I would appreciate the
ability to get these numbers.

Cheers, Jacob

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

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

[Cagier]

I agree it would be really useful to add this data but it could just be a new field in the existing "devicestatus" collection (where the uploaderBattery value is currently stored). This would facilitate future display on NightScout, NightWatch, NightWidget and Pebble as well as trend analysis, etc.

For analysis and debugging, it would be extra nice for the xbridge application to also transmit the "raw" battery values in the data packet as well as just the percentage - i.e. the value from "adcRead(0 | ADC_REFERENCE_INTERNAL)". This could then be stored along with the battery percentage in the same collection. Although, I suppose that maybe this can be (roughly) derived from the percentage value and the pre-defined min/max values. (My xbridge died at around 34% recently so it would be good to be able to know what the actual raw value was in order to re-calibrate my Min value.)

Incidentally, for the people who are using Wifi Wixels, the xbridge battery details are already stored by it. Mine is a home-grown version for a 2g wixel (parakeet type device) but I think the collection is in the same format...

_{ db : "geordanxxxxxxxdb", collection : "SnirData" }
{
"_id": {
"$oid": "56a9d3c071fe160ad0f72266"
},
"TransmissionId": 182,
"TransmitterId": "69xxx",
"RawValue": 155264,
"FilteredValue": 152864,
"BatteryLife": 214,
"ReceivedSignalStrength": -69,
"CaptureDateTime": 1453970368056,
"UploaderId": "Geordan",
* "UploaderBatteryLife": 74,*
"ReadableTime": "Thu Jan 28 08:39:16 GMT 2016"
}
_

So the UploaderBatteryLife field here is the wixel battery as opposed to the uploader phone...

[Cagier]

Sorry, I also meant to say many thanks to John for the detailed replies above. It was great to get that query clarified about the NS bridge battery once and for all (though some day hopefully!) (An interim fudge might be to have an option on the xDrip app to decide whether to upload/display the uploader or bridge battery into devicestatus.uploaderBattery maybe?)

Just to let you know that I reboxed everything and got my xbridge working properly again with the battery display all functioning correctly also. I think part of the issue may have been caused by swapping the xbridge and a traditional wixel backwards and forwards between two uploader phones at the same time. Anyway, it is all fixed now so thanks again for your help.

@9A6DQB - I wonder if you got your problem fixed in the end? It sounds from John's post above that you may always get 100% with the xbridge code and the original wixel-xdrip
circuit. @jstevensog - are there alternative min/max values that could be coded to allow for this or does it need an actual code change? The OP seems to have an issue compiling so I could generate a .wxl file for him if you tell me what to change.

I'm not sure how the original formula was derived but again this is where displaying the raw battery value rather than a percentage would come in handy! (It might be worth adding to the USB "S" status output. I can do that pretty easily myself but you might want to add it yourself as a feature.)

[forgetyan]

I had the same problem but I think I just found the problem. (At least in my case)

I used the instruction from StephenBlackWasAlreadyTaken to build the bridge on this page:
https://github.com/StephenBlackWasAlreadyTaken/xDrip/blob/gh-pages/hardware_setup.md
Note that the 1K resistor goes into the VIN and 2.2K goes into the GND pin.

But the StephenBlackWasAlreadyTaken repo does not contain the xBridge code. The Wixel code is for the "Bluetooth Wixel" which does not seems to report battery status.

So I searched again and finally found the xBridge code I found was here:
https://github.com/jstevensog/wixel-sdk

So I explored the "https://github.com/jstevensog/wixel-sdk/blob/master/apps/xBridge2/xBridge2.c" file and found these useful comments:
// assuming that there is a 27k ohm resistor between VIN and P0_0, and a 10k ohm resistor between P0_0 and GND, as per xBridge circuit diagrams
#define BATTERY_MAXIMUM (1814) //4.1V
#define BATTERY_MINIMUM (1416) //3.2V

The resistors assumed in the code are not the same that I used when building my xBridge. That probably why my battery status is always reported as 100%. I'll just try to figure out what is the Maximum and Minimum values required for these voltage and I suppose it will work fine.

[jstevensog]

If you are running xBridge2 wixel code on a "classic" circuit, I would recommend that you simply swap the resistors. When I wrote the code to support the classic circuit, I made the mistake of not checking the orientation of the voltage divider resistors and assumed they were the same way around as I had them.
Xbridge2 detects which circuit it is in and configures itself for it.

I would also recommend building the xBridge circuit (easy modifications) as the battery saving alone is worth the effort. We are deprecating the classic circuit and code.
Cheers

---- irDrake wrote ----

I had the same problem but I think I just found the problem. (At least in my case)

I used the instruction from StephenBlackWasAlreadyTaken to build the bridge on this page:
https://github.com/StephenBlackWasAlreadyTaken/xDrip/blob/gh-pages/hardware_setup.md
Note that the 1K resistor goes into the VIN and 2.2K goes into the GND pin.

But the StephenBlackWasAlreadyTaken repo does not contain the xBridge code. The Wixel code is for the "Bluetooth Wixel" which does not seems to report battery status.

So I searched again and finally found the xBridge code I found was here:
https://github.com/jstevensog/wixel-sdk

So I explored the "https://github.com/jstevensog/wixel-sdk/blob/master/apps/xBridge2/xBridge2.c" file and found these useful comments:
// assuming that there is a 27k ohm resistor between VIN and P0_0, and a 10k ohm resistor between P0_0 and GND, as per xBridge circuit diagrams
#define BATTERY_MAXIMUM (1814) //4.1V
#define BATTERY_MINIMUM (1416) //3.2V

The resistors assumed in the code are not the same that I used when building my xBridge. That probably why my battery status is always reported as 100%. I'll just try to figure out what is the Maximum and Minimum values required for these voltage and I suppose it will work fine.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

[forgetyan]

I'm not sure what is the "Classic" or "xBridge2" circuit. However, I looked at the code and I figured that I really had to change the resistors values to 27k and 10k ohm and now it works fine. :)

The voltage with the 2.2K and 1K ohm resistors were higher than the maximum value the Wixel could read so I couldn't just change the Max value in the code. (With the ADC_REFERENCE_INTERNAL parameter specified, the maximum voltage seems to be 1.25V.

(With the resistor at 2.2k and 1k, the voltage would be 2.8V when batteries are full.)

[jstevensog]

Especially wired that way around. Wired the same way around as the xBridge circuit, it would bring the voltage down just right, and the values in the code would be right enough for the code to "learn" you battery. That is another advantage of the xBridge code, it will adapt to your rig when it is first loaded and you go through a full charge/discharge cycle.

The issue is not the voltage reference, but the maximum analog input voltage of the cc2511 chip. Changing the reference in code won't help.

Btw, 2.8v is just under the level that will damage the cc2511 input.
Cheers

---- irDrake wrote ----

I'm not sure what is the "Classic" or "xBridge2" circuit. However, I looked at the code and I figured that I really had to change the resistors values to 27k and 10k ohm and now it works fine. :)

The voltage with the 2.2K and 1K ohm resistors were higher than the maximum value the Wixel could read so I couldn't just change the Max value in the code. (With the ADC_REFERENCE_INTERNAL parameter specified, the maximum voltage seems to be 1.25V.

(With the resistor at 2.2k and 1k, the voltage would be 2.8V when batteries are full.)

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

[forgetyan]

Thanks John!

Yes I saw the "Learning" part of your code (Very good idea btw) and I was even more puzzled that xDrip would still show 100%. That's until I figured that the Voltage was too high for the analog input. But I suppose that the learned voltage will reset on power loss?

So when I followed the instructions here, did I build the "xBridge" or the "Classic" Wixel?
https://github.com/StephenBlackWasAlreadyTaken/xDrip/blob/gh-pages/hardware_setup.md
What is the difference? And which one is the best/recent hardware version?

I'm trying to learn as much as possible because I would like to contribute and develop a "wifi" version for my two diabetics kids. (I'm a software developer) I'm not a fan of having a 3yo and 5yo carrying a 350$+ cellphone everywhere and they have wifi at kindergarten & school so a kind of "Parakeet" with WiFi instead of 3G would be perfect for us.

P. S: Since I changed the resistors and the code to your xBridge2 version, the range seems much higher. The kid is playing lego on the second floor and the xDrip still display readings. Earlier, I could not go farther than about 3 feets before I lost readings. Weird ;)

[jstevensog]

The "learned" battery limits only clear when the flash is overwritten,
usually when you load the .wxl file onto the wixel. I have thought about
putting a command in to clear everything, but that means the same sector of
flash gets cleared/overwritten constantly. It has a limited life span, so
probably not a good idea. Though, that said, I still haven't burnt out a
wixel's flash yet.

You definitely built the "classic" xdrip wixel circuit first. There are a
number of differences other than the voltage divider resistors, and most of
them pretty nerdy.

1. Communications is via packed byte array, rather than plain text. This
   means xBridge can transmit a lot more info in the limited BLE data size,
   and it does. It includes raw, filtered, transmitter battery, bridge
   battery, settings, and it will probably expand if I ever get xBridge3 out
   the door.
2. Bridge battery monitoring. It isn't perfect, but it is at least an
   indication. I'd like to get around to creating a single board that
   includes battery charging/monitoring, CC2541 and CC2511. But it will be a
   while.
3. Dex Transmitter ID set through protocol, so it can be set in the app
   without editing/compiling code.
4. Lower power consumption. It depowers the HM-1x module while it is
   sleeping. This can be turned on and off via a terminal command. When off,
   and the HM-1x is constantly powered, the BLE is more stable, but you burn
   through the battery. I usually get about 6 days between recharges (charge
   only on Mondays and Fridays) on a 1000mAh lipo with the HM-1x being
   depowered while the wixel sleeps, as opposed to 2 days if it is powered.

If you are going to start from scratch, I would look at the xBridge-oaps
code in my repo. It contains the bare bones packet capture, protocol and
sleep code. It is designed for interfacing to other devices, and not to be
a bridge. Probably easier to learn from.

BTW, I must stress, this is NOT all my original work. I began with Adrien
de Croy's dexterity-wixel code and improved on the packet capture code, and
added the rest. Same source that Stephen worked from with the classic
xdrip bridge. And Adrien will freely admit, he built on other's work. The
benefits of open source. Many contribute, many improve.
Cheers

On Mon, Apr 11, 2016 at 8:09 AM, irDrake notifications@github.com wrote:

Thanks John!

Yes I saw the "Learning" part of your code (Very good idea btw) and I was
even more puzzled that xDrip would still show 100%. That's until I figured
that the Voltage was too high for the analog input. But I suppose that the
learned voltage will reset on power loss?

So when I followed the instructions here, did I build the "xBridge" or the
"Classic" Wixel?

https://github.com/StephenBlackWasAlreadyTaken/xDrip/blob/gh-pages/hardware_setup.md
What is the difference? And which one is the best/recent hardware version?

I'm trying to learn as much as possible because I would like to contribute
and develop a "wifi" version for my two diabetics kids. (I'm a software
developer) I'm not a fan of having a 3yo and 5yo carrying a 350$+ cellphone
everywhere and they have wifi at kindergarten & school so a kind of
"Parakeet" with WiFi instead of 3G would be perfect for us.

P. S: Since I changed the resistors and the code to your xBridge2 version,
the range seems much higher. The kid is playing lego on the second floor
and the xDrip still display readings. Earlier, I could not go farther than
about 3 feets before I lost readings. Weird ;)

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#42 (comment)

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

[forgetyan]

Ok so that mean that, hardware wise, the only difference was the resistors. The rest is software.

So by changing the resistors AND software, I basically converted from "Classic" to "xBridge"?

I will definitely look into your xBridgeOaps project. Thanks for the heads up.

I'm definitely beginning to like these open source projects. I will continue to work in the same direction. Code based on another code based on another code. Who knows where this will lead us? :)

Is there a reason (legal or other) why nobody is offering an xDrip package for sell for non-DIY people?

Thanks for your work John (and Adrien's etc.), the xDrip will be really helpful for our family.

[jstevensog]

Yes,if you change the resistors AND power the HM-1x from the P1_0 pin of
the wixel, you have constructed the xBridge circuit. If you haven't powerd
the HM-1x from P1_0, then the xBridge2 code will think it is in a "classic"
sdrip circuit and configure itself accordingly, which might not be what you
want.

And, yes, there are legal rasons why people are not offering a pre-built
package. Once you pre-build a device, you are coming under the auspices of
the FDA and other authorities world wide. That is why NS is totally DIY.
Even though we now have approval for "remote viewing" of data, the actual
capturing and calculation of BGL is something altogether different.

I think the only wriggle room would be to make a single device that is a
"proprietary wireless to BLE bridge" that can just happen to be programmed
to do what xBridge does now. But that might be a stretch also.

In Italy they have the xItaly bridge package, but it is still DIY
assembly. In the UK, someone is putting a DIY package together and people
here have built it. Here in .au, we have a company that will sell a
"package" of the raw components (except the HM-1x) for people to build one.

But it still needs to be DIY to prevent the project coming under ire from
authorities.
Cheers

On Mon, Apr 11, 2016 at 11:32 AM, irDrake notifications@github.com wrote:

Ok so that mean that, hardware wise, the only difference was the
resistors. The rest is software.

So by changing the resistors AND software, I basically converted from
"Classic" to "xBridge"?

I will definitely look into your xBridgeOaps project. Thanks for the heads
up.

I'm definitely beginning to like these open source projects. I will
continue to work in the same direction. Code based on another code based on
another code. Who knows where this will lead us? :)

Is there a reason (legal or other) why nobody is offering an xDrip package
for sell for non-DIY people?

Thanks for your work John (and Adrien's etc.), the xDrip will be really
helpful for our family.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#42 (comment)

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

[forgetyan]

Ok, I see that "BATTERY_MAXIMUM_CLASSIC" is used if XBRIDGE_HW is set to 0. But it's set 0 only if there is not a high on P1_2. But according to build instruction I used on https://github.com/StephenBlackWasAlreadyTaken/xDrip/blob/gh-pages/hardware_setup.md, There is nothing to connect to P1_2. I'm using 3V3 port as described. So that mean the code "thinks" I built a "Classic". https://camo.githubusercontent.com/bb0139275311f6888a468057cd47767282b71018/687474703a2f2f692e696d6775722e636f6d2f4549476b6935522e706e67

So that mean that the code is not using the good battery minimum & maximum right now. And if I understand your code, that mean that I'm also wasting energy because my xBridge will not turn off BLE as intended on P1_0. Pin P1_0 is not plugged so any attempt by the code to turn on/off the BLE is useless. (Note to myself: Connect BLE to P1_0 ASAP)

Is there a schema / tutorial to build the xBridge that I missed? I googled but did not find anything else than the Classic setup on StephenBlackWasAlreadyTaken's wiki. I see that P1_2 should also be used but I'm not sure where it's supposed to be connected.

While I have experience in programming, I'm new to xDrip/xBridge/NS/OpenAPS etc. so I'm sorry if I asked a question that was already answered elsewhere.

[jstevensog]

You didn't miss anything on the internet. The circuit is explained and
well described in the xBridge2.pdf in the Circuit Diagrams section. I
haven't gotten around to doing any video of construction as yet, so most
people keep building the "classic" circuit. We really need to be clear
that the classic circuit is deprecated these days, but I am not in control
of the project documentation site.
Cheers

On Mon, Apr 11, 2016 at 12:28 PM, irDrake notifications@github.com wrote:

Ok, I see that "BATTERY_MAXIMUM_CLASSIC" is used if XBRIDGE_HW is set to
0. But it's set 0 only if there is not a high on P1_2. But according to
build instruction I used on
https://github.com/StephenBlackWasAlreadyTaken/xDrip/blob/gh-pages/hardware_setup.md,
There is nothing to connect to P1_2. I'm using 3V3 port as described. So
that mean the code "thinks" I built a "Classic".
https://camo.githubusercontent.com/bb0139275311f6888a468057cd47767282b71018/687474703a2f2f692e696d6775722e636f6d2f4549476b6935522e706e67

So that mean that the code is not using the good battery minimuim &
maximum right now. And if I understand your code, that mean that I'm also
wasting energy because my xBridge will not turn off BLE as intended on
P1_0. Pin P1_0 is not plugged so any attempt by the code to turn on/off the
BLE is useless. (Note to myself: Connect BLE to P1_0 ASAP)

Is there a schema / tutorial to build the xBridge that I missed? I googled
but did not find anything else than the Classic setup on
StephenBlackWasAlreadyTaken's wiki. I see that P1_2 should also be used but
I'm not sure where it's supposed to be connected.

While I have experience in programming, I'm new to
xDrip/xBridge/NS/OpenAPS etc. so I'm sorry if I asked a question that was
already answered elsewhere.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#42 (comment)

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

[forgetyan]

OMG! What I was searching for was in front of me this whole time! LoL!

Thank you very much! Now I only need to solder BLE VCC to P1_0 and STATE to P1_2 and I'm done :)

My next goal once this is done was to check on OpenAPS and since you began the integration, I might even send you a pull request in the future. Who knows ;)

Thanks John!

[jstevensog]

Your welcome.
Have fun.
Cheers

On Mon, Apr 11, 2016 at 12:49 PM, irDrake notifications@github.com wrote:

OMG! What I was searching for was in front of me this whole time! LoL!

Thank you very much! Now I only need to solder BLE VCC to P1_0 and STATE
to P1_2 and I'm done :)

My next goal once this is done was to check on OpenAPS and since you began
the integration, I might even send you a pull request in the future. Who
knows ;)

Thanks John!

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#42 (comment)

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

[square-eyes]

Hi all, I am quite confused after reading this. My first DIY bridge is about to die so I'm making my next one. I never had the batt indicator mod before because I was powering the Wixel via USB (different story).

I imported all the parts, including resistors, and have soldered the bridge circuit according to instructions here, which I might add is linked from the main xDrip landing page. The build took a whole day as I was meticulously doing everything correctly, taking care to get all the solder joints perfect so as to not perish early like my first one.

I was excited to see the batt indicator in xDrip+ at 100%. Now overnight my bridge lost power and I lost data. This morning, as soon as I plug the bridge in to the charger it shows 100%.

So I come to this extremely long thread where I find people with the same issue. I'm still really confused and I think it needs to be cleared up for others to read.

From what I'm reading above, I should actually have wired up my bridge differently from the instructions on the main page (which as far as I can tell make no distinction between the two configs). To make matters worse the new Wixel code allows for the old circuit (I know this is a cool feature for old circuit users).

I used this diagram and was sent this file xBridge2.wxl on an issue thread when I had problems compiling it myself. But reading above I'm seeing there is a different circuit.

Can someone please confirm what the best course of action is for me to get up and running with the batt indicator?

Will my 1K and 2.2K resistors still be suitable?

If I'm right in my interpretation of this, and all the posts above, then we really should make this clear on the landing page, which is how people find their way to the instructions.

I'm sorry if I have missed something blindingly obvious, and am happy to be put in my place!

[jstevensog]

Hi Mark,
The 1k and 2.2k resistors will still work fine, but they need to be
soldered differently if you are running xBridge2.wxl. Essentially swap
them around so that the voltage divider ratio is correct.

The correct circuit (including different resistors, and full information of
what is possible with xBridge) can be found here.
https://github.com/jstevensog/wixel-sdk/blob/master/apps/xBridge2/xBridge2.pdf

I highly recommend using the larger value resistors in this document, as it
will provide a noticeably longer battery life.

The issue is that with the wixel-dexdrip circuit the resistors are the
wrong way around for the xBridge2 code. One can argue that they are the
wrong way around full stop. Therefore, the value read by the Analogue to
Digital Converter in the wixel CC2511 chip is too high, and thus shows 100%
much of the time until the battery is flat. The resistors constitute a
voltage divider circuit to "drop down" the battery voltage to a level that
the CC2511 can handle and measure without doing damage.

If you used the 1 and 2.2 k resistors in your original bridge, they have
simply been draining your battery faster than needs be for no benefit.

Unfortunately, although the xDrip developer team have deprecated the
wixel-dexdrip code in favour of xBridge2, for some reason it has not made
it to the main page.

Also note, that xDrip is no longer being actively developed (only some
occasional bug fixes) anymore. It has been deprecated in favour of xDrip+.

I hope this helps.
Cheers

On Mon, Nov 14, 2016 at 10:12 AM, Mark Francis notifications@github.com
wrote:

Hi all, I am quite confused after reading this. My first DIY bridge is
about to die so I'm making my next one. I never had the batt indicator mod
before because I was powering the Wixel via USB (different story). I have
the parts and have soldered the bridge circuit according to instructions
here
https://github.com/StephenBlackWasAlreadyTaken/xDrip/wiki/xDrip-Wireless-Bridge,
which I might add is linked from the main xDrip landing page. The build
took a whole day as I was meticulously doing everything correctly, taking
care to get all the solder joints perfect so as to not perish early like my
first one.

I was excited to see the batt indicator in xDrip+ at 100%. Now overnight
my bridge lost poser and I lost connection. As soon as I plug the bridge in
to the charger it shows 100%

So I come to this extremely long thread where I find people with the same
issue. I'm still really confused and I think it needs to be cleared up for
others to read.

From what I'm reading above, I should actually have wired up my bridge
differently from the instructions on the main page (which as far as I can
tell make no distinction between the two configs). To make matters worse
the new Wixel code allows for the old circuit (I know this is a cool
feature for old circuit users).

I used this diagram
https://github.com/StephenBlackWasAlreadyTaken/xDrip/blob/gh-pages/hardware_setup.md
and was sent this file xBridge2.wxl
StephenBlackWasAlreadyTaken/xDrip#160 on an
issue thread when I had problems compiling it myself.but reading above
there is a different circuit.

Can someone please confirm what the best course of action is for me to get
up and running with the batt indicator?

Will my 1K and 2.2K resistors still be suitable?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#42 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIQs89H3hu8iMCVGaESEk4ghCv7iFRGHks5q95lTgaJpZM4HId8P
.

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

[square-eyes]

Great thanks for the info I will go to my local shop for new resistors. I'm going to have to re-do the circuit anyway by the looks.

Yes I'm using xDrip+ now thanks too.

It's pretty frustrating to have to re-solder the boards. That's a lost day for me and these things break easily (I destroyed a Wixel on a previous repair job - but I'm getting better!). I'm going to put a note on the Github pages I linked above as this could have easily been avoided.

I'm really grateful to all the developers though. This thing has made such a positive difference in my life.

[square-eyes]

Got it up an running :) Not too happy with the joints though. It's all a bit hectic so I'm going to try to tidy it up. Battery life is much better.

[jstevensog]

Sorry for the long delay in responding.
You probably already know this, but I will mention it anyway, regarding
soldering for high reliability.

1. Never apply solder to the tip of the iron, unless you absolutely need to
   (such as tinning wires). Heat the parts, and apply solder them, not the
   tip of the iron.
2. When using stranded wires, ALWAYS tin the wires. Hold the stripped end
   of the wire against the soldering iron tip, wait long enough for it to heat
   up, then apply a small amount of solder to the wire (not the iron tip).
   When soldering the wire to a PCB pad, the same applies for 1 above.

The reason being that the flux within the solder will burn off if you apply
it to the iron tip. By heating the parts and applying the solder to them,
it allows the flux to flow freely between the parts and take the solder
with it, macking a good joint, with maximum contact and adhesion.
Cheers

On Wed, Nov 16, 2016 at 9:08 PM, Mark Francis notifications@github.com
wrote:

Got it up an running :) Not too happy with the joints though. It's all a
bit hectic so I'm going to try to tidy it up. Battery life is much better.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#42 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIQs82LSAJ_xaufQC5oI61SoUF7qySBAks5q-tYYgaJpZM4HId8P
.

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