Bluetooh connection Raspberry Pi 4 with Lego WeDo 2.0

[markakis-sch]

I have successfully connect a Lego WeDo 2.0 hub on my laptop (Ubuntu 20.04) using pyscrlink and tested it with Scratch 3. I also tried to connect Raspberry Pi 4 with the same hub. The WeDo hub connected and after a few seconds disconnected. I'm getting the following error message:

pi@raspberrypi:~ $ /home/pi/.local/bin/scratch_link 2021-01-21 19:37:08,798 FireFox NSS DB not found. Do not add certificate. 2021-01-21 19:37:08,851 Certificate is ready for Chrome 2021-01-21 19:37:09,186 Started scratch-link 2021-01-21 19:37:26,914 Start session for web socket path: /scratch/ble 2021-01-21 19:37:50,445 connected to the BLE peripheral: LPF2 Smart Hub 2 I/O 2021-01-21 19:37:54,885 Failure in session for web socket path: /scratch/ble 2021-01-21 19:37:54,885 Device disconnected

Any idea what's wrong?

[markakis-sch]

I should also add that I was able to successfully connect a LEGO Mindstorm EV3 to both my laptop and my Raspberry Pi 4 using pyscrlink. In all cases I had to add the package libglib2.0-dev in order to build the pyscrlink.

[kawasaki]

Hi @markakis-sch Thank you for sharing your findings. Good to know that EV3 is working well on your RP4! I guess README.md needs update to add libglib2.0-dev to the apt target package list.

Regarding the WeDo disconnect, I have no idea. One suggestion is to add -d option to scratch_link command. A lot of debug messages will be printed. It may help me to guess what's wrong.

[markakis-sch]

I have 5% successful connections on Raspberry Pi 4. Here is the debug messages ( -d option) from a disconnection: scratch_link.log

[kawasaki]

Thanks! I took a quick look in the log.

I checked logs around disconnect event. The reason of disconnect was not reported in the Exception from bluepy layer. So, another action might be required to get logs from bluepy.

Another aspect is that WeDo and pyscrlink worked with your Ubuntu machine. Also, sometimes (5%) it worked with RP4. Then, my guess is that this can be timing issue caused by slow RP4. In the log, the last message exchange between pyscrlink and WeDo before disconnect was "start notification request" from pyscrlink. From the log, It takes around 3 seconds, and it sounds slow. I will compare how long it takes on my machine with micro:bit.

I will spend some more time on my next weekend to think about next action for further investigation.

[markakis-sch]

Please let me know if you need extra log files and which ones. I'm at your disposal. Thanks for your time and for the good work with pyscrlink!

[kawasaki]

Here's some update.

I took log using my PC and micro:bit, and compared the time to process "startNotifiction" request. In my environment, it took around 1.4 seconds. From the log by @markakis-sch , it took 2.2 seconds for RP4 + Lego WeDo. Hmm, 1.4 seconds vs 2.2 seconds does not sound a big difference. So, from the pyscrlink log, I do not notice anything weird. My current guess is that the disconnect cause may reside in other place than pyscrlink. (in bluepy stack, or bluez stack?)

I think next action is to check bluepy stack and bluez stack if they can do stable communication with Lego WeDo from RP4. One idea is to enable debug print of bluepy. I took a look in bluepy source code, but even if it is modified to print debug logs, it looks like difficult to print disconnect cause. Another idea is to do some manual operation on RP4 with command line (with btmgmt command maybe?) to check connectivity with Lego WeDo. I will try to figure out how to do that.

[kawasaki]

Hi @markakis-sch ,

Could you try following commands on your RP4? I assume your RP4 has bluetoothctl command. It will allow us to do simple connection test between RP4 and WeDo Hub.

$ bluetoothctl
[bluetooth] # info
(Controller information will be shown.)
[bluetooth] # scan on
Discovery started
[NEW] Devices xx:xx:xx:xx:xx:xx ....
(Devices discovered by RP4 are listed. Wait for your WeDo Hub appears. The device description will be "Smart Hub 2" or something. You may need to push button on the WeDo device.)
[bluetooth] # scan off
Discovery stopped
[bluetooth] # connect xx:xx:xx:xx:xx:xx
(Use the values for the WeDo Hub printed by "scan on" command. If it goes well, the message "Connect successful" is expected.)
[bluetooth] # exit
$ bluetoothctl
[bluetooth] # info
(Controller information will be shown. I expect this will show status about WeDo Hub.)

