Lost P4P+

[sar104]

Just a thought, but am unsure if this is correct. I know that P4's ( At least on IOS ) create .dat files on the device, and I am assuming along with .txt files ( Could be wrong there ). It might be worth taking a look see for any .dat files on your device dated the same as the .txt log file.
Off the top of my head, I do not recall the difference in supplied data between the two, but they are slightly different. It is possible to at least get a few more bit's of data that were not in the .txt file. As I said, this could be IOS only and if you are using the built in monitor the .txt files may be all you have. Just something to look at for possible additional data.

The DAT files are always created on the mobile device. They contain far more data fields than the txt but the sample rate is still 10 Hz.

EDIT: Apologies for the silly smilies - the forum software seems to be unable to ignore certain character combinations.

3.3.0-Tablet
aircraft_condition:fsm_state
aircraft_condition:int_fsm
aircraft_condition:land_state
aircraft_condition:last_fsm
aircraft_condition:near_gnd
aircraft_condition:safe_fltr
aircraft_condition:UP_acc_t
aircraft_condition:UP_state
aircraft_condition:UP_TF_t
ATTI_MINI0:s_agz0
ATTI_MINI0:s_cnt0
ATTI_MINI0:s_pgz0
ATTI_MINI0:s_qw0
ATTI_MINI0:s_qx0
ATTI_MINI0:s_qy0
ATTI_MINI0:s_qz0
ATTI_MINI0:s_rsv00
ATTI_MINI0:s_rsv10
ATTI_MINI0:s_vgz0
Attribute|Value
battery_info:ad_v
battery_info:ave_I
battery_info:cap_per
battery_info:dyna_cnt
battery_info:f_cap
battery_info:I
battery_info:l_cell
battery_infout_ctl
battery_infout_ctl_f
battery_infoack_ve
battery_info:r_cap
battery_info:r_time
battery_info:right
battery_info:temp
battery_info:vol_t
Controller:act_act_id
Controller:act_req_id
Controller:cmd_mod
Controller:ctrl_level
Controller:ctrl_mode
Controller:ctrl_pitch
Controller:ctrl_roll
Controller:ctrl_thr
Controller:ctrl_tick
Controller:ctrl_yaw
Controller2H_x
Controller2H_y
Controller:fw_flag
Controller:max_height
Controller:max_radius
Controller:mod_req_id
Controller:mode_switch
Controller:mot_sta
Controller:motor_state
Controller:OH_take
Controller:rc_cnt
Controller:sig_level
Controller:sim_model
Controller:sup_rc
ConvertDatV3
ctrl_acc_vert_debug:acc_cmd
ctrl_acc_vert_debug:acc_fdbk
ctrl_acc_vert_debug:acc_tag
ctrl_acc_vert_debug:thr_cmd
ctrl_horiz_ang_vel_debug:gyro_cmdx
ctrl_horiz_ang_vel_debug:gyro_cmdy
ctrl_horiz_ang_vel_debug:gyro_cmdz
ctrl_horiz_ang_vel_debug:gyro_fbkx
ctrl_horiz_ang_vel_debug:gyro_fbky
ctrl_horiz_ang_vel_debug:gyro_fbkz
ctrl_horiz_ccpm_debug:fix_lift
ctrl_horiz_ccpm_debug:fix_tilt_x
ctrl_horiz_ccpm_debug:fix_tilt_y
ctrl_horiz_ccpm_debug:fix_tor
ctrl_horiz_ccpm_debug:raw_lift
ctrl_horiz_ccpm_debug:raw_tilt_x
ctrl_horiz_ccpm_debug:raw_tilt_y
ctrl_horiz_ccpm_debug:raw_tors
ctrl_horiz_ccpm_debug:thr_max
ctrl_horiz_ccpm_debug:thr_min
ctrl_horiz_debug:AL_avoid
ctrl_horiz_debug:AL_bat
ctrl_horiz_debug:AL_final
ctrl_horiz_debug:AL_gmb_pri
ctrl_horiz_debug:AL_gmb_typ
ctrl_horiz_debug:ao_workable
ctrl_horiz_debug:ap_os_F
ctrl_horiz_debug:avd_ob_os_F
ctrl_horiz_debug:avoid_en
ctrl_horiz_debug:CL_tors
ctrl_horiz_debug:emg_brk_F
ctrl_horiz_debug:flw_gmb_F
ctrl_horiz_debug:G_tgt_gyro
ctrl_horiz_debug:GF_cur_yaw
ctrl_horiz_debug:GF_tgt_yaw
ctrl_horiz_debug:gmb_mode
ctrl_horiz_debug:gmb_on
ctrl_horiz_debug:gmb_pos
ctrl_horiz_debug:gmb_refYaw
ctrl_horiz_debug:h_api_frm
ctrl_horiz_debug:h_api_mode
ctrl_horiz_debug:H_fence_os_F
ctrl_horiz_debug:h_lmt_os_F
ctrl_horiz_debug:horiz_mode
ctrl_horiz_debug:hov_brk_T
ctrl_horiz_debug:hov_cfrm_T
ctrl_horiz_debug:hov_flag
ctrl_horiz_debug:hov_px
ctrl_horiz_debug:hov_py
ctrl_horiz_debug:hov_state
ctrl_horiz_debug:in_flw_gmb
ctrl_horiz_debug:near_bnd
ctrl_horiz_debug:nearest_ob
ctrl_horiz_debugos_cmdx
ctrl_horiz_debugos_cmdy
ctrl_horiz_debug:R_os_F
ctrl_horiz_debug:tilt_cmd_x
ctrl_horiz_debug:tilt_cmd_y
ctrl_horiz_debug:track_en
ctrl_horiz_debug:trck_yaw_v
ctrl_horiz_debug:trs_f_flg
ctrl_horiz_debug:trs_f_req
ctrl_horiz_debug:trs_lck_st
ctrl_horiz_debug:trs_lck_T
ctrl_horiz_debug:trs_mod
ctrl_horiz_debug:trs_p_cmd
ctrl_horiz_debug:trs_p_lck
ctrl_horiz_debug:trs_v_cmd
ctrl_horiz_debug:true_rad_lmt
ctrl_horiz_debug:v_ctrl_mod
ctrl_horiz_debug:vel_cmdx
ctrl_horiz_debug:vel_cmdy
ctrl_horiz_debug:watch_mode
ctrl_horiz_motor_debugwm1
ctrl_horiz_motor_debugwm2
ctrl_horiz_motor_debugwm3
ctrl_horiz_motor_debugwm4
ctrl_horiz_motor_debugwm5
ctrl_horiz_motor_debugwm6
ctrl_horiz_motor_debugwm7
ctrl_horiz_motor_debugwm8
ctrl_vert_debug:ap_high_os_F
ctrl_vert_debug:gnd_os_F
ctrl_vert_debug:high_os_F
ctrl_vert_debug:hit_gnd
ctrl_vert_debug:landing_tyoe
ctrl_vert_debug:low_os_F
ctrl_vert_debug:near_bound
ctrl_vert_debug:rf_os_F
ctrl_vert_debug:takeoff_T
ctrl_vert_debug:true_h_lmt
ctrl_vert_debug:v_lmt_os_F
ctrl_vert_debug:vert_brk_T
ctrl_vert_debug:vert_flag
ctrl_vert_debug:vert_mode
ctrl_vert_debug:vert_pos
ctrl_vert_debug:vert_state
err_code:gcm0_act
err_code:gcm0_break
err_code:gcm0_dev
err_code:gcm0_err
err_code:gcm0_fault
err_code:gcm1_act
err_code:gcm1_break
err_code:gcm1_dev
err_code:gcm1_err
err_code:gcm1_fault
err_code:gcm2_act
err_code:gcm2_break
err_code:gcm2_dev
err_code:gcm2_err
err_code:gcm2_fault
err_code:imu_stat
err_code:imu0_act
err_code:imu0_dev
err_code:imu0_err
err_code:imu0_fault
err_code:imu1_act
err_code:imu1_break
err_code:imu1_dev
err_code:imu1_err
err_code:imu1_fault
err_code:imu2_act
err_code:imu2_break
err_code:imu2_dev
err_code:imu2_err
err_code:imu2_fault
err_code:mag_stat
err_code:mc_act
err_code:mc_dev
err_code:mc_err
err_code:mc_fault
esc_data:cnt_1
esc_data:cnt_2
esc_data:cnt_3
esc_data:cnt_4
esc_data:cnt_5
esc_data:cnt_6
esc_data:cnt_7
esc_data:debug0_1
esc_data:debug0_2
esc_data:debug0_3
esc_data:debug0_4
esc_data:debug0_5
esc_data:debug0_6
esc_data:debug0_7
esc_data:debug0_8
esc_data:debug1_1
esc_data:debug1_2
esc_data:debug1_3
esc_data:debug1_4
esc_data:debug1_5
esc_data:debug1_6
esc_data:debug1_7
esc_data:debug1_8
esc_data:debug2_1
esc_data:debug2_2
esc_data:debug2_3
esc_data:debug2_4
esc_data:debug2_5
esc_data:debug2_6
esc_data:debug2_7
esc_data:debug2_8
esc_data:I_1
esc_data:I_2
esc_data:I_3
esc_data:I_4
esc_data:I_5
esc_data:I_6
esc_data:I_7
esc_data:I_8
esc_datapm_mode
esc_datapm_recv_1
esc_datapm_recv_2
esc_datapm_recv_3
esc_datapm_recv_4
esc_datapm_recv_5
esc_datapm_recv_6
esc_datapm_recv_7
esc_datapm_recv_8
esc_datapm_send
esc_datapm_send_1
esc_datapm_send_1_2
esc_datapm_send_2
esc_datapm_send_3
esc_datapm_send_4
esc_datapm_send_6
esc_datapm_send_7
esc_data:speed_1
esc_data:speed_2
esc_data:speed_3
esc_data:speed_4
esc_data:speed_5
esc_data:speed_6
esc_data:speed_7
esc_data:speed_8
esc_data:status_2
esc_data:status_3
esc_data:status_4
esc_data:status_5
esc_data:status_6
esc_data:status_7
esc_data:status_8
esc_data:status1
esc_data:temp_1
esc_data:temp_2
esc_data:temp_3
esc_data:temp_4
esc_data:temp_5
esc_data:temp_6
esc_data:temp_7
esc_data:temp_8
esc_data:V_1
esc_data:V_2
esc_data:V_3
esc_data:V_4
esc_data:V_5
esc_data:V_6
esc_data:V_7
esc_data:V_8
esc_data:v_out_1
esc_data:v_out_2
esc_data:v_out_3
esc_data:v_out_4
esc_data:v_out_5
esc_data:v_out_6
esc_data:v_out_7
esc_data:v_out_8
IMU_ATTI_0:agx0
IMU_ATTI_0:agy0
IMU_ATTI_0:agz0
IMU_ATTI_0:alti0
IMU_ATTI_0:atti_cnt0
IMU_ATTI_0:ax0
IMU_ATTI_0:ay0
IMU_ATTI_0:az0
IMU_ATTI_0:filter_stat0
IMU_ATTI_0:gbx0
IMU_ATTI_0:gby0
IMU_ATTI_0:gbz0
IMU_ATTI_0:lati0
IMU_ATTI_0:long0
IMU_ATTI_0:mx0
IMU_ATTI_0:my0
IMU_ATTI_0:mz0
IMU_ATTI_0ress0
IMU_ATTI_0:qw0
IMU_ATTI_0:qx0
IMU_ATTI_0:qy0
IMU_ATTI_0:qz0
IMU_ATTI_0:sensor_stat0
IMU_ATTI_0:svn0
IMU_ATTI_0:tx0
IMU_ATTI_0:ty0
IMU_ATTI_0:tz0
IMU_ATTI_0:vgx0
IMU_ATTI_0:vgy0
IMU_ATTI_0:wx0
IMU_ATTI_0:wy0
IMU_ATTI_0:wz0
IMU_EX_0:ex_cnt0
IMU_EX_0:flag_err0
IMU_EX_0:flag_navi0
IMU_EX_0:flag_rsv0
IMU_EX_0:rtk_alti0
IMU_EX_0:rtk_lati0
IMU_EX_0:rtk_long0
IMU_EX_0:us_p0
IMU_EX_0:us_v0
IMU_EX_0:vo_px0
IMU_EX_0:vo_py0
IMU_EX_0:vo_pz0
IMU_EX_0:vo_vx0
IMU_EX_0:vo_vy0
IMU_EX_0:vo_vz0
new_mvo_feedback:height
new_mvo_feedback:heightUncertainty
new_mvo_feedback:hoverPointUncertainty1
new_mvo_feedback:hoverPointUncertainty2
new_mvo_feedback:hoverPointUncertainty3
new_mvo_feedback:hoverPointUncertainty4
new_mvo_feedback:hoverPointUncertainty5
new_mvo_feedback:hoverPointUncertainty6
new_mvo_feedbackos_X
new_mvo_feedbackos_Y
new_mvo_feedbackos_Z
new_mvo_feedback:reserved1
new_mvo_feedback:reserved2
new_mvo_feedback:reserved3
new_mvo_feedback:reserved4
new_mvo_feedback:Vel_X
new_mvo_feedback:Vel_Y
new_mvo_feedback:Vel_Z
new_mvo_feedback:velocityUncertainty1
new_mvo_feedback:velocityUncertainty2
new_mvo_feedback:velocityUncertainty3
new_mvo_feedback:velocityUncertainty4
new_mvo_feedback:velocityUncertainty5
new_mvo_feedback:velocityUncertainty6
new_mvo_feedback:visionObservationCount
ns_data_component:ns_cmpnt
ns_data_debug:d00
ns_data_debug:d01
ns_data_debug:d02
ns_data_debug:d03
ns_data_debug:d04
ns_data_debug:d05
ns_data_debug:d06
ns_data_debug:d07
ns_data_debug:d08
ns_data_debug:d09
ns_data_debug:d10
ns_data_debug:d11
ns_data_debug:d12
ns_data_debug:d13
ns_data_debug:d14
ns_data_debug:d15
ns_data_debug:d16
ns_data_debug:d17
ns_data_debug:d18
ns_data_debug:d19
offsetTime
serial_api_inputs:avoid_E
serial_api_inputs:bit_S
serial_api_inputs:cmd_ack
serial_api_inputs:cmd_req
serial_api_inputs:ctrl_dev
serial_api_inputs:f_test
serial_api_inputs:fact_cnt
serial_api_inputspen_ack
serial_api_inputspen_req
serial_api_inputs:sdk_fdfd_x
serial_api_inputs:sdk_fdfd_y
serial_api_inputs:sdk_pitch_y
serial_api_inputs:sdk_roll_x
serial_api_inputs:sdk_thr_z
serial_api_inputs:sdk_yaw
serial_api_inputs:sub_mode
smart_battery_info:fly_t_for_gh
smart_battery_info:fly_t_for_land
smart_battery_info:gh_level
smart_battery_info:go_home_cmd
smart_battery_info:go_home_cnt
smart_battery_info:land_level
svo_avoid:AL_WF
svo_avoid:AO_EN
svo_avoid:AO_WF
svo_avoid:AO_WF_1
svo_avoid:Boundary_F
svo_avoid:Brake_WF
svo_avoid:FL_F
svo_avoid:GHA_EN
svo_avoid:HGL_WF
svo_avoid:Overshoot_F
svo_avoid:RL_F
svo_avoid:RL_WF
svo_avoid:UA_EN
svo_avoid:V_AL_WF
svo_avoid:V_LL_WF
Tick#
usonic:usonic_h[meters]

 

