Adding GPS

[jmmcg]

The GNSS module I have appears to only erratically permit the clock to sync to it. So I had a better look at the messages the SMK53 & BN-2220T produce to see if that might be an effect.

XXXsnipXXX
Sample NMEA0183 messages from the Beitian BN-220T GPS unit, with a lock:

Code: Select all

$GNVTG,,T,,M,0.126,N,0.234,K,A*3D
$GNGGA,134705.00,5203.45990,N,00016.30273,W,1,12,0.83,22.7,M,45.9,M,,*64
$GNGSA,A,3,08,27,10,11,21,20,16,,,,,,1.63,0.83,1.40*1C
$GNGSA,A,3,81,65,82,80,88,66,,,,,,,1.63,0.83,1.40*1E
$GPGSV,4,1,13,01,26,254,22,07,05,273,,08,82,270,22,10,52,073,28*73
$GPGSV,4,2,13,11,52,275,28,16,18,179,26,20,23,050,27,21,30,075,27*71
$GPGSV,4,3,13,22,11,204,20,27,60,128,24,28,06,329,,30,09,301,15*7E
$GPGSV,4,4,13,32,11,120,*49
$GLGSV,3,1,10,65,37,046,29,66,37,133,33,67,01,170,,72,07,015,*6D
$GLGSV,3,2,10,73,06,353,,79,20,233,18,80,33,293,29,81,72,022,39*68
$GLGSV,3,3,10,82,37,293,30,88,28,086,25*62
$GNGLL,5203.45990,N,00016.30273,W,134705.00,A,A*66
$GNRMC,134706.00,A,5203.45992,N,00016.30273,W,0.015,,300620,,,A*7D
$GNVTG,,T,,M,0.015,N,0.028,K,A*33
$GNGGA,134706.00,5203.45992,N,00016.30273,W,1,12,0.83,22.8,M,45.9,M,,*6A
$GNGSA,A,3,08,27,10,11,21,20,16,,,,,,1.63,0.83,1.40*1C
$GNGSA,A,3,81,65,82,80,88,66,,,,,,,1.63,0.83,1.40*1E
$GPGSV,4,1,13,01,26,254,20,07,05,273,,08,82,270,21,10,52,073,26*7C
$GPGSV,4,2,13,11,52,275,27,16,18,179,24,20,23,050,25,21,30,075,26*7F
$GPGSV,4,3,13,22,11,204,18,27,60,128,22,28,06,329,,30,09,301,*77
$GPGSV,4,4,13,32,11,120,*49
$GLGSV,3,1,10,65,37,046,27,66,37,133,28,67,01,170,,72,07,015,*69
$GLGSV,3,2,10,73,06,353,,79,20,233,18,80,33,293,29,81,72,022,34*65
$GLGSV,3,3,10,82,37,293,28,88,28,086,24*6A
$GNGLL,5203.45992,N,00016.30273,W,134706.00,A,A*67
$GNRMC,134707.00,A,5203.45994,N,00016.30274,W,0.023,,300620,,,A*78
$GNVTG,,T,,M,0.023,N,0.043,K,A*3B
$GNGGA,134707.00,5203.45994,N,00016.30274,W,1,12,0.83,22.8,M,45.9,M,,*6A
$GNGSA,A,3,08,27,10,11,21,20,16,,,,,,1.63,0.83,1.40*1C
$GNGSA,A,3,81,65,82,80,88,66,,,,,,,1.63,0.83,1.40*1E
$GPGSV,4,1,13,01,26,254,17,07,05,273,,08,82,270,20,10,52,073,25*7A
$GPGSV,4,2,13,11,52,275,26,16,18,179,24,20,23,050,23,21,30,075,25*7B
$GPGSV,4,3,13,22,11,204,,27,60,128,21,28,06,329,,30,09,301,*7D
$GPGSV,4,4,13,32,11,120,*49
$GLGSV,3,1,10,65,37,046,25,66,37,133,28,67,01,170,,72,07,015,*6B
$GLGSV,3,2,10,73,06,353,,79,20,233,16,80,33,293,28,81,72,022,34*6A
$GLGSV,3,3,10,82,37,293,28,88,28,086,23*6D
$GNGLL,5203.45994,N,00016.30274,W,134707.00,A,A*67
$GNRMC,134708.00,A,5203.45991,N,00016.30276,W,0.171,,300620,,,A*76
$GNVTG,,T,,M,0.171,N,0.317,K,A*3F
$GNGGA,134708.00,5203.45991,N,00016.30276,W,1,12,0.83,22.9,M,45.9,M,,*63
$GNGSA,A,3,08,27,10,11,21,20,16,,,,,,1.63,0.83,1.40*1C
$GNGSA,A,3,81,65,82,80,88,66,,,,,,,1.63,0.83,1.40*1E
$GPGSV,4,1,13,01,26,254,17,07,05,273,,08,82,270,19,10,52,073,25*70
$GPGSV,4,2,13,11,52,275,25,16,18,179,22,20,23,050,22,21,30,075,23*79
$GPGSV,4,3,13,22,11,204,,27,60,128,20,28,06,329,,30,09,301,*7C
$GPGSV,4,4,13,32,11,120,*49
$GLGSV,3,1,10,65,37,046,24,66,37,133,29,67,01,170,,72,07,015,*6B
$GLGSV,3,2,10,73,06,353,,79,20,233,15,80,33,293,27,81,72,022,34*66
$GLGSV,3,3,10,82,37,293,28,88,28,086,21*6F
$GNGLL,5203.45991,N,00016.30276,W,134708.00,A,A*6F
$GNRMC,134709.00,A,5203.45991,N,00016.30278,W,0.038,,300620,,,A*75
$GNVTG,,T,,M,0.038,N,0.070,K,A*31
$GNGGA,134709.00,5203.45991,N,00016.30278,W,1,12,0.83,22.9,M,45.9,M,,*6C
$GNGSA,A,3,08,27,10,11,21,20,16,,,,,,1.63,0.83,1.40*1C
$GNGSA,A,3,81,65,82,80,88,66,,,,,,,1.63,0.83,1.40*1E
$GPGSV,4,1,13,01,26,254,17,07,05,273,,08,82,270,19,10,52,073,25*70
$GPGSV,4,2,13,11,52,275,25,16,18,179,22,20,23,050,22,21,30,075,23*79
$GPGSV,4,3,13,22,11,204,,27,60,128,21,28,06,329,,30,09,301,*7D
$GPGSV,4,4,13,32,11,120,*49
$GLGSV,3,1,10,65,37,046,24,66,37,133,29,67,01,170,,72,07,015,*6B
$GLGSV,3,2,10,73,06,353,,79,20,233,14,80,33,293,28,81,72,022,34*68
$GLGSV,3,3,10,82,37,293,28,88,28,086,20*6E
$GNGLL,5203.45991,N,00016.30278,W,134709.00,A,A*60
$GNRMC,134710.00,A,5203.45996,N,00016.30278,W,0.196,,300620,,,A*7F
$GNVTG,,T,,M,0.196,N,0.363,K,A*35
$GNGGA,134710.00,5203.45996,N,00016.30278,W,1,12,0.83,22.9,M,45.9,M,,*63
$GNGSA,A,3,08,27,10,11,21,20,16,,,,,,1.63,0.83,1.40*1C
$GNGSA,A,3,81,65,82,80,88,66,,,,,,,1.63,0.83,1.40*1E
$GPGSV,4,1,13,01,26,254,18,07,05,273,,08,82,270,19,10,52,073,25*7F
$GPGSV,4,2,13,11,52,275,25,16,18,179,22,20,23,050,22,21,30,075,24*7E
$GPGSV,4,3,13,22,11,204,,27,60,128,21,28,06,329,,30,09,301,*7D
$GPGSV,4,4,13,32,11,120,*49
$GLGSV,3,1,10,65,37,046,24,66,37,133,29,67,01,170,,72,07,015,*6B
$GLGSV,3,2,10,73,06,353,,79,20,233,12,80,33,293,27,81,72,022,34*61
$GLGSV,3,3,10,82,37,293,29,88,28,086,20*6F
$GNGLL,5203.45996,N,00016.30278,W,134710.00,A,A*6F
$GNRMC,134711.00,A,5203.46001,N,00016.30278,W,0.147,,300620,,,A*76
$GNVTG,,T,,M,0.147,N,0.272,K,A*38
$GNGGA,134711.00,5203.46001,N,00016.30278,W,1,12,0.83,23.1,M,45.9,M,,*6F
$GNGSA,A,3,08,27,10,11,21,20,16,,,,,,1.63,0.83,1.40*1C
$GNGSA,A,3,81,65,82,80,88,66,,,,,,,1.63,0.83,1.40*1E
$GPGSV,4,1,13,01,26,254,18,07,05,273,,08,82,270,20,10,52,073,25*75
$GPGSV,4,2,13,11,52,275,25,16,18,179,22,20,23,050,23,21,30,075,24*7F
$GPGSV,4,3,13,22,11,204,,27,60,128,21,28,06,329,,30,09,301,*7D
$GPGSV,4,4,13,32,11,120,*49
$GLGSV,3,1,10,65,36,046,23,66,37,133,29,67,01,170,,72,07,015,*6D
$GLGSV,3,2,10,73,06,353,,79,20,233,,80,33,293,27,81,72,022,34*62
$GLGSV,3,3,10,82,37,293,29,88,28,086,20*6F
$GNGLL,5203.46001,N,00016.30278,W,134711.00,A,A*6A
$GNRMC,134712.00,A,5203.46006,N,00016.30280,W,0.194,,300620,,,A*7B
$GNVTG,,T,,M,0.194,N,0.360,K,A*34
$GNGGA,134712.00,5203.46006,N,00016.30280,W,1,12,0.83,23.3,M,45.9,M,,*6E
$GNGSA,A,3,08,27,10,11,21,20,16,,,,,,1.63,0.83,1.40*1C
$GNGSA,A,3,81,65,82,80,88,66,,,,,,,1.63,0.83,1.40*1E
$GPGSV,4,1,13,01,26,254,16,07,05,273,,08,82,270,20,10,52,073,25*7B
$GPGSV,4,2,13,11,52,275,25,16,18,179,22,20,23,050,24,21,30,075,23*7F
$GPGSV,4,3,13,22,11,204,,27,60,128,22,28,06,329,,30,09,301,*7E
$GPGSV,4,4,13,32,11,120,*49
$GLGSV,3,1,10,65,36,046,23,66,38,132,29,67,01,170,,72,07,015,*63
$GLGSV,3,2,10,73,06,353,,79,20,233,,80,33,293,27,81,72,022,34*62
$GLGSV,3,3,10,82,37,293,29,88,28,086,22*6D
$GNGLL,5203.46006,N,00016.30280,W,134712.00,A,A*69
$GNRMC,134713.00,A,5203.46001,N,00016.30285,W,0.284,,300620,,,A*7A
$GNVTG,,T,,M,0.284,N,0.525,K,A*31
$GNGGA,134713.00,5203.46001,N,00016.30285,W,1,12,0.83,23.4,M,45.9,M,,*6A
$GNGSA,A,3,08,27,10,11,21,20,16,,,,,,1.63,0.83,1.40*1C
$GNGSA,A,3,81,65,82,80,88,66,,,,,,,1.63,0.83,1.40*1E
$GPGSV,4,1,13,01,26,254,15,07,05,273,,08,82,270,20,10,52,073,25*78
$GPGSV,4,2,13,11,52,275,25,16,18,179,22,20,23,050,24,21,30,075,24*78
$GPGSV,4,3,13,22,11,204,,27,60,128,22,28,06,329,,30,09,301,*7E
$GPGSV,4,4,13,32,11,120,*49
$GLGSV,3,1,10,65,36,046,24,66,38,132,30,67,02,170,,72,07,015,*6F
$GLGSV,3,2,10,73,06,353,,79,20,233,,80,33,293,27,81,72,022,34*62
$GLGSV,3,3,10,82,37,293,29,88,28,086,23*6C
$GNGLL,5203.46001,N,00016.30285,W,134713.00,A,A*6A

