Bluetooth classic RFCOMM communication support #452

jaguilar · 2026-01-15T06:41:54Z

Please ignore the whitespace changes. I'll revert them when I get a chance. They weren't intended.

This has been tested with the example programs in pybricks/pybricks-projects#100

I expect some changes will be required for this pull request, but I'm putting it out there to demonstrate I have something working and as a jumping off point for further discussion.

(We will also need to decide exactly what functionality will be #ifdef'd out. If we've decided to put classic on all of the hubs that use btstack we could just remove some ifdefs and things would build.)

TODO

BertLindeman · 2026-01-15T14:02:02Z

James,

Trying my EV3 with this firmware on the tankbot_rc
The program runs up to the rfcomm_listen and waits.
Log:

Local address:  A0:E6:F8:E4:42:36
Waiting for connection...
Loaded 0 link keys from settings
[btc:rfcomm_listen] Listening for incoming RFCOMM connections...
sm.c.720: GAP Random Address Update due
sm.c.711: gap_random_address_trigger, state 0
HCI out packet type: 01, len: 3
HCI in packet type: 04, len: 2
HCI in packet type: 04, len: 6
HCI out packet type: 01, len: 9
HCI in packet type: 04, len: 2
HCI in packet type: 04, len: 6
The program was stopped (SystemExit).

What kind of device did you use as RC?
Or do I need 2 EV3brcks for this?

Bert

jaguilar · 2026-01-15T14:17:47Z

Hi, @BertLindeman! So kind of you to try this. You do need some sort of client to talk to the tankbot, be it another EV3 or a PC. If you have two EV3s, the client program here is designed to implement this LEGO model. If you run the program on another brick it should connect.

If you want to try connecting from a computer, you'll need a computer with bluetooth. I believe you should be able to connect in Python with something like:

import socket
sock = socket.socket(family=socket.AF_BLUETOOTH)
await sock.connect('XX:XX:XX:XX:XX:XX') # The address printed on the terminal by the tankbot.

You would send messages to the socket that are packed with the struct module -- the code is very short so you should be able to see the desired format.

jaguilar · 2026-01-15T20:48:43Z

FYI, this is building fine locally. Not sure what the deal is with CI. Possibly because the build state is not good at certain intermediate commits. I can squash whenever it is so desired.

BertLindeman · 2026-01-16T22:08:02Z

Used firmware ('ev3', '4.0.0b3', 'ci-build-4625-v4.0.0b3-114-gab4df866 on 2026-01-15')
on Windows 11 25H2.

With EV3 program:

#!/usr/bin/env pybricks-micropython

# simple tankbot program to test Bluetooth classic connection

from pybricks.hubs import EV3Brick
from pybricks.ev3devices import Motor, GyroSensor
from pybricks.parameters import Port, Direction, Button, Color
from pybricks.tools import StopWatch, wait, run_task
from pybricks.robotics import DriveBase
from pybricks.messaging import rfcomm_listen, local_address 

from micropython import const

import ustruct

from pybricks import version

# Initialize the EV3 brick.
ev3 = EV3Brick()
print(version)

left_motor = Motor(Port.A, Direction.COUNTERCLOCKWISE)
right_motor = Motor(Port.D, Direction.COUNTERCLOCKWISE)

WHEEL_DIAMETER = 54
AXLE_TRACK = 200

robot = DriveBase(left_motor, right_motor, WHEEL_DIAMETER, AXLE_TRACK)

SPEED_SCALE = 6
TURN_SCALE = 2

# Storage for incoming messages from remote control.
msg_buf = bytearray(2)    
msg_buf_view = memoryview(msg_buf)

# Tracks the next-to-be-filled index in msg_buf.
cur_idx = 0

# keep the local address out of the loop. It will not change.
addr = local_address()
print("Local address:", addr)


async def main():
    # light red on listening for a connection
    ev3.light.on(Color.RED)
    print('Waiting for connection...')
    try:
        conn = await rfcomm_listen()
        print('Connected!')
        # light green on connection
        ev3.light.on(Color.GREEN)
    except KeyboardInterrupt:
        conn.close()
        wait(200)
        raise SystemExit(0)

    timeout = StopWatch()
    cur_idx = 0
    try:
        while timeout.time() < 2000:  # Do not kame the wait too short
            cur_idx += conn.readinto(msg_buf_view[cur_idx:], len(msg_buf) - cur_idx)

            if cur_idx != len(msg_buf):
                # We were not able to read the entire message. Loop again.
                await wait(1)
                continue

            timeout.reset()
            axis1, axis2 = ustruct.unpack('>bb', msg_buf)
            cur_idx = 0

            if axis1 == axis2 == -127:  # stop connection
                print("\tGot stop signal from client")
                break

            speed = axis2 * SPEED_SCALE  # -768 to +768 mm/s
            turn_rate = axis1 * TURN_SCALE  # -320 to +320 deg/s
            robot.drive(speed, turn_rate)
    except OSError:
        print("\tRFCOMM error")
    except KeyboardInterrupt:
        print("\tGot keyboard interrupt")
        pass
    finally:
        robot.stop()
        # make sure to socket and channel are cleaned up
        conn.close()
        wait(200)  # wait a bit to give the close some time.
        print('\tIn finally: Closed connection')


run_task(main())

And Windows program:

import socket
import struct
import time

ADDR = "A0:E6:F8:E4:42:36"
CHANNEL = 1

def get_key():
    import msvcrt
    if msvcrt.kbhit():
        return msvcrt.getch().decode("ascii").lower()
    return None

sock = socket.socket(
    socket.AF_BLUETOOTH,
    socket.SOCK_STREAM,
    socket.BTPROTO_RFCOMM
)

STD_MOTOR_SCALE = 20
try:
    sock.connect((ADDR, CHANNEL))
    sock.settimeout(2.0)
    print("Connected. W/S/A/D to drive, space=stop, Q=quit")

    axis1 = 0  # turn
    axis2 = 0  # speed

    while True:
        key = get_key()

        if key == 'w':
            axis2 = STD_MOTOR_SCALE
        elif key == 's':
            axis2 = -STD_MOTOR_SCALE
        elif key == 'a':
            axis1 = -STD_MOTOR_SCALE
        elif key == 'd':
            axis1 = STD_MOTOR_SCALE
        elif key == ' ':
            axis1 = 0
            axis2 = 0
        elif key == 'q':
            axis1 = -127  # signal stop run
            axis1 = -127
            msg = struct.pack('>bb', axis1, axis2)
            sock.send(msg)
            break

        # ALWAYS send, even if unchanged
        msg = struct.pack('>bb', axis1, axis2)
        sock.send(msg)

        time.sleep(0.05)

except OSError as e:
    print("RFCOMM error:", e)

finally:
    try:
        sock.close()
    except OSError:
        pass
    print("Disconnected")

Log of one run:

``` pybricksdev run usb ..\EV3\tankbot_rc.py 100%|██████████████████████████████████████████████████████████████████████████████████████████████████| 1.33k/1.33k [00:00<00:00, 432kB/s] ('ev3', '4.0.0b3', 'ci-build-4625-v4.0.0b3-114-gab4df866 on 2026-01-15') Local address: A0:E6:F8:E4:42:36 Waiting for connection... [btc:rfcomm_listen] Listening for incoming RFCOMM connections... hci.c.3431: Connection_incoming: 8C:90:2D:41:E4:60, type 1 hci.c.312: create_connection_for_addr 8C:90:2D:41:E4:60, type fd hci.c.6672: sending hci_accept_connection_request hci.c.3457: Connection_complete (status=0) 8C:90:2D:41:E4:60 hci.c.3494: New connection: handle 1, 8C:90:2D:41:E4:60 hci.c.7505: BTSTACK_EVENT_NR_CONNECTIONS_CHANGED 1 IDENTITY_RESOLVING_STARTED sm.c.2269: LE Device Lookup: not found IDENTITY_RESOLVING_FAILED hci.c.506: pairing started, ssp 1, initiator 0, requested level 2 hci.c.7677: gap_mitm_protection_required_for_security_level 2 hci.c.6736: Remote not bonding, dropping local flag SSP User Confirmation Request. Auto-accepting... hci.c.528: pairing complete, status 00 Link key updated, saving to settings. Saved 0 link keys to settings sm.c.3900: Encryption state change: 1, key size 0 sm.c.3902: event handler, state 82 hci.c.2788: Handle 0001 key Size: 16 hci.c.7536: hci_emit_security_level 2 for handle 1 l2cap.c.2833: security level update for handle 0x0001 l2cap.c.3633: extended features mask 0xba l2cap.c.2460: create channel c007e770, local_cid 0x0042 l2cap.c.3649: fixed channels mask 0x8a hci.c.2509: Remote features 03, bonding flags 70 l2cap.c.2822: remote supported features, channel c007e770, cid 0042 - state 4 l2cap.c.1159: L2CAP_EVENT_INCOMING_CONNECTION addr 8C:90:2D:41:E4:60 handle 0x1 psm 0x3 local_cid 0x42 remote_cid 0x40 rfcomm.c.382: rfcomm_max_frame_size_for_l2cap_mtu: 1691 -> 1686 rfcomm.c.1074: RFCOMM incoming (l2cap_cid 0x42) => accept l2cap.c.3131: L2CAP_ACCEPT_CONNECTION local_cid 0x42 l2cap.c.1404: l2cap_stop_rtx for local cid 0x42 l2cap.c.1441: l2cap_start_rtx for local cid 0x42 l2cap.c.3359: L2CAP signaling handler code 4, state 11 l2cap.c.3187: Remote MTU 1017 l2cap.c.3359: L2CAP signaling handler code 5, state 11 l2cap.c.1404: l2cap_stop_rtx for local cid 0x42 l2cap.c.3289: l2cap_signaling_handle_configure_response l2cap.c.1129: L2CAP_EVENT_CHANNEL_OPENED status 0x0 addr 8C:90:2D:41:E4:60 handle 0x1 psm 0x3 local_cid 0x42 remote_cid 0x40 local_mtu 1691, remote_mtu 1017, flush_timeout 0 rfcomm.c.1101: channel opened, status 0 rfcomm.c.382: rfcomm_max_frame_size_for_l2cap_mtu: 1691 -> 1686 rfcomm.c.1219: Received SABM #0 rfcomm.c.1364: Sending UA #0 rfcomm.c.941: Multiplexer up and running rfcomm.c.1640: Received UIH Parameter Negotiation Command for #2, credits 7 rfcomm.c.509: rfcomm_channel_create for service c007e44c, channel 1 --- list of channels: rfcomm.c.1997: -> Inform app rfcomm.c.247: RFCOMM_EVENT_INCOMING_CONNECTION addr 8C:90:2D:41:E4:60 channel #1 cid 0x02 rfcomm.c.2628: accept cid 0x02 rfcomm.c.2025: Sending UIH Parameter Negotiation Respond for #2 rfcomm.c.1782: rfcomm_channel_ready_for_incoming_dlc_setup state var 00000003 rfcomm.c.1607: Received SABM #2 rfcomm.c.2029: Sending UA #2 rfcomm.c.1782: rfcomm_channel_ready_for_incoming_dlc_setup state var 00000007 rfcomm.c.2034: Incomping setup done, requesting send MSC CMD and send Credits rfcomm.c.1942: Sending MSC CMD for #2 rfcomm.c.2123: Providing credits for #2 rfcomm.c.1773: rfcomm_channel_ready_for_open state 8, flags needed 0010, current 00014007, rf credits 7 rfcomm.c.1660: Received MSC CMD for #2, rfcomm.c.1773: rfcomm_channel_ready_for_open state 8, flags needed 0010, current 0001500f, rf credits 7 rfcomm.c.1949: Sending MSC RSP for #2 rfcomm.c.1667: Received MSC RSP for #2 rfcomm.c.1773: rfcomm_channel_ready_for_open state 8, flags needed 0010, current 0001c01f, rf credits 7 rfcomm.c.1410: opened rfcomm.c.265: RFCOMM_EVENT_CHANNEL_OPENED status 0x0 addr 8C:90:2D:41:E4:60 handle 0x1 channel #1 cid 0x02 mtu 1011 RFCOMM channel opened: cid=2. rfcomm.c.2667: grant cid 0x02 credits 4 [btc:rfcomm_listen] Connected Connected! rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 25, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x02: 0, now 32 rfcomm.c.2667: grant cid 0x02 credits 2 rfcomm.c.291: RFCOMM_EVENT_CHANNEL_CLOSED cid 0x02 RFCOMM_EVENT_CHANNEL_CLOSED by remote for cid=2. RFCOMM channel closed: cid=2. rfcomm.c.2214: Sending UA after DISC for #2 [btc:rfcomm_recv] Socket is not connected or does not exist. RFCOMM error rfcomm.c.2553: disconnect cid 0x02 In finally: Closed connection rfcomm.c.1237: Received DISC #0, (ougoing = 0) rfcomm.c.1371: Sending UA #0 rfcomm.c.1372: Closing down multiplexer l2cap.c.3359: L2CAP signaling handler code 6, state 13 l2cap.c.1188: L2CAP_EVENT_CHANNEL_CLOSED local_cid 0x42 rfcomm.c.1174: channel closed cid 0x42, mult 0 l2cap.c.2466: free channel c007e770, local_cid 0x0042 l2cap.c.1404: l2cap_stop_rtx for local cid 0x42 ```

Fun.
I had to add the finally to the EV3 program to prevent already listening on a program restart.
Or I needed to reboot the EV3 to get rid of the socket? connection? or channel?

jaguilar · 2026-01-16T23:23:29Z

Bert, did you still have to add the finally with 29f1254, or was that with the firmware you built earlier? The fixup commits that I added were meant to fix that issue, but I guess I never tried it without removing the finally from my own test scripts.

BertLindeman · 2026-01-17T08:17:32Z

Bert, did you still have to add the finally with 29f1254, or was that with the firmware you built earlier? The fixup commits that I added were meant to fix that issue, but I guess I never tried it without removing the finally from my own test scripts.

James,
The finally is needed using ('ev3', '4.0.0b3', 'ci-build-4625-v4.0.0b3-114-gab4df866 on 2026-01-15') from the CI builds.
I did no builds myself.
Before that firmware I did not succeed as my programs were no good yet.
Do you want me to try another CI build?

BertLindeman · 2026-01-17T15:51:35Z

Just for my understanding:

If the user program stops after
conn = await rfcomm_listen()

Then the next run of the program fails with [btc:rfcomm_listen] Already listening.:

pybricksdev run usb  ..\EV3\tankbot_rc.py
100%|██████████████████████████████████████████████████████████████████████████████████████████████████| 1.29k/1.29k [00:00<00:00, 403kB/s]
('ev3', '4.0.0b3', 'ci-build-4625-v4.0.0b3-114-gab4df866 on 2026-01-15')
Local address: A0:E6:F8:E4:42:36
Waiting for connection...
[btc:rfcomm_listen] Already listening.
Traceback (most recent call last):
  File "tankbot_rc.py", line 99, in <module>
  File "tankbot_rc.py", line 50, in main
OSError: [Errno 16] EBUSY: Device or resource busy

Is that the expected result, so the python program should use e.g. a finally clause to stop the listening?

jaguilar · 2026-01-17T16:48:31Z

No, that is not the expected result. I will have to go back and test my fixes in the latest set of commits. They are intended to clean up all of the outstanding sockets, but it may be that I made a mistake.

This class is useful for rfcomm communication, specifically the readinto function.

jaguilar · 2026-01-18T17:42:09Z

I investigated how these APIs are typically implemented in Micropython. Particularly usocket. It looks like the general pattern is to implement things as objects. Therefore, I converted messaging to have an RFCOMMSocket object, which is what @dlech originally suggested.

I updated the examples to show what the API looks like now.

@BertLindeman I have tested the latest firmware (through 43ef418) and verified that if you disconnect the remote and reconnect it, you no longer get already-in-use errors, even without the try/finally. Please let me know if you find otherwise.

jaguilar · 2026-01-18T18:02:38Z

One minor point where I'd like to request feedback. Previously, upon closing the RFCOMM socket, we called gap_disconnect. This wasn't correct -- at a minimum, you need to rfcomm disconnect first to get a graceful channel shutdown.

The current RFCOMM code does not call gap_disconnect at all. Our btstack implementation does not count references to the HCI connection layer. If there are two connections to the same remote (e.g. both an LE connection and an RFCOMM connection, or two separate RFCOMM connections), gap_disconnect would terminate all of them, rather than just the specific RFCOMM socket that is being closed. It's not safe to do.

The problem with the current approach is that without gap_disconnect, the radio link stays up. It is kinda convenient, because when you restart an RFCOMM client program after a crash, it will connect basically instantly, skipping the slow classic link establishment process. However, because the radio link is still up, the brick is consuming a significant amount of power that it would not be doing if all of the radio links were closed down.

It might not be that big of an issue, but if it is, we need to start counting references to the HCI connections and calling gap_disconnect when the last reference is removed. Please let me know if you think that's important to do.

BertLindeman · 2026-01-18T18:42:47Z

James,

Ran your tankbot_rc on the now latest firmware:
('ev3', '4.0.0b3', 'ci-build-4628-v4.0.0b3-118-g05947152 on 2026-01-18')

log of one run until the EV3 is listening and then stop the program using the EV3 back button.
No re-boot done here.
The following run then fails "Already listening":

C:\Users\bert\py\pybricks>pybricksdev run usb  ..\EV3\tankbot_rc_james.py
rted 14/7
hci.c.2593: Command 0x03 supported 18/3
hci.c.2593: Command 0x04 supported 20/4
hci.c.2593: Command 0x06 supported 24/6
hci.c.2598: Local supported commands summary 0000005f
btstack_crypto.c.1121: controller supports ECDH operation: 0
hci.c.2722: Local Address, Status: 0x00: Addr: A0:E6:F8:E4:42:36
hci.c.2640: hci_read_buffer_size: ACL size module 1021 -> used 1021, count 4 / SCO size 180, count 4
hci.c.2756: Packet types cc18, eSCO 1
hci.c.2759: BR/EDR support 1, LE support 0
100%|██████████████████████████████████████████████████████████████████████████████████████████████████| 1.15k/1.15k [00:00<00:00, 383kB/s]
hci.c.1770:('ev3', '4.0.0b3', 'ci-build-4628-v4.0.0b3-118-g05947152 on 2026-01-18')
Local address:  A0:E6:F8:E4:42:36
Waiting for connection...
Loaded 0 link keys from settings
[btc:rfcomm_listen] Listening for incoming RFCOMM connections...
The program was stopped (SystemExit).

C:\Users\bert\py\pybricks>pybricksdev run usb  ..\EV3\tankbot_rc_james.py
100%|██████████████████████████████████████████████████████████████████████████████████████████████████| 1.15k/1.15k [00:00<00:00, 574kB/s]
('ev3', '4.0.0b3', 'ci-build-4628-v4.0.0b3-118-g05947152 on 2026-01-18')
Local address:  A0:E6:F8:E4:42:36
Waiting for connection...
[btc:rfcomm_listen] Already listening.
Traceback (most recent call last):
  File "tankbot_rc_james.py", line 89, in <module>
  File "tankbot_rc_james.py", line 63, in main
OSError: [Errno 16] EBUSY: Device or resource busy

As I only have one EV3, so I need to convert my windows program a bit, so later....

Bert

jaguilar · 2026-01-18T19:58:28Z

Hrm. That is very interesting. Let me try it with exactly the sequence that you are using incl the client program on PC and see if I can repro.

laurensvalk · 2026-01-18T21:06:32Z

Never mind my config change to this PR - that wasn't intentional. The mobile app doesn't seem to have a way of undoing it. Was just trying to catch up 😄

jaguilar · 2026-01-18T21:18:42Z

@BertLindeman I'm sorry, I can't reproduce your issue from my Linux machine. When I run the tank_bot_rc/main.py program again (without rebooting) it listens just fine. I'm wondering if the CI build is actually incorporating all the commits. @laurensvalk do you know if there is a way to check that?

BertLindeman · 2026-01-18T22:17:21Z

@jaguilar There was no other program involved, just:

run the tank_rc program
press the EV3 back button
run the tank_rc program
and get "already listening"

the `tankbot_rc_james.py` program I used

#!/usr/bin/env pybricks-micropython

"""
Example LEGO® MINDSTORMS® EV3 Tank Bot Program
----------------------------------------------

This program requires LEGO® EV3 MicroPython v2.0.
Download: https://education.lego.com/en-us/support/mindstorms-ev3/python-for-ev3

Building instructions can be found at:
https://education.lego.com/en-us/support/mindstorms-ev3/building-instructions#building-expansion
"""

from pybricks.hubs import EV3Brick
from pybricks.ev3devices import Motor, GyroSensor
from pybricks.parameters import Port, Direction, Button, Color
from pybricks.tools import StopWatch, wait, run_task
from pybricks.robotics import DriveBase
from pybricks.messaging import RFCOMMSocket, local_address 

from micropython import const

import ustruct
from pybricks import version

# Initialize the EV3 brick.
ev3 = EV3Brick()
print("\t", version, "\n")

# Configure 2 motors on Ports B and C.  Set the motor directions to
# counterclockwise, so that positive speed values make the robot move
# forward.  These will be the left and right motors of the Tank Bot.
left_motor = Motor(Port.A, Direction.COUNTERCLOCKWISE)
right_motor = Motor(Port.D, Direction.COUNTERCLOCKWISE)

# The wheel diameter of the Tank Bot is about 54 mm.
WHEEL_DIAMETER = 54

# The axle track is the distance between the centers of each of the
# wheels.  This is about 200 mm for the Tank Bot.
AXLE_TRACK = 200

# The Driving Base is comprised of 2 motors.  There is a wheel on each
# motor.  The wheel diameter and axle track values are used to make the
# motors move at the correct speed when you give a drive command.
robot = DriveBase(left_motor, right_motor, WHEEL_DIAMETER, AXLE_TRACK)

SPEED_SCALE = 6  # Scale factor for speed (768 // 127)
TURN_SCALE = 2  # Scale factor for turn rate (320 // 127)

# Storage for incoming messages from remote control.
msg_buf = bytearray(2)    
msg_buf_view = memoryview(msg_buf)

# Tracks the next-to-be-filled index in msg_buf.
cur_idx = 0

async def main():
    sock = RFCOMMSocket()
    print('Local address: ', local_address())
    ev3.light.on(Color.RED)
    print('Waiting for connection...')
    await sock.listen()
    print('Connected!')
    ev3.light.on(Color.GREEN)

    timeout = StopWatch()
    cur_idx = 0
    while timeout.time() < 100:
        cur_idx += sock.readinto(msg_buf_view[cur_idx:], len(msg_buf) - cur_idx)

        if cur_idx != len(msg_buf):
            # We were not able to read the entire message. Loop again.
            await wait(1)
            continue

        timeout.reset()
        axis1, axis2 = ustruct.unpack('>bb', msg_buf)
        cur_idx = 0

        speed = axis2 * SPEED_SCALE  # -768 to +768 mm/s
        turn_rate = axis1 * TURN_SCALE  # -320 to +320 deg/s
        robot.drive(speed, turn_rate)

    robot.stop()
    print('Client disconnected or timed out.')
    sock.close()

run_task(main())

jaguilar · 2026-01-18T22:21:41Z

I understand now. i can reproduce. I'll figure it out!

jaguilar · 2026-01-18T22:29:48Z

Should be fixed after latest commit.

BertLindeman · 2026-01-18T22:31:39Z

tomorrow for me. You are quick. Thanks!

jaguilar · 2026-01-19T05:53:59Z

~~Complaints about CI~~

Nevermind, forgot that CI builds each commit.

This implements the complete RFCOMM socket API, including listen, connect, send and recv. This does not contain python bindings for the API. Tested via manual ping-pong testing for both listen and connect, against a Windows desktop. EV3<->EV3 not yet tested.

Separate RFCOMM handling into its own packet handler. Drop separate HCI event handler for classic security events.

BertLindeman · 2026-01-19T08:28:56Z

Should be fixed after latest commit.

Fixed this scenario:

run the tank_rc program
press the EV3 back button
run the tank_rc program
and get "already listening"

Log:

C:\Users\bert\py\pybricks>pybricksdev run usb  ..\EV3\tankbot_rc_james.py
{'pybricks.hubs', 'pybricks.ev3devices', 'pybricks.messaging', 'pybricks.parameters', 'ustruct', 'pybricks.robotics', 'pybricks.tools', 'pybricks', 'micropython'}
{'pybricks.hubs', 'pybricks.ev3devices', 'pybricks.messaging', 'pybricks.parameters', 'ustruct', 'micropython', 'pybricks.robotics', 'pybricks.tools', 'pybricks'}
100%|██████████████████████████████████████████████████████████████████████████████████████████████████| 1.16k/1.16k [00:00<00:00, 582kB/s]
         ('ev3', '4.0.0b3', 'ci-build-4633-v4.0.0b3-110-gcddb1c86 on 2026-01-19')

Local address:  A0:E6:F8:E4:42:36
Waiting for connection...
Loaded 0 link keys from settings
[btc:rfcomm_listen] Listening for incoming RFCOMM connections...
The program was stopped (SystemExit).

C:\Users\bert\py\pybricks>pybricksdev run usb  ..\EV3\tankbot_rc_james.py
{'pybricks.robotics', 'pybricks', 'pybricks.messaging', 'pybricks.hubs', 'pybricks.tools', 'micropython', 'pybricks.parameters', 'ustruct', 'pybricks.ev3devices'}
{'pybricks.robotics', 'pybricks', 'pybricks.messaging', 'pybricks.hubs', 'pybricks.tools', 'micropython', 'pybricks.parameters', 'ustruct', 'pybricks.ev3devices'}
100%|██████████████████████████████████████████████████████████████████████████████████████████████████| 1.16k/1.16k [00:00<00:00, 386kB/s]
         ('ev3', '4.0.0b3', 'ci-build-4633-v4.0.0b3-110-gcddb1c86 on 2026-01-19')

Local address:  A0:E6:F8:E4:42:36
Waiting for connection...
[btc:rfcomm_listen] Listening for incoming RFCOMM connections...
The program was stopped (SystemExit).

Move to UARTDevice API.

jaguilar · 2026-01-20T19:51:00Z

As requested, migrated to use a UARTDevice workalike API. I ran brief tests with my remote control models and everything appears to still be working.

BertLindeman · 2026-01-20T20:53:50Z

Now testing with ('ev3', '4.0.0b3', 'ci-build-4634-v4.0.0b3-112-g068df580 on 2026-01-20')

I assume a test on a primehub is too soon?
With this commit we dropped the readinto Is that as intended?
It seemed easy to use.

jaguilar · 2026-01-20T22:54:09Z

@BertLindeman Sorry for the trouble. I've pushed a new commit to the pybricks-projects repo that shows how to use the reformulated API. The new API is actually simpler to use than what was there before, although it does create a bit more garbage.

Fix bugs: * `gap_connectable_control` cannot be used for this purpose. * We were granting too many credits and the code was more complicated than needed. * Some comments were over-verbose. * Remove one unnecessary pbio_os_request_poll.

BertLindeman · 2026-01-21T08:18:53Z

@BertLindeman Sorry for the trouble. I've pushed a new commit to the pybricks-projects repo that shows how to use the reformulated API. The new API is actually simpler to use than what was there before, although it does create a bit more garbage.

No problem at all.
Code looks much simpler indeed.

Let me know if you think a basic test on a primehub makes sense.

[EDIT]
On firmware ('ev3', '4.0.0b3', 'ci-build-4638-v4.0.0b3-113-g9add495b on 2026-01-21')
Running tankbot_rc.py on the EV3 I get
AttributeError: 'RFCOMMSocket' object has no attribute 'close' on line 75 sock.close()

If I do a dir(RFCOMMSocket) it does not show close.

Complete log of the tankbot_rc run

C:\Users\bert\py\pybricks\issue_2274_rfcomm>pybricksdev run usb tankbot_rc.py
rted 14/7
hci.c.2593: Command 0x03 supported 18/3
hci.c.2593: Command 0x04 supported 20/4
hci.c.2593: Command 0x06 supported 24/6
hci.c.2598: Local supported commands summary 0000005f
btstack_crypto.c.1121: controller supports ECDH operation: 0
hci.c.2722: Local Address, Status: 0x00: Addr: A0:E6:F8:E4:42:36
hci.c.2640: hci_read_buffer_size: ACL size module 1021 -> used 1021, count 4 / SCO size 180, count 4
hci.c.2756: Packet types cc18, eSCO 1
hci.c.2759: BR/EDR support 1, LE support 0
{'pybricks.ev3devices', 'pybricks.tools', 'pybricks.messaging', 'pybricks.robotics', 'ustruct', 'micropython', 'pybricks.hubs', 'pybricks.parameters'}
{'pybricks.ev3devices', 'pybricks.tools', 'pybricks.messaging', 'pybricks.robotics', 'ustruct', 'micropython', 'pybricks.hubs', 'pybricks.parameters'}
100%|██████████████████████████████████████████████████████████████████████████████████████████████████| 1.00k/1.00k [00:00<00:00, 501kB/s]
hci.c.1770:Local address:  A0:E6:F8:E4:42:36
Waiting for connection...
Loaded 0 link keys from settings
[btc:rfcomm_listen] Listening for incoming RFCOMM connections...
hci.c.3431: Connection_incoming: 8C:90:2D:41:E4:60, type 1
hci.c.312: create_connection_for_addr 8C:90:2D:41:E4:60, type fd
hci.c.6672: sending hci_accept_connection_request
hci.c.3457: Connection_complete (status=0) 8C:90:2D:41:E4:60
hci.c.3494: New connection: handle 1, 8C:90:2D:41:E4:60
hci.c.7505: BTSTACK_EVENT_NR_CONNECTIONS_CHANGED 1
IDENTITY_RESOLVING_STARTED
sm.c.2269: LE Device Lookup: not found
IDENTITY_RESOLVING_FAILED
hci.c.506: pairing started, ssp 1, initiator 0, requested level 2
hci.c.7677: gap_mitm_protection_required_for_security_level 2
hci.c.6736: Remote not bonding, dropping local flag
SSP User Confirmation Request. Auto-accepting...
hci.c.528: pairing complete, status 00
Link key updated, saving to settings.
Saved 0 link keys to settings
sm.c.3900: Encryption state change: 1, key size 0
sm.c.3902: event handler, state 82
hci.c.2788: Handle 0001 key Size: 16
hci.c.7536: hci_emit_security_level 2 for handle 1
l2cap.c.2833: security level update for handle 0x0001
l2cap.c.3633: extended features mask 0xba
l2cap.c.3649: fixed channels mask 0x8a
l2cap.c.2460: create channel c007e754, local_cid 0x0041
hci.c.2509: Remote features 03, bonding flags 70
l2cap.c.2822: remote supported features, channel c007e754, cid 0041 - state 4
l2cap.c.1159: L2CAP_EVENT_INCOMING_CONNECTION addr 8C:90:2D:41:E4:60 handle 0x1 psm 0x3 local_cid 0x41 remote_cid 0x40
rfcomm.c.382: rfcomm_max_frame_size_for_l2cap_mtu:  1691 -> 1686
rfcomm.c.1074: RFCOMM incoming (l2cap_cid 0x41) => accept
l2cap.c.3131: L2CAP_ACCEPT_CONNECTION local_cid 0x41
l2cap.c.1404: l2cap_stop_rtx for local cid 0x41
l2cap.c.1441: l2cap_start_rtx for local cid 0x41
l2cap.c.3359: L2CAP signaling handler code 4, state 11
l2cap.c.3187: Remote MTU 1017
l2cap.c.3359: L2CAP signaling handler code 5, state 11
l2cap.c.1404: l2cap_stop_rtx for local cid 0x41
l2cap.c.3289: l2cap_signaling_handle_configure_response
l2cap.c.1129: L2CAP_EVENT_CHANNEL_OPENED status 0x0 addr 8C:90:2D:41:E4:60 handle 0x1 psm 0x3 local_cid 0x41 remote_cid 0x40 local_mtu 1691, remote_mtu 1017, flush_timeout 0
rfcomm.c.1101: channel opened, status 0
rfcomm.c.382: rfcomm_max_frame_size_for_l2cap_mtu:  1691 -> 1686
rfcomm.c.1219: Received SABM #0
rfcomm.c.1364: Sending UA #0
rfcomm.c.941: Multiplexer up and running
rfcomm.c.1640: Received UIH Parameter Negotiation Command for #2, credits 7
rfcomm.c.509: rfcomm_channel_create for service c007e430, channel 1 --- list of channels:
rfcomm.c.1997: -> Inform app
rfcomm.c.247: RFCOMM_EVENT_INCOMING_CONNECTION addr 8C:90:2D:41:E4:60 channel #1 cid 0x01
rfcomm.c.2628: accept cid 0x01
rfcomm.c.2025: Sending UIH Parameter Negotiation Respond for #2
rfcomm.c.1782: rfcomm_channel_ready_for_incoming_dlc_setup state var 00000003
rfcomm.c.1607: Received SABM #2
rfcomm.c.2029: Sending UA #2
rfcomm.c.1782: rfcomm_channel_ready_for_incoming_dlc_setup state var 00000007
rfcomm.c.2034: Incomping setup done, requesting send MSC CMD and send Credits
rfcomm.c.1942: Sending MSC CMD for #2
rfcomm.c.2123: Providing credits for #2
rfcomm.c.1773: rfcomm_channel_ready_for_open state 8, flags needed 0010, current 00014007, rf credits 7
rfcomm.c.1660: Received MSC CMD for #2,
Received unknown RFCOMM event: 135
rfcomm.c.1773: rfcomm_channel_ready_for_open state 8, flags needed 0010, current 0001500f, rf credits 7
rfcomm.c.1949: Sending MSC RSP for #2
rfcomm.c.1667: Received MSC RSP for #2
rfcomm.c.1773: rfcomm_channel_ready_for_open state 8, flags needed 0010, current 0001c01f, rf credits 7
rfcomm.c.1410: opened
rfcomm.c.265: RFCOMM_EVENT_CHANNEL_OPENED status 0x0 addr 8C:90:2D:41:E4:60 handle 0x1 channel #1 cid 0x01 mtu 1011
RFCOMM channel opened: cid=1.
rfcomm.c.2667: grant cid 0x01 credits 4
Received unknown RFCOMM event: 136
[btc:rfcomm_listen] Connected
Connected!
Client disconnected or timed out.
Traceback (most recent call last):
  File "tankbot_rc.py", line 75, in <module>
  File "tankbot_rc.py", line 73, in main
AttributeError: 'RFCOMMSocket' object has no attribute 'close'
rfcomm.c.2553: disconnect cid 0x01
rfcomm.c.1613: Received UA #2
rfcomm.c.291: RFCOMM_EVENT_CHANNEL_CLOSED cid 0x01

jaguilar · 2026-01-21T15:38:26Z

I think it would be interesting -- I'm going to work up a quick test script that exercises the whole class a little more thoroughly, including simultaneous communication on the channel and some throughput and latency tests. After I put that up it might be fun to run one copy of the test script on a spike and the other copy on an EV3 and see how it goes.

BertLindeman · 2026-01-21T16:11:27Z

Did you notice the missing close method, also on the EV3?
Or is a del sock the future?

Looking forward to the tests.

jaguilar · 2026-01-21T16:18:54Z

I didn't notice it. I'll make sure to test that functionality in the test and then we'll be more assured of catching this in the future. In the mean time, if you do

with RFCOMMSocket() as sock:
  ...

It will have the same effect as close() when you exit the scope.

BertLindeman · 2026-01-21T16:27:36Z

I didn't notice it. I'll make sure to test that functionality in the test and then we'll be more assured of catching this in the future. In the mean time, if you do
with RFCOMMSocket() as sock:
  ...
It will have the same effect as close() when you exit the scope.

Better coding technique also. Thanks.

Adds back the `close()` method to RFCOMMSocket. Adds certain useful debug printing.

jaguilar · 2026-01-21T19:14:05Z

close() added back in the latest fixup commit.

Testing

Try using one brick to run tests/rfcomm_test_follower.py, and then note the bd address. Edit tests/rfcomm_test_leader.py to use the bdaddr from the follower, and then run it on another brick. You should see output like this:

Leader starting.
My Address: 24:71:89:5A:03:23
Connecting to F0:45:DA:13:1C:8A...
Connected.

Test 1: Message Order
  Sending 5 messages...
  Reading messages...
  Packet 1: OK
  Packet 2: OK
  Packet 3: OK
  Packet 4: OK
  Packet 5: OK

Test 2: Throughput
  Packet size: 1024 (Header: 3 + Payload: 1021)
  Result: 93 KB/s (Sent: 93, Recv: 93)

Test 3: RTT (40 samples)
  RTT Mean: 11.38 ms
  RTT 90% CI: +/- 0.18 ms

Test 4: Flow Control
  Sending BLOCK for 500ms
  Bytes sent during 500ms block window: 5120
  Flow Control: PASS

Test 5: waiting and read_all
  waiting: PASS
  read_all: PASS

Test 6: wait_until
  wait_until: PASS

Test 7: clear
  clear: PASS
Leader finished.

jaguilar · 2026-01-22T03:14:25Z

I think there are a few open questions where we need a decision about what to do from the maintainers.

Up 'til now, we've been trying to keep all the btstack bluetooth code in one file. In light of this PR, do we want to continue with that? If not, what unit of splitting would you like. I can split the following components:
- The RFCOMM socket system.
- The bluetooth classic handlers.
- The link key database.
- Any combination of the above.
Do you feel that more testing is needed? Is the API adequate to be merged? I feel that this is tested about as well as most things in pybricks but I would welcome instructions on what additional tests if any to add.
Any other feedback about this PR, broad changes you'd like to see, etc.?

To my taste this PR is done-ish. I would enjoy feedback on what stands between the PR and merging.

BertLindeman · 2026-01-22T14:17:02Z

Have not seen this commit in the CI buildds

laurensvalk · 2026-01-22T14:28:21Z

I'm wondering if the CI build is actually incorporating all the commits. @laurensvalk do you know if there is a way to check that?

You can check the current version/hash in the REPL. There should be only one definitive git history leading up to that.

One gotcha is that the hash in PR builds is the hash for GitHub's would-be merge commit, so it appears not to correspond to any branch. That history is still browseable through GitHub, though.

Or you can use the on-branch build which also runs. I usually do this to keep track of things, though only for rare cases where I suspect issues due to different compiler versions.

jaguilar · 2026-01-22T14:45:45Z

My guess is it is not building due to the conflicts we'd need to resolve before merging. I'll rebase at some point. In the mean time, @BertLindeman, if you do want to try it, you could check out my fork and build from that.

BertLindeman · 2026-01-22T14:48:35Z

My guess is it is not building due to the conflicts we'd need to resolve before merging. I'll rebase at some point. In the mean time, @BertLindeman, if you do want to try it, you could check out my fork and build from that.

Will try 😉

jaguilar · 2026-01-22T17:41:04Z

Did some testing with the virtual hub this morning. Unfortunately, nto much progress. My virtual hub does not appear to be working even in the basics. I tried bluetooth_scan and it couldnt' see my iPhone. (Will have to try the same on the EV3 and see if I get a different result -- more on that tonight.)

jaguilar force-pushed the ev3-bluetooth-rfcomm branch 3 times, most recently from 23477a9 to 29f1254 Compare January 15, 2026 20:34

jaguilar added 3 commits January 18, 2026 10:28

cleanup: Add clangd cache to .gitignore.

284523e

pbdrv/bluetooth: Temporarily enable debugging.

1098584

pybricks: memoryview in extra_level2.

172feea

This class is useful for rfcomm communication, specifically the readinto function.

jaguilar force-pushed the ev3-bluetooth-rfcomm branch from 29f1254 to 0b1bc47 Compare January 18, 2026 17:28

laurensvalk marked this pull request as ready for review January 18, 2026 21:04

jaguilar force-pushed the ev3-bluetooth-rfcomm branch from fbba1f5 to fb7c900 Compare January 19, 2026 06:06

fixup! pbdrv/bluetooth: RFCOMM socket API.

1324ac3

Separate RFCOMM handling into its own packet handler. Drop separate HCI event handler for classic security events.

fixup! pbdrv/bluetooth: RFCOMM socket API.

d0cd095

Move to UARTDevice API.

fixup! pbdrv/bluetooth: RFCOMM socket API.

ab2c7bd

Fix bugs: * `gap_connectable_control` cannot be used for this purpose. * We were granting too many credits and the code was more complicated than needed. * Some comments were over-verbose. * Remove one unnecessary pbio_os_request_poll.

jaguilar added 2 commits January 21, 2026 11:28

fixup! pbdrv/bluetooth: RFCOMM socket API.

bb5c41c

Adds back the `close()` method to RFCOMMSocket. Adds certain useful debug printing.

tests/bluetooth: Add test script for RFCOMM.

38fad7e

Uh oh!

Bluetooth classic RFCOMM communication support #452

Are you sure you want to change the base?

Bluetooth classic RFCOMM communication support #452

Conversation

jaguilar commented Jan 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

TODO

Uh oh!

BertLindeman commented Jan 15, 2026

Uh oh!

jaguilar commented Jan 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jaguilar commented Jan 15, 2026

Uh oh!

BertLindeman commented Jan 16, 2026

Uh oh!

jaguilar commented Jan 16, 2026

Uh oh!

BertLindeman commented Jan 17, 2026

Uh oh!

BertLindeman commented Jan 17, 2026

Uh oh!

jaguilar commented Jan 17, 2026

Uh oh!

jaguilar commented Jan 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jaguilar commented Jan 18, 2026

Uh oh!

BertLindeman commented Jan 18, 2026

Uh oh!

jaguilar commented Jan 18, 2026

Uh oh!

laurensvalk commented Jan 18, 2026

Uh oh!

jaguilar commented Jan 18, 2026

Uh oh!

BertLindeman commented Jan 18, 2026

Uh oh!

jaguilar commented Jan 18, 2026

Uh oh!

jaguilar commented Jan 18, 2026

Uh oh!

BertLindeman commented Jan 18, 2026

Uh oh!

jaguilar commented Jan 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

BertLindeman commented Jan 19, 2026

Uh oh!

jaguilar commented Jan 20, 2026

Uh oh!

BertLindeman commented Jan 20, 2026

Uh oh!

jaguilar commented Jan 20, 2026

Uh oh!

BertLindeman commented Jan 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jaguilar commented Jan 21, 2026

Uh oh!

BertLindeman commented Jan 21, 2026

Uh oh!

jaguilar commented Jan 21, 2026

Uh oh!

BertLindeman commented Jan 21, 2026

Uh oh!

jaguilar commented Jan 21, 2026

Testing

Uh oh!

jaguilar commented Jan 22, 2026

Uh oh!

BertLindeman commented Jan 22, 2026

Uh oh!

laurensvalk commented Jan 22, 2026

Uh oh!

jaguilar commented Jan 22, 2026

Uh oh!

jaguilar commented Jan 15, 2026 •

edited

Loading

jaguilar commented Jan 15, 2026 •

edited

Loading

jaguilar commented Jan 18, 2026 •

edited

Loading

jaguilar commented Jan 19, 2026 •

edited

Loading

BertLindeman commented Jan 21, 2026 •

edited

Loading