Your VOTER/RTCM May Have Broken Itself on 01/01/21 00:01

App_rpt-users
7

Here is the output of my “98”
Enter Selection (1-27,97-99,r,q,d) : 98

S/W Version: 1.54 04/14/2020
System Uptime: 1416.9 Secs
IP Address: 10.10.10.241
Netmask: 255.255.255.0
Gateway: 10.10.10.1
Primary DNS: 8.8.8.8
Secondary DNS: 8.8.4.4
DHCP: 0
VOTER Server IP: 10.10.10.134
VOTER Server UDP Port: 668
OUR UDP Port: 668
GPS Lock: 1
Connected: 1
COR: 0
EXT CTCSS IN: 0
PTT: 0
RSSI: 0
Current Samples / Sec.: 8000
Current Peak Audio Level: 51208
Squelch Noise Gain Value: 106, Diode Cal. Value: 43, SQL pot 167
Current Time: Tue Jan 05, 2021 20:11:32.180
Last Rx Pkt System time: 01/05/2021 20:11:09.760, diff: 22420 msec
Last Rx Pkt Timestamp time: 01/05/2021 20:11:09.760, diff: 0 msec
Last Rx Pkt index: 180, inbounds: 1

And here is output from my debug 32

GPS-DEBUG: $GPGGA,201338,4030.0246,N,08855.9307,W,2,09,0.9,254.0,M,-32.3,M,7E
GPS-DEBUG: $GPGSA,A,3,03,04,07,09,16,22,26,27,31,1.6,0.9,1.333
GPS-DEBUG: $GPGSV,3,1,11,03,28,221,34,04,78,296,42,07,12,277,33,08,07,175,2478
GPS-DEBUG: $GPGSV,3,2,11,09,37,311,43,16,80,081,40,22,14,203,34,26,46,051,3574
GPS-DEBUG: $GPGSV,3,3,11,27,27,145,38,29,02,027,25,31,16,082,294D
GPS-DEBUG: $GPRMC,201339,A,4030.0246,N,08855.9307,W,000.0,343.0,220501,002.3,W77
GPS-DEBUG: mon: 4, gps_time: 1609877619, real_time: 1609877619, ctime: Tue Jan 5 20:13:39 2021

GPS-DEBUG: $GPGGA,201339,4030.0246,N,08855.9307,W,2,09,0.9,254.0,M,-32.3,M,7F
GPS-DEBUG: $GPGSA,A,3,03,04,07,09,16,22,26,27,31,1.6,0.9,1.333
GPS-DEBUG: $GPGSV,3,1,11,03,28,221,34,04,78,296,42,07,12,277,33,08,07,175,2478
GPS-DEBUG: $GPGSV,3,2,11,09,37,311,43,16,80,081,40,22,14,203,34,26,46,051,3574
GPS-DEBUG: $GPGSV,3,3,11,27,27,145,38,29,02,027,25,31,16,082,294D
GPS-DEBUG: $GPRMC,201340,A,4030.0246,N,08855.9307,W,000.0,343.0,220501,002.3,W79
GPS-DEBUG: mon: 4, gps_time: 1609877620, real_time: 1609877620, ctime: Tue Jan 5 20:13:40 2021

This tells me that there is nothing wrong with mktime as used in this code.
I do not have a Trimble to test with, but I have a variety of Garmin that each need a different offset to correct them.

···

On Tue, Jan 5, 2021 at 1:50 PM Lee via AllStarLink Discussion Groups <noreply@community.allstarlink.org> wrote:

| ve7fet
January 5 |

  • | - |

Hi Chuck,

I don’t believe that is going to help in this case. I am running a similarly modified firmware (have been testing a number of similar changes to what you have in that branch), and they were all running fine, until we rolled over on NYE.

The problem isn’t a week rollover issue, it is a bug in the mktime routine, causing it to return -1 when you send it the tm struct to convert to epoch time.

That causes gpstime to be -1, so, it always starts counting at something like Dec 31, 1970 at 1600 (I can’t recall the exact time off the top of my head).

So, resetting the GPS, always causes it to start counting from that date, regardless of what the real date/time is.

At least, that is what I am seeing on both the TSIP (Trimble) and NMEA devices I have access to, they’re both behaving the same (and were previously working just fine).

I think the fix will be to convert the date/time from the GPS to epoch with a stand-alone function, that doesn’t use the built-in mktime from time.h.

Unfortunately, the box I was using to compile test code on decided to blow up (thanks Microsoft updates), so I haven’t had a chance to compile and test a fix, yet.

Lee

Visit Topic or reply to this email to respond.

Previous Replies

| Chuck_Henderson
January 5 |

  • | - |

You need “S/W Version: 1.54 04/14/2020” the source can be found at https://github.com/ccie2285/voter or at https://github.com/AllStarLink/voter/tree/testing or at https://github.com/pttlink/voter/tree/testing
This 1.54 has multiple fixes for different GPS versions and can accept different values for offline menu 12. Values of 0, 1, 2, 3, and 4 are available and different GPSs require different choices to get accurate dates and times. Use trial and error to find the best choice. If you find a GPS that does not work with any of those choices, let me know exactly what offset it needs so I can include it in the next version.

In each case, a reboot is needed after changing and saving each time the offline menu 12 choice.

I have not uploaded the compiled binary files for these because I have got no feedback on the code. But it works for me and I have several different Garmin GPSs that each require a different offset value. I do not have any other brands of GPS to test with.

··· (click for more details)

| WB6OZD
January 5 |

  • | - |

I’m running two different firmware versions on my various RTCM’s and this problem only shows up on the older v1.50 firmware. My other units are running the v1.51CHUCK version and did not have any issues. Looks like I’ll update the others to the same version to fix it.

| W8khw1
January 4 |

  • | - |

Wow, great catch. I just checked my RTCM’s and they are indeed showing the wrong date of 01/01/1970. It’s surprising to me that the message thread you referenced was from back in 2012.

73,

Kevin
W8KHW

··· (click for more details)

| ve7fet
January 4 |

  • | - |

Well, I found this (by accident) about a month ago, which scared the hell out of me:

https://www.microchip.com/forums/m653169.aspx

So, I did some testing/compiling to fast-forward time, and watch how it behaved when time rolled over.

Apparently, my testing wasn’t very good, because in my tests time rolled over fine from 12/31/2020 to 01/01/2021.

If you go look at the time in your VOTER/RTCM right now, it is going to be a mess (98 - status or debug 32), and if you do a voter debug level 3 in Asterisk, you’re going to see some strange things too (time starting back at around 1969 or 1970).

Indeed, mktime in the C30 compiler is broken, and broke the firmware in the VOTER/RTCM.

