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

App_rpt-users
1

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

2

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> wrote:

| 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.

3

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.

4

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.

···

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

| 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 or reply to this email to respond.

Previous Replies

| 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.

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

6

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 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.

In Reply To

| 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 fo…

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.

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