An issue with the NEO-M9 used with Openlog Artemis

Development Boards Artemis
1

Hi

I have a NEO-M9N (GPS-15712) connected to an Openlog Artemis via QWIIC, and am logging position and time. The question concerns mainly the lack of precise agreement between the two “gps times”, TOW and UTC.

  1. I’m trying to log 5 times a second but am only getting data logged every 400 ms. I assume that’s because with this sensor I’m pushing the Artemis too hard. Is this correct?

  2. The fractional part of the seconds in UTC is reported always as an integer times 200 ms (e.g. .000 or .400, and never .023 or .417). This seems contrived. Is it how the NEO-M9 reports UTC, or is it a function of the OLA firmware?

  3. The time reported in TOW is different from UTC by 200 ms. Actually this is the difference in the fractional part of the seconds. (I’d expect these to be different by an exact integer number of seconds, zero or 18). This discrepancy seems odd, so does it have a simple explanation? (If I change the logging rate to 2 per second, this difference becomes 500 ms).

Here are some sample lines of logged data with the headers. The TOW is apparently in milliseconds and is the 2nd last number in each line. The first date and time in each line is that of the OLA. The second date and time is UTC reported by the NEO-M9.

rtcDateTime,gpsDateTime,gps_Lat,gps_Long,gps_Alt,gps_SIV,gps_FixType,gps_CarrierSolution,gps_GroundSpeed,gps_Heading,gps_pDOP,gps_iTOW,output_Hz

31/10/2020 01:18:51.64,31/10/2020 01:18:51.800,-348546954,1387039616,124498,13,3,0,157,0,211,523150000,2.98

31/10/2020 01:18:51.99,31/10/2020 01:18:52.200,-348546850,1387039613,127225,17,3,0,36,0,184,523150400,2.75

In the second line the fractional part of the UTC time is .200 s and in the TOW it is .400 s .

Thanks for any help in sorting this out,

Murray

2

Hi Murray,

  1. Can you tell me what sensors you have connected and what settings you are using?

  2. The fractional part is certainly not contrived. That’s how we receive it from the u-blox module. The module does some internal syncing and if set to 5Hz will give you updates every 0.2 seconds, so the exact timings are not a surprise.

  3. I suspect you’re seeing the same thing as this issue:

https://github.com/sparkfun/OpenLog_Artemis/issues/53

The UTC and TOW appear to be being extracted from consecutive messages. We’re working on a fix for that. We are going to start using “autoPVT” which means the TOW and UTC time will be extracted from the exact same message from the module. We should be able to implement this in 1-2 weeks once we’ve got some other projects out of the way. Thank you for your patience and understanding!

Best wishes,

Paul

3

Thanks for the reply … in reverse order because the answer to 1) is wordy;

  1. That’s an interesting post. I suspected that consecutive messages might be underlying this. Though it leads to the question of whether the lat/long measurements are associated with the UTC or the TOW.

  2. That’s useful info. Thanks.

and for part 1) the device settings were

GPS-ublox.3.66.0.0.log=1

GPS-ublox.3.66.0.0.logDate=1

GPS-ublox.3.66.0.0.logTime=1

GPS-ublox.3.66.0.0.logPosition=1

GPS-ublox.3.66.0.0.logAltitude=1

GPS-ublox.3.66.0.0.logAltitudeMSL=0

GPS-ublox.3.66.0.0.logSIV=1

GPS-ublox.3.66.0.0.logFixType=1

GPS-ublox.3.66.0.0.logCarrierSolution=1

GPS-ublox.3.66.0.0.logGroundSpeed=1

GPS-ublox.3.66.0.0.logHeadingOfMotion=1

GPS-ublox.3.66.0.0.logpDOP=1

GPS-ublox.3.66.0.0.logiTOW=1

GPS-ublox.3.66.0.0.i2cSpeed=100000

and the OLA settings were

sizeOfSettings=96

olaIdentifier=277

nextSerialLogNumber=15

nextDataLogNumber=99

usBetweenReadings=200000

logMaxRate=0

enableRTC=1

enableIMU=0

enableSD=1

enableTerminalOutput=1

logDate=1

logTime=1

logData=1

logSerial=0

logIMUAccel=1

logIMUGyro=1

logIMUMag=1

logIMUTemp=1

logRTC=1

logHertz=1

getRTCfromGPS=1

correctForDST=0

americanDateStyle=0

hour24Style=1

serialTerminalBaudRate=115200

serialLogBaudRate=19200

showHelperText=1

logA11=1

logA12=0

logA13=0

logA32=0

logAnalogVoltages=1

localUTCOffset=0

printDebugMessages=0

powerDownQwiicBusBetweenReads=1

qwiicBusMaxSpeed=100000

qwiicBusPowerUpDelayMs=250

printMeasurementCount=0

enablePwrLedDuringSleep=1

logVIN=0

openNewLogFilesAfter=3600

vinCorrectionFactor=1.47

useGPIO32ForStopLogging=0

thanks again,

Murray

4

Hi Murray,

It looks like you’re using version 1.5 of the firmware. Can you please try upgrading to 1.6 and let me know if that makes any difference?

https://github.com/sparkfun/OpenLog_Art … UPGRADE.md

I don’t have a NEO-M9N, so I can’t exactly replicate your issue, but we regularly have other u-blox modules logging at 10Hz and so you should be able to log at 5Hz without difficulty. We just need to figure out why you’re having problems…

Also, are you logging serial data too? If so, do you have an idea how much data is coming in?

And are you using a good quality SD card?

Best wishes,

Paul

5

Thanks again Paul.

It will take a little while to upgrade the firmware as I don’t seem to have a computer young enough to run the GUI, and I’m waiting on a 2nd OLA to arrive before I try the Arduino IDE method, in case I brick the OLA that I have. In any case I turned off the logging of the TOW and a couple of other things (DoP and Carrier Sol’n), and then the logging of GPS time and position resumed at the desired 5 Hz. So it seems you are likely right about TOW being logged from a separate UBX message. The GPS position is thus probably associated with the UTC time and not the TOW. If I know this for sure, I don’t actually need to log TOW at all.

The SD card is a good one, quite happily records video on my camera.

I’m not logging serial data yet, but the thread about 2 earlier on this forum, about the lack of a timestamp for that data stream, is worrying. But first off I have to deal with the fact that the serial data is good old seriously hard-core RS232 with logic high at 10V and logic low at -10V.

regards

Murray