Read characteristics on BLE device?

How can I read strings from a arduino based ble device after connecting to it. If I notify... do I need to read it on the same time of notification. I believe timings after connecting is the issue. Maybe there are other ways to do that like register for strings but I cann't get it to work. Any Idea's how this works?

3 Likes

I did it like this and it works.

2021-07-01_000748

2021-07-01_000802

2 Likes

There is something wrong. Packages are not delivered without a delay. Also immediately after connection with subscribes doesn't work after connecting. only with a delay. It only happens when there is more than one register after each other. I checked on remove the mtu request and is not scanning so that's not it. Can't find any example with more than one register on subscribes for byte or strings, ... Soo I'm guessing I m doing right.

1 Like

I have to put a timer on connect too for checking if connected. And if I scan the same thing.

1 Like

I don't know what the BT_LE_RegisterTimer procedure is, but if you want to enter a 500ms delay between two RegisterForBytes blocks, you are unlikely to achieve it with the procedure.

1 Like

The procedure is all different for all previous en current millis I am running. It's just to make it more easy to read. Just a delay is needed for now. I will delete them if I solved this problem. I m reading the extension code and think there is a standard used for end byte of the package. /n, /r /0 don't know much about that. Could it be that those are different in the communication of register for notifications, connection and scanning? This is what I found.

/**
   * Creates a new BLEPacketReader to interpret the given array of bytes.
   *
   * @param packet byte array content of the packet
   */
  public BLEPacketReader(byte[] packet) {
    buffer = Arrays.copyOf(packet, packet.length);
    index = 0;
  }
1 Like

@Patryk_F This is the way I put a timer in it, to be clear.

Did some test for quit some time and I need to correct me. It is probably not the end byte that causing this problem... The common use of this is that it's called and than received the notification one by one. But In my case I m reading sensors states and settings and I need to do it after each other "when connected". Is this extension tested with for example 6 register that are call after each other?

The problem that craches the application is, when there are many registers of characteristics after each other. in the "when connected" from the extension. I don't receive notifications after the registration. Even on subscribe on the Arduino site it doesn't work. I need to wait on the arduino side to send it.

I had 8 registers and it crashes all the time, soo I merged characteristics in to one characteristic as a byte array and now it's running "more" stable.

For me this is the best way to do it.

Your delay method is very bad. By looping, you stop the entire app, including the user interface.

To avoid hard coded loops, use multiple deadline global variables, and have a fast Clock Timer check them, as in this sample project:

Beside that... Is a timer really a good way to do the checking if the registration is done. I am just guessing it is done. I don't know.

In the mean time I made it like this like you showed me.
blocks




I'm going to test it. I can already tell you this is stable. Only counter set to zero could be on top in procedure RegisterToReceive for shorter delays.

TimerExample_V1.aia (4.4 KB)

It is the first time I succeed it to make this timer easy to implement and to understand it in a short time. I am beyond that boundary. Thanks for the help. You could modify it or share it or what ever you want.

The registration works for me with a delay for the next one to register of 500ms. And the app could be used in the mean time. Didn't do the test with many registrations but I suppose it will do ok.

By the way my rssi was -71. I have seen rssi for over 200ms.

I was confused by your use of the word "register" for an act of scheduling in a calendar or list of deadline variables, because of the BLE usage of the word "register" for establishing subscriptions to incoming data events.

Consider using the word "schedule" instead of "register" for non-BLE deadline variable manipulation.

Nomenclature is half the battle.

A subscription is made after a connection is established. A register is a mac address that know by the server for a characteristic to send notifications to it. Soo yes, it doesn't have a time to execute. thinks on a hc74 chip that needs an address on a controller to identify the location.

The connection can be encoded to read soo... it is very useful it can be done before the notifications are received.