This may cause your satellite receivers to show they are connected to Asterisk, but they never receive anything. That will happen if there is a time differential between your master and the satellite receivers.

I’m going to try a couple solutions to see if I can find a way around this bug. I am hoping I can do a “Jim Special” and come up with a kluge to convert the time from the GPS to epoch time, without using mktime. I have seen some example code, and will see if I can cram it in to the PIC (man, space is getting real tight).

So, if you are seeing broken times, or your satellite receivers may have fallen off the air, this may be the cause.

I’m developing it over on my Github repo, along with some other firmware changes, and will create a pull request if I can find a solution, and once all the politics with the official repo get sorted out.

Lee

Visit Topic or reply to this email to respond.

You are receiving this because you enabled mailing list mode.

To unsubscribe from these emails, click here.

8

Well, isn’t that interesting.

That begs the question then, which version of MPLAB and more specifically, which version of C30 did you compile that with?

Lee

9

Hi Kevin,

Yeah, tried compiling it with the legacy libs, and that breaks other stuff. :slight_smile:

Lee

10

Upon checking additional RTCM’s, I’m finding that I have units both with and without the issue running 1.51 Chuck (8/8/17). I cannot say if they were loaded with the same binary copy of the firmware though. I also have a 1.50 version that does not have the date problem.

I’ll try flashing some tonight with the binary versions I have to see if any builds I have work fine. I have no idea what version of MPLAB was used to build them.

If you guys come up with a specific version that works, I’d be happy to test your binary here on my units as well.

11

I just now uploaded the 2 binary files that I use here.
https://github.com/ccie2285/voter/tree/master/board-firmware

they are
Voter154SMT04-14-20c.cry S/W Version: 1.54 04/14/2020 “CHUCK” for RTCM

and
Voter154voter-04-14-20c.cry S/W Version: 1.54 04/14/2020 “CHUCK” for Voter Board

I am using the compiler that I have been using since the beginning back in about 2010 that is running on Windows XP service pack 2 (offline)
It is a pain to get files onto and off of without a network, but I can slowly transfer via USB 2 thumb drives.

I only compile versions that I have hardware to test. Both of these files have been running without problems since 4-14-2020, the day I compiled them.
don’t forget to set offline #12 to one of 0, 1, 2, 3, or 4 and save and reboot
Chuck

···

On Tue, Jan 5, 2021 at 3:14 PM Jon Welfringer via AllStarLink Discussion Groups <noreply@community.allstarlink.org> wrote:

| WB6OZD
January 5 |

  • | - |

Upon checking additional RTCM’s, I’m finding that I have units both with and without the issue running 1.51 Chuck (8/8/17). I cannot say if they were loaded with the same binary copy of the firmware though. I also have a 1.50 version that does not have the date problem.

I’ll try flashing some tonight with the binary versions I have to see if any builds I have work fine. I have no idea what version of MPLAB was used to build them.

If you guys come up with a specific version that works, I’d be happy to test your binary here on my units as well.

Visit Topic or reply to this email to respond.

Previous Replies

| ve7fet
January 5 |

  • | - |

Hi Kevin,

Yeah, tried compiling it with the legacy libs, and that breaks other stuff. :slight_smile:

Lee

| ve7fet
January 5 |

  • | - |

Well, isn’t that interesting.

That begs the question then, which version of MPLAB and more specifically, which version of C30 did you compile that with?

Lee

| Chuck_Henderson
January 5 |

  • | - |

Here is the output of my “98”
Enter Selection (1-27,97-99,r,q,d) : 98

S/W Version: 1.54 04/14/2020
System Uptime: 1416.9 Secs
IP Address: 10.10.10.241
Netmask: 255.255.255.0
Gateway: 10.10.10.1
Primary DNS: 8.8.8.8
Secondary DNS: 8.8.4.4
DHCP: 0
VOTER Server IP: 10.10.10.134
VOTER Server UDP Port: 668
OUR UDP Port: 668
GPS Lock: 1
Connected: 1
COR: 0
EXT CTCSS IN: 0
PTT: 0
RSSI: 0
Current Samples / Sec.: 8000
Current Peak Audio Level: 51208
Squelch Noise Gain Value: 106, Diode Cal. Value: 43, SQL pot 167
Current Time: Tue Jan 05, 2021 20:11:32.180
Last Rx Pkt System time: 01/05/2021 20:11:09.760, diff: 22420 msec
Last Rx Pkt Timestamp time: 01/05/2021 20:11:09.760, diff: 0 msec
Last Rx Pkt index: 180, inbounds: 1

And here is output from my debug 32

GPS-DEBUG: $GPGGA,201338,4030.0246,N,08855.9307,W,2,09,0.9,254.0,M,-32.3,M,7E
GPS-DEBUG: $GPGSA,A,3,03,04,07,09,16,22,26,27,31,1.6,0.9,1.333
GPS-DEBUG: $GPGSV,3,1,11,03,28,221,34,04,78,296,42,07,12,277,33,08,07,175,2478
GPS-DEBUG: $GPGSV,3,2,11,09,37,311,43,16,80,081,40,22,14,203,34,26,46,051,3574
GPS-DEBUG: $GPGSV,3,3,11,27,27,145,38,29,02,027,25,31,16,082,294D
GPS-DEBUG: $GPRMC,201339,A,4030.0246,N,08855.9307,W,000.0,343.0,220501,002.3,W77
GPS-DEBUG: mon: 4, gps_time: 1609877619, real_time: 1609877619, ctime: Tue Jan 5 20:13:39 2021

GPS-DEBUG: $GPGGA,201339,4030.0246,N,08855.9307,W,2,09,0.9,254.0,M,-32.3,M,7F
GPS-DEBUG: $GPGSA,A,3,03,04,07,09,16,22,26,27,31,1.6,0.9,1.333
GPS-DEBUG: $GPGSV,3,1,11,03,28,221,34,04,78,296,42,07,12,277,33,08,07,175,2478
GPS-DEBUG: $GPGSV,3,2,11,09,37,311,43,16,80,081,40,22,14,203,34,26,46,051,3574
GPS-DEBUG: $GPGSV,3,3,11,27,27,145,38,29,02,027,25,31,16,082,294D
GPS-DEBUG: $GPRMC,201340,A,4030.0246,N,08855.9307,W,000.0,343.0,220501,002.3,W79
GPS-DEBUG: mon: 4, gps_time: 1609877620, real_time: 1609877620, ctime: Tue Jan 5 20:13:40 2021

This tells me that there is nothing wrong with mktime as used in this code.
I do not have a Trimble to test with, but I have a variety of Garmin that each need a different offset to correct them.

