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;
   
    }
  • I need to further supplement the problem I encountered. In the serial port debugging information of the advertiser, I will be given a warning, which is as follows: W: opcode 0x200a status 0x0d

    The following is the debugging information printed out of my serial port

    *** Booting nRF Connect SDK v2.5.0 ***
    Timestamp service provider starting...
    I: SoftDevice Controller build revision:
    I: c5 93 ba a9 14 4d 8d 05 |.....M..
    I: 30 4e 9b 92 d7 71 1e e8 |0N...q..
    I: aa 02 50 3c |..P<
    I: HW Platform: Nordic Semiconductor (0x0002)
    I: HW Variant: nRF52x (0x0002)
    I: Firmware: Standard Bluetooth controller (0x00) Version 197.47763 Build 2370639017
    I: Identity: E1:61:76:F1:19:1B (random)
    I: HCI: version 5.4 (0x0d) revision 0x1102, manufacturer 0x0059
    I: LMP: version 5.4 (0x0d) subver 0x1102
    Bluetooth initialized successfully
    == Advertising Data ==
    Type: 0x01, Length: 1, Data: 06
    Type: 0x03, Length: 2, Data: 56 78
    Type: 0x19, Length: 2, Data: 00 07
    Type: 0x09, Length: 11, Data: 54 53 5f 50 72 6f 76 69 64 65 72
    W: opcode 0x200a status 0x0d
    1 0 802825
    W: opcode 0x200a status 0x0d
    1 1 10902984
    W: opcode 0x200a status 0x0d
    1 2 20992767
    W: opcode 0x200a status 0x0d
    1 3 31084533

  • 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.

Related