EG91 QCOPS/QENG commands return negative numbers


We’re adding support to Ofono for various measures of signal strength other than vanilla RSSI.

Having spoken with the support team we’re using QCOPS and QENG commands for this purpose.

We are seeing a problem as these commands seem to return negative numbers, we assume in dBm.

The position of the Ofono team lead is,

"AT commands do not have a concept of negative numbers. v.250 Section 5.3.1:
may be a string of one or more characters from “0” through “9” representing a decimal
integer value. Commands that expect a are noted in the description of the command (see
clause 6).

I don’t recall any other vendor using negative values in AT commands. "

Can you please clarify if these commands are standards compliant, and if not whether whey can be made standards compliant?

Can you also please clarify the range on these returned values. i.e are they ALWAYS 0 or negative? If so a “hack” may be for me to reverse the sign.

This is more of a problem than it seems as right through Ofono it expects positive values and uses negative values for errors and so forth.




Hello ajlennon, thanks for your question on quectel forums.
QCOPS and QENG command show the RSSI、RSRP and SINR value of the network, this is in accordance with the 3GPP TS regulations, so it is normal for negative numbers to be displayed.image

This is very helpful Duncan. I will pass this back to the Ofono team!

Duncan I received this response from the Ofono lead.

He makes the point that in the image you provide what should be sent as the AT command response is on the left i.e. 0 … 97. NOT the negative numbers. This is as for CSQ.

i.e. he writes,

"So the image shows the value for

‘0’ if -140 dbm

‘95’ if dbm is -46 to -45

(what is actually sent over AT commands) is never negative. Isn’t the image supporting my earlier assertion: ‘AT commands do not have a concept of negative numbers’?

oFono exposes the value from 3GPP:

"byte ReferenceSignalReceivedPower [optional, lte]

    Contains the Reference Signal Received Power.  Valid range of values
    is 0-97. Refer to <rsrp> in 27.007, Section 8.69 for more details. "

Can you comment please?

Hi ajlennon:
For more information, see the 3GPP documentation in the link

Herbert this also seems to confirm (again) that your implementation is not in accordance with the image you provide or the spec you link to.

Is that your intention?



You SHOULD be providing the numbers on the left hand side of your image.

You ARE providing the numbers on the right hand side of your image.

This is incorrect I believe?

Hi ajlennon:
As you can see from the screenshot or protocol documentation above, it is reasonable for the specification to use the corresponding positive value instead of the range of actual signal measurement units (such as RSRP, RSRQ, RSSI);When you query and output the corresponding positive value of the signal measurement unit, you can use the corresponding conversion or find the actual value of the corresponding signal measurement unit.I suggest you download the 3GPP documentation in the above link. You may have a better understanding of the question you are asking.

I am not seeing what you suggest at all.

I am looking at 3GPP TS 36.133 V17.2.0 (2021-06)


It’s clear there is a measured value for a range and a reported value.

There is nothing here to suggest to me this statement is true

“When you query and output the corresponding positive value of the signal measurement unit, you can use the corresponding conversion or find the actual value of the corresponding signal measurement unit.”

Why do you think you can report the measured value instead of the mandated reported value?

I could be persuaded that RSRP_-17 should be read as the number -17 but I really want to see that stated somewhere…

Hi ajlennon:
Reported value main purpose is to correspond to another parameter in LTE (rxlev):
RSRP_00 = rxlev_0

OK I wanted to help support Quectel and improve the support for Quectel modems in Ofono.

However there appears to be no middle ground here.

Ofono say you can’t use negative numbers due to the spec.

You say it’s fine.

I don’t have time to be the middle-man between you so the code I am working on won’t be contributed upstream

Which is a shame.

Thanks anyway,


Hi ajlennon:
I’m sorry for causing you so much confusion!
If Ofono’s customers think that the non-negative parameter is CSQ, yes, but CSQ is not the actual measurement unit, its corresponding measurement unit is RSSI.
RSSI (dB) = -113 + CSQ *2 //CSQ is the actual query value according to AT+CSQ
For other measurement units, refer to 3GPP27.001, which is the 3GPP specification AT command!

Hi @herbert.pan-Q - this is the point. CSQ returns positive numbers which must be translated into RSSI (db) precisely because you should not be returning negative number (The ofono team are adamant about this and I think they are probably right)