Problem in data transfer in Bluetooth at 10ms

RE: Problem in data transfer in Bluetooth at 10ms

Karl Ylvisaker — Mon, 25 May 2020 13:52:11 GMT

Hello again,

[quote user="sharmelaraju"]I have tried cc2564moda Bluetooth(central) with cc2564moda Bluetooth(peripheral) .With this communication it is working fine.[/quote]

That is very strange to hear. Are you saying that the cc2564moda peripheral behaves differently with a cc2564moda, without any changes to the peripheral code? Could you detail how it is different - do you not see the occasional double or triple message appear on the debug terminal of the peripheral?
I do not think this is likely.

From the logs you sent, it is evident that the nRF sends all the data as expected when configured as the central. 10 ms connection intervals delivering your custom data to the peripheral.

Do I have it correctly that you in your cc2564moda peripheral code use a 10 ms timer to trigger reading of the BLE RX buffer?
In the case that I was correct:
Did you attempt what I suggested in my last comment - switching the cc2564moda peripheral code to instead react to radio RX events rather than a 10 ms timer? I think this would solve your problem, as the central is sending everything it is supposed to, when it is supposed to, according to the logs.
It would also free up resources on your peripheral advice, and conform more to best-practice principles of embedded development.

Looking forward to hearing from you,

Best regards,
Karl

RE: Problem in data transfer in Bluetooth at 10ms

sharmelaraju — Mon, 25 May 2020 07:32:43 GMT

Thanks for the reply.

I have tried cc2564moda Bluetooth(central) with cc2564moda Bluetooth(peripheral) .With this communication it is working fine.But not with the nrf52840 controller. can you please give me some solution.

RE: Problem in data transfer in Bluetooth at 10ms

Karl Ylvisaker — Wed, 20 May 2020 12:52:27 GMT

Hello again,

I was under the impression from your earlier comments that you currently were using the nRF as the peripheral device?
The code you have shared in your last reply seem to be for your CC250MODA device - which I am not familiar with. If there is a problem with this device, then I rather recommend that you contact Texas Instrument regarding this.

Nevertheless, giving the code a quick look, it looks to me like you are indeed scheduling a single read every 10 ms. Instead of setting up a scheduler to do a reading every 10 ms - when you already know that you will be receiving a packet every 10 ms - I suggest making use of the generated BLE Radio events (RX complete events) to start the processing of your data. I am not sure how this is implemented on the CC250MODA device, but I am sure they will generate an interrupt or event upon the completion of a BLE transfer.

Looking forward to resolving this issue,

Best regards,
Karl

RE: Problem in data transfer in Bluetooth at 10ms

sharmelaraju — Wed, 20 May 2020 10:39:15 GMT

Thanks.

I am hereby attaching the code of the peripheral which reads the data every 10ms.devzone.nordicsemi.com/.../per_5F00_code.txt

RE: Problem in data transfer in Bluetooth at 10ms

Karl Ylvisaker — Tue, 19 May 2020 16:29:57 GMT

Hello,

[quote user="sharmelaraju"]In the peripheral side the there is an scheduler function which reads the data at every 10ms. I am using termite application to log the data from the controller.[/quote]

Could you share some code or elaborate more on the scheduler function you use to read data ever 10 ms? It could be that this scheduler does not work as intended.

[quote user="sharmelaraju"]But in the captured_log1data i have noticed that one point of time the master has not connected to slave but the data is sending.I am here by attaching the log file .[/quote]

The first highlighted section might be caused by the peripheral not acknowledging the reception of the packet sent from the central device. This causes the central to resend the packet.
It might also be due to that the sniffer might receive packets that is lost or corrupted to the central/peripheral device - and vice verse. The first highlighted section of the screenshot you have shared might be showing this. That the sniffer lost a packet that the central/peripheral might still have received.
The frequency of loss and packet corruption depends heavily on the environment in which the devices are working.

What is interesting is the transmission starting on packet number 1209... I must have missed this exchange when reading the log earlier. What might be happening is that the central attempts to start a transfer, that is not acknowledged by the slave. This causes the central to have to wait until the next connection interval to re-transmit the non-acknowledged packet. Since your program schedules new data to be sent every 10 ms, a new packet will be placed in the TX buffer before the previous is retransmitted. This leads to the transmission exchanges we are seeing at packet 1209 - the master suddenly has more than one packet to transmitt at once, since the previous one was never acknowledged.
The re-transmission feature also ensures that no data is lost, even though it will arrive in the next connection interval. Note also how all the extra data is fitted into the next connection interval, without causing any sort of delay.
So, In essence; you are ensured that all the data will be transmitted over the BLE connection, but some data might arrive in the next connection interval, if the first transmission attempt is never acknowledged by the peripheral.
This is probably the cause of the logger "stutter" you've seen in your log. :)

As for the Empty PDU in the second highlighted section, it is probably caused by the central TX buffer being empty when the connection interval is up, causing the central to send an empty packet just to maintain the connection to the peripheral.
You can double click the packet in question to see its contents.

