Phantom 3 Standard range mod , let's do it together...

[Arya]

How does the RC/DJI Go App determine signal strength if there is no feedback signal to determine quality of signal?

After I crashed and repair my P3S and made my quad naked, I found that the quad has 4 antennas:
1. The 5.8 GHz (front and rear legs)
2. The 1.5 or 1.2 GHz (top of the quad)
3. The 2.4 GHz from gimbal (side of the battery)
4. The 2.4 GHz from camera (side of the battery)

Other leg is attached some mini compass circuit.

Point number 3, the gimbal board has Rx and Tx chips. That means it has OSD VTx to send telemetry data to you.

Point number 4, is camera WiFi FPV Tx only.
And when we did power mod to 20 dbm or 27 dbm to the quad side, it will applied to gimbal board circuit. Please correct me if I'm wrong.

Sadly, I cannot use my Taranis or Devo 10 to the P3S. (They has upto 600mw Tx!).

 

[sinxa]

How does the RC/DJI Go App determine signal strength if there is no feedback signal to determine quality of signal?

5.8 only one way from controller to AC and then determine its receiving signals and send it as telemetry data through 2.4 wifi downlink to the controller. Sounds logic, isn't it?

After I crashed and repair my P3S and made my quad naked, I found that the quad has 4 antennas:
1. The 5.8 GHz (front and rear legs)
2. The 1.5 or 1.2 GHz (top of the quad)
3. The 2.4 GHz from gimbal (side of the battery)
4. The 2.4 GHz from camera (side of the battery)

Other leg is attached some mini compass circuit.

Point number 3, the gimbal board has Rx and Tx chips. That means it has OSD VTx to send telemetry data to you.

Point number 4, is camera WiFi FPV Tx only.
And when we did power mod to 20 dbm or 27 dbm to the quad side, it will applied to gimbal board circuit. Please correct me if I'm wrong.

Sadly, I cannot use my Taranis or Devo 10 to the P3S. (They has upto 600mw Tx!).

I guess number 2 is for GPS. . .

Sent from my SCL23 using PhantomPilots mobile app

 

[Kapten]

So, what channel setting should i use? Get crazy inteference at stock channel.
Should i use chan 13 or 1-13 search?

 

[razrdan]

In my personal opinion changing only rcS should be sufficient. However try it and test it. If doesn't work modify the other files.
I'm not sure as I first edited all of them, then I realized I probably didn't have to, but I wrote instructions so i left it like that.
Please test it and let us know.

So far, I've edited all the rcS files and the rc.* files and entered the commands,

iw reg set US
iw dev wlan0 set txpower auto

But still, when I restart the RC and AC and take it for a flight, I can see via telnet that the region has been reset to GB (I do not live in GB, UK, EU) and the txpower is 15 dbm and 16 dbm on the RC and AC, respectively.

Upon going through the LOG messages I can see that after start up the system has run, "Calling CRDA for country", which returns GB and the TXPOWER values go back to GB setting than US - FCC settings.

I can override this by entering the following commands via telnet,

iw reg set US
iw dev wlan0 set txpower auto

and then flying. But I cannot possibly telnet these commands every time I want to fly the AC.

Please suggest how to write and save a script in the AC and RC so that it runs maybe 100 seconds after startup and sets the REG and TXPOWER as required.

Thank you.

 

[Vadar]

Suspect you are running into a problem with this part of the rcS file further up:

country=`fw_printenv -n country`
if [ $country = "GB" ];then
insmod /lib/modules/3.10.49/ath9k_hw.ko cert_country=1
else
insmod /lib/modules/3.10.49/ath9k_hw.ko
fi

the fw_printenv command is setting the variable country based on the OS environment variable for country set somewhere else, I surmise. Based on that, if country = GB, it executes ath9k_hw.ko with the additional syntax of cert_country=1. If country doesn't equal GB it just performs ath9k_hw.ko. You could try and remove cert_country=1 so that the statement looks like this:

if [ $country = "GB" ];then
insmod /lib/modules/3.10.49/ath9k_hw.ko
else
insmod /lib/modules/3.10.49/ath9k_hw.ko
fi

It will perform the same command no matter what the country variable is set to. I don't think you would need the iw reg set US command at that point. Do so at your own risk though...

If you can telnet into the RC, try typing fw_printenv country at the prompt to see what comes out.

 

[Argonaise]

Solution was already developed and it had been updated over times. Please find Papatita's automated updator.

