Means to know all AT responses have been received

[CMIT9763]

We are using an ANNA-B112 module with u-connectXpress for BLE. We are talking to the ANNA-B112 over uart using the ublxlib (https://github.com/u-blox/ubxlib) at_client, registering callbacks through uAtClientSetUrcHandler.

The problem we are encountering is that when we issue AT commands like AT+UBTGDCS to discover all of the characteristics for a given service, there are multiple responses followed by an OK.

For example this is what the command and responses look like using extended data mode to discover all the characteristics:

---><00><17><00>DAT+UBTGDCS=0,7,65535<0D>U

<---<00>6<00>E<0D><0A>+UBTGDCS:0,8,28,9,245468008B8511E48FBD0002A5D5C51BU

<---<00>8<00>E<0D><0A>+UBTGDCS:0,11,28,12,245468108B8511E48FBD0002A5D5C51BU

<---<00>8<00>E<0D><0A>+UBTGDCS:0,14,20,15,245468118B8511E48FBD0002A5D5C51BU<00>8<00>E<0D><0A>+

<---UBTGDCS:0,17,02,18,245468028B8511E48FBD0002A5D5C51BU<00>8<00>E<0D><0A>+

<---UBTGDCS:0,19,02,20,245468038B8511E48FBD0002A5D5C51BU<00>8<00>E<0D><0A>+

<---UBTGDCS:0,21,02,22,245468048B8511E48FBD0002A5D5C51BU<00><08><00>E<0D><0A>O

<---K<0D><0A>U

At the end of each response “U”, a callback from the at_client occurs as it should.

However, it appears there is no way to know when all of the characteristics have been received (When “OK” is received), and the module doesn’t respond to any further commands until it is has finished sending all responses.

Is there a mechanism that we are missing in the at_client to know when all responses have been received, or would we have to just know there are 6 characteristics to be discovered?

[RobMeades]

Hi there, and thanks for posting the issue. It may be that there is more that can be said about this specific AT command (my colleagues from the BLE side of the business may respond on that) but I can answer for the general case of an AT command with a multi-line response with an unknown number of lines, which is that it is not easy to handle!

You can see an example of a similar case on the cellular side in the activateContext() function in u_cell_net.c. In this case the cellular module sequence is:

AT+CGACT?
+CGACT: x,y
+CGACT: x,y
...
OK

...and, while the number of responses is bounded, in every case the number of responses received is smaller than the bound, and so it is a bit similar to your case.

As you can hopefully see from the code there, what we do is to lock the AT client, set a shorter timeout then usual (just to avoid hanging around unnecessarily) and issue uAtClientResponseStart() in a loop. The loop exits either when get the thing we were looking for or there is a timeout.

Now there might be a better strategy in this specific case, I'll let my colleagues comment on that, but basically this is a scenario which is not well handled by our AT client APIs. Very happy to consider any suggestions for improvement.