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.

LAUNCHXL-CC1352R1: SmartRF Studio 7 can't receive MSB.

Part Number: LAUNCHXL-CC1352R1
Other Parts Discussed in Thread: CC1352R

Hi.

Test Environment:

CC1352R launchpad 2 set.

#1 : "simplelink_cc13x2_26x2_sdk_3_40_00_02\examples\rtos\CC1352R1_LAUNCHXL\ti154stack\sensor_oad_offchip_secure" is operating.

#2 : Connect to SmartRF Studio 7 to view received packets

question:

1. when LSBit_First  is set up in SmartRF Studio7. I was able to check "Beacon Request packet"

What setting factors do I need to change to send to MBSbit-First in "simplelink_cc13x2_26x2_sdk_3_40_00_02\examples\rtos\CC1352R1_LAUNCHXL\ti154stack\sensor_oad_offchip_secure"

2. The frame control field's frame version is currently 00. Can I change it to 10?

best regard,

  • Hey Robin,

    robin Moon said:

    1. when LSBit_First  is set up in SmartRF Studio7. I was able to check "Beacon Request packet"

    What setting factors do I need to change to send to MBSbit-First in "simplelink_cc13x2_26x2_sdk_3_40_00_02\examples\rtos\CC1352R1_LAUNCHXL\ti154stack\sensor_oad_offchip_secure"

    In mac_settings.c, it looks like the 15.4 mac is already set to send MSB first on line ~180.

    RF_cmdPropRadioDivSetup.formatConf.bMsbFirst = 1;

    robin Moon said:
    The frame control field's frame version is currently 00. Can I change it to 10?

    In api_mac.h, you'll find the following code (lines ~791-797),

        /*!
         Currently supports 0 and 1.
         If 0, frame Version is always 0 and set to 1 only for secure frames.
         If 1, frame version will be set to 1 only if packet len > 102 or
         for secure frames
         */
        ApiMac_attribute_frameVersionSupport = 0xE6,

    You should be able to set the frame version by changing the ApiMac attribute. You can do this by calling the following line in your application:

    ApiMac_mlmeSetReqUint8(ApiMac_attribute_frameVersionSupport, 0x10);

    Note that I have assumed 10 to mean 0x10 in hex. Adjust this value accordingly if that assumption is invalid.

  • Thanks.

    if RF_cmdPropRadioDivSetup.formatConf.bMsbFirst was set 0, is it LSB First?

  • Yes, setting that changes the settings on the radio so that you transmit LSB first.

    I am not sure if the stack supports this change, however. Please allow me some time to look into this for you.

  • Thank,

    my customer want to transmit both LSB and MSB.

    please check it.

    regard.

  • Hey Robin,

    After looking into this further, I would not recommend changing the RF_cmdPropRadioDivSetup.formatConf.bMsbFirst parameter. This parameter changes the setting at the lowest layer (i.e. the radio). Our phy has been characterized and tested with this setting, and although changing this parameter does change the order the bits are sent over the air, it does not change the endianness as the application has set it. I.e. you must change this setting on both collector and sensor, and the data transmitted is still the same once interpreted. Does this make sense?

    For this reason, I would suggest changing the order of the data in the packet manually (from the application level) to fit your requirement of LSB or MSB first. Is this sufficient for your use case?

    EDIT: clarified wording on above statement

  • When 15.4-stack_sensor_OAD_off-Chip Example used without modify.

    it was set as MSBFirst.

    The packet can be checked normally only when it is set as LSBfirst in RFstudio.

    however,

    When rfEasyLinkListenBeforeTalk Example used without modify.

    it was set as MSBFirst.

    The packet can be checked normally only when it is set as MSBfirst in RFstudio.

    In conclusion, the stack configuration seems strange.

    You need to make sure that it is sent to MSBfirst.

  • Hey Robin,

    I apologize for the confusion. It's up to the user/application to decide how to transpose data when sending data over the air.

    Our 15.4 stack uses the same data format as the MCU, little endian.

    For this reason you see the mismatch you described. I recommend reversing the data being sent in the application layer if this is desired. Unfortunately, you won't be able to change the overhead layers because they are built in the source files.

  • Are there any plans to change the SDK?

    Do you need to modify the default beacon packet as well as the USER data?

    Please tell us your next version release plan.

  • Hey Robin,

    There aren't any plans to add an option for changing the endianness of the 15.4 stack packets, as this would add unnecessary latency to the project.

    You can modify the beacon payload as necessary from the application level just like you may modify user data.