Split BLE follow up work

[petejohanson]

There are some outstanding items in the implementation of the split BLE support that need to be work on:

• Fix BT pairing from host once halves are paired.
• Restore BT_SETTINGS usage to ensure pairing is saved, avoid future MiTMs.
• Peripheral side should stop advertising after the central hub is properly connected and subscribed, and resume advertising when disconnected
• Initial connection between central and peripheral is not always working, and is timing dependent on when each side starts. Need investigation
• We have occasional timing issues with keypress being sent "out of order" between central and peripheral side. Need to possibly add a delay of (intervalMin + intervalMax) / 2 / 2 on the central to give peripheral key press events to have time to process.
• Use a dynamic length data for the key press state attribute/notifications from peripheral to central hub, to reduce BLE payload size.
• Low Priority: Add "dynamic central/peripheral role" support, instead of fixed role for left/right sides.

[Nicell]

One thing to help improve the connection between the two halves is to enable 2Mbps PHY.

Pros:

• Slightly faster transmission due to 2Mbps speed instead of 1Mbps
• Less power usage to send the same amount of data due to less time needed blasting the radio (Nordic power profiler shows about a 20% reduction in power used to transmit)

Cons:

• The signal degrades more quickly hurting range. This should be fine as the halves are always extremely close to each other.
• Only BLE devices can connect, no BT classic. This is fine since we control both halves

[mhbkamaei]

Hi there,
any progress on last item? dynamic central/peripheral role would be nice, specially for Switching between dongle setup (3 device with dongle as central) to dongleless setup (2 device with left or right as central) and of course balancing battery drain.
as one of main ZMK's goal is to provide a WIRELESS firmware, which means battery matters, why Low Priority?

[Nick-Munnich]

Hi there, any progress on last item? dynamic central/peripheral role would be nice, specially for Switching between dongle setup (3 device with dongle as central) to dongleless setup (2 device with left or right as central) and of course balancing battery drain. as one of main ZMK's goal is to provide a WIRELESS firmware, which means battery matters, why Low Priority?

Hi, there are a number of features which have higher priority than this would have: ZMK studio, pointing work, wired split, etc. This is also a much more complex feature than it may seem. Contributions are always welcome though, if you wanted to give it a shot.