2.47f problems

[danpowell88]

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

[jstevensog]

Hi Daniel, Sorry for the delay in replying. This is very strange indeed. I have 2.47f running on 3 different bridges, one being my prod bridge and it has been even more solid than v2.47e on packet capture, and absolutely no bridge lock up since I put it in service. It might be that I have inadvertently "tuned" the defaults to my transmitter, so I will try and test two of the bridges with another transmitter. But that really shouldn't be the case. I have adjusted the first channel carrier frequency only marginally to bring the default channel offsets closer to 0. The first packet on each channel captured from my prod transmitter shows the adjustment just fine, and from then on tracks very well. Of course, this is mostly channel 0. I just checked that the .wxl in the v2.47f branch is correct, so I haven't mistakenly uploaded a potential dud version. Will try and check this out today. Cheers

…

On Wed, Oct 25, 2017 at 10:49 AM, Daniel Powell ***@***.***> wrote: 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. Watching the logs I can see that its not even doing any activity at all 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 This is against the latest 2.47f wixel file. Restarting does seem to fix it temporarily — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#32>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIQs8xN5crOSn6FTEMab9XRMpU2e7-KSks5svneIgaJpZM4QFPzm> .

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

[danpowell88]

Yeah was really weird, I have since switched back to e and everything seems fine, I had to delete and reinstall xdrip completly due to some other issues but I doubt that would effect the scanning stuff seen here.

Another thing that may just be due to my phone is it seems the BT connection isn't being closed as quickly.

[old-square-eyes]

I think I'm also getting this issue. #37

[danpowell88]

I had the fitbit app installed on my phone and I did notice a strong correlation of my BT connection improving once i deleted it, since then almost no dropped packets (due to BT connection).

Haven't noticed any weird scanning irregularities since either, although that wouldn't be effected by the fitbit app

[old-square-eyes]

I have a few other BT parings, but not Fitbit. I'll remove them all as a precaution.

[danpowell88]

Interestingly enough I didnt even have the fitbit paired (returned it to the store) but the app was somehow interrupting the BT stack it would seem

[old-square-eyes]

I updated my other issue. I disconnected Putty and serial USB and got subsequent readings.

[jstevensog]

I have had issues on my pixel 2 with pairings. Every power cycle, or BT off/on makes the phone forget the pairing, even though xDrip indicates is still valid. And sometimes other BT devices cause the pairing to break somehow. Never had these issues with marshmallow. Still, once I am permanently on xDrip+ I might be able to investigate more. Cheers

…

On 12 Feb. 2018 09:30, "old-square-eyes" ***@***.***> wrote: I updated my other issue. I disconnected Putty and serial USB and got subsequent readings. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#32 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIQs83d2cOPy80rGSHstXhLaxnDFy_dXks5tT2n7gaJpZM4QFPzm> .

[old-square-eyes]

Hmmm. I seem to be experiencing the need to forget and rescan for the bridge on every bridge power cycle too. Will do a few tests to verify.

Edit: Just power cycled and didn't have to reconnect that time.

[jstevensog]

Does the BLE name go back to defaults? Are you using a hm-16/18? Cheers

…

On 14 Feb. 2018 12:51, "old-square-eyes" ***@***.***> wrote: Hmmm. I seem to be experiencing the need to forget and rescan for the bridge on every bridge power cycle. Will do a few tests to verify. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#32 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIQs8zqYKlvD8X6EcZAeP4s0HASjEzdDks5tUjwFgaJpZM4QFPzm> .