This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

关于cc1310下TI15.4协议栈 collector与 sensor中断连接问题

Other Parts Discussed in Thread: CC1310

TI大神,你好!

请教问题如下

问题背景:

1、应用TI15.4协议栈LRM 模式 5k速率,每半小时sensor向collector发送一次数据,collector接收到sensor信息并串口打印;

2、collector与 sensor距离很近,经过实地测量平均信号强度为-87dbm;

3、collector配对6个sensor。

问题描述:

1、所有设备上电,系统正常稳定工作5小时左右,collector串口输出:

!Responding: 0x1
!Responding: 0x2
!Responding: 0x3
!Responding: 0x4
!Responding: 0x5
!Responding: 0x6

然后串口无信息输出。

2、故障出现几小时后,sensor不重启,重启collector后,sensor能够重新入网,并正常工作。

3、已经排除内存溢出的可能性、

4、怀疑会不会是串口引发的问题?

望大神不吝赐教!

  • 发送Responding: 0x1是由于 tracking message 没有成功的原因,或者是tracking 失败。
    The application calls this function to indicate that a device is no longer active in the network


    在过高的 polling time可能存在一些问题。当你的collector 想要下发一些信息给到sensor时,很有可能因为你的sensor在poll 间隔期无法发出。

    Responding 通常时由于没有发出,然后collector 决定了判读sensor 是否存在,所以发出了 tracking ,
    当 tracking message 没有在TRACKING_DELAY_TIME收到了rsp 则认为该设备为非alive状态,因为它从未回复跟踪消息。从而触发Csf_deviceNotActiveUpdate。

    请问你是否对demo进行了修改,特别是下面的参数:

    #define CONFIG_REPORTING_INTERVAL 2000
    /*!
    Polling interval in milliseconds to be set on connected devices using
    configuration request messages. Must be greater than or equal to default
    polling interval set on sensor devices
    */
    #define CONFIG_POLLING_INTERVAL 500
    /*!
    Time interval in ms between tracking message intervals
    */
    #define TRACKING_DELAY_TIME 2000
  • Alvin Chen,你好!

    感谢你的帮助!

    关于传感器网络的参数,我们只修改了信息传送间隔,其余全部沿用了demo的配置(传感器、集中器参数相同),如下:

    #define CONFIG_REPORTING_INTERVAL 1800000
    /*!
    Polling interval in milliseconds to be set on connected devices using
    configuration request messages. Must be greater than or equal to default
    polling interval set on sensor devices
    */
    #define CONFIG_POLLING_INTERVAL 60000
    /*!
    Time interval in ms between tracking message intervals
    */
    #define TRACKING_DELAY_TIME 300000

    我们分析:

    1、如果单次tracking message无响应,collector 认为目标传感器!Responding: 0x1,那么过一段时间以后,collector再次发出tracking message理论上应该可以正常接收,但是本例中后续没有任何重新tracking成功的迹象,并且重启collector后所有传感器能够迅速入网,说明无线信道的连通性应该没有问题。

    2、本例问题中collector 是在某一时刻出现全部传感器 tracking message失败,这个现象很奇怪,并且是否有助于分析错误原因。

    3、本问题属于偶发问题,有时可以持续工作很久,有时几小时就出现问题,并且现象相同,由于在办公室环境下从未出现问题,而在野外部署则有可能出现问题,是否能够怀疑环境因素有影响?

    再次感谢!

  • 也是有可能的不好说,你都说了是偶然现象。
  • 你把TRACKING_DELAY_TIME 加大到和你的CONFIG_REPORTING_INTERVAL一样测试一下。
  • 还有一种情况可以恢复网络通信:
    在不下电的情况下,将传感器和集中器分开到保证没有信号通信的地方,然后再放回原位,这时,可以重新连接
  • 这种是正常的rejoin 操作。
  • 在demo中:
    collector 的 CONFIG_REPORTING_INTERVAL 是 300000,我们改为1800000
    sensor 的 CONFIG_REPORTING_INTERVAL 是 600000,我们同样改为1800000

    两个问题:
    1、demo 中collector 和 sensor 的CONFIG_REPORTING_INTERVAL 是不相同的,经过测试demo中,实际的CONFIG_REPORTING_INTERVAL 应该是300000。为什么这么配置?
    2、我们应用中将collector 和sensor 的 CONFIG_REPORTING_INTERVAL改位相同的1800000,会不会存在问题?

    另外:还有一种情况可以恢复网络通信:
    在不下电的情况下,将传感器和集中器分开到保证没有信号通信的地方,然后再放回原位,这时,可以重新连接。
  • sensor加入collecotor後會先用自己本身的CONFIG_REPORTING_INTERVAL ,但是如果收到collector 的 CONFIG_REPORTING_INTERVAL 封包去更動sensor的report interval,就會改用collector 的 CONFIG_REPORTING_INTERVAL
  • 但是,当上述故障出现后,不这么操作的时候,传感器无法rejoin
  • collector与 sensor距离很近,经过实地测量平均信号强度为-87dbm;

    你用的是TI的開發版,還是你自己的硬件?如果是你自己的硬件,看來你硬件RF 設計有問題,要先詳查這部份

  • 实际距离300米,穿4堵墙,-87dbm;应该是没问题的,我们和开发板一起测试,信号强度差不多。
  • 那你原始問題怎會提到 "collector与 sensor距离很近"? 如果是实际距离300米,穿4堵墙,-87dbm;应该是没问题
  • 这个很近我是根据TI官方的标准对比的,1.5km甚至到20km,表述有点问题,请见谅。如果10m以内,天线位置得当,并且无遮挡,信号强度应该是-1X到-25之间,
  • 但是你中間穿4堵墙,這個應該會導致信號有時候不良而掉線吧
  • 如果只是单个掉线,或者某时刻某几个掉线,可以怀疑信号问题,并且信号问题不会影响rejoin,而现在的情况是,某一时刻全部sensor统一无响应,并且不会rejoin,重启collector后sensor全部上线。
  • 你用的SDK版本是?
  • simplelink_cc13x0_sdk_2_40_00_20
  • 要不要試試最新的3.10.00.11是不是還有同樣的問題
  • 能不能帮忙分析一下原因啊
  • 如果是協議棧卡住,很難分析,只能建議用最新的協議棧版本,或是定時重啟collector當作workaround
  • 也是个办法,有没有定时重启的demo或者例程,我们临时采用一下
  • 沒有這樣的例程,不過你只要起個timer event去做定时重启就好
  • YiKai Chen你好:

    麻烦您帮忙分析下问题,或者帮忙提供一个解决方案,不胜感激!

    根据您的建议,我们在原有程序的基础上做了改进实验,改进包括:

    1.采用最新的15.4协议栈

    2.增加重启机制

    3.调整了TRACKING_DELAY_TIME 为CONFIG_REPORTING_INTERVAL(30min)

    实验内容:

    分别通过4个collector建立传感器网络(通过CONFIG_PAN_ID区分不同网络),其中1个网络可以保证完全与其他网络隔离

    存在问题:

    1.掉线问题依然存在

    与之前相同,正常运行数小时后,collector停止打印传感器传送的数据,由于TRACKING_DELAY_TIME设置为30min,collector未打印!Responding信息。

    在断线数十小时后,又能够恢复正常通信,collector正常打印sensor传送来的数据。

    2.重启机制执行无效

    目前我们涉及了两个计时器:1)collector启动后9小时重启;2)collector1.5小时内没有收到sensor消息则重启。

    目前看来两个重启策略都没有奏效,代码如下:

    时钟初始化增加重启始终初始化:

    static void initializeClocks(void)
    {
        /* Initialize the tracking clock */
        Csf_initializeRestartClock();
        Csf_initializeTrackingClock();
        Csf_initializeConfigClock();
        Csf_initializeBroadcastClock();
        Csf_initializeIdentifyClock();
    }

    重启时钟的初始化,其中RESTART_DELAY_TIME  32400000   (9小时)

    void Csf_initializeRestartClock(void)
    {
        /* Initialize the timers needed for this application */
        restartClkHandle = Timer_construct(&restartClkStruct,
                                           processCollectorRestartCallback,
                                           RESTART_DELAY_TIME,
                                            0,
                                            false,
                                            0);
    
        Timer_setTimeout(restartClkHandle, RESTART_DELAY_TIME);
        Timer_start(&restartClkStruct);
    
        restartClkHandle2 = Timer_construct(&restartClkStruct2,
                                           processCollectorRestartCallback,
                                           RESTART_DELAY_TIME,
                                            0,
                                            false,
                                            0);
    }
    //设置重启时钟:
    void Csf_setRestartClock(uint32_t restartTime)
    {
        /* Stop the restart timer */
        if(Timer_isActive(&restartClkStruct) == true)
        {
            Timer_stop(&restartClkStruct);
        }
    
        if(restartTime)
        {
            /* Setup timer */
            Timer_setTimeout(restartClkHandle, restartTime);
            Timer_start(&restartClkStruct);
        }
    }
    
    
    void Csf_setRestartClock2(uint32_t restartTime2)
    {
        /* Stop the restart timer */
        if(Timer_isActive(&restartClkStruct2) == true)
        {
            Timer_stop(&restartClkStruct2);
        }
    
        if(restartTime2)
        {
            /* Setup timer */
            Timer_setTimeout(restartClkHandle2, restartTime2);
            Timer_start(&restartClkStruct2);
        }
    }

    在collector主循环中增加如下代码:

        /* Allow the Specific functions to process */
        Csf_processEvents();
    
    #ifdef FEATURE_SECURE_COMMISSIONING
        /* Allow the security manager specific functions to process */
        SM_process();
    #endif /* FEATURE_SECURE_COMMISSIONING */
        /*处理串口发送事件*/
        if (Collector_events & COLLECTOR_CLOUD_SEND_EVT)
        {
    
            uint16_t sensorData2Cloud_string_LEN;
            /* Clear the event */
            Util_clearEvent(&Collector_events, COLLECTOR_CLOUD_SEND_EVT);
    
           …………………………………………
    
            TaskUARTWrite(Pak_sensorData2Cloud_string, Pak_sensorData2Cloud_string_LEN);//写串口
            Csf_free(sensorData2Cloud_string);
    Csf_setRestartClock2(7200000);//1.5hour restart 更新重启时间 }

    请您指导一下,有何问题。而导致两个重启动作都不生效。

    几点疑问:

    1. 环境因素是否影响协议栈正常工作?(温湿度,传感器间干扰等)

    2. collector匹配的传感器数量是否导致短线现象

    3.  ti15.4协议栈采碰撞避免算法是否有影响

    4. 新版本的协议栈与2.40协议栈有什么不同?

    相关配置情况:

    collector的配置如下:

    #define CONFIG_REPORTING_INTERVAL 1800000
    #define CONFIG_POLLING_INTERVAL 60000
    #define TRACKING_DELAY_TIME 1800000  //将默认值1min改为:30min与reporting时间先沟通
    #define  RESTART_DELAY_TIME 32400000 //新增重启时间(每9小时重启)

    sensor配置如下:

    #define CONFIG_POLLING_INTERVAL      60000
    #define CONFIG_PAN_ADVERT_SOLICIT_CLK_DURATION    60000
    #define CONFIG_PAN_CONFIG_SOLICIT_CLK_DURATION    60000
    #define CONFIG_REPORTING_INTERVAL  1800000//1800000  :  30min//
  • 1.请你抓包看一下是sensor 不发数据了,还是sensor发送了数据, collector不回复导致的leave。怀疑是内存问题导致了死机,可以适当的加大下面的值:

    MAC_CFG_TX_DATA_MAX 

    MAC_CFG_TX_MAX

    MAC_CFG_RX_MAX

    2.如果你数量不是过多不会有影响。

    3.CSMA/CA算法默认在协议中使用。

    4.请具体看协议中的说明:http://dev.ti.com/tirex/explore/node?node=ABot4AjbS-88ia3wbftauA__eCfARaV__LATEST

  • 您说的内存问题具体是什么, 因为断线后,十几小时后会重新连接(期间无任何认为干扰),并且内存经过验证不会溢出?
    目前4个collector网络   分别配置6个、10个、12个、18个传感器并且都会出现断线情况

    经过测试sensor是发送了数据包的

    其实您建议的collector重启是目前一个很好的解决方案,但是经过测试,重启并没有奏效,请求帮助

  • 1.你的sensor 有没有正常按照poll rate 发送 data request.

    2.你如果说是collector 无法运行到你的重启定时器任务,是否为collector 跑飞或者死机,

    3.你除了修改那几个参数有没有修改一些其他东西。

    如果方便,你可以试一下完全没有改动的sensor/collector demo。

  • 两个重启策略都没有奏效?你是指collector時間到了沒有被重啟?你重啟的程序是在processCollectorRestartCallback?還有你有抓包檔可以分析問題嘛?

  • callback只是setevent  :
    static void processCollectorRestartCallback(UArg a0) { (void)a0; /* Parameter is not used */ Util_setEvent(&Collector_events, COLLECTOR_RESTART_EVT); /* Wake up the application thread when it waits for clock event */ Semaphore_post(collectorSem); }

    collector的大循环中 加入事件响应并重启:

        if(Collector_events & COLLECTOR_RESTART_EVT)
            {
    
                CollectorAssertHandler();
                /* Clear the event */
                Util_clearEvent(&Collector_events, COLLECTOR_RESTART_EVT);
    
    
            }
    void CollectorAssertHandler(void)
    {
        /* User defined function */
        Main_assertHandler(MAIN_ASSERT_COLLECTOR_RESTART);
    }
    void Main_assertHandler(uint8_t assertReason)
    {
        Main_assertReason = assertReason;
    
    #if defined(RESET_ASSERT)
        Csf_assertInd(assertReason);
    
        /* Pull the plug and start over */
        SysCtrlSystemReset();
    #else
        Hwi_disable();
        while(1)
        {
            /* Put you code here to do something if in assert */
        }
    #endif
    }

  • 你調試你的這部份程序會看到系統重啟嘛?
  • 调试的时候可以重启的
  • 建議你加上WATCHDOG ,萬一程序真的整個卡死,也會WATCHDOG reset
  • 这个和时钟有什么区别吗
  • WATCHDOG 算是硬件重啓

  • 交流下,cc1310。qq:3360133878