Advise on GPS alternatives

[Richard]

I have some issues in regards with the FrSky GPS, that several other have have as well in the sense of the delay between the data received at the transmitter and the actual geographical location of the plane.
I have seen that people have developed LUA scripts to show graphical data on the transmitter, based in GPS data, which seems to be just simple programming exercise rather than something that can be used in real life. Some of those scripts are supposedly intended for racing (with 5 to 10 sec data delay?).
Anyhow, the way I see this, is that the FrSky GPS has limited use for any application that requires almost real time information, whether this is for racing, autonomous flight (not that I recommend that), or crash site location.
With that said, I will be very happy to have some feedback on those using the Taranis telemetry for racing, soaring, or any other activity that requires almost real time data, to know which GPS are you guys using.
Carbo suggested already the openXsensor solution, which is fine, but regardless, I would like to know if there are other alternatives, more the type of "plug and play", considering that I am trying to avoid to go back to software programming classes.
Thanks a lot.

[bob195558]

Do you think this junk FrSky V2 GPS (https://alofthobbies.com/frsky-sp-gps-s ... ps-v2.html) is both a hardware and firmware problem
....... or could it be fixed with new firmware alone ?

FrSky V2 GPS: (https://www.frsky-rc.com/product/gps-2/).

FrSky GPS (V2) Sensor using Smart Port (S.Port): (viewtopic.php?f=95&t=8922&hilit=GPS+V2+Sensor).

Bob B.

[Richard]

Bob, I don't have a clue how FrSky can fix this shortcoming on the GPS.
One way or another, I don't think that if it is a firmware problem, we will be able to upload it to the devices. I don't think the GPS is hardware is designed to have firmware uploaded in the field.
From the point of view of obtaining the last real location, I am working in a "power back up", in the case that the main battery gets disconnected from the radio, but as for having real time data for real good applications, we are doomed with the current device.
Anyway, may be someone knows better than me, and may come with a solution to the existing hardware, but I won't hold my breath.

[Kilrah]

There's this if you're ready to shell the cash... https://www.sm-modellbau.de/GPS-Logger-2
Don't know of other ready-made alternatives.

There are several build therads for openxsensor based devices around.

[Raythegreat]

Hi Richard,

I have two FrSky GPS V2. Here is my opinion.
They seem to lock under one minute when outside but inside the house more than 7 minutes and sometimes never, but this is normal inside.
The GPS positions seem to be OK, pretty precise when the GPS is not moving, less good if it's moving because it is slow (1 hz).
However, I'm not sure if the speed and altitude work well. They seem off a little bit but difficult to verify.

The big disappointment is of course the large delay (approx. 5 seconds). It seems to vary from 3 to 7 seconds.
Not sure why there are some variations.
I hope there is no delay added by openTx or the smart port. I don't think so.

But what I find the strangest thing is the fact that a 1 Hz GPS has a delay of 5 seconds.
This means there must be some sort of memory buffer inside the device to "store" positions.
When the airplane is stopped the GPS continue to send different positions for 5 more seconds, so it needs some sort of buffer.
This means there might be some "improvements" possible to eliminate this delay but it would need FrSky to do it.
What I find more disappointing is that FrSky support is difficult to get for this type of problem.

If someone knows how to reach them, please let me know and I will ask some questions.

All and all for a $30 device it is functional but the delay is the killer, else it would be very acceptable.

I also use a GPS mainly to locate my airplane in case of a crash.
I found that buzzers are not enough in a big corn field when there is wind. You can't hear a 90 db buzzer in these conditions.

If someone has a better idea to locate an airplane other than a buzzer please let me know.
Yes a good GPS like Kilrah suggested would work but it is expensive.

What is good about openTX is that the transmitter will keep the last telemetry results after losing Rx power.

RTG

[mstrens]

As Carbo said, openXsensor seems to be a good solution.
You can build the gps sensor for about 15 € and it can provide data at 10 hz (if you select a NEO7M or a NEO8M module).
It does not requires programming skill. You just have to edit some options in a configuration file and upload the firmware with arduino IDE and a FTDI serial converter (USB to serial).
On the hardware side you just have to solder
- a servo cable to arduino pro mini
- 4 wires between GPS module and arduino.
If you can't edit the config files your self, I can easily provide you the files.

[bob195558]

Some GPS openXsensor info here: (viewtopic.php?f=86&t=8417&hilit=GPS+ope ... r.#p123156)
and" GPS Sensor" for openXgps sensor: (viewtopic.php?f=86&t=7562&hilit=GPS+openXsensor)
and "OpenXVario - an open source vario supported by the open source firmwares!!" (viewforum.php?f=86).

[Raythegreat]

Thanks all,

I will certainly look at this stuff after this summer. I'm in Canada so the summer is almost gone. A few more weeks.
The FrSky GPS is very disappointing because of the long delay and seems slow in general.

A 1 Hz GPS with a delay of 5 seconds may be an indication of lost positions and data between good data.


RTG

[Richard]

Raythegreat, I also have two GPS V2, and I agree on all your statements. I was initially disappointed when I made some scripts and found out that the data I was getting was way delayed bit time, but at that time I didn't realized that the culprit was the GPS itself.
I sent a message today to FrSky, in regards with this issue, just asking if they are doing something to fix it, either with new HW, FW or whatever. Will see if they come back to me.

mstrens, Thank you for your response and offering. I will go for the NEO7M and the arduino board, and sure enough when I get hands on them I will request your help. On the hardware side I am good enough to solder parts. Have been doing that for a few years. May be with some push, I may make it to the code, but that will be later.

Kilrah, thanks a lot for the link, as you suggested they are over their head with the pricing. I honestly think that if FrSky takes the challenge they will come with a way lower price. ANyhow, it looks that openXsensor is the way to go today.

Thanks a lot to all of you guys.

[Raythegreat]

Hi all,

I have second thoughts about the FrSky GPS being the only culprit of a long delay.
A 1Hz GPS should be able to send data at 1 Hz without using a memory and have a 5 seconds delay of positions recorded earlier.

A 1 to 2 second delay with some of the smart port sensors isn't uncommon. It has to do with how the telemetry receivers prioritize the information going back to the radio. Essentially, more critical information like RSSI and voltage are sent more frequently, while less critical information is sent less often. So I'm now reluctant to say the GPS is the only culprit in delays.

Is there someone using a 5HZ GPS with FrSky smart port receivers that can guaranty a delay less than a second or two at all times?
Including the Arduino stuff?

RTG

[Carbo]

Is there someone using a 5HZ GPS with FrSky smart port receivers that can guaranty a delay less than a second or two at all times?
Including the Arduino stuff?

Do you know an appropriate way to test it? I am not sure, how this can be done. OK, beside smash the plane into a wall, to stop moving and telemetry immediately, then compare crash and log coordinates...

When i zoom into a touchdown with my glider, i can see that airspeed, vertical speed, GPS speed and GPS coordinates are chronologically corresponding. This is also my personal impression with the openXsensor 5Hz GPS. Vertical speed of oXs is known to have very low delay, this implies, the other values have also a acceptable low delay. Btw. i did not land the plane, where i started it, the displayed 8,5m are bottom level.

[bob195558]

Here is my experience with the FrSky GPS V2 Sensor using Smart Port with X8R: (viewtopic.php?f=95&t=8922&hilit=GPS+V2+Sensor).

Seems better for us to make our own GPS at this point in time: (viewforum.php?f=86).

[Richard]

Carbo, you have set a challenge. How to know if we are getting real time data without crashing the plane. I think it is possible. Will come back with some idea, after figuring it out and testing it in the field.

[Richard]

Bob, I think you are looking for accuracy, and that is fine. I noticed the FrSky is not military grade, but seems to be close enough. However, refresh speed, or if you would, real time data, is disgusting. When you fly a plane and you have location, heading, speed or altitude 10 seconds late, your plane may well be in big hole in the ground. Unfortunately, speed and altitude can be solved with other sensors, but geographical location has no alternate solution. My last experience was that according with the data received the crash location was 30m high and 130m NW from the actual crash site. Therefore, what would we want a GPS for?
As I said, in my project, I will try to answer Carbo's challenge measuring the real delay and then see where to go.

[Carbo]

Well, i feel challenged
Here is a possible way to measure the delay non-destructive. Put GPS and RX in (or better on top of) a car, drive it with constant speed over a point with known coordinates. Make a video, where you can see the received coordinates on the TX display and the position of the driving car. With 30 frames/s there is a good enough resolution. But with FrSky GPS you want slow car speed or a fisheye lens

[rcbrust]

Are you guys aware that someone has worked on new firmware for the FrSky GPS to address this issue? We had a discussion of using FrSky equipment to do GPS triangle racing (soaring) and the FrSky GPS delay became quite apparent. One of the participants decided to try rewriting the GPS firmware to reduce the delay and I believe he succeeded. His thread is here.

Randy

[Carbo]

I know this, but it is much more complicated, than to build your own oXs GPS. But if you were able to flash it, it would be good, to measure its delay, so we can compare against FrSky standard and oXs.

[devil]

I have already done some tests with Frsky GPS V2, SM GPS Looger and also OpenXsensor and I think this log should clarify your questions.
You can see very well that all the values at the landing go to zero.
Only airspeed is not quite at zero, that is from the wind at the slope.

The same test with Frsky GPS V2 and Sm GPS looger has a very big delay and very very inaccurate.

The log is from OXS sensor and M8N GPS, if you can move your model you can meter for meter, life on the Taranis Dysplay see almost no lag.
Important is a good HDOP from the GPS module and enough satellite

[Carbo]

I have just finished the oXs GPS Exlusive 10Hz Edition , it will fight tomorrow against a F4 flightcontroller with M8N GPS over Smartport.

[bob195558]

Bob, I think you are looking for accuracy, and that is fine.
I noticed the FrSky is not military grade, but seems to be close enough.
However, refresh speed, or if you would, real time data, is disgusting.
When you fly a plane and you have location, heading, speed or altitude 10 seconds late, your plane may well be in big hole in the ground. Unfortunately, speed and altitude can be solved with other sensors, but geographical location has no alternate solution.
My last experience was that according with the data received the crash location was 30m high and 130m NW from the actual crash site.
Therefore, what would we want a GPS for ?
As I said, in my project, I will try to answer Carbo's challenge measuring the real delay and then see where to go.

Hi Richard,
Thank you for your reply as it help to understand and/or remember how to use the GPS data.
My expectations of the FrSky GPS V2 Sensor is caused from my comparison to my car GPS.
Which most of the time is spot-on-accurate, whether stationary or traveling 65 mph (little to no data delay).

For some unknown reason, the FrSky GPS V2 Sensor I have, will some times give data saying it is moving up when it is moving down
and when moving down give data saying it is moving up.
And 10 seconds of time has past by a long time ago.
The data being recorded seems to be just bad data 60% of the time also.

Bob B.

[Carbo]

Unbelievable good result with the openXsensor 10 Hz GPS: i made 20 trials and the maximum delay was 0.2s. I drove with my car with 10 m/s in east and west direction (forward and backward). The first picture shows the position of the sign (marker) with the car not in motion. The second picture shows the marker and the GPS position driving with 10m/s = 36 km/h. My car cannot drive faster backwards

In the 60 frames/s GoPro Video it is possible, to watch every frame. Max. 12 frames after passing the marker the X9D showed the true position of the marker.

I did not evaluate the F4 video yet, but the F4 can hardly be faster

Edit: Presumably this result is only possible, because the Ublox M8N predicts the position, using heading and speed. What i have measured is more or less the delay of the FrSky telemetry. The result is still astonishing.

[Raythegreat]

Hi Carbo,

This is good news. This means the delay really comes from the FRSky GPS V2 and not the combination Tx-Rx and openTx.
Can you please summarize what you did and what you used (or bought) to plug to X FrSky receivers?
There are so many threads on this that it is sometimes confusing. I saw many of them but they are all around.

Is there a single thread that explains step by step what to do instead of looking at several threads?

Thanks
RTG

[Carbo]

Is there a single thread that explains step by step what to do instead of looking at several threads?

I tried to make a quick overview here:
viewtopic.php?f=86&t=10472&p=131569#p131569

[Raythegreat]

Thanks Carbo.

RTG

[Richard]

Gents, Here are the observations I did on the flying field last Friday:
1) I set my logging every 1 sec.
2) Disregarding whether the log is or not active, the telemetry is always active, meaning that there is telemetry traffic as far as the RX has power.
3) The FrSky GPS V2 / Transmitter refreshes the position every second (I didn't try to set the log at a higher rate (less than 1 second)).
4) After the GPS locks on the satellites, there is a delay that I measured pf up to 10 sec for the GPS to synchronize time and date with the TX.
In one situation, there was a delay in refreshing the location at the time the GPS synchronized date and time. However, I reviewed former logs I have and did not find a similar situation.
5) The GPS time is updated in the log every 10 seconds.
6) As I agreed before, the actual location does not match the GPS reported location. However, because I was not looking to verify accuracy, but time delay, I cannot make comments about it. The only (and not fully reliable) data I have is that there it may be an error of about 15 to 20 meters. Anyhow, hopefully this week I will be able to run additional measurements, first giving the GPS time to have all synchronization completed, and then make a couple of low passes, and verify the location.
I am filming the process with time stamp, to confirm the location (just in front of me) of the plane and compare it with the data logged. I may use as a secondary check an unused switch toggle. That will also help me to figure out if there is a noticeable delay between local (TX generated data from switches and sticks) and remote data (that from the receiver).
Any comment will be welcome.