I note from the documentation that the SKM53 outputs these two message types that contain time information, for example:

Code: Select all

GGA message:
$GPGGA,033410.000,2232.1745,N,11401.1920,E,1,07,1.1,107.14,M,0.00,M,,*64
       HHMMSS.SSS
RMC message:
$GPRMC,075747.000,A,2232.8990,N,11405.3368,E,3.9,357.8,260210,,,A*6A
       HHMMSS.SSS

I also note from the documentation that the BN-220T outputs these two message types that contain time information, for example:

Code: Select all

GGA message:
$GPGGA,092725.00,4717.11399,N,00833.91590,E,1,08,1.01,499.6,M,48.0,M,,*5B
RMC message:
$GPRMC,083559.00,A,4717.11437,N,00833.91522,E,0.004,77.52,091202,,,A,V*57

From the log I gave earlier, we can see:

Code: Select all

$GNGGA,134705.00,5203.45990,N,00016.30273,W,1,12,0.83,22.7,M,45.9,M,,*64
XXXsnipXXX
$GNRMC,134706.00,A,5203.45992,N,00016.30273,W,0.015,,300620,,,A*7D

It is clear that the BN-220T has only 2 dp in the time field of both messages, yet the SKM53 has 3 dp. So there is a subtle difference in the messages.
Now trying NTP on my Gentoo/Linux laptop, I see:

Code: Select all

jason@marvin ~ $ ntpq -c lpeer
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*GPS_NMEA(0)     .GPS.            0 l    3   16    3    0.000  +366.36   0.313
 85.199.214.99 ( .STEP.          16 u    -   64    0    0.000   +0.000   0.000
 ns1.do.steersne 114.199.6.79     2 u   11   64    1   14.939  +481.69   0.000
 time.netweaver. 85.199.214.98    2 u    9   64    1   15.832  +482.76   0.000
 slideaway.presh .STEP.          16 u   14   64    0    0.000   +0.000   0.000

Code: Select all

jason@marvin ~ $ ntptrace
marvin.reality: stratum 1, offset 0.000000, synch distance 0.367004, refid 'GPS'

Note the asterisk next to "GPS_NMEA" and the non-zero "when" plus "delay, "offset" and "jitter". Also the fact that "marvin" is now at stratum 1, with a refclock of "GPS". These, I understand, confirm that NTP is using the BN-220T as a time source.

So.... I find that the clock erratically syncs to the BN-220T (for example today the clock appears to have synced, for the very first time). Might the difference of the 2 vs 3 dp (for the time field in the NMEA messages) be an issue?

(Note the BN-220T is a GNSS module (GPS/GLONASS/BEIDOU/etc), unlike the SKM53 which is only GPS, I understand from the documentation of both.)

[jmmcg]

Another GNSS unit https://www.u-blox.com/en/docs/UBX-13003221 indicates two dp for the time field:

Code: Select all

31.2.4 GGA:
$GPGGA,092725.00,4717.11399,N,00833.91590,E,1,08,1.01,499.6,M,48.0,M,,*5B

Code: Select all

31.2.14 RMC:
$GPRMC,083559.00,A,4717.11437,N,00833.91522,E,0.004,77.52,091202,,,A,V*57

Another unit http://www.skytraq.com.tw/datasheet/S1216V8_v0.9.pdf uses 3dp. So there is some variation. I presume that the clock can handle both 2 and 3 dp in this case? (As my BN-220T persistently does not want to be recognised by the clock it would appear.)
Please can you confirm:
1. Which NMEA message the clock uses?
2. Can it handle 2dp in the time format?
3. Are the messages from the BN-220T recognisable by the clock (see earlier post with a log of those messages)?

[Tony]

The field separation is the comma, Dps won't alter the position of the time data. This is the relevant part of the code, it reads the first 6 bytes after the first comma, counts to the date field, then reads another 6 bytes.

;We have a valid string, now extract the data we need from it
;$GPRMC,092751.000,A,5321.6802,N,00630.3371,W,0.06,31.66,280511,,,A*45

movlw 0x22
movwf FSR0L
movlw "R"
xorwf INDF0,w
btfss STATUS,Z
;goto GPSdecodeIR ;Not the string we want, exit
goto GPSdecodeX
incf FSR0L,f
movlw "M"
xorwf INDF0,w
btfss STATUS,Z
;goto GPSdecodeIR ;Not the string we want, exit
goto GPSdecodeX
incf FSR0L,f
movlw "C"
xorwf INDF0,w
btfss STATUS,Z
;goto GPSdecodeIR ;Not the string we want, exit
goto GPSdecodeX
incf FSR0L,f

call GPSgetbyte ;Read time bytes (6 characters)
movwf GHouk
call GPSgetbyte
movwf GMink
call GPSgetbyte
movwf GSeck

movlw 0x08
movwf TempCounP1a ;count ,s
GPSdecodeloop
incf FSR0L,f
movlw ","
xorwf INDF0,w
btfss STATUS,Z
goto GPSdecodeloop ;Not the comma, looop
decfsz TempCounP1a,f
goto GPSdecodeloop ;Not the LAST comma, looop

call GPSgetbyte ;Read time bytes (6 characters)
movwf GDayk
call GPSgetbyte
movwf GMonk
call GPSgetbyte
movwf GYeak

[jmmcg]

The field separation is the comma, Dps won't alter the position of the time data. This is the relevant part of the code, it reads the first 6 bytes after the first comma, counts to the date field, then reads another 6 bytes.
XXXsnipXXX

Note how the RMC message starts "GN" not "GP". Is that o.k.?

You see the reason I think it does not sync is that:
a) The time does not appear to change to the right time" UTC.
b) Menu 9.6 only ever appears to permit me to set the year (YY.YY) and never a timezone.

