SG-2340/MBT-4220 GPS-Lure Stratum-1 NTP clock under pfSense?
-
Sure thing @stephenw10; apologies for going off-topic.
Here is the new thread:
https://forum.netgate.com/topic/143727/building-a-stratum-1-ntp-server-using-raspberry-pi
-
@stephenw10 said in SG-2340/MBT-4220 GPS-Lure Stratum-1 NTP clock under pfSense?:
I don't see any actual specs on that antenna. Was it supplied with anything additional?
I would also expect it to work though....
Description lists this:
*Description
This GNSS (GPS, Galileo, Glonass) antenna has magnetic radome so it will stick to any steel structure like a roof of a car. It draws between 5-15mA and works in 2.2-5V DC range. You will need a sort of SMA to u.FL adapter cable to use it with u.FL modules/shields.50-ohm impedance
3-meter cable length with standard SMA connector
Polarization: RHCP
Radome Material: ABS
LNA Gain: 29±1 dB
Noise Figure: 1.5dB
Gain(Zenith): 3dB
V.S.W.R: <1.5* -
I'm thrilled to report, that it seems the GPS receiver finally has a lock, and I seem to get time just fine! :)
The settings used are:
GPS Type: MediaTek
Serial Port: cuau2
Port speed: 9600 baud
NMEA Sentences: All
Fudge Time 1: <empty>
Fudge Time 2: 0.400
Stratum: <empty> i.e. 0
Flags checked: Prefer this clock, Display extended GPS status
Flags unchecked: all others, in particular the PPS
Clock ID: <empty> i.e. GPS
GPS Initialization:$PMTK225,0*2B $PMTK314,1,1,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0*28 $PMTK301,2*2E $PMTK320,0*2F $PMTK330,0*2E $PMTK386,0*23 $PMTK397,0*23 $PMTK251,9600*17Auto correct malformed init commands: checked
This is what got things working, after a LONG LONG wait. So at least it seems the external antenna is working and up to spec, if anyone else needs the same.
So, having low expectations, that just made my day :D
-
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