[WV. Rootman]

I guess the data says different, but I made mistakes about RTH altitude when flying uphill. If I'm 500 ft. el. from home, but 200 ft. el. from ground and it RTH. I have my RTH at 200 ft. It will RTH to my 200 ft. from home el. That puts it a 100 ft. underground at It's location. Can that be a factor in this case?

 

[sar104]

I guess the data says different, but I made mistakes about RTH altitude when flying uphill. If I'm 500 ft. el. from home, but 200 ft. el. from ground and it RTH. I have my RTH at 200 ft. It will RTH to my 200 ft. from home el. That puts it a 100 ft. underground at It's location. Can that be a factor in this case?

No - that's not a problem. For reasons just like that, the aircraft will not descend to the RTH height if it is already above it. It will RTH at its current altitude and then descend directly above the home point.

 

[WV. Rootman]

No - that's not a problem. For reasons just like that, the aircraft will not descend to the RTH height if it is already above it. It will RTH at its current altitude and then descend directly above the home point.

Thank you for clearing up that point for me.

 

[aPpYe]

So I got access to a road near that location from the property owner. Tomorrow morning I will be going up there again, armed with more data. Honestly I just don't see how it could have attempted RTH and not made it back, having only burned through 22% battery on the way out, and still sitting at 61% when connection was lost.