··· (click for more details)

| W8khw1
January 5 |

  • | - |

I have a system that has been running for years without requiring any fiddling. I noticed the RTCM’s were running v1.50, so I decided to setup a spare RTCM and test v1.51. The updated version doesn’t report an error, but it also doesn’t set the System Time. I am running one of the QRP Labs GPS devices on the test unit (and also at a couple receive sites). When checking status with menu 98 it reports

I would be happy to test v1.54 and see if that works if the binary was available. I had difficulty getting the compiler working correctly the last time I tried.

Lee, the original link you provided from microchip had a “work around” post in the thread. I believe it mentioned using an alternate library.

Thanks for everybody’s help with this.

Kevin
W8KHW

··· (click for more details)

| ve7fet
January 5 |

  • | - |

Hi Chuck,

I don’t believe that is going to help in this case. I am running a similarly modified firmware (have been testing a number of similar changes to what you have in that branch), and they were all running fine, until we rolled over on NYE.

The problem isn’t a week rollover issue, it is a bug in the mktime routine, causing it to return -1 when you send it the tm struct to convert to epoch time.

That causes gpstime to be -1, so, it always starts counting at something like Dec 31, 1970 at 1600 (I can’t recall the exact time off the top of my head).

So, resetting the GPS, always causes it to start counting from that date, regardless of what the real date/time is.

At least, that is what I am seeing on both the TSIP (Trimble) and NMEA devices I have access to, they’re both behaving the same (and were previously working just fine).

I think the fix will be to convert the date/time from the GPS to epoch with a stand-alone function, that doesn’t use the built-in mktime from time.h.

Unfortunately, the box I was using to compile test code on decided to blow up (thanks Microsoft updates), so I haven’t had a chance to compile and test a fix, yet.

Lee

Visit Topic or reply to this email to respond.

You are receiving this because you enabled mailing list mode.

To unsubscribe from these emails, click here.

12

Thank you for uploading the binary files Chuck! Unfortunately I still have no glory on setting the time, but I am still testing with the QRP Labs GPS module which might be the problem. I am sure that I have some Garmin 18 puck GPS modules around here as well as a Thunderbolt running downstairs. I will give them a try later this evening.

Kevin, W8KHW

My Status output:

GPS signal acquired, number of satellites in use = 3
Warning: GPS Data time period elapsed
Warning: GPS PPS Signal time period elapsed
Time now syncronized to GPS

Enter Selection (1-27,97-99,r,q,d) : 98
S/W Version: 1.54 04/14/2020
System Uptime: 73.3 Secs
IP Address: 172.25.36.189
Netmask: 255.255.255.0
Gateway: 172.25.36.1
Primary DNS: 172.25.36.107
Secondary DNS: 172.25.34.108
DHCP: 0
VOTER Server IP: 172.25.36.89
VOTER Server UDP Port: 667
OUR UDP Port: 667
GPS Lock: 1
Connected: 0
COR: 1
EXT CTCSS IN: 1
PTT: 0
RSSI: 0
Current Samples / Sec.: 8000
Current Peak Audio Level: 40
Squelch Noise Gain Value: 20, Diode Cal. Value: 50, SQL pot 265
Last Rx Pkt System time: , diff: 0 msec
Last Rx Pkt Timestamp time: , diff: 0 msec
Last Rx Pkt index: 0, inbounds: 0

···

On Tue, Jan 5, 2021 at 4:59 PM Chuck Henderson via AllStarLink Discussion Groups <noreply@community.allstarlink.org> wrote:

| Chuck_Henderson
January 5 |

  • | - |

I just now uploaded the 2 binary files that I use here.
https://github.com/ccie2285/voter/tree/master/board-firmware

they are
Voter154SMT04-14-20c.cry S/W Version: 1.54 04/14/2020 “CHUCK” for RTCM

and
Voter154voter-04-14-20c.cry S/W Version: 1.54 04/14/2020 “CHUCK” for Voter Board

I am using the compiler that I have been using since the beginning back in about 2010 that is running on Windows XP service pack 2 (offline)
It is a pain to get files onto and off of without a network, but I can slowly transfer via USB 2 thumb drives.

I only compile versions that I have hardware to test. Both of these files have been running without problems since 4-14-2020, the day I compiled them.
don’t forget to set offline #12 to one of 0, 1, 2, 3, or 4 and save and reboot
Chuck

··· (click for more details)

Visit Topic or reply to this email to respond.

In Reply To

| WB6OZD
January 5 |

  • | - |

Upon checking additional RTCM’s, I’m finding that I have units both with and without the issue running 1.51 Chuck (8/8/17). I cannot say if they were loaded with the same binary copy of the firmware though. I also have a 1.50 version that does not have the date problem. I’ll try flashing some ton…

Visit Topic or reply to this email to respond.

You are receiving this because you enabled mailing list mode.

To unsubscribe from these emails, click here.

13

No go for me on the update as well. Tried all settings of option 12 (0,1,2,3,4) and get varying “Current Time” showing:
0 - 01/01/1970, time is value from power up
1 - 10/06/1988, 02:43:43
2 - 08/17/1989, time is value from power up
3 - 05/22/2008, 02:43:43
4 - 08/02/2009, time is value from power up
(note that current time was about UTC 23:28 when testing).

I’m currently testing with a newer BG7TBL unit, but I have a Garmin I can give a go on as well.

Here’s my status output:
S/W Version: 1.54 04/14/2020
System Uptime: 76.7 Secs
IP Address: 192.168.1.51
Netmask: 255.255.255.0
Gateway: 192.168.1.1
Primary DNS: 192.168.1.22
Secondary DNS: 1.1.1.1
DHCP: 1
VOTER Server IP: 192.5.222.90
VOTER Server UDP Port: 667
OUR UDP Port: 667
GPS Lock: 1
Connected: 1
COR: 0
EXT CTCSS IN: 1
PTT: 0
RSSI: 0
Current Samples / Sec.: 8000
Current Peak Audio Level: 53144
Squelch Noise Gain Value: 24, Diode Cal. Value: 44, SQL pot 559
Current Time: Thu Apr 02, 2009 00:01:09.300
Last Rx Pkt System time: , diff: 1679888052 msec
Last Rx Pkt Timestamp time: , diff: 0 msec
Last Rx Pkt index: 0, inbounds: 0

14

I got the same results as WB6OZD. I’m also using a BG7BTL GPS receiver and using the 1.54 voter board version.

Greg
WB6ZSU

15

I just finished testing with a Garmin !8 GPS. Still not setting the time correctly.

