7 months, 3 weeks ago.

RSSI calculation in UbloxCellularBase


We are using the RSSI function in UbloxCellularBase to measure signal quality on our custom board with a Ublox SARA-U201 modem. The performance of the signal/antenna seems very poor and we have investigated the electronics and couldn't find anything. (We've been consulting Ublox with the electronic research).

We have investigated our board with 3 different antennas with a dedicated test program measuring the RSSI signal. The test program is very simpel taking the RSSI value from the UbloxCellularBase and printing it to the log. We also run the tests on a Ublox C030-U201 development board. In all cases the RSSI is very poor. We also measured the RSSI with other 3G/UMTS equipment giving much better RSSI result.

I researched the Ublox AT manual and the UbloxCellularBase and I think there is a problem with the RSSI calculation.

According to the Ublox AT Manual the RSSI is calculated with this formula:

RSCP (dBm) = RSSI (dBm) - EC_NO_LEV (dB)

Looking into the library it seems the EC_NO_LEVEL is used. This is a level/index and not a (DB) value as specified by 3GPP. See the table below. I think this is wrong.

I have changed the conversion table in the library to use these interpolated values based on the 3GPP Ec/Io levels in the table below.:

const int qualConvert3G[] = {1, 4, 7, 10, 13, 16, 19, 22};

This is the best interpolation I could figure out (but considering if the numbers should be negative).

The RSSI result now looks more aligned with our expectations.

I also questions the RSSI calculation formula in the Ublox AT command manual. In other documents I find the formula expressed as:

RSSI (dBm) = RSCP (dBm) - EC_NO_LEV (dB)

Looks like this is also the formula used in the UbloxCellularBase library.

Can you confirm that there is a problem with the RSSI calculation in the library or am I misunderstanding something ?

3GPP EC_NO levels and values in UMTS RAT:


Table is from

Question relating to:

Development team for u-blox positioning and wireless products

Thanks again for the ticket a fix has been added and changeset hash is 93b157a47b8d. Are you getting expected results now ?

posted by fahim alavi 12 Jul 2018

Have tested it and compared with my own corrections. RSSI with my own corrections is in then band 70-80 and with this new change it is now in the band 65-70. This is almost too good.

I notice the qualConvert3G table has negative values. Guess this means according to the formula that the more noise the better RSSI. Hard for me to find the logic in this but I am not an expert in this field :-)

Wonder if the absolute dB value should be used in the formula ?

Thanks for fixing !

posted by Jens-Ole Graulund 12 Jul 2018

If I understand your question correctly; if quality is not good then RSCP will be lower too hence low RSSI.

posted by fahim alavi 12 Jul 2018

An example. Lets say we have these CSQ responses and apply the conversions table and formula:

CSQ response: 17,1 -> RSSI: -73 - (-4) = -69 CSQ response: 17,6 -> RSSI: -73 - (-10) = -63

I consider qual 6 as high noise/interference level, but the calculated RSSI -63 is a better signal than -69 which have a lower noise/interference level but same RSCP.

If you take the absolute value of the EC-NO-LEVEL it would be more as I expected.

CSQ response: 17,1 -> RSSI: -73 - 4 = -77 CSQ response: 17,6 -> RSSI: -73 - 10 = -83

The AT manual could be more precise regarding what is the interpretation of the formula:

RSSI (dBm) = RSCP (dBm) - EC_NO_LEV (dB)

posted by Jens-Ole Graulund 12 Jul 2018

If signal quality is low then RSCP will be low. These are not independent values i.e. you degrading quality in above examples but keeping RSCP value constant. For example if I use absolute value and CSQ response is 2, 7. RSSI = -106 - 22 = -128 dBm (That is no signal)

posted by fahim alavi 12 Jul 2018

OK thanks - Just glad I get those excellent signal values now

posted by Jens-Ole Graulund 12 Jul 2018
Comment on this question

1 Answer

7 months, 2 weeks ago.

Hi, and apologies for the delay in replying. This is quite a confusing subject so I'm going to go consult the R&D guys who know what they are talking about. I will get back to you...

Having consulted with R&D you are correct on all counts: my mistake in coding the driver was that I didn't realised the EC_NO_LEVEL was yet another index that needed translating into dB, the mistake in the AT manual (which will be corrected in the next release) was in the formula: the correct formula is indeed RSSI = RSCP – EC_NO_LEV. We will make the necessary changes in the driver; thanks very much for spotting this and letting us know.

posted by Rob Meades 10 Jul 2018

This is great. We appreciate your quick and solid response as always. No need to apologize.

posted by Jens-Ole Graulund 10 Jul 2018

Assigned to Phil Ware 7 months, 2 weeks ago.

This means that the question has been accepted and is being worked on.

To post an answer, please log in.