Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Raspberry Multiple Connections creates issue on virtual bridge #2892

Open
Ziozanna opened this issue Dec 9, 2024 · 21 comments · May be fixed by #2895
Open

Raspberry Multiple Connections creates issue on virtual bridge #2892

Ziozanna opened this issue Dec 9, 2024 · 21 comments · May be fixed by #2895
Assignees
@cagnulein
Labels
bug Something isn't working

Comments

@Ziozanna
Copy link

Ziozanna commented Dec 9, 2024 •
edited
Loading

Describe the bug
Ciao Roberto

Bug encountered using the app in graphical mode on Raspberry Pi 3 B, with the power source connected to MyWhoosh or Zwift, using a heart rate strap and Zwift click.

Case 1: No heart rate strap nor Click connected. QZ recognizes Kickr Core and MyWhoosh instantly connects to QZ, and everything works as expected.
Case 2: Strap and click connected. QZ recognizes the strap, the click, and the Kickr, but MyWhoosh does not detect QZ. Occasionally, it detects it, but you remain stuck on the pairing screen.
Case 3: If QZ was still connected to MyWhoosh from the last session, it recognizes both the click and the strap, as well as the Kickr, but neither the strap's nor the click's data are displayed in QZ nether are sent to MW.

I’m attaching two logs in chronological order, with the oldest for Case 1 and the most recent for Case 2.

To Reproduce
as descibed in Case 1, 2 and 3

Expected behavior
QZ connect strap , Click and kickr and MYWHOOSH pair QZ with all devices connected

Screenshots
NA

Desktop (please complete the following information):

  • OS: Raspbian
  • Uname -a 6.6.62+rpt-rpi-v8 Heart rate #1 SMP PREEMPT Debian 1:6.6.62-1+rpt1 (2024-11-25) aarch64 GNU/Linux

Smartphone (please complete the following information):

Append a debug log
Logs in attach
debug-Mon_Dec_9_20_11_38_2024.log
debug-Mon_Dec_9_20_14_37_2024.log

Follow this guide https://github.com/cagnulein/qdomyos-zwift/wiki/How-do-i-get-the-debug-log-in-case-something-doesn't-work%3F

Additional context
Nice job mate
@Ziozanna Ziozanna added the bug Something isn't working label Dec 9, 2024
@cagnulein
Copy link
Owner

@Ziozanna are you sure the older log is about the case 1 where everything works? because in that log i don't see any connection to the virtual bluetooth bridge device of qz. Instead of in the 14_37 log i can see it. Maybe it's the opposite?

@Ziozanna
Copy link
Author

Good question, first I tried case 1 than case 2 .
Preatty sure
case 1 debug-Mon_Dec_9_20_11_38_2024.log
case 2 debug-Mon_Dec_9_20_14_37_2024.log
If this doesn't make sense I can do it again
Thanks

@cagnulein cagnulein changed the title [BUG] Raspberry Multiple Connections creates issue on virtual bridge Dec 10, 2024
cagnulein added a commit that referenced this issue Dec 10, 2024
@cagnulein
Raspberry Multiple Connections creates issue on virtual bridge #2892
2581783
@cagnulein cagnulein linked a pull request Dec 10, 2024 that will close this issue
Open
@Ziozanna
Copy link
Author

After the new build, out of 4 boots, 3 were successful and one was not. I did a lot of reboots without the heart rate monitor and it never failed once. After a few hours, I turned everything back on with the heart rate monitor and clicks active, and MW did not show up in the search for power sources. A reboot fixed it, and after that, I did an hour of training without any problems.
Here the log of last failing boot

@cagnulein
Copy link
Owner

Remember the log :)

@Ziozanna
Copy link
Author

i'm trying bug github fails. maybe it is my connection
Uploading debug-Tue_Dec_10_16_26_39_2024.log.txt…

@cagnulein
Copy link
Owner

Zip it before pushing it

