jstevensog / wixel-sdk

Adrien de Croy's wixel-sdk for building dexterity-wixel and xBridge apps

xBridge SDK

Pololu Wixel SDK, with xBridge code.

This repository contains Adrien de Croy's polou wixel SDK, his original dexterity code, and a modified version of that code called xBridge2. To build xBridge2, please download this entire repository. Or download and install the xBridge2.wxl file from apps/xBridge2 onto your wixel.

All thanks to Adrien de Croy for all his work on developing dexterity, which has made this code possible.

xBridge Version History

Version	Changes
2.47e	Adds support for HM-16/17 BLE modules. Simplified circuitry. Greater packet capture and sleep timing stability
2.46	Increased LED indications as requested by Kate Farnsworth.
2.43	Improved power consumption. Fixed power drain through UART.

Road Map

1. Implement a packet queue, a la savek-cc's version. (target 2.48 or 3.0x). Requires a protocol change that will impact users of xDrip and older versions of xDrip+. Hence my reluctance to implement in v2.xx. v3 will only be supported in xDrip+, and this can be better managed.
2. Channel Scanning (target v3.xx). This will remove the reliance on sleep time being to within a 100ms accuracy. However, attempts to write the correct code into the radio mac has so far proven unsuccessful.

Important documentation to be completed

1. Test Plan - So that every developer can regression test their code prior to doing PRs.
2. Stand alone code repository, not dependent on the wixel-sdk.
3. Release Process - So far this has been a minimal process relying solely on jstevensog to manage. This needs to change so that others can contribute to getting changes through development, testing, beta testing and release without impacting the non-tehcnical user.

wixel-sdk's Issues

Feature request - bridgestatus in mongo similar to devicestatus

Hello John

I would like to analyze the bridge2 battery discharging in more details and
thought it would be convenient to have the bridge battery uploaded to mongodb
just like we have the uploader phone battery in the devicestatus collection
today. Would it be possible to add another collection to mongo, say bridgestatus,
that would have battery data for the bridge instead of the device.

Thanks a lot in advance,

Cheers, Jacob

Battery Level

Hello,
I know this has been discussed a bit, but just curious what the software side of the Wixel is doing with the xBridge2 27K/10K voltage divider, and what the levels are.
4.2V with a 27K/10K comes out 1.135V on the analog input of the Wixel.
3.0V (battery turns itself off) comes out 0.811V on the Wixel.
So that is 0.324V range only.
Just curious why these resistors were chosen.
Wixel is 7bit to 12bit resolution I believe, what resolution is being used for this? 0-128 or 0-4096, or something in between?

Wixel Analog input is 0-3.3V, and we are using at best 0.811-1.135V.
Can we improve this?

For example if it was changed from 27K/10K, to be 4K/10K, then
4.2V would be 3.0V on the Wixel
3.0V would be 2.143V on the Wixel
giving 0.857V range, instead of 0.324V range.

Could likely even be better than this, but this is just an example..

Maybe 3.3V is the 0% limit, given that is what the reference is based on, I am not sure.

Like my battery currently is 4.11V and its saying 80%, when in reality its more than that.

Can you tell me where in the software these bits are and if they are changeable, so I can experiment with different resistor values?
Does the xBridge2 send the 0-100% reading to the xDrip/xDrip2, or is the 0-100% calculated in the xDrip/xDrip2 application itself?

Thanks

xBridge2.wxl invalid data in file error

Have constructed the xBridge hardware with the potential divider and bluetooth state line and am trying to use the latest version of the xBridge2 software. Unfortunately I get an error in the Wixel configuration utility when using the xBridge2.wxl file within the apps/xBridge2 folder as follows:

Invalid data in file.
App File could not be opened: xBridge2.wxl

I've probably made a mistake somewhere along the line but I know my config utility is ok because I reprogrammed an xdrip a couple of days ago without a problem.

Any idea what could be happening?

Thanks,
Martin

hm-11 firmware flash impossible

hi
i tried to update the hm-11 to the latest firmware. but when i type AT-SBLUP i did not get OK-SBLUP. All other AT commands are working.

Transmitter serial to source/target radio address

Hi John,

I'm trying to make same bridge for my wife but using Arduino platform with C++ (I'm junior developer and this is for my self development mainly, and Arduino is more available in Ukraine) and I'm wondering how do you receive source address in ?? ?? ?? ?? format to read the data? If this is not a secret of course.

Thanks for your time.

Wixel Configuration Utility doesn't open xbrige2.wxl

Hello i'm trying to program wixel with the last release of the app , but configuration utility isn't able to open the file and gives this error " Invalid data in file.
App File could not be opened: xBridge2.wxl " With the previous version file everything is ok , may I know if something is wrong with datafile ? Tnx Antonio

Cannot update transmitter id on 2.47e and 2.47f

