Sending messages to the watch seems pretty slow

[matejdro]

I've been playing around with PebbleKit Android (#16) and it appears that BLE connection is pretty slow, much slower than the classic connection back in the day.

It seems the round trip AppMessage data from the phone -> Appmessage ACK to phone takes around 200-300ms and quite frequently much longer (if I remember correctly, it was consistently in low hundreds of ms back in the day).

For example, here is a log from one such instance, where the round trip took over 500ms:

2025-10-05 20:14:13.886 sending AppMessagePush(uuid=StructElement(size=16, linkedSize=null, value=0a7575eb-e5b9-456b-8701-3eacb62d74f1), count=StructElement(size=1, linkedSize=null, value=4), dictionary=SFixedList(list=[AppMessageTuple(key=StructElement(size=4, linkedSize=null, value=0), type=StructElement(size=1, linkedSize=null, value=2), dataLength=StructElement(size=2, linkedSize=null, value=1), data=SBytes(value=[4], size=1)), AppMessageTuple(key=StructElement(size=4, linkedSize=null, value=1), type=StructElement(size=1, linkedSize=null, value=2), dataLength=StructElement(size=2, linkedSize=null, value=1), data=SBytes(value=[0], size=1)), AppMessageTuple(key=StructElement(size=4, linkedSize=null, value=2), type=StructElement(size=1, linkedSize=null, value=0), dataLength=StructElement(size=2, linkedSize=null, value=3), data=SBytes(value=[0, 5, 0], size=3)), AppMessageTuple(key=StructElement(size=4, linkedSize=null, value=3), type=StructElement(size=1, linkedSize=null, value=0), dataLength=StructElement(size=2, linkedSize=null, value=76), data=SBytes(value=[68, 105, 115, 109, 105, 115, 115, 32, 45, 32, 80, 104, 111, 110, 101, 0, 0, 0, 0, 68, 105, 115, 109, 105, 115, 115, 32, 45, 32, 80, 101, 98, 98, 108, 101, 0, 0, 0, 79, 112, 101, 110, 32, 111, 110, 32, 112, 104, 111, 110, 101, 0, 0, 0, 0, 0, 0, 77, 117, 116, 101, 32, 97, 112, 112, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], size=76))]))
2025-10-05 20:14:13.891 sendPacketImmediately: Data(sequence=27, data=[0, -128, 0, 48, 1, 58, 10, 117, 117, -21, -27, -71, 69, 107, -121, 1, 62, -84, -74, 45, 116, -15, 4, 0, 0, 0, 0, 2, 1, 0, 4, 1, 0, 0, 0, 2, 1, 0, 0, 2, 0, 0, 0, 0, 3, 0, 0, 5, 0, 3, 0, 0, 0, 0, 76, 0, 68, 105, 115, 109, 105, 115, 115, 32, 45, 32, 80, 104, 111, 110, 101, 0, 0, 0, 0, 68, 105, 115, 109, 105, 115, 115, 32, 45, 32, 80, 101, 98, 98, 108, 101, 0, 0, 0, 79, 112, 101, 110, 32, 111, 110, 32, 112, 104, 111, 110, 101, 0, 0, 0, 0, 0, 0, 77, 117, 116, 101, 32, 97, 112, 112, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0])
2025-10-05 20:14:14.384 received packet: Ack(sequence=26)
2025-10-05 20:14:14.385 received packet: Data(sequence=14, data=[0, 2, 0, 48, -1, 58])
2025-10-05 20:14:14.387 sendPacketImmediately: Ack(sequence=14)
2025-10-05 20:14:14.390 inbound pebble protocol packet: io.rebble.libpebblecommon.packets.AppMessage$AppMessageACK@1b
2025-10-05 20:14:14.395 Result from the app: io.rebble.libpebblecommon.services.appmessage.AppMessageResult$ACK@a78bfda
2025-10-05 20:14:14.399 sent broadcast com.getpebble.action.app.RECEIVE_ACK 58

This was tested with the Pebble Time.

Delay appears to be on the watch side (between us sending the data and and us receiving the data). Is there anything we can do? If not, do the new watches behave better?

[ericmigi]

Would be interesting to compare with a Pebble 2 - which used BLE exclusively.

FWIW we haven't looked at optimizing BLE speed yet (on either libpebble3 or Asterix/PebbleOS)

[matejdro]

I agree, will test this as soon as new buttons arrive for my P2 (they finally disintigrated 2 clicks after taking them out of the closet for this development).

[sjp4]

If you're sending several messages in a burst, have you tried using app_comm_set_sniff_interval? (I don't remember if this works with BLE as well as classic, but if it does, then it would lower the connection interval, reducing roundtrip time while it is active)

[matejdro]

Yes, I'm doing this all the time.

Although, I have noticed two things:

• A person with a Samsung phone reported that it's pretty snappy on their end (with the PTR), so the issue could be linked to the Pixel phone's bluetooth stack
• It seems the longest delays happen when bluetooth has been idle for a while (which kinda makes sense, but it's still annoying UX, if first packet after leaving watch idle for a few seconds, needs 500ms to reach the phone)

[matejdro]

Yeah, P2 seems much better in this regard. I guess it just means that older watches had worse LE stack?