Enter Selection (1-27,97-99,r,q,d) : 98
S/W Version: 1.54 04/14/2020
System Uptime: 982.2 Secs
IP Address: 192.168.1.10
Netmask: 255.255.255.0
Gateway: 192.168.1.1
Primary DNS: 192.168.1.1
Secondary DNS: 0.0.0.0
DHCP: 1
VOTER Server IP: 0.0.0.0
VOTER Server UDP Port: 667
OUR UDP Port: 667
GPS Lock: 0
Connected: 0
COR: 1
EXT CTCSS IN: 1
PTT: 0
RSSI: 0
Current Samples / Sec.: 0
Current Peak Audio Level: 24
Squelch Noise Gain Value: 35, Diode Cal. Value: 41, SQL pot 179
Last Rx Pkt System time: , diff: 0 msec
Last Rx Pkt Timestamp time: , diff: 0 msec
Last Rx Pkt index: 0, inbounds: 0

Press The Any Key (Enter) To Continue
GPS signal lost entirely. Starting again…
GPS Receiver Active, waiting for aquisition
GPS signal acquired, number of satellites in use = 4
Time now syncronized to GPS

···

On Tue, Jan 5, 2021 at 7:03 PM Jon Welfringer via AllStarLink Discussion Groups <noreply@community.allstarlink.org> wrote:

| WB6OZD
January 5 |

  • | - |

No go for me on the update as well. Tried all settings of option 12 (0,1,2,3,4) and get varying “Current Time” showing:
0 - 01/01/1970, time is value from power up
1 - 10/06/1988, 02:43:43
2 - 08/17/1989, time is value from power up
3 - 05/22/2008, 02:43:43
4 - 08/02/2009, time is value from power up
(note that current time was about UTC 23:28 when testing).

I’m currently testing with a newer BG7TBL unit, but I have a Garmin I can give a go on as well.

Here’s my status output:
S/W Version: 1.54 04/14/2020
System Uptime: 76.7 Secs
IP Address: 192.168.1.51
Netmask: 255.255.255.0
Gateway: 192.168.1.1
Primary DNS: 192.168.1.22
Secondary DNS: 1.1.1.1
DHCP: 1
VOTER Server IP: 192.5.222.90
VOTER Server UDP Port: 667
OUR UDP Port: 667
GPS Lock: 1
Connected: 1
COR: 0
EXT CTCSS IN: 1
PTT: 0
RSSI: 0
Current Samples / Sec.: 8000
Current Peak Audio Level: 53144
Squelch Noise Gain Value: 24, Diode Cal. Value: 44, SQL pot 559
Current Time: Thu Apr 02, 2009 00:01:09.300
Last Rx Pkt System time: , diff: 1679888052 msec
Last Rx Pkt Timestamp time: , diff: 0 msec
Last Rx Pkt index: 0, inbounds: 0

Visit Topic or reply to this email to respond.

You are receiving this because you enabled mailing list mode.

To unsubscribe from these emails, click here.

16

Hi Chuck,

Yes, I have MPLAB running in “Windows XP Mode” (virtual machine) on my (broken) Windows 7 laptop. The nice thing about it is that it lets you map a shared folder to the host (Windows 7), so it is easy to get files in and out of the build environment.

I am wondering if you can tell me what version of the compiler (MPLAB C Compiler) you are running is (probably in Help/About in MPLAB)?

I am trying to restore my compiler environment, to confirm indeed that I was using the latest released version of the compiler (v3.31).

Lee

17

Hello,

I have sent an email to Microchip support asking if there is an updated library to solve the mktime issue. I also sent an email to Mark at Micro Node trying to make him aware of the issue.

I’m still trying to sort out why some users aren’t having any issues - are they all running Thunderbolts and the TB works?

I’d really like to get my repeater system back on the air.

73,
Kevin
W8KHW

···

On Jan 5, 2021, at 9:30 PM, Lee via AllStarLink Discussion Groups noreply@community.allstarlink.org wrote:

| ve7fet
January 6 |

  • | - |

Hi Chuck,

Yes, I have MPLAB running in “Windows XP Mode” (virtual machine) on my (broken) Windows 7 laptop. The nice thing about it is that it lets you map a shared folder to the host (Windows 7), so it is easy to get files in and out of the build environment.

I am wondering if you can tell me what version of the compiler (MPLAB C Compiler) you are running is (probably in Help/About in MPLAB)?

I am trying to restore my compiler environment, to confirm indeed that I was using the latest released version of the compiler (v3.31).

Lee

Visit Topic or reply to this email to respond.

In Reply To

| Chuck_Henderson
January 5 |

  • | - |

I just now uploaded the 2 binary files that I use here. https://github.com/ccie2285/voter/tree/master/board-firmware they are Voter154SMT04-14-20c.cry S/W Version: 1.54 04/14/2020 “CHUCK” for RTCM and Voter154voter-04-14-20c.cry S/W Version: 1.54 04/14/2020 “CHUCK” for Voter Board I am using t…

Visit Topic or reply to this email to respond.

You are receiving this because you enabled mailing list mode.

To unsubscribe from these emails, click here.

18

v3.30
Chuck

···

On Tue, Jan 5, 2021 at 8:29 PM Lee via AllStarLink Discussion Groups <noreply@community.allstarlink.org> wrote:

| ve7fet
January 6 |

  • | - |

Hi Chuck,

Yes, I have MPLAB running in “Windows XP Mode” (virtual machine) on my (broken) Windows 7 laptop. The nice thing about it is that it lets you map a shared folder to the host (Windows 7), so it is easy to get files in and out of the build environment.

I am wondering if you can tell me what version of the compiler (MPLAB C Compiler) you are running is (probably in Help/About in MPLAB)?

I am trying to restore my compiler environment, to confirm indeed that I was using the latest released version of the compiler (v3.31).

Lee

Visit Topic or reply to this email to respond.

Previous Replies

| W8khw1
January 6 |

  • | - |

I just finished testing with a Garmin !8 GPS. Still not setting the time correctly.

Enter Selection (1-27,97-99,r,q,d) : 98
S/W Version: 1.54 04/14/2020
System Uptime: 982.2 Secs
IP Address: 192.168.1.10
Netmask: 255.255.255.0
Gateway: 192.168.1.1
Primary DNS: 192.168.1.1
Secondary DNS: 0.0.0.0
DHCP: 1
VOTER Server IP: 0.0.0.0
VOTER Server UDP Port: 667
OUR UDP Port: 667
GPS Lock: 0
Connected: 0
COR: 1
EXT CTCSS IN: 1
PTT: 0
RSSI: 0
Current Samples / Sec.: 0
Current Peak Audio Level: 24
Squelch Noise Gain Value: 35, Diode Cal. Value: 41, SQL pot 179
Last Rx Pkt System time: , diff: 0 msec
Last Rx Pkt Timestamp time: , diff: 0 msec
Last Rx Pkt index: 0, inbounds: 0