So far, I've edited all the rcS files and the rc.* files and entered the commands,

iw reg set US
iw dev wlan0 set txpower auto

But still, when I restart the RC and AC and take it for a flight, I can see via telnet that the region has been reset to GB (I do not live in GB, UK, EU) and the txpower is 15 dbm and 16 dbm on the RC and AC, respectively.

Upon going through the LOG messages I can see that after start up the system has run, "Calling CRDA for country", which returns GB and the TXPOWER values go back to GB setting than US - FCC settings.

I can override this by entering the following commands via telnet,

iw reg set US
iw dev wlan0 set txpower auto

and then flying. But I cannot possibly telnet these commands every time I want to fly the AC.

Please suggest how to write and save a script in the AC and RC so that it runs maybe 100 seconds after startup and sets the REG and TXPOWER as required.

Thank you.

 

[Argonaise]

Tuning P3S's wifi link capability.

P3S transmits video packet with fragmentation, and each fragmented packet requires ACK to complete transmission. If ACK does not arrive, drone retransmits packet. So even if some packet lost by any reason, the video can be seen normally, in close range.

Before FCC mod, it was not a problem that this ACK had timeouts, because P3S usually flown at close range. Packets transmitted, and ACK transmitted in return, so there is round trip of packets. The time limit set upon this round trip is 1us by default on most APs, because wifis are used within 10-20m range.

After FCC mod, P3S began to fly further, and problem arisen. At 1km, packets cannot return in 1us. Over 300m, time taken in round trip distance(×2) increases 1us at every 300m. Over this distance, ACK timeouts occured frequently even in ACK has been normally transmitted from RC. Retransmission is frequently occured at longer distance from drone for no purpose, at this time video transmission begins to lag behind, despite of full signal strength and clean radio environment. Combined this, loss of some amount of ACKs makes drone link speed drop, and transmission itself adjusted to less frequent. By the nature of TCP transmission, dropped link speed is slowly recovered over time, because wifi weighs error-less transmission over realtime-ness, and it suggests congested wifi network over dropped link speed.

There is option to increase ACK timeout in wifi command in drone and RC. By tuning this timeout parameter, video can be smoothed in the distance.

Try to run this at the terminal, after boot (essentially at drone, and better apply at RC)
iw phy phy0 set distance 800

By applying this, ACK timeout adjusted 1us to near 3us, and I could feel smoother video over 500-800m. (Where I usually feeling lagged video in clean wifi radio environment ).

Making this option too high, phantom's video signal meter drops, even if the drone is very close to the RC. That signal check method is known for counting successfully received ACK packets in some time window, so loosing the ACK window too much causes that method confusion. Making packets unfragmented (making packet transmission less frequent, for high throughput networking) shows similar result.

I got favorable result for test one or two, but it is still not proven. Same as txpower option, adjusting this parameter considered as not harmful during test. It can be executed at terminal, but as usually, test always should taken at own risk, because I don't know the side effects at the field, or in environment with much interference.

And please let me know when I got wrong at the theory. I feel everything is not evident without proper amount of testing.

 

[Argonaise]

Good point, but touching rcS had been considered dangerous, because when it's screwed, it's irreversible(can reversible but requires much much effort...) Could rsmod and insmod run by telnet shell environment or djiled.sh?

Suspect you are running into a problem with this part of the rcS file further up:

country=`fw_printenv -n country`
if [ $country = "GB" ];then
insmod /lib/modules/3.10.49/ath9k_hw.ko cert_country=1
else
insmod /lib/modules/3.10.49/ath9k_hw.ko
fi

the fw_printenv command is setting the variable country based on the OS environment variable for country set somewhere else, I surmise. Based on that, if country = GB, it executes ath9k_hw.ko with the additional syntax of cert_country=1. If country doesn't equal GB it just performs ath9k_hw.ko. You could try and remove cert_country=1 so that the statement looks like this:

if [ $country = "GB" ];then
insmod /lib/modules/3.10.49/ath9k_hw.ko
else
insmod /lib/modules/3.10.49/ath9k_hw.ko
fi

It will perform the same command no matter what the country variable is set to. I don't think you would need the iw reg set US command at that point. Do so at your own risk though...

If you can telnet into the RC, try typing fw_printenv country at the prompt to see what comes out.

 

[Arya]

Good point, but touching rcS had been considered dangerous, because when it's screwed, it's irreversible(can reversible but requires much much effort...) Could rsmod and insmod run by telnet shell environment or djiled.sh?

