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.
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
etc.
(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’?
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.
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?
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! https://www.3gpp.org/ftp/Specs/archive/27_series/27.007/
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)