[Richard]

Unbelievable good result with the openXsensor 10 Hz GPS: i made 20 trials and the maximum delay was 0.2s. I drove with my car with 10 m/s in east and west direction (forward and backward). The first picture shows the position of the sign (marker) with the car not in motion. The second picture shows the marker and the GPS position driving with 10m/s = 36 km/h. My car cannot drive faster backwards

In the 60 frames/s GoPro Video it is possible, to watch every frame. Max. 12 frames after passing the marker the X9D showed the true position of the marker.

I did not evaluate the F4 video yet, but the F4 can hardly be faster

Marker0.jpg

Marker.jpg

Edit: Presumably this result is only possible, because the Ublox M8N predicts the position, using heading and speed. What i have measured is more or less the delay of the FrSky telemetry. The result is still astonishing.

Well, here you pointed out an interesting point, which I (fool of me) missed. You are using a X9D, while I am using one of the first series Taranis running 2.0.18. Regardless the hardware difference (that may or may not be that important), most probably you are using a 2.1.X of higher, isn't it?
The other thing that we should not miss is that while the telemetry comes straight to the transmitter screen, you cannot drive a RC vehicle and at the same time look at the transmitter screen (unless you use some very advanced and expensive goggles), and normally you use the log for further analysis. I have to admit, that I may be quite wrong in this statement though, and if some one can bring me to speed, I will appreciate it.