Press The Any Key (Enter) To Continue
GPS signal lost entirely. Starting again…
GPS Receiver Active, waiting for aquisition
GPS signal acquired, number of satellites in use = 4
Time now syncronized to GPS

··· (click for more details)

| Gregn1
January 6 |

  • | - |

I got the same results as WB6OZD. I’m also using a BG7BTL GPS receiver and using the 1.54 voter board version.

Greg
WB6ZSU

| WB6OZD
January 5 |

  • | - |

No go for me on the update as well. Tried all settings of option 12 (0,1,2,3,4) and get varying “Current Time” showing:
0 - 01/01/1970, time is value from power up
1 - 10/06/1988, 02:43:43
2 - 08/17/1989, time is value from power up
3 - 05/22/2008, 02:43:43
4 - 08/02/2009, time is value from power up
(note that current time was about UTC 23:28 when testing).

I’m currently testing with a newer BG7TBL unit, but I have a Garmin I can give a go on as well.

Here’s my status output:
S/W Version: 1.54 04/14/2020
System Uptime: 76.7 Secs
IP Address: 192.168.1.51
Netmask: 255.255.255.0
Gateway: 192.168.1.1
Primary DNS: 192.168.1.22
Secondary DNS: 1.1.1.1
DHCP: 1
VOTER Server IP: 192.5.222.90
VOTER Server UDP Port: 667
OUR UDP Port: 667
GPS Lock: 1
Connected: 1
COR: 0
EXT CTCSS IN: 1
PTT: 0
RSSI: 0
Current Samples / Sec.: 8000
Current Peak Audio Level: 53144
Squelch Noise Gain Value: 24, Diode Cal. Value: 44, SQL pot 559
Current Time: Thu Apr 02, 2009 00:01:09.300
Last Rx Pkt System time: , diff: 1679888052 msec
Last Rx Pkt Timestamp time: , diff: 0 msec
Last Rx Pkt index: 0, inbounds: 0

| W8khw1
January 5 |

  • | - |

Thank you for uploading the binary files Chuck! Unfortunately I still have no glory on setting the time, but I am still testing with the QRP Labs GPS module which might be the problem. I am sure that I have some Garmin 18 puck GPS modules around here as well as a Thunderbolt running downstairs. I will give them a try later this evening.

Kevin, W8KHW

My Status output:

GPS signal acquired, number of satellites in use = 3
Warning: GPS Data time period elapsed
Warning: GPS PPS Signal time period elapsed
Time now syncronized to GPS

Enter Selection (1-27,97-99,r,q,d) : 98
S/W Version: 1.54 04/14/2020
System Uptime: 73.3 Secs
IP Address: 172.25.36.189
Netmask: 255.255.255.0
Gateway: 172.25.36.1
Primary DNS: 172.25.36.107
Secondary DNS: 172.25.34.108
DHCP: 0
VOTER Server IP: 172.25.36.89
VOTER Server UDP Port: 667
OUR UDP Port: 667
GPS Lock: 1
Connected: 0
COR: 1
EXT CTCSS IN: 1
PTT: 0
RSSI: 0
Current Samples / Sec.: 8000
Current Peak Audio Level: 40
Squelch Noise Gain Value: 20, Diode Cal. Value: 50, SQL pot 265
Last Rx Pkt System time: , diff: 0 msec
Last Rx Pkt Timestamp time: , diff: 0 msec
Last Rx Pkt index: 0, inbounds: 0

··· (click for more details)

| Chuck_Henderson
January 5 |

  • | - |

I just now uploaded the 2 binary files that I use here.
https://github.com/ccie2285/voter/tree/master/board-firmware

they are
Voter154SMT04-14-20c.cry S/W Version: 1.54 04/14/2020 “CHUCK” for RTCM

and
Voter154voter-04-14-20c.cry S/W Version: 1.54 04/14/2020 “CHUCK” for Voter Board

I am using the compiler that I have been using since the beginning back in about 2010 that is running on Windows XP service pack 2 (offline)
It is a pain to get files onto and off of without a network, but I can slowly transfer via USB 2 thumb drives.

I only compile versions that I have hardware to test. Both of these files have been running without problems since 4-14-2020, the day I compiled them.
don’t forget to set offline #12 to one of 0, 1, 2, 3, or 4 and save and reboot
Chuck

··· (click for more details)

Visit Topic or reply to this email to respond.

You are receiving this because you enabled mailing list mode.

To unsubscribe from these emails, click here.

19

Kevin,
I notice that you do not have “GPS lock” in the 98 output that you showed us.
Try again but allow more time to get GPS lock before using “98”

I use the Garmin 18 puck GPS and I use datefix “2”

If you use my compile and NEMA it should work for you. If you do not get GPS lock then you probably have a hardware or cable or GPS signal problem.

Send full output of debug 32
Chuck

···

On Tue, Jan 5, 2021 at 6:52 PM Kevin Walsh via AllStarLink Discussion Groups <noreply@community.allstarlink.org> wrote:

| W8khw1
January 6 |

  • | - |

I just finished testing with a Garmin !8 GPS. Still not setting the time correctly.

Enter Selection (1-27,97-99,r,q,d) : 98
S/W Version: 1.54 04/14/2020
System Uptime: 982.2 Secs
IP Address: 192.168.1.10
Netmask: 255.255.255.0
Gateway: 192.168.1.1
Primary DNS: 192.168.1.1
Secondary DNS: 0.0.0.0
DHCP: 1
VOTER Server IP: 0.0.0.0
VOTER Server UDP Port: 667
OUR UDP Port: 667
GPS Lock: 0
Connected: 0
COR: 1
EXT CTCSS IN: 1
PTT: 0
RSSI: 0
Current Samples / Sec.: 0
Current Peak Audio Level: 24
Squelch Noise Gain Value: 35, Diode Cal. Value: 41, SQL pot 179
Last Rx Pkt System time: , diff: 0 msec
Last Rx Pkt Timestamp time: , diff: 0 msec
Last Rx Pkt index: 0, inbounds: 0

Press The Any Key (Enter) To Continue
GPS signal lost entirely. Starting again…
GPS Receiver Active, waiting for aquisition
GPS signal acquired, number of satellites in use = 4
Time now syncronized to GPS

··· (click for more details)

Visit Topic or reply to this email to respond.

Previous Replies

| Gregn1
January 6 |

  • | - |

