No simple recovering from sudden missing signals

[ghost]

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

[jweismann]

It should be mentioned that for version 2.47 of the xbridge2 code, there is no yellow LED
turned on when the problem arise. Also Connection status become: 'Not connected' and
restart collector does not change this, i.e. it seems that the phone and the rig become
totally disconnected for version 2.47 but not for 2.33. Maybe this would be useful
information to you.

Thanks, Jacob

[savek-cc]

@nan4kam one possibility could be a fragile RX/TX/Pwr wire from wixel to hm11 on the RnotOK. So if you shake it at the wrong moment, the data exchanged between wixel and hm11 goes bad and it's unable to recover?

[jweismann]

Thanks, savek-cc. I did re-inspect but none of them appear fragile.

And an update: I decided to build a third rig (my last wixel) to see if I could reproduce the problem. This time with HM10 since I had no more hm11 spares nor did I have a spare battery so I reused the one from RNotOK and believe it not, I can reproduce the problem with a new wixel, a new hm10 and a new recharger but the same battery so I now suspect that the battery constitutes the fragile part. Thus, will try to order some new batteries in the nearest future and see if both spare rigs then start to function properly.

Cheers, Jacob

[jstevensog]

HI All, Sorry for the long delay in responding. I have been travelling and not able to regularly answer mail. nan4kam, can you please tell me the versions of xBridge2 you are running on ROK and RnotOK? I am running the latest 2.47 code on my production bridge and it runs fine for more than 24 hours. Whilst I have been travelling, I have had instances where a prolonged "black out" period has occurred. I am not certain if the issue is the standard Android BLE problem, or if the latest code has an as yet undetected bug in the sleep function. As it has otherwise performed very well for days at a time, I am going over the sleep code to see if I can identify a potential bug. But it is difficult, as the sleep mode when the wixel is connected to USB is different to when it is not. But if you are running the same xBridge version on both wixels, my suspicion is that the RnotOK wixel is likely the issue. I would suggest leaving it plugged into a computer and monitoring the output for a while (I understand you can't be near a computer for 24 hours) to see if the issue occurs. Cheers

…

On Sat, Jul 8, 2017 at 7:51 AM, jweismann ***@***.***> wrote: Thanks, savek-cc. I did re-inspect but none of them appear fragile. And an update: I decided to build a third rig (my last wixel) to see if I could reproduce the problem. This time with HM10 since I had no more hm11 spares nor did I have a spare battery so I reused the one from RNotOK and believe it not, I can reproduce the problem with a new wixel, a new hm10 and a new recharger but the same battery so I now suspect that the battery constitutes the fragile part. Thus, will try to order some new batteries in the nearest future and see if both spare rigs then start to function properly. Cheers, Jacob — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#26 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIQs846DqNSdPXAdVBvZQXrZZsucICDUks5sLqhQgaJpZM4OLjAW> .

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

[jweismann]

Hi Steven

No worries. I tried v2.33 on ROK and I tried both V2.33 and v2.47 on RnotOK. With ROK, I have no problems. With RnotOK, I see the same issues with V2.33 and V2.47 but now that you bring it up, it once reproduced itself quicker on V2.47 (i.e. after a few hours only) but only once. I have done the test several times both with 2.33 and 2.47 and the problem is indeed reproducible with both.

I build a third rig (installed v2.33 on that), RmaybeOK, to see if I could reproduce problems with that and at first I had problems but found that they related to a fragile battery (Murphy's law). Then I did the tests again with a new battery and RmaybeOK has worked for more than a week now so I now have a spare rig again and feel more comfortable.

For RmaybeOK, I used the same charger and the same working battery as I used for RnotOK but I used a new HM10 and a new wixel.

I suspect that it's my wixel on RnotOK that is unreliable. I can still communicate with HM11 on RnotOK when it enters the state of no return and that's why I tend to believe that the wixel is broken.

Thanks again for your suggestions and your great contributions on this project.

Cheers, Jacob

[Empyyy]

Hello everyone. Thank you Steven for your great job.
I'll add some information about this problem. For the past 1.5 years I am builded about 200 xDrip's for my friends. All of this based on identically hardware and packed in the same cases. About past half a year I'm used 2.46 firmware. And I have the 2 same problems on all of it:

1. When the signal is missing some of xbridges can find it within 10 minutes. But some of it cannot get the data pocket from transmitter until I reboot the xbridge and it gets the measurement within 5 minutes.
2. Some of xbridges (about 5-10%) having constantly missing signal. When i replacing it with the new Wixel it gets working well. So the problem may be in wixel board. But 5-10% of defect is too much!

All of this problems occur when the xbridge in the 0-4m range from transmitter.
Please tell me if I can help you for debugging. I have big experience in building this device.
Best regards

[jstevensog]

Hi Empyyy, Unfortunately, the 5-10% of wixels not behaving sounds about right. I believe that the crystals they use are not so stable. The new 2.47d branch code in my repo may help with this, as it changes how the wixel sleeps between packets. But if it is the radio crystal that is causing the issue it will not. On item 1, I have never had to reboot my production bridge running 2.46 at all. It ran since release until I released 2.47 in June without any issues. v2.47 DOES have a bug that causes the wixel to stay asleep. I am fairly sure this is resolved in v2.47d, but I am waiting a while for the people beta testing, and my own production bridge, to confirm. If you try 2.47d, keep in mind it is still beta code. It still has a couple of issues I am trying to improve on, but will likely be released next week. It is at https://github.com/jstevensog/wixel-sdk/tree/v2.47d/apps/xBridge2 . On item 2, this is just a fact of using the wixels. We have had reports of wixels that are just not reliable. Occasionally they have batches like this, and it is usually the sleep function that is unstable due to low quality components. It is a pity that the wixel quality control is not great. But keep in mind it is meant for experimenters, not for a medical device. They are cheap because they do not use the low tolerance components required for accuracy. I am looking at creating a board with everything we need on it, so that I can specify the quality of components, and open sourcing the circuit, board, and bill of materials specifying components and tolerances so that anyone can get numbers of the built at fabrication houses worldwide. But that will be a long way off. OK, to help debug the issue, I need to know the following things when the wixels stop working: 1) Are the wixels constantly awake and are they waiting for packets? You will need the LEDs turned on to see this. The yellow LED should be solid (BLE Connected) and the red LED should be flashing, and it should stay this way for more than 5 minutes. 2) Can you please tell me what BLE modules you are using and where you sourced them? In other words, are they genuine JNHuaMao HM-1x modules? Some BLE modules can interfere with the CC2511 receiver if they are not good quality. It is why I specify that you use the genuine JNHuaMao versions, as I have had good experience with them. Some have failed in rather strange ways, but most work fine. Hope this helps. Cheers

…

On Sat, Aug 26, 2017 at 2:10 AM, Empyyy ***@***.***> wrote: Hello everyone. Thank you Steven for your great job. I'll add some information about this problem. For the past 1.5 years I am builded about 200 xDrip's for my friends. All of this based on identically hardware and packed in the same cases. About past half a year I'm used 2.46 firmware. And I have the 2 same problems on all of it: 1. When the signal is missing some of xbridges can find it within 10 minutes. But some of it cannot get the data pocket from transmitter until I reboot the xbridge and it gets the measurement within 5 minutes. 2. Some of xbridges (about 5-10%) having constantly missing signal. When i replacing it with the new Wixel it gets working well. So the problem may be in wixel board. But 5-10% of defect is too much! All of this problems occur when the xbridge in the 0-4m range from transmitter. Please tell me if I can help you for debugging. I have big experience in building this device. Best regards — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#26 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIQs85etGHGTA6obUuKJfRXHSu8_rQ9Rks5sbvIQgaJpZM4OLjAW> .

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

[Empyyy]

Thank for your answer.

1. Yes, wixels are waiting for the pockets. It can wait for a long time (upward 10 minutes). Then it usually gets the data pocket from transmitter. But if I reboot the system it gets the pocket within 5 minutes.
2. I'm using this one https://www.aliexpress.com/item/HM-10-cc2541-4-0-BLE-bluetooth-to-uart-transceiver-Module-Central-Peripheral-switching-iBeacon-AirLocate/32460585727.html?spm=a2g0s.9042311.0.0.lMNrN7

[jstevensog]

Hi Empyyy, 1) Yes, that is actually normal. A single packet miss will usually take up to the next packet (so, a 10 minute gap, as packets are only transmitted every 5 minutes) before a reading will be seen again. 2) I cannot tell if these are genuine JNHuaMao HM-10 modules. There are a lot of copies out there. I would recommend purchasing them from Fasttech and specifying genuine JNHuaMao modules. They did one time send me copies, but once I pointed that out, the sent real ones at no extra cost. Try the beta code of v2.47d. I believe it will work much better for you. Cheers

…

On Sat, Aug 26, 2017 at 9:33 PM, Empyyy ***@***.***> wrote: Thank for your answer. 1. Yes, wixels are waiting for the pockets. It can wait for a long time (upward 10 minutes). Then it usually gets the data pocket from transmitter. But if I reboot the system it gets the pocket within 5 minutes. 2. I'm using this one https://www.aliexpress.com/ item/HM-10-cc2541-4-0-BLE-bluetooth-to-uart-transceiver- Module-Central-Peripheral-switching-iBeacon-AirLocate/ 32460585727.html?spm=a2g0s.9042311.0.0.lMNrN7 <https://www.aliexpress.com/item/HM-10-cc2541-4-0-BLE-bluetooth-to-uart-transceiver-Module-Central-Peripheral-switching-iBeacon-AirLocate/32460585727.html?spm=a2g0s.9042311.0.0.lMNrN7> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#26 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIQs8yjQPXuxoSJUe5a7Bnt6AG2eLIu6ks5scAKIgaJpZM4OLjAW> .

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