PPS Operation Will Hurt Your Brain (WAS: ppsx validation seems to be wrong) #17
Description
ppsx is supposed to show whether PPS is good (0) or bad (1). It should be initialized as 0 by default, since it is a global variable. That's probably a bad idea... since we should explicitly set it to the "bad" state, so we can make it good when PPS is valid.
It is supposed to get validated in the PPS ISR, but the logic seems flawed? There is no test/set condition if PPS Polarity is set to 2 = IGNORE for mix mode clients.
Mix mode clients don't need GPS, so what should ppsx be set to for proper operation? Suspect it should be 0.
There also seems to be a bug in the test logic in that if you have no valid GPS data (no GPS Lock), and you set PPS Polarity = 0, ppsx gets set to 0... which is good? That's not right. ppsx should not be "good" when we don't have GPS Lock, unless we're a mix mode client.
S/W Version: 3.01 12/26/2025
System Uptime: 3.7 Secs
IP Address: 172.16.16.230
Netmask: 255.255.255.0
Gateway: 172.16.16.254
Primary DNS: 172.16.16.254
Secondary DNS: 0.0.0.0
DHCP: 0
VOTER Server IP: 172.16.16.102
VOTER Server UDP Port: 1667
OUR UDP Port: 1667
GPS Lock: 0
PPS BAD or Wrong Polarity: 0
Connected: 0
COR: 0
EXT CTCSS IN: 1
PTT: 0
RSSI: 0
Current Samples / Sec.: 0
Current Peak Audio Level: 0
Squelch Noise Gain Value: 16, Diode Cal. Value: 54, SQL Level 378, Hysteresis 24
Last Ntwk Rx Pkt System time: <System Time Not Set>, diff: 0 msec
Last Ntwk Rx Pkt Timestamp time: <System Time Not Set>, diff: 0 msec
Last Ntwk Rx Pkt index: 0, inbounds: 0
May need to fix the GPS-DEBUG messages too...
Maybe we should re-name this var to something like ppsgood, and build the logic around that instead?