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.

Is this a bug included in a high speed mode of CC1310?

Other Parts Discussed in Thread: CC1310, CC1350

Hello, TI employees.

 

I suspect the CC1310 High speed mode has a transmission error bug when data type is random & byte length in the packet is long.

During the test of HSM(high speed mode), the occurrence of packet error in the HSM is quite frequent even in the high SNR (RSSI : -15dBm).

 

The test condition is as below.

 

- CC1310 Rev.A (TX, RX)

- Test board : TI EVM board & our customized board. (same result)

- Center frequency : 915MHz

- Byte length in packet : 500 bytes

- RF connected directly using RF cable and attenuator (= no interference condition)

 

Notice : We have confirmed the same phenomenon occurs at the bands of 913MHz and 917MHz.

Also, the same in the CC1310 7XD Evaluation board.

 

<Test results - No error data type>

- all zeros, all ones, 0x01, 0xAA, 0xCC...

- some random pattern : seed17, 9, 100, 98, 97...

 

<Test results - error data type>

- packet error occur when using random data of seed 9, 17, 98

- measured PER is about 0.001 ~ 0.000001

 

<Error patern>

- packet error has some pattern

- (1) 40byte period  - error position 37, 77, 117, 147...

- (2) allways last bit error

- (3) Increase error rate as data in the packet goes backward

 

<Detail error test result>

 

(randome data seed 17)

 

the position : 237, data expected : 94, data received : 95

                277, data expected : 48, data received : 49

                317, data expected : 96, data received : 97

(randome dataseed 100)

the position : 77, data expected : 94, data received : 95

 

(randome data seed 98)

the position : 397, data expected : 118, data received : 119

 

 

As you might have noticed something, the positions of error bytes are the specific points

and the errors are only one bit error. For the time limitation, we couldn't do the test

with more random seeds. But I think these results are enough to describe the situation we

are facing. We might have done the test wronlgy or your RF core may have a bug.

I don't know exactly why this is happening. A clear fact is that our video image is frequently

corrupted in the high speed mode. (the frequency is once in about 3 ~ 4 seconds.)

 

After seeing the above test results, please let me know how to fix the problem.

 

THANK YOU for your interest.

 

