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: Disastrous transceiver performance of sensor/collector network

Part Number: LAUNCHXL-CC1310
Other Parts Discussed in Thread: CC1310

Hey guys,

we currently have 29 sensor nodes (TIDA 00489 design) and one CC1310 launchpad as collector connected to a raspberry pi. We use the sensor collector example based on the SDK 2.4.

Each 5 mins, the sensors send their data, a 2 byte long integer, to the collector. The collector receives the data and prints it to UART so the Raspi can read it. Additionally, we have a sniffer installed checking the whole traffic. The sniffer is lying directly next to the collector. Note, that the maximum number of retries if a message was not acknowledged by the collector is 3.

Setup 1: The sensors are on a table, the collector is lying on the floor with a distant of 3m to the sensors in an office room.

Setup 2: The Collector is lying on a table next to the sensors, approx. 1m distance.

Setup 3: The sensors are placed in another room so they have to pass 3 walls (approx. 25m of total distance)

Observations:

  • Setup 1: The data send of several sensors is not acknowledged by the collector even after 3 retries of the sensor, no acknowledge from the collector. Sometimes the second or the third try of the sensors is acknowledged.
  • Setup 2: Approximately 90% of the data is acknowledged immediately by the collector. The other 10% after the second or third retry.
  • Setup 3: A few sensors still get acknowledged all the time, most of the others are not acknowledged anymore.

For all setups, the RSSI value measured by the sniffer is not a criteria if the collector acknowledges the message or not. For setup 1 and 2 its -40 to -60 dbm, for setup 3 its around -80 to -90dbm. Sometimes messages with slightly lower RSSI get acknowledged and others not.

Questions:

What could be the reason, that some sensors are have bad acknowledgement rates compared to others, when the distance is increased? (all suggestions welcome)

And why are there performance issues even if the sensors are only 1m away and why is that so randomly?

Kind regards

