• State Not Answered
  • Replies 17 replies
  • Subscribers 73 subscribers
  • Views 303 views
  • Users 0 members are here
Attachments (2) Download All
Nordic Case Info
  • Case ID: 340306
Options

conn failed to establish. RF noise?

Hayden Ball

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?

  • 0

    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

  • 0

    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

  • 0 in reply to Asbjørn

    Thanks Asbjørn.

    I'd need a bit more guidance to check this, I'm afraid.

    It's an off-the-shelf nRF21540-DK (PCA 10112, Power Source set to VDD, SW6 set to Default), and an unmodified sample from nRF Connect SDK @ v2.9.0 (from my earlier post).

  • 0 in reply to Hayden Ball

    Hello,

    Asbjørn is out of office today, do you have some on air sniffer logs (e.g. using nRF Sniffer for BLE) for the different setups you have tested here, so we can look at the wireshark files (.pcapng) to potentially look at the differences?

    Does turning off WiFi on the iOS change anything?

    Kenneth

  • 0 in reply to Kenneth

    Hello Kenneth,

    Sorry for the delay.

    Turning off WiFi does not help.

    Please find attached a pcap captured with mini-moreph, along with a trace from the iPhone's sysdiagnose feature (the latter zipped as your forums wouldn't accept the pklg file).

    I started the connection attempt slightly after 09:17 UTC.

    The relevant MAC addresses appear to be 72:23:05:93:B3:C1 and C2:F1:36:E3:54:88.

    minimoreph.pcapng

    sysdiagnose.pklg.zip

Related
Terms of service