Strange pitching behavior of M2P under weak signal

boblui · Jul 14, 2020

I went out to a local beach to do a test on the range improvement achievable by reflectors when used on my M2P’s RC. It was a simple flight. Went straight out over the water until the signal was lost or the battery reached about 60% and then came back.

In the return leg, the signal turned bad at the beginning and I did nothing but just waited for RTH to kick in by itself. It didn’t happen and the artificial horizon indicated that the craft was pitching back and forth more or less periodically when full forward elevator was applied. After I was convinced that it was not going to come back, I hit the RTH button. Then I cancelled it and reverted back to manual control after the signal was restored and stable.

Just wondering if flight log analysts in this forum can shed some light on the strange pitching behavior of the craft ?

The screen capture of the GO app in the return leg :

The .TXT flight log file is attached. The .DAT file is not available as always for my M2P.

bumper · Jul 14, 2020

I'll be watching this one! Should be interesting . . . glad you got the drone back. How was the range, BTW?

Deleted member 103366 · Jul 14, 2020

That was a long 11 minutes or so

boblui said:
The .DAT file is not available as always for my M2P.

do you know why this is?

SkyeHigh · Jul 14, 2020

boblui said:
I went out to a local beach to do a test on the range improvement achievable by reflectors when used on my M2P’s RC. It was a simple flight. Went straight out over the water until the signal was lost or the battery reached about 60% and then came back.

In the return leg, the signal turned bad at the beginning and I did nothing but just waited for RTH to kick in by itself. It didn’t happen and the artificial horizon indicated that the craft was pitching back and forth more or less periodically when full forward elevator was applied. After I was convinced that it was not going to come back, I hit the RTH button. Then I cancelled it and reverted back to manual control after the signal was restored and stable.

View attachment 107794

Just wondering if flight log analysts in this forum can shed some light on the strange pitching behavior of the craft ?

The screen capture of the GO app in the return leg :

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.

The .TXT flight log file is attached. The .DAT file is not available as always for my M2P.

Just a thought, could the return leg be affected by the changed position of the sun reflecting off the water affecting the downward facing sensors? How high above the water?

Deleted member 103366 · Jul 14, 2020

Uuum isn't the lowest indicated height 70 odd metres so A'G/S'L would be more

sar104 · Jul 14, 2020

The pitch variations were caused entirely by intermittent uplink while you were holding full forward elevator. Each time it lost uplink it applied reverse pitch to stop, then restarted when it returned. In the plot below the loss of uplink is shown by the black line - thin is no uplink.

boblui · Jul 14, 2020

sar104 said:
In the plot below the loss of uplink is shown by the black line - thin is no uplink.

Good insight ! I can see from the csv file exported by CsvView that telemetry data is available only intermittently during the time period in which the radio signal was bad. How can it be identified that the unavailability of data is due to loss of uplink or downlink ?

boblui · Jul 14, 2020

PhiliusFoggg said:
That was a long 11 minutes or so

do you know why this is?

No idea. I used to have it but after DJI gave me a replacement drone ( new, not refurb ), I stopped getting the .DAT file. Firmware upgrade and GO APP upgrade does not help.

sar104 · Jul 14, 2020

boblui said:
Good insight ! I can see from the csv file exported by CsvView that telemetry data is available only intermittently during the time period in which the radio signal was bad. How can it be identified that the unavailability of data is due to loss of uplink or downlink ?

Loss of downlink (almost?) always correlates with loss of uplink. For example, I've never seen an aircraft enter failsafe RTH while downlink is still working. In fact it's only ever been postulated that you can have one without the other - generally in the form of an active uplink after the downlink is lost - but I've never seen confirmation that it can happen.

BudWalker · Jul 14, 2020

boblui said:
Good insight ! I can see from the csv file exported by CsvView that telemetry data is available only intermittently during the time period in which the radio signal was bad. How can it be identified that the unavailability of data is due to loss of uplink or downlink ?

