xBridge Gets one reading then fails - Sleep seems to happen even when disabled. #37
Comments
old-square-eyes
changed the title
Open
|
OK I disconnected Putty and the data USB and seem to have gotten my second and third packets and was able to calibrate. Seems that something goes wonky on the serial com when left connected. |
|
Nope. Worked fine for a few hours then 30 minutes missed readings. Power cycle brought it back online. Not sure I can capture the debug output without breaking it too. Now I can't even connect. really not sure what's happening. |
|
Bask on the S5 now. I get a recurring xDrip+ log "SetSerialDataToTransmitterRawData: TXID wrong. Expected 6553988 but got 0" |
|
I got a call on my other (non xBridge) mobile, which was paired to a BT speaker. This broke the BT connection and I suddenly got a packet on my dev xBridge phone, and every packet after. It's such a coincidence but maybe my main phone was blocking my dev phone from pairing properly with the xBridge. I had it connected a couple of days ago, but had gracefully "forgot" the bridge before switching it out. |
|
Ok. That's weird. The output thinks that there is inbound data, hence the
send is blocked. Sleeping with BLE always on had been tested to death. I'll
fire up one of my Dev bridges tomorrow and loaf the .wxl from git and see
if I can find any issues.
…On 12 Feb. 2018 08:18, "old-square-eyes" ***@***.***> wrote:
I'm having a hard time getting readings. I've tried a stock Galaxy S8 and
Lineage 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.
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
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#37>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AIQs87gXDHhhnqnAViV0-BftdvjbxL2cks5tT1kpgaJpZM4SBgup>
.
|
|
That is all very strange. BLE pairing shouldn't do this. Though that said,
I always power cycle the bridge of dealing between prod and dev to make
sure the hm-1x forgets the pairing.
…On 13 Feb. 2018 14:53, "old-square-eyes" ***@***.***> wrote:
I got a call on my other (non xBridge) mobile, which was paired to a BT
speaker. This broke the BT connection and I suddenly got a packet on my dev
xBridge phone, and every packet after. It's such a coincidence but maybe my
main phone was blocking my dev phone from pairing properly with the bridge.
I had it connected a couple of days ago, but had gracefully "forgot" the
bridge before switching it out.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#37 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AIQs84gZfc32VJWdLxT0MH4V5Gp3ykszks5tUQccgaJpZM4SBgup>
.
|
|
OK, I think I see the sleep_ble issue. sleep_ble=0 only stops the HM-1x
from being depowered when the wixel goes into sleep mode. It doesn't stop
the wixel from sleeping. Big difference.
Also, I have had lots of issues with one of my USB ports when the wixel
sleeps. It breaks the connection to PuTTY. Every single time. The other
USB port has no issue.
This is probably something to do with the wixel driver. I will try and get
hold of the latest and give it a whirl.
Cheers
…On Tue, Feb 13, 2018 at 10:38 PM, John Stevens ***@***.***> wrote:
Ok. That's weird. The output thinks that there is inbound data, hence the
send is blocked. Sleeping with BLE always on had been tested to death. I'll
fire up one of my Dev bridges tomorrow and loaf the .wxl from git and see
if I can find any issues.
On 12 Feb. 2018 08:18, "old-square-eyes" ***@***.***> wrote:
> I'm having a hard time getting readings. I've tried a stock Galaxy S8 and
> Lineage 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.
>
> 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
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <#37>, or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AIQs87gXDHhhnqnAViV0-BftdvjbxL2cks5tT1kpgaJpZM4SBgup>
> .
>
--
John Stevens
"You are how you live, not what you have."
|
|
I've been using my G4 again and this error |
|
So, it seems that the wixel has overwritten the TXID value in RAM, and
perhaps flash. Is this message in response to a DATA packet from the wixel
or a BEACON packet? Either way, xDrip should be sending back a TXID packet
to the bridge to set the ID correctly, which should fix the issue. That's
how it works on all of mine.
So, a reflash fixed the issue?
Cheers
…On Tue, Apr 3, 2018 at 8:52 AM, old-square-eyes ***@***.***> wrote:
Ive been using my G4 again and this error Bask on the S5 now. I get a
recurring xDrip+ log "SetSerialDataToTransmitterRawData: TXID wrong.
Expected 6553988 but got 0 has come up again in xDrip. No amount of
pairing/unpairing seemed to fix it. In the end I had to re-flash the Wixel.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#37 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AIQs87MKTIyy_3aWdyYqZ7LT4noohw71ks5tkqu5gaJpZM4SBgup>
.
--
John Stevens
"You are how you live, not what you have."
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The text was updated successfully, but these errors were encountered: