When reading NMEA log ( ) using the flow pictured below, some of the lines have an erroneous timestamp.
Using FME(R) 2020.0.2.1 (20200511 - Build 20238 - WIN64), GPSBabel 1.6.0.
Is there something i'm overlooking?
When reading NMEA log ( ) using the flow pictured below, some of the lines have an erroneous timestamp.
Using FME(R) 2020.0.2.1 (20200511 - Build 20238 - WIN64), GPSBabel 1.6.0.
Is there something i'm overlooking?
Seems to be GPS points (using GPS Babel).
Could it be at that moment the GPS device was using a different satellite, and therefor using a different timezone?
I see no timezone indication in the time.
The actual log (included in the original post) has no such timeslip. GPS time is always UTC. Something happens during the transformation.. When manually converting with GPSBabel the result is good. It's the interaction between FME/GPSBabel.... i think..
The actual log (included in the original post) has no such timeslip. GPS time is always UTC. Something happens during the transformation.. When manually converting with GPSBabel the result is good. It's the interaction between FME/GPSBabel.... i think..
Can you share some data, so we can have a look?
Kind of hard to see what is going on without data.
Hi @beosan, thank you for your question. I was able to reproduce it and I have filed this for the dev team to take a closer look at (internal reference code: FMEENGINE-64456). I will post any updates or follow-ups here. Thanks for bringing this to our attention.
For now i've solved my problem with the following snippet.. Read NMEA log as CSV, process and create vertices..
The actual log (included in the original post) has no such timeslip. GPS time is always UTC. Something happens during the transformation.. When manually converting with GPSBabel the result is good. It's the interaction between FME/GPSBabel.... i think..
Data is attached to the original post