• State Resolved
  • Locked Locked
  • Replies 19 replies
  • Answers 3 answers
  • Subscribers 58 subscribers
  • Views 1706 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC1352R: CW test for Sub-1GHz

AlexTim
Expert 1270 points
Part Number: CC1352R
Other Parts Discussed in Thread: BLE-STACK

Hi,

we have HCI_EXT_ModemTestTxCmd(), HCI_EXT_ModemTestRxCmd() for 2.4GHz.

Do we have something similar and simple to use for Sub-1GHz?

We want to implement radio tests for Sub-1Ghz in our project. We can do it for 2.4Ghz, read RSSI, etc.

In our previous project we used EasyLink and we run the Sub-1GHz CW tests there (EasyLink_Ctrl_Test_Tone, EasyLink_Ctrl_Test_Signal),

but we don't use EasyLink in our new project, there are BLE and TI 15.4 stacks in the project.

How can we start the continuous tx/rx tests with TI 15.4 (sub-1Ghz)?

  • 0
    Guru 735695 points

    Maybe try to use SmartRF Studio.

  • 0 in reply to YiKai Chen
    Expert 1270 points

    I know, but we want to run the Sub-1GHz tests during inline testing from the firmware. Is it possible?

    Actually, we use the SmartRF on the reference side in TX/RX mode for 2.4GHz and run the TX/RX test in our firmware on our device. But we don't know how to do it for Sub-1GHz.

  • +1 in reply to AlexTim
    TI__Guru* 87001 points

    Why do you want to use the TI 15.4 stack to do this? You can do this using the Prop API and just use the same PHY as you plan to use when using the TI 15.4 stack. Please see

    https://dev.ti.com/tirex/explore/node?node=AL6GtuZsDzmzmirIdG71dA__BSEc4rl__LATEST

    Siri

  • 0 in reply to Siri
    Expert 1270 points

    Thanks! Looks like it is exactly what we need, I will try.

  • 0 in reply to Siri
    Expert 1270 points

    I implemented the code from the rfCarrierWate in our project, but it hangs up after the

    rfHandle = RF_open(&rfObject, &RF_prop, (RF_RadioSetup*)&RF_cmdPropRadioDivSetup_, &rfParams);

    in the command

    RF_runCmd(rfHandle, (RF_Op*)&RF_cmdFs, RF_PriorityNormal, NULL, 0);

    because the rfHandle is NULL.


    So it looks like the radio interface is busy with TI15.4 stack and can't be reused.

    I guess I should run RF_close(RF_handle h) or something, but I need to know the TI15.4 handle.

    How can it be solved?

  • 0 in reply to AlexTim
    TI__Guru* 87001 points

    I am not familiar with the TI 15.4 stack, so I will need to find someone else that can comment on that. However, I do not understand why you need to use the TI 15.4 stack for this at all. I assume that sending a CW is for some kind of RF testing and not something that you are going to do in your application. For RF testing, why do you not just make test code that run without using the stack. You can use the same PHYs as the stack does when running prop.

    Siri

  • 0 in reply to Siri
    TI__Expert 3886 points

    Hi Alex,

    AlexTim said:

    So it looks like the radio interface is busy with TI15.4 stack and can't be reused.

    I guess I should run RF_close(RF_handle h) or something, but I need to know the TI15.4 handle.

    Unfortunately there isn't an equivalent to the RF_Handle in the TI 15.4-Stack. The Stack does take ownership of the radio as you correctly pointed out, and by doing so you are limited to use the radio in a specific way (that's not really compatible with a CW test).

    As Siri mentioned, for RF testing the best approach is to just make code that runs without the stack.

    BR,
    Andres 

  • 0 in reply to Siri
    Expert 1270 points

    The radio CW test should be a part of our main firmware. So, our device supports two stacks: BLE and TI15.4 and does the regular work in our system.

    We have a CLI and a few commands to start the tests. The tests should be available in the device anytime, not only for temporary testing in production.

    We can stop BLE advertising and use HCI commands to start the tests for 2.4GHz.

    So, my questions are:

    1. Does TI15.4 stack have an option to run the carrier test like BLE stack? Looks like your answer is "no"

    2. Can we stop the TI15.4 stack and release the RF core to use the prop_rf carrier code?

  • 0 in reply to AndresM
    Expert 1270 points

    Have a look at my previous answer please.

    So, probably the only possible solution in my case is implementing a CLI command that would reboot the device with a flag "don't start ti15.4 stack", so the rf core for sub-1ghz would be not busy and then we could start the prop_rf carrier test. When we done the tests, we set flag "start ti15.4 stack" and reboot it again. Right?

  • +1 in reply to AlexTim
    TI__Expert 3886 points

    Hi,

    AlexTim said:
    Does TI15.4 stack have an option to run the carrier test like BLE stack? Looks like your answer is "no"

    There is no API available in the TI 15.4-Stack that would allow you to do this. My guess is that HCI_EXT_ModemTestTxCmd() and HCI_EXT_ModemTestRxCmd() are part of the TI BLE-Stack to meet the requirements of a particular standard. 

    AlexTim said:
    Can we stop the TI15.4 stack and release the RF core to use the prop_rf carrier code?

    I don't see an API in the TI 15.4-Stack that is meant to stop the MAC later after the application has made a call to ApiMac_init(), but it's worth looking at the DMM documentation to see how the radio is shared between multiple stacks. Maybe this can provide some ideas on how to do it.

    AlexTim said:
    So, probably the only possible solution in my case is implementing a CLI command that would reboot the device with a flag "don't start ti15.4 stack", so the rf core for sub-1ghz would be not busy and then we could start the prop_rf carrier test. When we done the tests, we set flag "start ti15.4 stack" and reboot it again. Right?

    That might also be good option since it would allow you to control when TI 15.4-Stack starts.

    BR,
    Andres 

  • 0 in reply to AndresM
    Expert 1270 points

    Hi,

    I managed to run the code in our project,

    but it gets stuck after the command "RF_cmdTxTest".

    I see in the rfCarrierWave example that it is expected behavior, because

    How could I change the command

    to path through and be able to return from the function to our code?

  • 0 in reply to AlexTim
    TI__Guru* 87001 points

    In the example you have used, the end trigger of the command is set to TRIG_NEVER, meaning that the command will never end.

    You need to change this to TRIG_REL_START:

    RF_cmdTxTest.endTrigger.triggerType   =  TRIG_REL_START;

    and then you need to sett the RF_cmdTxTest.endTime to how long you want the device to transmit (in RAT ticks).

    If you do not want to stay in TX for a fixed time, you can have for example an interrupt and use RF_cancelCmd()

    BR

    Siri

  • +1 in reply to Siri
    Expert 1270 points

    Thanks, but I asked about different thing.

    Why the program counter never reach the breakpoint?

  • +1 in reply to AlexTim
    TI__Guru* 87001 points

    That is what I tried to explain.

    RF_runCmd is blocking and waits for the for the command to complete, and it does not complete because you tell it to never complete (TRIG_NEVER).

    Changing trigger to end the command, will have the function return and you will reach your breakpoint.

  • 0 in reply to Siri
    Expert 1270 points

    ok, thanks, I understand. Looks like I should use RF_postCmd() instead of RF_runCmd()

  • +1 in reply to AlexTim
    TI__Guru* 87001 points

    If you do that, and not change the trigger, you need to manually cancel the command whenever you do not want to transmit anymore.

  • 0 in reply to Siri
    Expert 1270 points

    I noticed that the rfCarrierWave code works only when I disable BLE stack, so it doesn't depend on the TI15.4 stack at all.

    If I just disable BLE advertising, it doesn't help, only disabling the whole stack with the define xBLE_START works. So it looks like when I try RF_open() in the rfCarrierWave function, it work only if one stack is active at the moment.

    Also I found some similar topics:

    https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/950304/cc2652p-can-rf_runcmd-don-t-block-system-cpu

    https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/849979/cc1352r-combined-code-from-the-sensor-2-4g-example-and-the-rfcarrierwave-example-resetting-mcu

    It's very sad that we can't run the CW test in ti15.4 projects directly without issues.

  • 0 in reply to Siri
    Expert 1270 points

    Actually I found a way to disable initialization TI15.4 stack as well. So, the rfCarrierWave works only when one of stacks (BLE or TI1.4) is disabled (or both of them). Otherwise it fails during running RF_open().

  • 0 in reply to AlexTim
    TI__Guru* 87001 points

    I assume that what you are trying to do is not a use case that is very common, hence not supported by the API.

    Once you start to control the RF by using the RF Driver directly, while using two different Stacks that are supposed to take care of this, it is easy to mess things up. I am sorry that we do not have a good solution for this.

    BR

    Siri