@cagnulein cagnulein linked a pull request Dec 10, 2024 that will close this issue
Raspberry Multiple Connections creates issue on virtual bridge #2892 #2895
Open
@cagnulein cagnulein mentioned this issue Dec 10, 2024
Open
@Ziozanna
Copy link
Author

here the log zipped
debug-Tue_Dec_10_16_26_39_2024.zip

@cagnulein
Copy link
Owner

interesting, i don't see anything wrong here. can you upload also a working one from this build so i can compare them? thanks

@Ziozanna
Copy link
Author

Here you are, it is bigger because it is about 1 hour of training
debug-Tue_Dec_10_17_04_18_2024.zip

@cagnulein
Copy link
Owner

what i can see it's that when it works the virtual interface appears after 50 seconds from the startup of qz, instead when it doesn't it brings up after 66 seconds. if you want i can increase this timing just to check that the error will go away.

probably the best way will be sync the events of the connection of all the devices. anyway this patch is only to validate my thoughts about the culprit

@cagnulein
Copy link
Owner

here it's building https://github.com/cagnulein/qdomyos-zwift/actions/runs/12279400709

@Ziozanna
Copy link
Author

Ziozanna commented Dec 12, 2024 •
edited
Loading

Yesterday I tried another session with V1 patch and I have another log to add... Cold boot detected it, but it wouldn't connect. Reboot worked, but after a while, the strap disconnected. After finishing the workout, I tried disconnecting and reconnecting QZ from MW, but it was no longer visible.
Today I'm out all day long, I'll check the new patth with longer bridge opening time and I let you know
May I ask you to put somewere in the top bar a green spot when the bridge is open, just for debug purpose if you don't like in a stable release ? :)
debug-Wed_Dec_11_17_45_02_2024.zip

@cagnulein
Copy link
Owner

May I ask you to put somewere in the top bar a green spot when the bridge is open, just for debug purpose if you don't like in a stable release ? :)

the bridge from the QZ point of view is always open, that's the issue. there is no evidence about the fact that the virtual bridge is not open

@Ziozanna
Copy link
Author

After 3 cold boot it reconnect to MW flawlessy
debug-Fri_Dec_13_17_47_27_2024.zip

@Ziozanna
Copy link
Author

With a cold boot and the new build (30 seconds of waiting for the bridge), it works well apart from what happened again.
After a short while of riding, I noticed that the HR freezes, and the bike resistance, as well as the climb do not make any changes. It looks completely disconnected from the app. Gear changes still affect the resistance, so the connection between QZ and
debug-Sat_Dec_14_15_06_45_2024.zip
RB is still active. There’s no way to restart the connection with the app unless a new boot is performed. Here is the log.

@Ziozanna
Copy link
Author

Here the last debug with a Asust BT400 dongle configured as unique BT on RB
zanna@raspberrypi:~$ dmesg | grep Bluetooth
[ 9.699775] Bluetooth: Core ver 2.22
[ 9.707404] Bluetooth: HCI device and connection manager initialized
[ 9.707428] Bluetooth: HCI socket layer initialized
[ 9.707439] Bluetooth: L2CAP socket layer initialized
[ 9.709243] Bluetooth: SCO socket layer initialized
[ 9.990083] Bluetooth: hci0: BCM: chip id 63
[ 9.992095] Bluetooth: hci0: BCM: features 0x07
[ 10.011296] Bluetooth: hci0: BCM20702A
[ 10.011335] Bluetooth: hci0: BCM20702A1 (001.002.014) build 0000
[ 10.015744] Bluetooth: hci0: BCM20702A1 'brcm/BCM20702A1-0b05-17cb.hcd' Patch
[ 11.022106] Bluetooth: hci0: BCM: features 0x07
[ 11.039073] Bluetooth: hci0: Broadcom Bluetooth Device
[ 11.039105] Bluetooth: hci0: BCM20702A1 (001.002.014) build 1467
[ 12.353815] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 12.353838] Bluetooth: BNEP filters: protocol multicast
[ 12.353858] Bluetooth: BNEP socket layer initialized
[ 12.365020] Bluetooth: MGMT ver 1.22

