CCS/CC1310: Frequency hopping: Are all fixed unicast channels of sleeping sensors the same?

Hey Chris,

I think I was not clear enough. I know about the connection procedure and how the sensor follows the channel sequence of the collector. However, during polling the sensor transmits on the current channel of the collector, let's say channel 1. As far as I understood the concept, the collector will acknowledge on channel 1, however, the collector will then prepare the config request message and send this message on the sensors fixed unicast channel, which let us assume, is channel 22. Now, if all sensors would have the same fixed unicast channel and there would be more than one sensor requesting a config by polling within 20s, the collector would send all config requests on channel 22 and thus violate FCC regulations.

Besides, I just noticed that the MAX_DATA_RETRY has to be set to 0 on the collector side or the same regulation will be violated easily for frames in simple long range mode.

Please correct me if I am wrong.

Hey Ammar,

thank you for your answer.

I have already checked this function but to be honest I did not really understand the logic behind it. The function is called 3 times.

1. During initialization

2. Before PAS transmission

3. Before PCS transmission

It looks like that a different channel is set every time the function is called. But I think there is no randomization thus after sending the PCS frame it is the same for all sleepy sensors?!

best wishes

slev1n

Slev1n,

There isn't any randomization for sleepy sensors from what I see. The getFHSleepNodeHopChannel() function uses the sleepNodeChIdx to track the current channel in FH sleep node hop sequence. This is set in that function and iterated through based on the channel mask.

Non-sleepy sensors use the DH1CHF hopping framework based on the channel mask and is randomized.

Hey Ammar,

sorry for my late reply on that.

Ammar N said:

There isn't any randomization for sleepy sensors from what I see.

Ok, that is what I got from the code, too. Do you share my worries, regarding my concerns posted in my first thread, that if all sleepy sensors are on one channel, the collector could easily exceed the allowed 400ms transmission time per channel per 20s if several sensors are getting polled for example.

I guess I have to disallow the collector to perform a config of the sensor within 20s or do you have a better idea?

Btw, on what channel are the different association steps performed? I mean which of the messages is send on the collectors and which on the fixed sensor channel?

best wishes

Slev1n

Hey Slev1n,

Not sure if you've had a chance to see this: https://www.ti.com/lit/an/swra529a/swra529a.pdf?ts=1590597170576.

In general, I think it would be best to stagger the join times rather than have all the sensors try and join together.

The association request is sent on the collector's target channel, and the response is sent on the end node's fixed channel. (I refer back to the User's guide http://dev.ti.com/tirex/content/simplelink_cc13x2_26x2_sdk_3_40_00_02/docs/ti154stack/html/ti154stack/frequency-hopping-mode.html#fig-fh-sleepy-join)

Hope this helps.

Hey Ammar,

thank you for your information.

Ammar N said:

In general, I think it would be best to stagger the join times rather than have all the sensors try and join together.

This is not possible. In the later application, the sensors are already running and will be brought into place while already running and scanning for a network. When the collector is installed they will join eventually and we have no influence on when a sensor is sending his async message.

Quick question. When sensor 1 transmits its PAS and sensor 2 starts transmitting its PAS 5s later and the collector receives both. Will the collector send one PA or a second PA on all channels 5s after the first async message bundle has been sent?

Ammar N said:

The association request is sent on the collector's target channel, and the response is sent on the end node's fixed channel.

I noticed, that the fixed channel is always the first channel of the frequency mask. Therefore, I have set up a sniffer to that channel. However, I do not get messages during association neither during polling/config of sensor (which I do when sensor and collector only have 1 active channel in their channel mask). Could you confirm, that there are transmissions on the sensors fixed unicast channel when having 50+ channels set in the channel mask?

Ammar N said:

Not sure if you've had a chance to see this: www.ti.com/.../swra529a.pdf

I havent seen that before, no idea why google didnt drop it although the headline were exact terms I used for search. Equation 1 seems not to be right (n k) is a vector and not a fraction. However, the documents describes how to design the application. But there are several scenarios, which could (not very likely) cause a higher occupation than allowed. With 5kbps only 250 bytes can be transferred within 20s on one channel. Imagine a collector sends an async message like a PC which has 163 bytes and is send on every channel. 87 bytes are left and a simple Ack of a data frame already has 102 bytes. In a network with 2 sensors, this can easily happen. One sensor wants to join the network while the other is transmitting a data message. So I wonder if such singularities, which do not happen often, are an issue. In the document there is written "an average" of 400ms. Does this mean, that if this limit is violated once every 1000h the issue can be ignored?

If it cant be ignored, than either LRM is not possible for FH or TI should implement a function in the stack simply forbidding the device to violate that FCC directive. Any comment on that?

PS: Are the fixed unicast channels of the sensors stored somewhere on the collector and I can access to check what channel is set? Or can I see somewhere on which channel a certain message is transmitted?

best wishes

Slev1n

Hey Slev1n,

I believe a second PA will be sent by the collector if sensor 2 sends a PAS 5s later, as the collector would view it as a separate event.

A sleepy sensor will follow the collector's hopping pattern, perhaps we're looking on the wrong channel here.

In terms of the FCC compliance, I would verify that the collector is sending the 5 PA's to its sensors. I'm unsure if the stack handles this compliance in FH mode but will try to find out for you.

For sleepy sensors, you can see the main code in jdllc. Below is how we set the unicast channel for a sleepy sensor:

ApiMac_mlmeSetFhReqUint16(ApiMac_FHAttribute_unicastFixedChannel,
                                      (uint16_t) getFHSleepNodeHopChannel());

You can also use the similar Get function before sending a message to narrow down what channel is set before sending a message.

Ammar N said:

A sleepy sensor will follow the collector's hopping pattern, perhaps we're looking on the wrong channel here.

Well, could you check on your side if you set only a certain amount of channels (e.g. Channel 12 to channel 112) on the sensors frequency mask what the fixed channel will be on the sensors' side?

Besides, since every communication is initiated by the sensor which is sending the first message (e.g. data, poll request, association request) I assume, that the collector is never sending on the sleepy sensors fixed channel. it is always the sensor starting on the collectors current channel and if the collector preceeds to the next channel in its list, the sensor just follows no matter if the sensors next action is Tx or Rx. Just an assumption, because there is no message visible in the sniffer which is set to the sensors fixed channel.

Best wishes

Slev1n

Slev1n,

Glad you got this figured out! I see now in getFHSleepNodeHopChannel() that the logic in this function matches your description.