This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Device not advertising after few minutes when concurrent scan and advert procedure is ongoing on nrf52810 with SDK 14.2 and S132 v5.10 soft device

I have an application where in i need to scan for non connectable advertisements as well as advertise beacons on the device. I am using the Fanstel BT832A module which contains the nrf 52810 chipset on it.

To have both the broadcaster and the scanner role supported on the same device i had to work with the S132 soft device version v5.10 and SDK 14.2 which is tested for production version.

I have written an application which scans for a specific beacons as well as advertises a beacon regularly. The problem is the scanning always works but advertisement being sent is sporadic as well as the device goes into a mode where it would never send the advertisements at all. The broadcaster and scanner role works perfectly if they are tested individually but only when both roles are done simultaneously we get the above issue.

My query would be has anyone tested the concurrent roles on the nrf52810 with the S132 device? Also is there a way to workaround the issue.

The same program of both the roles running concurrently when compiled on the BT832 module which has the nrf52832 and the same SDK with the same soft device works well as expected. Hence i do not think that this is an issue with the application that has been written. 

One difference i can see between the modules that i am testing is that the BT832A module with nrf52810 works on internal clock where as the BT832 with nrf52832 has an external crystal. The sdk_config.h is updated with the required config setting for the same.

If anyone can suggest a solution or give an insight onto the issue faced it would be great.

Regards

Ashwin

Parents
  • Hi,

    I suggest to set scan window = scan interval = BLE_GAP_SCAN_WINDOW_MIN. This should have the least effect on active links or other procedures you may have.

    Best regards,
    Kenneth

  • Hi Kenneth,

      Thanks for your suggestion. I had earlier used scan interval and scan window of 1 second but as per your suggestion changed its value to 2.5ms. After changing the i am able to get advertisements more consistently but even then after a period of 5+ odd minutes the advertisement from the device completely stops but the scan has been working without any interruptions at all. By the way i am advertising the beacons every 1 second and forever.

    Regards

    Ashwin

  • Hi Kenneth,

       I have tested the above hex file attached. The device stopped advertising after 10 minutes. I do have beacons in my office so the device is scanning them continually. Can you please check with some beacons on at your end?

    Regards

    Ashwin

  • I have tested it for 18minutes without any problems now, have you tried to run this on a devkit with no external hardware?

    Best regards,
    Kenneth

  • Hi Kenneth,

       Can you please do an overnight test. Because the issue is very random sometimes it happens in 5 minutes, sometimes after an hour or so. So i suggest you to run overnight and you will definitely see this issue. I have also attached the softdevice that i am using for flashing for your reference. 

       Currently we are testing it on a fanstel BT832A module without connecting any external peripherals. I do not have a dev kit for the nrf52810.

    Regards

    Ashwin

    s132_nrf52_5.1.0.zip

  • The kit was powered last night, still advertising every 1 seconds. Though we used S132 v5.0 which is default in SDKv14.2, that should not have an impact on the problem you experience (would need to update softdevice header files to v5.1 and recompile project to try with v5.1). But you may try for comparison v5.0 if you  suspect it may be relevant.

  • Hi Kenneth,

          Thanks for your support on this. But this is what we found on our testing.

          If the device has to operate on both scanning and advertising roles simultaneously then with S132 soft-device version v5.1 did not work. This does not work on both 52810 and 52832 chipsets. The issue is the same as reported above the device stops advertising randomly and never ever advertises again until the device is reflashed with the softdevice and new firmware.

          Hence we had to move to newer version of the soft-device which is 6.0. On the 6.0 as S132 is not production tested on the 52810 we had to move to the 52832 and it worked fine.

          So we had to change our design from 52810 to 52832 for the same. Thanks to fanstel we were using identical version of modules we were able to replace the BT832A containing the 52810 with BT832 containing the 52832 without any hardware redesign. Even then the customer had to bear with the higher module cost of BT832 for the same.

          I suggest that you need to highlight that the NRF52810 does not support Central role in a production version of the latest SDK release. This will hep many of design houses to choose the best possible chipset for a solution based on the capabilities rather than going through the painful process as getting to know at the end juncture that this feature set in not supported on the 52810 chipset as we had the problem above.

    Regards

    Ashwin

Reply
  • Hi Kenneth,

          Thanks for your support on this. But this is what we found on our testing.

          If the device has to operate on both scanning and advertising roles simultaneously then with S132 soft-device version v5.1 did not work. This does not work on both 52810 and 52832 chipsets. The issue is the same as reported above the device stops advertising randomly and never ever advertises again until the device is reflashed with the softdevice and new firmware.

          Hence we had to move to newer version of the soft-device which is 6.0. On the 6.0 as S132 is not production tested on the 52810 we had to move to the 52832 and it worked fine.

          So we had to change our design from 52810 to 52832 for the same. Thanks to fanstel we were using identical version of modules we were able to replace the BT832A containing the 52810 with BT832 containing the 52832 without any hardware redesign. Even then the customer had to bear with the higher module cost of BT832 for the same.

          I suggest that you need to highlight that the NRF52810 does not support Central role in a production version of the latest SDK release. This will hep many of design houses to choose the best possible chipset for a solution based on the capabilities rather than going through the painful process as getting to know at the end juncture that this feature set in not supported on the 52810 chipset as we had the problem above.

    Regards

    Ashwin

Children
No Data
Related