HL6528RD-G GPS rollover bug

It seems that the HL6528RD-G with latest Airvantage firmware version installed is susceptible for the “GPS week rollover” bug that occurred April 6th this year. The GPS receiver reports an incorrect date:
+GPSPVT:0,09:55:16,31/12/1999,2D FIX
Will this be fixed in a future firmware update, or do I have to implement my own workaround?

Hi allardpotma,

I did not see the GPS rollover issue with HL6RD v2.5.1.1.
Could you try with this version?

Here’s my partial log: (without SUPL GPS aiding)
RHL6528RD.2.5.1.1.11CV10F49_P1.201808201245.m6261a_1
AT+GPSNMEA=1,1,FFFF,FF
AT+GPSPVT=1,1,FFFF
AT+GPSSTART=0

+GPSEVPOS: 3
$GPGGA,064133.753,2232.2950,N,11356.9714,E,1,04,1.6,-145.0,M,-2.5,M,6E
$GPGLL,2232.2950,N,11356.9714,E,064133.753,A,A
5F
$GPRMC,064133.753,A,2232.2950,N,11356.9714,E,0.5,0.0,190819,A65
$GPGSA,A,3,06,13,19,29,1.6,32
$GPVTG,0.0,T,M,0.5,N,0.9,K,A
01
$GPGSV,2,1,05,06,32,079,27,13,42,174,36,19,27,146,31,29,13,323,29
7C
$GPGSV,2,2,05,30,06,104,174A
$GLGSV,1,1,03,70,40,066,48,69,01,027,18,71,42,140,15
5A
$GLGSA,A,3,1.6,29
$GNGNS,064133.753,2232.2950,N,11356.9714,E,AN,04,1.6,-145.0,-2.5,55
$GNGSA,A,3,06,13,19,29,5.8,1.6,5.6
22
$GPGGA,064133.753,2232.2950,N,11356.9714,E,1,04,1.6,-145.0,M,-2.5,M,6E
$GPGLL,2232.2950,N,11356.9714,E,064133.753,A,A
5F
$GPRMC,064133.753,A,2232.2950,N,11356.9714,E,0.5,0.0,190819,A
65
+GPSPVT:0,06:41:34,19/08/2019,3D FIX,N 022 32’17.66",E 113 56’58.23",-0147m
+GPSPVT:1,000.0deg,000m/s
+GPSPVT:2,04SV,1.6HDOP,37,25.3
+GPSPVT:3,4,1,[13,U,36],[6,U,27],[19,U,31],[29,U,29],[30,N,18],[17671,N,15]
+GPSPVT:3,4,2,[23558,N,48],[16645,N,18],[16395,N,0],[24332,N,0],[23830,N,0],[17429,N,0]
+GPSPVT:3,4,3,[17928,N,0],[16916,N,0],[22794,N,0],[17175,N,0],[24077,N,0],[7,N,0]
+GPSPVT:3,4,4,[8321,N,0]

My module has the same firmware version. I used the same commands as you.

After a couple of minutes the time is set correctly, but the date is invalid.
+GPSPVT:0,10:23:13,25/06/2012,NO FIX,N 000 00’00.00",E 000 00’00.00",+0000m
$GPRMC,102120.956,V,250612,N*45

After ~5 minutes the date is set correctly:
+GPSPVT:0,10:28:50,19/08/2019,NO FIX,N 000 00’00.00",E 000 00’00.00",+0000m
+GPSPVT:1,000.0deg,000m/s
+GPSPVT:2,00SV,0.0HDOP,0,0.0
+GPSPVT:3,2,1,[7,N,18],[8,N,21],[16399,N,25],[17425,N,14],[22798,N,0],[23826,N,0]
+GPSPVT:3,2,2,[24077,N,0],[17171,N,0],[17667,N,0],[17924,N,0],[23554,N,0]
$GPGGA,102850.956,0,7C
$GPGLL,0000.0000,N,00000.0000,E,102850.956,V,N
45
$GPRMC,102850.956,V,190819,N41
$GPVTG,0.0,T,M,0.0,N,0.0,K,N
02
$GPGSV,1,1,02,07,89,157,18,08,00,000,217C
$GLGSV,1,1,02,79,38,002,25,81,26,358,14
61
$GLGSA,A,1,0.0,*2C
$GNGNS,102850.956,NN,*49

