Koti » Modify CAP_PRUNE to change 5G EN_DC/SA/CA combinations on Qualcomm 5G devices

Modify CAP_PRUNE to change 5G EN_DC/SA/CA combinations on Qualcomm 5G devices

Some Qualcomm devices have CAP_PRUNE file to have allowed 5G EN_DC/SA/CA combinations on Qualcomm devices. On most of devices (written 8/2021) do not have this device, but example Samsung Qualcomm devices often have. If your device don’t have this file then all hardware defined combinations have allowed or limited with another way if do not match UE Capability Information message requested output.

This do not change hardware defined combinations of the device (0xB826 NR CA Combinations) so that will be limit but with this file could reduce hardware defined combinations.

Requirements

  • QPST and access to EFS. This may require root

This instruction tested with Xiaomi Mi 11 Lite 5G.

Let’s start

Open EFS Explorer on your Windows computer and navigate to /nv/item_files/modem/nr5g/RRC/.

Find cap_prune file. If it’s exist you can download it and edit if you like. If you like to remove all limitations. just backup the file and delete it on EFS.

If you like to edit, use Qualcomm format. Here is example file:

n28AA-n78A;b1AA-b3A-b7A-n28AA-n78A;b1A-b3AA-b7A-n28AA-n78A;b1A-b3A-b7AA-n28AA-n78A;

Check changes working

You can check two different ways: 0xB826 and UE Capability Information message. In UE Capability Information if use our test cap_prune on Xiaomi, the device respond to n28 and n78 band NR band request example on 5G n28AA-n78A, but not n78AA because it missing in cap_prune file because we on this test we tested NR-CA (article in Finnish).

4 thoughts on “Modify CAP_PRUNE to change 5G EN_DC/SA/CA combinations on Qualcomm 5G devices”

  1. could this cap_prune be used to unblock mmWave bands perhaps
    I’ve experimeneted a lot lately with some of your tricks on many ‘undisclosed’ X65 based UE’s (i work in a telCo company)
    Hence i noticed carrier_policy.xml is a good way to open bands etc., however i figured out that policies.xml can simply be commented out with <!– and then in some caes it even opened up for SA bands + all NSA bands. but not mmWave bads, namely 257 & 258
    How could one achieve that with basic qpst (have no qxdm5 yet), perhaps nv items from ‘asus insiders ue’ could make the trick?
    Or is it simply because they’re compiled that way from factory
    Looking forward to any reply and ofc future posts from you. thank you

  2. could this cap_prune be used to unblock mmWave bands perhaps
    I’ve experimented a lot lately with some of your tricks on many ‘undisclosed’ X65 based UEs (i work in a telCo company)
    Hence i noticed carrier_policy.xml is a good way to open bands etc., however i figured out that policies.xml can simply be commented out and then in some cases it even opened up for SA bands also. but not mmWave bands, namely 257, 258
    How could one achieve that with basic qpst (have no qxdm5 yet), perhaps nv items from ‘asus insiders ue’ could make the trick?
    Or is it simply because they’re compiled that way from factory, hardware limitied
    Looking forward to any reply and ofc future posts from you. thank you

  3. could this cap_prune be used to unblock mmWave bands perhaps
    I’ve experimented a lot lately with some of your tricks on many ‘undisclosed’ X65 based UEs (i work in a telCo company)
    Hence i noticed carrier_policy.xml is a good way to open bands etc., however i figured out that policies.xml can simply be commented out and then in some cases it even opened up for SA bands also. but not mmWave bands, namely 257, 258
    How could one achieve that with basic qpst (have no qxdm5 yet), perhaps nv items from ‘asus insiders ue’ could make the trick?
    Or is it simply because they’re compiled that way from factory, hardware limitied
    Looking forward to any reply and ofc future posts from you. thank you

Kommentoi