CC3100MODBOOST: Unable to receive transmissions from other MODBOOST in transceiver mode

Hi Patrick,

Is there a specific reason you are looking at transceiver mode? Also, how many times do you transmit in your test case?

In general, sending a packet in transceiver mode is inherently not a "reliable" transmission. There is no official connection between the devices and no guarantee that when the packet is sent, it will be received by the other side. Your receiver is configured to pick up any data transmissions that it sees on channel 3, which is why your application reads out other "unrelated" data.

To try to make this a little cleaner, you could use the internal RX filters so the device drops packets that do not fit the specific data you are trying to receive from your other device. See chapter 15 of the CC3100/CC3200 network processor user guide:

http://www.ti.com/lit/swru368

Otherwise, I recommend using a connection oriented approach with reliable transport (TCP).

Best Regards,

Ben M

Hi Ben!  Yes, actually the transceiver mode is necessary for my application and it is understood that it is not "reliable."

I transmit the same command (with a different sequence number) every two seconds but I'm not seeing _any_ of the transmissions.  Either the data is being excluded internal to the CC3100 on the receiving side or it's not actually being transmitted on the sending side.

Is there any chance that there are default RX filters enabled that I need to disable to get my data to come through?  If not, what would be the next thing to check?

Switching to a normal socket with STA or AP mode is not an option for my application.  This part was chosen specifically because transceiver mode was available.

Hi, what's the next best step for diagnosing this issue?

Hi Patrick,

How often are you reading data on the receiver side? What happens when you increase the frequency of the transmission (perhaps every 100ms)?

Thanks,

Ben M

The recv() is blocking and the data that does come in (from elsewhere) comes in sporadically.  I just counted 5 RX in a minute (not the data I'm sending from the other board.)

When I increase the TX from board 2 to every 100ms, there is not difference at all.  None of these TX appear to be received on board 1.

Related question:  I set the TX power on the socket option to a value of 1.  I understand this is the maximum, is that correct?  Just want to be sure that I'm not causing the boards to whisper.

#define RAW_POWER                    (1)
u32Value = RAW_POWER;
setsockopt(eSocket, SL_SOL_PHY_OPT, SL_SO_PHY_TX_POWER, &u32Value, sizeof(u32Value));

Hi Patrick,

5 RX events per minute seems very low even for channel 3. Testing in my office, I see data constantly as expected. Most of it is unwanted data, but when I turn my transmitter on and just send in a loop with CCA bypass my packets start dominating. I have a very small delay between calls to sl_Recv so I don't overwhelm my terminal.

Can you switch your transceiver sockets to be type SL_SOCK_RAW? Can you also show me how you are opening the receiving socket? 

Feel free to share snippets of both the sending and receiving functions.

Maximum TX power level would be "0". Power level 1 is still very close to max, so that is most likely not your issue. You shouldn't need to set all those extra socket/PHY options for the receiving device (I can't tell from your description if this is what you are doing). They are intended for setting the parameters for the transmitter since you can't control the power-level, rate, etc. of the sending side from the receiver. Opening the RAW socket with the channel number should be sufficient. 

Best,

Ben M

Hi Ben, thanks for the response.

I did try raw and switched to SOCK_DGRAM in the hopes that the L2 socket would improve airtime access for me.  I'm getting the same results whether I choose SOCK_DGRAM or SOCK_RAW.

Here's how I create both the socket on each board.  I'm only opening one AF_RF socket for each board.  That socket does the sending and receiving on each board:

        eSocket = socket(AF_RF, SOCK_DGRAM, 0);

Receive for raw socket:

s16WifiSocketResult = recv(psSocketInternal->eSocket, (void *) pu8TempRx, (uint16) u32BufferSize, 0);

Send for raw socket:

s16WifiSocketResult = send(psSocketInternal->eSocket, (void *) pu8TempTx, (uint16) u32Chunk, 0 );

Can you explain what you meant by "CCA bypass"?  I'm not familiar with that and want to be sure I'm not missing something I should be configuring.  Also, do I need to do anything to "turn the transmitter on" other than open the socket with AF_RF and SOCK_DGRAM/RAW?

Hi Patrick,

