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