Running xDrip+ on the phone and xBridge wixel with an HM11 circuit as per Chris Bothello (CC2541) firmware v540. This has performed beautifully for a couple of years, but I cannot upgrade to 2.47e or 2.47f (See diagnostics below.) and 2.47 seems to experience a lot of zombie disconnects. Each instance started with a fresh install of Xdrip+ on the phone and a rewrite of the wixel and ended with a status request to confirm the stored settings. All done within minutes of each other, so no temperature differences. Also I did the checks referred to in issue "2.47e does not work" - both p1_6 and p1_7 are ok as expected because this xBridge functions OK at version 2.43, 2.46 and 2.47 Just the dropout rate at 2.46 and especially 2.47 appears to be more frequent. (or dropouts are more invisible/silent, difficult to manage due to improved sleeping).
Thanks for your work to date. Ken.
+++++++++++++++++++++++++++++++++++version 2.43 works OK++++++++++++
xBridge hardware circuit selected
batteryPercent val: 353
batteryPercent returning 0
No dex_tx_id. Sending beacon.
OK+CONNOK+Get:06OK+Get:00O49359: sending beacon Now
Sending: �?K+Get:7D
Response: OK+Get:1EOK+Get:00OK+Get:25No dex_tx_id. Sending beacon.
59423: sending beacon Now
Sending: �?
Response: ��?�ilooking for 6883233 (6J1W1)
waiting for packet on channel 0 for 0
sProcessing Status Command
xBridge v2.43
dex_tx_id: 6883233 (6J1W1)
initialised: 0, sleep_ble: 1, dont_ignore_ble_state: 1, xBridge_hardware: 1, send_debug: 1, do_leds: 1
battery_capacity: 0
current ms: 85247

+++++++++++++++++++++++++++++++++++version 2.46 works OK++++++++++++
AT+RESETxBridge hardware circuit selected
batteryPercent val: 351
batteryPercent returning 0
No dex_tx_id. Sending beacon.
OK+CONNOK+Get:06OK+Get:00OK+Get35601: sending beacon Now
Sending: �?:7D
Response: OK+Get:1EOK+Get:00OK+Get:25No dex_tx_id. Sending beacon.
45679: sending beacon Now
Sending: �?
Response: ��?�ilooking for 6883233 (6J1W1)
waiting for packet on channel 0 for 0
sProcessing Status Command
xBridge v2.46
dex_tx_id: 6883233 (6J1W1)
initialised: 0, sleep_ble: 1, dont_ignore_ble_state: 1, xBridge_hardware: 1, send_debug: 1, do_leds: 1
dex_tx_id_set: 1, got_packet: 0
battery_capacity: 0
current ms: 57187

+++++++++++++++++++++++++++++++++++version 2.47 works OK++++++++++++
Starting xBridge v2.47
Retrieving Settings
ATAT+NAMExBridgefc4fAT+RESETxBridge hardware circuit selected
batteryPercent val: 351
batteryPercent returning 0
No dex_tx_id. Sending beacon.
OK+CONN30958: sending beacon Now
Sending: �?
Response: OK+Get:06OK+Get:00OK+Get:7DOK+Get:15OK+Get:00OK+Get:25No dex_tx_id. Sending beacon.
40999: sending beacon Now
Sending: �?
Response: ��?�ilooking for 6883233 (6J1W1)
waiting for packet on channel 0 for 0
sProcessing Status Command
xBridge v2.47
dex_tx_id: 6883233 (6J1W1)
initialised: 0, sleep_ble: 1, dont_ignore_ble_state: 1, xBridge_hardware: 1, send_debug: 1, do_leds: 1
dex_tx_id_set: 1, got_packet: 0
battery_capacity: 0
current ms: 49884

+++++++++++++++++++++++++++++++++version 2.47e Fails to update TX-ID++++++++++++
Starting xBridge v2.47e
Retrieving Settings
Determining HM-1x baudrate
trying 9600
11024 - send_data AT (2)
Sending: AT
Response: OK11065 - got OK
11065 - atBt() got OK
11066 - send_data AT (2)
11066 - send_data blocked on uart1 input
Sending: AT
Response: OK11087 - got OK
11087 - atBt() got OK
11088 - send_data AT (2)
11088 - send_data blocked on uart1 input
Sending: AT
Response: 11595 - atBt() Did not get an OK
12603 - send_data AT+NAMExBridgefc4f (18)
12604 - send_data blocked on uart1 input
?Sending: AT+NAMExBridgefc4f
Response: OK12641 - got OK
+Set:xBridgefc4f13131 - send_data AT+NOTI1 (8)
13131 - send_data blocked on uart1 input
Sending: AT+NOTI1
Response: OK+Set:113647 - send_data AT+RESET (8)
13647 - send_data blocked on uart1 input
Sending: AT+RESET
Response: OK+RESET?xBridge hardware circuit selected
batteryPercent val: 352
batteryPercent returning 0
No dex_tx_id. Sending beacon.
OK+CONNble connected
25184: sending beacon Now
25184 - send_data �? (7)
25185 - send_data blocked on uart1 input
Sending: �?OK+Get:06OK+Get:00OK+Get:7DOK+GeNo dex_tx_id. Sending beacon.
35697: sending beacon Now
35697 - send_data �? (7)
35697 - send_data blocked on uart1 input
Sending: �?No dex_tx_id. Sending beacon.
46218: sending beacon Now
46218 - send_data �? (7)
46219 - send_data blocked on uart1 input
Sending: �?No dex_tx_id. Sending beacon.
56739: sending beacon Now
56740 - send_data �? (7)
56740 - send_data blocked on uart1 input
Sending: �?sProcessing Status Command
xBridge v2.47e
dex_tx_id: 0 (00000)
initialised: 0, sleep_ble: 1, dont_ignore_ble_state: 1, xBridge_hardware: 1, send_debug: 1, do_leds: 1
dex_tx_id_set: 0, got_packet: 0
battery_capacity: 0
current ms: 62166

No dex_tx_id. Sending beacon.
67264: sending beacon Now
67264 - send_data �? (7)
67264 - send_data blocked on uart1 input
Sending: �?

