Is there a way to emulate BLE packet error?

[vit bernatik]

Hello, Is there a way to test packet corruption? My setup would be that I have my FW in nRF52-DK. Then I would test communication using nRF51-Dongle. I would like to force dongle to corrupt selected packet. By this I would like to test that nRF52-DK application is correctly reacting for tested packet corruption. Is it possible with dongle? If so can you point me to some API/example? Or if it is not possible with dongle is there some other way how to do it?

[Øyvind Karlsen]

Hi,

Generally you can look at the Direct Test Mode along with application note An34 (and added python scripts).

If a packet is dropped in BLE it will automatically be resent, this is part of the protocol. So it might not make sense to handle things based on a single packet failing.

Best regards,

Øyvind

[vit bernatik]

Thank you for links. But DTM seems rather to test BLE HW. I would rather like to test application. My previous experience is that I used Alpwise stack before. For example in alpwise API during connection you call BLEGAP_ConnectWithIntervals() and you wait for TaskBLE_GAP_CB_Connected(). IT works 99% of times. But sometimes when specific packet is corrupted the TaskBLE_GAP_CB_Connected() is never called and application waits forever. When I debug it I add my own timer and handle the case. I'm not sure yet how robust Nordic API is but I would like to have tools on dongle side to kill some packets. For example when my app is in role CENTRAL and sends CONNECT_IND packet I want to kill this packet so dongle reacts as if it never received packet. And I want to test that API returns me some error after some timeout, or I will add timeout myself. I want to test my application + Nordic API that system works for errors in any packet. For that I need to have tools to kill selected packets... And perhaps the answer is that such tools does not exists...

[Øyvind Karlsen]

Hi,

When not running the SoftDevice you could intentionally change the Adress or CRC registers when you want to create false packages. With the SoftDevice running it only makes sense to handle the cases when you don't receive expected data. If you are in a connection you will get retransmissions on lost data, while the connections are maintained you will get packets through, if the connections time out you get alerts. If you lose advertising packets the best you can do is to check if there was some period where you expected data, but did not get it.

Øyvind