S.Port GPS-Time

[onki69]

Some transmitters set the internal time when a GPS-Time-protocol is received from a sensor. Is this something that can be added to the protocol?

Best regards Onki

[mstrens]

When a GPS is connected, oXs transmits the date and time in Sport protocol. It is then up to the handset firmware to handle it or not to update his internal clock.

[onki69]

If I understand correctly the time is transfered but not available as telemetry parameter? It does not seem to work correctly. When I use a SM GPS-Logger 3 the time is a separate telemetry value and the transmitter clock is set automatically. I have tested this with the 1.8.1 version and a valid 3D fix but my transmitter clock is still 1 hour behind. Will double check this with the GPS-Logger 3

[fourfingers4]

@onki69 you may try setting your time zone (+/- X hours) on the transmitter, in respect to UTC time being send from gps.

[onki69]

Time zone is set correctly. I will try it with another receiver (Archer M+). With a Radiomaster R16 it does not seem to work. It is not only 1 hour behind the time itself is also wrong as the RTC of my X20 is drifing quite significant (even with correction factor set). Why there is no telemetry value for the date/time such with the GPS-Logger3? Is the this only mused internally?

[fourfingers4]

I believe, at least with RM tx16s, gps time is updated if an internal gps is present at the transmitter, not from the telemetry gps.

[Satcomix]

Hello Mstrens, Since the latest version from yesterday, my X20S handset system clock no longer updates itself automatically from the GPS Date/Time Sensor 0x850. Usually has nothing to do with the oXs system clock of 133MHz, right? br, Torsten

[mstrens]

there is no relation between GPS time and oXs clock. Do you get the other GPS data?

[Satcomix]

Edit: FYI It was related to the new Ethos software. Ethos 1.4.8 works with GPS and automatic time from GPS

Hello Mstrens, I get all 34 values ​​displayed properly. Only the time from the handset (very, very imprecise) no longer wants to update, although I have the button in the time menu set to update automatically. I'll search the FrSky GitHub for possible reasons, there are enough unsolved problems at Ethos. Thanks for your answer, Greeting, Torsten

[onki69]

I did some testing about a week ago. Still no success with my x20(S) and Ethos 1.5 Nightlies. To check if this is Ethos related I tried it with a GPSLogger3 (SM-Modellbau.de). As soon as I got a fix the time on the transmitter was corrected (with the GPSLogger3). The only issue was a 2h shift but this was related to the settings in the GPSLogger3 as the time zone can be adjusted there. The GPS module I use is a uBlox 6M. It was reset to factory settings (9k6). Time is shown in Ublox Software.

[mstrens]

With oXs, when you ask for discovering the sensors, do you get the GPS data and time in the list of sensors? Are the oXs values displayed in the telemetry list correct and in the same format as with GPSLogger3?

[Satcomix]

I'm starting to suspect that the date/time data packet from an M6 GPS module is structured a little differently and oXs or Ethos can't understand it. I found something about M6 and M8 Time. Look at GNSS TIME https://discuss.ardupilot.org/t/gps-inconsistent-handling-in-ardupilot-and-zubax-uavcan-ap/17057

[mstrens]

It is oXs that decodes the date and time values received from GPS in some frame types. I know that Ublox added/deleted frame types but I do not expect that they changed the frame format when moving from M6 to M10.

[Satcomix]

I'm currently searching the net for M6N Time problems, and it looks like it's not the frame format, it's a specific setting in the M6, or it is a problem with setting the ROLLOVER-Timestamp-Complement Unfortunately I don't have one here, only M8 and M10

[mstrens]

I do not have anymore a GPS to test. With a M8 or M10, do you get

• date and time as telemetry fields
• if yes, are the values correct when you ask to display them on a telemetry screen. Perhaps I do not send the values in the right format.

[Satcomix]

I make a test with Ver. 2.3.0_Test with FBUS Protocoll and a FrSky X20S with TD-R10 Receiver and a Beitian BE-250 M10 and BN-220 M8 The GPS time is UTC and ok and the Handheldtime is set from GPS with UTC+2h The Display shows 2023-05-08 14-43-46 The only lag I have in the seconds range comes from the refresh rate of the 32+8 telemetry sensor readings as my time is only updated every 3 seconds. Cmd to execute: FV