And now for some crazy ideas... I know there are pot farmers in the area who might want to take it out of the air, but a drone moving at that speed at that attitude would make an extremely difficult target, certainly beyond the range of any shotgun. A rifle could reach it certainly, but it would require pretty amazing marksmanship. I don't remember hearing any gunshots anyway. It it possible to hit it with something electronic like a jammer? Could such a thing also prevent RTH after having blocked the signal? Can someone with another remote commandeer it somehow?

I hope it didn't just go nuts and fly off in some random direction...

 

[RunningWithScissors]

I know there are pot farmers in the area who might want to take it out of the air, but a drone moving at that speed at that attitude would make an extremely difficult target, certainly beyond the range of any shotgun.

While anything is possible, I suspect a more rational explanation is likely.

 

[Erised]

The craft usually does not go nuts, just the pilot when we lose connection the first time, I know it happened to me about 2 years ago. I think this could be one of those times. My first OMG situation, I had lost connection over a lake I lost connection then my tablet crashed WTF . So like a newbe I sorta have the panic on, I did not check on my RC if the left light was green (connected) or red (not connected) and hit the RTH, waited and moved around singing I lost my bird! Hit RTH again! Then I regained composure check my RC light (it was green and hit RTH and it started to beep, nice, those few minutes where long and my craft came home. (I still don't have my tablet running) Looking at the video on the card in the craft after the fact I saw what I did. I lost all connection, the craft turned to home and headed back then after a few hundred yards, I not knowing had regained connection I hit RTH and cancelled it, I though I turned it on, you can see on the video the craft just stops, I had moved my RC around and lost connection again (I still don't know this) and the craft auto RTH again and started home, then what do I do I cancel it again, you see it on the video the second stop. That's when I calmed down, saw the green light and new I had a connection without having a running tablet and then manual RTH and the beeping started. The RC does not beep when you lose connection and the craft is in auto RTH. (you gotta have faith at this point and wait for signal to return) If you manually do it with success and a connection it will beep. I think you may have cancelled the auto RTH and the craft hovered till battery low and landed. Hope you find it.

 

[aPpYe]

Heh, I'm pretty sure I kept my cool... I remember setting the controller down and waiting a good while for the signal to come back. I had played with the loss of signal RTH thing a couple times by flying it to over to my neighbor's property (the next canyon) then walking inside my house.

Anyway, I FOUND IT!

It was on the ground between some trees about 70 yards beyond the point of last contact and maybe 30 feet to the right (south-easterly wind of 3.71 mph shortly before loss of contact) ... This supports the loss of power theory.

The battery was about 50 feet south of the drone. It had suffered an impact on the end opposite the side of the power button, so a pretty hard impact after it ejected. The housing was popped open and there was some mud in there. There is some visible corrosion on many of the solder points on the exposed circuit board. The lipo packs are not puffy. I took the casing apart and it is sitting on my workbench. It may or may not be salvageable.

The drone itself had no corrosion on any of the solder points as far as I could tell by a quick inspection (not yet opened up). As the battery was not in it, I think I am going to be okay here... The only visible damage I saw was a couple of broken props and a crack on one of the arms of the upper casing, possibly from the same impact that ejected the battery. I dried it out in an old oven with a pilot light, (maybe 100F?) for a few hours and put in a different battery. Everything so far seems to work just fine. I may have just dodged a bullet here.

The loss of connection setting was set to RTH when I connected the drone.

I want to see if there is any additional information on the .dat flight log, so I would like to upload it for someone to look at. I only have access to a Linux box for the next day or two, so getting the file may require some research. Perhaps someone can point me in the right direction? I may be able to set up a Windows VM tomorrow ... Perhaps there is some way to browse the filesystem from the P4P+ remote?

Okay, it's 2am. I am officially too tired to attempt anything requiring logical thinking.

 

[sar104]

Heh, I'm pretty sure I kept my cool... I remember setting the controller down and waiting a good while for the signal to come back. I had played with the loss of signal RTH thing a couple times by flying it to over to my neighbor's property (the next canyon) then walking inside my house.

Anyway, I FOUND IT!

It was on the ground between some trees about 70 yards beyond the point of last contact and maybe 30 feet to the right (south-easterly wind of 3.71 mph shortly before loss of contact) ... This supports the loss of power theory.

The battery was about 50 feet south of the drone. It had suffered an impact on the end opposite the side of the power button, so a pretty hard impact after it ejected. The housing was popped open and there was some mud in there. There is some visible corrosion on many of the solder points on the exposed circuit board. The lipo packs are not puffy. I took the casing apart and it is sitting on my workbench. It may or may not be salvageable.

The drone itself had no corrosion on any of the solder points as far as I could tell by a quick inspection (not yet opened up). As the battery was not in it, I think I am going to be okay here... The only visible damage I saw was a couple of broken props and a crack on one of the arms of the upper casing, possibly from the same impact that ejected the battery. I dried it out in an old oven with a pilot light, (maybe 100F?) for a few hours and put in a different battery. Everything so far seems to work just fine. I may have just dodged a bullet here.

The loss of connection setting was set to RTH when I connected the drone.

I want to see if there is any additional information on the .dat flight log, so I would like to upload it for someone to look at. I only have access to a Linux box for the next day or two, so getting the file may require some research. Perhaps someone can point me in the right direction? I may be able to set up a Windows VM tomorrow ... Perhaps there is some way to browse the filesystem from the P4P+ remote?

Okay, it's 2am. I am officially too tired to attempt anything requiring logical thinking.

Nice result - that was always going to be the most probable explanation. The aircraft DAT file is recorded at a high enough sample rate to see the voltage drop in sudden power failure events, so it is worth a look - just for final confirmation.

If the battery was that far from the aircraft then it may have ejected fully in mid-air, and the reduced mass of the aircraft may have contributed to the relatively light damage.

 

[aPpYe]

Well, I did neglect to mention that south is also downhill and steep from the drone. The fact that the smash was on the inside end is suggestive that it ejected before hitting the tree or the ground:

The placement of the crack on the hull is suggestive that the battery may have ejected upon impact:

I have performed my own DIY repair and am satisfied with it:

Anyway, I have uploaded the .dat files to google drive, and I am hoping you might be willing to take a look? The first file is what dji assistant generated when it exported the log from the drone. The second is what was on the mounted drive letter for the drone itself, I guess that is its native form or something. Here is the link:

DroneLogs - Google Drive

Thanks for all the help!

 

[Rick218]

I have never had to save a flight log or open one... when I attempted to open this one it's all scrambled... what program do I need to use to read it?

 

[Neon Euc]

I have never had to save a flight log or open one... when I attempted to open this one it's all scrambled... what program do I need to use to read it?

If your on Android then follow these steps

1) go to files and select DJI