Best regards

  • Hello Sukneung,

    Thank you providing detailed description of the problem you are seeing in HS mode. We are looking into this but because of Thanksgiving, response will be a bit slower this week. Will get back to you with updates or questions when we are able to replicate this issue.

    Regards,
  • Hi,

    Any updates on this bit error?
    Our customer's application has similar kind of bit error problem with CC1310.
    CC1310 is communicating with a Sub 1GHz IC from a different maker.
    Everything is working well but sometimes there will be a bit error at CC1310 side.
    The error pattern is same and every time occurs at the same place
    and when there is a bit error it is always 0 changed to 1. Occurs only in standalone mode.


    This bit error doesn't occur when debugging through CCS, it only occurs in standalone mode.
    We wonder why this bit error won't occur when connected to CCS.

    Best Regards
    Kummi

  • Hello Sukneung,

    I am trying to replicate this issue on my test bench and do not see the same data with the seeds for random number that you have provided. I am also transmitting 500 bytes payload and tried a few seeds for the random number generator but do not see the problem. Have you tested this on more than one device? Can you please share your packet generation process so I can match your test bench.

    Regards,
  • Hello Kummi,

    If you do not see this issue when debugging with CCS, it may be related to timing/power management settings. Can you disable to idle task in config file on the project and check if the error goes away even when not using the debugger?

    Regards,
  • Hello, Thanks for  your interest.

    Basically, we modified and tested the code your company provided in Resource explorer, rfPacketErrorRate_CC1310_.

    First, create the packet as below

        /* Create packet with incrementing sequence number and random payload */
        testBuffer[0] = packet[0] = (uint8_t)(seqNumber >> 8);
        testBuffer[1] = packet[1] = (uint8_t)(seqNumber);

        srand(RAND_SEED);  // RAND_SEED = 98, 17, 100, etc.

        for (i = 2 ; i < PAYLOAD_LENGTH; i++)
        {
            testBuffer[i] = (uint8_t)rand();
        }

    And set some parameters and transmit the packet as below

                     currentDataEntry = RFQueue_getDataEntry();
                     currentDataEntry->length = PAYLOAD_LENGTH;  // 440
                     pPacket = &currentDataEntry->data;

                     memcpy(pPacket, testBuffer, PAYLOAD_LENGTH);  // copy the contents of TestBuffer into pPacket pointer.

                     RF_postCmd(rfHandle, (RF_Op*)&RF_cmdTxHS, RF_PriorityNormal, tx_callback, RF_EventTxEntryDone);
                     while(bTxPending);  // stand by until the last packet is transmitted. bTxPending becomes zero in the tx_callback.

    If the above code is not enough, request me more.

    Above is all we have done for testing the error condition.

    I repeat that this test was done in TI EVM(7xd) as well as our custom board in 915MHz band.

    We also have done the test with all radom seeds by increasing the sequence number automatically.

    In that test, a number of random seeds have yielded lots of errors and the results are the same with previous test.

    The specific points (e.g. 37, 77, 117, etc.) are the frequent error postions. Also, the unsaid error positions are come up but very rare.

    Regarding the specific error postions, we could correct the errors by prepending the TX data present in the specific error postions.

    This correction process is possble because the errors are not nearly present in the front part(error position start from 37).

    However, the errors still exist. We'd like to know the complete solution or our fault.

    Thanks.

  • Hi Sukneung Bae,

    Could you share the detail configuration information in High Speed Mode. We could not success in HSM with long packet loads(more than 80 bytes each), no matter how long the time gap of each packet is.

    Should we change some parameters(e.g. the pre code length) ? Could you share your configuration code of the Radio?

    Thanks

    Franklin
  • Hello Franklin

    My codes are all from the rfPacketErrorRate project.
    Basic settings are the same and some parameters were modified.

    Below are Tx settings.

    RF_cmdTxHS.pQueue = &dataQueue;
    RF_cmdTxHS.startTrigger.triggerType = TRIG_NOW;
    RF_cmdTxHS.startTrigger.pastTrig = 1;
    RF_cmdTxHS.startTime = 0;

    currentDataEntry = (rfc_dataEntryGeneral_t*)&txDataEntryBuffer;
    currentDataEntry->length = PAYLOAD_LENGTH; // 500 bytes
    pPacket = &currentDataEntry->data;

    If you want to speed up, use callback function in the High speed mode.

    Rx settings are below.

    RF_cmdRxHS.pQueue = &hsmDataQueue ;

    RF_cmdRxHS.pOutput = &rxStatistics_hs;
    RF_cmdRxHS.maxPktLen = HSM_MAX_PAYLOAD; // 512
    RF_cmdRxHS.pktConf.bRepeatOk = 1;
    RF_cmdRxHS.pktConf.bRepeatNok = 1;
    RF_cmdRxHS.rxConf.bAutoFlushCrcErr = 0;

    If you have further question, do not hesitate to ask.
    Good luck.
  • Hi 

    Could you share a copy of your project(in high speed mode) with your configuration(PAYLOAD_LENGTH = 500 bytes). We have tried HSM following your instruction, while the programme crashed with out any reactions.

    That's very kind of you.

    Franklin

    franklinzhang1985@gmail.com

  • Please check your email. I hope that helps you.
  • Hello, TI guys,

    Are there any futher comments on this subject?

    We are temporarily attaching redundant data to the header of the payload.

    This reduces the error rate but is imperfect.

    We investigated whether this error occur in CC1350 and the result is the same, i.e, frequent error occurs at the mentioned position.

    But, this error doesn't occur in GFSK mode. I am attaching the result capture obtained from our test.

    The picture right above includes the result from 2GFSK test. For 5 minute test, there are no packet errors as you can see.

    Right above result is from HSM. The picture shows the byte position and number of occurences of the byte error.

    Packet length of the test is 440 and the frequency is 919MHz. This result was obtained using two CC13xxEM-7xd-7793-AL Rev 1.0.

    I hope that this problem is recognized by TI engineer.

    Thanks.