• State TI Thinks Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 3 answers
  • Subscribers 53 subscribers
  • Views 366 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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-CC1310: Create proprietary ISM network for telemetry purposes

Dimitar Belev
Prodigy 30 points
Part Number: LAUNCHXL-CC1310
Other Parts Discussed in Thread: CC1310, CC1312R, CC1350

Hi,

We are in charge to create for new system RF proprietary network. Our goal is to be able to add maximum of 50 devices. We need to use ISM band (868/915) due to RF coverage requirements. As far as we read the radio module datasheet, there are several modes of operation, 802.15.4 and proprietary radio (the second seems best for our purposes). The system is telemetry system and each monitored device should send ~130bytes payload each 100mS, also some individual and broadcast commands should be received from the devices. The data rate (per device) is ~ 10*130 = 1300 bytes, total rate is ~50 * 1300 = 65KB/s

For this purpose we need to implement "Network like" simple Media Access Control. We can have single CC1310, acting as a network concentrator (similar to WiFi Access Point).

Do you have some recommendations, based on your experience if this should be possible to achieve, using the CC1310 proprietary radio commands, and if you can recommend how it will be best to create the media access level for collision avoidance - ether based on carrier detection before sending from each device, or hard network synchronization from single "master" device in the network.

Our additional goals are:

- We want to have address assignment, similar to the DHCP - the central device to detect how many clients are connected (for 1-2 seconds time for detection per new device) and give addresses. This task will be hardly achieved if there is single master, which to synchorize all the traffic. From the other hand, we do not have any experience with the CC1310 radio possibilities and any conceptual advice what we can read about will be highly useful for us.

Regards

