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

Reading battery level from peripheral BLE to central BLE to iOS app.

I have a BLE device acting as a central and a peripheral, relaying information between that peripheral and a custom iOS app. As a central, it reads (not notifications) the battery level of another BLE acting as a peripheral. This is working fine. I see the battery level of the peripheral being reported in RTT. On this relay BLE device, I have ble_bas_c related code working fine. However I can't seem to get the ble_bas related code working so that the iOS app can read that same battery level. There is another battery service that is working fine for the iOS app to read the BLE relay device battery level.

Parents
  • Hi,

    Just to clarify: The issue here is that the battery level relayed from the central/peripheral device is not updated? Have you tried with our nRF Connect app to see if there is anything different? 

    Dont know if this will help but have you tried with other phones?

  • Have you taken a look at the relay example we have in the SDK? If not, I would suggest you to have a look at the Experimental: BLE Relay Example, I think it will give you an idea on how to do it.

  • I was already reviewing the BLE Relay Example, but it wasn't relaying a battery service. I used the heart rate service relay as an example for a battery service relay, but I was still having issues. Then I found out that the target  peripheral was not actually notifying the battery level. I didn't write the firmware for the target peripheral, but I have access to the source. On the Central device, I saw that I was getting a BLE_BAS_C_EVT_BATT_READ_RESP instead of a BLE_BAS_C_EVT_BATT_NOTIFICATION so I placed the call for battery_level_update in the bas_c_evt_handler at the switch case BLE_BAS_C_EVT_BATT_READ_RESP instead of the switch case  BLE_BAS_C_EVT_BATT_NOTIFICATION. It working now. I am able to see the target peripheral battery level through the central and then to the mobile app.

    Please let me know if there is a reason I shouldn't be doing it this way.

    Thank you for your help.

Reply
  • I was already reviewing the BLE Relay Example, but it wasn't relaying a battery service. I used the heart rate service relay as an example for a battery service relay, but I was still having issues. Then I found out that the target  peripheral was not actually notifying the battery level. I didn't write the firmware for the target peripheral, but I have access to the source. On the Central device, I saw that I was getting a BLE_BAS_C_EVT_BATT_READ_RESP instead of a BLE_BAS_C_EVT_BATT_NOTIFICATION so I placed the call for battery_level_update in the bas_c_evt_handler at the switch case BLE_BAS_C_EVT_BATT_READ_RESP instead of the switch case  BLE_BAS_C_EVT_BATT_NOTIFICATION. It working now. I am able to see the target peripheral battery level through the central and then to the mobile app.

    Please let me know if there is a reason I shouldn't be doing it this way.

    Thank you for your help.

Children
  • Now that I have two battery services running, I have one more question. How can the mobile app distinguish between the two battery services? 

  • In BluetoothGattService object you'll find getInstance() method. For Android version 4.3 - 6?? they return zero-based indexes, for more recent versions they return handle number. This is not documented what they return and this may change to something else again in the future. The important thing is, that each next instance of the same service (and characteristic) gets a different value of instance id.

    There is no such method for descriptors, for some reason.

    Also, instances don't work for local GATT configuration on the phone. Even if you add 5 services of the same UUID, they all get the same instance id = 0. If a packet is received for a characteristic inside one of them, it will be delivered ONLY to the first instance of the server. This might have changed in recent years, however, I would have to check.

Related