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.

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

How to get current PHY mode #668

Open
henkelis opened this issue May 24, 2024 · 4 comments
Open

How to get current PHY mode #668

henkelis opened this issue May 24, 2024 · 4 comments

Comments

@henkelis
Copy link

Hi,

For my use case I want to get the current mode of a connection, to be able to display it (from the client side, but could also be from the server side). I also want to be able to change the mode after connection.

I've added functions to NimbleClient and NimbleServer to do that as follows (based on existing functions):

  • getLePhy - calls ble_gap_read_le_phy in ble_gap
  • setLePhy - calls ble_gap_set_prefered_le_phy in ble_gap

The functions work and I can get and set modes. Unfortunately when getting the modes for coded PHY, the BLE spec states to return just that it is coded, and not the actual mode (S2 or S8). The mode appears to be available in the low level connection data, but I can't work out how to get to that.

I can see HCI code that gets the PHY (ble_ll_conn_hci_le_rd_phy) and could cheat and return the mode in the top 4 bits alongside the phy, but my board (Adafruit Feather esp32-s3) provides precompiled bt libs so I would have to edit that source and recompile those libs.

Is there another way to get the actual mode?

Mark.

@h2zero
Copy link
Owner

h2zero commented May 24, 2024

Hello, you can assume it to be S8, S2 is almost never used.

@henkelis
Copy link
Author

Thanks.

I might actually set it to S2, it's a shame I can't prove that that's what it's set to at any point in the future (obviously I get a success code when I set it).

@h2zero
Copy link
Owner

h2zero commented May 24, 2024

Not sure why you'd want to use S2, you get half the data rate and almost no detectable difference in range, that's why it's not commonly used.

@henkelis
Copy link
Author

All the more reason to be able to detect if it's set :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants