[LG V10 General] Brobro1:
VARIABLE_WAS_NOT_ACTIVE issue

Hey folks!

I run a cellphone repair service, and I'm really busy these days, so that's why I'm not at all active on here nowadays.

I was debating with myself about whether I should post my thoughts on the whole VARIABLE_WAS_NOT_ACTIVE issue here or not, because I have not pedantically investigated it yet, and I hate contributing with half-baked posts.

In the end, mainly because of repeated community requests, I decided to post my preliminary findings.

Hello Tickertapes,

your phone's strange dual sim behavior with regard to signal loss is symptomatic of DFS misflashing your device, which could have happened for various reasons, some of which I have discovered, some not (I'm still documenting these reasons and preexisting conditions); the behavior you described in the quoted post is something that I have already seen before in praxis, twice; and I've got bad news for you, I guess, as I was unable to fix it in either of the cases, not even by reverting the LTE BC Config LTE #6828 back to stock values. One client of mine insisted to reflash their device's band settings back to stock values again, unroot, and RMA their device, so I did just that, but the claim got denied on the grounds of unauthorized software modification. LG fixed it for a relatively high price (compared to the retail price of a brand new product), and it's working now, as it should. I'm not totally sure what they did to repair the device, to be honest, but I have a strong suspicion that they replaced the radios, and I'm basing this speculation on the fact that while formerly, the device's WiFi chip's manufacturer was identified as "Lg electronics (mobile communications)", the repaired device's WiFi chip's manufacturer was identified as "Shanghai dareglobal technologies co., ltd". I'm almost 100% sure that the returned device was the same device that was shipped for RMA (ship of Theseus?), because it had the same blemishes on its "Dura Guard" frame and on the top part of the plastic front-facing bezel; in addition, the device had signs of its display being removed for disassembly purposes.

