• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 55 subscribers
  • Views 1056 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

CCS/LAUNCHXL-CC1310: Frequency hopping: Activation of RX_on_when_idle before async message was send

CCS/LAUNCHXL-CC1310: Frequency hopping: Understanding dwell time and channel hopping behavior

Slev1n
Genius 5680 points

Part Number: LAUNCHXL-CC1310
Other Parts Discussed in Thread: CC1310

Tool/software: Code Composer Studio

I have splitted my last thread to make the question easier searchable for others. Original https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz/f/156/t/892536

Using CC1310 newest SDK for Sensor and CC1352R1 3.3 SDK for collector:

Here some questions we are asking ourselves:

1. Should the dwell time be the same on collector and sensor?

2. Assuming a dwell time of 250ms and the 5kbps transmission rate. How is it possible, that a 300byte message (takes 480ms) can be successfully transmitted from sensor to collector? (it looks like it can)

3. When a sensor transmits a message to the collector, on which channel is the ack returned? On the same channel or the sensors hopping sequence channel?

4. Will the transmitter change the channel according to the receivers hopping list also during data retries?

5. What happens if e.g. the reporting interval expires and when the sensor wants to send the message it notices that 200ms of the 250ms dwell time of the collectors current channel has already past, will the MAC wait until the collector hops on the next channel or just try to transmit?

6. Since our devices are all sleepy, unicast messages will be transmitted to the sensor on a fixed channel (according to the user guide) is this channel randomly chosen from the channel mask or is it the same for all sensors?

7. Our sensors send each hour, however, if a transmission fails, it will try a few minutes later again. Since the sensor knows the hopping sequence of the collector, the collector should be able to receive this message, right?

best wishes