2) select DJI PILOT

3) select flight record

4) select the most recent one at the top and upload on here

Hope that helps buddy [emoji4]

 

[aPpYe]

This is the dat file from the aircraft I am wanting to examine, not the txt file from the remote or tablet. Unfortunately, the walk through above will not apply...

 

[msinger]

You can view the data in DAT flight logs with CsvView or DatCon.

 

[aPpYe]

yep ... I am going to have to decipher these readouts. I am trying to figure it out... I will play with it tomorrow

 

[aPpYe]

Nice result - that was always going to be the most probable explanation. The aircraft DAT file is recorded at a high enough sample rate to see the voltage drop in sudden power failure events, so it is worth a look - just for final confirmation.

If the battery was that far from the aircraft then it may have ejected fully in mid-air, and the reduced mass of the aircraft may have contributed to the relatively light damage.

What columns should I be looking at in the dat log to compare data to the txt log? I figure I want to determine whether or not the dat log records any time after where the txt log cuts off, as well as look for the battery voltage items you mentioned...

 

[Rick218]

If your on Android then follow these steps

1) go to files and select DJI View attachment 97892
2) select DJI PILOT View attachment 97893
3) select flight record View attachment 97894
4) select the most recent one at the top and upload on here View attachment 97895

Hope that helps buddy [emoji4]

Thanks... as mine is the p4p+ I have never connected to a computer, phone or tablet... guess I need to stop flying and figure it out! LOL

 

[sar104]

What columns should I be looking at in the dat log to compare data to the txt log? I figure I want to determine whether or not the dat log records any time after where the txt log cuts off, as well as look for the battery voltage items you mentioned...

The effects of power loss are normally visible in the motor voltage data. However, in this case there are no such indications. The end of the DAT log is somewhat confusing, with a discontinuity in the offsetTime and other data. It may be a case where the file was not properly closed and includes other data.

Ignoring that, the DAT data effectively stop 0.218 s after the end of the txt log. The only unusual features that stand out are the gyro X, Y, Z data, which show some strange excursions starting at 421.88 s (369.17 s relative to txt flight time) and lasting 0.145 s until the end of the sensible data.

I'm not sure what to make of this. There are no relevant log entries. I'll keep looking.

 

[DJI_Stunt_Pilot]

the main question I have at this point would be where a good point to find the craft would be.

A buddy of mine lost his P3P when the wind and loss of direct L.O.S. took his away from his HPLZ. I used my P4P and his flight records. Directly above his last known location camera down in landing mode flew an increasing spiral around this point. 10 minutes into it we found his. I set a GPS marker changed battery and returned to hover over his craft while he treated the thickets to find his. I returned to my HPLZ then joined him. Had to climb about 30 foot into a tree and used a fishing pole with a truble hook to retrieve his.
It was 2 weeks from loss to recovery, we had rain during this time. After a very thorough inspection and then battery change, his P3P was fine.
If you can contact someone living close to the area that has another drone, this might be an easier option. Scott had been through those trees almost every day for 2 weeks looking for his. We found it in less than 30 minutes including preflight time.

 

