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

If you like you could post your RTCM code here? At least the bin so folks can get going right away.

That’s great news, Thank You!

I was surprised when searching to see that Microchip’s fix in other compilers solved the problem through 2037. I kept wondering why they would use that date or what they know about the future that I don’t.

73,
Kevin
W8KHW

···

On Jan 8, 2021, at 9:01 AM, Wa1jhk1 via AllStarLink Discussion Groups noreply@community.allstarlink.org wrote:

| Wa1jhk1
January 8 |

  • | - |

Hi All,

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

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

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

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

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

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

I’d be happy to share the code.

73,

Dave
WA1JHK


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.

Hi Kevin,

That is a much BIGGER problem… see https://en.wikipedia.org/wiki/Year_2038_problem

Lee

Great news Dave! Do you also have Chuck’s mods in this version? (e.g. Chuck Squelch and RSSI ?)

Hi Dave,

Where were you able to find the 1.60 version for the RTCM firmware?

-Jesse

Jesse,

I think the 1.60 code was a test version of what Chuck ultimately ended up calling 1.51.
It had the first fix for Trimble Thunderbolt GPSDO’s the last time the turnover broke stuff.
I probably have a copy around here somewhere but don’t think it will help.

Dave…

Dave WA1JHK,
I am interested testing your code (should you need additional testers).
Thanks,
Dave…
WB6WTM

Dave wb6wtm,

I’ve definitely tried 1.51 without any luck.
Thanks for the clarification.

-Jesse

Hi Tim,

Absolutely! I’ll post it later today.

Dave
WA1JHK

I have rebooted my voter boards and my RTCMs in the last 2 days and all are working fine with correct dates and times with the Garmin GPS lvc18 on all of them. datefix=2 ( this is found in the “offline” menu of the RTCM/voter)
The Rx Pkt time only updates if that device is set to transmit in the voter.conf file. so on receive only sites the only important time is the “current time” and it would only be valid after there is GPS lock.
After changing the datefix setting in the “offline” menu, and saving it with “99”, the device must be rebooted and resync with the GPS signals before checking the current time.
Chuck

···

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

| WB6OZD
January 8 |

  • | - |

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

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

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


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


Visit Topic or reply to this email to respond.


Previous Replies

| wb6wtm Board Member
January 8 |

  • | - |

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

| JRB
January 8 |

  • | - |

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

| Chuck_Henderson
January 8 |

  • | - |

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

··· (click for more details)

| JRB
January 7 |

  • | - |

Hey Gents,

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

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

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

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

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

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

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

| Chuck_Henderson
January 7 |

  • | - |

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

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

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

Send full output of debug 32
Chuck

··· (click for more details)


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.

There are multiple fixes in 1.54 that are not in what someone mis-labeled as 1.60. I think that the mktime in compiler v3.30 must be okay and maybe it broke in 3.31. It seems fine into 2030+ with the 3.30 version that I have. I do not have the 3.31 version.

But maybe it would be good to add the fixed mktime to the source for voter/RTCM code 1.54 so that it will work with any compiler version.

I think that I have figured out a fix for the Trimble Thunderbolt-E with TSIP protocol that JRB is using. If it works then I plan to call it 1.55. and it will have a new DateFix 4 for Trimble.

I checked all of the versions I have, 1.50, 1.51, 1.52, 1.53, and 1.54, and none of them have mis-spellings like “aCquisition” or "syncHronized” so I suspect that those must have resulted from damaged files or transfer errors while updating firmware. Can anyone find those in the voter.c source on Github? Those errors are not in the voter.c files on my hard drive that were sent to Github by me.
Chuck

···

On Fri, Jan 8, 2021 at 12:32 PM Dave Shaw via AllStarLink Discussion Groups <noreply@community.allstarlink.org> wrote:

| wb6wtm Board Member
January 8 |

  • | - |

Jesse,

I think the 1.60 code was a test version of what Chuck ultimately ended up calling 1.51.
It had the first fix for Trimble Thunderbolt GPSDO’s the last time the turnover broke stuff.
I probably have a copy around here somewhere but don’t think it will help.