Dimitar

  • 0
    TI__Guru* 79361 points

    Hi Dimitar

    Standard packet format in prop mode is 4 bytes preamble, 4 bytes sync, 1 optional length byte, I optional address byte, payload, and 2 bytes CRC.

    That means that for 130 bytes payload, you will send in total 4+4+1+1+130+2 = 142 bytes

    Using a data rate of 50 kbps means it will take 142*8/50000 = 22.72 ms to transmit a packet on the air, while using 500 kbps means that it takes 2.27 ms (max characterized data rate for cc1310 is 500 kbps)

    The CC1312R support 1 Mbps data rate, and sending a 130 bytes long payload will with this radio take 1.14 ms.

    We do not have any recommendations and/or guide as to how to build a proprietary MAC layer, so I can only comment on what the radio itself is capable of.

    Typically when forming a network and having multiple devices wanting to transmit over the air, you need to implement some kind of collision avoidance.

    The CMD_PROP_CS command can be used for this purpose.

    More info regarding the carrier sense command can be found here: https://dev.ti.com/tirex/explore/node?node=AOFmdaK8impnxmEqGU3jkg__pTTHBmu__LATEST

    and an example of how to use it to check a channel before transmitting is found here:

    https://dev.ti.com/tirex/explore/node?node=APElKwJhh6-TGvG9qVY69g__pTTHBmu__LATEST

    For testing of simple RX and TX I will recommend the rfPacketRX and rfPacketTX examples from the SDK.

    I strongly recommend that you take a look at Section 27.7 in the CC1310 TRM (https://www.ti.com/lit/swcu117) to learn more regarding packet format and available API commands for prop mode.

    BR

    Siri

  • 0 in reply to Siri
    Prodigy 30 points

    Hi Siri, thank you for the clarifications and very useful information,

    As far as we checked in the other threads, it should be possible to enter HS mode and achieve 4mbps, using 8FSK modulation at 868MHz, but it is not officially supported. Do you have any information if we can use such configuration. The threads i found are:

    https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/548001/some-questions-on-high-speed-mode-in-cc1310

    Here the suggestion is, that the CC1310 is capable of 4mbps, using the 8FSK, which is not officially supported by RF studio. The thread is very old, and we got the latest version of the RF studio, still nothing above 500kbps and 2FSK modulation.

    https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/885164/cc1310-cc1310-what-is-max-data-rate-on-reva-device

    Here there is suggestion to use specific example, which configures the CC1310 in high-speed mode, which is available in the SDK. We will check that and test it if it is possible to implement the radio settings and if it is possible to use HS settings for our purposes.

    Regarding the Media Access Control (MAC) - we will follow to check the commands you suggested and will try to base the network access on them, using some repeating and confirming at RF level protocol. Thank you very much for this info.

    Do you have more information if it is possible and how to implement HS mode and possibility of achieving 4mbps for CC1310?

    Regards

    Dimitar

  • 0 in reply to Dimitar Belev
    TI__Guru* 79361 points

    4 Mbps is not available in SmartRF Studio, as that PHY requires a HS API that is not supported in Studio.

    The only example we have of using the HS API is in the rfPacketErrorRate example in the CC1310 SDK:

    https://dev.ti.com/tirex/explore/node?node=ANa4Yp5tjPzx-RH4lkrXXw__eCfARaV__LATEST

    Please note that the CMD_PROP_CS command is not available when using HS mode.

    While the sensitivity for 4 mbps is around -84 dBm, the sensitivity for 1 mbps on CC13x2 is -97 dBm, so if you do not absolutely need a data rate of 4 mbps (I do not see why you should need that), I would recommend going for 1 mbps on C1312R.

    Siri

  • 0 in reply to Siri
    Prodigy 30 points

    Hi Siri,

    Thanks much for the valuable info. Typically the project we build is system of 50 devices maximum, each device sends ~each 80-100ms a packet with 130payload/142total bytes, 50 * 142 * 12.5 = 88750KB/s ~ 710000. It very depends how we will build the MAC layer, so the network can run with minimum network access overhead, but 1mbps seems usable and we will try to fit into 1mbps in order to get the bigger sensitivity.

    I found this thread:

    https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/637171/rtos-launchxl---cc1310-cc1310-listenbefortalk-at-1m-rate/2352098#2352098

    Which (if true and working) may be useful at forcing the CC1310 at 1mbps (HSM) but also working CMD_PROP_CS. We bought 4pcs of LAUNCHPAD-CC1310. Will try to implement some test functionality to test the sensitivity/rate/CMD_PROP_CS possibility with CC1310. If we cannot fit into CC1310, will check CC1312R.

    Thanks again for the suggestions

    Regards

    Dimitar

  • 0 in reply to Dimitar Belev
    TI__Guru* 79361 points

    The post you are linking to has nothing to do with High Speed Mode (HSP) which is a defined PHY with its own API.

    What the post is referring to is to use the BLE PHY (1 Mbps) + the prop API.

    I have tested the PHY, but I have never tested the CMD_PROP_CS with this combo of PHY/API.

  • 0 in reply to Siri
    Prodigy 30 points

    Hi Siri,

    We tested, 4pcs of CC1310 Launchpad. 500kbps works normal, all examples. We tested the BLE Phy with the patch from the thread above (BLE Phy + proprietary API) , RX and TX works, CMD_PROP_CS still does not work. On the example "WaitBeforeTalk" if we use the default configuration, the  CMD_PROP_CS command returns PROP_DONE_IDLE result. If we apply the patch, the PROP_DONE_IDLE command returns PROP_DONE_BUSYTIMEOUT.

    We checked the CC1312R, but seems there is no stock, and higher price. Our target is 4months of design and April 2021 to start first test batch. Basically if it is any chance to use the CC1310 with 1mbps and working networking MAC (based on RSSI and carrier measuring) will be the only option. We checked options for another MAC collision avoidance, based on pure synchronization packets from the network master, but adding more devices adds much overhead and timings and is not usable in our case.

    If you can provide any help with the patches (if it is possible at all BLE and the proprietary API, or similar configuration), we will test them in field, or if there is another proper part number, we can test it and start the design. If we can measure the RSSI/carrier somehow, or to build the channel state detection ourselves, will also be a possible solution. In the project we will use the CC13xx only as a RF interface and the application will run entirely in the main MCU, so any ideas are possible.

    Many thanks in advance

    Regards

    Dimitar

  • 0 in reply to Dimitar Belev
    TI__Guru* 79361 points

    HI Dimitar

    It will not be possible to use the BLE PHY with the CMD_PROP_CS (I have checked with R&D).

    I am not sure what patches you are referring to when you say that you are able to get BLE PHY + Prop API up and running.

    I realized today that when I have been testing this before I have use the CC1350 and 2.4 GHz. I have been trying all day to get BLE PHY + Prop API to work on 868 MHz, but without any luck. If you have managed to get this up and running, I would appreciate if you could share you overrides and API setup etc.

    If you are able to run BLE PHY + Prop API, you should be able to use the RX TEST command to put the radio in RX, and then just read the RSSI manually. Based on what the RSI is, you can choose to call your TX command or not.

    BR

    Siri

  • 0 in reply to Siri
    Prodigy 30 points

    Hi Siri,

    10x for the advice, it seems BLE plus prop API is still not working, i am waiting also for my colleague, to confirm, if he had managed to run the BLE PHY and prop API combination as RX and TX even without CMD_PROP_CS. In the meantime i borrowed the rfPacketErrorRate example - HSM phy code and commands and will try to run the rfPacketRx and rfPacketTx, based on the HSM phy and commands, which should work (the rfPacketErrorRate works in HSM mode out of the box). Then i will try to implement the manual read of the RSSI in this mode and will evaluate if it will work. Currently i managed to run the rfPacketTx and later will run the Rx and do the tests.

    Our final goal is to run 4pcs of launchpad boards with the final "network-like" application, each of the board to transmit 130 data payload bytes each 8ms, in order to try how the "network" will behave similar to 50 devices, trying to send 130 bytes each 100ms. The idea is to be able to measure sent/received packets of each board and to evaluate if this can work for the final application (we are redesign existing project, based on WiFi network - we want to increase the range and keep the troughtput)

    Some (additional) questions:

    1. For the HSM mode is it possible to decrease the datarate bellow 4mbps, due to we want to trade datarate per sensitivity/range for best fit in our application, if there are some patches we can use, just let me know.

    2. The XDS110 debugger is not visible in linux environment (I use Ubuntu 20.04LTS) and we cannot program/debug the boards. When i test the connected devices to the USB ($lsusb) the debugger seems present, but the studio does not see it. The $xdsdfu -e command does not find any connected XDS110 debugger. We found some existing e2e threads, pointing to links to proper driver, but this links does not seems to be alive and we cannot get driver. If you can help on this, we will speed-up the tests Slight smile

    3. For the manual RSSI read do we need to use this command:

    #define CMD_GET_RSSI 0x0403

    4. Where we can find description for the difference between the normal RX and RX_TEST, due to we are in HS mode, may be RX_TEST is not relevant, sorry, we are still new to the platform and now getting familiar with the development process.

    Regards

    Dimitar

  • 0 in reply to Dimitar Belev
    TI__Guru* 79361 points

    Hi Dimitar

    1) This is not possible

    2) I will recommend that you post this question in the Tools forum: https://e2e.ti.com/support/tools/

    3 and 4) That was the command I was thinking of, and it is called if you use the RF_getRssi function described here:

    https://dev.ti.com/tirex/explore/content/simplelink_cc13x2_26x2_sdk_5_20_00_52/docs/rflib/html/group__rf__driver.html#gac3fe0d39243fb6bbefe0216d958a6779

    For proprietary I would have used the CMD_RX_TEST, as this does not look for sync word and stays in RX until you turn it off/cancel it, but I tested it right now with the HS RX command, and even if the command runs without error, it always reports -128 back.

    I will try to investigate further, but there seems to be challenges around getting the RSSI with the HS mode.

    BR

    Siri

  • 0 in reply to Siri
    Prodigy 30 points

    Hi Siri,

    10x for the suggestions:

    1. We found this thread:

    https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/628551/cc1310-receive-nothing-using-433m-1mbps-with-rf_cmdproptxadv-rf_cmdproprxadv/2363574#2363574

    It contains patch for 1.5mbps (Should be the HS PHY with 4FSK modulation), which works with the HS commands, we implemented and tested it - it works (the attached working project at the end of the thread is the working one, the previous code does not work). We will use this as a backup if 1mbps is not enough. We also implemented the HS patch from the rfPacketErrorRate example - it also works. Currently we created basic project with selectable 4/1.5mbps based on the HS commands - works.

    2. OK, will do it later, for now will stuck to the Win versions and in the meantime will try to switch back.

    3 and 4. We just managed to run the RF_getRssi command together with the HS and it (seems to) worked. I will post the current test code, so you can check also, it is based on the HS patch and includes receiving and check for RSSI, if the RSSI is bellow the threshold value, it sends a packet in HS mode. Currently seems to work (The RSSI values seems real in debug) but will test it with more devices and will get back with the project.

    Currently we are clear to implement and test the network access protocol, if it works, will get back with the information to you and will mark the thread to resolved.

    Regards

    Dimitar