• State Not Answered
  • Replies 6 replies
  • Subscribers 97 subscribers
  • Views 1552 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 300711
Options

Using BLE Peripheral for my application.

JIVAN

Using Segger version 5.10. As we found that only this version can work with the SDK17 we use for BLE application. We tried the latest version and latest sdk but we could not make it work directly. 

My question is i want to modify the peripheral example for ble as follows

1. The sensor is connected to the Analog input via signal conditioning.

2. We keep reading the value of the sensor. 

3. We maintain a counter of min. so we the timer be on even in sleep or deeep sleep mode so we get correct min count from the start of the device 

4. We want to store the ADC value along with the counter in the flash memory. Thus using the program memory to store the data Please guide how we can use it

5. We want to use BLE connection to mobile. We need to use BLE only when the phone is in the vicinity else the BLE should be kept off. So is there a way the 

     a. In run mode we know that the required  phone with the required BLE name is available and we can connect to it

    b. During the sleep or deep sleep mode when we are not takinng the sensor reading, is there a way to wake up when we detect the phone (BLE) is in vicinity

Please guide. Thank you

Regards

Jivan

Parents
  • 0

    Hi Jivan,

    Using Segger version 5.10. As we found that only this version can work with the SDK17 we use for BLE application. We tried the latest version and latest sdk but we could not make it work directly. 

    If you are starting with the nRF5 SDK, I strongly suggest that you use SDK 17.1.0, as that is compatible with the latest revision of the ICs. It is possible to modify the SDK to use a later Segger Embedded Studio version, but the simplest and recomended is to use the version that was used for release testing, which you can find in the release notes of the SDK (version 5.42a for nRF5 SDK 17.1.0). 

    4. We want to store the ADC value along with the counter in the flash memory. Thus using the program memory to store the data Please guide how we can use it

    I would suggest you use FDS for this.

         a. In run mode we know that the required  phone with the required BLE name is available and we can connect to it

        b. During the sleep or deep sleep mode when we are not takinng the sensor reading, is there a way to wake up when we detect the phone (BLE) is in vicinity

    It makes sense for the nRF to be a peripheral that advertises, and for the phone to connect to it (by scanning and then sending a connection request after the advertising packet). This is how BLE is normally used. To conserve power the nRF can use a long advertising interval, which will keep the average current consumption low. You can play with the online power profiler to see the battery usage you can expect in this case.

Reply
  • 0

    Hi Jivan,

    Using Segger version 5.10. As we found that only this version can work with the SDK17 we use for BLE application. We tried the latest version and latest sdk but we could not make it work directly. 

    If you are starting with the nRF5 SDK, I strongly suggest that you use SDK 17.1.0, as that is compatible with the latest revision of the ICs. It is possible to modify the SDK to use a later Segger Embedded Studio version, but the simplest and recomended is to use the version that was used for release testing, which you can find in the release notes of the SDK (version 5.42a for nRF5 SDK 17.1.0). 

    4. We want to store the ADC value along with the counter in the flash memory. Thus using the program memory to store the data Please guide how we can use it

    I would suggest you use FDS for this.

         a. In run mode we know that the required  phone with the required BLE name is available and we can connect to it

        b. During the sleep or deep sleep mode when we are not takinng the sensor reading, is there a way to wake up when we detect the phone (BLE) is in vicinity

    It makes sense for the nRF to be a peripheral that advertises, and for the phone to connect to it (by scanning and then sending a connection request after the advertising packet). This is how BLE is normally used. To conserve power the nRF can use a long advertising interval, which will keep the average current consumption low. You can play with the online power profiler to see the battery usage you can expect in this case.

Children
Related
Terms of service