[jmmcg]

Most curious: after about 3 hours (the BN0-220T had had GNSS lock for about 2 hours already) the clock seemed to read the time from the GNSS module data. But it seemed to have a 8 hours subtracted from it (the GGA & RMC messages have the right timezone no odd offset, i.e. UTC). I checked menu entry 9.6 and this was 2020 (13-23 == subtract x hrs, so this makes sense). I changed it to 0000 so no timezone should be added/deducted. This had no effect. I tried changing the Summer TIme setting and this added an hour.

Clearly I do not understand how to set the timezone... And why the odd 8-hour deduction by default?

[jmmcg]

I have built another cylinder clock (sent the other one as a present) and the NMEA messages from the BN-220T GNSS module do not seem to be updating the time nor date nor year, despite having a lock. So I hypothesise that the incompatibility was not alone to the previous clock, but common to them. Can you advise?

[Tony]

I have a couple of new GPS modules to test over the weekend and will check the GPS code is behaving as it should. All clocks will be the same as the firmware is identical. The timezone offset is GMT by default. Are you seeing any other strange variables set?.

[Tony]

The field separation is the comma, Dps won't alter the position of the time data. This is the relevant part of the code, it reads the first 6 bytes after the first comma, counts to the date field, then reads another 6 bytes.
XXXsnipXXX