It just a programming logic. Why so worry to screw a script? All programmers always did back-up and log book before start editting. Even a drone pilot also has log book.


Subscribe to my channel.

 

[Argonaise]

It just a programming logic. Why so worry to screw a script? All programmers always did back-up and log book before start editting. Even a drone pilot also has log book.

Subscribe to my channel.

1. Screws in script usually reversible by backup because you have a way to edit that script.

2. Screws in rcS usually reversible in normal linux system because you have wired console.

3. Screws in rcS of Phantom or RC cannot reversible by backup script because you lose way to edit it.
Why so worry to screw a script - because it is "special" script that provides a way to edit itself.

If it goes wrong, you cannot back to normal unless you disassemble phantom gimbal and solder tx/rx line and get proper virt-serial connector and make it work altogether and you have to type so many chars to back to normal. I have done it for other person and found it very tiresome.

Very small error(like mixing CR in newline, it is even invisible) can brick a phantom. I should say you can screw other scripts as you wish, but avoid touching rcS as long as it's avoidable.

 

[razrdan]

Suspect you are running into a problem with this part of the rcS file further up:

country=`fw_printenv -n country`
if [ $country = "GB" ];then
insmod /lib/modules/3.10.49/ath9k_hw.ko cert_country=1
else
insmod /lib/modules/3.10.49/ath9k_hw.ko
fi

the fw_printenv command is setting the variable country based on the OS environment variable for country set somewhere else, I surmise. Based on that, if country = GB, it executes ath9k_hw.ko with the additional syntax of cert_country=1. If country doesn't equal GB it just performs ath9k_hw.ko. You could try and remove cert_country=1 so that the statement looks like this:

if [ $country = "GB" ];then
insmod /lib/modules/3.10.49/ath9k_hw.ko
else
insmod /lib/modules/3.10.49/ath9k_hw.ko
fi

It will perform the same command no matter what the country variable is set to. I don't think you would need the iw reg set US command at that point. Do so at your own risk though...

If you can telnet into the RC, try typing fw_printenv country at the prompt to see what comes out.

I have modified that bit of code to avoid the problem you mentioned as follows, (do let me know what you think):

#country=`fw_printenv -n country` #OEM code
country=US #USER code
if [ $country = "GB" ];then
insmod /lib/modules/3.10.49/ath9k_hw.ko cert_country=1
else
insmod /lib/modules/3.10.49/ath9k_hw.ko
fi

I have also tried typing the command fw_printenv country via telnet and the response since the beginning, before I modified anything, has been US and still continues to be US.

Upon checking the system log, I can see after first setting it to World Regulatory Domain, it switches to US then switches to GB.

 

[Argonaise]

I have modified that bit of code to avoid the problem you mentioned as follows, (do let me know what you think):

#country=`fw_printenv -n country` #OEM code
country=US #USER code
if [ $country = "GB" ];then
insmod /lib/modules/3.10.49/ath9k_hw.ko cert_country=1
else
insmod /lib/modules/3.10.49/ath9k_hw.ko
fi

I have also tried typing the command fw_printenv country via telnet and the response since the beginning, before I modified anything, has been US and still continues to be US.

Upon checking the system log, I can see after first setting it to World Regulatory Domain, it switches to US then switches to GB.

What I understand is "cert_country=1" option makes no difference in the CRDA regulation process. Did I get it right?
CRDA domain switching is known to be triggered by GPS lock. Regardless of App(Litchi, DJI Go) CRDA is applied with GPS lock. Those are experimented by forum members.

 

[PapaTita]

I have done it for other person and found it very tiresome.

I experienced it as well

 

[razrdan]

Solution was already developed and it had been updated over times. Please find Papatita's automated updator.

I experienced it as well

Hi PapaTita,

Could you please direct me to your latest solution for the problem I am facing...

So far, I've edited all the rcS files and the rc.* files and entered the commands,

iw reg set US
iw dev wlan0 set txpower auto

But still, when I restart the RC and AC and take it for a flight, I can see via telnet that the region has been reset to GB (I do not live in GB, UK, EU) and the txpower is 15 dbm and 16 dbm on the RC and AC, respectively.

Upon going through the LOG messages I can see that after start up the system has run, "Calling CRDA for country", which returns GB and the TXPOWER values go back to GB setting than US - FCC settings.

I can override this by entering the following commands via telnet,

iw reg set US
iw dev wlan0 set txpower auto

