Multiple interrupt during data transmition

First question - YES.

Second querstion - I have to put the same code third time please read my messages attentively

ble_gatts_rw_authorize_reply_params_t auth_reply = {0};
    auth_reply.type = BLE_GATTS_AUTHORIZE_TYPE_READ;
    auth_reply.params.read.gatt_status = BLE_GATT_STATUS_SUCCESS;
    auth_reply.params.read.update = 1;

  auth_reply->params.read.p_data = get_calibraion_buff;
        auth_reply->params.read.len = 135;
        DEBUG_MSG("Size Of Spectrum = %d", auth_reply->params.read.len);

        sd_ble_gatts_rw_authorize_reply(conn_handle, auth_reply);

     where get_calibraion_buff is pointer to array with size 135 byte.

  third question - the size of MTU is assigned during connection esteblishment .

The sizue of MTU accordingly  sdk _config.h

#ifndef NRF_SDH_BLE_GATT_MAX_MTU_SIZE
#define NRF_SDH_BLE_GATT_MAX_MTU_SIZE 160
#endif

But question how to increaase MTU during connection establishment it is another question and another  topic.

Current question is why soft device generate 5 time BLE_GATTS_AUTHORIZE_TYPE_READ event 

after calling sd_ble_gatts_rw_authorize_reply(conn_handle, auth_reply) with  parrameter filled by above mentioned way.

Best regards

Andrii

Please, I am reading your messages attentively, but it's not obvious to me how your program will behave based on this code, which is why I'm asking you these questions. So I would appreciate if you could answer my question and not just post the same code again. Thanks.

I believe the MTU is very relevant to your question, as it seems likely to me that your data is split into 5 packets because of the MTU.

From your original post it seems the MTU is set to 31, have you changed the sdk_config.sh since your first post or is the setting not taking effect? Also it is not enough to just set the MTU, you'll also have to set the data length variable to send larger packets.

-Einar

Hello Einarh

Excuse me for later answer.

There are several software principles. One of them, if it describe roughly, sounds like - one part of software (In our case high level) should not know details of another part of software (in our case low level of BLE stack).. Other words - the application should not know about details of transport of its messages.

If apply this principle to our case, so application should call function with 2 parameters one of them pointer to the buffer of data, another number of data. After that application should receive the result of transmition  in synchronous or asynchronous way. That is all . Everything other should be business  of  BLE stack(Size of MTU, Fragmentation, memory allocation etc..).

You consider some particular case, but it is necessary to provide some common approach.

Of coarse this case depends from size of MTU. AND IT IS PROBLEM. For example what happen if I need to transmit not 135 bytes but 1350 bytes ? Or size of MTU will be changed during connection establishment negotiation to the 27 or other because it depends from which version of BLE  protocol hardware of opposite side  support or another circumstances?

THE MAIN QUESTION OF THIS TOPIC IS - 

Whether such behaviour is result of wrong BLE stack adjustment or wrong parameter filling or it is bug of BLE stack.

That is why I have sent you sources. 

Best regards

Andrii Shevchuk

Hi again

These are nice principles to have when doing high level programming, but I'm afraid much of what you are doing here is fairly low level. If you don't want to deal with low level BLE stack behavior, then you should consider whether a pre-existing BLE service can work for your application instead of writing your own.

I'm still having trouble understanding how your code is supposed to work, if you could please explain the expected basic program flow of your application that would make it much easier for me to help you.

I would also appreciate if you could send me a sniffer trace showing the communication between your two devices, using the nRF sniffer tool, as that would help a lot with debugging.

Best regards,

Einar