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 抓包信息咨询,sensor关联之后发送数据包,collector无法收到(断点在collector接收处),抓包信息确有ACK回复。SDK,2.4,sensor/collector

  • 断点重启一次就可以了
  • 例程是否有改动?通信多久后出现问题?每次都能复现吗?
  • 偶尔出现,10个sensor大概1-2个。关联请求之后就出现此现状(非信标节点入网后,发送数据。collector无法加收,抓包信息如上。)。例子有改动。
  • 请问下,sensor发出的关联请求中的channel是对应的信道?0-6?
    我collector中的信道设置是
    #define CONFIG_CHANNEL_MASK { 0x64, 0x00, 0x00, 0x00, 0x00, 0x00, \0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \ 0x00, 0x00, 0x00, 0x00, 0x00 }

    如果我要去关联,channel对应6?

    我在测试中,sensor发送关联请求,无论是哪个collector,channel设置为0才可以请求成功,否则返回的是E9.(我想sensor主动去关联某个collector)在关联发送函数中需要传入三个参数,网络短地址 默认AABB ,PANID,CHANNEL
  • 你想做什么?

    /*!
    Channel mask used when CONFIG_FH_ENABLE is false.
    Each bit indicates if the corresponding channel is to be scanned
    First byte represents channels 0 to 7 and the last byte represents
    channels 128 to 135.
    For byte zero in the bit mask, LSB representing Ch0.
    For byte 1, LSB represents Ch8 and so on.
    e.g., 0x01 0x10 represents Ch0 and Ch12 are included.
    The default of 0x0F represents channels 0-3 are selected.
    APIMAC_STD_US_915_PHY_1 (50kbps/2-FSK/915MHz band) has channels 0 - 128.
    APIMAC_STD_ETSI_863_PHY_3 (50kbps/2-FSK/863MHz band) has channels 0 - 33.
    APIMAC_GENERIC_CHINA_433_PHY_128 (50kbps/2-FSK/433MHz band) has channels 0 - 6.
    */
    #define CONFIG_CHANNEL_MASK { 0x0F, 0x00, 0x00, 0x00, 0x00, 0x00, \
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \
    0x00, 0x00, 0x00, 0x00, 0x00 }

    #define CONFIG_CHANNEL_MASK { 0x64, 0x00, 0x00, 0x00, 0x00, 0x00, \0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \ 0x00, 0x00, 0x00, 0x00, 0x00 }

    你这个写法不对吧

    举个例子你想设置channel 1:

    #define CONFIG_CHANNEL_MASK { 0x02, 0x00, 0x00, 0x00, 0x00, 0x00, \
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \
    0x00, 0x00, 0x00, 0x00, 0x00 }----->信道0

  • 你具体卡在那里,大致说一些你做了什么改动。
  • 信道难道不是?
    #define CONFIG_CHANNEL_MASK 中 1 2 4 8 16 32 64 对应信道0 1 2 3 4 5 6

    channel 的概念是 1-7对应信道0-6?
  • 不是啊
    0xf 代表0 1 23 四个信道,分别是 1111 为F

  • 加入你要0 和12 channel 有效则是
    1 0000 0000 0001
    01 10
    e.g., 0x01 0x10 represents Ch0 and Ch12 are included.


    0-6 111 1111 7F

  • #define CONFIG_CHANNEL_MASK { 0x0F, 0x00, 0x00, 0x00, 0x00, 0x00, \0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \0x00, 0x00, 0x00, 0x00, 0x00 }

    1111 1111 是FF

    F对应 1111

    0111 1111
    1 2 4 8 16 32 64

    按照你说的如果是四个信道 0 1 23 是0F
    那5,6,7 是1F 2F 4F?


    你下面说的
    0-6 111 1111 7F
    不懂
  • For example, 0x01 0x10 represents Ch0 and Ch12 are included.
  • 你自己想想。。。。

    1 有效 0无效。
    加入channel 6有效 100 0000 0x40
  • 我理解错你的意思。
    我的意思是我开单个的开启某个信道

    0000 0001 0信道 1
    0000 0010 1信道 2
    0000 0100 2信道 4
    0000 1000 3信道 8
    0001 0000 4信道 16
    0010 0000 5信道 32
    0100 0000 6信道 64

    如果我打开所有信道是7F或者FF应该都可以吧

    然后0f是打开前四个信道

    通道1-7对应是的信道0-6吗?
  • 你想设置有效就是设置为1 无效为 0 然后转为16进制,我表达能力有限,希望你能理解。0001 0000 是0x10
  • 信道的概念我理解了,我上面是用十进制表示。

    通道这个概念我应该怎么理解。

    我现在把7个collector设置成不同的信道。是0-6信道。collector panid已知。

    我sensor要去关联6信道的Collector,我应该把channel设置为什么?是在config中修改,还是直接给关联中的devInFoBlock.channel赋值?
  • 如果你的sensor 不固定panid 为FFFF 则需要设置信道 ,如果你的sensor panid 和要去连接的collector 一致则设置为相同的channel 或者0-6 全部有效也可以。

    设置channel 需要在config里面修改。

  • 我想请问的是:
    sensor去连接一个collector(collector 的panid为12345 ,短地址AABB ,信道是1)

    sensor发送直接关联请求
    devInFoBlock.panid=12345 ;
    devInFoBlock.coordshortaddr=0XAABB;

    devInFoBlock.channel=这个时候通道是多少?

    我自己测试把channel设置为1,关联失败。如果设置为0,则成功。

    我想知道channel这个值是如何判断的。或者是应该如何设置。或者说channel 对应的信道0-6如何修改
  • 你没必要去操作associate ,你在发送scan request;
    static void sendScanReq(ApiMac_scantype_t type)
    {
    ApiMac_mlmeScanReq_t scanReq;
    /* set common parameters for all scans */
    memset(&scanReq, 0, sizeof(ApiMac_mlmeScanReq_t));
    /* set scan channels from channel mask*/
    memcpy(scanReq.scanChannels, defaultChannelMask,


    defaultChannelMask这个扫描channel 就是你在config 里面设置的,后面的你无需操作。
    建议你去看一下code。
  • 我知道,扫描是可以修改config中的CONFIG_CHANNEL_MASK,

    我有个需求,需要直接关联collector。

    因为在某个collector死机或者断点,sensor应该去连接对应的collector,而不是自己去scan。这样子会让其他在线的collector,连接的sensor压力会很大。所以我想让sensor得到collector信息的情况下直接去关联他。


    我现在有7个collector (panid分别是 abcdefg),分别修改了
    #define CONFIG_CHANNEL_MASK { 0x0F, 0x00, 0x00, 0x00, 0x00, 0x00, \ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \ 0x00, 0x00, 0x00, 0x00, 0x00 };
    0x0f代替如下
    0x01
    0x02
    0x04
    0x08
    0x10
    0x20
    0x40


    abcdefg的短地址都是AABB。

    我sensor第一次扫描到了collector D。正常通讯(传递了其他6个collector的panid)。这时候如果D断线了。我的分配让我去连接collector F。然后直接发送关联

    devInFoBlock.panid=F;
    devInFoBlock.coordshortaddr=0XAABB;

    devInFoBlock.channel=
    我把channel设置为0x20 或者设置为5。都无法关联。只有设置为0才可以。不懂
    devInFoBlock.channel。
    而且我用scan结果看
    devInFoBlock.channel这个值也是0
  • 你试试清除NV
  • 我肯定是清除了NV。应为我的自己定义了一块flash,第一次连接后,我把7个collector 信息存在了自定义的flash中。每次重启,我都会在main中SSF_CLEARALLNVITEMS();和Ssf_clearNetworkInfo();
  • 我把所有的collector 都扫描了一边,
    发现
    devInfoBlock.channel = pData->panDesc.logicalChannel;
    都是为0.
    如果按照你说的collector中
    #define CONFIG_CHANNEL_MASK { 0x0F, 0x00, 0x00, 0x00, 0x00, 0x00, \0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \0x00, 0x00, 0x00, 0x00, 0x00 }
    可以设置。devInfoBlock.channel = pData->panDesc.logicalChannel;返回应该不是0呀。
  • "我把channel设置为0x20 或者设置为5。都无法关联。只有设置为0才可以。不懂
    devInFoBlock.channel。"

    你去发送associate request的collector channel 到底是什么? 如果是0x20 ,你设置为channel=0不可能发送的到。

  • 我现在有7个collector (panid分别是 abcdefg),分别修改了
    #define CONFIG_CHANNEL_MASK { 0x0F, 0x00, 0x00, 0x00, 0x00, 0x00, \ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \ 0x00, 0x00, 0x00, 0x00, 0x00 };
    0x0f代替如下 :
    0x01
    0x02
    0x04
    0x08
    0x10
    0x20
    0x40


    associate request发送的channel=0只有等于0才可以。channel=0x20或者channel=5都不可以。
  • #define CONFIG_CHANNEL_MASK 不能够定义channel,在主动请求中可以修改这个111 1111。

    我刚刚断点调试了collector代码,是因为collector的coordInfoBlock.channel=0;

    这是非信标模式。我上图画圈这一步可以直接屏蔽吗?或者我直接coordInfoBlock.channel赋值?

  • "我刚刚断点调试了collector代码,是因为collector的coordInfoBlock.channel=0;" 所以你只有设置为相同的 channel 0才能成功这是对的。

    你画圈的的地方是同时支持多个channel 则选择其中最好的一个信道。可以直接赋值,你看扫描请求中的操作:
    memcpy(scanReq.scanChannels, defaultChannelMask,
    APIMAC_154G_CHANNEL_BITMAP_SIZ);
    同理。
  • 你好请问,我标题中的图片问题是什么原因。

    sensor用Falsh Programme 2清掉Falsh,然后重新烧入代码,关联成功,collectorAddr赋值。然后sendmsg给collector,sendmsg==true后poll,抓包信息ACK都正常,collector无回应,collector接收断点无法进入。如标题中的图所示。

    请问只是什么原因?发送地址collectorAddr在jdllcjoinedcb中赋值。
  • 我发现出现这种现状跟 sensor1,sensor2连接collector1,如果这个之后collector1重新烧入代码,sensor1和sensor2就出现了如图所示。

    collector1重新烧入,应该不会改动NV信息啊,sensor1和sensor2应该在NV中有记录才对。
  • 而且我在操作中collector 是没有重新烧入的。一直在运行中,sensor是入网操作,不去会用NV覆盖。入网操作,collectorAddr都是最新的。
  • 你重新烧录要看你的选项是否erase all ,此外你是自己手动associate,你不需要修改这个,自己会rejoin进去的。请勿修改该逻辑。
  • 你误解我的意思了。
    我没有修改他的逻辑。
    sensor启动网络的判断,是看nv是否有信息,有入网,否则 再入网。
    我的是直接进入rejoin,所以可以证明sensor的nv是清掉的。

    我所说的手动associate是有NV的情况下。

    但是我在测试中遇见的现象是,一个干净NV的sensor,去连接collector,会出现如标题中图所示。

    这种现象跟我把sensor加入到collectorA中,然后重新扫入collectorA代码,这个时候sensor发送抓包,也如图一致。
    我的烧入是先用Falsh programme 2清空了,在烧入的代码。
    我想明白这种情况是什么?
  • 你如果个设备都进行清掉NV就可以成功加入对吧。
    正常逻辑你不需要这样做,当你一个设备有NV 信息时会是去rejoin,没有则是请求正常入网,你现在应该是你退网没有调用Jdllc_sendDisassociationRequest。
    你在sensor 想要离开collector 需要使用 Jdllc_sendDisassociationRequest(void); 这样会清掉这个设备在collector的NV下次就可以加入了。
    你去试试,
  • 你的意思是:如果collector没有清掉NV,sensor清掉了。会出现我标题所示的抓包信息?

    我sensor在离开每个collector的时候都会 Jdllc_sendDisassociationRequest(void); 分离一次。

    我现在遇见的问题有二个。

    第一:sensor和collector通讯中,(多个通讯)某一方重启,sensor出现如标题所示。

    第二:45个sensor,依次启动入网(打开了一个立马启动下一个sensor),sensor会出现个别无法收到collector发送的数据。如何设置防碰撞。在mac_cfg里面设置有用吗?50个的理想设置参数是多少?
  • 建议你重新发个帖子,第二问题。
  • 第二个问题:e2echina.ti.com/.../173036

    第一个问题:我还没有解决,偶然现象。不常出现。一个干净NV的sensor,去连接collector(collector可能保存这个sensorNV信息,也可能没有保存,虽然我每次都发送了分离退出请求,但是不能排除),会出现如标题中图所示?
  • 如果你发出了Jdllc_sendDisassociationRequest 则会清除NV,重新加入就如一个新的设备,你这个问题我很难复现。
  • 如果出现sensorA连接collectorB,sensor入网了通讯正常。然后把sensorA,重新烧入代码。collectorB不修改。应该是可以复原标题抓包。

    看文档中的sensor/collector数据交互,还是有点不明白其中MAC细节操作,我只能判断出sensor的入网目标是对的,发送目标也是对的。
    我想是不是其中collector,有屏蔽某些特需的sensor功能。抓包中有ACK回复,是证明了collector的RF接收正常吧。但是RF没有回调MAC中函数(只要collector进入回调,collector都会串口输出,此现象无输出),RF中有其他特需处理吗?
  • 我测试一个快速复原此现象。
    一个sensor模块,二个collector模块。

    sensor去连接collector A,然后关闭collectorA,打开collectorB。(collectorA和collectorB,panid,信道,短地址设置一为相同)。
  • 'collectorA和collectorB,panid,信道,短地址设置一为相同“ 这个就做不到 Stack 会check for duplicate PAN ID。


    case Cllc_coordStates_scanEdCnf:

    if(!CONFIG_FH_ENABLE)
    {
    /* check for duplicate PAN ID */
    configureStartParam(coordInfoBlock.channel);



    如果无法解决,建议你要去修改入网过程。
  • 我知道collector中有个检查panid,重复函数。

    我把collectorA关机,collectorB还会检查到吗?

    我最大的疑问是:collectorA中如果没有sensor的NV信息。但是sensor的发送目标确实collectorA。这样会发现标题情况吗?
  • 请问你的sensor 都变为orphan 了又如何去发送呢?

  • 你所说orphan,是指collectorA和B交换时?

    在睡眠时期(sensor的每包间隔5分钟),我在一个周期内,置换collector。而且我们应用可能每个周期是24小时。

    一直不明白数据交互和NV信息有没有关系。我所才问,

    collectorA中如果没有sensor的NV信息。但是sensor的发送目标确实collectorA。这样会发现标题情况吗?
  • 1.如果你的collector 没有Sensor的设备信息(associate table )根本无法rejoin 进去,也就谈不上发数据。
    你设备睡眠了当他唤醒想发数据的成功的前提是他的collector还存在,否则会发送失败变为orphan 设备。

    ”在睡眠时期(sensor的每包间隔5分钟),我在一个周期内,置换collector“ 你新换的collector associate table 从哪里来?如果没有无法发送。
  • 我把你所说的这些我测试了。
    1:新换的collector 虽然panid和信道都复制一样,没有associate table 这张表,抓包信息如标题。(问题总结,sensor有目标collector信息,目标collector无associate table ,无法通讯?)
    2:新换的collector和旧collector,我都依次断电入网重连(sensor的NV是清除掉的,sensor发送数据可以判断,清掉为1,否则为2)。使二个collector 都具有associate table ,然后collectorA启动,sensor正常通讯,关掉collectorA,启动collectorB,还是入标题所示现象。(问题总结:在sensor和collector通讯中除了associate table,还有其他因素导致吗?)
  • 1.无法通信
    2.sensor NV清掉之后可以加入任意的collector,当你sensor 清除NV加入collectorB之后又会分配一个短地址,所以无法和原来的collectorA通信。懂了没?

  • 嗯,貌似是这样子。感谢,应该就是短地址不一致导致的。
    A和B分配不一样。谢谢,手动点赞.........
  • 你好,我还是这个问题,复原方式很麻烦,能否帮忙梳理下。


    (新设备)sensor去连接1,2,3,4,5,6,7个collector。(7个collector都具有一张collector表,表里面记录的数collector的panid和信道,短地址)
    假如,sensor连接到1,给sensor发送collector表,sensor变成孤节点或者重启,就会去根据collector表发送associate。

    sensor每次异常都会先发送退出网络,然后在根据collector表发送associate。

    我启动50个sensor,去连接collector。会有极少数sensor,出现标题图。


    问题:sensor如果重复的去入网不同collector(或者同一个collector入网多次),collector又没有收到退出网络请求,会出现标题现象吗? 大哥!!!!急
  • 这个应该不会这个原因导致的,理论上你只要正常退网,再加入其他网络,associate 成功就可以正常通信。
    我没有复现你的这个现象。建议发到E2E 英文看一下老外有什么想法没。
  • 假如:sensor连接collector(分配的地址是1),先发送退出,collector没有到接收到(没有清掉此sensorNV),然后sensor又发 send_associate request,成功。这个时候collector分配的地址是1还是其他?