# Your VOTER/RTCM May Have Broken Itself on 01/01/21 00:01 **URL:** \ **Category:** AllStarLink\ **Created:** [January 4, 2021, 6:44am UTC](https://community.allstarlink.org/t/your-voter-rtcm-may-have-broken-itself-on-01-01-21-00-01/18031 "2021-01-04T06:44:47Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![VE7FET](https://community.allstarlink.org/user_avatar/community.allstarlink.org/ve7fet/32/1267_2.png) [@VE7FET](https://community.allstarlink.org/u/VE7FET)\ **Post date:** [January 4, 2021, 6:44am UTC](https://community.allstarlink.org/t/your-voter-rtcm-may-have-broken-itself-on-01-01-21-00-01/18031/1 "2021-01-04T06:44:47Z")
Well, I found this (by accident) about a month ago, which scared the hell out of me: [https://www.microchip.com/forums/m653169.aspx](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 ---
**Author:** ![W8khw1](https://community.allstarlink.org/letter_avatar_proxy/v4/letter/w/b9bd4f/32.png) [@W8khw1](https://community.allstarlink.org/u/W8khw1)\ **Post date:** [January 4, 2021, 7:04am UTC](https://community.allstarlink.org/t/your-voter-rtcm-may-have-broken-itself-on-01-01-21-00-01/18031/2 "2021-01-04T07:04:50Z")
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 > **···** > > On Mon, Jan 4, 2021 at 1:54 AM Lee via AllStarLink Discussion Groups \<[noreply@community.allstarlink.org](mailto:noreply@community.allstarlink.org)\> wrote: > > > > ![](https://community.allstarlink.org/user_avatar/community.allstarlink.org/ve7fet/45/1267_2.png "ve7fet") | [ve7fet](https://community.allstarlink.org/u/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](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](https://community.allstarlink.org/t/your-voter-rtcm-may-have-broken-itself-on-01-01-21-00-01/18031/1) or reply to this email to respond. > > > > You are receiving this because you enabled mailing list mode. > > > > To unsubscribe from these emails, [click here](https://community.allstarlink.org/email/unsubscribe/7e90c7bca45b958ac5507d41c092959e81edfc09da0e9a3540c9b5b826f5d7ab). ---
**Author:** ![WB6OZD](https://community.allstarlink.org/letter_avatar_proxy/v4/letter/w/977dab/32.png) [@WB6OZD](https://community.allstarlink.org/u/WB6OZD)\ **Post date:** [January 5, 2021, 6:12pm UTC](https://community.allstarlink.org/t/your-voter-rtcm-may-have-broken-itself-on-01-01-21-00-01/18031/3 "2021-01-05T18:12:47Z")
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. ---
**Author:** ![Chuck\_Henderson](https://community.allstarlink.org/letter_avatar_proxy/v4/letter/c/ba9def/32.png) [@Chuck\_Henderson](https://community.allstarlink.org/u/Chuck_Henderson)\ **Post date:** [January 5, 2021, 7:22pm UTC](https://community.allstarlink.org/t/your-voter-rtcm-may-have-broken-itself-on-01-01-21-00-01/18031/4 "2021-01-05T19:22:31Z")
You need “S/W Version: 1.54 04/14/2020” the source can be found at [https://github.com/ccie2285/voter](https://github.com/ccie2285/voter) or at [https://github.com/AllStarLink/voter/tree/testing](https://github.com/AllStarLink/voter/tree/testing) or at [https://github.com/pttlink/voter/tree/testing](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. > **···** > > On Tue, Jan 5, 2021 at 12:22 PM Jon Welfringer via AllStarLink Discussion Groups \<[noreply@community.allstarlink.org](mailto:noreply@community.allstarlink.org)\> wrote: > > > > ![](https://community.allstarlink.org/letter_avatar_proxy/v4/letter/w/977dab/45.png "WB6OZD") | [WB6OZD](https://community.allstarlink.org/u/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. > > > > * * * > > > > [Visit Topic](https://community.allstarlink.org/t/your-voter-rtcm-may-have-broken-itself-on-01-01-21-00-01/18031/3) or reply to this email to respond. > > > > * * * > > > > #### Previous Replies > > > > > ![](https://community.allstarlink.org/letter_avatar_proxy/v4/letter/w/b9bd4f/45.png "W8khw1") | [W8khw1](https://community.allstarlink.org/u/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)](https://community.allstarlink.org/t/your-voter-rtcm-may-have-broken-itself-on-01-01-21-00-01/18031/2) > > > > > ![](https://community.allstarlink.org/user_avatar/community.allstarlink.org/ve7fet/45/1267_2.png "ve7fet") | [ve7fet](https://community.allstarlink.org/u/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](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](https://community.allstarlink.org/t/your-voter-rtcm-may-have-broken-itself-on-01-01-21-00-01/18031/3) or reply to this email to respond. > > > > You are receiving this because you enabled mailing list mode. > > > > To unsubscribe from these emails, [click here](https://community.allstarlink.org/email/unsubscribe/408811202590d966a8b85f1d96b6b8269593707dd1a60b7e096f6c78011de3a0). ---
**Author:** ![VE7FET](https://community.allstarlink.org/user_avatar/community.allstarlink.org/ve7fet/32/1267_2.png) [@VE7FET](https://community.allstarlink.org/u/VE7FET)\ **Post date:** [January 5, 2021, 7:40pm UTC](https://community.allstarlink.org/t/your-voter-rtcm-may-have-broken-itself-on-01-01-21-00-01/18031/5 "2021-01-05T19:40:36Z")
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 ---
**Author:** ![W8khw1](https://community.allstarlink.org/letter_avatar_proxy/v4/letter/w/b9bd4f/32.png) [@W8khw1](https://community.allstarlink.org/u/W8khw1)\ **Post date:** [January 5, 2021, 8:16pm UTC](https://community.allstarlink.org/t/your-voter-rtcm-may-have-broken-itself-on-01-01-21-00-01/18031/6 "2021-01-05T20:16:44Z")
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 > **···** > > > On Jan 5, 2021, at 2:50 PM, Lee via AllStarLink Discussion Groups [noreply@community.allstarlink.org](mailto:noreply@community.allstarlink.org) wrote: > > > > ![](https://community.allstarlink.org/user_avatar/community.allstarlink.org/ve7fet/45/1267_2.png "ve7fet") | [ve7fet](https://community.allstarlink.org/u/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](https://community.allstarlink.org/t/your-voter-rtcm-may-have-broken-itself-on-01-01-21-00-01/18031/5) or reply to this email to respond. > > > > * * * > > > > #### In Reply To > > > > > ![](https://community.allstarlink.org/letter_avatar_proxy/v4/letter/c/ba9def/45.png "Chuck\_Henderson") | [Chuck\_Henderson](https://community.allstarlink.org/u/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](https://github.com/ccie2285/voter) or at [https://github.com/AllStarLink/voter/tree/testing](https://github.com/AllStarLink/voter/tree/testing) or at [https://github.com/pttlink/voter/tree/testing](https://github.com/pttlink/voter/tree/testing) This 1.54 has multiple fixes for different GPS versions and can accept different values fo… > > > > * * * > > > > [Visit Topic](https://community.allstarlink.org/t/your-voter-rtcm-may-have-broken-itself-on-01-01-21-00-01/18031/5) or reply to this email to respond. > > > > You are receiving this because you enabled mailing list mode. > > > > To unsubscribe from these emails, [click here](https://community.allstarlink.org/email/unsubscribe/1acc5bc61a0c33270b1a3b34837170b4e565f204341be825d97cbeb7dd51b9c9). ---
**Author:** ![Chuck\_Henderson](https://community.allstarlink.org/letter_avatar_proxy/v4/letter/c/ba9def/32.png) [@Chuck\_Henderson](https://community.allstarlink.org/u/Chuck_Henderson)\ **Post date:** [January 5, 2021, 8:21pm UTC](https://community.allstarlink.org/t/your-voter-rtcm-may-have-broken-itself-on-01-01-21-00-01/18031/7 "2021-01-05T20:21:30Z")
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.3_33 GPS-DEBUG: $GPGSV,3,1,11,03,28,221,34,04,78,296,42,07,12,277,33,08,07,175,24_78 GPS-DEBUG: $GPGSV,3,2,11,09,37,311,43,16,80,081,40,22,14,203,34,26,46,051,35_74 GPS-DEBUG: $GPGSV,3,3,11,27,27,145,38,29,02,027,25,31,16,082,29_4D GPS-DEBUG: $GPRMC,201339,A,4030.0246,N,08855.9307,W,000.0,343.0,220501,002.3,W_77 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.3_33 GPS-DEBUG: $GPGSV,3,1,11,03,28,221,34,04,78,296,42,07,12,277,33,08,07,175,24_78 GPS-DEBUG: $GPGSV,3,2,11,09,37,311,43,16,80,081,40,22,14,203,34,26,46,051,35_74 GPS-DEBUG: $GPGSV,3,3,11,27,27,145,38,29,02,027,25,31,16,082,29_4D GPS-DEBUG: $GPRMC,201340,A,4030.0246,N,08855.9307,W,000.0,343.0,220501,002.3,W_79 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](mailto:noreply@community.allstarlink.org)\> wrote: > > > > ![](https://community.allstarlink.org/user_avatar/community.allstarlink.org/ve7fet/45/1267_2.png "ve7fet") | [ve7fet](https://community.allstarlink.org/u/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](https://community.allstarlink.org/t/your-voter-rtcm-may-have-broken-itself-on-01-01-21-00-01/18031/5) or reply to this email to respond. > > > > * * * > > > > #### Previous Replies > > > > > ![](https://community.allstarlink.org/letter_avatar_proxy/v4/letter/c/ba9def/45.png "Chuck\_Henderson") | [Chuck\_Henderson](https://community.allstarlink.org/u/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](https://github.com/ccie2285/voter) or at [https://github.com/AllStarLink/voter/tree/testing](https://github.com/AllStarLink/voter/tree/testing) or at [https://github.com/pttlink/voter/tree/testing](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)](https://community.allstarlink.org/t/your-voter-rtcm-may-have-broken-itself-on-01-01-21-00-01/18031/4) > > > > > ![](https://community.allstarlink.org/letter_avatar_proxy/v4/letter/w/977dab/45.png "WB6OZD") | [WB6OZD](https://community.allstarlink.org/u/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. > > > > > ![](https://community.allstarlink.org/letter_avatar_proxy/v4/letter/w/b9bd4f/45.png "W8khw1") | [W8khw1](https://community.allstarlink.org/u/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)](https://community.allstarlink.org/t/your-voter-rtcm-may-have-broken-itself-on-01-01-21-00-01/18031/2) > > > > > ![](https://community.allstarlink.org/user_avatar/community.allstarlink.org/ve7fet/45/1267_2.png "ve7fet") | [ve7fet](https://community.allstarlink.org/u/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](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](https://community.allstarlink.org/t/your-voter-rtcm-may-have-broken-itself-on-01-01-21-00-01/18031/5) or reply to this email to respond. > > > > You are receiving this because you enabled mailing list mode. > > > > To unsubscribe from these emails, [click here](https://community.allstarlink.org/email/unsubscribe/5e52dfad35afde0336df130c7941a24c0907b2362cd190b6fcc40f139eef1110). ---
**Author:** ![VE7FET](https://community.allstarlink.org/user_avatar/community.allstarlink.org/ve7fet/32/1267_2.png) [@VE7FET](https://community.allstarlink.org/u/VE7FET)\ **Post date:** [January 5, 2021, 8:43pm UTC](https://community.allstarlink.org/t/your-voter-rtcm-may-have-broken-itself-on-01-01-21-00-01/18031/8 "2021-01-05T20:43:07Z")
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 ---
**Author:** ![VE7FET](https://community.allstarlink.org/user_avatar/community.allstarlink.org/ve7fet/32/1267_2.png) [@VE7FET](https://community.allstarlink.org/u/VE7FET)\ **Post date:** [January 5, 2021, 8:48pm UTC](https://community.allstarlink.org/t/your-voter-rtcm-may-have-broken-itself-on-01-01-21-00-01/18031/9 "2021-01-05T20:48:49Z")
Hi Kevin, Yeah, tried compiling it with the legacy libs, and that breaks other stuff. 🙂 Lee ---
**Author:** ![WB6OZD](https://community.allstarlink.org/letter_avatar_proxy/v4/letter/w/977dab/32.png) [@WB6OZD](https://community.allstarlink.org/u/WB6OZD)\ **Post date:** [January 5, 2021, 9:04pm UTC](https://community.allstarlink.org/t/your-voter-rtcm-may-have-broken-itself-on-01-01-21-00-01/18031/10 "2021-01-05T21:04:03Z")
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. ---
**Author:** ![Chuck\_Henderson](https://community.allstarlink.org/letter_avatar_proxy/v4/letter/c/ba9def/32.png) [@Chuck\_Henderson](https://community.allstarlink.org/u/Chuck_Henderson)\ **Post date:** [January 5, 2021, 9:49pm UTC](https://community.allstarlink.org/t/your-voter-rtcm-may-have-broken-itself-on-01-01-21-00-01/18031/11 "2021-01-05T21:49:11Z")
I just now uploaded the 2 binary files that I use here. [https://github.com/ccie2285/voter/tree/master/board-firmware](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](mailto:noreply@community.allstarlink.org)\> wrote: > > > > ![](https://community.allstarlink.org/letter_avatar_proxy/v4/letter/w/977dab/45.png "WB6OZD") | [WB6OZD](https://community.allstarlink.org/u/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](https://community.allstarlink.org/t/your-voter-rtcm-may-have-broken-itself-on-01-01-21-00-01/18031/10) or reply to this email to respond. > > > > * * * > > > > #### Previous Replies > > > > > ![](https://community.allstarlink.org/user_avatar/community.allstarlink.org/ve7fet/45/1267_2.png "ve7fet") | [ve7fet](https://community.allstarlink.org/u/ve7fet) > > > January 5 | > > > > > > - | - | > > > > Hi Kevin, > > > > Yeah, tried compiling it with the legacy libs, and that breaks other stuff. ![:slight_smile:](https://community.allstarlink.org/images/emoji/fluentui/slight_smile.png?v=9 ":slight\_smile:") > > > > Lee > > > > > ![](https://community.allstarlink.org/user_avatar/community.allstarlink.org/ve7fet/45/1267_2.png "ve7fet") | [ve7fet](https://community.allstarlink.org/u/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 > > > > > ![](https://community.allstarlink.org/letter_avatar_proxy/v4/letter/c/ba9def/45.png "Chuck\_Henderson") | [Chuck\_Henderson](https://community.allstarlink.org/u/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.3_33 > > GPS-DEBUG: $GPGSV,3,1,11,03,28,221,34,04,78,296,42,07,12,277,33,08,07,175,24_78_ > > _GPS-DEBUG: $GPGSV,3,2,11,09,37,311,43,16,80,081,40,22,14,203,34,26,46,051,35_74 > > GPS-DEBUG: $GPGSV,3,3,11,27,27,145,38,29,02,027,25,31,16,082,29_4D_ > > _GPS-DEBUG: $GPRMC,201339,A,4030.0246,N,08855.9307,W,000.0,343.0,220501,002.3,W_77 > > 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.3_33 > > GPS-DEBUG: $GPGSV,3,1,11,03,28,221,34,04,78,296,42,07,12,277,33,08,07,175,24_78_ > > _GPS-DEBUG: $GPGSV,3,2,11,09,37,311,43,16,80,081,40,22,14,203,34,26,46,051,35_74 > > GPS-DEBUG: $GPGSV,3,3,11,27,27,145,38,29,02,027,25,31,16,082,29_4D_ > > _GPS-DEBUG: $GPRMC,201340,A,4030.0246,N,08855.9307,W,000.0,343.0,220501,002.3,W_79 > > 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)](https://community.allstarlink.org/t/your-voter-rtcm-may-have-broken-itself-on-01-01-21-00-01/18031/7) > > > > > ![](https://community.allstarlink.org/letter_avatar_proxy/v4/letter/w/b9bd4f/45.png "W8khw1") | [W8khw1](https://community.allstarlink.org/u/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)](https://community.allstarlink.org/t/your-voter-rtcm-may-have-broken-itself-on-01-01-21-00-01/18031/6) > > > > > ![](https://community.allstarlink.org/user_avatar/community.allstarlink.org/ve7fet/45/1267_2.png "ve7fet") | [ve7fet](https://community.allstarlink.org/u/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](https://community.allstarlink.org/t/your-voter-rtcm-may-have-broken-itself-on-01-01-21-00-01/18031/10) or reply to this email to respond. > > > > You are receiving this because you enabled mailing list mode. > > > > To unsubscribe from these emails, [click here](https://community.allstarlink.org/email/unsubscribe/bd94eff45caa9dd4a925a5433955b3dc36bd412419a71f03c279e7338c04be07). ---
**Author:** ![W8khw1](https://community.allstarlink.org/letter_avatar_proxy/v4/letter/w/b9bd4f/32.png) [@W8khw1](https://community.allstarlink.org/u/W8khw1)\ **Post date:** [January 5, 2021, 11:00pm UTC](https://community.allstarlink.org/t/your-voter-rtcm-may-have-broken-itself-on-01-01-21-00-01/18031/12 "2021-01-05T23:00:15Z")
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](mailto:noreply@community.allstarlink.org)\> wrote: > > > > ![](https://community.allstarlink.org/letter_avatar_proxy/v4/letter/c/ba9def/45.png "Chuck\_Henderson") | [Chuck\_Henderson](https://community.allstarlink.org/u/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](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)](https://community.allstarlink.org/t/your-voter-rtcm-may-have-broken-itself-on-01-01-21-00-01/18031/11) > > > > * * * > > > > [Visit Topic](https://community.allstarlink.org/t/your-voter-rtcm-may-have-broken-itself-on-01-01-21-00-01/18031/11) or reply to this email to respond. > > > > * * * > > > > #### In Reply To > > > > > ![](https://community.allstarlink.org/letter_avatar_proxy/v4/letter/w/977dab/45.png "WB6OZD") | [WB6OZD](https://community.allstarlink.org/u/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](https://community.allstarlink.org/t/your-voter-rtcm-may-have-broken-itself-on-01-01-21-00-01/18031/11) or reply to this email to respond. > > > > You are receiving this because you enabled mailing list mode. > > > > To unsubscribe from these emails, [click here](https://community.allstarlink.org/email/unsubscribe/f632ad5dc8642ef71bb4c33f7a9d40cda8accdc773db8845c4a7fe8b56173037). ---
**Author:** ![WB6OZD](https://community.allstarlink.org/letter_avatar_proxy/v4/letter/w/977dab/32.png) [@WB6OZD](https://community.allstarlink.org/u/WB6OZD)\ **Post date:** [January 5, 2021, 11:52pm UTC](https://community.allstarlink.org/t/your-voter-rtcm-may-have-broken-itself-on-01-01-21-00-01/18031/13 "2021-01-05T23:52:47Z")
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 ---
**Author:** ![Gregn1](https://community.allstarlink.org/letter_avatar_proxy/v4/letter/g/9de0a6/32.png) [@Gregn1](https://community.allstarlink.org/u/Gregn1)\ **Post date:** [January 6, 2021, 12:25am UTC](https://community.allstarlink.org/t/your-voter-rtcm-may-have-broken-itself-on-01-01-21-00-01/18031/14 "2021-01-06T00:25:39Z")
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 ---
**Author:** ![W8khw1](https://community.allstarlink.org/letter_avatar_proxy/v4/letter/w/b9bd4f/32.png) [@W8khw1](https://community.allstarlink.org/u/W8khw1)\ **Post date:** [January 6, 2021, 12:42am UTC](https://community.allstarlink.org/t/your-voter-rtcm-may-have-broken-itself-on-01-01-21-00-01/18031/15 "2021-01-06T00:42:02Z")
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](mailto:noreply@community.allstarlink.org)\> wrote: > > > > ![](https://community.allstarlink.org/letter_avatar_proxy/v4/letter/w/977dab/45.png "WB6OZD") | [WB6OZD](https://community.allstarlink.org/u/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](https://community.allstarlink.org/t/your-voter-rtcm-may-have-broken-itself-on-01-01-21-00-01/18031/13) or reply to this email to respond. > > > > You are receiving this because you enabled mailing list mode. > > > > To unsubscribe from these emails, [click here](https://community.allstarlink.org/email/unsubscribe/22b7db4bb5258abc74654a6df66d982de748757638c5af9aa1a12f1666fd36fd). ---
**Author:** ![VE7FET](https://community.allstarlink.org/user_avatar/community.allstarlink.org/ve7fet/32/1267_2.png) [@VE7FET](https://community.allstarlink.org/u/VE7FET)\ **Post date:** [January 6, 2021, 2:19am UTC](https://community.allstarlink.org/t/your-voter-rtcm-may-have-broken-itself-on-01-01-21-00-01/18031/16 "2021-01-06T02:19:50Z")
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 ---
**Author:** ![W8khw1](https://community.allstarlink.org/letter_avatar_proxy/v4/letter/w/b9bd4f/32.png) [@W8khw1](https://community.allstarlink.org/u/W8khw1)\ **Post date:** [January 7, 2021, 9:03pm UTC](https://community.allstarlink.org/t/your-voter-rtcm-may-have-broken-itself-on-01-01-21-00-01/18031/17 "2021-01-07T21:03:57Z")
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](mailto:noreply@community.allstarlink.org) wrote: > > > > ![](https://community.allstarlink.org/user_avatar/community.allstarlink.org/ve7fet/45/1267_2.png "ve7fet") | [ve7fet](https://community.allstarlink.org/u/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](https://community.allstarlink.org/t/your-voter-rtcm-may-have-broken-itself-on-01-01-21-00-01/18031/16) or reply to this email to respond. > > > > * * * > > > > #### In Reply To > > > > > ![](https://community.allstarlink.org/letter_avatar_proxy/v4/letter/c/ba9def/45.png "Chuck\_Henderson") | [Chuck\_Henderson](https://community.allstarlink.org/u/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](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](https://community.allstarlink.org/t/your-voter-rtcm-may-have-broken-itself-on-01-01-21-00-01/18031/16) or reply to this email to respond. > > > > You are receiving this because you enabled mailing list mode. > > > > To unsubscribe from these emails, [click here](https://community.allstarlink.org/email/unsubscribe/411b5644c2354dbc5da015fd6880ebba2286f0d2b5d1a2901f44746e4be54b6e). ---
**Author:** ![Chuck\_Henderson](https://community.allstarlink.org/letter_avatar_proxy/v4/letter/c/ba9def/32.png) [@Chuck\_Henderson](https://community.allstarlink.org/u/Chuck_Henderson)\ **Post date:** [January 7, 2021, 10:03pm UTC](https://community.allstarlink.org/t/your-voter-rtcm-may-have-broken-itself-on-01-01-21-00-01/18031/18 "2021-01-07T22:03:51Z")
v3.30 Chuck > **···** > > On Tue, Jan 5, 2021 at 8:29 PM Lee via AllStarLink Discussion Groups \<[noreply@community.allstarlink.org](mailto:noreply@community.allstarlink.org)\> wrote: > > > > ![](https://community.allstarlink.org/user_avatar/community.allstarlink.org/ve7fet/45/1267_2.png "ve7fet") | [ve7fet](https://community.allstarlink.org/u/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](https://community.allstarlink.org/t/your-voter-rtcm-may-have-broken-itself-on-01-01-21-00-01/18031/16) or reply to this email to respond. > > > > * * * > > > > #### Previous Replies > > > > > ![](https://community.allstarlink.org/letter_avatar_proxy/v4/letter/w/b9bd4f/45.png "W8khw1") | [W8khw1](https://community.allstarlink.org/u/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)](https://community.allstarlink.org/t/your-voter-rtcm-may-have-broken-itself-on-01-01-21-00-01/18031/15) > > > > > ![](https://community.allstarlink.org/letter_avatar_proxy/v4/letter/g/9de0a6/45.png "Gregn1") | [Gregn1](https://community.allstarlink.org/u/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 > > > > > ![](https://community.allstarlink.org/letter_avatar_proxy/v4/letter/w/977dab/45.png "WB6OZD") | [WB6OZD](https://community.allstarlink.org/u/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 > > > > > ![](https://community.allstarlink.org/letter_avatar_proxy/v4/letter/w/b9bd4f/45.png "W8khw1") | [W8khw1](https://community.allstarlink.org/u/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)](https://community.allstarlink.org/t/your-voter-rtcm-may-have-broken-itself-on-01-01-21-00-01/18031/12) > > > > > ![](https://community.allstarlink.org/letter_avatar_proxy/v4/letter/c/ba9def/45.png "Chuck\_Henderson") | [Chuck\_Henderson](https://community.allstarlink.org/u/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](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)](https://community.allstarlink.org/t/your-voter-rtcm-may-have-broken-itself-on-01-01-21-00-01/18031/11) > > > > * * * > > > > [Visit Topic](https://community.allstarlink.org/t/your-voter-rtcm-may-have-broken-itself-on-01-01-21-00-01/18031/16) or reply to this email to respond. > > > > You are receiving this because you enabled mailing list mode. > > > > To unsubscribe from these emails, [click here](https://community.allstarlink.org/email/unsubscribe/88135e57e99663e07acb95fda47e772dde49a7e138908107d5be45b226c9deef). ---
**Author:** ![Chuck\_Henderson](https://community.allstarlink.org/letter_avatar_proxy/v4/letter/c/ba9def/32.png) [@Chuck\_Henderson](https://community.allstarlink.org/u/Chuck_Henderson)\ **Post date:** [January 7, 2021, 10:14pm UTC](https://community.allstarlink.org/t/your-voter-rtcm-may-have-broken-itself-on-01-01-21-00-01/18031/19 "2021-01-07T22:14:49Z")
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](mailto:noreply@community.allstarlink.org)\> wrote: > > > > ![](https://community.allstarlink.org/letter_avatar_proxy/v4/letter/w/b9bd4f/45.png "W8khw1") | [W8khw1](https://community.allstarlink.org/u/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)](https://community.allstarlink.org/t/your-voter-rtcm-may-have-broken-itself-on-01-01-21-00-01/18031/15) > > > > * * * > > > > [Visit Topic](https://community.allstarlink.org/t/your-voter-rtcm-may-have-broken-itself-on-01-01-21-00-01/18031/15) or reply to this email to respond. > > > > * * * > > > > #### Previous Replies > > > > > ![](https://community.allstarlink.org/letter_avatar_proxy/v4/letter/g/9de0a6/45.png "Gregn1") | [Gregn1](https://community.allstarlink.org/u/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 > > > > > ![](https://community.allstarlink.org/letter_avatar_proxy/v4/letter/w/977dab/45.png "WB6OZD") | [WB6OZD](https://community.allstarlink.org/u/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 > > > > > ![](https://community.allstarlink.org/letter_avatar_proxy/v4/letter/w/b9bd4f/45.png "W8khw1") | [W8khw1](https://community.allstarlink.org/u/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)](https://community.allstarlink.org/t/your-voter-rtcm-may-have-broken-itself-on-01-01-21-00-01/18031/12) > > > > > ![](https://community.allstarlink.org/letter_avatar_proxy/v4/letter/c/ba9def/45.png "Chuck\_Henderson") | [Chuck\_Henderson](https://community.allstarlink.org/u/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](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)](https://community.allstarlink.org/t/your-voter-rtcm-may-have-broken-itself-on-01-01-21-00-01/18031/11) > > > > > ![](https://community.allstarlink.org/letter_avatar_proxy/v4/letter/w/977dab/45.png "WB6OZD") | [WB6OZD](https://community.allstarlink.org/u/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](https://community.allstarlink.org/t/your-voter-rtcm-may-have-broken-itself-on-01-01-21-00-01/18031/15) or reply to this email to respond. > > > > You are receiving this because you enabled mailing list mode. > > > > To unsubscribe from these emails, [click here](https://community.allstarlink.org/email/unsubscribe/d897a71cb4ac5dc507897d2e4137fea104e672deb54983f3992b125ffc918eec). ---
**Author:** ![JRB](https://community.allstarlink.org/letter_avatar_proxy/v4/letter/j/4da419/32.png) [@JRB](https://community.allstarlink.org/u/JRB)\ **Post date:** [January 7, 2021, 11:28pm UTC](https://community.allstarlink.org/t/your-voter-rtcm-may-have-broken-itself-on-01-01-21-00-01/18031/20 "2021-01-07T23:28:38Z")
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](https://community.allstarlink.org/uploads/default/original/2X/5/554909dc301aa46c985f829e971f11abd4c27409.png) [Next page](https://community.allstarlink.org/t/your-voter-rtcm-may-have-broken-itself-on-01-01-21-00-01/18031.md?page=2)