GPS Latitude = XX.1225248 degree GPS Longitude = X.7172880 degree GPS Groundspeed = 4 cm/s GPS Heading = 305.120000 degree GPS Altitude = 3953 cm GPS Num sat. = 122 GPS Date J M A = 8 5 23 GPS Time H M S = 12 43 46 GPS Pdop = 128 GPS Home bearing = 164 degree GPS Home distance = 9 m Volt 1 = 1839 mVolt Current (Volt 2) = 1656 mA Volt 3 = 1601 mVolt Volt 4 = 213 mVolt Capacity (using current) = 13367 mAh Vspeed = 1 cm/s Baro Rel altitude = 122 cm Pitch = -4 degree Roll = -1 degree RPM = 999 Hertz Ads 1 1 = 119 mVolt Ads 1 2 = 119 mVolt Ads 1 3 = 119 mVolt Ads 1 4 = 119 mVolt Ads 2 1 = 119 mVolt Ads 2 2 = 119 mVolt Ads 2 3 = 119 mVolt Ads 2 4 = 119 mVolt Airspeed = 30 cm/s Compensated Vspeed = -16 cm/s Gps cumulative distance = 981 Vspeed compensation = 1.15

[Satcomix]

Hello Mstrens, Hello Onki, FYI: An issue with GPS Time was opened in the FrSky GitHub. The user still has Ethos version 1.4.7 installed. I've done my testing on Ethos version 1.4.8 and Nightly and haven't noticed anything unusual. Very strange, since the user also receives untraceable date and time values ​​on the handset from an original FrSky ADV GPS. https://github.com/FrSkyRC/ETHOS-Feedback-Community/issues/2632 Greeting, Torsten

[bsongis-frsky]

For dev purposes I can provide a special Ethos firmware, which will write a sport.log file with the raw S.Port stream. It helps to track such issues and know if Ethos or the custom sensor are involved

[Satcomix]

For dev purposes I can provide a special Ethos firmware, which will write a sport.log file with the raw S.Port stream. It helps to track such issues and know if Ethos or the custom sensor are involved

Hello Bertrand, Thank you for your quick reply, here on oXs. I think such an Ethos variant to read would be a very good thing. But what I don't understand are the problems with the GPS date/time data, I own an X20S with a TD-R10 and from June an X20PRO :-)) I had no other problems with original sensors or the oXs_RP2040, also not with the date/time, except for the telemetry problem in the Nightly (which was fixed directly), while others have these problems also on original FrSky sensors, very strange this behavior . Greetings, Torsten

[jasc76]

I have these issues too... x20s ethos 1.4.8

[Satcomix]

I have these issues too... x20s ethos 1.4.8

Hello Jasc76, Hall everyone, I know about the GPS date/time problems that some users of original FrSky GPS-ADV or oXs_RP2040 GPS have. Bertrand and his FrSky Ethos team are also aware of these issues. I just can't explain it to myself because I don't have these problems, for whatever reason? I tried to reproduce the error by only defining an oXs_RP2040 as GPS Phys.ID03 0x83, and no other telemetry data is transmitted in the frame. I always get an exact time regardless of whether I switch on the transmitter first and then the GPS telemetry on the oXs or vice versa, switch on the oXs with GPS first and then the transmitter. I can also disconnect and reconnect the GPS, the time does not exist for the time of the disconnect, and reappears and syncs again after a successful connection. Bertrand had spoken of an analysis software that he wanted to make available to those involved, but he did not comment on the GPS topic. I found this software on FrSky GitHub at 08/05/2022 from Wismy Yao. I just can't promise success by evaluating the data as it will clearly be down to the ethos and not the different GPS systems. https://github.com/FrSkyRC/ETHOS-Feedback-Community/issues/1827#issuecomment-1205998699 Best regards, Torsten

[jasc76]

FUNJET-2023-05-20-19-07-06.csv

Here is a log. At first the GPS Time is 2023 all good, but after a period with no reception it's suddenly 2015

[Satcomix]

FUNJET-2023-05-20-19-07-06.csv

