pbio/drv/bluetooth: Broadcast on the Move Hub while connected. - #504
Open
dlech wants to merge 1 commit into
Open
pbio/drv/bluetooth: Broadcast on the Move Hub while connected.#504dlech wants to merge 1 commit into
dlech wants to merge 1 commit into
Conversation
Member
Author
|
Note, this doesn't completely fix things on it's own. It will need to be rebased once #500 is merged. So until then, use https://github.com/pybricks/pybricks-micropython/actions/runs/34675375120 for test firmware instead of the link in the comment below. |
The BlueNRG-MS GAP layer refuses to enter any advertising mode while a computer is connected, so aci_gap_set_non_connectable() answered BLE_STATUS_FAILED and nothing was broadcast. The driver mapped that one error to success so that programs using broadcasting could at least run. Drive the link layer directly instead, with the set advertising parameters, set advertising data and set advertise enable sequence from UM1865 section 3.3. The chip is already configured for role mode 4, which supports advertising alongside connections and scanning, and it accepts all three commands while a computer is connected. Asking the chip first was no help: HCI_LE_Read_Supported_States answers with bit 20 clear, but it also claims not to support advertising while scanning and not to support scanning while a slave, both of which demonstrably work, so its answer understates what this stack can do. Advertising is now enabled behind the GAP layer's back, so stopping has to disable it the same way, and the discoverable mode has to be left before the parameters can be set. The link layer advertises exactly the payload it is given, so the service UUID and TX power AD types left over from discovery no longer have to be deleted to make room. Broadcasts therefore no longer carry the Flags AD type, which is what the BTstack hubs already send. The advertising interval has to be requested as a range. The chip fits a new activity to the anchor period it is already running for the connection and for any scanning, and answers 0x85 BLE_STATUS_INTERVAL_TOO_LARGE when no multiple of that period falls between the requested minimum and maximum. A fixed 100ms therefore failed the moment the hub was also observing or connected, which is precisely the case being fixed here. The GAP layer picked its own range internally and so never ran into it. 100ms is the fastest this Bluetooth 4.1 controller allows for non-connectable advertising and is the bottom of the range; 200ms at the top measures the same as the GAP layer managed, 2.45 against 2.53 broadcasts a second reaching a third hub, which is inside the run to run spread. Drop the note about broadcasting interfering with observing as well. Measured on a Move Hub with the 50% scan duty cycle, reception is unchanged by broadcasting at the same time: 13.4 advertisements a second from a reference transmitter either way, with the same distribution of gaps. That measurement depends on the duty cycle, so this belongs after that change. Fixes pybricks/support#2826
dlech
force-pushed
the
movehub-broadcast-while-connected
branch
from
September 12, 2026 15:05
a8f7207 to
835dacf
Compare
Member
Author
Done |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The BlueNRG-MS GAP layer refuses to enter any advertising mode while a computer is connected, so aci_gap_set_non_connectable() answered BLE_STATUS_FAILED and nothing was broadcast. The driver mapped that one error to success so that programs using broadcasting could at least run.
Drive the link layer directly instead, with the set advertising parameters, set advertising data and set advertise enable sequence from UM1865 section 3.3. The chip is already configured for role mode 4, which supports advertising alongside connections and scanning, and it accepts all three commands while a computer is connected. Asking the chip first was no help: HCI_LE_Read_Supported_States answers with bit 20 clear, but it also claims not to support advertising while scanning and not to support scanning while a slave, both of which demonstrably work, so its answer understates what this stack can do.
Advertising is now enabled behind the GAP layer's back, so stopping has to disable it the same way, and the discoverable mode has to be left before the parameters can be set. The link layer advertises exactly the payload it is given, so the service UUID and TX power AD types left over from discovery no longer have to be deleted to make room. Broadcasts therefore no longer carry the Flags AD type, which is what the BTstack hubs already send.
The advertising interval has to be requested as a range. The chip fits a new activity to the anchor period it is already running for the connection and for any scanning, and answers 0x85
BLE_STATUS_INTERVAL_TOO_LARGE when no multiple of that period falls between the requested minimum and maximum. A fixed 100ms therefore failed the moment the hub was also observing or connected, which is precisely the case being fixed here. The GAP layer picked its own range internally and so never ran into it. 100ms is the fastest this Bluetooth 4.1 controller allows for non-connectable advertising and is the bottom of the range; 200ms at the top measures the same as the GAP layer managed, 2.45 against 2.53 broadcasts a second reaching a third hub, which is inside the run to run spread.
Drop the note about broadcasting interfering with observing as well. Measured on a Move Hub with the 50% scan duty cycle, reception is unchanged by broadcasting at the same time: 13.4 advertisements a second from a reference transmitter either way, with the same distribution of gaps. That measurement depends on the duty cycle, so this belongs after that change.
Fixes pybricks/support#2826