Clock synchronization

Dear Engineer

When the advertiser and the scanner enter the connect callback, a timestamp will be printed immediately. The problem now is that the advertiser and the scanner do not seem to enter the connect callback at the same time and there will be a fixed time error of 2800us in the middle. Why is this

This is the advertiser's code

static void connected(struct bt_conn *conn, uint8_t conn_err)
{
 
   // update_timestamp();  // 获取当前时间戳
    if(conn_err) {
        printk("Connection failed (err %d)\n", conn_err);
        bt_conn_unref(conn);
        return;
    }
  //  unsigned int key = irq_lock();  // 禁用中断
      // 延迟获取时间戳,确保连接完全建立
     current_timestamp_us = k_ticks_to_us_floor64(k_uptime_ticks());
     num++;
}
This is the scanner's code
static struct bt_gatt_discover_params discover_params = { 0 };

    // 连接回调
    static void connected(struct bt_conn *conn, uint8_t conn_err)
    {
        if (conn_err) {
            printk("Connection failed (err %d)\n", conn_err);
            bt_conn_unref(conn);
            default_conn=NULL;
            k_work_submit(&restart_scan_work);
            return;
        }

    //  unsigned int key = irq_lock();  // 禁用中断
        local_conn_time_us = k_ticks_to_us_floor64(k_uptime_ticks());
        num++;
        //printk("Connected, local timestamp t2: %llu us\n", local_conn_time_us);
       

    if(!timestamp_synced){
        if (conn == default_conn) {
        // 启动 GATT 发现
        discover_params.uuid = &timestamp_uuid.uuid;
        discover_params.func = discover_func;
        discover_params.start_handle = 0x0001;
        discover_params.end_handle = 0xffff;
        discover_params.type = BT_GATT_DISCOVER_CHARACTERISTIC;

        int err = bt_gatt_discover(conn, &discover_params);
            if (err) {
                printk("GATT characteristic discovery failed: %d\n", err);
            }
        }
    }
    else {
        // 从第二次连接开始,不再进行 GATT 交互,直接断开连接
        bt_conn_disconnect(conn, BT_HCI_ERR_REMOTE_USER_TERM_CONN);
       
    }
    return;
   
    }
Parents
  • The 2800 µs delay might be corresponding to the time taken for the peripheral to process the connection request, establish the connection, and notify its application layer.

    It might help to get a clear sniffer log of this transactions so that we understand clearly what is going on in air to see if any side of the connection is misbehaving in terms of BLE timings.

  • Can you describe more clearly the clear sniffer log for this transaction and how I got this log from ncs v2.5.2? And the time it takes for this peripheral to process the connection request, establish the connection and notify its application layer, is this time clearly specified in the Bluetooth manual, or the program in the ncs suite of nordic company requires this fixed time, thank you

Reply
  • Can you describe more clearly the clear sniffer log for this transaction and how I got this log from ncs v2.5.2? And the time it takes for this peripheral to process the connection request, establish the connection and notify its application layer, is this time clearly specified in the Bluetooth manual, or the program in the ncs suite of nordic company requires this fixed time, thank you

Children
No Data
Related