Here is a log. At first the GPS Time is 2023 all good, but after a period with no reception it's suddenly 2015

Hello jasc76, I could never find these problems with me, that the time/date shifts by a few years. Is it maybe related to the ROLLOVER timestamp complement? Which GPS board and which receiver do you use with your X20S. I use the X20S with TD-R10 and FBUS protocol with Beitian M10 chip (BE-220 to 450) br, Torsten

[jasc76]

in this plane I use: I think its a BN220 REceiver S6R S.Port

[jasc76]

this might help in future https://github.com/FrSkyRC/ETHOS-Feedback-Community/issues/2513

[romoloman]

in this plane I use: I think its a BN220 REceiver S6R S.Port

I think that the main problem is the gps module you are using, It uses the M8 engine so no PVT messages out, To get the time in openXsensor I configure the GPS to transmit TIMEUTC on uart1 and then I parse the related packet. oXs_on_RP2040 instead get time and date from PVT packet that doesn't exist at least in M6 protocol (not sure about M8 as at the moment i do not have a M8 gps available).

@jasc76 May you try with my fork ? If it works I will create a pull request to this repository

https://github.com/romoloman/oXs_on_RP2040

[romoloman]

In some receivers (fake/clone) the following test if (( _buffer.pvt.valid & 0x03) == 0X03 ) is true even with wrong date / time (that's why when it start receiving you may get the original date / time of the GPS receiver) Btw i will check instead for if (( _buffer.pvt.valid & 0x07) == 0X07 ) as it takes into account also the fullyResolved flag

fullyResolved - - 1 = UTC time of day has been fully resolved (no seconds uncertainty). Cannot be used to check if time is completely solved) looking in the U-BLOX integration manual is indeed suggested to check also onfirmedDate and confirmedTime flags.

Here an extract of integration manual:

Information about the validity of the time solution is given in the following form: • Time validity: Information about time validity is provided in the valid flags (e.g. validDate and validTime flags in the UBX-NAV-PVT message). If these flags are set, the time is known and considered valid for use. These flags are shown in table GNSS times in section GNSS times above as well as in the UBX-NAV-PVT message. • Time validity confirmation: Information about confirmed validity is provided in the confirmedDate and confirmedTime flags in the UBX-NAV-PVT message. If these flags are set, the time validity can be confirmed by using an additional independent source, meaning that the probability of the time to be correct is very high. Note that information about time validity confirmation is only available if the confirmedAvail bit in the UBX-NAV-PVT message is set. validDate means that the receiver has knowledge of the current date. However, it must be noted that this date might be wrong for various reasons. Only when the confirmedDate flag is set, the probability of the incorrect date information drops significantly. validTime means that the receiver has knowledge of the current time. However, it must be noted that this time might be wrong for various reasons. Only when the confirmedTime flag is set, the probability of incorrect time information drops significantly. fullyResolved means that the UTC time is known without full seconds ambiguity. When deriving UTC time from GNSS time the number of leap seconds must be known, with the exception of GLONASS. It might take several minutes to obtain such information from the GNSS payload. When the one second ambiguity has not been resolved, the time accuracy is usually in the range of ~20s.

(statement about 20 second of inaccuracy is not true for fake/clones)

Instead getting the time from timeutc record using the following test always return a proper date/time if ((_buffer.timeutc.flag & 0x07) ==0x07) {

That's what I'm implemented in the arduino version and also in my fork.

[jasc76]

in this plane I use: I think its a BN220 REceiver S6R S.Port

I think that the main problem is the gps module you are using, It uses the M8 engine so no PVT messages out, To get the time in openXsensor I configure the GPS to transmit TIMEUTC on uart1 and then I parse the related packet. oXs_on_RP2040 instead get time and date from PVT packet that doesn't exist at least in M6 protocol (not sure about M8 as at the moment i do not have a M8 gps available).

@jasc76 May you try with my fork ? If it works I will create a pull request to this repository

https://github.com/romoloman/oXs_on_RP2040

I was on vacation... and had little time ... it adds up :-) Ok, will do. Sadly I can't be certain since I need to check with a friend to fly, because this Funjet can only be launched with a bungee and not alone