+++++++++++++++++++++++++++++++++version 2.47f Fails to update TX-ID++++++++++++
Starting xBridge v2.47f
Retrieving Settings
Determining HM-1x baudrate
trying 9600
11024 - send_data AT (2)
Sending: AT
Response: OK11065 - got OK
11065 - atBt() got OK
11066 - send_data AT (2)
11066 - send_data blocked on uart1 input
Sending: AT
Response: OK11087 - got OK
11087 - atBt() got OK
11088 - send_data AT (2)
11088 - send_data blocked on uart1 input
Sending: AT
Response: 11595 - atBt() Did not get an OK
12603 - send_data AT+NAMExBridgefc4f (18)
12604 - send_data blocked on uart1 input
?Sending: AT+NAMExBridgefc4f
Response: OK12641 - got OK
+Set:xBridgefc4f13131 - send_data AT+NOTI1 (8)
13131 - send_data blocked on uart1 input
Sending: AT+NOTI1
Response: OK+Set:113647 - send_data AT+RESET (8)
13647 - send_data blocked on uart1 input
Sending: AT+RESET
Response: OK+RESET?xBridge hardware circuit selected
batteryPercent val: 351
batteryPercent returning 0
No dex_tx_id. Sending beacon.
OK+CONNble connected
23157: sending beacon Now
23157 - send_data �? (7)
23157 - send_data blocked on uart1 input
Sending: �?OK+Get:06OK+Get:00OK+Get:7DOK+GeNo dex_tx_id. Sending beacon.
33669: sending beacon Now
33670 - send_data �? (7)
33670 - send_data blocked on uart1 input
Sending: �?No dex_tx_id. Sending beacon.
44191: sending beacon Now
44191 - send_data �? (7)
44191 - send_data blocked on uart1 input
Sending: �?sProcessing Status Command
xBridge v2.47f
dex_tx_id: 0 (00000)
initialised: 0, sleep_ble: 1, dont_ignore_ble_state: 1, xBridge_hardware: 1, send_debug: 1, do_leds: 1
dex_tx_id_set: 0, got_packet: 0
battery_capacity: 0
current ms: 48912

No dex_tx_id. Sending beacon.
54715: sending beacon Now
54715 - send_data �? (7)
54716 - send_data blocked on uart1 input
Sending: �?

xBridge Gets one reading then fails - Sleep seems to happen even when disabled.

I'm having a hard time getting readings. I've tried a stock Galaxy S8 Nougat, and Lineage Nougat on S5.

I have sleep_ble off to improve BT performance, but it seems to sleep anyway. xDrip+ gets one reading and then nothing after that. I power cycled after a clean 2.4.7f flash.

I'm using a HM17 with @WanaGo's motherboard. Dexcom G4 receiver is happily receiving data.

xBridge v2.47f
dex_tx_id: 6553988 (680C4)
initialised: 0, sleep_ble: 0, dont_ignore_ble_state: 1, xBridge_hardware: 1, sen                            d_debug: 1, do_leds: 1
dex_tx_id_set: 1, got_packet: 1
battery_capacity: 0
current ms: 250032
254002 - packet waiting
254002 - send pkt
254003 - send_data  (17)
254003 - send_data blocked on uart1 input
Sending: ▒p▒a▒▒d
Response: 254019 - waiting for ack
264034 - packet waiting
264035 - send pkt
264035 - send_data  (17)
264035 - send_data blocked on uart1 input
Sending: ▒p▒a▒▒d
Response: 264051 - waiting for ack
274067 - packet waiting
274067 - send pkt
274067 - send_data  (17)
274067 - send_data blocked on uart1 input
Sending: ▒p▒a▒▒d
Response: 274084 - waiting for ack
284099 - packet waiting
284099 - send pkt
284099 - send_data  (17)
284100 - send_data blocked on uart1 input
Sending: ▒p▒a▒▒d
Response: 284116 - waiting for ack
294131 - packet waiting
294131 - send pkt
294131 - send_data  (17)
294132 - send_data blocked on uart1 input
Sending: ▒p▒a▒▒d
Response: 294148 - waiting for ack
304163 - packet waiting
304163 - send pkt
304164 - send_data  (17)
304164 - send_data blocked on uart1 input
Sending: ▒p▒a▒▒d
Response: 304180 - waiting for ack
314195 - packet waiting
314196 - send pkt
314196 - send_data  (17)
314196 - send_data blocked on uart1 input
Sending: ▒p▒a▒▒d
Response: 314212 - waiting for ack
324227 - packet waiting
324228 - send pkt
324228 - send_data  (17)
324228 - send_data blocked on uart1 input
Sending: ▒p▒a▒▒d
Response: 324244 - waiting for ack
334260 - packet waiting
334260 - send pkt
334260 - send_data  (17)
334260 - send_data blocked on uart1 input
Sending: ▒p▒a▒▒d
Response: 334277 - waiting for ack
344292 - packet waiting
344292 - send pkt
344292 - send_data  (17)
344293 - send_data blocked on uart1 input
Sending: ▒p▒a▒▒d
Response: 344309 - waiting for ack
354324 - No ACK received
354825 - sleeping for 260
354825 - sleep_time_ms is 130000, this_sleep_time is 9110

Wixel-HM10 as a G4 to G5 bridge ?

How difficult would it be to convert the xBridge into a transceiver that receives G4 data (simpliciTI) on the wixel side and communicates as a G5 (BTLE) on the HM-10 side ?

Diagram for bare HM11 seems inconsistent with the datesheet

Hi John

