CC1310: trouble in distance coverage compared the 15.4 stack vs the SimplyLink stack

Hi Dirk,

Which version of the SDK are you using? 

Thanks, 
Elin

Hi Elin,

we are using SimpleLink CC13x0 SDK v1.50.0.08

Besides I cannot add team members of mine to add here for whatever reason. Seems I have no rights in this forum. Can you please grant me access to add a team member of mine ?

Hi Dirk, 

Can you update to the latest version of the SDK and test if you see the same issue? 

In what capacity do you want to add your team member? Everyone that has an account on E2E can go in and comment on the open threads. 

Thanks, 
Elin

Dear Elin,

We worked on 2 SimpleLink libraries on both our product and CC1310 LunchPads:

1. SimpleLink 4.10.01.01

2 SimpleLink 1.15.00.08

We tried both on 915Mhz, 14dBm, 50kpbs, and using sensor and collector examples.

CONFIG_SECURE is true

CONFIG_FH_ENABLE is true

Our question is, the RSSI seems to stop at -80dBm, once we go a bit farther away, the pair is lost.

The TI documents said that @50kbps RSSI can down to -1110dBm.

We tried the rfPacketErrorRate Example also, the RSSI can go down to -10x dBm, which is more likely close to what TI documents have mentioned.

Seems to us using 15.4 Stack makes less sensitivity on the RF, the RSSI only can go down to -80dBm.

Thanks,

Larry

Hi Larry, 

Thanks for sharing. 

Are you able to migrate to the latest version of the SDK (4.30) and see if you can reproduce the issue?

You should be able to see lower RSSI values when than -80dBm using the TI15.4 stack. Do you see this issue when running the default examples from the SDK too? 

Thanks, 
Elin

Dear Elin,

We are using CC13x0 SDK 4.10.01.01 (below picture) on both CC1310 LunchPad and our hardware. We did some range tests using 2 CC1310 LunchPad. The result we got on 15.4 Stack's Example (Sensors and Collector) was somewhere between 150-200 meters and the lowest RSSI I can get is around -8x dBm. Once we walk some more distance away the connection lost and can not get it to pair again. However, on SimpleLink 2-GFSK or Long-range mode don't have the problem, the lowest RSSI I can see in Long-range mode was -10x dBm and the distance can up to 400-500 meter away. (note that, we use rfPacketErrorRate to test 2-GFSK and Long-range mode.)

Thank you

Larry

Hi Larry, 

Have you made any modifications to the sensor and collector projects?
1. If no: can you upgrade to the latest SDK and see if you can reproduce the issue? 
2. If yes: can you test with the default projects from the SDK and test if you see the same issue? 

Thanks, 
Elin

Elin, according to the screenshot above the 4.10 is the latest online available.

Best

Dirk

Dear Elin,

As I saw in IDE, 4.10.01.01 is the latest SDK. I did not make any modifications on the sensor and collector project besides putting debug to show RSSI.

Thanks,

Larry

Hi Elin, can you respond to the raised problem of SDK availability ?

Thanks

Dirk

Hi Larry, 

Yes sorry, I forgot that it was the latest as the CC13x2/CC26x2 SDK is on version 4.30.

Thanks for sharing. I'll see if I can reproduce the same issue here and debug to find the cause. Do you see this issue on all the Launchpad demo boards or just a couple? 

Thanks, 
Elin

Dear Elin,

I only have 2 CC1310 LaunchPad, we tested on the rfPacketErrorRate examples, it works pretty well. But once I use Sensor and Collector Examples, RSSI below -80, will be hard to pair up and lose connection.

Thanks,

Larry

Hi Larry,

Perfect, thanks for letting me know. I'll try and reproduce the issue here at the office. I'll keep you updated on the progress. 

Thanks, 
Elin

Dear Elin,

any update on your 15.4 Stack and SimpleLink test?

Thank you,

Larry

Hi Larry, 

No update yet but I'll perform the tests later this week. 

Thanks, 
Elin

Hi Elin,

can you please focus on precisely replicate our issues and finalise by this week to at least bring us to the same level of facing facts. 

As we are about in newly large production runs shortly require input in wether hold off or get a approve for resolved.

Best

Dirk

Hi Dirk, 

I understand the urgency of the situation. Unfortunately, I haven't been able to test because I haven't had access to the proper HW, which I will have later this week. 

Thanks, 
Elin

Thanks Elin. Please keep us posted.

We continued the tests and our results are quite alarming given the fact we also swapped hardware around to exclude electrical issues. 

Dear Elin,

Any update for your test?

Thank you,

Larry

Hi Larry, 

Apologies, I thought I send an update on this on Friday. Thanks for the reminder. 

I did some testing at the office but I wasn't able to reach that low RSSI values at the office, unfortunately. So I'm couldn't reproduce the issue. I have checked in the stack and there shouldn't be any RSSI limit there. Have you measured the noise floor of your environment? 

Thanks, 
Elin

Another question; are you using the same PHYs on both ends? 

Thanks, 
Elin

Dear Elin,

Yes, both are using the same PHY. and the rf noise floor should not be too bad in our office.

Moreover, I have been tested on both my home and office and I not getting any difference in RSSI. 

Thank you,

Larry

Hi Larry, 

Thanks for sharing. 

By any difference in RSSI, do you mean that the RSSI value you are seeing is static or the original issue that it's not going below -80?

Thanks, 
Elin 

Dear Elin,

Happy new year, and wish you have a happy holiday.

The RSSI is different every time the data pass through the RF. The lowest RSSI we saw was -80 something (around -84- -86), once we see this value, the connection becomes unstable. but in the rfPacketErrorRate example, we see some spots receiving data at around -9x to -100 dBm very stable.

Thank you,

Larry

Hi Larry, 

Happy new year to you too Larry!

Thanks for clarifying. I just want to reiterate that it sounds very strange that the TI 15.4 examples only work down to ~-85 dBm as there is no limitation in the stack. I'll look into this again and get back to you later this week. 

Thanks,
Elin

Dear Elin,

Any update on your side?

Thank you,

Larry

Hi Larry, 

Unfortunately I haven't been able to reproduce this issue. I'll keep you updated. 

Thanks, 
Elin 

Hi Larry, 

Apologies for the delay. 

Have you tried using another PHY and data rate? What do you see then? 

Thanks, 
Elin