I’m indoors so setting a fix is difficult. It seems that the GPSPVT and $GPRMC may report a faulty date? How do I know if the reported date is valid? Should I only use trust a date that is reported with a 3D-fix? Isn’t reception of one satellite enough for a date/time?

Hi allardpotma,

Please wait 2D or 3D fix to get the correct date or from NEMA GPRMC. And I suppose 25/06/2012 should not due to the gps roll over event.

No it seems that it is not a rollover problem. In my original message I had a 2D fix, but the date was still wrong?

Hi,

I’m working with the same module with the same firmware than you do but I cannot get any response with the GPS related AT commands. Are you guys using the uart1 port to send these?

I’m using this uart1 port and I get an “OK” by doing “AT\r” but once I try with “AT+GPSSTART=0”, or any other GPS related, it always return “ERROR”.

Did you enable some pin, or command, or it may detect that there is not antenna maybe? I can’t think any reason why the AT commands are not responding though.

Thanks

Hi allardpotma, could you provide your full NMEA logs? Do you enable SUPL in your test?

Hi dbailos.

please make sure your module is with GNSS. Pls check by:
ATI
HL6528RD-G2.8V
OK

Hi Sierra_klin2,

Thanks for your answer, I’ve got the following:
ATI
HL6528RD-2.8V
OK

So I presume that the missing “G” means GNSS and I need to change my module, is that correct? Now it makes sense…

Thank you for your help

See attachment for full log. Even with a 3D fix a faulty date is reported. This is without SUPL (hence the GPSSUPLERROR messages), I can see the same behavior with SUPL enabled.

The date is not always wrong, I have tried it four times now, three times going well.

GPS_date_error.txt (167.7 KB)

Hi allardpotma,

In your log we can see GPS rollover issue, the date is back to 19.7years.

+GPSPVT:0,13:58:23,05/01/2000,2D FIX,N 052 15’17.66",E 004 37’48.79",-0047m
+GPSPVT:0,13:59:44,05/01/2000,3D FIX,N 052 15’21.27",E 004 37’31.45",+0064m

Could you please share your result of AT+GPSSUPLCFG?.

AT+GPSSUPLCFG?

+GPSSUPLCFG: 0,“supl.google.com”,7276,1,0
+GPSSUPLCFG: 1,-1,1,1
+GPSSUPLCFG: 2,"","","",“0.0.0.0”,“0.0.0.0”,“0.0.0.0”

OK

This should be the default value, I do not set the SUPL configuration.

Hi allardpotma,

  • When module has no cellular connection or when AT+GPSSULCFG=0,""
    (no SUPL server configured), the GPS date information should be correct.

  • When module has cellular connection and GPSSUPLCFG is active with default settings +GPSSUPLCFG: 0,“supl.google.com”,7276,1,0 the GPS date will be incorrect.

Please disable SUPL or wait new release of V2.6.

I just tested without SUPL, but I do not get the right date:
+GPSPVT:0,08:28:06,07/02/2000,2D FIX,N 052 15’20.39",E 004 37’39.90",-0047m

The date is faulty, but does make some sense, to calulate the right date I’ve implemented a temporarily fix:
timestamp = (timestamp - GPS_EPOCH_1999) + GPS_EPOCH_2019;
Where GPS_EPOCH_1999 is 935193600 and GPS_EPOCH_2019 is 1554508800 (unix timestamps)

I will use this patch until the release of V2.6
log_noSUPL.txt (484.1 KB)