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

Android nRF-ToolBox multiple BLE services within a single Android Service

Hello all,

I've been working on creating a test app for a product that I've been developing for sometime. It has multiple BLE services such as Device information (DIS), Cycling Power (CP), Battery Service, DFU and a custom service. I've got no prior experience with Java or xml, so the answer might be obvious to the following questions.

I've adjusted the Cycling Speed and Cadence example in the nRF Toolbox application to receive and display the Cycling Power Measurement, the Cycling Power Feature, Sensor location and the DIS firmware, hardware, model number and serial number Characteristics.

I added all these characteristics in the Cycling Power Manager, but with so many services I'd like to implement this becomes quite a mess and I'd like to seperate each BLE service into a serperate manager/class(es).

I've noticed that the Battery service is already implemented by extension of the Cycling Power Manager (CSCManger in the original toolbox)

public class CPManager extends BatteryManager <CPManagerCallbacks>

From what I've attempted, failed and then read, I cannot extend this class further with other services like this. So what would be the best solution to extend the manager/service with more BLE services without putting all services and characteristics in a single class, while sending all handled BLE data to a single Activity?

Second question: I've removed all other BLE services in the first menu except the DFU and the Cycling Power services by removing the <service from the AndroidManifest.xml file as the template service readme file stated it would. However the Beacon service remains in the main menu, no matter which services I disable or remove. So where does the beacon service come from?

Thank you in advance for helping me out.

Parents
  • Hi

    Are you able to find out if this is delay is on the phone or nRF side (if you're using an nRF device on one side that is)? I think we need more information to decide what causes this delay. Are you able to take a sniffer trace of the connection so we can get some more details of what's causing this delay? You're of course welcome to try adding a separate thread for your GUI, but I can't say if it will help without knowing the cause of this delay.

    Please check out the nRF Logger API, that should help you with a text log solution.

    Best regards,

    Simon

  • I've stumbled onto something: The options menu is recreated/refreshed on each action/iteration of the GUI. I found out about it as I set a breakpoint in the onCreateOptionsMenu and the breakpoint would be hit continously and immediately after I continued from the same breakpoint. It seems that the onCreateOptionsMenu is called in some sort of while loop, but in a file that read-only and in a package controlled by Android Studio of some sort, so I can't edit it or change my permissions.

    With the menu disabled, having the NUS service enabled does not break my application as much as it did previously. Though I do note that not all functionality works as intended. It seems that quite a few BLE messages are lost when I attempt to write to a characteristic, even though the functions to write to the characteristic are indeed called. Previously they would not be called as the whole GUI was unresponsive with the options menu and the NUS service enabled.

    I have done a bit of testing with reliableWrite in order to solve the missing BLE messages, but that seems to do more harm than good. Do you have any suggestions to resolve this?

Reply
  • I've stumbled onto something: The options menu is recreated/refreshed on each action/iteration of the GUI. I found out about it as I set a breakpoint in the onCreateOptionsMenu and the breakpoint would be hit continously and immediately after I continued from the same breakpoint. It seems that the onCreateOptionsMenu is called in some sort of while loop, but in a file that read-only and in a package controlled by Android Studio of some sort, so I can't edit it or change my permissions.

    With the menu disabled, having the NUS service enabled does not break my application as much as it did previously. Though I do note that not all functionality works as intended. It seems that quite a few BLE messages are lost when I attempt to write to a characteristic, even though the functions to write to the characteristic are indeed called. Previously they would not be called as the whole GUI was unresponsive with the options menu and the NUS service enabled.

    I have done a bit of testing with reliableWrite in order to solve the missing BLE messages, but that seems to do more harm than good. Do you have any suggestions to resolve this?

Children
No Data
Related