SG-2340/MBT-4220 GPS-Lure Stratum-1 NTP clock under pfSense?
-
Nice. What sort of jitter, offset etc do you see without the PPS signal?
Steve
-
@stephenw10 said in SG-2340/MBT-4220 GPS-Lure Stratum-1 NTP clock under pfSense?:
Nice. What sort of jitter, offset etc do you see without the PPS signal?
Reported jitter is itself jittery: have seen it as low as 6-ish and as high as 235-ish. So it's all over the place.
So on the low side: fine, on the high side: not ideal.
I wonder if raising the baud rate and reporting frequency would help. I think the module is capable of 5Hz or even 10Hz up reporting, with the proper settings and baudrate.
That would require some further tweaking of the init commands.
-
Mmm, yeah that's not great. With the PPS signal the jitter can be waay below 1ms. I think johnpoz was seeing ~10μs on his RasPi setup. Something must be done!
Steve
-
The idea to increase the update frequency may be foiled:
for a higher update frequency (like 5 or 10Hz), it requires a correspondingly higher baud rate.
The problem is, the firmware of the module specifies what default baud rate the module has, and I think these are programmed with 9600 baud.
It is possible increase both update rate and baud rate with corresponding commands, the problem is, pfSense doesn't have a pre and post configuration baud rate.
So if I indicate a higher baud rate in pfSense, then it won't be able to talk to the module to set the baud rate to the higher rate, and if I set 9600, and then tell the GPS module to go faster pfSense is stuck at the lower rate, as there's no "auto" setting.So either pfSense would need to have an auto-baud setting, so it could sync up at 9600, send over the new config, and then resync at 38400 or 115200, or one would need an init baud rate, and a post-init baud rate, to which it would switch once the init commands are sent.
In any case: I can't get pfSync to use a higher rate successfully, because either I can't send the init commands, or pfSync won't sync after.
That means I'm stuck at the 9600/1Hz situation, unless I'd somehow took the risk of attempting to flash different firmware settings, so the module would communicate at 38400 or 115200 out of the the gate.
-
I know this thread is a bit dated, but a lot of good information here on using GPS with pfSense:
https://forum.netgate.com/topic/51920/gps-receiver-ntp
My original intention was just to try to a USB based GPS receiver since it's the cheapest approach, but upon seeing the warning in the documentation and reading that threat, it seems like a waste of time and money. PPS capability is also really important. Some more useful info:
http://support.ntp.org/bin/view/Support/InexpensiveOemGps
-
Wow was that 2013. Yikes!
-
Do you see a solid red LED on the lure when it has satellite lock?
Steve
-
Something was blinking red at some point, just noticed the blinking, since the system is in a case, I’m not sure what.
Can’t check now, as the unit is now at a remote site.
If it’s important somehow, I can check it out myself in a couple of months...
..,otherwise I’d have to get maintenance staff involved.
Is there a particular reason you ask? -
It isn't important. As far as I can see from the data sheet that's what it should do. Blinks at 0.5Hz without lock then solid once it has a 3D fix. But it can be set in firmware for other behaviour.
I have one to play with now myself so I'll let you know, if it ever gets a fix that is! TTFF from cold is.... um loooong.
Of course my antenna is not ideally placed. The chipset itself looks to be capable of TTFF in 45s so....Steve
-
Lock on to GPS NEVER happened with the built-in antenna, as the metal case, despite air vents, seems to have pretty much shielded that.
On the other hand, once the external antenna was connected, it was relatively swift in picking them up.
So I think it’s either taking the cover off, or using an external antenna, for which the case is fortunately well prepared, with a pre-made hole for the connector. -
For reference the 'fix' LED actually goes out entirely when a 3D fix is obtained.
Might be better to have it stay on solidly instead. I think that default is done to save power in battery driven applications which doesn't apply here. A firmware update might be possible to change that.Steve
