On 2015-12-28 08:16, Leon McCalla wrote:
Normally, the GPRMC gets sent every second even when the puck doesn't have a
fix. There is a field that says OK vs no-fix. ntpd checks that field.
10 satelite fix indoors. GPS is operating.
Normal timing setup is to have the device send only one NMEA GPRMC message
at 1s interval, and tweak driver fudge time1 until offset measured against
other sources averages around zero.
the GPS sends 3 GPRMC messages in a 3 second window but NOT 1 per second.
Beware. The SiRF chips are well known not co cooperate with that approach,
depending upon what you expect. They have lots of wander that you can't
filter out. If you tweak the fudge so that it is working correctly, it will
This is my problem. I bought a GPS based on an inferior chipset.
My GPS18xLVC+PPS averages within 1us and peaks about 50us jitter on Windows,
Garmin is a real GPS. please don’t mock me...
Garmins are mocked as not real timing GPS receivers, so...
it is because of these instability that I analyzed that messages in detail and
noticed GPGBS being sent every 3 seconds with under 10 ms jitter.
This is the reason I am asking how difficult will it be for me to modify the
NMEA driver to accept GPGBS messages with mode 16?
Should this question be on another list?
It would be easier to modify the GPS receiver settings to send only one GPRMC
message per second and see how well you can get that to work.
It may also be easier to look at what GPSD supports and see if you could set
up GPSD to talk to your GPS receiver and provide NTP with time, using either
SHM driver 28 or GPSD NG driver 46.
GPGBS appears to be a satellite fault detection message, so you may not see
those unless there are faulty satellites in the tracked constellation(s),
the message is only available with NMEA 3, appears to be assciated with a
preceding GPGGA or GPGNS fix message, and if you are seeing a GPGGA message,
that is already supported with mode 2.
If you want to support GPGBS, look at the NMEA driver 20 docs
https://www.eecis.udel.edu/~mills/ntp/html/drivers/driver20.html
and you will see that mode bits up to 0x100 plus 0x10000 are in use.
Start with that doc page from the current dev release and add changes for
GPGBS so you can more easily see what you shoukd be able to reuse from
existing message data field processing.
It would be consistent and not too hard to use say 0x200 as process GPGBS
message mode flag, and copy/paste/modify relevant sections from existing
message processing, with any unique additions that GPGBS message data
requires.
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