zanna@raspberrypi:~$ hciconfig list
hci0: Type: Primary Bus: USB
BD Address: 5C:F3:70:AB:E6:FF ACL MTU: 1021:8 SCO MTU: 64:1
UP RUNNING
RX bytes:91599 acl:1042 sco:0 events:8818 errors:0
TX bytes:144811 acl:122 sco:0 commands:8199 errors:0

Result with latest build
debug-Thu_Dec_19_11_02_28_2024.zip

Connect Core, Click an HR but the bridge vene come up in MY
After a short while HR and click freeze

Here the log

@cagnulein
Copy link
Owner

yes for sure there is an issue on the advertising packet to MW

Thu Dec 19 11:03:36 2024 1734606216881 Debug:   HCI event triggered, type: e
Thu Dec 19 11:03:36 2024 1734606216882 Debug:   command 7 executed successfully
Thu Dec 19 11:03:36 2024 1734606216882 Debug:   TX power level is 10
Thu Dec 19 11:03:36 2024 1734606216883 Debug:   advertising parameters: "a000a0000000000000000000000700"
Thu Dec 19 11:03:36 2024 1734606216884 Debug:   advertising data: "12020a0a0201060509515a5049050326180d1800000000000000000000000000"
Thu Dec 19 11:03:36 2024 1734606216884 Debug:   scan response data: "0f020a0a0509515a5049050326180d1800000000000000000000000000000000"
Thu Dec 19 11:03:36 2024 1734606216885 Debug:   sending command; ogf: 8 ocf: 10
Thu Dec 19 11:03:36 2024 1734606216885 Debug:   command sent successfully
Thu Dec 19 11:03:36 2024 1734606216888 Debug:   HCI event triggered, type: e
Thu Dec 19 11:03:36 2024 1734606216888 Debug:   command 10 failed with status 12
Thu Dec 19 11:03:36 2024 1734606216889 Debug:   Advertising disable failed, ignoring
Thu Dec 19 11:03:36 2024 1734606216889 Debug:   sending command; ogf: 8 ocf: 6
Thu Dec 19 11:03:36 2024 1734606216890 Debug:   command sent successfully
Thu Dec 19 11:03:36 2024 1734606216892 Debug:   HCI event triggered, type: e
Thu Dec 19 11:03:36 2024 1734606216892 Debug:   command 6 executed successfully
Thu Dec 19 11:03:36 2024 1734606216893 Debug:   sending command; ogf: 8 ocf: 8
Thu Dec 19 11:03:36 2024 1734606216893 Debug:   command sent successfully
Thu Dec 19 11:03:36 2024 1734606216894 Debug:   HCI event triggered, type: e
Thu Dec 19 11:03:36 2024 1734606216895 Debug:   command 8 executed successfully
Thu Dec 19 11:03:36 2024 1734606216896 Debug:   sending command; ogf: 8 ocf: 9
Thu Dec 19 11:03:36 2024 1734606216896 Debug:   command sent successfully
Thu Dec 19 11:03:36 2024 1734606216897 Debug:   HCI event triggered, type: e
Thu Dec 19 11:03:36 2024 1734606216898 Debug:   command 9 executed successfully
Thu Dec 19 11:03:36 2024 1734606216898 Debug:   sending command; ogf: 8 ocf: 10
Thu Dec 19 11:03:36 2024 1734606216899 Debug:   command sent successfully
Thu Dec 19 11:03:36 2024 1734606216901 Debug:   HCI event triggered, type: e
Thu Dec 19 11:03:36 2024 1734606216902 Debug:   command 10 failed with status 12
Thu Dec 19 11:03:36 2024 1734606216902 Warning:   received advertising error

but i can see the HR for the whole file. i will try to compare the adv frame with the previous logs to check if there is soemthing different. it could be a driver issue

@cagnulein
Copy link
Owner

this is from a working adv

