Gents I need some help here to understand what is going on with the telemetry logs. I had a crash, and the telemetry data is really weird.
Transporting the data to google earth, the last geographical location of the plane was about the place I noticed I lost control, that would tell me that the receiver for one or other reason stop working. However, given that I tried to minimize the damage I sent aileron, elevator and throttle commands, even there was some sporadic response given the plane attitude, those commands were not logged. I verified that stick movements are logged regardless of the receiver operation, therefore, there some strange situation, because according with the data log, the telemetry ended at the time of the crash, however the last GPS location in the log indicates that the plane was above ground level and about 100m away from the crash site.
Please, find attached the log as well as the google earth screenshot.
Telemetry inconsistency or malfunctioning?
-
- Posts: 183
- Joined: Sat Mar 29, 2014 10:44 pm
- Country: United States
- Location: Coral Springs, FL
Telemetry inconsistency or malfunctioning?
- Attachments
-
- Yak-130-2017-08-15.csv
- Data log good flight and crash flight
- (432.25 KiB) Downloaded 292 times
Richard
Re: Telemetry inconsistency or malfunctioning?
Sorry for your loss. The log shows valid RSSI until you stopped to control the plane. Therefore up- and downlink were always working, no problem here. The FrSky GPS V2 has a time lag of some seconds. This explains the different location of the crash spot and the last logged GPS position. Your planes GSpd was about 20 m/s.
-
- Posts: 183
- Joined: Sat Mar 29, 2014 10:44 pm
- Country: United States
- Location: Coral Springs, FL
Re: Telemetry inconsistency or malfunctioning?
Thank you for your response Carbo.
If i understood correctly, there is a time offset of 5 to 10 seconds (don't know how did you came to the plane speed of 20 m/s) between the downlink data (RSSI, GPS, etc) and the locally generated data (joysticks position).
If that is the case, the way the log is generated must be corrected to compensate for that offset, or otherwise in the Companion, to make the correction when the log is displayed, or sent to the Google Earth application.
If i understood correctly, there is a time offset of 5 to 10 seconds (don't know how did you came to the plane speed of 20 m/s) between the downlink data (RSSI, GPS, etc) and the locally generated data (joysticks position).
If that is the case, the way the log is generated must be corrected to compensate for that offset, or otherwise in the Companion, to make the correction when the log is displayed, or sent to the Google Earth application.
Richard
Re: Telemetry inconsistency or malfunctioning?
Richard,
my english trials are sometimes hard to understand, sorry for this. What i meant is: Only the data from the FrSky GPS is delayed several seconds. I suppose, it is an issue of the GPS firmware. When you use an openXsensor GPS like me, you will notice a much shorter delay.
I have never measured the delay between stick movement data log and telemetry data log, a careful estimation is 0.1 to 0.5s. But you made a good point, i will try to measure the delay out of interest. Or one of the experts here can tell us.
To be clear, at the time, when your plane crashed, the GPS transmitted the position, where the plane was about 5s earlier. A correction afterwards can not determine the crash position, because the FrSky GPS had not enough time at all, to send it.
The estimated speed of your plane is simply converted from the logged GPS groundspeed, to verify the 100m (5s x 20 m/s) difference between the two spots.
Bernd
my english trials are sometimes hard to understand, sorry for this. What i meant is: Only the data from the FrSky GPS is delayed several seconds. I suppose, it is an issue of the GPS firmware. When you use an openXsensor GPS like me, you will notice a much shorter delay.
I have never measured the delay between stick movement data log and telemetry data log, a careful estimation is 0.1 to 0.5s. But you made a good point, i will try to measure the delay out of interest. Or one of the experts here can tell us.
To be clear, at the time, when your plane crashed, the GPS transmitted the position, where the plane was about 5s earlier. A correction afterwards can not determine the crash position, because the FrSky GPS had not enough time at all, to send it.
The estimated speed of your plane is simply converted from the logged GPS groundspeed, to verify the 100m (5s x 20 m/s) difference between the two spots.
Bernd
Re: Telemetry inconsistency or malfunctioning?
The FrSky GPS sensor is very slow. Rest is delay-free.
-
- Posts: 183
- Joined: Sat Mar 29, 2014 10:44 pm
- Country: United States
- Location: Coral Springs, FL
Re: Telemetry inconsistency or malfunctioning?
Bernd and Kilrah thank you for the clarifications.
The main reason I was using the GPS is to locate the plane in the event of a crash. I was lucky enough that I did not crash in the swamp, because 100m radius it would be impossible to search.
Therefore I now have a way better understanding of the problem, and that takes me to replace my GPSs, as they are not able to provide the vital information I need.
With that said, Bernd, I will appreciate if you can fill me with the details of the OpenXsensor GPS to take a look at it.
Thanks a lot for your help and clarifications.
The main reason I was using the GPS is to locate the plane in the event of a crash. I was lucky enough that I did not crash in the swamp, because 100m radius it would be impossible to search.
Therefore I now have a way better understanding of the problem, and that takes me to replace my GPSs, as they are not able to provide the vital information I need.
With that said, Bernd, I will appreciate if you can fill me with the details of the OpenXsensor GPS to take a look at it.
Thanks a lot for your help and clarifications.
Richard
Re: Telemetry inconsistency or malfunctioning?
Do not hesitate, to start a new thread here, if you are not familiar with Arduino. The developer and others will assist you. Unfortunately there is no 'openXsensor for beginners' thread, so it is time to start one, if you are a beginner. The developer mstrens is working on making oXs more beginner friedly and thoughts of actual beginners are very welcome.
openXsensor GitHub + download + first steps
Fullhouse openXsensor with GPS, airspeed, vario, voltage
You will need an Arduino nano (or pro mini 328 5V + FTDI if every mm counts) and a Ublox neo M6, M7 or M8 GPS unit and some basic soldering skills. The Arduino sketch is ready to go, only some configuration changes have to be made with a texteditor (notepad++ is my favourite).
Bernd
openXsensor GitHub + download + first steps
Fullhouse openXsensor with GPS, airspeed, vario, voltage
You will need an Arduino nano (or pro mini 328 5V + FTDI if every mm counts) and a Ublox neo M6, M7 or M8 GPS unit and some basic soldering skills. The Arduino sketch is ready to go, only some configuration changes have to be made with a texteditor (notepad++ is my favourite).
Bernd
-
- Posts: 183
- Joined: Sat Mar 29, 2014 10:44 pm
- Country: United States
- Location: Coral Springs, FL
Re: Telemetry inconsistency or malfunctioning?
Thanks for the lead Bernd. Will look into the links that you sent me and go from there. Sure enough I have seen Arduino all over the place, but never put my nose in one of those boards. Therefore, may be I will soon start the new thread as you suggested.
Richard