2.47e does not work

[AlexD97]

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.

[jstevensog]

Hi AlexD97, The RED LED blinking four times then pausing, then repeating means that the bridge has not yet received the Transmitter ID from xDrip/xDip+. Please "forget" the bridge, and scan for it again. When the bridge receives the the Transmitter ID, the RED LED will constantly blink once every second until a packet is captured. Please do not use 2.47d. Although there is no real difference with it and 2.47e as far as packet capture is concerned, I am only supporting the latest version. 2.47d fixed an issue where the bridge stayed in a sleep state. 2.47e added support for the HM-16/17 modules. The STATUS wire is no longer needed, as the module is communicated with using the serial connection. 2.47e is much more stable, has less power use, and prevents the Android BLE issue. One other has reported an issue with the bridge often requiring a reset. I am trying to investigate. I have had this happen only on 3 occasions with v2.47e myself. If it occurs again for you, can you please take note of the state of the LEDS, and if the bridge is staying asleep (no LEDS lit for more than 5 minutes), staying awake (YELLOW LED lit, RED LED blinking for more than 5 minutes), or if it is sleeping and waking (YELLOW LED lit, RED LED off or on solid for up to 2 minutes, No LEDS lit for up to 3 minutes) and let me know. Thanks in advance. Cheers

…

On Sun, Oct 8, 2017 at 5:49 AM, AlexD97 ***@***.***> wrote: 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. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#28>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIQs8_55oDxr9Zc11YDPeDzFYomriRl0ks5sp8fUgaJpZM4PxdDX> .

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

[AlexD97]

Hi jstevensog,

thank you for your answer. Unfortunately forgetting the device doesn't help. It is still waiting for the Transmitter ID from xDrip+.

[jstevensog]

Hi AlexD97, Then there is likely a break in connection between the HM-1x and the wixel on the serial line. To test this, load the usb_serial.wxl file onto the wixel, connect to it with a PuTTY or other terminal, and connect to the HM-1x using a BLE utility on the phone. I use BLE Scanner. View the Custom Service, Custom Characteristic, and make sure you have the BLE utility set up for Notifications (N is green in BLE Scanner). As you type keys on the keyboard they should appear in the Value property. If that is OK, then Write a string back to the wixel. It should appear on your terminal. In your case, one of these will likely fail. If it is the first one (no reception of the characters in the BLE utility), the issue will be in the P1_6 wire from the wixel to the HM-1x. If it is the second (no reception of the characters in the terminal display), the issue will be with the P1_7 wire to the wixel from the HM-1x. Wire breakage or poor connection can happen. If both tests pass, I would recommend using the usb_serial.wxl to issue an AT+ RENEW command to the HM-1x. It may be that the wixel has not been able to determine the baud rate of the module, and has defaulted to 9600, but your module is using a different baud rate. Hope this helps. Cheers

…

On Tue, Oct 10, 2017 at 1:18 AM, AlexD97 ***@***.***> wrote: Hi jstevensog, thank you for your answer. Unfortunately forgetting the device doesn't help. It is still waiting for the Transmitter ID from xDrip+. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#28 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIQs8_DaK_owxQ-ko1j2PiTRxqE8gLpRks5sqitFgaJpZM4PxdDX> .

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

[AlexD97]

Hi jstevensog,

the wixel passed both tests.
I tried to issue an AT+RENEW command but it didn't respond anything. Also the HM-10 doesn't respond to AT+SBLUP (but to AT it responds OK).
Regards

[jstevensog]

Hi AlexD97, Make sure that the HM-10 is NOT connected to any BLE app (including xDrip+) when you issue AT+RENEW. If this still does not work, then your HM-10 is not a genuine one, and this would explain why v2.47e is less reliable on your rig. v2.47e requires the module to respond to AT with an OK+LOST when a connection is active. Previous versions relied on the STATUS line to know if a connection was active or not. If this is the case, stay with v2.47d until you can get hold of a genuine JNHuaMao HM-10/11 or HM-16/17 module. There is no other difference between these two versions other than the support for the HM-16/17 modules. Cheers

…

On Wed, Oct 11, 2017 at 1:20 AM, AlexD97 ***@***.***> wrote: Hi jstevensog, the wixel passed both tests. I tried to issue an AT+RENEW command but it didn't respond anything. Also the HM-10 doesn't respond to AT+SBLUP (but to AT it responds OK). Regards — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#28 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIQs85QPL1z_f4M-Ob6OmFfSCrHOkV1Dks5sq302gaJpZM4PxdDX> .

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

[AlexD97]

Hi jstevensog,

thank you for your answer. It seems like my HM-10 is not a genuine device. Therefore I will pick another one and try it again.
Regards