Dave…


Visit Topic or reply to this email to respond.


Previous Replies

| JRB
January 8 |

  • | - |

Hi Dave,

Where were you able to find the 1.60 version for the RTCM firmware?

-Jesse

| WB6OZD
January 8 |

  • | - |

Great news Dave! Do you also have Chuck’s mods in this version? (e.g. Chuck Squelch and RSSI ?)

| ve7fet
January 8 |

  • | - |

Hi Kevin,

That is a much BIGGER problem… see https://en.wikipedia.org/wiki/Year_2038_problem

Lee

| W8khw1
January 8 |

  • | - |

That’s great news, Thank You!

I was surprised when searching to see that Microchip’s fix in other compilers solved the problem through 2037. I kept wondering why they would use that date or what they know about the future that I don’t.

73,
Kevin
W8KHW

··· (click for more details)

| wd6awp ASL Admin
January 8 |

  • | - |

If you like you could post your RTCM code here? At least the bin so folks can get going right away.


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.

Dave,

I’ve it’s not too difficult, please post both RTCM (SMT) and voter board (thru hole) versions.

Thanks,
Greg
WB6ZSU

1 Like

We have completed our testing of the time fix on 16 RTCMs here in Colorado. All are operating as expected.

At the following link:

are three files:

Voter-smt_1_50_CHUCK_WA1JHK.cry
Voter_1_50_CHUCK_WA1JHK.cry
Voter_1_50_WA1JHK.c

There’s both an SMT version and a thru-hole board version. These builds include Chuck’s changes to Squelch and RSSI operation. And the updated voter.c file is there for reference and other builds.

Note that the thru-hole version has not yet been tested. I don’t have that hardware here to do that.

Give it a try and let us know how it is working for you.

73,

Dave


Dave Maciorowski, WA1JHK

Dave,

I only see the .c file and the smt.cry files. I don’t see a file for the non-smt version.

Greg
WB6ZSU

Hi Greg,

Thanks for letting me know. Fixed.

73,

Dave


Dave Maciorowski, WA1JHK

Dave,

Thanks! I just loaded this on two thru-hole boards (voter boards). The date and time is now correct.

73,
Greg
WB6ZSU

Greetings,

I can report that your firmware is initially working correctly with the QRP Labs GPS modules in TTL mode. Thank you for your hard work and posting your solution.

73 and have a Great Weekend!

Kevin
W8KHW

···

On Jan 9, 2021, at 4:35 PM, Wa1jhk1 via AllStarLink Discussion Groups noreply@community.allstarlink.org wrote:

| Wa1jhk1
January 9 |

  • | - |

We have completed our testing of the time fix on 16 RTCMs here in Colorado. All are operating as expected.

At the following link:

Dropbox
### RTCMFWShare

Shared with Dropbox

are three files:

Voter-smt_1_50_CHUCK_WA1JHK.cry
Voter_1_50_CHUCK_WA1JHK.cry
Voter_1_50_WA1JHK.c

There’s both an SMT version and a thru-hole board version. These builds include Chuck’s changes to Squelch and RSSI operation. And the updated voter.c file is there for reference and other builds.

Note that the thru-hole version has not yet been tested. I don’t have that hardware here to do that.

Give it a try and let us know how it is working for you.

73,

Dave


Dave Maciorowski, WA1JHK


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.

Thanks for posting these Dave. Looks like mine are all functioning properly now.

@Chuck_Henderson Could you build a 1.54 SMT BEW CHUCK? The diagnostics have to be removed to fit BEW but I need BEW for the Quantars.

Edit: Sorry, turns out 1.54 is not working for me. I did try all 3 (0, 1 & 2) datefix settings.

@Wa1jhk1 Looks like @Chuck_Henderson 1.54 version is not working for me but your 1.50 is. Could you make a SMT BEW CHUCK? You probably saw that I mentioned to Chuck the BEW is for the Quantars and the diagnostics must be removed to make room.