I got the same results as WB6OZD. I’m also using a BG7BTL GPS receiver and using the 1.54 voter board version.

Greg
WB6ZSU

| WB6OZD
January 5 |

  • | - |

No go for me on the update as well. Tried all settings of option 12 (0,1,2,3,4) and get varying “Current Time” showing:
0 - 01/01/1970, time is value from power up
1 - 10/06/1988, 02:43:43
2 - 08/17/1989, time is value from power up
3 - 05/22/2008, 02:43:43
4 - 08/02/2009, time is value from power up
(note that current time was about UTC 23:28 when testing).

I’m currently testing with a newer BG7TBL unit, but I have a Garmin I can give a go on as well.

Here’s my status output:
S/W Version: 1.54 04/14/2020
System Uptime: 76.7 Secs
IP Address: 192.168.1.51
Netmask: 255.255.255.0
Gateway: 192.168.1.1
Primary DNS: 192.168.1.22
Secondary DNS: 1.1.1.1
DHCP: 1
VOTER Server IP: 192.5.222.90
VOTER Server UDP Port: 667
OUR UDP Port: 667
GPS Lock: 1
Connected: 1
COR: 0
EXT CTCSS IN: 1
PTT: 0
RSSI: 0
Current Samples / Sec.: 8000
Current Peak Audio Level: 53144
Squelch Noise Gain Value: 24, Diode Cal. Value: 44, SQL pot 559
Current Time: Thu Apr 02, 2009 00:01:09.300
Last Rx Pkt System time: , diff: 1679888052 msec
Last Rx Pkt Timestamp time: , diff: 0 msec
Last Rx Pkt index: 0, inbounds: 0

| W8khw1
January 5 |

  • | - |

Thank you for uploading the binary files Chuck! Unfortunately I still have no glory on setting the time, but I am still testing with the QRP Labs GPS module which might be the problem. I am sure that I have some Garmin 18 puck GPS modules around here as well as a Thunderbolt running downstairs. I will give them a try later this evening.

Kevin, W8KHW

My Status output:

GPS signal acquired, number of satellites in use = 3
Warning: GPS Data time period elapsed
Warning: GPS PPS Signal time period elapsed
Time now syncronized to GPS

Enter Selection (1-27,97-99,r,q,d) : 98
S/W Version: 1.54 04/14/2020
System Uptime: 73.3 Secs
IP Address: 172.25.36.189
Netmask: 255.255.255.0
Gateway: 172.25.36.1
Primary DNS: 172.25.36.107
Secondary DNS: 172.25.34.108
DHCP: 0
VOTER Server IP: 172.25.36.89
VOTER Server UDP Port: 667
OUR UDP Port: 667
GPS Lock: 1
Connected: 0
COR: 1
EXT CTCSS IN: 1
PTT: 0
RSSI: 0
Current Samples / Sec.: 8000
Current Peak Audio Level: 40
Squelch Noise Gain Value: 20, Diode Cal. Value: 50, SQL pot 265
Last Rx Pkt System time: , diff: 0 msec
Last Rx Pkt Timestamp time: , diff: 0 msec
Last Rx Pkt index: 0, inbounds: 0

··· (click for more details)

| Chuck_Henderson
January 5 |

  • | - |

I just now uploaded the 2 binary files that I use here.
https://github.com/ccie2285/voter/tree/master/board-firmware

they are
Voter154SMT04-14-20c.cry S/W Version: 1.54 04/14/2020 “CHUCK” for RTCM

and
Voter154voter-04-14-20c.cry S/W Version: 1.54 04/14/2020 “CHUCK” for Voter Board

I am using the compiler that I have been using since the beginning back in about 2010 that is running on Windows XP service pack 2 (offline)
It is a pain to get files onto and off of without a network, but I can slowly transfer via USB 2 thumb drives.

I only compile versions that I have hardware to test. Both of these files have been running without problems since 4-14-2020, the day I compiled them.
don’t forget to set offline #12 to one of 0, 1, 2, 3, or 4 and save and reboot
Chuck

··· (click for more details)

| WB6OZD
January 5 |

  • | - |

Upon checking additional RTCM’s, I’m finding that I have units both with and without the issue running 1.51 Chuck (8/8/17). I cannot say if they were loaded with the same binary copy of the firmware though. I also have a 1.50 version that does not have the date problem.

I’ll try flashing some tonight with the binary versions I have to see if any builds I have work fine. I have no idea what version of MPLAB was used to build them.

If you guys come up with a specific version that works, I’d be happy to test your binary here on my units as well.

Visit Topic or reply to this email to respond.

You are receiving this because you enabled mailing list mode.

To unsubscribe from these emails, click here.

20

Hey Gents,

I’m having this same issue. I’m using a Trimble Thunderbolt-E with TSIP protocol. Still not working properly with the 1.54 version.
Here’s what I’m getting with the different settings in the GPS DateFix variable.

Datefix 0
Current Time: Thu Jan 01, 1970 00:00:05.880

DateFix 1
Current Time: Thu Aug 17, 1989 00:00:24.420

DateFix 2
Current Time: Thu Apr 02, 2009 00:00:35.460

DateFix 3
Current Time: Thu Nov 16, 2028 00:00:45.480

