Cannot connect to Powered Up Remote #397
Comments
|
Could you share the script you used? Can you also add the following to your code, and share the output? from pybricks import version
print(version) |
from pybricks.pupdevices import Remote
from pybricks.parameters import Button
from pybricks.tools import wait
# Connect to the remote.
my_remote = Remote()
while True:
# Check which buttons are pressed.
pressed = my_remote.buttons.pressed()
# Show the result.
print("pressed:", pressed)
# Check a specific button.
if Button.CENTER in pressed:
print("You pressed the center button!")
# Wait so we can see the result.
wait(100) |
dlech
added
bug
|
('cityhub', '3.1.0a3', 'v3.1.0a3 on 2021-07-19') |
|
It is working for me with the same firmware version. They only way I know to troubleshoot would be to connect the defective remote to a computer and log the Bluetooth packets. Maybe the remote has different firmware or something like that? |
|
Also, try turning on the remote later after the program is already started instead of pressing the buttons at the same time. |
|
I'm on a 2021 MacBook Air. The remote doesn't appear in the bluetooth list when in pairing mode, nor does it on iOS. It connects through the app quickly, without any issues. |
|
You would need to use a program like pybricksdev that knows how to connect to the remote. |
Do you remember roughly when this remote was purchased? Was it purchased separately or as part of a train set? |
|
Someone on our Facebook page has reported a similar issue. @dlech, if more people run into this, perhaps we can share a firmware zip here that prints out relevant debug info during the connection process, so people can try it without Pybricksdev. |
That was me on Facebook, sorry! The remote came from a 60198 set that I purchased sealed, but from a private seller, in December 2020. I had a look on the box, but it doesn't look like there's a date code. The remote has the following under the battery box:
The following is moulded:
|
|
I just had another idea. If you have iOS or Android, you can install nRF Connect and sniff the adverting data from the remote. We are looking for the raw advertising data like this: |
|
Thanks Dlech. Unfortunately I'm away from home until the end of August, but I'll try this as soon as I get back. |
dlech
added
the
hub: handset
|
It looks like nRF Connect doesn't show raw advertising data on iOS. I'll try and get an Android device for testing in the next few days. |
|
FYI, we've made some changes that could affect this issue. Could you try again with the v3.1.0a4 firmware from https://beta.pybricks.com? |
|
V3.1.0a34 makes no difference unfortunately |
|
Completely different environment, but this combo works: and so on. |
|
I grabbed the advertising data using an Android device today |
|
Was this any use? |
|
It matches the advertising data from my hub (other than the hub name, which should not be relevant), so it rules out the possibility that LEGO changed the advertising data layout. However, that doesn't get us any closer to a solution. We did have one other report of not being able to connect to a different LWP3 device: #442 (comment). Not sure if this might be related or not. |
|
I installed pybricksdev on an older, Intel MacBook and my remote connects without issue. I'm unable to connect my city hub, although that might be my fault. I'll read the documentation further. |
|
It the city hub currently has Pybricks firmware on it instead of LEGO firmware, then that would explain why it doesn't connect in the same way as the remote. |
|
I tried again with the Lego firmware and it connects. Is there some diagnostics I can do with pybricksdev? |
|
Since it is connecting properly with pybricksdev, there probably isn't much to be learned there. If you really want to, you can log the Bluetooth packets (instructions). But what we really need is the Bluetooth traffic going between the city hub running Pybricks firmware and the remote handset. However, that requires a sniffer. |
|
Hi, just ran into seemingly similar issue on CityHub :)
Remote never shows up in beta.pybricks.com (neither flashing mode, nor the regular connection), but I can connect to it using
So if the remote can connect ok with TechnicHub, is it something special to do with cityhub? My CityHub is:
|
|
Another experiment:
|
|
Also tried shortening the remote connect timeout |
|
It's a long shot, but we could try adding this (suggested here to fix a similar issue of not able to connect a peripheral while another peripheral is connected). diff --git a/lib/pbio/drv/bluetooth/bluetooth_stm32_cc2640.c b/lib/pbio/drv/bluetooth/bluetooth_stm32_cc2640.c
index 1a264a52..5d86204f 100644
--- a/lib/pbio/drv/bluetooth/bluetooth_stm32_cc2640.c
+++ b/lib/pbio/drv/bluetooth/bluetooth_stm32_cc2640.c
@@ -1355,6 +1355,11 @@ static PT_THREAD(gap_init(struct pt *pt)) {
PT_WAIT_UNTIL(pt, hci_command_status);
// ignoring response data
+ PT_WAIT_WHILE(pt, write_xfer_size);
+ GAP_SetParamValue(TGAP_REJECT_CONN_PARAMS, 1);
+ PT_WAIT_UNTIL(pt, hci_command_status);
+ // ignoring response data
+
PT_END(pt);
}
|
|
I can confirm the same issue with latest beta: |
|
@mateusz and @stephg, which operating system are you using on your computer? Can you also reproduce this problem if you run https://beta.pybricks.com/ on your Android device? This might help us see if perhaps there isn't necessarily a hardware difference between all of our city hubs. |
|
@laurensvalk OMG, I can't believe we haven't thought about that, great suggestion 😅 It works! The scenario I described here works fine on Android - I can have both Android and remote connected, and I can see the log coming out too. The machine where I reported it not working is a MacBook Pro (16-inch, 2019), on Big Sur 11.6. Amazing, I can now get some data out while having the remote on :) Nice! Thank you! Some more info on the mac BT: Mac browser: Android browser: |
Glad to hear it! Then so far we have:
Originally posted by @mateusz in #397 (comment)
Originally posted by @pqhf5kd in #397 (comment) |
|
MacBook Pro (16-inch, 2019), Big Sur 11.6 to be specific (updated post) |
|
I have an early 2015 MacBook Pro running macOS 12 beta and it works there. (I'm ready to upgrade, but I've been holding out to see what new models are announced this fall). Since we've narrowed it down to potentially a macOS issue, we can try logging Bluetooth packets there and see if we see anything interesting. Instructions. |
I was using OSX 11.5.2 on an 2019 MacBook Pro 16-inch and Chrome. My Linux machine has no BLE, so can't test that. When running Pybricks Code on my Android mobile, the remote can connect successfully! |
You can find a btsnoop of downloading and running my sample program here: https://drive.google.com/file/d/1fZNnsmhxE0zbns8pn5axAkg3lHbvOjHn/view?usp=sharing |
If the hub actually crashes, it should reboot itself. If you are still able to power off with the button then it didn't totally crash, but got into some sort of bad state. If you have to remove the batteries, then something really bad is going on. |
Thanks for this. I looks like the Mac is periodically scanning the entire time. I wonder if these could be interfering with the process, e.g. if the Mac says to stop scanning right after the City hub starts scanning. Here is a city hub firmware to try that does passive scanning instead of active scanning (and has the debug logging enabled). diff --git a/lib/pbio/drv/bluetooth/bluetooth_stm32_cc2640.c b/lib/pbio/drv/bluetooth/bluetooth_stm32_cc2640.c
index 1a264a52..1c2faa51 100644
--- a/lib/pbio/drv/bluetooth/bluetooth_stm32_cc2640.c
+++ b/lib/pbio/drv/bluetooth/bluetooth_stm32_cc2640.c
@@ -431,7 +431,7 @@ static PT_THREAD(scan_and_connect_task(struct pt *pt, pbio_task_t *task)) {
// start scanning
PT_WAIT_WHILE(pt, write_xfer_size);
- GAP_DeviceDiscoveryRequest(GAP_DEVICE_DISCOVERY_MODE_ALL, 1, GAP_FILTER_POLICY_SCAN_ANY_CONNECT_ANY);
+ GAP_DeviceDiscoveryRequest(GAP_DEVICE_DISCOVERY_MODE_ALL, 0, GAP_FILTER_POLICY_SCAN_ANY_CONNECT_ANY);
PT_WAIT_UNTIL(pt, hci_command_status);
context->status = read_buf[8]; // debug |
|
Flashed the "passive-scanning" firmware (v3.1.0b1-3-g0602b0e7-dirty) - now the controller does not connect at all (regardless of connection to macos) |
|
Did it log receiving advertising data though? |
|
Oh sorry, here is the output: |
dlech
added
the
hub: cityhub
|
I got a new MacBook a week ago and sure enough, I was able to reproduce the problem. I used my Bluetooth sniffer to compare it to a working setup (my Linux desktop) to see what the difference was. The only thing I could see is that connection interval when connected to the MacBook was 15 ms compared to something like 50 ms when connected to Linux (I've attached the file for the curious). Fortunately Apple spells out how to change this setting and I was able to find the TI API to do this so the issue is fixed. |
Is this a Mac-specific fix, or could it fix it on Windows also? |
|
Hard to say if it fixes other platforms without any logs to compare. However the change is generic and should affect all platforms. |
|
Great - I'll get a Windows user who had this problem to try the new firmware. |
Their problem could not be reproduced anymore. It is now working with this new build, as well as the current beta. So it must have been a different issue. We'll make logs next time. |
|
Thank you for fixing this! Amazing :) |
Originally posted by @pqhf5kd in #186 (comment)
The text was updated successfully, but these errors were encountered: