[Zooper Widget General] Scotty1:
Zooper has problems calculating dBm & ASU on LTE (4G)

I have the same problem as the OP, and others on the thread. I have already posted about it on the Zooper G+ forum, and on the Zooper support site, to no (apparent) avail.

Using Zooper Pro v245010b on a Verizon CDMA Galaxy Nexus running KitKat (4.4.2 rooted, Shiny ROM, which is very close to the stock ROM). I'm having three problems with the cell signal information (NCSIGN) when I'm in an area with a 4G / LTE connection.

1. Zooper reports NCSIGN as a negative integer when on 3G / eH; but as a positive integer on 4G / LTE. The OP seems to have seen the same thing (positive dBm on 4G) on Sprint. This means that (for example) to get the dBm to display as the negative integer regardless of connection type, I can't just tell it to display #NCSIGN #, I have to tell Zooper "if I'm on LTE, precede the dBm value with a negative sign". This is easy enough, using $#NCONNS#=4G?-#NCSIGN#:#NCSIGN# . So, if that was the only problem, it would be trivial, and barely worth reporting, but I think it may reflect a deeper issue with Zooper & LTE......

2. The central problem is that (at least for me, and some other users) Zooper does not report the absolute value of NCSIGN correctly on 4G / LTE. The reported value does change from time to time, but it's not the correct value. See the attached file with 2 images, captured within a few seconds of each other when I was in an area with a very strong & stable LTE connection.

The top image shows the phone info screen. The yellow arrows indicate (from the bottom up) that I'm connected on LTE, with a dBm of -68, and an ASU of 72. Note that the dBm value (-68) is taken from the value "rsrp" value shown on the line "CellSignalStrengthLte". -68 is quite a strong signal, as confirmed by the 4 bars of connection shown in the status bar.

The bottom image shows my Zooper widget. It shows (correctly) that I am on LTE. however, the dBm is incorrect, showing 85 (the "-" sign comes from the display code I've provided in point 1 above). Because the reported dBm (as a negative integer, i.e., -85) is much weaker than the real dBm (-68), the indicated percentage signal, and the signal bar strength, are lower than they should be - but that's not a real issue; they're wrong because Zooper is delivering an incorrect value for NCSIGN under an LTE connection. If this dBm is fixed, the progress bar & percentages will be fine, too.

3. There's another problem, separate from the above. ASU (NCSIG) doesn't work properly for Zooper when you're on LTE. As you see from the images, my ASU was 72.... but Zooper's cutoff max ASU is 31. Anything above that is displayed, by Zooper, as "99" - which, I think, means "ASU value unknown". ﻿I believe the problem is that ASU is calculated differently depending on whether you're on 3G or LTE. Under 3G, the calculation is ASU = (RSSI + 113) / 2. Max value is 31. Zooper does this OK. But under LTE, ASU is calculated as follows: ASU = RSRP + 140. And under LTE, the max is around 97. So, looking again at the attache image, my RSRP is -68. Add 140, bingo, my ASU is 72.

Bottom line: I think that Zooper needs two tweaks in order to report correctly under LTE. Under LTE, (1) Zooper should use the RSRP data (NOT RSSI) to define #NCSIGN# (i.e., dBm, reported as a

negative

integer); and (2) to correctly calculate the value of #NCSIG# (ASU), Zooper should use the LTE-specific equation (ASU = RSRP + 140).﻿ Note that the second item (the ASU calculation) is less important to me, because it's easy to customize Zooper code to display the correct ASU, so long as Zooper is providing the correct input value for #NCSIGN#. But without the correct dBm value under LTE, we're stuck.