Slev1n

  • Have you check the RF performance on your board according to http://www.ti.com/lit/an/swra603/swra603.pdf ?

  • Thank you for this document it is very interesting.

    However, the hardware design was followed strictly using the TIDA 00489 documentation regarding the antenna. And this http://www.ti.com/lit/an/swra479a/swra479a.pdf (page 10) document states, that at 50kbps -110dbm sensitivity is the limit at the receiver. The sniffer being directly next to the collector has way higher RSSI values (minus 40-90dbm).

    Is using the sniffer sufficient to pass test 4 of your link since we do not have a spectrum analyzer?

    Do you think an external antenna would help here or is the RSSI quality good enough and there is another issue?!

    kind regards

    Slev1n

  • The app note suggests measuring methods also for those who does not have access to a spectrum.

    You should simplify first, in other words just look at a CW first, then packetRx/ packetTx and when that works you can look at the full stack.

  • Hey TER,

    i did perform several tests over the weekend using SmartRF Studio 7. I confirmed, that the sensitivity of the collector currently connected to the Raspi has the same performance as the other collector launchpads we have. I made an infinite Packet TX and Packet RX test and 1000 messages did not show one drop and the RSSI was constantly at -41dBm for both tested collector boards. I used the same transmission mode (50kbps - IEEE). I did then make a test with a TIDA 00489 board as transmitter and a collector launchpad as receiver. Again everything worked perfectly until we decreased the amount of obstacles between receiver and transmitter and the RSSI dropped below -90dBm like expected. Around -100dBm the first packet losses were detected with the normal mode. With the long range mode with 5kbps the perfomance was increased again.

    So far everything as expected. To sum it up, the TIDA board as transmitter and the launchpads as receiver work perfectly and as expected using smart rf studio.

    But if approx. 25 sensors are connected with the launchpad using the sensor/collector software the collector occasionally does not acknowledge sensor messages more or less randomly. I have attached a sniffer sequence where the sniffer was lying directly next to the collector launchpad. (EDIT: I cannot attach a pcapng extension file, in which format do you want me to send the wireshark content to you?)

    I assume it has something to do with the stack. Any idea why the collector does not acknowledge the messages although the RSSI is fine?

    If you need my ccs project to check write me a PN.

    I am thankfull for all suggestions because we are totally stuck and cannot use such a system

    kind regards

    Slev1n

  • Hello Slev1n,

    What PHY are you using?

    In what mode are you operating the network, FH, BEacon, or non beacon?

    What is your reporting interval for your sensors?

    What is the poll interval?

    Regards,

    AB

  • Hey AB,

    AB said:
    What PHY are you using?

    I use APIMAC_STD_ETSI_863_PHY_3 Channel 13

    AB said:
    In what mode are you operating the network, FH, BEacon, or non beacon?

    non-beacon

    AB said:
    What is your reporting interval for your sensors?

    5 mins

    AB said:
    What is the poll interval?

    1 hour (tracking delay is set to 3 hours)

    kind regards

    Slev1n

  • Hello,

    I would Increase the retries to 5 and see if this improves the behavior.

    Part of why the collector might not see the message, might be because it may be transmitting an Ack when the message is sent. The sensors only do LBT when in the ETSI band, and this might cause more failed message attempts. 

    Try increasing  CONFIG_MAX_DATA_FAILURES also, and test again. Let me know if it improves the results.

    Also, have you taken a look at the channel spectrum to make sure that channel is not too crowded

    Regards,

    AB

  • Hey AB,

    If I understand you correctly, the collector wants to acknowledge a sensor message, but while the collector makes LBT before acknowledging the received message, the sensor is sending again. But I think the fourth try should get an acknowledge then?!

    However, I will increase the retry number. I guess this is still within ETSI conformity, as long as the 1 hour occupation is not exceeded? Just costs a little bit more energy.

    The max data failures value is currently at 2, because we are changing the collector pretty often and during test phase with customers it is annoying if we have to wait too long until the sensor disconnects after trying two times. Interestingly, if a polling message is not acknowledged the sensor directly disconnects. This disconnecting and rejoining is no problem as long as the short addresses are not overflowing at the collector, which I guess has been fixed within the last SDK.

    Regarding the channel occupation by external sources, we sometimes see some alien messages in the sniffer on certain channels but they are very rare. And using smart RF Studio continuous RX we usually see -110dBm noise floor without any peaks, although the longest time I measured was only 10mins.

    Kind regards

    Slev1n

  • One more question, is it possible to increase the waiting delay for the acknowledge before it retries to send the message? This could solve the LBT issue preventing the acknowledging as well.

    And external traffic on this channel does not seem logical to me to cause the "not acknowledging" because than, I would see something in the sniffer and the sensor would not send at all, right?

  • Update: Changing the retries improved the performance slightly, however missing ACKs still appear in an unperiodic manner.

    What would you say, is the realsitic or expectable acknowledge rate for a non-beacon network with ETSI PHY, a reporting and polling interval of 1h (I've increased this) and approximately 30-50 sensor nodes (Using SDK 3)? Is close to 100% realistic in an application environment like on a big farm assuming only 1 collector with 50 sensors is present and of course possible other devices with RF? I would like to have a better estimation what we can expect from our system and I guess you guys have much more experience.

    For a better understanding, could you name me reasons why the collector is not acknowledging a message. Assuming the sensor is in a working network with the collector and the quality of the messages send from sensor to collector (RSSI value) is definately good enough?

    E.g. LBT and what else?

    Thank you for the good support.

  • Hello Slev1n,

    I would expect close to 100%.

    Something that could affect this is Cellular band (if you are in the US), and noise.

    Regards,

    AB

  • In our test field we've changed the code using Long Range Mode, 14dBm and an external antenna for our collector board.

    Without the antenna we are not able to build a network at all. But with the antenna, we have 97.84% transmission at first try (however retries have been set to 5, so I can not distinguish between first try and 6th try for one transmission). Which is good enough, since the rest of the data is send later.