• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 56 subscribers
  • Views 2511 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.

Questions regarding frequency hopping using the TI 15.4 stack

Savinda Gunawardena
Intellectual 965 points
Other Parts Discussed in Thread: SIMPLELINK-CC13X0-SDK

Hi,

It appears that switching to frequency hopping using the TI 15.4 stack is quite easy- changing the CONFIG_FH_ENABLE setting seems to do the trick. I can't really think of a good way of confirming that the sensor and collector launchpads are indeed actually using frequency hopping, since the LCDs are broken, but the LEDs start blinking after about a 30 second delay, which seems promising. :

I am unfortunately having quite a bit of trouble actually understanding the developer's guide (have been reading this and other documents for the better part of two days), and would very much appreciate some assistance. Right now I've got three questions

1.) When trying to use a network of sleepy devices, pg 59 of the developer's guide states that "the channel hopping function for a sleepy device must be set to Fixed, and the fixed channel can be set to any desired channel." If this is the case, though, wouldn't the sleepy device NOT actually be using frequency hopping, since the channel is apparently fixed? Furthermore, page 67 shows that if ApiMac_FHAttribute_broadcastChannelFunction  is set to 0, it would not actually be hopping. 

2.) What is the difference between unicast and broadcast hopping? My understanding is that unicast is used for sensors to communicate with each other, and the sensors communicate with the controller using broadcast hopping- is this accurate? 

3) Does the out-of-the box sensor/ collector example project use unicast hopping or is it only using broadcast hopping?