I figure that this rabbit hole goes much deeper than this, though: I've had the pleasure to somewhat intimately deal with over a dozen of these devices (both H961N and H962), and I've identified at least three different "versions" of their radios, some of them (if I recollect correctly, they were all the first iteration of the smartphone that shipped with the V10a ROM version) could have their band settings flashed with DFS with little problems (including the LTE BC Config LTE DIV #6829 with no VARIABLE_WAS_NOT_ACTIVE issues, although l still had to do step 10 of my guide:

which I thought was a very weird thing to do: i. e., re-flashing the stock CDMA/GSM/HSDPA band settings without modifying them at all: it just didn't make much sense to me, really, but there you go! If I didn't do step 10, I'd get strange behavior: for example, the phone would flip out and constantly change 2G/3G icons like once every five seconds or so, even when the device was positioned in direct line of sight of the carrier's 3G transceiver. First time I saw this flip-out behavior [when I didn't do step 10)], I thought the device was toast and that it was a good thing that I had had my client sign a disclaimer), but some others ran into the VARIABLE_WAS_NOT_ACTIVE issue: that basically meant, in those cases, that the pertinent NV items were write-protected.

Let's say I hypothetically used a certain hypothetical custom tool to hypothetically force-flash the desired hex values into the device's appropriate NVM segments and it hypothetically worked fine the first time around; however, when I hypothetically did it off-the-cut to another device of the same breed (H961N), but which was newer according to its date of manufacture, thinking that I already had done my homework on it, since they are, or should be, basically the same devices, after all, my hypothetical tool hypothetically errored out, hypothetically claiming address space violation: thankfully, the hypothetical tool hypothetically caught the exception and didn't crash, because who knows what would have happened if it did hypothetically crash (worst case scenario: it would have rewritten some other [possibly the next accessible, maybe the first ever accessible, or even some "random"] NVM segments, likely hard-bricking the device in the process); however, the end result of this particular hypothetical case was thankfully the same as when I formerly ran into the VARIABLE_WAS_NOT_ACTIVE issue within DFS, meaning one of these VARIABLE_WAS_NOT_ACTIVE cases was hypothetically fixed to client's full satisfaction, whereas the other one could not be fixed, even hypothetically, but the device still worked relatively fine, sort of.

Devices that were unable to have their LTE BC Config DIV LTE #6829 flashed have exhibited all sorts of problematic behavior, mainly centered around connectivity dropouts, phone freeze-outs, etc., and

were not fixable by me,

but one of them ended up being fully repaired by the manufacturer.

What does this all mean?

I'm not too sure, to be honest, but if I had to guess, I'd say that LG uses several different radios for the same device which meet the required specifications (e. g., band compatibility) that LG guarantees; some of these radios one could squeeze more out of, while others are more limited in what they can do; with this, a desktop CPU analogy comes to mind: highest quality CPUs that withstand the highest clocks in a stable state bear the "most powerful" model number, while those CPUs that failed the most demanding tests get their model number "downgraded", and those CPUs that are grossly underperforming, have a few cores damaged, and are generally unstable in any but the very lowest clocks get downclocked, get their defunct cores disabled, and get to be labelled budget CPUs: all of these CPUs could conceivably come from the same crystalline silicon substrate. Here's the catch: If the CPU manufacturer expects to produce 5% tier 1 CPUs, 5% tier 2 CPU, 10% tier 3 CPUs, 20% tier 4 CPUs, and 60% tier 5 CPUs but actually produces 5% tier 1 CPUs, 5% tier 2 CPU, 15% tier 3 CPUs, 15% tier 4 CPUs, and 60% tier 5 CPUs, they often "unnecessarily" downgrade, in this particular exemplified case, the 25% of their tier 3 CPUs to tier 4 CPUs, in order to meet their sales targets and save face. If one goes out to buy a tier 4 CPU and gets lucky, they might actually purchase one of the downgraded tier 3 CPUs and be able to unlock it to its "full" tier 3 potential. I suspect something similar is going on here, where they over at LG have a big metaphorical box of radios in which you can find many compatible makes of said radios, which get mounted on the LG V10 motherboard on a semi-random basis: this approach would have the advantage of LG not having to rely on a single supplier for their components that can be freely interchanged among themselves within LG's guaranteed specifications!

To confirm my suspicions, however, I would have to teardown several of these smartphones, and I'm not very keen to do it (for obvious reasons and because after all, the S7s and the G5s are all the rage, nowadays, for better or for worse).

I also wonder if these issues have anything to do with what this person: https://youtu.be/B0FJ9TN8F1c?t=2m44s had to say back in early December 2015: maybe some of the radios that LG used for early production units didn't cut it quality-wise, so they possibly removed them from the list of radios they mount at assembly, I'm not too sure: this is pure speculation, but the problems the person in the video described are quite similar to some of the problems I encountered after using DFS to modify the NVM of the LG V10s. Maybe those first units were the ones which could have their LTE BC Config DIV LTE #6829 easily adjusted, who knows...

All in all, from my limited, albeit still somewhat relevant, experience, I would say that the latter iterations of the LG V10 Dual SIM device are less likely to be " 'fully' LTE unlockable".

Just for completeness, I will say that I'm using the DFS Evolution (non-demo version), but when I wrote the guide, I tested it on the demo version, and it worked fine.

Some of the LG V10 Dual SIM devices whose LTE bands I have

personally

unlocked/enabled in the past did not have the VARIABLE_WAS_NOT_ACTIVE issue and had their LTE BC Config DIV LTE #6829 flashed with little problems: their LTE BC Config DIV LTE #6829 values even persisted after the flashed device got rebooted and re-mounted and re-read in DFS.

I hope that this answer adequately satisfied your curiosity.

Unfortunately, VoLTE is confirmed to NOT work on the current rooted ROM even with carriers supporting it, so if your carrier won't let you access LTE unless you have VoLTE enabled, I guess you're out of luck; VoLTE might POSSIBLY work after you upgrade to MM if you unlocked/enabled the appropriate LTE bands back when you were on the rooted ROM, on which, again, VoLTE is confirmed to NOT work.

Thank you for your screenshot, Addy.

However, I can't use that screenshot to confirm and document the assumption that LTE Band 28 (700 MHz) works in a real world deployment, because unless I'm bat-blind, I can't see where it says that it's LTE Band 28 (700 MHz).

Please, do have a look at the attachments of this post and notice how such a screenshot should look like: http://xdaforums.com/showpost.php?p=65254465&postcount=368

I wonder why does it say "LTE Band Unknown": are you rooted, having granted all of the necessary permissions to the LTE Discovery app?

From my personal experience, I respectfully disagree with the second and third statements of the above post of Tickertapes's.

In regards their first statement, I will say that while rooting your LG V10 Dual SIM with the publicly available method won't "cause you to lose any bands" or LTE service per se; but having said that, if your carrier conditions their providing you access to their LTE service on your device having a functioning VoLTE system, then you will NOT be able to access their LTE service while running your device on the rooted LP ROM, unfortunately.

----------------------------------------

I have mostly moved on from this device, so for now, I'll return to my forum hiatus, as far as this thread is concerned.

I'll still be reading it, possibly dropping a couple of one-liners here and there, but to sum up this topic: if you are satisfied with how the unlocked/enabled LTE bands currently work, whether your device is on LP or MM, then good; if not, your device might or might not be quirked for good, but by all means and existing inconveniencies, you can either live with it, or have it repaired by an LG authorized repair center, most probably for a relatively substantial fee.

----------------------------------------

I hope that some of you find this post useful.

Thanks!