and then flying. But I cannot possibly telnet these commands every time I want to fly the AC.

Please suggest how to write and save a script in the AC and RC so that it runs maybe 100 seconds after startup and sets the REG and TXPOWER as required.

Thank you.

 

[PapaTita]

Hi PapaTita,

Could you please direct me to your latest solution for the problem I am facing...

How to Update Tx-Power with DJIUpdate.exe (CE to FCC)

 

[Vadar]

Tuning P3S's wifi link capability.

P3S transmits video packet with fragmentation, and each fragmented packet requires ACK to complete transmission. If ACK does not arrive, drone retransmits packet. So even if some packet lost by any reason, the video can be seen normally, in close range.

Before FCC mod, it was not a problem that this ACK had timeouts, because P3S usually flown at close range. Packets transmitted, and ACK transmitted in return, so there is round trip of packets. The time limit set upon this round trip is 1us by default on most APs, because wifis are used within 10-20m range.

After FCC mod, P3S began to fly further, and problem arisen. At 1km, packets cannot return in 1us. Over 300m, time taken in round trip distance(×2) increases 1us at every 300m. Over this distance, ACK timeouts occured frequently even in ACK has been normally transmitted from RC. Retransmission is frequently occured at longer distance from drone for no purpose, at this time video transmission begins to lag behind, despite of full signal strength and clean radio environment. Combined this, loss of some amount of ACKs makes drone link speed drop, and transmission itself adjusted to less frequent. By the nature of TCP transmission, dropped link speed is slowly recovered over time, because wifi weighs error-less transmission over realtime-ness, and it suggests congested wifi network over dropped link speed.

There is option to increase ACK timeout in wifi command in drone and RC. By tuning this timeout parameter, video can be smoothed in the distance.

Try to run this at the terminal, after boot (essentially at drone, and better apply at RC)
iw phy phy0 set distance 800

By applying this, ACK timeout adjusted 1us to near 3us, and I could feel smoother video over 500-800m. (Where I usually feeling lagged video in clean wifi radio environment ).

Making this option too high, phantom's video signal meter drops, even if the drone is very close to the RC. That signal check method is known for counting successfully received ACK packets in some time window, so loosing the ACK window too much causes that method confusion. Making packets unfragmented (making packet transmission less frequent, for high throughput networking) shows similar result.

I got favorable result for test one or two, but it is still not proven. Same as txpower option, adjusting this parameter considered as not harmful during test. It can be executed at terminal, but as usually, test always should taken at own risk, because I don't know the side effects at the field, or in environment with much interference.

And please let me know when I got wrong at the theory. I feel everything is not evident without proper amount of testing.

This is awesome info. So essentially the 2.4Ghz channel uses TCP protocol with all the error correcting overhead while the 5.8Ghz channel probably uses UDP which is fire and forget, right?

 

[bigdog21782]

Tuning P3S's wifi link capability.

P3S transmits video packet with fragmentation, and each fragmented packet requires ACK to complete transmission. If ACK does not arrive, drone retransmits packet. So even if some packet lost by any reason, the video can be seen normally, in close range.

Before FCC mod, it was not a problem that this ACK had timeouts, because P3S usually flown at close range. Packets transmitted, and ACK transmitted in return, so there is round trip of packets. The time limit set upon this round trip is 1us by default on most APs, because wifis are used within 10-20m range.

After FCC mod, P3S began to fly further, and problem arisen. At 1km, packets cannot return in 1us. Over 300m, time taken in round trip distance(×2) increases 1us at every 300m. Over this distance, ACK timeouts occured frequently even in ACK has been normally transmitted from RC. Retransmission is frequently occured at longer distance from drone for no purpose, at this time video transmission begins to lag behind, despite of full signal strength and clean radio environment. Combined this, loss of some amount of ACKs makes drone link speed drop, and transmission itself adjusted to less frequent. By the nature of TCP transmission, dropped link speed is slowly recovered over time, because wifi weighs error-less transmission over realtime-ness, and it suggests congested wifi network over dropped link speed.

There is option to increase ACK timeout in wifi command in drone and RC. By tuning this timeout parameter, video can be smoothed in the distance.

Try to run this at the terminal, after boot (essentially at drone, and better apply at RC)
iw phy phy0 set distance 800

By applying this, ACK timeout adjusted 1us to near 3us, and I could feel smoother video over 500-800m. (Where I usually feeling lagged video in clean wifi radio environment ).