[aPpYe]

...If you can contact someone living close to the area that has another drone, this might be an easier option...

Heh ... actually the drone was found several days ago. Check out a few posts up. I actually did find a guy who lives near me and he came up to try and find it with his Mavic, but we didn't have much luck. What actually helped me the most was the telemetry data from the log. Sar104's red line projection and wind data (a few more posts up) was the most help. I found it just to the right and about 70 yards beyond the end of the yellow line, just as the telemetry predicted... Some strenuous hiking and that fantastic moment when I found it was all worth it. I have my drone back now!

The effects of power loss are normally visible in the motor voltage data. However, in this case there are no such indications. The end of the DAT log is somewhat confusing, with a discontinuity in the offsetTime and other data. It may be a case where the file was not properly closed and includes other data.

Ignoring that, the DAT data effectively stop 0.218 s after the end of the txt log. The only unusual features that stand out are the gyro X, Y, Z data, which show some strange excursions starting at 421.88 s (369.17 s relative to txt flight time) and lasting 0.145 s until the end of the sensible data.

I'm not sure what to make of this. There are no relevant log entries. I'll keep looking.

View attachment 97933

I noticed some weirdness there as well. There is a gap somewhere in the middle with motor speeds of 0 as well... As you indicated, the file may be corrupted somewhat. I am happy to see that the data confused you as well. I did notice that the GPS data does extend perhaps 30 feet beyond what is seen in the txt file. I am glad you know how to decipher the timestamps ... I couldn't figure out how to correlate them with the txt file. It seems the power did indeed go out on it for some reason, and it more or less traveled and landed as predicted given that scenario.

While I am feeling somewhat vindicated as to my poor flying choices, I am now unsure if I can trust it not to do the same thing... Perhaps it powered off because I pushed it too hard? It was in sport mode for several minutes with the sticks more or less jacked up to the tops? I don't know. Wouldn't the electronics have some sort of failsafe for this? After the first crash a few weeks ago, I inspected the esc boards (and every other board) pretty closely and there was no sign of impact or any other damage.