EdgeTX / edgetx

EdgeTX is the cutting edge open source firmware for your R/C radio

Home Page:https://edgetx.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

In the Companion in the GPS data latest version 2.11.0 the comma between Lat/Lon is missing

koaxheli opened this issue · comments

Is there an existing issue for this problem?

  • I have searched the existing issues

What part of EdgeTX is the focus of this bug?

Simulator

Current Behavior

With FrSky S.Port the LOG-csv file GPS file Lat/Lon is written with spaces and everything was OK.

Expected Behavior

Now a comma is required as a separator in the simulator, but this is not present and the string cannot be read.

Steps To Reproduce

In all previous versions the comma was inserted by the program now it is missing.
Please set it again with comma as fixed value.

Version

Other (Please specify below)

Transmitter

RadioMaster TX16S / TX16SMK2

Operating System (OS)

Windows

OS Version

No response

Anything else?

Companion 2.10.3
GPS_lat_lon
GPS_lat_lon_2 10 3
Companion 2.11.0

@nrw505 When is a comma not a comma? 🙃 🤣

If a csv log file is read in the Companion during simulation, there is no comma in the GPS column between lat and lon but a space.
This means that the csv-GPS file column is read as a null string.
In the previous version of Companion, a comma was automatically placed between lat/lon when the scv file was read in.

I think there are a couple of problems with reading the gps lat/lon.

On my Frsky/sport format GPS until it gets a satellite lock it sends one byte of 0 for the lat/lon instead of the "dd.dddddd dd.dddddd" format so the first few lines of the log file do not contain the correct data. And since telemetrysimu.cpp line 433 checks the first line of the log to determine the format it detects the wrong format.

So I thought that changing the check from the first line of the file to the last line of the file by changing telemetrysimu.cpp line 433 from
433 QStringList firstRowVlues = csvRecords[1].split(',') to
433 QStringList firstRowVlues = csvRecords[csvRecords.count()-1].split(',');
would correct the problem.

And it does correct the problem of the wrong format being detected, but that is not the only problem and the replay still shows the GPS as 0 00'0.0"N 0 00'0.0"E.

When I get some more time I'll try to figure out what else is wrong if nobody else does it in the mean time. I'm attaching the log file from my Edge540 that I've been using to test.
gpstest.csv

@nrw505 When is a comma not a comma? 🙃 🤣

When you fix it in simulatedgps.cpp and the FrSky implementation's still using it's own GPS implementation because I didn't finish refactoring it to use the new one. Whoops.

Tested PR 5476 and can verify that GPS Lat/Lon now replays correctly on my log files.

The change from Degree/Minute/Second to Decimal Degrees when producing log CSV files in the radio happened in April 2016. (edit: and got released with OpenTX 2.1.9 in Sep 2016)

I think it's safe to remove the "Is this decimal degrees or DMS in the CSV file" check entirely at this point. If someone really cares about replaying logs from back then, they can still use OpenTX companion to do it.

edit: With #5410 we don't actually use the result of that check any more anyway.