[Carbo]

Hey, hey, my good old Taranis X9D is also from 2013, only she insisted in some plastic surgery. From my experience, there is also no difference regarding telemetry speed of the different OpenTX versions.

A small camera (GoPro, wingcam or similar) is able to watch the display and the model simultaneously, but the exposure is critical. Mostly the display is too dark. Sunset is presumably a good time for your experiment.

[Richard]

Hahaha. I din't mean to say the old lady X9D was that old. Boy, your suggestion about "following" the plane with the TX is over my skills on top of the sunlight issue. However, if there is a time shift between the screen and the log, there is no other culprit than the TX. You were able to demonstrate that what you see in the screen is consistent with the NEO8 GPS, and that proves at least that the NEO8 provides accurate information to the TX and that the TX displays that information in real time. So far so good. Let's see if I can get something related to the logs and positioning before Irma hits us with the FrSky V2.

[Richard]

Well, after a number of tests in the car and in the plane, plus picking the brain of one FrSky expert, it seems that at this point the only alternative is the DIY GPS. Therefore, I will start the project in short, but I need some additional information from those that already are using the NEO 7 or 8 and the arduino. Therefore, here is the question:
Besides the coordinates, does the NEO + Arduino GPS provides Altitude, heading and speed? Is there anywhere where I can see which parameters are transmitted back to the TX?
Thank you guys.

[Carbo]

Yes and yes
oXs_out_frsky.cpp:

Code: Select all

#if defined(GPS_INSTALLED)
    struct ONE_MEASUREMENT sport_gps_lon ; 
    struct ONE_MEASUREMENT sport_gps_lat ;
    struct ONE_MEASUREMENT sport_gps_alt ;
    struct ONE_MEASUREMENT sport_gps_speed ; 
    struct ONE_MEASUREMENT sport_gps_course;
    extern bool GPS_fix ;
#endif