[
https://issues.apache.org/jira/browse/MYNEWT-526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15899366#comment-15899366
]
Łukasz Rymanowski commented on MYNEWT-526:
------------------------------------------
Hi Jacob,
Ok, there is PR for bad calculations.
When it comes to other places where we could mess up with parameters - I did
double check and it looks good.
Thanks for Wireshark logs as it shows actually what is happening - let me
describe it:
1. Connection is created at frame #1352 with params (win_size=1, win_off=0,
interval=50ms , timeout=2560ms, latency=0)
2. Then you can see master sending connection events every 50ms which is good.
Slave is responding on it as it should.
3. at #3790 L2CAP Connection parameter update req is sent by Slave
(min_int=312.5ms, max_int=500ms, timeout=6000ms, latency=1))
4. at #3797 Master sends LL_CONNECTION_UPDATE_IND with parameters(win_size=1,
win_off=0, interval=500ms, timeout=6000ms, latency=1, instance=613)
Note that instance is the connection event index from which
parameters are really applied.
5. at #3799 Master sends L2CAP Connection parameter update response with status
Accepted.
6. starting from #3811 (connection event index 613), Master starts to send
connection events with new interval which is 500ms
7. at #3812 we can see last slave response on connection event
8. from #3813 - #3824 master sends connection events every 500ms and there is
no slave response in the air therefore link is dropped.
Looking on this it seems to be Polar HR issue, but it is very odd that Polar
would require parameters which later would not be able to handle correctly.
I should be able to get Polar HR H7 really soon and try to test it by myself.
Stay tuned.
> Gap params update succeeds, but times out immediately after
> -----------------------------------------------------------
>
> Key: MYNEWT-526
> URL: https://issues.apache.org/jira/browse/MYNEWT-526
> Project: Mynewt
> Issue Type: Bug
> Components: Nimble
> Affects Versions: v1_0_0_beta1
> Environment: macos sierra, gcc version 5.4.1 20160919
> Reporter: Jacob
> Assignee: Łukasz Rymanowski
>
> Modification of blecent, connecting and subscribing to my polar HRM.
> My monitor (consistently) connects and subscribes and gets notifications for
> like 30 seconds before it does a successful gap params update, and then
> promptly times out.
> I havent confirmed this yet but grammar wise you do seem to be mixing terms,
> timeout_multiplier and supervision_timeout are separate things in the spec
> l2cap_params->timeout_multiplier = params->supervision_timeout;
> Perhaps the timeout_multiplier should be multiplied by 10ms to get the
> supervision_timeout?
> 3924:[ts=30656208ssb, mod=4 level=0] rxed att command: notify req; conn=1
> handle=0x0011
> 3926:[ts=30671832ssb, mod=64 level=1] received notification; conn_handle=1
> attr_handle=17 attr_len=4
> 3928:[ts=30687456ssb, mod=64 level=1] 0x16:0x00:0xee:0x02
> 3929:[ts=30695268ssb, mod=64 level=1] pkthdr_len=16; om_len=4
> ble_hs_hci_evt_acl_process(): handle=1 pb=2 len=13 data=0x09 0x00 0x04 0x00
> 0x1b 0x11 0x00 0x16 0x55 0xda 0x02 0xc9 0x02
> 4052:[ts=31656208ssb, mod=4 level=0] rxed att command: notify req; conn=1
> handle=0x0011
> 4054:[ts=31671832ssb, mod=64 level=1] received notification; conn_handle=1
> attr_handle=17 attr_len=6
> 4056:[ts=31687456ssb, mod=64 level=1] 0x16:0x55:0xda:0x02:0xc9:0x02
> 4057:[ts=31695268ssb, mod=64 level=1] pkthdr_len=16; om_len=6
> ble_hs_hci_evt_acl_process(): handle=1 pb=2 len=16 data=0x0c 0x00 0x05 0x00
> 0x12 0x01 0x08 0x00 0xfa 0x00 0x90 0x01 0x01 0x00 0x58 0x02
> 4148:[ts=32406224ssb, mod=4 level=0] L2CAP - rxed signalling msg: 0x12 0x01
> 0x08 0x00 0xfa 0x00 0x90 0x01 0x01 0x00 0x58 0x02
> 4151:[ts=32429660ssb, mod=4 level=1] GAP procedure initiated: connection
> parameter update; conn_handle=1 itvl_min=250 itvl_max=400 latency=1
> supervision_timeout=600 min_ce_len=16 max_ce_len
> 4156:[ts=32468720ssb, mod=4 level=0] ble_hs_hci_cmd_send: ogf=0x08 ocf=0x13
> len=14
> 4158:[ts=32484344ssb, mod=4 level=0] 0x13 0x20 0x0e 0x01 0x00 0xfa 0x00 0x90
> 0x01 0x01 0x00 0x58 0x02 0x10 0x00 0x00 0x03
> 4159:[ts=32492156ssb, mod=4 level=0] Command Status: status=0 cmd_pkts=1
> ocf=0x13 ogf=0x8
> 4162:[ts=32515592ssb, mod=4 level=0] host tx hci data; handle=1 length=10
> 4163:[ts=32523404ssb, mod=4 level=0] ble_hs_hci_acl_tx(): 0x01 0x00 0x0a 0x00
> 0x06 0x00 0x05 0x00 0x13 0x01 0x02 0x00 0x00 0x00
> 4171:[ts=32585900ssb, mod=4 level=0] Number of Completed Packets:
> num_handles=1
> 4173:[ts=32601524ssb, mod=4 level=0] handle:1 pkts:1
> 4178:[ts=32640584ssb, mod=4 level=0] ble_hs_hci_evt_acl_process(): handle=1
> pb=2 len=11 data=0x07 0x00 0x04 0x00 0x1b 0x11 0x00 0x16 0x56 0xc0 0x02
> 4181:[ts=32664020ssb, mod=4 level=0] rxed att command: notify req; conn=1
> handle=0x0011
> 4183:[ts=32679644ssb, mod=64 level=1] received notification; conn_handle=1
> attr_handle=17 attr_len=4
> 4185:[ts=32695268ssb, mod=64 level=1] 0x16:0x56:0xc0:0x02
> 4186:[ts=32703080ssb, mod=64 level=1] pkthdr_len=16; om_len=4 LE Connection
> Update Complete. handle=1 itvl=400 latency=1 timeout=600
> 4978:[ts=38890568ssb, mod=4 level=0] Disconnection Complete: status=0
> handle=1 reason=8
> 4980:[ts=38906192ssb, mod=64 level=1] disconnect; reason=520 handle=1
> our_ota_addr_type=0 our_ota_addr=0c:0c:0c:0c:0c:0c our_id_addr_type=0
> our_id_addr=0c:0c:0c:0c:0c:0c peer_ota_addr_type=0
> peer_ota_addr=00:22:d0:2a:e4:a3 peer_id_addr_type=0
> peer_id_addr=00:22:d0:2a:e4:a3 conn_itvl=400 conn_latency=1
> supervision_timeout=600 encrypted=0 authenticated=0 bonded=0
> 4988:[ts=38968688ssb, mod=4 level=1] GAP procedure initiated: discovery;
> own_addr_type=0 filter_policy=0 passive=1 limited=0 filter_duplicates=1
> duration=forever
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
