• 【DWM1000】 code 解密8一 TAG接收blink response 信号


             在分析这个部分前,目前我看到DWM1000 的资料,data可以分为blink和一般无线数据,后面有内容我们再扩充, 上面我们已经看到接收到blink触发的事件为

    case SIG_RX_BLINK :

    一般数据包应该触发的的是

    case DWT_SIG_RX_OKAY :

    表示接收到一个无线无线数据包,具体怎么解析这个数据包我们一点点分析。

    好了,看TAG收到ANCHOR的blink response,这个数据包为一般数据包,具体数据内容我们前面简单列出来了,这里从TAG接收的角度一点点在分析。

    好了,还是上代码

    event_data_t* dw_event = instance_getevent(15); //get and clear this event

    uint8  srcAddr[8] = {0,0,0,0,0,0,0,0};

    int fcode = 0;

    int fn_code = 0;

    uint8 *messageData;

    inst->stoptimer = 0; //clear the flag, as we have received a message

    首先是获取事件getevent,这个应该是获取到接收数据成功的事件。后面紧随其后是一下变量的生命。后面看用到这些变量再看。

    switch(dw_event->msgu.frame[1])

    这个msgu.frame[1] 是啥内容,我们需要回到ANCHOR发送端看了

    #if (USING_64BIT_ADDR == 1)

                                         inst->rng_initmsg.frameCtrl[1] = 0xCC;

                                         inst->psduLength += FRAME_CRTL_AND_ADDRESS_L + FRAME_CRC;

    #else

    我们接着摘录具体的代码

    case 0xCC: //

    memcpy(&srcAddr[0], &(dw_event->msgu.rxmsg_ll.sourceAddr[0]), ADDR_BYTE_SIZE_L);

    fn_code = dw_event->msgu.rxmsg_ll.messageData[FCODE];

    messageData = &dw_event->msgu.rxmsg_ll.messageData[0];

    这个决定了我们从不同地方去srcAddr以及fn_code 和messageData。 后面用到这几个变量再看具体是什么内容

        if(inst->mode == ANCHOR)

          {

    ……

          }

          else // LISTENER or TAG

         {

                                fcode = fn_code;

         }

    接着后面看

      switch(fcode)

        {

               case RTLS_DEMO_MSG_RNG_INIT:

              {

    原来fcode是这些家伙,我们再看看ANCHOR发送的时候fcode是什么吧

    inst->rng_initmsg.messageData[FCODE] = RTLS_DEMO_MSG_RNG_INIT;

    正好是第一个case,直接在拉代码看看做了什么,没看代码前,我们根据发送时的数据(短地址以及两个delay)可以大概猜出来,TAG应该是保持这些数据,因为ANCHOR那边还在等着,所以应该还会发一个数据给ANCHOR。

    好,上代码

    先修改了两个非常重要的变量,我们记一下,等一会还会用到

    inst->testAppState = TA_TXE_WAIT;

    inst->nextState = TA_TXPOLL_WAIT_SEND ; // send next poll

    后面就是从数据包提取短地址和两个delay

    inst->tagShortAdd = messageData[RNG_INIT_TAG_SHORT_ADDR_LO]                                                        + (messageData[RNG_INIT_TAG_SHORT_ADDR_HI] << 8) ;

    // Get response delays from message and update internal timings accordingly

    resp_dly[RESP_DLY_ANC] =  messageData[RNG_INIT_ANC_RESP_DLY_LO]

    + (messageData[RNG_INIT_ANC_RESP_DLY_HI] << 8);

    resp_dly[RESP_DLY_TAG] =  messageData[RNG_INIT_TAG_RESP_DLY_LO]

    + (messageData[RNG_INIT_TAG_RESP_DLY_HI] << 8);

    其中短地址被保存到结构体instance中,而两个delay目前只保存到临时变量里。

    后面两个delay在代码中进行了转换,最终计算出了两个delay保存到instance中了

    // Update delay between poll transmission and response reception.

    inst->txToRxDelayTag_sy

    // Update delay between poll transmission and final transmission.

    inst->finalReplyDelay

    inst->finalReplyDelay_ms

    后面的inst->sleep_en = 0; 我们姑且认为是吧。 接着分析后面的代码

    #if (USING_64BIT_ADDR == 1)

    memcpy(&inst->msg.destAddr[0], &srcAddr[0], ADDR_BYTE_SIZE_L);

    //set the anchor address for the reply (set destination address)

    #else

    看代码,用的是64bit 地址,前面分析srcAddr其实是源地址

    memcpy(&srcAddr[0], &(dw_event->msgu.rxmsg_ll.sourceAddr[0]), ADDR_BYTE_SIZE_L);

    也就是ANCHOR的地址,我们可以看到执行

    memcpy(&inst->msg.destAddr[0], &srcAddr[0], ADDR_BYTE_SIZE_L);

    也就是destAddr[0]里面存放的ANCHOR的地址

    接着看后面依然有个地址复制,我们先记录先来看看是否有用。

    memcpy(&inst->relpyAddress[0], &srcAddr[0], ADDR_BYTE_SIZE_L);

     //remember who to send the reply to (set destination address)

    后面的代码就是几个变量的赋值了

    inst->mode = TAG ;

    inst->instToSleep = 0;

    inst->instancetimer_saved = inst->instancetimer = portGetTickCount(); //set timer base

    然后退出testapprun_s,来回分析ANCHOR 和TAG已经忘记done的状态了,我们暂且认为不需要定时器,所以回很快再次进去testapprun_s。首先列一下重要变量

    inst->testAppState = TA_TXE_WAIT;

    inst->nextState = TA_TXPOLL_WAIT_SEND ; // send next poll

    inst->mode = TAG ;

    然后在testapprun_s找案发现场

    case TA_TXE_WAIT : //either go to sleep or proceed to TX a message

           //if we are scheduled to go to sleep before next sending then sleep first.

           if(((inst->nextState == TA_TXPOLL_WAIT_SEND)

             || (inst->nextState == TA_TXBLINK_WAIT_SEND))

             && (inst->instToSleep)  //go to sleep before sending the next poll

                        )

             {

    根据绿色标出的地方,可以看出,满足if判断

    //the app should put chip into low power state and wake up in tagSleepTime_ms time...

    //the app could go to *_IDLE state and wait for uP to wake it up...

    inst->done = INST_DONE_WAIT_FOR_NEXT_EVENT_TO;

     //don't sleep here but kick off the TagTimeoutTimer (instancetimer)

    inst->testAppState = TA_SLEEP_DONE;

     if(inst->mode == TAG_TDOA) //once we start ranging we want to display the new range

             {

                                ……不满足条件

             }

    #if (DEEP_SLEEP == 1) 宏定义确实为1

         if (inst->sleep_en) 上面我们假定这个参数为0

          {

                 ……不满足条件

           }

    #endif

                       //DW1000 gone to sleep - report the received range

                       if(inst->tof > 0) //if ToF == 0 - then no new range to report

                       {

                        ……

                       }

    后面的tof我们之前也没有遇到过,假定为0,也不满足。绕了一圈,发现其实这次进入到testapprun_s只设置两个两个重要变量

    inst->done = INST_DONE_WAIT_FOR_NEXT_EVENT_TO;

    inst->testAppState = TA_SLEEP_DONE;

    根据之前分析,由于是INST_DONE_WAIT_FOR_NEXT_EVENT_TO,在instance_run 会开个定时器。我们认为溢出前会先进入testapprun_s,看看在TA_SLEEP_DONE 做了什么吧。接着找作案现场

    case TA_SLEEP_DONE :

    {

        event_data_t* dw_event = instance_getevent(10); //clear the event from the queue

                                // waiting for timout from application to wakup IC

             if (dw_event->type != DWT_SIG_RX_TIMEOUT)

             {

                       // if no pause and no wake-up timeout continu waiting for the sleep to be done.

             inst->done = INST_DONE_WAIT_FOR_NEXT_EVENT; //wait here for sleep timeout

               break;

        }

    可以看出如果进来发现不是TIMEOUT,一直break,所以定时器一直需要等待溢出才执行后面的代码。

    ……等待定时器,等待定时器……溢出。好了,我们看后面的代码

    inst->done = INST_NOT_DONE_YET;

    inst->instToSleep = 0;

    inst->testAppState = inst->nextState;

    inst->nextState = 0; //clear

    inst->instancetimer_saved = inst->instancetimer = portGetTickCount(); //set timer base

    有点尴尬nextState好像好久没用到,没事回头找代码

    case RTLS_DEMO_MSG_RNG_INIT:

    {

          if(inst->mode == TAG_TDOA) //only start ranging with someone if not ranging already

             {

                 uint32 final_reply_delay_us;

                 uint32 resp_dly[RESP_DLY_NB];

                 int i;

                 inst->testAppState = TA_TXE_WAIT;

                 inst->nextState = TA_TXPOLL_WAIT_SEND ; // send next poll

    根据done = INST_NOT_DONE_YET;退出不加载定时器,根据TA_TXPOLL_WAIT_SEND 我们再找作案现场

      case TA_TXPOLL_WAIT_SEND :  //TAG:send poll message

                {

    这里主要是发送poll message给ANCHOR

    与发送相关的代码

    inst->msg.seqNum = inst->frame_sn++;

    setupmacframedata(inst, RTLS_DEMO_MSG_TAG_POLL);

    #if (USING_64BIT_ADDR==1)

             inst->psduLength = TAG_POLL_MSG_LEN + FRAME_CRTL_AND_ADDRESS_L + FRAME_CRC;

    #else

    dwt_writetxdata(inst->psduLength, (uint8 *)  &inst->msg, 0) ;  // write the frame data

    dwt_writetxfctrl(inst->psduLength, 0);

    dwt_starttx(DWT_START_TX_IMMEDIATE | inst->wait4ack);

    发送具体数据包在meg中了,我们现在具体不看,ANCHOR用到在看,反正是发送了,而且还是个DWT_RESPONSE_EXPECTED

    inst->wait4ack = DWT_RESPONSE_EXPECTED;

    还设置了两个延时,tx后多久打开接收器等待应答,以及rx 的timeout

    //set the delayed rx on time (the response message will be sent after this delay)

    dwt_setrxaftertxdelay(inst->txToRxDelayTag_sy);

    dwt_setrxtimeout((uint16)inst->fwtoTime_sy);

    发送完poll message等待应答需要转状态,保存重要变量

    inst->testAppState = TA_TX_WAIT_CONF ;   // wait confirmation

    inst->previousState = TA_TXPOLL_WAIT_SEND ;

    inst->done = INST_DONE_WAIT_FOR_NEXT_EVENT; //will use RX FWTO to time out (set below)

    根据done,知道退出后不需要启动定时器。

    之前我们就分析过TA_TX_WAIT_CONF,不过这个函数会根据previousState有很多岔路,我们接着分析它

    if(dw_event->type != DWT_SIG_TX_DONE) //wait for TX done confirmation

    {

             if(dw_event->type == DWT_SIG_RX_TIMEOUT)

             {

             ……没有启动定时器,所以不会执行到这里

             }    

        inst->done = INST_DONE_WAIT_FOR_NEXT_EVENT;

        break;

    }

    由这段代码可以看出,TAG一直不停的循环,直到等待DWT_SIG_TX_DONE,也就是DWM1000把数据包发送出去。

    inst->done = INST_NOT_DONE_YET;

    else

     {

             inst->txu.txTimeStamp = dw_event->timeStamp;

    if(inst->previousState == TA_TXPOLL_WAIT_SEND)

              {

    可以看出,满足if 判断会接着执行后面的代码,后面很多代码都是计算poll message 发送时间的。

    uint64 tagCalculatedFinalTxTime ;

    // Embed into Final message: 40-bit pollTXTime,  40-bit respRxTime,  40-bit finalTxTime

    tagCalculatedFinalTxTime = (inst->txu.txTimeStamp + inst->finalReplyDelay) & MASK_TXDTS;

     // time we should send the response

    inst->delayedReplyTime = tagCalculatedFinalTxTime >> 8;

    // Calculate Time Final message will be sent and write this field of Final message

    // Sending time will be delayedReplyTime, snapped to ~125MHz or ~250MHz boundary by

    // zeroing its low 9 bits, and then having the TX antenna delay added

    // getting antenna delay from the device and add it to the Calculated TX Time

    tagCalculatedFinalTxTime = tagCalculatedFinalTxTime + inst->txantennaDelay;

    tagCalculatedFinalTxTime &= MASK_40BIT;

    // Write Calculated TX time field of Final message

    memcpy(&(inst->msg.messageData[FTXT]), (uint8 *)&tagCalculatedFinalTxTime, 5);

    // Write Poll TX time field of Final message

    memcpy(&(inst->msg.messageData[PTXT]), (uint8 *)&inst->txu.tagPollTxTime, 5);

    这几个时间我们后面在分析,我们先看代码

    inst->testAppState = TA_RXE_WAIT ;  

    message = 0;

    //break ; // end case TA_TX_WAIT_CONF

    case TA_RXE_WAIT :  //enable rx,and  wait to recive a message

    接着会执行TA_RXE_WAIT ,根据之前的分析结果,这里只是打开接收器等到数据,所以到此为止,TAG又开始等待了,等待ANCHOR回复。

    总结一下该小段: TAG发送poll message给ANCHOR后进入等待状态,ANCHOR应该此时接收数据并回复TAG。

    博客讨论一些室内定位(DWM1000/CC2431/CC2530) 以及一些随性的技术。博文可以转载,但需要注明出处!
  • 相关阅读:
    递归实现全排列问题
    LeetCode
    LeetCode
    连续子元素最大和
    简单模板view调用
    如何清除PHP中不需要的Layout模板
    Model中设置表单验证方法
    数据修改操作
    MVC模式tp框架四中路由形式
    zend Framework的MVC模式的搭建
  • 原文地址:https://www.cnblogs.com/tuzhuke/p/7719491.html
Copyright © 2020-2023  润新知