nRF8001 advertising issue

RE: nRF8001 advertising issue

didier — Thu, 02 Nov 2017 21:46:44 GMT

Thanks David, We are still finishing our test cases and the only way to try to replicate this issue is with several connects and disconnects from the peer device. A SPI trace would be tracking the SPI data, clock, REQN and RDYN pin? Regarding the suggestions we will proceed with the reading of the ACTIVE pin, since keeping the REQN line low would create some unexpected behavior from nRF8001, since it will also lower RDYN pin and expect a change of data in the SPI lines.

RE: nRF8001 advertising issue

David Edwin — Wed, 01 Nov 2017 13:27:30 GMT

I think the 300ms delay is the closest to what you may be seeing. An SPI trace is essential to help you, so we have a more controlled environment as compared to the android phone.

You should have a bit of control of the testing, the SPI trace will help you automate this.

Suggestion: Keep the REQN line low for 300ms every time the ACI connect is sent and see if the issue occurs.

Additional suggestion to see if the advertising is running: Turn on the ACTIVE line using the nRF8001 settings so if the advertising is successfully running you will see the ACTIVE line changing state.

However you definitely need to get control of the test to progress the case.

RE: nRF8001 advertising issue

didier — Tue, 31 Oct 2017 13:27:38 GMT

Hi David, Please check the answers below:

I don't have a SPI trace but the RDYN line is behaving as expected, since during the problem it stayed HIGH (no incoming events).
I actually doesn't know how to encrypt the GATT table, so I guess I am not doing it. Actually i just changed (slight ones) based on the nordic UART example.
NRF D 8001 1408PW

Regarding the sleep issue. Your assumption is correct, since I didn't put nRF8001 into sleep mode when or before the issue happened.

I'll test, but the problem is that the issue is not easy to replicate, it happened only three times during 3 months of developing/testing.
I'm using my android cellphone (nordic apps), but it's pretty much accurate since after a reset the nRF8001 I was able to scan it once again.

RE: nRF8001 advertising issue

David Edwin — Fri, 27 Oct 2017 09:41:27 GMT

The nRF8001 is reliable in what it is specified to do within the operating spec. This appears within what the nRF8001 is specified to do.

Can you post an SPI trace in addition to see if the RDYN line is behaving as expected.
I assume that you are not setting up the GATT table to be encrypted in the nRFgo studio settings file. Can you confirm this ?
Can you provide the IC markings on the nRF8001 ?

The only known issue is, after a wakeup of the nRF8001, the nRF8001 needs to wait ~300ms (worst case) to send the connect command, otherwise the start of advertising can get delayed. However you do not seem to be having the same issue.

Can you test by adding a similar delay (~300 ms) from the previous command/event before the "ACI Connect" command is sent
Do you have a sniffer or similar infrastructure to verify that the nRF8001 is indeed advertising or not.