• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 2 answers
  • Subscribers 53 subscribers
  • Views 856 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.

CC1310: Fastest way to trig TX command after RX command

abdullah cinar
Intellectual 540 points
Part Number: CC1310
Other Parts Discussed in Thread: WMBUS

Hi,

I'm trying to implement something like range extender. I need to listen for specific packets continuously and for each packet received, I need to verify whether that packet needs to be extended. If yes, I need to start the TX command and after finishing the TX command, go back to start (listening).

I have to do some custom decode and CRC verification on the received packets in order to decide whether the received packet should be transmitted or not. I have some ideas below on how to achieve this, but I'm not sure which way would be the fastest.

  1. Chain TX to the end of RX. Use CMD_TRIGGER as a software trigger for the startTrigger of the TX command. When RF_EventRxEntryDone occurred, verify the packet INSIDE THE CALLBACK (otherwise we would have to use another task to do it because commands are chained and RF_runCmd will not return until the TX is finished.). If the packet needs to be extended, trig the TX command using RF_runImmediateCmd.
  2. Do not use command chaining, just start RX command. When RX finished, verify the packet and start the TX command if the packet needs to be extended. In this method, I can do the verification of the received packet inside the main task after RF_runCmd for RX command returned.

Regarding the above ways;

The way1 is doing the packet verification inside the callback. Normally I don't want to do that. And I don't want to use another task too because I have read that it is not recommended to send RF commands from 2 different tasks.

The way2 does not use command chaining, I will be responsible for starting the RX and TX commands consecutively after the verification of the packet. In this case, as I know it will be slower compared to command chaining because I will send another command to start TX.

Regards.

  • 0
    TI__Guru* 86071 points

    Hi

    I think both methods would work, but unfortunately we do not have any data on what would be the fastest. Normally, command chaining is the fastest, but then again, you would normally use TRIG_NOW for the TX command, so that it would start as soon as possible after the RX command was done.

    Why do you need to do custom CRC verification? The CRC of the CC1310 is configurable, so the best thing is to let the radio itself take care of this.

    If you in addition you use address filtering/length filtering etc. so that you only received packets that should be re-sent, this would definitely be the fastest.

    BR

    Siri

  • 0 in reply to Siri
    Intellectual 540 points

    Hi Siri,

    Thanks for the answer. The received packets will be encoded with 3out6 encoding. So we have to decode the received packet in order get the length from the first byte and then do CRC verification. I couldn't find any way to make the radio do that. So I just disabled CRC from both RX and TX commands. I also can not use variable-length packets because the first byte contains the length BUT as encoded with 3out6 encoding. So in order to find the packet length, I have to decode the first 12 bits. I am using fixed packet length with the length set to maximum. Later I will try to use partial reading as a more efficient way.

    Regarding the command chaining, I just completed a demo like I described in the first step:

    • Start RX command (without chaining) and wait for packets
    • Decode and verify the received packets when RX command finishes.
    • If the packet should be extended, start TX command.
    • Go back to step1 (infinite loop)

    I have only one question regarding this method; between RX and TX commands, I'm only doing a decode/CRC check. Do I have to wait for a while in order to switch from RX to TX? Is there any limit or caution that I should care while switching between them?

  • 0 in reply to abdullah cinar
    TI__Guru* 86071 points

    You can send the TX command as soon as the RX command has finished.

    Is it by any chance wmbus you are working on? If it is, we have a patch that does the 3out6 encoding/decoding for T-mode:

    Siri

  • 0 in reply to Siri
    Intellectual 540 points

    Hi Siri,

    It is really interesting that I and my colleague had problems with StackForce's wmbus stack for months and asked for help from TI. I haven't seen this document before and no one in E2E suggested this document even if I said I'm trying to write my own wmbus stack.

    In the last month, we have completed our wmbus T-mode stack at least as one-directional. We are now trying to implement a range extender.

    When I have time, I will review this document and try to find out if we should stop our work on our custom wmbus project and use your patch.

  • 0 in reply to abdullah cinar
    TI__Guru* 86071 points

    Hi

    I have looked through your old post and only see one where you state that you cannot use the stack from SF since it does not support as many devices as you want to support. Your questions are related to FIFOs etc. and not RF settings, so I guess that this is why no one has suggested this document.

    The document is easily found on the same page as you found the stack from SF :-)

    Siri

  • 0 in reply to Siri
    Intellectual 540 points

    Hi Siri,

    Sorry for the inconvenience. I realised that we already had that file as a reference but since we had limited experience with wMBus and CC1310, we thought that document is part of the StackForce library. Now when you sent me that document here and I looked at it, I realised that it offers a different solution as a patch to start with. 

    I also found a project named "HybridWmbusPlcExample_CC1310_LAUNCHXL_tirtos_ccs" and mentioned in this link. What do you think about this project? Did you use the same patches for this project?

    Thanks!