CC1310: TI 15.4 FH mode problems

In addition: I found that sometimes my collector got the MAC_MLME_ASSOCIATE_IND event and processed assocIndCb success and send Send response back to the sensor, but the sensor still got MAC_MLME_ASSOCIATE_CNF with status = 0xE9(ApiMac_status_noAck). I think may be there is a clock issus here, and some timing seting is not correct, but which one? I tried a lot but nothing changed.

Anybody here?

Am I the last one in the world?

Who can heal those tiny broken hearts.....I dry my eyes again.....

TopCat
Siri
Richard W.
FredG
Sverre
I am sorry but can you help me?

Hi, the TI-15.4 stack is supported by some other resources in this forum, and not so much by the resources you added to this thread.
I have notified a resource about your issues.
Ping me again if you don't have a reply soon.

Thank you FredG. But still no one reply me except me and I have been stuck in such problems for sevral weeks...

Hey Summery,

To answer your questions:

1). An ack is not required for a transmission to be considered a success. See ApiMac_txOptions_t structure for a list of options that can be set when sending a data request. On of these fields is an ack field, and when set true, an ack is required to confirm the transmission.

2). This sounds like the real issue as to why your network isn't performing correctly. What modifications have been made to the collector code? And I assume you are using he embedded collector application?

3). FHing takes longer to join and rejoin the network, but 5 mins seems a little bit long. Can you post your config.h? Sometimes if the channel mask is too big, it can lead to long joining times.

~Brocklobsta

Hi Brocklobsta:

I am so glad to see your reply and thank you a lot.

I have installed simplelink_cc13x0_sdk_1_00_00_13 and use the ti 15.4 stack example ran on two SmartRF06 evaluation boards, one as collector and the other one as sensor.
Follow is What I chenged:
1. Delete the launchpad files and instead add the smartrf06 board files (cause I have no launchpad), and changed the compile parameters, such as predefined symbols,add “CC1310EM_7XD_7793", and delete " CC13XX_LANCHXL" .
2. undefined FEATURE_ALL_MODES and defineed FEATURE_FREQ_HOP_MODE and enable CONFIG_FH_ENABLE (cause I just want to use frequency hopping), ;
3. Change the value of CONFIG_REPORTING_INTERVAL from 90000 to 500 (cause I want the sensor transmit rate is 2 packets per seconds);
     Change the value of CONFIG_POLLING_INTERVAL from 6000 to 400;
4. Change the value CONFIG_RX_ON_IDLE from false to true(cause in my application the node should be a non sleepy device).

Attached is the config.h file in collector application.

2727.config.h

Very appreciate for your help.

After I changed the txOptions.ack to false, and the sensor actually did't judge the transmission failed and did't always reassocate the network again and again, so the problem appears more clear: all those issuses cames from that the collector cannot receive the data at the sensor's reporting interval but just can receive partial of them at a non-fix interval. Follow is the debug information that record the collector's receiving situation: (ps: The sensor send 120bytes the same value from 1 to 120 per second, I just printf one of the data the collector received)
recv: 1
recv: 6
recv: 20
recv: 25
recv: 27
recv: 28
recv: 33
recv: 48
recv: 63
recv: 64
recv: 80
recv: 93
recv: 94
recv: 116
recv: 2
recv: 11
recv: 17
.......
It seems that the collector doesn't in a "good mood" to take notice of the data that sensor transmit.I want to know how to control the collector to "keep in a good mood" to receive all the data without loss.
These two files attached are the config.h for collector and sensor.

5153.config.h5153.config.h
Appriciate for your reply.

Is there any parameters that can influence how ofen the colletcor receive a data??
Kumaran Vijayasankar
FredG
TopCat
Richard W.
Sverre

Hi Summery,

  Can you kindly check the FH_NUM_NON_SLEEPY_NEIGHBORS paramter  on the collector side? Can you make sure that it is atleast 1 and not 0.

 By default it would be 50 (sleepy) and (0) non sleepy.

 Since you are using a non sleepy neighbor, it is required to change it to 49,1 (or) 48, 2 

Best regards,

Kumaran

Yes， the FH_NUM_NON_SLEEPY_NEIGHBORS   is  2 and the FH_NUM_SLEEPY_NEIGHBORS is 10 in collector side(Since it just says these two value "must be less than 50" and does not say the total value should be 50, and I want to decrease the memory size, so...)    and my collector's config.h also attached above.May be I should to attach these two config.h again:

Collector's config.h:

2804.config.h

Sensor's config.h:

2804.config.h

Hi Summery,

 Looks like both those config files are identical and seem to be that for the sensor. I was looking for the one for collector which would have fields like "CONFIG_COORD_SHORT_ADDR".

Also regarding the total number of nodes, it can be less than 50 to save memory, so the configurations you had mentioned is right.

Can I request you to kindly run the test with the default parameters the following changes alone first:

* No of non sleepy neighbors on collector increase to 2

* No of sleepy neighbors on sensor = 2 (or any other value such that total < 50)

* RX_ON_IDLE on sensor = true (to make it non sleep)

* CONFIG_FH_ENABLE  = true on both sides

* Modify features.h as you had mentioned

Please run with default poll interval and sensor interval and let us know if this works for you.

If this also does not work for you, the only change I can see is the use of smart RF board instead of launchpad and we may have to look into the changes you had made for that.

Best regards,

Kumaran

Hi Kumaran:

Thank you for your reply. I did what you mentioned and the collector still can received partial of the data and lost some of them.

I don't know why I attached wrong config.h files for two times( all of them are sensor's config.h), now I just attach collecotor's config.h file:

3480.config.h

Hey Summery,

I can reproduce this issue! I will start looking into the root cause. Sorry for the delay in pin pointing this issue

~Brocklobsta

I am glad to hear that this issue can be paid more attention by offical staff, and it also means my struggling days spending on this issue will end soon. Waiting for your reply about the final outcome. Thank you Brocklobsta!

Hi Brocklobsta:
I am sorry but how is the progress? Is the root cause for this issue has been found? I am really axious about the result casue I have spent so much time on this issues. Thank you.

Hey Summery, Can you disable CONFIG_DOUBLE_TRICKLE_TIMER and test your network again?

Yes!!!!!It works! But what's wrong with "CONFIG_DOUBLE_TRICKLE_TIMER "?Since it says:

/*!

To enable Doubling of PA/PC trickle time,

useful when network has non sleepy nodes and

there is a requirement to use PA/PC to convey updated

PAN information

*/

And I just test the non sleepy mode, why?