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.

CC1312R: UDP vs TCP

Part Number: CC1312R

Hi Team, 

Can you please check and advise following request;

"

1-  TI example “6lowpan_mesh_ti_15_4_cc1312_tirtos_ccs” uses UDP not TCP please confirm?

2- Can I use the TCP instead of UDP? If it is possible, which components need to be modified?

3- Is there any reason for you using UDP instead of TCP in this example?

4- Where can I find the “path cost” from coordinator to the end node in this project?

"

Thanks in advance

Best Regards

Furkan Sefiloglu

  • Hi Furkan,

    1. Yes, this example uses UDP.

    2. You can use TCP instead of UDP. This software was developed using Contiki stack. I would recommend to check at the Contiki community to see if there is any examples of TCP.

    3. UDP is more suited for low power and lossy network. TCP requires more overhead and reliable connection which is not a typical use case for realistic networks. However, for a lower number of devices in a stable environment, TCP can be used but at the cost of higher memory.

    4. Do you mean time taken from end node to concentrator?

    With Regards,

  • Hi Prasanna,

    Please see feedback below:

    "

    About the questions

    1. Do you mean time taken from end node to concentrator?

    No, I mean the total cost between them that determines which is the best path from node to its root coordinator.

     

    Further question

    Can I send data packets from a node to other node in the same network without the need to go through the root coordinator?

    In other words, as a node why should I go to the root coordinator then return data back to other node if I and the other node have the same parent?

    "

    Thanks in advance

    Furkan

  • Hi Furkan,

    Best path taken to go from node to root is decided based on the trickle algorithm (RFC6206).

    https://tools.ietf.org/html/rfc6206

    Yes, it is possible send the packets between adjacent nodes without going through the root. It mainly depends on the path it has to take to communicate. 

    With Regards,

  • Hi Team, 

    Can you please check and advise with following request?

    "

    as we mentioned before we built our project on “TI stack 15.4” and developed our application based on “6lowpan_mesh_ti_15_4_cc1312_tirtos_ccs” TI example.

     

    I have put a print log in “dataIndCB” function (callback called from MAC layer when receiving any packet) in “middleware.c” software module.

     

    I saw that there are a frequent packets that are sent from node to coordinator and I do know what is the content and source of these

    Packets.

    Samples of these packet in hex format:

    1. data <7A333A9B0297821E0000F10512018020010DB81234FFFF02124B0021B104D806140000007820010DB81234FFFF02124B002293AED0>, rssi (-51), src IP <D804B121004B1200>, dst IP <D0AE9322004B1200><LF>
    2. data <7A3B3A1A9B014BD91EF0038010F1000020010DB81234FFFF02124B002293AED0040E00040D0A07000100000100780005081E406000000000000000000000000020010DB81234FFFF02124B0021B104D8>, rssi (-54), src IP <D804B121004B1200>, dst IP <0000000000000000><LF>

     

    The problem is when there are a large number of nodes (roots)(more than 50) these frames are sent to coordinator with high frequency

    and I see that The MAC layer fails to respond with transmit confirmation callback “dataCnfCB” to “middleware.c” means that the middleware timeouts on transmit with “processDataTxTimeout” many times and then try to send the next packet if exists.

     

    Q1) what are the cases that MAC does not respond with transmit confirmation?

    Q2) If there is any documents describes (content and source) the above frames, could you please provide it?

    "

    Thanks in advance

    Best Regards

    Furkan Sefiloglu