Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Immediate Alert Client Application + Smartphone

Hi!

I am trying to test the Immediate Alert Client application example (ble_app_ias_c) from nRF5_SDK_15.0.0 on my nRF52832 based module. I want to understand how to test this application and see the alert notification on my smartphone.

Thank you.

  • Hi,

    All nRF5 SDK examples have a testing section in the documentation explaining how to get the example up running. Below you can see the testing section for the Immediate Alert Client.

    Best regards,
    Rune Holmgren

  • Hi! Rune,

    Thanks for your response.
    Looks like this testing method is for nRFConnect desktop version.

    But anyway, in smartphone app also by adding the predefined Immediate Alert service in a new server, I could get it working.

    Thanks again for your help.

    Regards,

    Gaurav.  

  • Hi! Rune,

    I have a follow-up question.

    Now, I want to modify the Immediate Alert Client Application.
    Currently, there are three states in the example:
    -0x00: No Alert
    -0x01: Mild Alert
    -0x02: High Alert
    Now I plan to modify these state values itself. How do you suggest to proceed with it?

    Basically, the application simply requires me to have a sensor(that gives binary output only) connected to the nRF52832 module and display the sensor value on the smartphone.
    So, I plan to attach the sensor with one of the GPIO's (input) and send the GPIO status via the Immediate Alert Client Application to the smartphone.

    If you think I should try something else, please let me know. 

    Thank you.

  • If it's only a single sensor I guess sending "no alert" and "mild alert" is a reasonable enough way of indicating to a phone what state the sensor is in. Note that you can't just send arbitrary values if you want to be within the specification of the service. If you want to make changes to the way the service and/or characteristics work you should create a new UUID for which there is no specification and you may do whatever you want. For testing purposes you can, of course, do whatever you want to the service, it's only releasing a mass produced product which would require a proper UUID.

    A more correct way of reporting the state of a sensor would be to create a custom service with a "sensor state" characteristic which would simply be an integer which is 0 or 1 depending on the sensor state.

    Best regards,
    Rune Holmgren

  • Hi, Rune!

    Thanks for your advice. I understand.
    Since I just want to develop a quick POC for now, so such quick-fixes could be handy and that's why wanted to check with you.
    But yeah, as you mentioned, the mass-produced product must have a custom service with a formal UUID.

    Anyway, I could finally manage to get the GPIO status on the smartphone.
    So, I think we can conclude this.

    Thank you.

Related