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

App_rpt-users
#19

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

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

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

Send full output of debug 32
Chuck

···

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

W8khw1
January 6

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

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

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

··· (click for more details)

Visit Topic or reply to this email to respond.

Previous Replies

Gregn1
January 6

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

Greg
WB6ZSU

WB6OZD
January 5

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

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

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

W8khw1
January 5

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

Kevin, W8KHW

My Status output:

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

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

··· (click for more details)

Chuck_Henderson
January 5

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

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

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

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

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

··· (click for more details)

WB6OZD
January 5

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

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

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

Visit Topic or reply to this email to respond.

You are receiving this because you enabled mailing list mode.

To unsubscribe from these emails, click here.

#20

Hey Gents,

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

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

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

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

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

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

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

GPS debug

#21

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

···

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

JRB
January 7

Hey Gents,

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

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

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

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

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

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

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

Visit Topic or reply to this email to respond.

Previous Replies

Chuck_Henderson
January 7

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

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

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

Send full output of debug 32
Chuck

··· (click for more details)

Chuck_Henderson
January 7

v3.30
Chuck

··· (click for more details)

W8khw1
January 7

Hello,

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

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

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

73,
Kevin
W8KHW

··· (click for more details)

ve7fet
January 6

Hi Chuck,

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

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

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

Lee

W8khw1
January 6

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

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

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

··· (click for more details)

Visit Topic or reply to this email to respond.

You are receiving this because you enabled mailing list mode.

To unsubscribe from these emails, click here.

#22

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

#23

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

#24

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

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

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

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

#25

Good Evening,

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

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

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

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

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

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

Thanks again for all the help,

Kevin
W8KHW

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

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

···

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

WB6OZD
January 8

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

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

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

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

Visit Topic or reply to this email to respond.

In Reply To

W8khw1
January 7

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

Visit Topic or reply to this email to respond.

You are receiving this because you enabled mailing list mode.

To unsubscribe from these emails, click here.

#26

Hi All,

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

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

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

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

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

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

I’d be happy to share the code.

73,

Dave
WA1JHK

#27

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

#28

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.

#29

Hi Kevin,

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

Lee

#30

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

#31

Hi Dave,

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

-Jesse

#32

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…

#33

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

#34

Dave wb6wtm,

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

-Jesse

#35

Hi Tim,

Absolutely! I’ll post it later today.

Dave
WA1JHK

#36

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.

#37

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.

#38

Dave,

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

Thanks,
Greg
WB6ZSU

1 Like