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