This page is a bit of an experiment. Over time, many people have asked “Can we do 32ch and FCC on a P4p”. Based on the previous files, the answer was no. But, I have always intended to go back and look at this to see if it is possible.

What I propose to do is to look at the 32ch file, and the FCC file, and the source code that parses these files, and come to a conclusion.

Below, we can see the data contained in each of these files. It is easy to see the individual bits that change for power and frequency tweaks. What is not so obvious at the moment is what part of this file does the 32 channel mod. If anyone has that detail, it would be useful information.

00000000  44 4a 49 20 53 4f 46 54  57 41 52 45 20 43 4f 4e  |DJI SOFTWARE CON|
00000010  46 49 47 20 3a 20 44 4f  20 4e 4f 54 20 44 45 4c  |FIG : DO NOT DEL|
00000020  45 54 45 21 00 00 00 01  11 11 11 11 11 11 11 11  |ETE!............|
00000030

00000000  01 01 01 01 01 01 01 01  01 01 01 01 01 01 01 01  |................|
00000010  01 01 01 01 01 01 01 01  01 01 01 01 01 01 01 01  |................|
00000020  01 01 01 01 01 01 01 01  00 00 00 00 00 00 00 11  |................|
00000030  11 11 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000040  00 00 00 00 00 00 00                              |.......|
00000047

Now. If we look at those two files, it appears that the first 36 bytes at least are header data that is not used. Beyond that, we can see that the 32ch file as a bunch of 11's next. Comparing that to the force_fcc file, it has a few 11's in different positions and some extra nulls at the end.

Why not combine the two files and try it?

00000000  44 4a 49 20 53 4f 46 54  57 41 52 45 20 43 4f 4e  |DJI SOFTWARE CON|
00000010  46 49 47 20 3a 20 44 4f  20 4e 4f 54 20 44 45 4c  |FIG : DO NOT DEL|
00000020  45 54 45 21 00 00 00 01  11 11 11 11 11 11 11 11  |ETE!............|
00000030  11 11 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000040  00 00 00 00 00 00 00                              |.......|
00000047

Theoretically, we are just merging two files. The suggested combined file also align with the code below, which is believed to be the parser for this file. There are some offsets for which byte to look at in various places in the parser. However the parser is not looking at a structure of the same size as our files since the bytes do not clearly align to the correct position in our file. The original authors of these config files also were guessing a bit, since they repeat the same values in multiple places. Even 1 “1” gets written as “11” to account for different encoding standards. It doesn't hurt to do both. Either way, the original files work… So, theoretically, our composite file will work also. The only reason it would not work is if the SDR in the P4P does not support higher TX power levels. But, lets give it a test fly…. Stay tuned for more.

• Previous State:
  • On 2.4 32ch mod, I got some pretty decent range. however, I was unable to descend to a lower altitude. I maintained 120m to avoid obstructions.
  • For 5.8 - I had not tried all that much before. The 32ch mod for 2.4 gave me what I needed. I know that I regularly had range issues on 5.8. In testing today, I was able to go the same range as the 2.4 32ch test.
  • Conclusion: Overall, due to interference, 32ch doubles my range. Due to higher output, I believe the FCC part of the custom file gives me increased range on 5.8g.
  • But: Need to do something more scientific to validate before releasing a new config file to the masses.
  • WANTED: Need someone with some test gear.

if ((an unsigned __int64) objc_msgSend(v9, "the length") > = 0x29) {
  v11 = (void * ) objc_retainAutorelease(v10);
  if ( * ((_ BYTE * ) objc_msgSend(v11, "bytes") + 39) == 1)
    v2 - > NSObject_opaque[OBJC_IVAR ___ DJIAppSettings__canUseIllegalChannels] = 1;
}
If((unsigned __int64) objc_msgSend(v10, "length") > = 0x2A) {
  v12 = (void * ) objc_retainAutorelease(v10);
  if ( * ((_ BYTE * ) objc_msgSend(v12, "bytes") + 40) == 1)
    v2 - > NSObject_opaque[OBJC_IVAR ___ DJIAppSettings__mfiDisable] = 1;
}
If((unsigned __int64) objc_msgSend(v10, "length") > = 0x2D) {
  v13 = (void * ) objc_retainAutorelease(v10);
  V14 = * ((unsigned __int8 * ) objc_msgSend(v13, "bytes") + 43);
  if ((_DWORD) v14 == 2)
    * (DWORD * _) & v2 - > NSObject_opaque[OBJC_IVAR ___ DJIAppSettings__firmwareServiceType] = 2;
  Else
    * (_ DWORD * ) & v2 - > NSObject_opaque[OBJC_IVAR ___ DJIAppSettings__firmwareServiceType] = v14 == 1;
}
If((unsigned __int64) objc_msgSend(v10, "length") > = 0x2E) {
  v15 = (void * ) objc_retainAutorelease(v10);
  if ( * ((_ BYTE * ) objc_msgSend(v15, "bytes") + 44) == 1)
    v2 - > NSObject_opaque[OBJC_IVAR ___ DJIAppSettings__limitCameraRecordingTime] = 0;
}
If((unsigned __int64) objc_msgSend(v10, "length") > = 0x2F) {
  v16 = (void * ) objc_retainAutorelease(v10);
  If( * ((_ BYTE * ) objc_msgSend(v16, "bytes") + 45) == 1)
  v2 - > NSObject_opaque[OBJC_IVAR ___ DJIAppSettings__simulatorInternalDisable] = 1;
}
If((unsigned __int64) objc_msgSend(v10, "length") > = 0x31) {
    v17 = (void * ) objc_retainAutorelease(v10);
    V18 = * ((_ BYTE * ) objc_msgSend(v17, "bytes") + 48);
    If(v18 & 1)
    objc_msgSend(v2, " setSdr_force_fcc :", 1 LL);
    if (v18 & 2)
      objc_msgSend(v2, "setSdr_force_boost:", 1 LL);
    if (v18 & 4)
      objc_msgSend(v2, "setSdr_force_2_3_G:", 1 LL);
    if (v18 & 8)
      objc_msgSend(v2, "setSdr_force_2_5_G:", 1 LL);