After the success with the HM10 module, I had a look at the bare HM11 diagram and the GND line from the HM11 is drawn as going out from line13 in the diagram in xbridge2.pdf but according to the datasheet, GND is line12 (line 13 is PIO3), cf. reference below. Have I misunderstood something or is there are typo in one of the documents ?

Cheers, Jacob

PS! Datasheet referece (section 1.7)
http://www.pridopia.co.uk/pi-doc/BT4.0-HM-10 Serial_Port_BLE_Module_Master_Slave.pdf

Initial feedback on the xbridge documentation

Hello John

I am writing mainly to express my sincere gratitude for your contributions on the
xbridge HW and SW. I recently heard about xdrip and ordered a couple of wixels etc.
to get started.

Here are my initial findings which might be useful to you in case you are to
upgrade your documentation:

1. At first I got confused wrt the source to build. I found your documentation
   here https://github.com/StephenBlackWasAlreadyTaken/xDrip/wiki/xDrip-Beta

Read the awesome docs John put together here... And it took me a while before
I realized that xdrip beta (which was where I found the document) and xbridge
(your repository) was different repositories.

2. I did build with sdcc v3.3.0 (default on kubuntu 14.04) and some of the
   apps in your wixel-sdk directory did not compile with this version of sdcc.
   However, both xbridge2 and usb-serial build without problems so I just skipped
   the ones that I didn't need. I realize that you are using an older version of
   sdcc but I hope not that a specific version of the compiler is required to get
   a properly build binary.

3. I forgot to solder a jumper on the charger simply because I followed your
   instructions one by one. Maybe it would be a good idea to mention it in your
   documentation too if others are as sloppy as me and first study the "reference"
   afterwards when they find that charging is really slow.

4. I experience occasional gaps like Mathias and others have reported too but
   thus far I only have a couple of days experiences so still too early to say if
   this is consistent. I might try to solder an xdrip too so that we can
   cross-compare with that.

5. Not sure if I will be able to reproduce your 6 days on a 1200mAh. It dropped
   from 100% to 86% in a few hours but now it seems to stabilize on 86% so maybe
   I will. I will keep you updated on this. As an aside, the nightscout site
   (running 0.8.1) setup for this does not show the correct battery status. It
   stays on 60% and does not change at all.

Again, the main purpose of this email was really to thank you. I really
appreciate your (and all other xdrip/xbridge/nightscout developers for that
matter) efforts on this. THANKS!

Kind regards, Jacob

PS! For the reference here is a detailed listing of the parts that I used for
my first installation:

Lithium Ion Polymer Battery - 3.7v 1200mAh from adafruit.com (PID: 258)
Adafruit Micro Lipo w/MicroUSB Jack - USB LiIon/LiPoly charger - v1 PID: 1904
(bought directly from adafruit, shipment to US address despite the fact that I live in Denmark, Europe)

Wixels from www.pololu.com, bought in the US with shipment to US address.

Note that I bought the wixels in the US but experience the same problems as others
that bought them in Europe. Thus, I think we can exclude the location as the
main issue.

HM-10 BLE module from fasttech:
https://www.fasttech.com/product/1292002-ti-cc2540-cc2541-bluetooth-4-0-ble-2540-2541

Moto G running android 5.1

No simple recovering from sudden missing signals

Hi Steven

I would really appreciate some feedback on further debugging of
the issue described below.

I have two rigs, say ROK and RnotOK that were build back in 2015. We
have used ROK on a daily basis for 2 years and it has worked without
problems at all. THANKS!!!

The RnotOK was build as a spare rig and I have only used it for some minor
tests during this period so it was not until recently I found that it
actually shows issues with missing signals like those others have reported
both here and in xdrip threads. Thus, I went from thinking I had a spare
rig to a situation where I need to get the spare working in case I will
need it one day.

Here are a short summary of the tests and findings I have done thus far:

1. The RnotOK will work absolutely fine for a longer period, i.e. more
   than 24 hours. Then suddenly is start to loose signals consistently and
   there is nothing simple that will bring it back on track and catch another
   signal. The only thing that will make it function again is to:

a) take off battery power to RnotOK ensuring that the wixel is
disconnected from any possible power sources
b) reset the wixel by wiring P2_2 to 3V3 and then plug it into USB
c) reload the xbridge2.wxl onto the wixel
d) forget device on the phone
e) scan for bt
f) then signals are back within 5-10 minutes and consistently so for
at least 24H.

In order to exclude various sources to this problem I have used two
phones, say P1 and P2, and done several experiments

My conclusion is that we can exclude the usual suspects

1. This is not a without-of-range related problem.
2. This is not a phone related problem, i.e.
   a. Both phones treat RnotOK and ROK the same way, i.e. both
   works like a charm for ROK (P1 in years and P2 in weeks)
   and both fails to get signal for RnotOK after having worked
   fine for a period exceeding 24H but never reached 72H (I
   did not forget to charge the battery :)).
   b. different OS versions treat both RnotOK and ROK consistently, i.e.
   phone1 runs 5.1 whereas phone2 runs 6.0.1
3. This is not a xdrip-version related problem, i.e. tried both
   xdrip plus and the old xdrip beta and both versions works fine
   and consistently with ROK and fails the same way for RnotOK.
4. This does not seem to be a Bridge2 wxl version issue either. I
   have tried both the latest 2.47 and an older 2.33 version.
5. It is not a transmitter issue, during all the tests conducted I
   have had two dexcom receivers and the ROK working without problems.

Potential remaining sources to the issues