Making this option too high, phantom's video signal meter drops, even if the drone is very close to the RC. That signal check method is known for counting successfully received ACK packets in some time window, so loosing the ACK window too much causes that method confusion. Making packets unfragmented (making packet transmission less frequent, for high throughput networking) shows similar result.

I got favorable result for test one or two, but it is still not proven. Same as txpower option, adjusting this parameter considered as not harmful during test. It can be executed at terminal, but as usually, test always should taken at own risk, because I don't know the side effects at the field, or in environment with much interference.

And please let me know when I got wrong at the theory. I feel everything is not evident without proper amount of testing.

Hi Argonaise,
Just wondering, you say iw phy phy0 set distance 800 is nearly 3us, what would the value for 1us be and what can you put it up to before you start having problems. Also is there a way to check it through telnet?

Sent from my Letv X500 using PhantomPilots mobile app

 

[Argonaise]

This is awesome info. So essentially the 2.4Ghz channel uses TCP protocol with all the error correcting overhead while the 5.8Ghz channel probably uses UDP which is fire and forget, right?

• 2.4ghz WiFi - Video / Telemetry Downlink <-- standard WiFi protocol with a few added non-published schemes. Note: The P3S' internal WiFi Module is easily removed since it is held in place via a two row pin socket strip and a small piece of double sticky foam. (Power and pin-out information is available.) It is powered using 3.3VDC. For the most part, it does the same exact function as the P2V+' wifi module; of course engineers like to change things so the P3S' wifi module is not compatible with the P2V+.
• 5.8ghz RC - Control Uplink <-- A Packet based frequency hopping scheme using FSK modulation. The in-air bit rate is 1mbs. Packets contain a Control and Payload section. The Control section contains a unique address based on the serial number of your drones controller; not the drone itself. The Payload section is fixed width (up to 32 bytes) and also encoded with a 16 bit CRC. The Payload section contains joystick and switch position information. The controller transmits Packets are blindly repeated ~143 packets per second. The controller is transmit only and the drone is receive only. The 5.8ghz radio hardware does not support two-way communications (ie they are not transceivers). If a few Packets get through per second to the drone then controlled flight is maintained. Else, the drone times out and executes an RTH (Return To Home).

See page 64, garrock explained internals about P3S radio protocols

 

[Argonaise]

Hi Argonaise,
Just wondering, you say iw phy phy0 set distance 800 is nearly 3us, what would the value for 1us be and what can you put it up to before you start having problems. Also is there a way to check it through telnet?

Sent from my Letv X500 using PhantomPilots mobile app

1us, 3us are ACK timeouts.

Changing ACK timeout and Slottime

For every further 300 meter increase in distance above 300 meters add 1 µs to the Slottime of your device, and 2 µs to the ACK timeout and CTS timeout.

Every station connected on the same channel should have the same time constants.

Use the furthest distance between any two nodes as the distance in your calculations.

For specific examples for popular operating systems and drivers please see http://www.air-stream.org/Change_ACK

Definitions

ACK Timeout = Air Propagation Time (max) + SIFS + Time to transmit 14 byte ACK frame [14 * 8 / bitrate in Mbps] + Air Propagation Time (max)

Slottime = MAC and PHY delays + Air Propagation Time (max)

DIFS = SIFS + 2 * Slottime

See here for more detailed info.

ACK Timeouts and the effects on distance links | Air-Stream

It is something like running app in windows, you click an app, windows executing, but you only wait 1us, but app executes at 3us. You don't wait for that app executing and double clicks icon at 1us. Windows starts to lag. This is a situation similar to above.

Theorically, it does not affect packet transmission itself. But it can affect the wifi network throughput, you can feel lagging videos if that timeout setting have problems. If you feel problems, just return the bird and reboot(unless you did not added it to startup script). It is close to tuning, somewhat far from modification. iw and iwinfo does not shows the ACK timeout, so checking parameter in telnet is impossible. (In normal wifi enviornment it should be left as it is, and no one should care about it)

 

[razrdan]

How to Update Tx-Power with DJIUpdate.exe (CE to FCC)

Your mod worked like a charm. I'm finally able to enjoy flying the Phantom with an almost lag free video feed.. It feels like the flight time has increased 2x, cause I no longer waste time waiting for signal or the video to catch up. It's freed me up to do so much more!

NOTE: Your mod / program ran STEP 1 and STEP 2 automatically, without me having to restart the RC and AC in between. I was only directed to restart at the end. Is that an update in your program's working?