Boron LTE and Cellular.RSSI() - funny values


#1

According to the documentation I can find, Cellular.RSSI().rssi values should be in the range of -113 to -51. I’m getting values in the range from 43 to 46. My .qual values are around 18 to 20, so within the documented range of 0 to 49.


#2

Boron LTE or 3G/2G?

The exact model will be useful :slight_smile:


#3

Good point. It’s the Boron LTE


#4

Not sure… but mine shows up fine!

unsigned long old_time = 0;

void loop() {
  if (millis() - old_time > 10000) {
    CellularSignal sig = Cellular.RSSI();
    
    Particle.publish("CS", String(sig), PRIVATE);
    
    old_time = millis();
  }
}

#5

What are some typical values that you get for the CS sig value?


#6

I’m getting the same issues with odd signal values. I’m getting RSSI values around 30-40 (which isn’t in the documented -113dBm to -51dBm range), and quality of around 10 (which is a lot lower than a SIMComm module on the same antenna).

It is running an external SIM from Telstra in Australia, and running rc.25. Cellular is working, as it’s the only connectivity the module has, but is having stability issues.


#7

Same issue for me on Boron LTE, I get 44 and 22 for both RSSI value as an example.


Boron LTE now support in Canada?
#8

I have confirmed that we have an issue with Electron-compatible RSSI / quality calculation on Borons, which we’ll fix in the next release, however going forward we’ll be migrating to using the new (and currently undocumented) API that provides information on the current radio access technology (RAT) as well as RAT-specific strength/quality parameters along with percentages: https://github.com/particle-iot/firmware/blob/mesh-develop/wiring/inc/spark_wiring_cellular_printable.h#L48. I can suggest using it as a workaround on Borons to get more sensible strength and quality values for now.

getAccessTechnology() returns one of the following values:

    NET_ACCESS_TECHNOLOGY_UNKNOWN = 0,
    NET_ACCESS_TECHNOLOGY_NONE = 0,
    NET_ACCESS_TECHNOLOGY_WIFI = 1,
    NET_ACCESS_TECHNOLOGY_GSM = 2,
    NET_ACCESS_TECHNOLOGY_EDGE = 3,
    NET_ACCESS_TECHNOLOGY_UMTS = 4,,
    NET_ACCESS_TECHNOLOGY_CDMA = 5,
    NET_ACCESS_TECHNOLOGY_LTE = 6,
    NET_ACCESS_TECHNOLOGY_IEEE802154 = 7

For each RAT getStrengthValue() and getQualityValue() return RAT-specific strength and quality parameters, whereas getStrength() and getQuality() will return the percentage based on minimum and maximum values (0% - 100%).

GSM

Strength: RSSI (dBm) [-111, -48], see 3GPP TS 45.008 8.1.4
Quality: BER (Bit Error Rate) (%) [0.14%, 18.10%], see 3GPP TS 45.008 8.2.4

EDGE

Strength: RSSI (dBm) [-111, -48], see 3GPP TS 45.008 8.1.4
Quality: log10(Mean BEP) (Bit Error Probability) [-0.6, -3.6] (QPSK table), see 3GPP TS 45.008 10.2.3.3

UMTS (3G)

Strength: RSCP (dBm) [-121, -25], see 3GPP TS 25.133 9.1.1.3
Quality: Ec/Io (dB) [-24.5, 0], see 3GPP TS 25.133 9.1.2.3

LTE

Strength: RSRP (dBm) [-141, -44], see 3GPP TS 36.133 subclause 9.1.4
Quality: RSRQ (dB) [-19.5, -3], see 3GPP TS 36.133 subclause 9.1.7

(cc @rickkas7)


Higher Gain Antenna Options for a Fixed Location With Poor Reception
#9

@avtolstoy, thanks for the note, but I’m not quite clear on what you mean by “use it as a workaround on Boron for now.”

getAccessTechnology() is not defined on my Boron. Do mean that it should be available now automatically? Or available now if I do something special (like include a library)? Or is it something that is not yet available, but will be coming in the future? Thanks.


#10

It should be available. It is a method of CellularSignal class.

CellularSignal s = Cellular.RSSI();

auto rat = s.getAccessTechnology();

float strengthVal = s.getStrengthValue();
float strengthPercentage = s.getStrength();

float qualityVal = s.getQualityValue();
float qualityPercentage = s.getQuality();

Boron Cellular Signal
#11

@avtolstoy,

While I value compatibility with the 2G devices, this is a significant improvement over what we had before. I have tested this approach in my own applications and am very happy with this change. I would only suggest updating the Bottom reference documentation to reflect this new approach.

Thank you!

Chip


#12

@avtolstoy,

I am getting a “rat” value of 8 from this code for my Boron LTE. Is this correct? Can you please provide the correct rat values or point me to the repo?

Thanks,

Chip


#13

@chipmc We should really update the docs :sweat:

It’s LTE Cat M1: https://github.com/particle-iot/device-os/blob/develop/hal/inc/net_hal.h#L52


#14

@avtolstoy,

Figured as much, thank you!

Chip


#15

@chipmc are you setting the network band at all? My RAT is actually coming back as = 6. Which is just LTE not CAT_M1 ??


#16

@ric_hard,

No, I am not setting the network band. Running deviceOS@1.3.1 if that helps.

Would seem that all the Particle devices should be CAT_M1 or CAT_NB1 as I don’t think they use plain old LTE.

Chip


#17

@chipmc appears they do when you change the modem settings…

Aldo do you mind telling me what you have in these fields? I have some Boron’s with 6 and some with 8.

lte2

Thanks


#18

@ric_hard,

Interesting. Here is what I see on my console - the “at” value is 8 - just like yours.

42%20PM 44%20AM

So it seems that the only issue was updating the definitions of the “at” values:

const char* radioTech[10] = {"Unknown","None","WiFi","GSM","UMTS","CDMA","LTE","IEEE802154","LTE_CAT_M1","LTE_CAT_NB1"};
  

This seems to work for me. but not sure why the “LTE” value is needed.

Chip