DateFix 4
Current Time: Monday Jan -), 1970 0*:.(:0+.060

That last one is quite interesting. My GPS debug 32 is showing everything is “good in the hood”.
Any further insight would be greatly appreciated.

GPS debug

21

Jesse,
Is this an RTCM or a voter board? I can do a custom build for you to try.Chuck

···

On Thu, Jan 7, 2021 at 5:38 PM Jesse via AllStarLink Discussion Groups <noreply@community.allstarlink.org> wrote:

| JRB
January 7 |

  • | - |

Hey Gents,

I’m having this same issue. I’m using a Trimble Thunderbolt-E with TSIP protocol. Still not working properly with the 1.54 version.
Here’s what I’m getting with the different settings in the GPS DateFix variable.

Datefix 0
Current Time: Thu Jan 01, 1970 00:00:05.880

DateFix 1
Current Time: Thu Aug 17, 1989 00:00:24.420

DateFix 2
Current Time: Thu Apr 02, 2009 00:00:35.460

DateFix 3
Current Time: Thu Nov 16, 2028 00:00:45.480

DateFix 4
Current Time: Monday Jan -), 1970 0*:.(:0+.060

That last one is quite interesting. My GPS debug 32 is showing everything is “good in the hood”.
Any further insight would be greatly appreciated.

Visit Topic or reply to this email to respond.

Previous Replies

| Chuck_Henderson
January 7 |

  • | - |

Kevin,
I notice that you do not have “GPS lock” in the 98 output that you showed us.
Try again but allow more time to get GPS lock before using “98”

I use the Garmin 18 puck GPS and I use datefix “2”

If you use my compile and NEMA it should work for you. If you do not get GPS lock then you probably have a hardware or cable or GPS signal problem.

Send full output of debug 32
Chuck

··· (click for more details)

| Chuck_Henderson
January 7 |

  • | - |

v3.30
Chuck

··· (click for more details)

| W8khw1
January 7 |

  • | - |

Hello,

I have sent an email to Microchip support asking if there is an updated library to solve the mktime issue. I also sent an email to Mark at Micro Node trying to make him aware of the issue.

I’m still trying to sort out why some users aren’t having any issues - are they all running Thunderbolts and the TB works?

I’d really like to get my repeater system back on the air.

73,
Kevin
W8KHW

··· (click for more details)

| ve7fet
January 6 |

  • | - |

Hi Chuck,

Yes, I have MPLAB running in “Windows XP Mode” (virtual machine) on my (broken) Windows 7 laptop. The nice thing about it is that it lets you map a shared folder to the host (Windows 7), so it is easy to get files in and out of the build environment.

I am wondering if you can tell me what version of the compiler (MPLAB C Compiler) you are running is (probably in Help/About in MPLAB)?

I am trying to restore my compiler environment, to confirm indeed that I was using the latest released version of the compiler (v3.31).

Lee

| W8khw1
January 6 |

  • | - |

I just finished testing with a Garmin !8 GPS. Still not setting the time correctly.

Enter Selection (1-27,97-99,r,q,d) : 98
S/W Version: 1.54 04/14/2020
System Uptime: 982.2 Secs
IP Address: 192.168.1.10
Netmask: 255.255.255.0
Gateway: 192.168.1.1
Primary DNS: 192.168.1.1
Secondary DNS: 0.0.0.0
DHCP: 1
VOTER Server IP: 0.0.0.0
VOTER Server UDP Port: 667
OUR UDP Port: 667
GPS Lock: 0
Connected: 0
COR: 1
EXT CTCSS IN: 1
PTT: 0
RSSI: 0
Current Samples / Sec.: 0
Current Peak Audio Level: 24
Squelch Noise Gain Value: 35, Diode Cal. Value: 41, SQL pot 179
Last Rx Pkt System time: , diff: 0 msec
Last Rx Pkt Timestamp time: , diff: 0 msec
Last Rx Pkt index: 0, inbounds: 0

Press The Any Key (Enter) To Continue
GPS signal lost entirely. Starting again…
GPS Receiver Active, waiting for aquisition
GPS signal acquired, number of satellites in use = 4
Time now syncronized to GPS

··· (click for more details)

Visit Topic or reply to this email to respond.

You are receiving this because you enabled mailing list mode.

To unsubscribe from these emails, click here.

22

Chuck, you’re a life saver.
This is a system with RTCMs.
I will happily test anything you want to build.
:partying_face::partying_face::partying_face:

23

Hi Chuck,
Another data point.
On my (9) RTCM’s, I’m using thunderbolts and garmin lvc 18’s.
The RTCM’s with thunderbolts had a version 1.60 which appeared to work.
Updated thunderbolt units to 1.54 with datefix=1 also appear to be ok.
The Garmin isn’t working though no matter what (tried all datafix values). (older fw versions too).
Anything else I can try? Am I missing something?
Thanks for all your rtcm support,
Dave
WB6WTM

24

I think some folks aren’t having issues mainly because they haven’t rebooted their RTCM’s. I can’t confirm this 100% as I don’t want to reboot any currently functioning RTCM’s, but I had one that was voting until I restarted it and now it won’t vote due to the time issue. I have others still properly voting, but they’ve not been restarted since prior to 1/1. I think if they restart, they will no longer vote.

Below are two different RTCM’s that are still properly voting (same node), but one is showing bad “Last Rx Pkt System time”, but current time is correct and the other is showing correct pkt and current time.

S/W Version: 1.51CHUCK 08/08/2017
System Uptime: 2884560.9 Secs
IP Address: 10.0.1.22
Netmask: 255.255.255.0
Gateway: 10.0.1.1
Primary DNS: 10.0.1.1
Secondary DNS: 8.8.8.8
DHCP: 0
VOTER Server IP: 10.0.1.10
VOTER Server UDP Port: 667
OUR UDP Port: 667
GPS Lock: 1
Connected: 1
COR: 0
EXT CTCSS IN: 1
PTT: 0
RSSI: 0
Current Samples / Sec.: 8000
Current Peak Audio Level: 57560
Squelch Noise Gain Value: 115, Diode Cal. Value: 45, SQL pot 383
Current Time: Fri Jan 08, 2021 04:06:05.700
Last Rx Pkt System time: 01/01/2021 08:00:09.120, diff: 590756600 msec
Last Rx Pkt Timestamp time: 01/01/2021 08:00:09.120, diff: 0 msec
Last Rx Pkt index: 880, inbounds: 1

S/W Version: 1.51CHUCK 08/08/2017
System Uptime: 930525.8 Secs
IP Address: 192.168.3.27
Netmask: 255.255.255.0
Gateway: 192.168.3.1
Primary DNS: 192.168.3.1
Secondary DNS: 8.8.8.8
DHCP: 0
VOTER Server IP: 192.5.222.90
VOTER Server UDP Port: 667
OUR UDP Port: 667
GPS Lock: 1
Connected: 1
COR: 0
EXT CTCSS IN: 1
PTT: 0
RSSI: 255
Current Samples / Sec.: 8001
Current Peak Audio Level: 55096
Squelch Noise Gain Value: 119, Diode Cal. Value: 45, SQL pot 385
Current Time: Fri Jan 08, 2021 04:06:04.920
Last Rx Pkt System time: 01/08/2021 04:05:33.280, diff: 31680 msec
Last Rx Pkt Timestamp time: 01/08/2021 04:05:33.280, diff: 0 msec
Last Rx Pkt index: 1080, inbounds: 1

25

Good Evening,

Thank you Chuck for the suggestions. I must confess I don’t know where to set “datefix”. I looked in the manual and searched the .conf files, but didn’t find anything.

The plus for the evening is the repeater is running - single site, no voting, but on the air. Hopefully it won’t get stuck in TX again :-).

I ran further experiments this evening. The Garmin GPS 18LVS I am using is a very old model - Pre “X”. I looked to see if they had a firmware update for the old model, but couldn’t not find one. The firmware updater for the X model returns “No update available”.

