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.