The Windows version of CsvView has the signal General:downlinkSigStrength.

sar104 · Jul 14, 2020

BudWalker said:
The Windows version of CsvView has the signal General:downlinkSigStrength.
View attachment 107849

Those seem like rather small variations in downlink signal strength when the downlink was dropping out completely.

BudWalker · Jul 15, 2020

sar104 said:
Those seem like rather small variations in downlink signal strength when the downlink was dropping out completely.

I think this is more about the name "downlinkSigStrength". The term signal strength is usually associated with the signal to noise ratio - how many decibels is the signal above the decibels of the noise floor. That value doesn't exist in the .txt (or the .DAT). Instead, CsvView calculates a percentage from

number of packets received / number of packets that should have been received

A rough proxy for actual signal strength.

Perhaps someone could suggest are better name for this signal.

SkyeHigh · Jul 15, 2020

BudWalker said:
I think this is more about the name "downlinkSigStrength". The term signal strength is usually associated with the signal to noise ratio - how many decibels is the signal above the decibels of the noise floor. That value doesn't exist in the .txt (or the .DAT). Instead, CsvView calculates a percentage from

number of packets received / number of packets that should have been received

A rough proxy for actual signal strength.

Perhaps someone could suggest are better name for this signal.

May be: receiveDataIntegrity or receiveValidData or even receiveDropPackets

boblui · Jul 15, 2020

BudWalker said:
I think this is more about the name "downlinkSigStrength". The term signal strength is usually associated with the signal to noise ratio - how many decibels is the signal above the decibels of the noise floor. That value doesn't exist in the .txt (or the .DAT). Instead, CsvView calculates a percentage from

number of packets received / number of packets that should have been received

A rough proxy for actual signal strength.

Perhaps someone could suggest are better name for this signal.

How about "downlinkSigQuality" ?

sar104 · Jul 15, 2020

BudWalker said:
I think this is more about the name "downlinkSigStrength". The term signal strength is usually associated with the signal to noise ratio - how many decibels is the signal above the decibels of the noise floor. That value doesn't exist in the .txt (or the .DAT). Instead, CsvView calculates a percentage from

number of packets received / number of packets that should have been received

A rough proxy for actual signal strength.

Perhaps someone could suggest are better name for this signal.

OK - so it's a rolling average - that's why the value doesn't drop that much when the loss is intermittent. How big is the window?

manowar_gub · Jul 16, 2020

Dont you use any mods - FCC, boost?

Last year when nld FCC & boost were in my m2p, I got same behavior over 1km range, very strange. After that I removed all mods and changed RC cable to original phone cable. No such problems today

boblui · Jul 16, 2020

manowar_gub said:
Dont you use any mods - FCC, boost?

No, it's all stock CE configuration.

sar104 · Jul 16, 2020

boblui said:
No, it's all stock CE configuration.

You said that you were using reflectors. That's a mod.

BudWalker · Jul 16, 2020

sar104 said:
OK - so it's a rolling average - that's why the value doesn't drop that much when the loss is intermittent. How big is the window?

Not exactly a rolling average. The exact formula (I had to take a look at the code) is

sigStrength = 100.0 - (Gap - 0.1)/0.1 where Gap is the interval since the last record.

The sample rate for the .txt is 10 Hz. If there are no dropouts then Gap will always be 0.1 and sigStrength will be 100.0. If, e.g. there are two consecutive dropouts Gap is 0.3 and sigStrength = 98.0

Implementing a true rolling average is problematical. The results of the calcs that CsvView performs are conveyed by adding columns to the .csv that TXTlogToCSVtool creates. A rolling average would require inserting rows in the .csv created by TXTlogToCSVtool. Not a particularly difficult software effort. But, I'd rather not modify the data created by TXTlogToCSVtool.

Edit: In the above formula sigStrength is set to 0.0 if it's been calculated to be < 0.0;