CCA refers to Clear Channel Assessment which is the mechanism for detecting if other RF transmissions are occupying the channel. Using the "SL_SOCK_RAW" option instead of "SL_SOCK_DGRAM" bypasses the CCA mechanism.

I think the issue you may be having is that it seems you aren't opening on the raw socket correctly by including the channel in the "socket()" call. I'm assuming you are applying the "channel" option with the setsockopt afterwards.

Please try testing with the call as follows:

eSocket = socket(AF_RF, SOCK_RAW, 3);

EDIT: For reference, see section 16.2 of the Network Processor User Guide - http://www.ti.com/lit/swru368

Best Regards,

Ben M

Thanks for the explanation RE the CCA.  I understand what you mean now.  I'm trying both the SOCK_RAW and SOCK_DGRAM options.

Yes, I was setting the channel with a setsockopt afterwards. I instead tried setting the channel in the last argument of the socket() call as you specified and that doesn't appear to make any difference.  I'm still not receiving what appears to be sent.  Did it actually make a difference for you to set it in the socket() call vs in setsockopt()?

I need further advice on how to debug this issue. Is there a way for me to verify on the sending board that the data is actually transmitted successfully?  Could I use a transmit byte count in this case?

With regard to the final argument of the socket() API, socket.h does not reflect that the channel can be set here.  Also, swru368 says that 0 is a valid value "to keep the default channel."   Perhaps the documentation can be clarified?

Hi Patrick,

My mistake. My setup does work for both the setsockopt or specifying when you open the raw socket. 

You are using EVMs, correct? I'm assuming this based on the reference to "CC3100MODBOOST". There shouldn't be a HW issue unless something has been modified.

I'm running the same use-case on my LPs and it works as expected. I would recommend trying my setup code directly. Otherwise, you would need to have a tool like a sniffer to detect the data coming from the transmitter.

On my receiver I have:

    /* bypass the cca */
    //socketId = sl_Socket(SL_AF_RF, SL_SOCK_RAW, 3);
    socketId = sl_Socket(SL_AF_RF, SL_SOCK_RAW, 0);

    _u32 newChannel = 3; // range is 1-13
    sl_SetSockOpt(socketId, SL_SOL_SOCKET, SL_SO_CHANGE_CHANNEL, &newChannel, sizeof(newChannel));


    UART_PRINT("Starting data RX...\n\r");
    while (1)
    {
        MAP_UtilsDelay(800000);
        numBytesReceived = sl_Recv(socketId, buf, FRAME_LENGTH + 8, 0);

        if (numBytesReceived > 0)
        {
            UART_PRINT("Received %d bytes,", numBytesReceived);
            frameRadioHeader = (TransceiverRxOverHead_t *) buf;
            UART_PRINT(
                    " Rate = %d, Channel = %d, RSSI = %d, TimeStamp = %d\n\r",
                    frameRadioHeader->rate, frameRadioHeader->channel,
                    frameRadioHeader->rssi, frameRadioHeader->timestamp);
            for (idx = 8; idx < 38; idx++)
            {
                UART_PRINT("%x", buf[idx]);
            }
            UART_PRINT("...\n\r\n\r");
        }
        else
        {
            UART_PRINT("\n\r Error %d", numBytesReceived);
        }
    }

On my transmitter -

    for (idx = 0; idx < FRAME_LENGTH; idx++)
    {
        dataFrame[idx] = (signed char) (idx % 255);
    }

    /* bypass the cca */
    socketId = sl_Socket(SL_AF_RF,SL_SOCK_RAW, 3);

    _u32 preamble = 1;
    sl_SetSockOpt(socketId, SL_SOL_PHY_OPT, SL_SO_PHY_PREAMBLE, &preamble,
                  sizeof(preamble));

    for (idx = 0;idx < NUM_OF_PKT; idx++)
    {
        status =
            sl_Send(socketId, dataFrame, FRAME_LENGTH,
                    SL_RAW_RF_TX_PARAMS(TAG_CHANNEL,
                                             TAG_FRAME_TRANSMIT_RATE,
                                             TAG_FRAME_TRANSMIT_POWER,
                                             1));
        MAP_UtilsDelay(800000);
    }

