conn failed to establish. RF noise?

We're seeing the following intermittently while attempting to connect from a Mac/iOS Central.

Using Android as a Central does not produce the same error.

[00:00:33.054,656] <wrn> bt_conn: conn 0x20003878 failed to establish. RF noise?
[00:00:33.054,931] <inf> bluetooth: Disconnected (reason 0x3e)

[00:00:34.374,511] <wrn> bt_conn: conn 0x20003878 failed to establish. RF noise?
[00:00:34.374,816] <inf> bluetooth: Disconnected (reason 0x3e)

[00:00:34.644,561] <wrn> bt_conn: conn 0x20003878 failed to establish. RF noise?
[00:00:34.644,836] <inf> bluetooth: Disconnected (reason 0x3e)

[00:00:35.154,479] <wrn> bt_conn: conn 0x20003878 failed to establish. RF noise?
[00:00:35.154,754] <inf> bluetooth: Disconnected (reason 0x3e)

[00:00:35.334,289] <wrn> bt_conn: conn 0x20003878 failed to establish. RF noise?
[00:00:35.334,564] <inf> bluetooth: Disconnected (reason 0x3e)

[00:00:35.724,487] <wrn> bt_conn: conn 0x20003878 failed to establish. RF noise?
[00:00:35.724,761] <inf> bluetooth: Disconnected (reason 0x3e)

[00:00:36.114,410] <wrn> bt_conn: conn 0x20003878 failed to establish. RF noise?
[00:00:36.114,685] <inf> bluetooth: Disconnected (reason 0x3e)

[00:00:36.505,371] <wrn> bt_conn: conn 0x20003878 failed to establish. RF noise?
[00:00:36.505,645] <inf> bluetooth: Disconnected (reason 0x3e)

[00:00:36.685,363] <wrn> bt_conn: conn 0x20003878 failed to establish. RF noise?
[00:00:36.685,638] <inf> bluetooth: Disconnected (reason 0x3e)

[00:00:37.282,043] <wrn> bt_l2cap: Ignoring data for unknown channel ID 0x003a
[00:00:38.182,312] <inf> bluetooth: Disconnected (reason 0x13)

Sometimes the connection eventually establishes, sometimes it doesn't.

Running the BT peripheral sample, the error does not occur.

Are you able to suggest any debugging steps, please, or suggestions as to why the behaviour might be different with the two centrals?

Parents
  • Thank you Hayden for the follow up, I've been talking to developers here and the assumption was that it was the iOS version, but it seems we have also met similar cases when there's been issues with the timing related to clock selections, it's just unuasual that you don't get the same failure when connecting with Android, but there's a chance that android devices have a larger timing window that enables this to work.

    Anyways, may I ask you to check you clock sources.

    Q1: Are you using INTCAP setting on the 32MHz crystal and what is it set to compared to your crystal Cl value?

    Q2: LFCLK source, same INTCAP question if you are using 32kHz crystal. If you are using LFRC as source, what settings are you using for that? If you set LFCLK source to be LFSYNT as a trial, do you still see the same issue? LFSYNT will use the 32MHz to generate the 32kHz, but will more accuracy at the cost of higher current consumption, but it''s useful as a clock source test.

    Best regards

    Asbjørn

Reply
  • Thank you Hayden for the follow up, I've been talking to developers here and the assumption was that it was the iOS version, but it seems we have also met similar cases when there's been issues with the timing related to clock selections, it's just unuasual that you don't get the same failure when connecting with Android, but there's a chance that android devices have a larger timing window that enables this to work.

    Anyways, may I ask you to check you clock sources.

    Q1: Are you using INTCAP setting on the 32MHz crystal and what is it set to compared to your crystal Cl value?

    Q2: LFCLK source, same INTCAP question if you are using 32kHz crystal. If you are using LFRC as source, what settings are you using for that? If you set LFCLK source to be LFSYNT as a trial, do you still see the same issue? LFSYNT will use the 32MHz to generate the 32kHz, but will more accuracy at the cost of higher current consumption, but it''s useful as a clock source test.

    Best regards

    Asbjørn

Children
No Data
Related