Fri Dec 13 17:48:58 2024 1734112138186 Debug:   QLowEnergyControllerPrivate setting state to QLowEnergyController::AdvertisingState
Fri Dec 13 17:48:58 2024 1734112138187 Debug:   sending command; ogf: 8 ocf: 7
Fri Dec 13 17:48:58 2024 1734112138187 Debug:   command sent successfully
Fri Dec 13 17:48:58 2024 1734112138190 Debug:   HCI event triggered, type: e
Fri Dec 13 17:48:58 2024 1734112138191 Debug:   command 7 executed successfully
Fri Dec 13 17:48:58 2024 1734112138192 Debug:   TX power level is 12
Fri Dec 13 17:48:58 2024 1734112138193 Debug:   advertising parameters: "a000a0000000000000000000000700"
Fri Dec 13 17:48:58 2024 1734112138194 Debug:   advertising data: "12020a0c0201060509515a5049050326180d1800000000000000000000000000"
Fri Dec 13 17:48:58 2024 1734112138194 Debug:   scan response data: "0f020a0c0509515a5049050326180d1800000000000000000000000000000000"
Fri Dec 13 17:48:58 2024 1734112138195 Debug:   sending command; ogf: 8 ocf: 10
Fri Dec 13 17:48:58 2024 1734112138196 Debug:   command sent successfully
Fri Dec 13 17:48:58 2024 1734112138197 Debug: ./ergtable.h void ergTable::collectData(uint16_t, uint16_t, uint16_t, bool) discarded C 0 W 0 R 0
Fri Dec 13 17:48:58 2024 1734112138200 Debug:   HCI event triggered, type: e
Fri Dec 13 17:48:58 2024 1734112138201 Debug:   command 10 failed with status 12
Fri Dec 13 17:48:58 2024 1734112138202 Debug:   Advertising disable failed, ignoring
Fri Dec 13 17:48:58 2024 1734112138203 Debug:   sending command; ogf: 8 ocf: 6
Fri Dec 13 17:48:58 2024 1734112138203 Debug:   command sent successfully
Fri Dec 13 17:48:58 2024 1734112138204 Debug:   HCI event triggered, type: e
Fri Dec 13 17:48:58 2024 1734112138205 Debug:   command 6 executed successfully
Fri Dec 13 17:48:58 2024 1734112138206 Debug:   sending command; ogf: 8 ocf: 8
Fri Dec 13 17:48:58 2024 1734112138206 Debug:   command sent successfully
Fri Dec 13 17:48:58 2024 1734112138208 Debug:   HCI event triggered, type: e
Fri Dec 13 17:48:58 2024 1734112138208 Debug:   command 8 executed successfully
Fri Dec 13 17:48:58 2024 1734112138209 Debug:   sending command; ogf: 8 ocf: 9
Fri Dec 13 17:48:58 2024 1734112138209 Debug:   command sent successfully
Fri Dec 13 17:48:58 2024 1734112138210 Debug:   HCI event triggered, type: e
Fri Dec 13 17:48:58 2024 1734112138211 Debug:   command 9 executed successfully
Fri Dec 13 17:48:58 2024 1734112138212 Debug:   sending command; ogf: 8 ocf: 10
Fri Dec 13 17:48:58 2024 1734112138212 Debug:   command sent successfully
Fri Dec 13 17:48:58 2024 1734112138213 Debug:   HCI event triggered, type: e
Fri Dec 13 17:48:58 2024 1734112138214 Debug:   command 10 executed successfully

@Ziozanna
Copy link
Author

Latest build , bridge not come up
debug-Thu_Dec_19_17_33_33_2024.zip

@cagnulein
Copy link
Owner

cagnulein commented Dec 19, 2024 via email

@Ziozanna
Copy link
Author

Ziozanna commented Dec 20, 2024 •
edited
Loading

Yep, bridge il come up but do not pass the pairing process. A new try on MY makes the bridge disappears

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@cagnulein cagnulein

Labels
bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Raspberry Multiple Connections creates issue on virtual bridge #2892 cagnulein/qdomyos-zwift
2 participants
@cagnulein @Ziozanna