Best regards,
Karl

RE: Problem in data transfer in Bluetooth at 10ms

sharmelaraju — Tue, 19 May 2020 11:39:38 GMT

Thanks for the reply.

In the peripheral side the there is an scheduler function which reads the data at every 10ms. I am using termite application to log the data from the controller.

But in the captured_log1data i have noticed that one point of time the master has not connected to slave but the data is sending.I am here by attaching the log file .

please give me the solution.

RE: Problem in data transfer in Bluetooth at 10ms

Karl Ylvisaker — Mon, 18 May 2020 14:42:09 GMT

Hello again,

Those logs were much better, thank you.

When viewing the logs, this seems exactly as it should be to me.
The delta time for each transmission is ~10 ms for each transmission. From this, we can now be sure that you are in fact completing your data transmission (the 0x11, 0x12, 0x15 .. data) every 10 ms.
If you take a look at packet number 531 particularly, that is when the central initiates the connection - with 8 as connection interval, which translates to 10 ms (8 * 1.25 ms).

Seeing this, in combination with the printed UART log you shared earlier(where the data is not being processed right away after being received. So, that leads us to examining what the peripheral spends its time doing.

When does the data handling happen? Could it be that your device is over encumbered, and thus not always finish its processing of the received data in time, before a new packet is received?
It could also be that the UART logging itself is what pushes the peripheral to miss its processing windows - are you using deferred logging?

Best regards,
Karl

RE: Problem in data transfer in Bluetooth at 10ms

sharmelaraju — Mon, 18 May 2020 05:27:37 GMT

Plz give me the solution.

RE: Problem in data transfer in Bluetooth at 10ms

sharmelaraju — Mon, 18 May 2020 05:27:18 GMT

Hi,

Thanks for the reply.

I am here by attaching the captured sniff data between the central and peripheral.devzone.nordicsemi.com/.../captured_5F00_logdata.pcapng devzone.nordicsemi.com/.../captured_5F00_log1data.pcapng

RE: Problem in data transfer in Bluetooth at 10ms

Karl Ylvisaker — Wed, 13 May 2020 09:55:31 GMT

[quote user="sharmelaraju"]Sorry for the delayed response.[/quote]

No problem at all.

[quote user="sharmelaraju"]Still i am getting the same thing while logging the data in the ble sniffer.[/quote]

Did you take a look at the sniffer trace I attached in my last reply?
Are you unable to see the master-slave communication happening as shown in the trace?
If so, could you verify that the two modules manage to connect to each other? If you are not seeing the master-slave communication, and not receiving the data, then it is possible that the two devices are not connecting to each other.

The master-slave communication should show up in the sniffer as soon as the connection is established.

Could you verify if this is the case, and get back to me?

Best regards,
Karl

RE: Problem in data transfer in Bluetooth at 10ms

sharmelaraju — Wed, 13 May 2020 05:25:28 GMT

Sorry for the delayed response.

Still i am getting the same thing while logging the data in the ble sniffer.

I have even tried nrf52840 as (peripheral) and cc2564 moda Bluetooth as central.Still i am not able receive the data at every 10ms .

please help me with the soluion.

RE: Problem in data transfer in Bluetooth at 10ms

Karl Ylvisaker — Tue, 05 May 2020 14:03:41 GMT

Hello again,

[quote user="sharmelaraju"]Thanks for the reply.[/quote]

No problem at all, I am happy to help!

Looking at the new log you have provided, I again only see advertising - no connections is happening. The advertising follows the same pattern as I saw in the previous logs.

[quote user="sharmelaraju"]I have observed that while logging the data the source address kept on changing every time whenever i have closed the wire shark application and opened the application and logging.[/quote]

That sounds strange. Do you make any changes to the code running on the central device?

[quote user="sharmelaraju"]one more doubt is the peripheral Bluetooth is other controller Bluetooth(CC2564MODA bluetooth) so while logging in nrf sniffer will it be able to capture the data of other controller Bluetooth because i am not using the same controller Bluetooth on central and peripheral.[/quote]

Yes, the Sniffer tool will see all BLE traffic happening around it - it does not differentiate between different chip-sets or vendors.

Please have a look at the Wireshark sniffer trace I have attached to this comment.
The log illustrates how the connection should look between the central(master) and the peripheral(slave).
Notice that the peripheral only advertises its presence for the first 4-5 seconds, before the central comes online and establishes a connection.
The central in the log I have supplies is using the code I provided you earlier - notice that it is sending your custom message as a write command to the peripheral every 10 ms.
Since this is working as intended on my end, I am having a hard time replicating and debugging your error - and this is strengthening my suspicion that your peripheral might be at fault here.

devzone.nordicsemi.com/.../master_5F00_slave_5F00_communication.pcapng

Could you attempt to capture a sniffer trace like the one I sent you now, with the connection between central and peripheral?

Best regards,
Karl

RE: Problem in data transfer in Bluetooth at 10ms

sharmelaraju — Tue, 05 May 2020 07:20:11 GMT

Thanks for the reply.

The log data which i have sent is sniffer data between the central and peripheral device.I have placed the development board(NRF51422) which runs the NRF sniffer between the central (NRF52840 ) device and peripheral (cc2564 moda other controller bluetooth) .I have opened the wire shark application and log the data.

I have observed that while logging the data the source address kept on changing every time whenever i have closed the wire shark application and opened the application and logging.

one more doubt is the peripheral Bluetooth is other controller Bluetooth(CC2564MODA bluetooth) so while logging in nrf sniffer will it be able to capture the data of other controller Bluetooth because i am not using the same controller Bluetooth on central and peripheral.

please you give me the solution.

I am here by attaching the log of the snif data between central and peripheral device.devzone.nordicsemi.com/.../IBP_5F00_LOG_5F00_DATA.pcapng

RE: Problem in data transfer in Bluetooth at 10ms

Karl Ylvisaker — Mon, 04 May 2020 17:28:11 GMT

[quote user="sharmelaraju"]sorry for the delayed response.[/quote]

It is no problem at all - I fully understand these days being hectic. We resume whenever you are able to reply back.

[quote user="sharmelaraju"]I am here by attaching the sniffer log central(NRF52840) and peripheral( CC2564MODA Bluetooth).[/quote]

What do you mean by this?
Preferably the sniffer trace is taken while the transfer from the central to the peripheral is taking place.
What I would like to see in the sniffer trace is what is happening at the same time as your peripheral reads an abnormal amount of bytes(24, 16, 0).
Could you ensure that the sniffer traces contain these exchanges?

Looking at LOG12 and LOG22(assuming the 24:5c is the correct device):
- There is no connection happening in these logs: only a single device advertising its presence and manufacturer specific data.
- It is advertising very frequently for the first 500ms, with intervals as low as ~2-3 ms.
- After 500 ms it advertises roughly every 100 ms.

The device address is the same in both these logs, and their behavior is also similar: Could you verify that these were the logs you meant to send?
If this in fact was the logs you meant to send, could you tell me what process what going on when these logs were captured?
Please verify that the transfer over BLE is happening while the sniffer trace is captured.

I still suspect that the issue is on the peripheral end of things.

Best regards,
Karl

RE: Problem in data transfer in Bluetooth at 10ms

sharmelaraju — Mon, 04 May 2020 13:31:46 GMT

Thanks for the reply.

sorry for the delayed response.

I am here by attaching the sniffer log central(NRF52840) and peripheral( CC2564MODA Bluetooth).

Plz give me the solution.devzone.nordicsemi.com/.../LOG12.pcapng devzone.nordicsemi.com/.../LOG22.pcapng

RE: Problem in data transfer in Bluetooth at 10ms

Karl Ylvisaker — Tue, 28 Apr 2020 08:56:53 GMT

No problem at all, I am happy to help!

I see.
Could you provide me with a sniffer trace of the BLE traffic you are seeing?
On my end, the central is communicating as expected, and I am not seeing these deviations.
With a sniffer trace, I would be able to pinpoint if the issue is with your central, peripheral or the BLE link.

What else, other than receiving BLE communication, is the peripheral doing?
Could you ensure that the peripheral always has enough time to process the received data?

Looking forward to resolving this issue,

Best regards,
Karl

RE: Problem in data transfer in Bluetooth at 10ms

sharmelaraju — Mon, 27 Apr 2020 13:25:45 GMT

Thanks for the support.

I have tried your it is working....I am receiving the 8 bytes of data at every 10 ms .But sometimes the receiver Bluetooth reads 24 bytes,16 bytes,0 bytes. Can you please tell me how to resolve this issue.

I am here by attaching the log of the received data.devzone.nordicsemi.com/.../MAIN_5F00_IBP_5F00_DONGLE.txt

RE: Problem in data transfer in Bluetooth at 10ms

Karl Ylvisaker — Thu, 23 Apr 2020 15:04:01 GMT

Hello,

[quote user="sharmelaraju"]Thanks for the support.[/quote]

No problem at all, I am happy to help!

[quote user="sharmelaraju"]In our application we need to achieve at every 10ms. [/quote]

Yes, that much is understood.
I took a closer look at the code you provided, and made some discoveries.
First of all, the reason why you have not been able to set the connection interval properly: It seems that there is a bug in the ble_central/blinky source code, where it in fact does not make use of the parameters MIN_CONNECTION_INTERVAL and MAX_CONNECTION_INTERVAL as specified in main.c - but instead uses the default NRF_BLE_SCAN_MIN_CONNECTION_INTERVAL from the sdk_config.h file.
I have created an internal ticket on these misleading lines, for our SDK team to take a closer look at. I am sorry for any confusion this has caused you in your development.

Having found this, I changed the NRF_BLE_SCAN_MIN_CONNECTION_INTERVAL and NRF_BLE_SCAN_MAX_CONNECTION_INTERVAL to 10, which resulted in the expected 10 ms connection interval between the central device and an arbitrary peripheral device I set up.

Then, I used a Sniffer tool to capture the BLE traffic from the central, and noticed that it was only sending the data every other connection interval, instead of every 10 ms.
Taking a closer look at you code, I see that you have merged the Led Button service with the Nordic UART example service, and discovered that your data is scheduled to be sent every 20 ms by your "battery_level_meas_timeour_handler()" function. I changed the BATTERY_LEVEL_MEAS_INTERVAL from 20 ms to 10 ms, and observed that the changes were reflected in the BLE traffic captured using the Sniffer. I have attached the sniffer log here, for you to take a look at.

For future reference, I strongly recommend changing variable- and function-names so that they match their actual function, for significantly increased readability.

You can find the changes I made to your project code by looking at the lines preceded by "CHANGE START" and ending with "CHANGE END"
I recommend that you take a look at the changes I have made, but input them into your project yourself - rather than continuing to develop using the code I have sent.
This will ensure that you have full control and understanding of the changes made.

Please let me know if you should encounter any other questions or issues in the future.

Best regards,
Karl

devzone.nordicsemi.com/.../sharmelaraju.pcapng devzone.nordicsemi.com/.../IBP_5F00_DONGLE.zip

RE: Problem in data transfer in Bluetooth at 10ms

sharmelaraju — Thu, 23 Apr 2020 07:33:43 GMT

Thanks for the support.

In our application we need to achieve at every 10ms.

RE: Problem in data transfer in Bluetooth at 10ms

Karl Ylvisaker — Wed, 22 Apr 2020 20:00:22 GMT

Hi again,

I have been able to replicate your minimal 20 ms connection interval with the code you provided.
I have also successfully created a modified version of the Blinky examples, that communicate with 10 ms connection intervals - since this is the basis of your application.

Tomorrow I will pursue the reason for your application only achieving to send every 20 ms.

Best regards,
Karl

RE: Problem in data transfer in Bluetooth at 10ms

Karl Ylvisaker — Tue, 21 Apr 2020 13:41:11 GMT

Thank you for you patience.
I have allocated time to review your code tomorrow.

I'll get back to you once I have looked over the code.

Best regards,
Karl

RE: Problem in data transfer in Bluetooth at 10ms

sharmelaraju — Mon, 20 Apr 2020 08:41:47 GMT

Thanks for the reply.

I am here by sharing the entire project in the folder IBP_DONGLE( NRF52840), Soft device s 140, SDK VERSION 15.3, EXAMPLE -ble_app_blinky.devzone.nordicsemi.com/.../IBP_5F00_DONGLE.rar

RE: Problem in data transfer in Bluetooth at 10ms

Karl Ylvisaker — Mon, 20 Apr 2020 07:31:28 GMT

Hello again,

This is just the contents of your main.c source code file - if I am to be able to run your code on my end, I will need the entire project directory, complete with the project and configuration files as well. If you would like to send me this, please compress the project folder to a .zip or .7z file, and post it here, so I may take a look.
Before you do this, please make sure that the project you are sending is the correct version, exhibiting the behavior you have detailed earlier.

Best regards,
Karl

RE: Problem in data transfer in Bluetooth at 10ms

sharmelaraju — Sat, 18 Apr 2020 11:38:11 GMT

Hi,

I am here by attaching the code.

/**
 * Copyright (c) 2014 - 2019, Nordic Semiconductor ASA
 *
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without modification,
 * are permitted provided that the following conditions are met:
 *
 * 1. Redistributions of source code must retain the above copyright notice, this
 *    list of conditions and the following disclaimer.
 *
 * 2. Redistributions in binary form, except as embedded into a Nordic
 *    Semiconductor ASA integrated circuit in a product or a software update for
 *    such product, must reproduce the above copyright notice, this list of
 *    conditions and the following disclaimer in the documentation and/or other
 *    materials provided with the distribution.
 *
 * 3. Neither the name of Nordic Semiconductor ASA nor the names of its
 *    contributors may be used to endorse or promote products derived from this
 *    software without specific prior written permission.
 *
 * 4. This software, with or without modification, must only be used with a
 *    Nordic Semiconductor ASA integrated circuit.
 *
 * 5. Any software provided in binary form under this license must not be reverse
 *    engineered, decompiled, modified and/or disassembled.
 *
 * THIS SOFTWARE IS PROVIDED BY NORDIC SEMICONDUCTOR ASA "AS IS" AND ANY EXPRESS
 * OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
 * OF MERCHANTABILITY, NONINFRINGEMENT, AND FITNESS FOR A PARTICULAR PURPOSE ARE
 * DISCLAIMED. IN NO EVENT SHALL NORDIC SEMICONDUCTOR ASA OR CONTRIBUTORS BE
 * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
 * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
 * GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
 * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 *
 */
/**
 * @brief BLE LED Button Service central and client application main file.
 *
 * This file contains the source code for a sample client application using the LED Button service.
 */

#include <stdint.h>
#include <stdio.h>
#include <string.h>
#include "nrf_sdh.h"
#include "nrf_sdh_ble.h"
#include "nrf_sdh_soc.h"
#include "nrf_pwr_mgmt.h"
#include "app_timer.h"
#include "boards.h"
#include "bsp.h"
#include "bsp_btn_ble.h"
#include "ble.h"
#include "ble_hci.h"
#include "ble_advertising.h"
#include "ble_conn_params.h"
#include "ble_db_discovery.h"
#include "ble_lbs_c.h"
#include "nrf_ble_gatt.h"
#include "nrf_ble_scan.h"

#include "nrf_log.h"
#include "nrf_log_ctrl.h"
#include "nrf_log_default_backends.h"



typedef unsigned char Byte_t;                   /* Generic 8 bit Container.   */



#define CENTRAL_SCANNING_LED            BSP_BOARD_LED_0                     /**< Scanning LED will be on when the device is scanning. */
#define CENTRAL_CONNECTED_LED           BSP_BOARD_LED_1                     /**< Connected LED will be on when the device is connected. */
#define LEDBUTTON_LED                   BSP_BOARD_LED_2                     /**< LED to indicate a change of state of the the Button characteristic on the peer. */

#define SCAN_INTERVAL                   0x0030                              /**< Determines scan interval in units of 0.625 millisecond. */
#define SCAN_WINDOW                     0x0030                              /**< Determines scan window in units of 0.625 millisecond. */
#define SCAN_DURATION                   0x0000                              /**< Timout when scanning. 0x0000 disables timeout. */

#define MIN_CONNECTION_INTERVAL         MSEC_TO_UNITS(20, UNIT_1_25_MS)    /**< Determines minimum connection interval in milliseconds. */
#define MAX_CONNECTION_INTERVAL         MSEC_TO_UNITS(20, UNIT_1_25_MS)     /**< Determines maximum connection interval in milliseconds. */
#define SLAVE_LATENCY                   0                                   /**< Determines slave latency in terms of connection events. */
#define SUPERVISION_TIMEOUT             MSEC_TO_UNITS(4000, UNIT_10_MS)     /**< Determines supervision time-out in units of 10 milliseconds. */

#define LEDBUTTON_BUTTON_PIN            BSP_BUTTON_0                        /**< Button that will write to the LED characteristic of the peer */
#define BUTTON_DETECTION_DELAY          APP_TIMER_TICKS(50)                 /**< Delay from a GPIOTE event until a button is reported as pushed (in number of timer ticks). */

#define APP_BLE_CONN_CFG_TAG            1                                   /**< A tag identifying the SoftDevice BLE configuration. */
#define APP_BLE_OBSERVER_PRIO           3                                   /**< Application's BLE observer priority. You shouldn't need to modify this value. */

NRF_BLE_SCAN_DEF(m_scan);                                       /**< Scanning module instance. */
BLE_LBS_C_DEF(m_ble_lbs_c);                                     /**< Main structure used by the LBS client module. */
NRF_BLE_GATT_DEF(m_gatt);                                       /**< GATT module instance. */
BLE_DB_DISCOVERY_DEF(m_db_disc);                                /**< DB discovery module instance. */
#define BLE_NUS_MAX_DATA_LEN            8

//static char const m_target_periph_name[] = "Nordic_Blinky";     /**< Name of the device we try to connect to. This name is searched in the scan report data*/

static char const m_target_periph_name[] = "DEVICE";     /**< Name of the device we try to connect to. This name is searched in the scan report data*/

#define BATTERY_LEVEL_MEAS_INTERVAL         APP_TIMER_TICKS(20)                   /**< Battery level measurement interval (ticks). */

APP_TIMER_DEF(m_battery_timer_id);  

/**@brief Function to handle asserts in the SoftDevice.
 *
 * @details This function will be called in case of an assert in the SoftDevice.
 *
 * @warning This handler is an example only and does not fit a final product. You need to analyze
 *          how your product is supposed to react in case of Assert.
 * @warning On assert from the SoftDevice, the system can only recover on reset.
 *
 * @param[in] line_num     Line number of the failing ASSERT call.
 * @param[in] p_file_name  File name of the failing ASSERT call.
 */
void assert_nrf_callback(uint16_t line_num, const uint8_t * p_file_name)
{
    app_error_handler(0xDEADBEEF, line_num, p_file_name);
}


/**@brief Function for the LEDs initialization.
 *
 * @details Initializes all LEDs used by the application.
 */
static void leds_init(void)
{
    bsp_board_init(BSP_INIT_LEDS);
}


/**@brief Function to start scanning.
 */
static void scan_start(void)
{
    ret_code_t err_code;

    err_code = nrf_ble_scan_start(&m_scan);
    APP_ERROR_CHECK(err_code);

    bsp_board_led_off(CENTRAL_CONNECTED_LED);
    bsp_board_led_on(CENTRAL_SCANNING_LED);
}


/**@brief Handles events coming from the LED Button central module.
 */
static void lbs_c_evt_handler(ble_lbs_c_t * p_lbs_c, ble_lbs_c_evt_t * p_lbs_c_evt)
{
    switch (p_lbs_c_evt->evt_type)
    {
        case BLE_LBS_C_EVT_DISCOVERY_COMPLETE:
        {
            ret_code_t err_code;

            err_code = ble_lbs_c_handles_assign(&m_ble_lbs_c,
                                                p_lbs_c_evt->conn_handle,
                                                &p_lbs_c_evt->params.peer_db);
            NRF_LOG_INFO("LED Button service discovered on conn_handle 0x%x.", p_lbs_c_evt->conn_handle);

            err_code = app_button_enable();
            APP_ERROR_CHECK(err_code);

            // LED Button service discovered. Enable notification of Button.
            err_code = ble_lbs_c_button_notif_enable(p_lbs_c);
            APP_ERROR_CHECK(err_code);
        } break; // BLE_LBS_C_EVT_DISCOVERY_COMPLETE

       /* case BLE_LBS_C_EVT_BUTTON_NOTIFICATION:
        {
            NRF_LOG_INFO("Button state changed on peer to 0x%x.", p_lbs_c_evt->params.button.button_state);
            if (p_lbs_c_evt->params.button.button_state)
            {
                bsp_board_led_on(LEDBUTTON_LED);
            }
            else
            {
                bsp_board_led_off(LEDBUTTON_LED);
            }
        } break; // BLE_LBS_C_EVT_BUTTON_NOTIFICATION*/

        default:
            // No implementation needed.
            break;
    }
}

void send_ble_data(uint8_t * p_data, uint16_t length)
{
	uint32_t  err_code;
static uint8_t data_array[BLE_NUS_MAX_DATA_LEN];
memcpy(data_array, p_data, length);
ble_nus_c_string_send(&m_ble_lbs_c, data_array, length);
}
	
/**@brief Function for handling the Battery measurement timer timeout.
 *
 * @details This function will be called each time the battery level measurement timer expires.
 *
 * @param[in] p_context  Pointer used for passing some arbitrary information (context) from the
 *                       app_start_timer() call to the timeout handler.
 */
static void battery_level_meas_timeout_handler()
{
   // UNUSED_PARAMETER(p_context);
    //battery_level_update();
	
uint8_t dummyData[8] ;

int i=0;	

//nrf_gpio_pin_toggle(24);
	
dummyData[0]=0X11;
	
dummyData[1]=0X12;

dummyData[2]=0X23;
	
dummyData[3]=0X34;

dummyData[4]=0X55;
	
dummyData[5]=0X66;

dummyData[6]=0X57;
	
dummyData[7]=0x58;
send_ble_data(dummyData, sizeof(dummyData));
	
}


/**@brief Function for handling BLE events.
 *
 * @param[in]   p_ble_evt   Bluetooth stack event.
 * @param[in]   p_context   Unused.
 */
static void ble_evt_handler(ble_evt_t const * p_ble_evt, void * p_context)
{
    ret_code_t err_code;

    // For readability.
    ble_gap_evt_t const * p_gap_evt = &p_ble_evt->evt.gap_evt;

    switch (p_ble_evt->header.evt_id)
    {
        // Upon connection, check which peripheral has connected (HR or RSC), initiate DB
        // discovery, update LEDs status and resume scanning if necessary. */
        case BLE_GAP_EVT_CONNECTED:
        {
            NRF_LOG_INFO("Connected.\r\n");
					   nrf_ble_scan_stop();
        
            err_code = ble_lbs_c_handles_assign(&m_ble_lbs_c, p_gap_evt->conn_handle, NULL);
            APP_ERROR_CHECK(err_code);

            err_code = ble_db_discovery_start(&m_db_disc, p_gap_evt->conn_handle);
            APP_ERROR_CHECK(err_code);
					  if(err_code==NRF_SUCCESS)
						{
							NRF_LOG_INFO("DISCOVERY COMPLETED\r\n");
            
						}

            // Update LEDs status, and check if we should be looking for more
            // peripherals to connect to.
            bsp_board_led_on(CENTRAL_CONNECTED_LED);
            bsp_board_led_off(CENTRAL_SCANNING_LED);
						} break;

        // Upon disconnection, reset the connection handle of the peer which disconnected, update
        // the LEDs status and start scanning again.
        case BLE_GAP_EVT_DISCONNECTED:
        {
            NRF_LOG_INFO("Disconnected.");
            scan_start();
        } break;

        case BLE_GAP_EVT_TIMEOUT:
        {
            // We have not specified a timeout for scanning, so only connection attemps can timeout.
            if (p_gap_evt->params.timeout.src == BLE_GAP_TIMEOUT_SRC_CONN)
            {
                NRF_LOG_INFO("Connection request timed out.");
            }
        } break;

        case BLE_GAP_EVT_CONN_PARAM_UPDATE_REQUEST:
        {
            // Accept parameters requested by peer.
            err_code = sd_ble_gap_conn_param_update(p_gap_evt->conn_handle,
                                        &p_gap_evt->params.conn_param_update_request.conn_params);
            APP_ERROR_CHECK(err_code);
        } break;

        case BLE_GAP_EVT_PHY_UPDATE_REQUEST:
        {
            NRF_LOG_INFO("PHY update request.");
            ble_gap_phys_t const phys =
            {
                .rx_phys = BLE_GAP_PHY_AUTO,
                .tx_phys = BLE_GAP_PHY_AUTO,
            };
            err_code = sd_ble_gap_phy_update(p_ble_evt->evt.gap_evt.conn_handle, &phys);
            APP_ERROR_CHECK(err_code);
        } break;

        case BLE_GATTC_EVT_TIMEOUT:
        {
            // Disconnect on GATT Client timeout event.
            NRF_LOG_INFO("GATT Client Timeout.");
            err_code = sd_ble_gap_disconnect(p_ble_evt->evt.gattc_evt.conn_handle,
                                             BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION);
            APP_ERROR_CHECK(err_code);
        } break;

        case BLE_GATTS_EVT_TIMEOUT:
        {
            // Disconnect on GATT Server timeout event.
            NRF_LOG_INFO("GATT Server Timeout.");
            err_code = sd_ble_gap_disconnect(p_ble_evt->evt.gatts_evt.conn_handle,
                                             BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION);
            APP_ERROR_CHECK(err_code);
        } break;
				
				
				
         case BLE_GATTS_EVT_SYS_ATTR_MISSING:
            // No system attributes have been stored.
            err_code = sd_ble_gatts_sys_attr_set(p_ble_evt->evt.gatts_evt.conn_handle, NULL, 0, 0);
            APP_ERROR_CHECK(err_code);
        default:
            // No implementation needed.
            break;
				
    }
}

/**@brief Function for starting application timers.
 */
static void application_timers_start(void)
{
    ret_code_t err_code;

    // Start application timers.
    err_code = app_timer_start(m_battery_timer_id, BATTERY_LEVEL_MEAS_INTERVAL, NULL);
    APP_ERROR_CHECK(err_code);
}

/**@brief LED Button client initialization.
 */
static void lbs_c_init(void)
{
    ret_code_t       err_code;
    ble_lbs_c_init_t lbs_c_init_obj;

    lbs_c_init_obj.evt_handler = lbs_c_evt_handler;

    err_code = ble_lbs_c_init(&m_ble_lbs_c, &lbs_c_init_obj);
    APP_ERROR_CHECK(err_code);
}


/**@brief Function for initializing the BLE stack.
 *
 * @details Initializes the SoftDevice and the BLE event interrupts.
 */
static void ble_stack_init(void)
{
    ret_code_t err_code;

    err_code = nrf_sdh_enable_request();
    APP_ERROR_CHECK(err_code);

    // Configure the BLE stack using the default settings.
    // Fetch the start address of the application RAM.
    uint32_t ram_start = 0;
    err_code = nrf_sdh_ble_default_cfg_set(APP_BLE_CONN_CFG_TAG, &ram_start);
    APP_ERROR_CHECK(err_code);

    // Enable BLE stack.
    err_code = nrf_sdh_ble_enable(&ram_start);
    APP_ERROR_CHECK(err_code);

    // Register a handler for BLE events.
    NRF_SDH_BLE_OBSERVER(m_ble_observer, APP_BLE_OBSERVER_PRIO, ble_evt_handler, NULL);
}


/**@brief Function for handling events from the button handler module.
 *
 * @param[in] pin_no        The pin that the event applies to.
 * @param[in] button_action The button action (press/release).
 */
/*static void button_event_handler(uint8_t pin_no, uint8_t button_action)
{
    ret_code_t err_code;

    switch (pin_no)
    {
        case LEDBUTTON_BUTTON_PIN:
            err_code = ble_lbs_led_status_send(&m_ble_lbs_c, button_action);
            if (err_code != NRF_SUCCESS &&
                err_code != BLE_ERROR_INVALID_CONN_HANDLE &&
                err_code != NRF_ERROR_INVALID_STATE)
            {
                APP_ERROR_CHECK(err_code);
            }
            if (err_code == NRF_SUCCESS)
            {
                NRF_LOG_INFO("LBS write LED state %d", button_action);
            }
            break;

        default:
            APP_ERROR_HANDLER(pin_no);
            break;
    }
}
*/

/**@brief Function for handling Scaning events.
 *
 * @param[in]   p_scan_evt   Scanning event.
 */
static void scan_evt_handler(scan_evt_t const * p_scan_evt)
{
    ret_code_t err_code;

    switch(p_scan_evt->scan_evt_id)
    {
        case NRF_BLE_SCAN_EVT_CONNECTING_ERROR:
            err_code = p_scan_evt->params.connecting_err.err_code;
            APP_ERROR_CHECK(err_code);
            break;
        default:
          break;
    }
}



/**@brief Function for initializing the button handler module.
 */
/*static void buttons_init(void)
{
    ret_code_t err_code;

    //The array must be static because a pointer to it will be saved in the button handler module.
    static app_button_cfg_t buttons[] =
    {
        {LEDBUTTON_BUTTON_PIN, false, BUTTON_PULL, button_event_handler}
    };

    err_code = app_button_init(buttons, ARRAY_SIZE(buttons),
                               BUTTON_DETECTION_DELAY);
    APP_ERROR_CHECK(err_code);
}
*/

/**@brief Function for handling database discovery events.
 *
 * @details This function is callback function to handle events from the database discovery module.
 *          Depending on the UUIDs that are discovered, this function should forward the events
 *          to their respective services.
 *
 * @param[in] p_event  Pointer to the database discovery event.
 */
static void db_disc_handler(ble_db_discovery_evt_t * p_evt)
{
    ble_lbs_on_db_disc_evt(&m_ble_lbs_c, p_evt);
}


/**@brief Database discovery initialization.
 */
static void db_discovery_init(void)
{
    ret_code_t err_code = ble_db_discovery_init(db_disc_handler);
    APP_ERROR_CHECK(err_code);
}


/**@brief Function for initializing the log.
 */
static void log_init(void)
{
    ret_code_t err_code = NRF_LOG_INIT(get_rtc_counter);
    APP_ERROR_CHECK(err_code);

    NRF_LOG_DEFAULT_BACKENDS_INIT();
}
uint32_t  get_rtc_counter(void)
{
	return NRF_RTC1->COUNTER;
}


/**@brief Function for initializing the timer.
 */
static void timer_init(void)
{
    ret_code_t err_code = app_timer_init();
    APP_ERROR_CHECK(err_code);
	 err_code = app_timer_create(&m_battery_timer_id,
                                APP_TIMER_MODE_REPEATED,
                                battery_level_meas_timeout_handler);
    APP_ERROR_CHECK(err_code);

}


/**@brief Function for initializing the Power manager. */
static void power_management_init(void)
{
    ret_code_t err_code;
    err_code = nrf_pwr_mgmt_init();
    APP_ERROR_CHECK(err_code);
}


static void scan_init(void)
{
    ret_code_t          err_code;
    nrf_ble_scan_init_t init_scan;

    memset(&init_scan, 0, sizeof(init_scan));

    init_scan.connect_if_match = true;
    init_scan.conn_cfg_tag     = APP_BLE_CONN_CFG_TAG;

    err_code = nrf_ble_scan_init(&m_scan, &init_scan, scan_evt_handler);
    APP_ERROR_CHECK(err_code);

    // Setting filters for scanning.
    err_code = nrf_ble_scan_filters_enable(&m_scan, NRF_BLE_SCAN_NAME_FILTER, false);
    APP_ERROR_CHECK(err_code);

    err_code = nrf_ble_scan_filter_set(&m_scan, SCAN_NAME_FILTER, m_target_periph_name);
    APP_ERROR_CHECK(err_code);
}


/**@brief Function for initializing the GATT module.
 */
static void gatt_init(void)
{
    ret_code_t err_code = nrf_ble_gatt_init(&m_gatt, NULL);
    APP_ERROR_CHECK(err_code);
}


/**@brief Function for handling the idle state (main loop).
 *
 * @details Handle any pending log operation(s), then sleep until the next event occurs.
 */
static void idle_state_handle(void)
{
    NRF_LOG_FLUSH();
    nrf_pwr_mgmt_run();
}



int main(void)
{
    // Initialize.
    log_init();
    timer_init();
    leds_init();
   // buttons_init();
    power_management_init();
    ble_stack_init();
    scan_init();
    gatt_init();
    db_discovery_init();
    lbs_c_init();

    // Start execution.
    NRF_LOG_INFO("Blinky CENTRAL example started.");
    scan_start();

    // Turn on the LED to signal scanning.
    bsp_board_led_on(CENTRAL_SCANNING_LED);
	  application_timers_start();

    // Enter main loop.
    for (;;)
    {
        idle_state_handle();
    }
}

Please give me the solution

RE: Problem in data transfer in Bluetooth at 10ms

Karl Ylvisaker — Fri, 17 Apr 2020 13:34:01 GMT

Hello,

[quote user="sharmelaraju"]I am here by attaching the code.[/quote]

I am not sure I understand what you have shared with me in the previous snippet. It seems to be an incomplete snippet of the ble event handler?
Also, the defines you have stuck at the end of the snippet The defines should be located at the top of your source code file. I do not know if your placement of them inside the event handler is intentional. In short, the code snippet you included in the last comment does not provide me with anything to work with.

Could you instead share the entire project with me?
That way, I can attempt to replicate your error at my end, to see if I may find a solution to this issue.

If you would like, I can make the ticket private before you share your code - so that it is only viewable to you and the support staff here at Nordic Semiconductor.
Let me know if you could like me to do that.

Looking forward to hearing back from you,

Best regards,
Karl