I can see the prints in my terminal when I receive with my buffer of dummy data -

Received 1004 bytes, Rate = 4, Channel = 3, RSSI = -58, TimeStamp = 194023934
0123456789abcdef101112131415161718191a1b1c1d...

Received 1004 bytes, Rate = 4, Channel = 3, RSSI = -57, TimeStamp = 194084936
0123456789abcdef101112131415161718191a1b1c1d...

Received 1004 bytes, Rate = 4, Channel = 3, RSSI = -54, TimeStamp = 194145934
0123456789abcdef101112131415161718191a1b1c1d...

Received 99 bytes, Rate = 0, Channel = 3, RSSI = -72, TimeStamp = 194188629
40000ffffffffffff1856802347b8ffffffffffffa047001824...

Received 1004 bytes, Rate = 4, Channel = 3, RSSI = -50, TimeStamp = 194207085
0123456789abcdef101112131415161718191a1b1c1d...

Received 1004 bytes, Rate = 4, Channel = 3, RSSI = -50, TimeStamp = 194268140
0123456789abcdef101112131415161718191a1b1c1d...

Received 1004 bytes, Rate = 4, Channel = 3, RSSI = -53, TimeStamp = 194329111
0123456789abcdef101112131415161718191a1b1c1d...

Received 1004 bytes, Rate = 4, Channel = 3, RSSI = -54, TimeStamp = 194390140
0123456789abcdef101112131415161718191a1b1c1d...

Received 1004 bytes, Rate = 4, Channel = 3, RSSI = -53, TimeStamp = 194451138
0123456789abcdef101112131415161718191a1b1c1d...

Received 1004 bytes, Rate = 4, Channel = 3, RSSI = -52, TimeStamp = 194512316
0123456789abcdef101112131415161718191a1b1c1d...

Received 1004 bytes, Rate = 4, Channel = 3, RSSI = -54, TimeStamp = 194573318
0123456789abcdef101112131415161718191a1b1c1d...

Received 1004 bytes, Rate = 4, Channel = 3, RSSI = -56, TimeStamp = 194634316
0123456789abcdef101112131415161718191a1b1c1d...

Received 1004 bytes, Rate = 4, Channel = 3, RSSI = -51, TimeStamp = 194756370
0123456789abcdef101112131415161718191a1b1c1d...

Received 1004 bytes, Rate = 4, Channel = 3, RSSI = -48, TimeStamp = 194817494
0123456789abcdef101112131415161718191a1b1c1d...

Best Regards,

Ben M

Oh, very nice. I seem to be making some progress.  Your examples work to an extent and I'm finally getting some data but not getting all of it.

1) I set my FRAME_SIZE to 30 and am only getting 34 bytes on recv() (with 26 bytes of transmitted data) instead of 38.  What FRAME_SIZE are you using?  I see you're receiving 1004 bytes.

2) I set my rate to a value of 4 but it seems to come through as 3 in the info structure on recv().  Also sometimes I get invalid rate and channel values (as seen in the last example below.  Which rate value did you use for TAG_FRAME_TRANSMIT_RATE?

3) Sometimes I receive more data than I specify in the length field for recv().  For instance, I requested 38 bytes and got 46.  This is a problem since it will write past the end of my buffer (see below).  Should I open a new ticket for this?

On the receiving side:

Received 34 bytes, Rate = 3, Channel = 3, RSSI = -44, TimeStamp = 436970611
000102030405060708090a0b0c0d0e0f10111213141516171819007f0800...

Received 34 bytes, Rate = 3, Channel = 3, RSSI = -44, TimeStamp = 437472558
000102030405060708090a0b0c0d0e0f10111213141516171819007f0800...

Received 34 bytes, Rate = 3, Channel = 3, RSSI = -44, TimeStamp = 437974504
000102030405060708090a0b0c0d0e0f10111213141516171819007f0800...

Received 46 bytes, Rate = 0, Channel = 3, RSSI = -74, TimeStamp = 438143852
40000000ffffffffffff9cda3e00802fffffffffffff50b8000001088284...

Received 32 bytes, Rate = 48, Channel = 72, RSSI = 96, TimeStamp = 157424173
17ff00000000000000000000000000000000000000000000000001088284...