Slev1n

  • 0
    TI__Mastermind 25810 points

    Hey Slev1n,

    I found a few posts that provides insight on some questions.Here they are for reference: 

    Slev1n said:
    1. Should the dwell time be the same on collector and sensor?

    No, they don't have to be the same. The dwell time is how long the device stays on a particular channel.

    Slev1n said:

    2. Assuming a dwell time of 250ms and the 5kbps transmission rate. How is it possible, that a 300byte message (takes 480ms) can be successfully transmitted from sensor to collector? (it looks like it can)

    3. When a sensor transmits a message to the collector, on which channel is the ack returned? On the same channel or the sensors hopping sequence channel?

    If this is the case, the device will stay on the channel and finish the transmission of the packet. Once it's complete (and an ack is received if applicable), it will resume hopping on the other channels. The stack should calculate the sequence for you and resume on the proper channel. The ack is returned on the same channel the original message was transmitted on.

    Slev1n said:
    4. Will the transmitter change the channel according to the receivers hopping list also during data retries?

    Yes

    Slev1n said:
    5. What happens if e.g. the reporting interval expires and when the sensor wants to send the message it notices that 200ms of the 250ms dwell time of the collectors current channel has already past, will the MAC wait until the collector hops on the next channel or just try to transmit?

    If there is still time left on the channel and the transmission is queued, the MAC will stay on that channel until the transmission is complete.

    Slev1n said:
    6. Since our devices are all sleepy, unicast messages will be transmitted to the sensor on a fixed channel (according to the user guide) is this channel randomly chosen from the channel mask or is it the same for all sensors?

    I would say it's "randomly" chosen and not the same for all the sensors. What I mean by "randomly" is that the channel the message is transmitted on depends on the timing it is sent and the hopping sequence of that sensor which is tracked by the collector. I.e., whichever channel the sensor is on, the collector should send the message to that channel. I believe it should be unique per device, depending on your settings.

    Slev1n said:
    7. Our sensors send each hour, however, if a transmission fails, it will try a few minutes later again. Since the sensor knows the hopping sequence of the collector, the collector should be able to receive this message, right?

    Correct

  • 0 in reply to Ammar N
    Genius 5680 points

    Thank you very much Ammar, you shed a lot of light onto this matter.

    Ammar N said:
    Slev1n

    2. Assuming a dwell time of 250ms and the 5kbps transmission rate. How is it possible, that a 300byte message (takes 480ms) can be successfully transmitted from sensor to collector? (it looks like it can)

    3. When a sensor transmits a message to the collector, on which channel is the ack returned? On the same channel or the sensors hopping sequence channel?

    If this is the case, the device will stay on the channel and finish the transmission of the packet. Once it's complete (and an ack is received if applicable), it will resume hopping on the other channels. The stack should calculate the sequence for you and resume on the proper channel. The ack is returned on the same channel the original message was transmitted on.

    Transmitting longer than 400ms on a channel within 20s violates FCC 15.247. Hence, I have to watch out myself not to send too long messages, right? (remember, we us LongRangeMode with 5kbps)

    Ammar N said:
    Slev1n
    5. What happens if e.g. the reporting interval expires and when the sensor wants to send the message it notices that 200ms of the 250ms dwell time of the collectors current channel has already past, will the MAC wait until the collector hops on the next channel or just try to transmit?

    If there is still time left on the channel and the transmission is queued, the MAC will stay on that channel until the transmission is complete.

    One follow up question onto that. Let's assume, that the collector has a 250ms dwell time on channel 100 and the sensor starts to transmit a message to the collector though 150ms of this 250ms dwell time has already past. The transmission + ack takes 200ms. When finished the collector hops his RX on the next channel in the list, e.g. channel 101. Will the collector now stay there only for 150ms, because if it would stay there longer, the whole hopping sequence would be messed up, right?

    Ammar N said:
    Slev1n
    6. Since our devices are all sleepy, unicast messages will be transmitted to the sensor on a fixed channel (according to the user guide) is this channel randomly chosen from the channel mask or is it the same for all sensors?

    I would say it's "randomly" chosen and not the same for all the sensors. What I mean by "randomly" is that the channel the message is transmitted on depends on the timing it is sent and the hopping sequence of that sensor which is tracked by the collector. I.e., whichever channel the sensor is on, the collector should send the message to that channel. I believe it should be unique per device, depending on your settings.

    The sensors are sleepy, so for transmission, they follow the collector and receive the ack on the same channel. However, if a message (config request) is send from collector to sensor, aren't the sensors on a fixed channel? Maybe I still got it wrong.

    One further question I forgot to ask:

    This is how the dwell time is set in the stack: ApiMac_mlmeSetFhReqUint8(ApiMac_FHAttribute_unicastDwellInterval, CONFIG_DWELL_TIME); Can I just change it to ApiMac_mlmeSetFhReqUint16 and set a higher dwell time?

    EDIT: I think I can now answer this question myself. First, the maximum dwell time is 250ms (found it somewhere in the documents). Second, dwell time is rather irrelevant for sleeping sensor nodes. Sleeping sensors dont hop themselves. If they have to transmit a message to the collector, they transmit on the collectors current channel. If a collector communicates with a sensor (not broadcast msg), the collector transmitts on the sensors unicast fixed channel.

    Best wishes

    Slev1n

  • 0 in reply to Slev1n
    TI__Mastermind 25810 points

    With a quick test (setting the collector to hop on 2 channels), I set the broadcast frame to 300+ bytes (should take ~0.5s to transmit) to see if the data would be fragmented into two different TX's split apart. I did not observe the stack handling this behavior. I've reached out to the dev team regarding this to confirm what I'm seeing. If this is the case, then yes, for FCC purposes you should send smaller packets to avoid violating the 0.4s requirement.

    In terms of the hopping on the collector, you understand correctly. The device will continue its hopping sequence, and will entirely skip over channels (assuming this were the case) to maintain the sequence.

    Slev1n said:
    The sensors are sleepy, so for transmission, they follow the collector and receive the ack on the same channel. However, if a message (config request) is send from collector to sensor, aren't the sensors on a fixed channel? Maybe I still got it wrong.

    Yes, for sleepy sensors this is the case. Thanks for clarifying.

  • 0 in reply to Ammar N
    Genius 5680 points

    Thanks for your help.

    Would be interesting if stack could handle this by itsself.

    Well, looks like the only question remains in the thread with the transmission/acknowledge performance.