• I think when I measured it at 7.5ms the average current is like 0.5mA and when set to hundreds ms it is like 0.01mA

    So one would maybe want a configuration where connection interval upon user interaction is generally at some hundreds ms but kicks down to 7.5 ms when much data transfer is happening or is expected?

    EDIT: But that also seems to already be the case - so an extra app seems less and less useful.

    As mentioned it is the activity of the watch (=running javascript) that draws much more. So when connected it is not BLE that is taking the power (unless it is at 7.5ms all the time) but possibly the data traffic triggering some activity in the watch making cpu busy.

    Ok - gotcha 👍

  • So one would maybe want a configuration where connection interval upon user interaction is generally at some hundreds ms but kicks down to 7.5 ms when much data transfer is happening or is expected?

    maybe. connection interval is the time when both devices wake and data is sent in one or possibly more packets at once, so if we have MTU of 131 and maybe 2-4 packets are sent in one connection interval (not sure about this now, it varies) then if more data than131-3=128*number of packets needs to be sent it will slow things down. So if you use 200ms and 2 packets are sent in one interval you have transfer rate of 2*128*(1000/200)=1280 bytes per second

    EDIT: oh, we still send only one packet per connection interval (in watch->phone direction) https://github.com/espruino/Espruino/blob/master/targets/nrf5x/bluetooth.c#L972 , this is maybe too conservative

About

Avatar for Ganblejs @Ganblejs started