On the sending side:

Sent: 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d...

Sent: 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d...

Sent: 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d...

It turns out that the first byte sent must be a zero.  If I force the first byte to be a zero I receive most of the data sent (minus 4 bytes) on the other end. I tried setting it to 0x02 and 0x03 and neither of them would permit the message to be received on the other side.  Can you help me understand why this is the case?

Also, I still need help with the 3 issues outlined in the my previous response above.

Hi Patrick,

I'll need to bring my test setup back up to dig into these further. There isn't an inherent requirement to set the first byte of your payload as zero to see it received. I'll double check if any default filters are enabled that would prevent anything else from being dropped. I expect I'll be able to give you an update by end of day Wednesday.

1) I'm using a frame size of 1000. I believe the sl_Recv function is just returning the total number of useful data received and not accounting for padding. I'll double check this though because I ran a quick test on our CC3x20 device and it does return 1008.

2) I will have to retest. I swapped my test around a few times and I'm not sure which setting was used for the output I shared. Perhaps there is an overall issue with how the radio header is read in my example.

3) This did not happen while I was testing. When I bring my setup back up I will run it for longer to see if I can recreate this same issue. 

Best,

Ben M

Hi Patrick,

I was able to reproduce the issues with not receiving data when sending a payload that begins with 0x2.  I am also seeing that the end of my buffer is missing 4 bytes as you describe (it's not just returning the incorrect length as I originally thought). I am still investigating both of these.

I am not able to reproduce the issue with the network processor returning a packet that is longer than the buffer (length that I specify). I added a quick check after the sl_Recv() returns and I'm never hitting the condition during long test runs.

        numBytesReceived = sl_Recv(socketId, buf, FRAME_LENGTH + 8, 0);

        if(numBytesReceived > (FRAME_LENGTH+8))
        {
            while(1); // never hit this
        }

Regarding the mismatch in the rate parameter of the radio header, it is simply offset because the host is using a different numbering scheme than the network processor. To compensate, you can use an array with the following enums to print the value that you are expecting to see -

//from wlan.h
typedef enum
{
    RATE_1M         = 1,
    RATE_2M         = 2,
    RATE_5_5M       = 3,
    RATE_11M        = 4,
    RATE_6M         = 6,
    RATE_9M         = 7,
    RATE_12M        = 8,
    RATE_18M        = 9,
    RATE_24M        = 10,
    RATE_36M        = 11,
    RATE_48M        = 12,
    RATE_54M        = 13,
    RATE_MCS_0      = 14,
    RATE_MCS_1      = 15,
    RATE_MCS_2      = 16,
    RATE_MCS_3      = 17,
    RATE_MCS_4      = 18,
    RATE_MCS_5      = 19,
    RATE_MCS_6      = 20,
    RATE_MCS_7      = 21,
    MAX_NUM_RATES   = 0xFF
}SlRateIndex_e;

Note that RATE_1M should start at index 0 in the array and that there is no element with the value "5". Use the value that the radio header gives to index into the array and print the correct value.

Best Regards,
Ben M

Thanks Ben for the followup!  I'm really glad you were able to reproduce most of the issues.

Did you try a FRAME_SIZE of 30?  If you do that and then choose a busy channel, you should receive a packet that is larger than requested.

Hi Patrick,

I dropped the FRAME_SIZE to 50 when I tested because I saw a lot of packets coming in larger than 58 bytes. I'll drop it to 30 and try on a couple different channels today.

Best,

Ben M

Hi Patrick,

I'm still not able to reproduce the issue with receiving a packet longer than the buffer that is provided to the sl_Recv() function call, even with a smaller buffer. That seems to be working fine for me.

I am seeing more inconsistencies with the radio header (rate, rssi, channel, timestamp) that is reported on the packets though. This will take some time to dig into and resolve since the issue appears to be related to the firmware of the device in the transceiver mode.

I'll keep looking into this and give you another status update by the end of the day on next Monday.

Are you using the CC3200 in an existing product or is this a new design?

Thanks,
Ben M

Ben, thanks for continuing the investigation.

I'm using the CC3100 and this is a new design.