Note how the RMC message starts "GN" not "GP". Is that o.k.?

You see the reason I think it does not sync is that:
a) The time does not appear to change to the right time" UTC.
b) Menu 9.6 only ever appears to permit me to set the year (YY.YY) and never a timezone.

The code only looks for RMC, the first 2 letters are ignored so it's not that. Note that the timezone
change is only applied to incoming GPS data and not to the current time. If it's syncing there will be no doubt about if it's working, the date and time will be correct. Something seems to be confusing the code, can you see if the serial data reaching the PIC is clean?.

[jmmcg]

[SOLVED] Good catch: there was a dry joint on the serial-to-USB converter module that meant the data to the computer was fine, but to the clock too noisy. Re-soldered: time, date & year synchronised right away (as the GNSS module had an up-to-date ephemeris). Looks like that was the issue as that board was common to tests on both clocks, hence the common issue. *Thanks a lot.* I shall soak test the GNSS module with it and let you know. I expect all to be well. Ran overnight, with some brief unplugging & plugging, all well, as suspected. Apologies for the hassle.

[jmmcg]

With the GNSS module attached when I power up the clock it often displays this behaviour: it shows "15[+/-]15" for about 10 seconds (and responds to the IR) then the display changes to "5~~~5" where "~" means the nixie is not lit and the clock no longer responds to the IR sensor. Without the GNSS module it starts fine. Looking at the MEA output from the GNSS module (on start-up it has no lock, of course):

Code: Select all

XXXsnipXXX
$GNRMC,,V,,,,,,,,,,N*4D
$GNRMC,,V,,,,,,,,,,N*4D
$GNRMC,185124.58,V,,,,,,,,,,N*65
$GNRMC,185125.00,V,,,,,,,,,,N*69
$GNRMC,185127.00,V,,,,,,,,,,N*6B
$GNRMC,185128.00,V,,,,,,,,,,N*64
$GNRMC,185129.00,V,,,,,,,,,,N*65
$GNRMC,185130.00,V,,,,,,,,,,N*6D
$GNRMC,185131.00,V,,,,,,,,,,N*6C
$GNRMC,185132.00,V,,,,,,,,,,N*6F
$GNRMC,185133.00,V,,,,,,,,,,N*6E
$GNRMC,185134.00,V,,,,,,,,,,N*69
$GNRMC,185135.00,V,,,,,,,,,,N*68
$GNRMC,185136.00,V,,,,,,,,,,N*6B
$GNRMC,185137.00,V,,,,,,,,,,N*6A
$GNRMC,185138.00,V,,,,,,,,,,N*65
$GNRMC,185139.00,V,,,,,,,,,,N*64
$GNRMC,185140.00,V,,,,,,,,,,N*6A
$GNRMC,185141.00,V,,,,,,,,,,N*6B
$GNRMC,185142.00,V,,,,,,,,,,N*68
$GNRMC,185143.00,V,,,,,,,,,,N*69
$GNRMC,185144.00,V,,,,,,,,,,N*6E
$GNRMC,185145.00,V,,,,,,,070820,,,N*62
$GNRMC,185146.00,V,,,,,,,070820,,,N*61
XXXsnipXXX

This is most curious: the date seems to be updated 20+seconds after the time. From a previous post you made, I quote:

This is the relevant part of the code, it reads the first 6 bytes after the first comma, counts to the date field, then reads another 6 bytes.

Is it ok for the date to be optional in the RMC message? I hope the behaviour of my GNSS module is not out-of-specification regarding the clock!