This is a continuation of my previous thread (Connections drop and don't come back (and "SoftDevice Controller ASSERT: 53, 296")) (Case ID: 341823).
The project is a star network in which the Central is housed in a steel enclosure with a patch antenna perhaps 1cm from the steel surface. Currently, the network is running with Coded PHY. The Central is always scanning for Peripherals, but turns off scanning after a Peripheral is detected (with the required device name and service UUID) to establish the connection and then to read various characteristics with metadata and control information, after which scanning is turned back on. Thereafter, the Peripheral reports its environmental readings via Notify every 60 seconds. If a connection is lost for whatever reason, the Peripheral resumes advertising, and the reconnection process is repeated.
When the Central is facing the Peripherals, everything works great. Occasionally, connections are dropped, and after a bit (about 20 seconds) the Peripheral comes back online. However, when the box is flipped over such that the steel box is between the antenna and the Peripherals, the reported RSSI is worse by 5 to 10dB, and the rate at which the Peripherals lose their connections increases significantly. This is not surprising. However, some unknown condition occurs hours to days later that prevents the Central from seeing the Peripherals any more - they drop and don't come back. A DK running the Central software right next to the box (chip antenna, not shadowed by steel) can see the Peripherals advertising.
The action recommended from the previous thread was to update the NCS. I did so, migrating from 2.6.0 to 2.9.1. Under 2.6.0, I would also see the occasional SoftDevice assertion. Under 2.9.1, I don't see the assertion anymore. Apparently, the assertion was not the root cause of the "drop and don't come back" phenomenon.
The other error conditions previously observed are still present:
- Failure of Discovery to obtain a characteristic handle
- Failure of a characteristic Read operation
- Failure reported in a callback following bt_conn_le_create() (error code 2; BT_HCI_ERR_UNKNOWN_CONN_ID)
- Failure reported in a callback following bt_gatt_read() (error code 14; BT_ATT_ERR_UNLIKELY)
These errors are reported continuously until the "drop and don't come back" phenomenon happens. In the event of these new-connection-oriented errors, the connection is dropped and allowed to re-establish per the above process.