Looks like Chris and my responses crossed paths a bit here. However, I want to
clarify a few things:
1) All packets sent get sent with a 24-bit CRC. This includes all forms of
packets sent by the controller (advertisements and data channel PDU’s).
2) The MIC only gets appended to data channel
The MIC stands for “message integrity check”. If you are using Link Layer
encryption, which is seems like you are given some of the output you displayed
in your email (supervision_timeout=256 encrypted=1 authenticated=1 bonded=1),
there is a 4-byte MIC appended to every PDU sent by the link
The 573 is interesting also as my application has nothing to do with a mic.
I'm writing and receiving notifications.
I'm doing a
gatt-write conn=2 no_rsp=1 attr=25 value=10:01:00:00:01:10:02:10:03:53:56
then waiting for a response
notification rx event; attr_handle=25 indication=0 len=13
Hi Fred,
On Tue, Feb 05, 2019 at 02:25:43PM -0500, Copper Dr wrote:
> I'm trying to figure out how to decode these disconnections.
>
> Reason 688 (0x02B0) and 573 (0x023D)
>
> I checked
> http://mynewt.apache.org/latest/network/docs/ble_hs/ble_hs_return_codes.html
> and the disconnect code does
I'm trying to figure out how to decode these disconnections.
Reason 688 (0x02B0) and 573 (0x023D)
I checked
http://mynewt.apache.org/latest/network/docs/ble_hs/ble_hs_return_codes.html
and the disconnect code does not make any sense.
The 573 is the one I'm really interested in it happened just