1. I guess (but don't see how I can exclude this completely) that it's
   not a wiring problem either since then I wouldn't expect that I should
   be able to bring RnotOK back to good mode again, cf. procedure above,
   and get good consistent results for a longer period of time (say 24H).

2. The wixel itself is broken somehow but it takes a special cases to trigger
   the issue.

3. The BT module is broken somehow (I use HM11 both on ROK and RnotOK) but
   again it takes a special cases to trigger the issue. It should be noted
   that the rig and the phone stays connected and 'restart collection' does
   have an impact on the rig, i.e. version 2.33 have yellow LED turned on
   consistently once the issue begins and 'restart collection' will turn it
   off for a short period of time but then it re-enters the situation where
   we have yellow LED turned on (not blinking).

4. The logic in the xBridge2 code (even in the latest version 2.47) is incomplete
   somehow in the sense that we can reach stages that the code cannot recover
   from and where a complete RESET as described above is required to get it
   back on track.

5. ?????

I would be most grateful for any kind of feedback on this and especially ideas
on what I could try to pinpoint the issue further. Thank you so much in advance,

Cheers, Jacob

Beacon Packet length in PDF

Should the byte zero of the beacon packet in the documentation pdf for xBridge2 be a value of 7 bytes and not 6?

One xBridge2 as data source for two (multiple) xDrip+ phones (devices)

My sincere apologies if this is not the best and most logical question, but I would really like to know from the experienced ones if there is some proper (feasible, secure) good way of getting two or more phones with xDrip+ app to connect to the same xBridge2 as their collector. I noticed that after the data is transferred between xBridge2 and xDrip, the xBridge2 goes to sleep. I am asking this from the perspective of redundancy in the possible practical situation when one has two phones, or maybe phone and cheap Chinese Android (but NOT Wear) smartwatch or...? The question is not targeted to Master + Follower setup. Also, I understand that in such a situations as described above the one should always calibrate both xDrip+ phones in order to have comparable and consistent devices/results.

Channel statistics

It'd be interesting / useful if the debug output included the total number of packets captured on each channel and/or the channel of the last packet

2.47f problems

I seem to be getting a lot of missed packets on 2.47f, it usually happens after being powered on for some time and then will drop off.

sProcessing Status Command
xBridge v2.47f
dex_tx_id: 6840542 (6GQ6X)
initialised: 0, sleep_ble: 1, dont_ignore_ble_state: 1, xBridge_hardware: 1, send_debug: 1, do_leds: 1
dex_tx_id_set: 1, got_packet: 0
battery_capacity: 93
current ms: 10642037
10905792 - start is 10905792, waiting for packet on channel 1 for 500
10906292 - start is 10906292, waiting for packet on channel 2 for 500
10906792 - start is 10906792, waiting for packet on channel 3 for 500
10907292 - missed a packet, resetting channel offset to default
10907292: sending beacon Now
10907292 - send_data ▒▒`h (7)
10907293 - send_data blocked on uart1 input
Sending: ▒▒`h
Response: 10907299 - start is 10907299, waiting for packet on channel 0 for 298510
11205809 - start is 11205809, waiting for packet on channel 1 for 500
11206309 - start is 11206309, waiting for packet on channel 2 for 500
11206809 - start is 11206809, waiting for packet on channel 3 for 500
11207309 - missed a packet, resetting channel offset to default
11207309: sending beacon Now
11207309 - send_data ▒▒`h (7)
11207310 - send_data blocked on uart1 input
Sending: ▒▒`h
Response: 11207316 - start is 11207316, waiting for packet on channel 0 for 298510

This is against the latest 2.47f wixel file.

Restarting does seem to fix it temporarily, the times it was waitinng on the channels didnt really correspond to the 5 minute interval it should have been receiving it at, was about a minute or 2 out

HM11 range issue

Good morning, I assembled the xbridge, my version is like the Chris Bothello’s HM-11 board, just with a different battery (Lithium Ion Cylindrical Battery - 3.7v 2200mAh), my main issue is the range of the bluetooth module, even if I keep it like less than a meter far from me, mostly when I'm in bed it always miss readings, last night it missed reading fo like an hour.
Is there any way to increase the range?
I also have another problem, sometimes the red led of wixel keeps blinking and my battery stand much less than it should.

Do you have any advice for me?

Thank you in advance.

Never sleep xbridge

Good morning from Spain. My xbridge works fine for a while and suddenly starts to lose readings and there is no way to make it work (I have to "forget device", reboot xbridge, and restart all the "bluetooth scan" process again and, If I'm lucky, it works again)
I've been reading several old post and they talk about a "never sleep" mode to prevent the xbridge from sleeping and this way keep the bluetooth up and running (I tried with B option in Wixel command line but it doesn't seem to work. I don't know if the bluetooth module is a jnhuamao original but I updated it to the last firmware version from its page, HM10-v603). Is it possible to post a xbridge2.wml that is always on (as the xdrip)? Or tell me the files I have to change and I can compile it. Can I install xdrip firmware in xbridge?
Thank you so much for your help
Kind regards

Simplified circuit

Good morning. Probably it has nothing to do with the new circuit (as far as I know the only modification is the connection between P1_2 an State). In xbridge 2.43 to 2.47d I have no problems with sleeping and wake up, but the wixel takes two minutes to sleep after sending a package to the phone: "waiting for ack" From 2.47e to 2.48b xbridge loses packages and doesn't wake up as expected, but it always sleeps after sending a package and receiving the ack from the phone. Could it have something to do with the new circuit? Should I remove the State wire?
As always, thank you so much for your work and help
Regards

Edit: probably it has to do with my previous issue...

DexSim

Hi, I'm building a rig for my niece and want to test it, but I don't have the G4 here. I'm trying to use the dexsim program to simulate the G4. What program do you recommend for use with dexsim? I see there is dex-drip, dexbridge, xBridge, dexterity_wixel and radio_snifer. Would they all work? Right now I'm just trying to see the data from dexsim through a USB connection to my terminal program. I've run the test_tx and test_rx on each wixel and viceversa. The packets are getting across.

I do have 2 Wixels, and I'm very familiar with microcontrollers and computer programming.

Thanks,
Denis.

waitDoingServices does not work with break flag

Giving the break_flag to waitDoingServices apparently doesn't have any effect - it will always wait for the full timeout. Passed by value? Passing by reference is apparently not possible with SDCC.

Type of resistor for xBridge2

Hi John,

regarding to this link

https://github.com/StephenBlackWasAlreadyTaken/xDrip/blob/gh-pages/hardware_setup.md

1/4w 1K Ohm and a 1/4w 2.2K Ohm resistor should be used.

But you mentioned in the xBridge2 PDF 27k and 10k resistors...

What type are you prefer for the xBridge2 hardware setup?

Thanks, Matthias

Issue with BT Module HM-10

Hi all,

after soldering the modules and uploading the 2.47 xBridge on the Wixel by the utility, I got no signals from the BT module (HM-10).

What I get from Putty is what you can see on the 1st pic. If I try to upload the 2.0 xBridge version Putty becomes unresponsive.

Any help on this? It's the second time I try to solder the kit and get the same results. On the specs the BT module seems to be fine.

Thanks
Samuele

Delay Calculations

In the xBridge2.c file, line 1724 you have this code:
if(delay)
{
delay - (channel*500);
}

Is it supposed to be "delay -= (channel*500)"? (added the "-=" instead of "-")
Should this be taken out since it looks like it's been running without it anyway? Since no change to delay is happening?

Thanks,
Denis.

Shorter battery life by using a voltage divider (27k/10k - xDrip classic/xBridge2 firmware)

I would like to know the influence of the voltage divider with regard to the battery life.

I not really noticed a shorter battery life with my 1100mAh Lipo (it runs for 3.5 days), but I have been experiencing with a 250mAh Lipo a battery life reduction of 40 percent when using the 27k/10k voltage divider.

I am running xDrip classic soldering with the xBridge2.wxl

Can anyone tell similar issues or behavior?

I have been modified these values in xBridge2.c

define BATTERY_MAXIMUM_CLASSIC (1814)

define BATTERY_MINIMUM_CLASSIC (1416)

Any help or advice will be appreciated!

Cheers,
Matthias

Wixel SDK make errors

Hi, I just downloaded your project and recompiled the wixel SDK.
I'm on OSX Yosemite and installed sdcc using brew.
I had a few errors which I "resolved", now I'm going to try if the apps so "patched" really work too :-)
I put here the errors signaled and what I did to complete the "make" process.
I wonder if you get the same problems, I'm starting clean, so everything is compiled.

---

MBP-di-Daniele:wixel-sdk dgariboldi$ make
Compiling apps/adc_test/adc_test.rel
Compiling libraries/src/radio_com/radio_com.rel
Creating libraries/lib/radio_com.lib
Compiling libraries/src/radio_link/radio_link.rel
Creating libraries/lib/radio_link.lib
Compiling libraries/src/radio_mac/radio_mac.rel
Creating libraries/lib/radio_mac.lib
Compiling libraries/src/radio_registers/radio_registers.rel
Creating libraries/lib/radio_registers.lib
Compiling libraries/src/random/random.rel
Compiling libraries/src/random/random_from_adc.rel
Compiling libraries/src/random/random_from_sernum.rel
Creating libraries/lib/random.lib
cp libraries/src/uart/core/uart.c libraries/src/uart/uart0.c
Compiling libraries/src/uart/uart0.rel
cp libraries/src/uart/core/uart.c libraries/src/uart/uart1.c
Compiling libraries/src/uart/uart1.rel
Creating libraries/lib/uart.lib
Compiling libraries/src/usb/green_led.rel
Compiling libraries/src/usb/usb.rel
Creating libraries/lib/usb.lib
Compiling libraries/src/usb_cdc_acm/usb_cdc_acm.rel
libraries/src/usb_cdc_acm/usb_cdc_acm.c:355: error 98: conflict with previous definition of 'usbComRxReceive' for attribute 'type'
from type 'void function ( const-unsigned-char xdata* fixed, unsigned-char fixed) fixed'
to type 'void function ( unsigned-char xdata* fixed, unsigned-char fixed) fixed'
make: *** [libraries/src/usb_cdc_acm/usb_cdc_acm.rel] Error 1
MBP-di-Daniele:wixel-sdk dgariboldi$

---

-- modified usb_cdc_acm.c to have the same signature as in usb_com.h

---

Linking apps/dexsim/dexsim.hex

?ASlink-Warning-Undefined Global '___sdcc_isdigit' referenced by module '_atof'
make: *** [apps/dexsim/dexsim.hex] Error 1

---

-- bug http://sourceforge.net/p/sdcc/bugs/2295/ I update sdcc to HEAD which means version 3.5.4 #9306

---

Compiling apps/dexsim/dexsim.rel
apps/dexsim/dexsim.c:752: error 226: no type specifier for '(cast)'
make: *** [apps/dexsim/dexsim.rel] Error 1

---

-- modified memcpy(&flash_settings, (__xdata *)FLASH_SETTINGS, sizeof(flash_settings));
-- to memcpy(&flash_settings, (uint8 XDATA *) FLASH_SETTINGS, sizeof(flash_settings));

---

Compiling apps/joystick/joystick.rel
apps/joystick/joystick.c:140: error 78: incompatible types
from type 'char xdata* xdata'
to type 'int generic* pdata'
apps/joystick/joystick.c:142: error 78: incompatible types
from type 'char xdata* xdata'
to type 'int generic* pdata'
apps/joystick/joystick.c:144: error 78: incompatible types
from type 'char xdata* xdata'
to type 'int generic* pdata'
apps/joystick/joystick.c:146: error 78: incompatible types
from type 'char xdata* xdata'
to type 'int generic* pdata'
apps/joystick/joystick.c:148: error 78: incompatible types
from type 'char xdata* xdata'
to type 'int generic* pdata'
apps/joystick/joystick.c:150: error 78: incompatible types
from type 'char xdata* xdata'
to type 'int generic* pdata'
make: *** [apps/joystick/joystick.rel] Error 1

---

-- removed from apps the joystick app

---

Compiling apps/shiftbrite/shiftbrite.rel
apps/shiftbrite/shiftbrite.c:127: error 2: Initializer element is not constant
apps/shiftbrite/shiftbrite.c:128: error 2: Initializer element is not constant
apps/shiftbrite/shiftbrite.c:129: error 2: Initializer element is not constant
make: *** [apps/shiftbrite/shiftbrite.rel] Error 1

---

-- removed from apps the shiftbrite app

---

Compiling apps/xBridge2/xBridge2.rel
apps/xBridge2/xBridge2.c:1716: warning 212: support for large long long literals is incomplete
apps/xBridge2/xBridge2.c:1716: warning 212: support for large long long literals is incomplete
allocated more than 4 or 0 registers for type longlong-int fixed
allocated more than 4 or 0 registers for type longlong-int fixed
allocated more than 4 or 0 registers for type longlong-int fixed
allocated more than 4 or 0 registers for type longlong-int fixed
allocated more than 4 or 0 registers for type longlong-int fixed
allocated more than 4 or 0 registers for type longlong-int fixed
apps/xBridge2/xBridge2.c:1800: error 226: no type specifier for '(cast)'
make: *** [apps/xBridge2/xBridge2.rel] Error 1

---

-- modified memcpy(&settings, (__xdata *)FLASH_SETTINGS, sizeof(settings));
-- to memcpy(&settings, (uint8 XDATA *)FLASH_SETTINGS, sizeof(settings));

---

Compiling apps/xBridge3/xBridge3.rel
apps/xBridge3/xBridge3.c:1710: warning 212: support for large long long literals is incomplete
apps/xBridge3/xBridge3.c:1710: warning 212: support for large long long literals is incomplete
allocated more than 4 or 0 registers for type longlong-int fixed
allocated more than 4 or 0 registers for type longlong-int fixed
allocated more than 4 or 0 registers for type longlong-int fixed
allocated more than 4 or 0 registers for type longlong-int fixed
allocated more than 4 or 0 registers for type longlong-int fixed
allocated more than 4 or 0 registers for type longlong-int fixed
apps/xBridge3/xBridge3.c:1794: error 226: no type specifier for '(cast)'
make: *** [apps/xBridge3/xBridge3.rel] Error 1

---

-- modified memcpy(&settings, (__xdata *)FLASH_SETTINGS, sizeof(settings));
-- to memcpy(&settings, (uint8 XDATA *)FLASH_SETTINGS, sizeof(settings));

---

Compile OK (I get only the above non blocking warnings)

Lock on 2.47e

Had an instance of 2.47e where I'm not getting any data for over an hour

Using a hm-10, restarting phone has no effect and BT led indicates there is a bluetooth connection.

Logs as follows

sProcessing Status Command
xBridge v2.47e
dex_tx_id: 6840542 (6GQ6X)
initialised: 0, sleep_ble: 1, dont_ignore_ble_state: 1, xBridge_hardware: 1, sen d_debug: 1, do_leds: 1
dex_tx_id_set: 1, got_packet: 0
battery_capacity: 81
current ms: 512082207

sProcessing Status Command
xBridge v2.47e
dex_tx_id: 6840542 (6GQ6X)
initialised: 0, sleep_ble: 1, dont_ignore_ble_state: 1, xBridge_hardware: 1, sen d_debug: 1, do_leds: 1
dex_tx_id_set: 1, got_packet: 0
battery_capacity: 81
current ms: 512144307

sProcessing Status Command
xBridge v2.47e
dex_tx_id: 6840542 (6GQ6X)
initialised: 0, sleep_ble: 1, dont_ignore_ble_state: 1, xBridge_hardware: 1, sen d_debug: 1, do_leds: 1
dex_tx_id_set: 1, got_packet: 0
battery_capacity: 81
current ms: 512253643
512342872 - start is 512342872, waiting for packet on channel 1 for 500
512343372 - start is 512343372, waiting for packet on channel 2 for 500
512343872 - start is 512343872, waiting for packet on channel 3 for 500
512344372 - missed a packet
512344372: sending beacon Now
512344372 - send_data ▒▒h (7) 512344372 - send_data blocked on uart1 input Sending: ▒▒h
Response: 512344378 - start is 512344378, waiting for packet on channel 0 for 29 8510

sProcessing Status Command
xBridge v2.47e
dex_tx_id: 6840542 (6GQ6X)
initialised: 0, sleep_ble: 1, dont_ignore_ble_state: 1, xBridge_hardware: 1, send_debug: 1, do_leds: 1
dex_tx_id_set: 1, got_packet: 0
battery_capacity: 81
current ms: 512463366

It seems to never be getting the packet and continues to be able to respond to status commands so it's not going into sleep.

Android 10 and xBridge compatibility

Have not found anything useable about this: I heard and read about issues when Android 8 was released in combination with the xBridge (packet and connection losses). Is there a similar issue with Android 10 as it has been working perfectly with Android 9?

Power requirements - sleeping?

I just measured the current actually drawn by the xBridge2 setup without voltage divider.
After boot while waiting for the first packet, it draws an almost constant 35mA.
Once a packet has been detected and sent to the phone, the orange LED is disabled (so no LEDs are on at this point) and BLE is disconnected (according to phone).
In this state, it still draws 10mA from the battery with current code (xBridge v2.42).
Status:
xBridge v2.42
dex_tx_id: 0123456 (XXXX)
initialised: 0, sleep_ble: 1, dont_ignore_ble_state: 1, xBridge_hardware: 1, send_debug: 0, do_leds: 1
Any idea what might be going on while the wixel should be sleeping?

Lipo Fuel Gauge

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

No power when connected to lipo

I've wired it all up as per the pdf, however I haven't got the voltage resistors.

BAT and GND connect directly to VIN and GND on the wixel, for some reason the wixel doesn't appear to be powering on at all when the code is loaded, if i plug the wixel in via usb it powers up correctly and works as its supposed to.

I've tried multiple batteries,wixels and lipo boards, is there something I'm missing? Even with usb power plugged directly into the lipo board it doesnt work.

If I erase the wixel and just try to run it via battery the LEDs light up, so at a guess it would seem like the app is modifying how the power gets to the board?

Any help would be great.

Cheers

xBridge2.wxl invalid data in file error No.2

Hi! First, Jstevensog thank you on your great work!
I have the same issue today with latest 2.47e trying to write it to wixel.
When I try to open the .wxl app the Pololu Wixel Config Utility says exactly the same:
Invalid data in file.
App File could not be opened: xBridge2.wxl
I am using RPi - Raspbian (all latest updates) to do that. As a note: other .wxl files (for example jamorhams wixel-xDrip..) are opening without a problem.
I tried to download through cli using git , tried to download as zip file and than extract it on RPi, tried to do the same on Win and then transfer the file to RPi using Samba etc... Always the same error when I try to open wxl in the Wixel Utility.
Is there any solution for this?
I saw the closed issue #16 but can not reopen it so I am opening this as a new issue No.2. Apologies if this is not appropriate, please correct me if I am wrong.

EDIT1: Using Notepad++ I changed newline (line ending) from CR+LF combination in the .wxl file to pure LF and now reading the app works just fine also on RPi.

2.47e does not work

I flashed 2.47e on my wixel, but this version does not work properly. The HM-10 connects to my phone, the yellow led on my the wixel is on, and the red one is blinking four(!) times then it pauses and again blinking four times and so on.
With 2.47d it works actually fine, but often it doesn't recover from signal drops and it needs to be reset.

Not sending Beacon packet on Waking

The current dexbridge2 code does not always send a beacon on wixel waking. This is not a huge issue until someone changes their transmitter before setting their Transmitter ID. Need to fix this.

Android 9 and xBridge compatibility

Have not found anything useable about this: I heard and read about issues when Android 8 was released in combination with the xBridge (packet and connection losses). Is there a similar issue with Android 9?

xBridge2 (lastest code from 07/20/2015) sudden signal gaps

Hi John,

I have been soldering new componts for xBridge2 (accoring the xBridge2.pdf) using the lastest code provided yesterday. Unfortunately I have sudden signal gaps.

I have very good soldering experiences, all solder joints look very good to me.

I have been running a xDrip Experimental box (different hardware) since 6 weeks without any gaps.

My setup consists of:
HM-10 (version 540) from

http://www.ebay.de/itm/New-HM-10-CC2540-4-0-BLE-Bluetooth-to-UART-Transceiver-Module-Central-Peripheral-/390879063376?pt=LH_DefaultDomain_77&hash=item5b02352d50

Sony xperia E1 Android 4.4.4

Pololu Wixel

https://www.pololu.com/product/1336

Here you can see all componets temporarily placed in this open box due to testing purpose. Always the green box is very close to the Dex sensor/transmitter.

I would be very happy to have to stability of "dexdrip.c" which is used for xDrip Experimental.

Thanks for your assistance John!

Greeting from Germany,
Cheers

Matthias

Can anyone help me to build WXL file for 6AAPN

Can anyone help me to build WXL file for 6AAPN

[email protected]

Need flash stored flag to indicate HM-1x has been set up.

Currently, every time the dexbridge is powered on, it sets up the HM-1x with a name and some other parameters, then restarts it. This takes significant time, and only really needs to be done once.
Add a Byte that can be stored in flash. This will be used to indicate (bit 0 = 1) that the HM-1x needs to be configured, and will be saved to flash (bit 0 = 1) when it has been.
This will make start up time much faster. Byte can also be used for other uses (turn LEDs on for diagnostics?), but the Beacon packet will need to change to include it.

how was the maximum_battery and min batt calculated

Hello.. I have a question on these two lines:

define BATTERY_MAXIMUM (1771)

define BATTERY_MINIMUM (1416)

Is it 1771 mVolt? and how did you calculate it?