I tried looking at the GPS Lock menu item and found that strange. Even though it shows as not locked, the GPS light on the RTCM is solid yellow indicating it should be locked. I connected the Garmin GPS directly to the serial port on my laptop and captured the data. I took several samples of strings and pasted them into an online NEMA parser and they decoded correctly - date and time were correct. The parser also confirmed that the GPS was locked. So I know it’s passing data that should be readable, just not being calculated correctly in the RTCM.

I also took the RTCM to the basement and connected it to a Thunderbolt that has been running for at least the last ten years. I changed the Protocol to TSIP and confirmed the Baud rate. It reported connected, but not synced. I finally set the PPS Polarity to NONE and it started to pass data. It had the wrong date and still reported “System Time Not Set”. The GPS light on the RTCM was solid, but the firmware reported the GPS as not locked. That TBolt is definitely locked! When I reconnected it to its normal device, it reported that it was locked.

(Side Note: In the connection message sent by the RTCM, “aCquisition” is mis-spelled. And “Time is now syncHronized” - in case anybody’s bored looking through code. Thank goodness for spell check in email. :slight_smile:

Thanks again for all the help,

Kevin
W8KHW

GPS PPS set to None:
Solid Yellow light on RTCM
Even though it “syncd” the time (May 25, 2001), it still reports the “System Time Not Set”

Enter Selection (1-27,97-99,r,q,d) : GPS Receiver Active, waiting for aquisition
GPS signal acquired
05/25/2001 02:10:58.000 Time now syncronized to GPS
98
S/W Version: 1.54 04/14/2020
System Uptime: 26.6 Secs
IP Address: 192.168.1.10
Netmask: 255.255.255.0
Gateway: 192.168.1.1
Primary DNS: 192.168.1.1
Secondary DNS: 0.0.0.0
DHCP: 1
VOTER Server IP: 0.0.0.0
VOTER Server UDP Port: 667
OUR UDP Port: 667
GPS Lock: 0
Connected: 0
COR: 1
EXT CTCSS IN: 1
PTT: 0
RSSI: 0
Current Samples / Sec.: 0
Current Peak Audio Level: 32
Squelch Noise Gain Value: 35, Diode Cal. Value: 41, SQL pot 179
Current Time: Fri May 25, 2001 02:11:22.000
Last Rx Pkt System time: , diff: -1380763376 msec
Last Rx Pkt Timestamp time: , diff: 0 msec
Last Rx Pkt index: 0, inbounds: 0

···

On Thu, Jan 7, 2021 at 11:20 PM Jon Welfringer via AllStarLink Discussion Groups <noreply@community.allstarlink.org> wrote:

| WB6OZD
January 8 |

  • | - |

I think some folks aren’t having issues mainly because they haven’t rebooted their RTCM’s. I can’t confirm this 100% as I don’t want to reboot any currently functioning RTCM’s, but I had one that was voting until I restarted it and now it won’t vote due to the time issue. I have others still properly voting, but they’ve not been restarted since prior to 1/1. I think if they restart, they will no longer vote.

Below are two different RTCM’s that are still properly voting (same node), but one is showing bad “Last Rx Pkt System time”, but current time is correct and the other is showing correct pkt and current time.

S/W Version: 1.51CHUCK 08/08/2017
System Uptime: 2884560.9 Secs
IP Address: 10.0.1.22
Netmask: 255.255.255.0
Gateway: 10.0.1.1
Primary DNS: 10.0.1.1
Secondary DNS: 8.8.8.8
DHCP: 0
VOTER Server IP: 10.0.1.10
VOTER Server UDP Port: 667
OUR UDP Port: 667
GPS Lock: 1
Connected: 1
COR: 0
EXT CTCSS IN: 1
PTT: 0
RSSI: 0
Current Samples / Sec.: 8000
Current Peak Audio Level: 57560
Squelch Noise Gain Value: 115, Diode Cal. Value: 45, SQL pot 383
Current Time: Fri Jan 08, 2021 04:06:05.700
Last Rx Pkt System time: 01/01/2021 08:00:09.120, diff: 590756600 msec
Last Rx Pkt Timestamp time: 01/01/2021 08:00:09.120, diff: 0 msec
Last Rx Pkt index: 880, inbounds: 1

S/W Version: 1.51CHUCK 08/08/2017
System Uptime: 930525.8 Secs
IP Address: 192.168.3.27
Netmask: 255.255.255.0
Gateway: 192.168.3.1
Primary DNS: 192.168.3.1
Secondary DNS: 8.8.8.8
DHCP: 0
VOTER Server IP: 192.5.222.90
VOTER Server UDP Port: 667
OUR UDP Port: 667
GPS Lock: 1
Connected: 1
COR: 0
EXT CTCSS IN: 1
PTT: 0
RSSI: 255
Current Samples / Sec.: 8001
Current Peak Audio Level: 55096
Squelch Noise Gain Value: 119, Diode Cal. Value: 45, SQL pot 385
Current Time: Fri Jan 08, 2021 04:06:04.920
Last Rx Pkt System time: 01/08/2021 04:05:33.280, diff: 31680 msec
Last Rx Pkt Timestamp time: 01/08/2021 04:05:33.280, diff: 0 msec
Last Rx Pkt index: 1080, inbounds: 1

Visit Topic or reply to this email to respond.

In Reply To

| W8khw1
January 7 |

  • | - |

Hello, I have sent an email to Microchip support asking if there is an updated library to solve the mktime issue. I also sent an email to Mark at Micro Node trying to make him aware of the issue. I’m still trying to sort out why some users aren’t having any issues - are they all running Thunderbol…

Visit Topic or reply to this email to respond.

You are receiving this because you enabled mailing list mode.

To unsubscribe from these emails, click here.

26

Hi All,

To check for the problem without rebooting the RTCM, change the debug value to 32 (menu option 14). The symptom shows up as “gps_time: -1” in the GPS-DEBUG string:

GPS-DEBUG: $GPRMC,201833,A,4004.3350,N,10521.2352,W,000.0,023.1,050121,008.8,E*6C
GPS-DEBUG: mon: 0, gps_time: -1, ctime: Thu Jan 1 00:00:0/ 1970

The -1 is being returned from the mktime library call. mktime evidently has a defect. -1 reports an error.

I have written a replacement for mktime that will work thru 2099. I have it running in V1.50. It displays this debug string:

GPS-DEBUG: $GPRMC,134238,A,4004.3361,N,10521.2338,W,000.0,322.5,080121,008.8,E*6D
GPS-DEBUG: mon: 1, gps_time: 1610113358, ctime: Fri Jan 8 13:42:38 2021

We have this code running in ~10 RTCMs restoring our systems to operation.

I’d be happy to share the code.

73,

Dave
WA1JHK