Value from simpleble_peripheral_mtu() is not ATT_MTU size but max attribute data length

[eriklins]

ATT_MTU is equal to the max attribute data length + 3 (actually vice versa), so ATT_MTU size could be calculated, but would be good to get the actual ATT_MTU value. Actually it would be great if more connection parameters could be exposed by a SimpleBLE function, like ATT_MTU, attribute data length, event length, mix/max connection interval, slave latency, link supervision timeout. Not sure, what would be exposed by the underlying OS functions...

[kdewald]

Hey! On this one I specifically picked the return value of the mtu function to be "the maximum size of data you can exchange", as it's the value that most users (including myself) will need to use most of the time.

I'm open to using more explicit names or adding a function to return the ATT_MTU value, but in general I don't think it will be used that much.

About exposing all the remaining connection parameters, my take is a strong yes if you can find the documentation of how each operating system is exposing that value xD

[eriklins]

Technically there are three parameter: LL packet length (27-251), mtu size (23-247) and attribute data length (20-244). Not sure what the OS's expose. If it's just the att data length (which you chose to pick) then I would rename the function to something like simpleble_peripheral_att_data_len() or so. If the OS exposes more parameters, it would be great to expose these as well. Maybe just one function which puts all those connection related and negotiated parameters into some data structure?

If possible, would be cool to get connection parameters like max/min connection interval, supervision timeout, slave latency...

Would it be possible to set any of these parameter from SimpleBLE as well? Like setting mtu size according to what makes sense for a particular application and not just a fixed value the OS thinks is great.

[kdewald]

Depending on the OS, you either get the MTU size or the attribute data length, of which I decided to standardize to the attribute data length. Given that there's a constant 3 byte different between those two, do you think it makes sense to generate a separate function to for att_len and mtu?

If possible, would be cool to get connection parameters like max/min connection interval, supervision timeout, slave latency...

As far as I know they are not exposed by all operating systems (but I might be wrong, so feel free to dig into the documentation to find out)

Would it be possible to set any of these parameter from SimpleBLE as well? Like setting mtu size according to what makes sense for a particular application and not just a fixed value the OS thinks is great.

Right now this doesn't seem possible, I haven't seen any user-facing options to tweak this. I've always had to deal with this from the peripheral end.

[eriklins]

In most cases attribute data length is mtu size -3, but this is not mandatory. You can negotiate mtu size to a larger value but still e.g., use the default att data length of 20. Not sure if it would be important to expose both values by a function. In case of issues it might be good the be able to check both values from an application perspective.

[kdewald]

I see, the problem is that there's only one source and it's not consistent between OSes, so this is the best compromise we can get. You should look at how I've implemented this to get an idea of what I mean.

Feel free to go and bully Microsoft, Apple and the Bluez team to expose all the underlying parameters :D

So far, the next actionable step would be to rename mtu to att_mtu for correctness. Does that seem appropriate?