I'm very sorry about the wall-of-text; I'm just a little overwhelmed by all this information, and would really, really love some insight! 

  • 0
    TI__Expert 4375 points

    Hey Savinda,

    It is more difficult to confirm frequency hopping OTA because it would require multiple sniffers, but you could also debug the low level MAC commands to see if they are being issued on different channels. To answer your questions:

    1. The way a device, sleepy or not, sends a message in frequency hopping mode is by sending the message on the channel of the receiver node. What this means is that if the collector is set to hop, ApiMac_FHAttribute_unicastChannelFunction or ApiMac_FHAttribute_broadcastChannelFunction being set to '2' which is default, will hop based on its DH1CF sequence. A sleepy node set to fixed channel mode wanting to talk to the collector will switch to the channel the collector is currently on to send a message. The sleepy device will remain on its fixed channel otherwise.
    2. Broadcast hopping sets a time, the dwell interval, that all nodes are listening to the collector for a message, while unicast hopping each node has an independent sequence which allows for direct messaging.
    3. Out of box The broadcast interval is set to 0 meaning only unicast hopping is used.

  • 0
    TI__Prodigy 160 points

    Hi,

     First of all, Thank you for evaluating our FH solution and for providing your feedback and questions.

     To answer your questions:

    1. For sleepy devices, the initial channel can be set to any channel by setting the fixed channel. The sleepy device shall stay on this channel until it associates with a "Channel hopping" collector. .The initial channel can be changed if the all join attempts fail (which may be caused due to interference on that channel) and a fresh attempt can be made. After that any data exchange will use channel hopping. In 2.0 release, the application would be required to change the channel before initiating a poll request. In 2.0.1 release, the stack will automatically take care of changing the channel, while the application has to just set the initial channel.

    2.  Broadcast Feature is only supported for Non-sleepy devices. You can use this feature to send broadcast frames to all nodes in the network. We did get some feedback stating that this was not clearly expressed int the developer's guide and hence, this has been explicitly mentioned in 2.0.1 developers guide.

    3.  Out of the box version uses both unicast and broadcast hopping. The broadcast feature can be tested out by making some non sleepy devices (MAC_RX_ON_IDLE set to TRUE) join the network and then using the Collector to initiate the broadcast transfers.

    Best regards,

    Kumaran

  • 0 in reply to Kumaran Vijayasankar
    Intellectual 965 points
    Hi, thank you very much for your detailed replies Brocklobsta and Kumaran. Is the 2.0.1 developer's guide still being written (would like to download it)? Unfortunately I'm still confused about a few points.

    1)Both the unicast and broadcast dwell intervals appear to be set to 250 through the CONFIG_DWELL_TIME define in the collector and sensor config.h files. From what Kumaran says, only the collector is using broadcast hopping, and the sensors all use unicast hopping. When you say that the "out of the box version uses both unicast AND broadcast hopping" do you mean that the collector uses ONLY broadcast hopping and the sensors use ONLY unicast hopping?

    2) If multiple sleepy sensors only communicate with the collector, my current understanding is that a sleepy sensor would wake up and try to transmit on whatever fixed channel that it's been set at regardless of what channel the collector is broadcasting in- if the collector channel happens to change to the fixed channel of the sensor, and at that moment the sensor is actually "awake" and trying to transmit, ONLY THEN would the sensor be able to communicate with the collector. Is this correct?

    3) What will happen if the sleepy sensor set at a dwell time of 250ms is trying to transmit a packet that is too large to be transmitted within 250ms? If a sleepy sensor can only unicast how does it know what channel the frequency hopping collector is currently broadcasting in?
  • 0 in reply to Savinda Gunawardena
    TI__Prodigy 160 points

    Hi,

    Let me first try to clarify, the hopping and "channel of data exchange".

    As shown in Figure 4-22 of the Developer's Guide:

    1. The transmitter of a data shall first determine the channel at which the receiver is currently listenining on (It does not have any relation to what channel the transmitter is listening on (fixed/hopping))

    2. It shall then transmit the frame on the receiver's channel (on whatever channel it is on that time)

    3. The tx and rx shall continue to stay on that channel till the entire frame is exchanged (Limit of 250 ms does not apply to packet transmission time)

    Broadcast Hopping (Figure 4-17):

    1. Collector shall hop to "Broadcast channel" and stays in that channel for "Broadcast Dwell Time (250 ms)" every broadcast interval (Default - 4.25 s)

    2. A "Non Sleepy Device - (MAC_RX_ON_IDLE set to TRUE) shall be capable of following this schedule while a sleepy device will not

    3. This allows for exchange of broadcast frames between collector and "non-sleepy (always on)" devices

    Exchange of channel hopping and timing information at network start is explained in section 4.3.2.3 (The Async frames are used to exchange this information at start)

    With this background, let me answer your questions below:

    1. Unicast and Broadcast hopping both occur at collector and "non-sleepy" devices. Unicast hopping is done whenever there is a gap in broadcast hopping (from end of broadcast dwell time to broadcast interval period)

    2. Sleepy devices shall transmit on "whatever channel" collector is listening on. Collector will transmit to sensor on the fixed channel on which the sensor is listening. 

    3.  Packet transmission can exceed slot boundaries as mentioned earlier. Sleepy device shall track both unicast and broadcast hopping of collector (it shall not go to broadcast channel every time but shall know the channel at which the collector is listening on).

    Best regards,

    Kumaran

  • 0 in reply to Kumaran Vijayasankar
    TI__Genius 10650 points
    The TI 15.4-Stack-2.0.1 is released as part of the SimpleLink CC13x0 SDK, which combines TI-RTOS, TI 15.4-Stack-2.0.1, and Proprietary-RF examples in one package. You can download the new TI 15.4-Stack from www.ti.com/tool/SIMPLELINK-CC13X0-SDK.
    After installing you can find the new TI 15.4-Stack-2.0.1 developers guide and other documentation at C:\ti\simplelink_cc13x0_sdk_1_00_00_13\docs\ti154stack\. (Please note you will need to use CCSv7 for your application development)
  • 0 in reply to Kumaran Vijayasankar
    Intellectual 965 points
    Thank you for this detailed reply Kumaran. Does this mean that I'll have to find a way to ensure that a sleepy sensor wouldn't transmit data on one fixed channel for too long (to make sure that it doesn't occupy one frequency for over 400ms as per the FCC regulations) by making changes to the sensor application project? Also am I correct in understanding that a network with sleepy sensors and one collector would never use unicast hopping?
  • 0 in reply to Suyash Jain
    Intellectual 965 points
    It looks like it uses up less space than the old 15.4 stack, which is great, and not having to program the stack image separately is nice! Will compiling the new projects on the CCS v7 release candidates yield problems though, since apparently it'll be the 12th of December before CCS v7 is actually released?
  • 0 in reply to Savinda Gunawardena
    TI__Genius 10650 points
    Release Candidate is very close to the final release planned for the Dec 12th you shouldnt see issues, you can start your development on the release candidate and it will be very easy to just move to the final release version getting released within 2 weeks for your product release.