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 radio performance on Contiki

Other Parts Discussed in Thread: CC1310, CC2650

Hi,

We have done some range tests with cc1310 on Contiki vs the 50kbps TI Test-SW which comes with the EM cards, and saw ~10dB poorer performance for Contiki. We also tried updating to the latest cc13xxware, seeing the same results.

I have gone through the radio settings with the Contiki maintainer for the platform, please see https://sourceforge.net/p/contiki/mailman/contiki-developers/thread/CAFBGMVNOmRZWLCVfw6c0MeAs29FJippw%2BScxY2DeUfoqiCPg8Q%40mail.gmail.com/  where the Contiki radio settings and SmartRF studio settings are listed. My next step is to fiddle with the "overrides" setting of SmartRF, but I wanted to ask here

1) Does anyone has any directions or ideas as to what might be causing this?

2) Does the TI Test-SW shipped with the EM-cards utilize the boost mode, i.e. 14dBm output power?

Regards,

Andreas Urke

  • Hi, Andreas

    How did you test the two cases? And how do you define ~10dBm poor performance? Do they have the same packet drop rate?
    What is the RSSI you got when testing cc1310 on Contiki?

    Thanks.

    Regards,
    Yinxu Wang
  • As I know, the datarate of Contiki CC1310 is 50k bps. Do you test RF performance with the same datarate using SmartRF Studio 7?
  • Hi, thanks for the replies.

    1) We had EM-cards mounted on two SRF boards placed at some fixed distance. We then ran the TI 50kbps (same datarate as Contiki) test and observed the dB on the display. Next we switched to Contiki SW and did the same test and observed the dB as reported by the radio via the sicslowpan_get_last_rssi() method which, as far as I can tell, reads a field populated directly by the radio. Comparing these two values showed ~10dB difference. I did not make notes of the exact values of dB. We also did a quick "test" outdoor a long time ago with Contiki, and the general feel was that the range was significantly shorter compared to our previous test with TI 50kbps

    2) As noted above, we chose the 50 kbps mode when running the TI software, so at least the datarate should be equal to Contiki (I am not sure of other radio properties in the pre-flashed TI software)

    Andreas

  • I also tested the radio performance of Contiki CC1310. I tested with MQTT application layer, the two nodes (one is edge router, another is sensor node) can communicate well when RSSI is larger than -87 dB, however, if I moved the sensor node further, which obviously reduced the RSSI, the two nodes cannot communicate with each other anymore. I know there must be some performance loss due to communication stack and I thought the loss results from that until I saw this post.There are almost 20 dB performance loss if I use MQTT application layer, maybe 10 dB of it comes from the problem you have as well.
  • The application layer would not affect the RSSI of the received packets unless it changes the radio settings, which would be extremely strange. It's more likely that there's a difference in radio settings (modulation, channel width, etc, etc) between the two (TI test app and Contiki).

  • Thanks for sharing Yinxu. As mslothy pointed out, the application layer should not cause this. Can you elaborate on "There are almost 20 dB performance loss if I use MQTT application layer": What is your other setup not using MQTT?

    Regarding the distance, check out the CCA threshold which is set to -90dB, see PROP_MODE_RSSI_THRESHOLD in prop-mode.c. I don't know the rationale behind choosing this particular value, but you can probably experiment around it. If you do I am very interested in the results!

    Andreas

  • Hi Andreas

    Thank you for replying.

    I understand that the RSSI of received packets (the value given by CC2650 Radio Core) will not be affected by communication stack. What I meant is that communication stack may cause some packets dropped when RSSI is very low because there are several "acknowledgements" on different layers. I was thinking of that two nodes might be able to send and receive with a packet drop rate, let's say 80%, and if nodes just send something like "hello" and no "acknowledgement" needed, they can work at a very low RSSI, but when there is communication stack, nodes need "acknowledge" to each other and thus, a successful communication can only be made at a relative high RSSI. And since the RSSI I saw is a RSSI of the successful communication, it is relatively high.

    I am not sure what I was thinking is right.

    I will try the experiment that you mentioned. I will post if any results.

    Yinxu
  • Yeah, that's absolutely a possibility. I don't know if RPL defaults or not to drop weak links in order to "protect" itself, and RF links are indeed asymmetrical (eg A may successfully hear B but not vice versa). So your two setups may be optimized for two different things - TI test for maximum range to show RF range performance, Contiki for optimal link to energy expenditure ration.

    I'd recommend you to think through what you want to test, why, and how, and set up accordingly. Eg maximum possible range, but keep in mind that this may not be a useful metric or expectation in your application - ie, if you require bidirectional communication and to conserve power, a too weak link may be useless (hence Contiki is here doing the right thing by dropping too weak links). Also, a too weak link may cause many retransmissions, causing network congestion thus reducing the overall usable network throughput.
  • Hi mslothy

    I totally agree on what you mentioned, what, why and how to set up and test is important. I am trying to figure out a way to test if there are some performance loss due to optimization for reliability.

    Thanks much.

    Yinxu
  • Hi Andreas,
    I am experiencing the same issue and wonder if you have come to some resolution?
    I see your post on lists.sourceforge.net which also seemed to end without a positive conclusion
  • Hi Phil,
    Try to revise "#define PROP_MODE_RSSI_THRESHOLD 0xA6" to "#define PROP_MODE_RSSI_THRESHOLD 0x9C" in prop-mode.c under \contiki\cpu\cc26xx-cc13xx\rf-core
  • Thanks YK,

    This is not a solution to my problem - once the RSSI gets above 90bBm, the comms becomes unreliable so 90dBm seems like a reasonable threshold (perhaps some tweaking could be done once signal strength issues are resolved).

    What I am seeing is that the RSSI I am receiving for a given distance is MUCH (i.e. 20 to 30 dBm) below what would be expected (based on the Range Estimation for Indoor / Outdoor, and also what I see with the packet error rate tester that the CC1310 comes shipped with).

    here is what I am seeing :

    distance (m) | RSSI (dBm)
    0.05 -14
    0.1 -25
    0.2 -33
    1 -42
    2 -51
    5 -60
    10 -63
    20 -67
    25 -69
  • Hi Phil,

    I have not resolved the issue, but "jimmycmlo" at the Contiki github has experience the same issue, and gotten some clues as to the possible cause, please see: https://github.com/contiki-os/contiki/issues/1659

    Btw, your dBm values seems really low. There is a known issue on some EM cards with faulty whip antenna/connector which cause ~40 dBm at 1 m, compared to ~20 dBm. We tested 5-6 cards at our office, and we found one with this issue - all ordered directly from TI. Please see: https://e2e.ti.com/support/wireless_connectivity/low_power_rf_tools/f/155/p/474018/1815817

    YK: Do you mind sharing the rationale behind the value 0x9C? I also got hints to tweak this value, but not sure how to decide which value...(trial and error?)

    Andreas

  • 0x9C is two's complement of -100 dbm.
  • Wow - very interesting link, thank you!! Looks like there could be some fundamental issue in TIs drivers.
    Could someone from TI offer some input??

    FYI I am using the CC1310 launchpad with onboard PCB antenna, perhaps there is also some inherent issue with the layout of these boards.
  • We saw that the PCB antennas are very sensitive to direction/polarity (only tested EM cards). Have you tried tilt,yaw,roll 90 degrees around?

    YK: Yes, but I was wondering why 100 and not 95, or 105 or 110? Any empirical or analytical reasoning one can apply?

    Andreas

  • For some reason I did not get a notification on my previous post (assuming no one else did either), so I will blatantly post again so everyone involved gets a notif. :)

  • Hello,

    Can someone in this thread confirm that you have done tests with nullrdc driver, not only ContikiMAC?

    Sorry for the lack of reply. I will summarize all the finding you guys (and others) have made and:

    -push an update to contiki, using new cc13xx/cc26xxwares, this will include new RF settings.
    -look into the prop-mode RF driver logic (the RSSI issue)
    -look into if the ContikiMAC driver logic can be changed to not look at the RSSI before entering RX.

    We estimate to have a PR (or more) ready for Contiki toward the end of June.

    We are also looking into the bad antenna (hardware) issue.

    Jonas
  • 2) the PER test shipped is using 12.5dBm output power.
  • Hi, and thanks for the reply. All our tests were made using ContikiMAC.

    Andreas