The steps above worked well between my Raspberry Pi zero and micro:bit. If it goes well between your RP4 and WeDo Hub, basic bluetooth connect is ok. If not, an issue is there.

[markakis-sch]

I followed the steps you said. Here is the result:

pi@raspberrypi:~ $ bluetoothctl
Agent registered
[bluetooth]# info
Missing device address argument
[bluetooth]# scan on
Discovery started
[CHG] Controller DC:A6:32:D4:17:74 Discovering: yes
[CHG] Device 60:77:71:47:20:7C RSSI: -38
[CHG] Device 60:77:71:47:20:7C TxPower: 0
[bluetooth]# scan off
[CHG] Device 60:77:71:47:20:7C TxPower is nil
[CHG] Device 60:77:71:47:20:7C RSSI is nil
[CHG] Controller DC:A6:32:D4:17:74 Discovering: no
Discovery stopped
[bluetooth]# connect 60:77:71:47:20:7C
Attempting to connect to 60:77:71:47:20:7C
[CHG] Device 60:77:71:47:20:7C Connected: yes
Connection successful
[CHG] Device 60:77:71:47:20:7C ServicesResolved: yes
[LPF2 Smart Hub 2 I/O]# exit
pi@raspberrypi:~ $ bluetoothctl
Agent registered
[LPF2 Smart Hub 2 I/O]# info
Device 60:77:71:47:20:7C (public)
    Name: LPF2 Smart Hub 2 I/O
    Alias: LPF2 Smart Hub 2 I/O
    Paired: no
    Trusted: yes
    Blocked: no
    Connected: yes
    LegacyPairing: no
    UUID: Vendor specific           (00001523-1212-efde-1523-785feabcd123)
    UUID: Generic Access Profile    (00001800-0000-1000-8000-00805f9b34fb)
    UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
    UUID: Device Information        (0000180a-0000-1000-8000-00805f9b34fb)
    UUID: Battery Service           (0000180f-0000-1000-8000-00805f9b34fb)
    UUID: Vendor specific           (00004f0e-1212-efde-1523-785feabcd123)
    ServiceData Key: 00001523-0000-1000-8000-00805f9b34fb
    ServiceData Value:
  00 00 00 00 00 00                                ......          
[LPF2 Smart Hub 2 I/O]#

I tried it many times. The WeDo hub remains connected to RP4, in all cases .

[kawasaki]

@markakis-sch Thank you for the action and report. Then, bluez layer is working well. Next step is to focus on bluepy layer. Let me think what to do.

[kawasaki]

Hi @markakis-sch , As the next action, I would like to test if a simple bluepy script can keep connection with WeDo. Could you run this python script on your RP4? test.py.txt It should connect to WeDo, and keep connection for 10 seconds. If no error happens, output will be like this:

$ sudo python3 ./test.py.txt
Found WeDo Smart Hub! <bluepy.btle.ScanEntry object at 0xXXXXXXXXX>
wait 10 seconds...

[markakis-sch]

pi@raspberrypi:~/.local/lib/python3.7/site-packages $ sudo python3 ./test.py.txt
Found WeDo Smart Hub! <bluepy.btle.ScanEntry object at 0xb646fb70>
wait 10 seconds...
pi@raspberrypi:~/.local/lib/python3.7/site-packages $

I tried it many times. I also changed the sleep command to 60 seconds. Same behaviour.

[markakis-sch]

Today i ran an apt upgrade command on my RP4. After that I no longer have disconnections from the WeDo hub. I noticed that the upgrade contained some upgrades for python packages for the ARM architecture. I think the problem was somewhere there and it was fixed.

Whatever, the news is good! Now the WeDo 2.0 works fine on my RP4!

Thank you again for your time and the very good work with the pyscrlink!

[kawasaki]

Wow, that's great! Very happy to know that RP4 and WoDo are working good via pyscrlink! The lesson learnt is to make sure the system is up to date for bluetooth related trouble shooting. Thank you for sharing your experience and cooperation for investigations :)