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.

Send UDP Multi-Cast

Other Parts Discussed in Thread: CC3200

Hi all, I got Multicast Receive working thanks to this very helpful post combined with the advice on this unrelated forum post. In summary, it allowed me to add *this* code to the BsdUdpServer function in the udp_server example (after creation of the socket using sl_Socket):

    // multicast group
    SlSockIpMreq mReq;
    memset(&mReq, 0, sizeof(SlSockIpMreq));
    #define ADDR_MULTICAST_GROUP (0xE0000063) // 224.0.0.99
    mReq.imr_interface.s_addr = htonl(INADDR_ANY);
    mReq.imr_multiaddr.s_addr = htonl(ADDR_MULTICAST_GROUP);

    if (setsockopt(iSockID, SL_IPPROTO_IP, SL_IP_ADD_MEMBERSHIP, &mReq, sizeof(SlSockIpMreq)) == -1)
    {
        sl_Close(iSockID);
        ASSERT_ON_ERROR(UCP_SERVER_FAILED);
    }
    // end multicast group join

and test it from my Windows PC using the following iperf command:

iperf -c 224.0.0.99 -u -T 32 -t 3 -i 60
Now I'd like to have the CC3200 send UDP Multi-Cast to the same group address, but I've yet to figure out the secret sauce to doing that. First off, I can't figure out how to get iperf to bind to a multicast address as a server and I get an error when I use the syntax from the referenced post above:

C:\Users\Victor\Desktop\iperf>iperf -s -u -B 224.0.0.99 -i 1
bind failed: Cannot assign requested address

If anyone knows what's up with that, please share - the internet is not that forthcoming with an answer and/or my google-fu is weak. Anyway, having gotten stuck trying to get Windows to listen in, I figured I'd just use the CC3200 code that I already proved works as a listener as described above. I just ran the  same (slightly modified as described above) example code on a two CC3200s. On the first CC3200 I commanded it (via the Serial terminal) to listen on the UDP Multi-Cast group as before. On the second CC3200 I configured it in the terminal to use the UDP Multi-Cast group address as the Destination IP, and commanded it to do the "Send UDP packets" action.

Unfortunately, I did not receive any packets on the listening CC3200's Serial terminal. Both are using the same PORT define obviously, but I didn't add any code to the BsdUdpClient function whereas I did add the code as described above to the BsdUdpServer function. Do I have to add the same code to the BsdUdpClient to get UDP Multi-Cast Sending to work?

  • I think I've made a bit of progress at least in that I seem to have a Multicast Listener working in Windows using Python based on an answer in this Stack Exchange thread, copied here for posterity.

    import socket
    import struct
    
    MCAST_GRP = '224.0.0.99'
    MCAST_PORT = 5001
    
    sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)
    sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
    sock.bind(('', MCAST_PORT))
    mreq = struct.pack("4sl", socket.inet_aton(MCAST_GRP), socket.INADDR_ANY)
    
    sock.setsockopt(socket.IPPROTO_IP, socket.IP_ADD_MEMBERSHIP, mreq)
    
    while True:
      print (sock.recv(10240))

    This script outputs traffic sent from another Windows computer running the sister script:

    import socket
    
    MCAST_GRP = '224.0.0.99'
    MCAST_PORT = 5001
    
    sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)
    sock.setsockopt(socket.IPPROTO_IP, socket.IP_MULTICAST_TTL, 2)
    sock.sendto(bytes("robot", 'UTF-8'), (MCAST_GRP, MCAST_PORT))

    But it doesn't hear traffic from the CC3200 when I set it up to use Destination Address 224.0.0.99 and port 5001 and then "Send UDP Packets". So I'm thinking some code needs to be added to the BsdUdpClient function?

  • Hi Victor,

    We tried the same setup with 2 CC3200 devices and it works fine.

    I have used the same code that you have provided above.

    The 2 cc3200 devices are connected to the same AP, and one runs a multicast server and the other sends multicast packets to the group.

    I could also see these packets received on the PC that was on the same network. Can you please try to use wireshark to see if the packets are received on your PC?

    Multicast UDP client:

        //filling the UDP server socket address
        sAddr.sin_family = SL_AF_INET;
        sAddr.sin_port = sl_Htons((unsigned short)4444);
        sAddr.sin_addr.s_addr = sl_Htonl((unsigned int)0xE0000063);
    
        iAddrSize = sizeof(SlSockAddrIn_t);
    
        // creating a UDP socket
        iSockID = sl_Socket(SL_AF_INET,SL_SOCK_DGRAM, 0);
        if( iSockID < 0 )
        {
            // error
            ASSERT_ON_ERROR(UDP_CLIENT_FAILED);
        }
    
        // for a UDP connection connect is not required
        // sending 1000 packets to the UDP server
        while (lLoopCount < g_ulPacketCount)
        {
            // sending packet
            iStatus = sl_SendTo(iSockID, g_cBsdBuf, sTestBufLen, 0,
                                    (SlSockAddr_t *)&sAddr, iAddrSize);
            if( iStatus <= 0 )
            {
                // error
                sl_Close(iSockID);
                ASSERT_ON_ERROR(UDP_CLIENT_FAILED);
            }
            lLoopCount++;
        }
    
        UART_PRINT("Sent %u packets successfully\n\r",g_ulPacketCount);

    Regarding the windows application, please check if a firewall is blocking these packets.

    Regards,
    Raghavendra

  • |, first of all thanks very much for repeating my basic test on your end. Why did you set the port on the socket to 4444 (an irrelevant change I suspect)?

    Irrespective of that, I've continued to try and figure this out on my own, armed with the knowledge that it worked for you. I switched over from Windows to Ubuntu to eliminate that O/S question. That actually yielded some new information. I finally was able to receive packets concurrently on both my python script and the CC3200 terminal sometimes. Basically I played with the packet burst length on send, settling qualitatively on 5 packets per send for an experiment. I got some results that I'm don't have a good handle on how to interpret, so I'm bringing them back here for your consideration. I'm worried a bit now that I may actually be dealing with an RF hardware problem. Here's a description of my experiment:

    • Laptop running Reciever Python Script, CC3200 sender, CC3200 receiver on the same desktop space (within two feet of each other).
    • CC3200 Sender and Receiver both running the UDP Server Example (modified as above for multicast), and sender configured to send 5 packets at a time, receiver configured to receive 1000 packets and print packet counter on each packet received.
    • I sent from the CC3200 sender (via 1 <enter> <enter>), recorded the last packet counter printed in a spreadsheet from both the python script and the cc3200 receiver (both listening at the same time). I performed this process 100 times manually and the spreadsheet is attached.

    The summary of my 100 trials is:

    • 41 times both the python script and the cc3200 receiver got all 5 sent packets
    • 28 times the CC3200 receiver got more packets than the python script
    • 16 times the Python script got more packets than the CC3200 receiver
    • 15 times the CC3200 receiver and the Python script tied with fewer than 5 packets received
    • Overall the CC3200 receiver got 400/500 packets, and the Python script got 361/500 packets

    I'm going to repeat the test with the CC3200 sender farther away from the laptop and CC3200 receiver this afternoon to see if the results look any different. I guess the main reason I'm worried that this is actually an RF issue is that I didn't expect the CC3200 receiver to outperform on packets received the laptop running a Python script. Another test I would like to run is using a laptop as the sending source and collecting data.

    PacketBursts_005_PacketsPer.xlsx

  • Victor, Would you be needing any help from TI on this? If not, I'd want to close this thread.

    -/Praneet
  • I'm all set thanks, you can close it.