GPSD(8) GPSD Documentation GPSD(8)

gpsd - دیمن واسط گیرنده‌های GPS

gpsd [گزینه‌ها]

gpsd -h

gpsd -V

اگر یک GPS متصل به درگاه USB با کمترین شماره در یک سیستم لینوکس دارید و می‌خواهید گزارش‌های آن را روی درگاه TCP/IP به شماره ۲۹۴۷ بخوانید، معمولاً کافی است این کار را با دسترسی ریشه (root) انجام دهید:

# gpsd /dev/ttyUSB0

برای درگاه سریال با کمترین شماره:

# gpsd /dev/ttyS0

دستور gpsd ممکن است به عنوان یک کاربر عادی یا با استفاده از sudo اجرا شود، اما بخشی از قابلیت‌ها از دست خواهند رفت. بهتر است به عنوان ریشه اجرا شود. بخش مسائل امنیتی و مجوزها (SECURITY AND PERMISSIONS ISSUES) را در ادامه ببینید.

اگر نیاز به استفاده از درگاه متفاوتی دارید، شماره دستگاه را تغییر دهید. گزینه‌های خط فرمان امکاناتی چون ثبت وقایع با جزئیات بیشتر، یک درگاه کنترل و سایر قابلیت‌های اختیاری را فعال می‌کنند اما برای عملکردهای پایه ضروری نیستند؛ تنها استثنا، در سخت‌افزارهایی با طراحی بسیار ضعیف، ممکن است گزینه -b باشد (توضیحات آن را ببینید).

در سیستم‌های لینوکسی که از udev پشتیبانی می‌کنند، gpsd معمولاً هنگام رویداد اتصال یک دستگاه USB به طور خودکار اجرا می‌شود (اگر قبلاً در حال اجرا نباشد) و نام دستگاه تازه فعال‌شده به آن تحویل داده می‌شود. در این حالت به هیچ فراخوانی دستی نیازی نخواهد بود.

برای آزمایش‌های اولیه، سخت‌افزار GPS خود را طوری تنظیم کنید که با پروتکل NMEA صحبت کند، زیرا تضمین می‌شود که gpsd قادر به پردازش آن است. اگر GPS شما دارای یک حالت محلی (native) یا باینری با کارایی بهتر باشد که gpsd بتواند با آن ارتباط برقرار کند، ممکن است gpsd آن حالت را به طور خودکار پیکربندی نماید.

می‌توانید صحت عملکرد را ابتدا با اجرای gpsd بررسی کنید؛ سپس برنامه xgps (کلاینت آزمایشی سامانه پنجره X) یا cgps (کلاینت ترمینال مبتنی بر curses) را اجرا نمایید.

اگر با مشکلی مواجه شدید، پروژه GPSD اطلاعات مفیدی را به صورت آنلاین نگهداری می‌کند. برخی پیوندها در انتهای این صفحه راهنما قرار دارند.

برنامه gpsd یک دیمن پایشگر است که اطلاعات را از گیرنده‌های GPS، رادیوهای تفاضلی GPS (یا DGPS) یا گیرنده‌های AIS متصل به سیستم میزبان جمع‌آوری می‌کند. انتظار می‌رود هر گیرنده GPS، رادیوی DGPS یا گیرنده AIS مستقیماً از طریق یک دستگاه سریال USB یا RS232C به میزبان متصل باشد. دستگاه سریال ممکن است هنگام راه‌اندازی به gpsd مشخص شود، یا از طریق دستوری که از سوکت کنترل محلی ارسال می‌شود (برای نمونه توسط اسکریپت اتصال گرم USB) تعیین گردد. با مشخص شدن دستگاه GPS از هر یک از این دو روش، gpsd سرعت درگاه و پروتکل صحیح آن را شناسایی می‌کند.

برنامه gpsd باید قادر باشد هر GPSای را که با پروتکل متنی استاندارد NMEA 0183 صحبت می‌کند، یا از لهجه‌های توسعه‌یافته NMEA مورد استفاده در MTK-3301، iTrax، Motorola OnCore، Sony CXD2951، Ashtech/Thales و برخی دستگاه‌های دیگر استفاده می‌کند پرس‌وجو کند. همچنین می‌تواند پروتکل‌های باینری به کار رفته در دستگاه‌های EverMore، Garmin، Javad، Navcom، Rockwell/Zodiac، SiRF، Trimble و u-blox را تفسیر کند. در لینوکس می‌تواند بسته‌های NMEA2000 را از طریق سوکت CAN هسته بخواند. این برنامه می‌تواند اطلاعات جهت‌گیری و وضعیت فضایی (heading and attitude) را از قطب‌نماهای دیجیتال TNT Revolution بخواند.

قالب‌های گزارش‌دهی GPS پشتیبانی‌شده توسط فایل اجرایی gpsd شما ممکن است بسته به نحوه کامپایل آن متفاوت باشد؛ نسخه‌های عمومی از پروتکل‌های متعددی پشتیبانی می‌کنند، اما برای استفاده در محیط‌های محدود می‌تواند با زیرمجموعه‌ای از پروتکل‌ها تا حد یک پروتکل منفرد کامپایل شود. برای مشاهده فهرستی از پروتکل‌های GPS پشتیبانی‌شده توسط باینری خود، خروجی gpsd -l را ببینید.

برنامه gpsd تفاوت‌های میان انواع GPSهای پشتیبانی‌شده را به طور مؤثری پنهان می‌کند. همچنین دستوراتی را می‌شناسد و به کار می‌گیرد که این GPSها را برای تأخیر کمتر تنظیم می‌کنند. با استفاده از gpsd به عنوان یک واسطه، برنامه‌های کاربردی از رقابت و تداخل برای دسترسی به دستگاه‌های سریال پرهیز می‌کنند.

برنامه gpsd می‌تواند از تصحیحات GPS تفاضلی حاصل از یک رادیوی DGPS یا از طریق شبکه و از یک ایستگاه زمینی دارای سرور DGPSIP یا یک پخش‌کننده Ntrip که داده‌های RTCM-104 را مخابره می‌کند استفاده نماید؛ این امر ممکن است خطاهای موقعیت‌یابی را کاهش دهد. زمانی که gpsd یک دستگاه سریال ارسال‌کننده RTCM-104 را باز می‌کند، به طور خودکار این موضوع را تشخیص داده و از آن دستگاه به عنوان منبع تصحیح برای تمام GPSهای متصلی که تصحیحات RTCM را می‌پذیرند استفاده می‌کند (این امر به نوع GPS بستگی دارد؛ همه GPSها قابلیت سفت‌افزاری لازم برای پذیرش بسته‌های تصحیح RTCM را ندارند).

برنامه‌های کلاینت معمولاً از طریق یک درگاه TCP/IP (به طور پیش‌فرض درگاه ۲۹۴۷) با gpsd ارتباط برقرار می‌کنند. هر دو نوع اتصال IPv4 و IPv6 پشتیبانی می‌شوند و کلاینت می‌تواند از طریق هر یک از آنها متصل شود.

این برنامه گزینه‌های زیر را می‌پذیرد:

-?, -h, ---help

نمایش پیام راهنما و خروج.

-b, --readonly

حالت ایمنی برای دستگاه‌های معیوب، که به عنوان حالت فقط‌خواندنی نیز شناخته می‌شود. تعداد کمی از گیرنده‌های بلوتوث و USB هنگام کاوش یا پیکربندی مجدد قفل می‌کنند یا کاملاً از دسترس خارج می‌شوند؛ برای جزئیات، فهرست سازگاری سخت‌افزار را در وب‌سایت پروژه GPSD ببینید. این سوییچ مانع نوشتن gpsd روی گیرنده می‌شود. این بدان معناست که gpsd نمی‌تواند گیرنده را برای عملکرد بهینه پیکربندی کند، اما همچنین تضمین می‌کند که آسیبی به گیرنده نمی‌رسد. راه‌حل بهتر این بود که بلوتوث تا این حد شکننده نباشد. یک روش مستقل از بستر برای شناسایی دستگاه‌های سریال روی بلوتوث نیز بسیار مفید می‌بود.

-D LVL, --debug LVL

تنظیم سطح اشکال‌زدایی. مقدار پیش‌فرض 0 است. در سطوح اشکال‌زدایی 2 و بالاتر، اگر gpsd در پیش‌زمینه (-N) باشد، جملات دریافتی و اقدامات را در خطای استاندارد (stderr) و اگر در پس‌زمینه باشد، در syslog گزارش می‌دهد. بخش ثبت وقایع (LOGGING) را در ادامه ببینید.

-F FILE, --sockfile FILE

ایجاد یک سوکت کنترل برای دستورات افزودن و حذف دستگاه. مقدار پیش‌فرض None است. شما باید یک مسیر معتبر در سامانه فایل محلی خود مشخص کنید؛ این مسیر به عنوان یک سوکت دامنه یونیکس ایجاد می‌شود که می‌توانید دستورات ویرایش فهرست داخلی دستگاه‌های دیمن را در آن بنویسید.

-f FRAME, --framing FRAME

تثبیت قالب‌بندی (framing) فریم‌ها برای دستگاه GNSS. پارامتر فریم به صورت: [78][ENO][012] است. اکثر دستگاه‌های GNSS به صورت 8N1 هستند. در برخی دستگاه‌های Trimble پیش‌فرض 8O1 است. حالت پیش‌فرض، جستجو برای یافتن قالب‌بندی صحیح است.

-G, --listenany

این فلگ باعث می‌شود gpsd روی تمام آدرس‌ها (INADDR_ANY) گوش دهد، به جای اینکه فقط روی آدرس لوپ‌بک (INADDR_LOOPBACK) فعال باشد. به دلایل حفظ حریم خصوصی و امنیت، اطلاعات gpsd به طور پیش‌فرض برای ماشین محلی خصوصی است تا زمانی که کاربر صراحتاً آن را برای دنیای بیرون در دسترس قرار دهد.

-l, --drivers

فهرست کردن تمام راه‌اندازهایی که در این نمونه از gpsd کامپایل شده‌اند. حروف سمت چپ نام هر درایور، دستورات کنترلی gpsd هستند که توسط آن درایور پشتیبانی می‌شوند. سپس خارج می‌شود.

-n, --nowait

قبل از اتصال یک کلاینت، منتظر نمانید و هر GPS مرتبط با آن را بی‌درنگ پایش کنید. برخی از GPSهای RS232 زمانی که ماشین میزبان خط DTR را فعال نکرده است در حالت آماده‌به‌کار (با مصرف توان کمتر) منتظر می‌مانند، و برخی از GPSهای تعبیه‌شده در تلفن همراه و دستگاه‌های دستی نیز رفتار مشابهی دارند. بر این اساس، انتظار برای درخواست پایش جهت باز کردن دستگاه ممکن است در مصرف باتری صرفه‌جویی کند. (این قابلیت در دستگاه‌های رده مصرفی متداول نادر است). اگر قصد دارید از gpsd برای ارائه اطلاعات ساعت مرجع به ntpd یا chronyd استفاده کنید، باید از این گزینه بهره بگیرید. این گزینه همچنین کلاینت‌ها را قادر می‌سازد تا هنگام برقراری اتصال، داده‌های گیرنده را سریع‌تر مشاهده کنند.

-N, --foreground

به صورت دیمن اجرا نشود؛ در پیش‌زمینه اجرا شود. این سوییچ عمدتاً برای اشکال‌زدایی کاربرد دارد.

-p, --passive

حالت غیرفعال (پسیو). گیرنده را به طور خودکار پیکربندی نکنید، اما به تغییرات پیکربندی دستی اجازه دهید.

-P FILE, --pidfile FILE

مشخص کردن نام و مسیر پرونده برای ثبت شناسه فرایند (PID) دیمن.

-r, --badtime

استفاده از زمان GPS حتی بدون تثبیت موقعیت فعلی (fix). برخی از GPSها دارای ساعت بلادرنگ (RTC) باتری‌دار داخلی هستند که آنها را حتی پیش از تثبیت موقعیت به یک منبع معتبر زمان تبدیل می‌کند. این ویژگی می‌تواند روی رزبری‌پای یا سایر دستگاه‌هایی که ساعت RTC باتری‌دار ندارند و بنابراین در زمان راه‌اندازی فاقد زمان معتبر هستند مفید باشد. با احتیاط استفاده شود.

--port PORT, -S PORT

تنظیم درگاه TCP/IP برای گوش دادن به درخواست کلاینت‌های GPSD (پیش‌فرض ۲۹۴۷ است).

-s SPEED, --speed SPEED

تثبیت سرعت درگاه سریال برای دستگاه GNSS. سرعت‌های مجاز عبارتند از: 4800، 9600، 19200، 38400، 57600، 115200، 230400، 460800 و 921600. حالت پیش‌فرض تنظیم خودکار نرخ باد (autobaud) است. توجه داشته باشید که برخی دستگاه‌های دارای USB مجتمع سرعت درگاه را نادیده می‌گیرند.

-V, --version

چاپ نگارش و خروج.

آرگومان‌ها به عنوان نام‌های منابع داده تفسیر می‌شوند. معمولاً یک منبع داده، مسیر پرونده دستگاهی محلی است که دیمن انتظار دارد داده‌های GPS را از آن دریافت کند. اما سه نوع منبع خاص دیگر نیز شناسایی می‌شوند که در مجموع چهار نوع منبع را تشکیل می‌دهند:

دستگاه محلی سریال یا USB

نام عادی یک دستگاه یونیکس مربوط به دستگاه سریال یا USB که یک حسگر به آن متصل است. مثال‌ها: /dev/ttyS0 یا /dev/ttyUSB0.

دستگاه محلی PPS

نام عادی یک دستگاه یونیکس مربوط به دستگاه PPS که منبع PPS به آن متصل است. نام دستگاه باید با "/dev/pps" آغاز شود و یک دستگاه GPS محلی سریال یا USB نیز باید در دسترس باشد. مثال: /dev/pps0.

خوراک TCP

یک نشانی URI با پیشوند "://tcp"، به دنبال نام میزبان، دونقطه، و شماره درگاه. دیمن یک سوکت به نشانی و درگاه تعیین‌شده باز کرده و بسته‌های داده را از آن می‌خواند؛ این بسته‌ها به گونه‌ای تفسیر می‌شوند که گویی از یک دستگاه سریال صادر شده‌اند. مثال: tcp://data.aishub.net:4006.

خوراک UDP

یک نشانی URI با پیشوند "://udp"، به دنبال نام میزبان، دونقطه، و شماره درگاه. دیمن یک سوکت باز کرده و به دیتاگرام‌های UDP ورودی در نشانی و درگاه تعیین‌شده گوش می‌دهد؛ این دیتاگرام‌ها به گونه‌ای تفسیر می‌شوند که گویی از یک دستگاه سریال صادر شده‌اند. مثال: udp://127.0.0.1:5000.

کستر Ntrip

یک نشانی URI با پیشوند "://ntrip" به دنبال نام یک پخش‌کننده Ntrip (پروتکل Ntrip برای انتشار تصحیحات تفاضلی GPS روی اینترنت است). برای سرویس‌های Ntrip که نیازمند احراز هویت هستند، می‌توان پیشوندی به شکل "@username:password" را قبل از نام پخش‌کننده Ntrip اضافه کرد. برای سرویس Ntrip، باید مشخص کنید که از کدام جریان (stream) استفاده شود؛ جریان به شکل "streamname/" داده می‌شود. یک مثال URI برای DGPSIP می‌تواند "dgpsip://dgpsip.example.com" و یک URI برای Ntrip می‌تواند "ntrip://foo:bar@ntrip.example.com:80/example-stream" باشد. تصحیحات دریافتی از کستر به هر GPS متصلی که توانایی پذیرش آنها را داشته باشد ارسال می‌شود.

سرور DGPSIP

یک نشانی URI با پیشوند "://dgpsip" به دنبال نام میزبان، یک دونقطه، و شماره درگاه اختیاری (با پیش‌فرض ۲۱۰۱). دیمن با سرور DGPSIP دست‌تکانی کرده و داده‌های تصحیح RTCM2 را از آن می‌خواند. تصحیحات حاصل از سرور به هر GPS متصلی که قابلیت پذیرش آنها را داشته باشد فرستاده می‌شود. مثال: dgpsip://dgps.wsrcc.com:2101.

خوراک از راه دور gpsd

یک نشانی URI با پیشوند "://gpsd"، به دنبال نام میزبان و در صورت تمایل یک دونقطه و شماره درگاه (اگر درگاه مشخص نشود از درگاه پیش‌فرض gpsd استفاده خواهد شد). سپس به صورت اختیاری یک دونقطه دوم و نام دستگاه راه دور می‌آید. دیمن یک سوکت به نشانی و درگاه مشخص‌شده باز کرده و نقش کلاینت gpsd را ایفا می‌کند، و گزارش‌های JSON را از نمونه راه‌دور gpsd دریافت کرده و به کلاینت‌های محلی تحویل می‌دهد. مثال: gpsd://gpsd.io:2947:/dev/ttyAMA0.

داده‌های CAN مربوط به NMEA2000

یک نشانی URI با پیشوند "://nmea2000"، به دنبال نام دستگاه CAN. تنها واسط‌های سوکت CAN در لینوکس پشتیبانی می‌شوند. این واسط باید قبل از اجرای gpsd برای دریافت پیام‌های CAN پیکربندی شده باشد. اگر بیش از یک دستگاه روی گذرگاه CAN داده‌های GPS را ارائه دهد، gpsd دستگاهی را انتخاب می‌کند که پیام GPS آن زودتر دیده شود. مثال: nmea2000://can0.

(نوع منبع "://ais" که در برخی نسخه‌های قدیمی‌تر دیمن پشتیبانی می‌شد، به نفع نوع عمومی‌تر "://tcp" کنار گذاشته شده است).

علاوه بر این، در صورتی که فایل باینری شما با گزینه MAGIC_HAT کامپایل شده باشد، دو نام دستگاه سریال اثر جانبی به همراه دارند:

/dev/ttyAMA0

دستگاه UART در برد رزبری‌پای. دارای اثر جانبی باز کردن /dev/pps0 برای داده‌های RFC2783 1PPS است.

/dev/gpsd0

دستگاه عمومی GPS شماره ۰. دارای اثر جانبی باز کردن /dev/pps0 برای داده‌های RFC2783 1PPS است.

توجه داشته باشید که اگر /dev/pps0 مربوط به PPS ساختگی "ktimer" باشد، از /dev/pps1 به جای آن استفاده خواهد شد.

درون برنامه، دیمن یک استخر دستگاه (device pool) نگهداری می‌کند که مسیر دستگاه‌ها و سرورهای راه دور شناخته‌شده را در خود دارد. در ابتدا، این فهرست با آرگومان‌های نام دستگاه مشخص‌شده در خط فرمان مقداردهی می‌شود. این فهرست می‌تواند خالی باشد؛ در این حالت دیمن هیچ دستگاهی در فهرست جستجوی خود نخواهد داشت تا زمانی که از طریق دستوری در سوکت کنترل اضافه شوند. راه‌اندازی دیمن در صورتی که هیچ دستگاه و هیچ سوکت کنترلی مشخص نشده باشد با خطا متوقف می‌شود.

هنگامی که یک دستگاه فعال می‌شود (یعنی کلاینتی داده‌های آن را درخواست می‌کند)، gpsd تلاش می‌کند یک قلاب (hook) را از /etc/gpsd/device-hook اجرا کند که در آن اولین آرگومان خط فرمان برابر با مسیر فایل دستگاه و دومین آرگومان برابر با ACTIVATE تنظیم شده است. هنگام غیرفعال‌سازی نیز همین کار را انجام داده و DEACTIVATE را برای آرگومان دوم ارسال می‌کند.

برنامه gpsd می‌تواند داده‌ها را به سه روش به برنامه‌های کاربردی کلاینت ارائه دهد: از طریق یک رابط سوکت، از طریق قطعه حافظه مشترک، و از طریق D-Bus. سه بخش عمده بعدی به شرح این رابط‌ها می‌پردازند.

هنگامی که gpsd به صورت یک دیمن اجرا می‌شود (نه در پیش‌زمینه)، تمام گزارش‌های خود را به syslog(3) می‌فرستد. وقایع با شناسه "gpsd" و با استفاده از تسهیلات "LOG_USER" ارسال می‌شوند.

اگر از syslog-ng استفاده می‌کنید، می‌توانید تمام گزارش‌های gpsd را به پرونده /var/log/gpsd هدایت کنید. این خطوط را در انتهای پرونده /etc/syslog-ng/syslog-ng.conf خود قرار دهید:

destination gpsdf { file("/var/log/gpsd"); };
filter f_gpsd { program("gpsd"); };
log { source(src); filter(f_gpsd); destination(gpsdf); };

کلاینت‌ها می‌توانند از طریق درخواست‌ها و پاسخ‌های متنی روی یک سوکت با دیمن ارتباط برقرار کنند. ارتباط مستقیم برنامه‌ها با این پروتکل ایده نامناسبی است؛ در عوض، برنامه‌ها باید از کتابخانه کلاینت libgps استفاده کرده و مراقبت‌های لازم را برای شرطی‌سازی کدهای خود بر اساس نمادهای نگارش اصلی و فرعی پروتکل به عمل آورند.

پروتکل درخواست-پاسخ برای رابط سوکت به طور کامل در gpsd_json(5) مستند شده است.

برنامه gpsd دارای دو رابط دیگر (صرفاً فقط‌خواندنی) است.

هر زمان که دیمن یک بسته را از هر دستگاه متصلی تشخیص دهد، وضعیت انباشته‌شده از آن دستگاه را در یک قطعه حافظه مشترک (shared memory segment) می‌نویسد. کتابخانه‌های کلاینت C و ++C که همراه با GPSD عرضه می‌شوند می‌توانند این بخش را بخوانند. متدهای کلاینت و محدودیت‌های گوناگون ناشی از ماهیت فقط‌خواندنی این رابط در libgps(3) مستند شده‌اند. رابط حافظه مشترک در درجه اول برای محیط‌های تعبیه‌شده در نظر گرفته شده است که در آنها gpsd یک دستگاه منفرد را پایش می‌کند، و مزیت اصلی آن این است که یک نمونه دیمن که با حافظه مشترک ولی بدون رابط سوکت پیکربندی شده باشد، بخش قابل توجهی از بار و وزن زمان اجرا را کاهش می‌دهد.

دیمن را می‌توان به گونه‌ای پیکربندی کرد که هر بار که یک دستگاه متصل تثبیت موقعیت (fix) جدیدی ارائه می‌دهد، یک سیگنال D-Bus ارسال کند. مسیر سیگنال "path /org/gpsd"، رابط سیگنال "org.gpsd"، و نام سیگنال "fix" است. ساختار بار داده‌ای (payload) سیگنال به شرح زیر است:

جدول ۱. شیء ماهواره (Satellite object)

نوع توضیحات
DBUS_TYPE_DOUBLE زمان (ثانیه از مبدأ یونیکس)
DBUS_TYPE_INT32 حالت
DBUS_TYPE_DOUBLE عدم قطعیت زمان (ثانیه).
DBUS_TYPE_DOUBLE عرض جغرافیایی به درجه.
DBUS_TYPE_DOUBLE طول جغرافیایی به درجه.
DBUS_TYPE_DOUBLE عدم قطعیت افقی به متر.
DBUS_TYPE_DOUBLE ارتفاع از سطح دریا (MSL) به متر.
DBUS_TYPE_DOUBLE عدم قطعیت ارتفاع به متر.
DBUS_TYPE_DOUBLE جهت حرکت به درجه از شمال واقعی.
DBUS_TYPE_DOUBLE عدم قطعیت جهت به متر.
DBUS_TYPE_DOUBLE سرعت، متر بر ثانیه.
DBUS_TYPE_DOUBLE عدم قطعیت سرعت بر حسب متر بر ثانیه.
DBUS_TYPE_DOUBLE نرخ صعود، متر بر ثانیه.
DBUS_TYPE_DOUBLE عدم قطعیت صعود بر حسب متر بر ثانیه.
DBUS_TYPE_STRING نام دستگاه

مقادیر عدم قطعیت توسط گیرنده GNSS ارائه می‌شوند. به مستندات گیرنده خود مراجعه کنید تا ببینید منظور آن از "عدم قطعیت" چیست.

برنامه gpsd فهرستی داخلی از دستگاه‌های GPS را نگهداری می‌کند ("استخر دستگاه"). اگر دستگاه‌ها را در خط فرمان مشخص کنید، فهرست با آن مسیرها مقداردهی اولیه می‌شود؛ در غیر این صورت، فهرست در ابتدا خالی است. دستورات افزودن و حذف مسیر دستگاه‌های GPS از فهرست دستگاه‌های دیمن باید در یک سوکت محلی دامنه یونیکس نوشته شوند که تنها برای برنامه‌های در حال اجرا با دسترسی ریشه (root) قابل دسترسی خواهد بود. این سوکت کنترل در هر مکانی که گزینه -F مشخص کند قرار خواهد گرفت.

همچنین اگر GPSD در حین خواندن از یک دستگاه داده‌ای با طول صفر دریافت کند، آن دستگاه از استخر حذف خواهد شد. این وضعیت پایان فایل (EOF) نشان می‌دهد که ارتباط دستگاه قطع شده است.

هنگامی که gpsd همراه با اسکریپت‌های اعلان اتصال گرم (hotplug) فعال نصب شده باشد که دستورات افزودن دستگاه را از طریق سوکت کنترل به آن ارسال می‌کنند، gpsd برای یافتن دستگاه‌های متصل نباید به هیچ پیکربندی یا اقدام کاربری نیاز داشته باشد.

ارسال سیگنال SIGHUP به یک gpsd در حال اجرا، آن را وادار می‌کند تا تمام گیرنده‌های GPS و تمام اتصالات کلاینت‌ها را ببندد. سپس تلاش خواهد کرد مجدداً به تمام GPSهای موجود در فهرست دستگاه‌های خود متصل شده و پذیرش اتصالات کلاینت را از سر بگیرد. این عمل در صورتی مفید است که GPS شما در وضعیتی معلق یا نامشخص قرار گرفته باشد اما بتوان با پایین کشیدن پایه DTR آن را به صورت نرم‌افزاری بازنشانی کرد.

هنگامی که gpsd بدون هیچ دستگاه اولیه‌ای اجرا شود (بنابراین انتظار دارد دستگاه‌ها از طریق اعلان‌ها به سوکت کنترل تحویل داده شوند)، و پس از مشاهده چند دستگاه به وضعیتی برسد که در آن هیچ دستگاهی متصل نبوده و هیچ مشترکی وجود نداشته باشد، با آرامش خاتمه می‌یابد. انتظار می‌رود که رویدادهای آینده اتصال دستگاه‌ها آن را مجدداً فعال سازند.

برای هدایت gpsd به سوی دستگاهی که ممکن است یک GPS باشد، علامت مثبت ('+') و به دنبال آن نام دستگاه و سپس کاراکتر LF یا CR-LF را در سوکت کنترل بنویسید. بنابراین برای هدایت دیمن به /dev/foo، رشته "+/dev/foo\n" را ارسال کنید. برای اعلام اینکه یک دستگاه قطع شده و دیگر در دسترس نیست، یک علامت منفی ('-') و به دنبال آن نام دستگاه و سپس LF یا CR-LF ارسال نمایید. بنابراین برای حذف /dev/foo از فهرست جستجو، رشته "-/dev/foo\n" را ارسال کنید.

برای ارسال یک رشته کنترلی به یک دستگاه مشخص، در سوکت کنترل یک '!'، سپس نام دستگاه، سپس '=' و به دنبال آن رشته کنترلی را بنویسید.

برای ارسال یک رشته کنترلی باینری به یک دستگاه مشخص، در سوکت کنترل یک '&'، سپس نام دستگاه، سپس '=' و به دنبال آن رشته کنترلی را به صورت جفت ارقام هگزادسیمال بنویسید.

کلاینت شما می‌تواند منتظر پاسخ بماند، که خطی خواهد بود که با "OK" یا "ERROR" آغاز می‌شود. پاسخ ERROR به دستور 'add' به این معنی است که دستگاه داده‌های قابل تشخیص به عنوان بسته‌های GPS را صادر نکرده است؛ پاسخ ERROR به دستور حذف به این معنی است که دستگاه مشخص‌شده در استخر دستگاه‌های gpsd وجود نداشته است. پاسخ ERROR به دستور '!' به این معنی است که دیمن نام دستگاه مشخص‌شده را شناسایی نکرده است.

سوکت کنترل برای استفاده توسط اسکریپت‌های اتصال گرم و سایر سرویس‌های کشف دستگاه در نظر گرفته شده است. این کانال کنترلی از درگاه سرویس عمومی gpsd مجزا بوده و تنها به صورت محلی در دسترس است تا از حملات ازکاراندازی سرویس و جعل هویت از راه دور جلوگیری شود.

خطای پایه برآورد مسافت کاربر (UERE) برای دستگاه‌های GPS برابر ۸ متر یا کمتر با ضریب اطمینان ۶۶٪، و ۱۵ متر یا کمتر با ضریب اطمینان ۹۵٪ است. خطای افقی واقعی برابر با حاصل‌ضرب UERE در ضریب تضعیف وابسته به موقعیت فعلی ماهواره‌ها خواهد بود. تعیین ارتفاع نسبت به عرض و طول جغرافیایی در برابر نوسانات تأخیر سیگنال در یونوسفر حساس‌تر است، و همچنین در معرض خطاهای برآورد سطح متوسط دریا در منطقه قرار دارد؛ خطای پایه ارتفاع ۱۲ متر با اطمینان ۶۶٪ و ۲۳ متر با اطمینان ۹۵٪ است. مجدداً این مقدار در ضریب تضعیف عمودی دقت (VDOP) وابسته به هندسه ماهواره‌ها ضرب می‌شود، و مقدار VDOP معمولاً بزرگ‌تر از HDOP است. کاربران نباید برای اقدامات حیاتی مانند فرود هواپیما به ارتفاع گزارش‌شده توسط GPS اتکا کنند.

این خطاها جزء ذاتی طراحی و فیزیک سامانه GPS هستند. برنامه gpsd محاسبات داخلی خود را با دقتی کافی انجام می‌دهد به طوری که هیچ خطای مکانی قابل اندازه‌گیری از سوی خود به آن نمی‌افزاید.

تصحیح DGPS ممکن است UERE را کاهش دهد، به شرطی که شما در فاصله حدود ۱۰۰ مایلی (۱۶۰ کیلومتری) یک ایستگاه زمینی DGPS باشید که تصحیحات را از آن دریافت می‌کنید.

روی یک اتصال با سرعت ۴۸۰۰ بیت بر ثانیه، تأخیر زمانی موقعیت‌یابی‌های ارائه‌شده توسط gpsd در ۹۵٪ مواقع یک ثانیه یا کمتر خواهد بود. بیشتر این تأخیر ناشی از این واقعیت است که گیرنده‌های GPS معمولاً یک بار در هر ثانیه موقعیت تثبیت‌شده را صادر می‌کنند، بنابراین تأخیر مورد انتظار ۰٫۵ ثانیه است. روی سخت‌افزارهای رایانه‌های شخصی موجود از سال ۲۰۰۵ به بعد، تأخیر محاسباتی تحمیل‌شده توسط gpsd ناچیز و در حدود یک میلی‌ثانیه خواهد بود. با این حال، تأخیر می‌تواند برای وسایل نقلیه در حال حرکت خطاهای چشمگیری ایجاد کند؛ در سرعت ۵۰ کیلومتر بر ساعت (۳۱ مایل بر ساعت) نسبت به زمین، ۱ ثانیه تأخیر برابر با ۱۳٫۸ متر تغییر در موقعیت مکانی میان دو به‌روزرسانی است.

گزارش زمان خود سامانه GPS دارای حد دقت ذاتی ۱۴ نانوثانیه است، اما این مقدار را تنها می‌توان با گیرنده‌های تخصصی تقریب زد که پالس دقیق PPS (یک پالس در ثانیه) را روی RS232 ارسال می‌کنند تا یک کریستال ساعت را همگام سازند. بیشتر گیرنده‌های GPS زمان را تنها با دقت ۰٫۰۱ یا ۰٫۰۰۱ ثانیه گزارش می‌کنند و هیچ تضمین دقتی برای کمتر از ۱ ثانیه ندارند.

اگر GPS شما از چیپست SiRF با سفت‌افزار نگارش ۲۳۱ استفاده می‌کند، زمان UTC گزارش‌شده ممکن است از زمان راه‌اندازی تا دریافت اطلاعات کامل زیرفریم، به اندازه اختلاف بین افست پیش‌فرض ثانیه کبیسه کامپایل‌شده و تصحیح ثانیه کبیسه اعمال‌شده فعلی دارای خطا باشد. سفت‌افزارهای نگارش ۲۳۲ و بالاتر این مشکل را ندارند. می‌توانید gpsd را با سطح اشکال‌زدایی ۴ اجرا کنید تا نوع چیپست و نگارش سفت‌افزار را مشاهده کنید.

دقیقاً دو وضعیت وجود دارد که در آنها gpsd به ساعت سامانه میزبان متکی است:

در سیگنال انتشار GPS، زمان GPS با استفاده از یک شماره هفته نمایش داده می‌شود که بسته به فضاپیما، پس از ۲ به توان ۱۰ یا ۲ به توان ۱۳ هفته (حدود ۱۹٫۶ سال، یا ۱۵۷ سال) سرریز شده و صفر می‌شود (rollover). گیرنده‌ها موظفند این تاریخ را به تاریخ صحیح ابهام‌زدایی کنند، اما ممکن است به دلیل ندانستن زمان در بازه نیمی از این محدوده، یا به دلیل باگ‌های نرم‌افزاری دچار مشکل شوند. کاربران تاریخ‌های نادرستی را گزارش کرده‌اند که به نظر می‌رسد ناشی از همین مسئله است. gpsd از زمان راه‌اندازی دیمن برای تشخیص و جبران سرریزها در حین اجرای خود استفاده می‌کند، اما در غیر این صورت تاریخ را همان‌گونه که توسط گیرنده گزارش شده بدون تلاش برای اصلاح آن ارائه می‌دهد.

اگر از یک GPS صرفاً NMEA استفاده می‌کنید (یعنی بدون استفاده از حالت باینری SiRF یا Garmin یا Zodiac)، برنامه gpsd برای تشخیص سده فعلی به ساعت سیستم متکی است. اگر ساعت سیستم مقداری نامعتبر و نزدیک به صفر برگرداند، و GPS پیام GPZDA را در آغاز چرخه به‌روزرسانی خود صادر نکند (که اکثر GPSهای رده مصرفی NMEA این کار را نمی‌کنند)، بخش سده از تاریخ‌هایی که gpsd ارائه می‌دهد ممکن است اشتباه باشد. علاوه بر این، در نزدیکی تغییر سده، بازه‌ای از تاریخ‌ها به گستردگی ثانیه‌های دقت ساعت سیستم شما ممکن است به سده نادرستی نسبت داده شود.

برنامه gpsd می‌تواند اطلاعات ساعت مرجع را به ntpd یا chronyd ارائه دهد تا ساعت سیستم با زمان ارائه‌شده توسط گیرنده GPS همگام بماند.

در لینوکس، gpsd شامل پشتیبانی از تفسیر پالس‌های PPS است که در آغاز هر ثانیه روی خطوط تشخیص حامل (carrier-detect) در برخی از GPSهای سریال صادر می‌شوند؛ این پالس می‌تواند برای به‌روزرسانی NTP با دقتی بسیار بالاتر از زمان بسته‌های پیام به کار رود. می‌توانید با اجرای برنامه با گزینه -D 5 و زیر نظر گرفتن پیام‌های تغییر وضعیت تشخیص حامل در پرونده وقایع، مشخص کنید که آیا GPS شما این پالس را ارسال می‌کند یا خیر. علاوه بر این، اگر هسته شما رابط برنامه‌نویسی RFC 2783 kernel PPS API را فراهم کند، gpsd از آن برای دقت بیشتر بهره خواهد برد.

برنامه gpsd با استفاده از قطعات حافظه مشترک (SHMها) با ntpd ارتباط برقرار می‌کند. قطعات SHM از SHM(0) تا SHM(7) شماره‌گذاری شده‌اند و نام (کلید) آنها از NTP0 تا NTP7 است. نخستین منبع زمان محلی در خط فرمان ممکن است از NTP0 و NTP1 استفاده کند. دومی ممکن است از NTP2 و NTP3 بهره ببرد و به همین ترتیب.

می‌توانید خروجی gpsd به ntpd را به صورت بلادرنگ با دستور ntpshmmon مشاهده کنید.

دیمن‌های دیگر، مانند ptp4l نیز ممکن است از همین بخش‌های SHM برای گفتگو با ntpd استفاده کنند.

دستورالعمل‌های دقیق برای استفاده از GPSD به منظور راه‌اندازی یک سرویس زمان با کیفیت بالا را می‌توانید در میان مستندات موجود در وب‌سایت GPSD بیابید.

در سیستم‌های عاملی که از D-BUS پشتیبانی می‌کنند، gpsd می‌تواند طوری ساخته شود که تثبیت‌های موقعیت GPS را برای برنامه‌های آگاه از D-BUS پخش کند. از آنجا که D-BUS هنوز در مراحل اولیه خود است، ما در اینجا اقدام به مستندسازی این رابط نمی‌کنیم. برای آگاهی بیشتر کدهای منبع gpsd را مطالعه نمایید.

برنامه gpsd در صورت دریافت فلگ -G، به اتصالات از هر میزبان قابل دسترسی گوش داده و سپس موقعیت مکانی فعلی را افشا خواهد کرد. پیش از استفاده از فلگ -G، بررسی کنید که آیا موقعیت رایانه خود را داده‌ای حساس می‌دانید که باید محرمانه بماند یا چیزی است که تمایل به انتشار آن دارید.

برنامه gpsd برای باز کردن قطعه حافظه مشترک NTPD، باز کردن پرونده وقایع، و ایجاد سوکت کنترل محلی خود باید با دسترسی ریشه (root) آغاز شود. توجه داشته باشید که اجرای gpsd با sudo معادل اجرا به عنوان کاربر ریشه نیست. این برنامه پیش از انجام هرگونه پردازش روی داده‌های GPS، تلاش می‌کند با تنظیم شناسه کاربری (UID) خود به "nobody" (یا شناسه کاربری پیکربندی‌شده دیگر) و گروه کاربری (GID) به گروه اولین GPS تعیین‌شده در خط فرمان — یا در صورت عدم وجود آن دستگاه، به گروه /dev/ttyS0 — امتیازات ریشه را رها کند.

رهاسازی امتیازات ریشه، سپری در برابر این احتمال است که داده‌های با دقت طراحی‌شده و مخرب، چه از سوی یک سوکت کلاینت یا از سوی یک دستگاه سریال نفوذیافته که خود را به عنوان GPS جا می‌زند، بتوانند برای ایجاد رفتار مخرب در بخش‌های داخلی gpsd به کار روند. این کار تضمین می‌کند که از چنین آسیب‌پذیری‌هایی نمی‌توان برای ارتقای دسترسی به کاربر ریشه (root) سوءاستفاده کرد.

فرض پشت این رفتار خاص gpsd این است که تمام دستگاه‌های tty که ممکن است یک GPS به آنها متصل شود تحت مالکیت یک گروه غیر ریشه یکسان قرار دارند و اجازه خواندن/نوشتن به آن گروه داده شده است، هرچند ممکن است این گروه به دلیل تفاوت در توزیع‌ها یا شیوه‌های مدیریتی محلی متفاوت باشد. اگر این فرض نادرست باشد، ممکن است gpsd نتواند دستگاه‌های GPS را برای خواندن باز کند (این‌گونه خطاها در وقایع ثبت خواهند شد).

به منظور دفع حملات غیرعمدی ازکاراندازی سرویس (DoS) توسط پویشگرهای درگاه (و البته حملات عمدی)، gpsd اتصالات کلاینت‌های غیرفعال را پس از پایان مهلت زمانی (timeout) قطع می‌کند. پیش از اینکه کلاینت دستوری صادر کند که درخواست تخصیص کانال داشته باشد، یک زمان انتظار کوتاه (۶۰ ثانیه) اعمال می‌شود. برای کلاینت‌ها در حالت‌های پایشگر (watcher) یا خام (raw) هیچ مهلت زمانی اعمال نمی‌شود؛ بلکه gpsd در صورتی که این کلاینت‌ها برای مدتی طولانی داده‌ها را نخوانند به طوری که بافر خروجی نوشتن در سوکت پر شود، اتصال آنها را قطع می‌کند. کلاینت‌هایی با دستگاه تخصیص‌یافته در حالت پرس‌وجوی دوره‌ای (polling) مشمول یک مهلت زمانی طولانی‌تر (۱۵ دقیقه) هستند.

اگر gpsd شما برای پشتیبانی از capabilities(7) کامپایل شده باشد، ممکن است بتواند به عنوان یک کاربر عادی اجرا شده و برخی از قابلیت‌های تقلیل‌یافته را حفظ کند. قابلیت‌های زیر مفید خواهند بود:

جدول ۲. شیء قابلیت‌ها (caps object)

نام توضیحات
CAP_FOWNER برای ()chmod
CAP_SETGID برای ()setgid()، setgroups
CAP_SETUID برای ()setuid

می‌توانید با اجرای این دستورات با دسترسی ریشه، قابلیت‌ها را تنظیم کنید:

export CAPS='cap_fowner=ep cap_setgid=ep cap_setuid=ep'
setcap "${CAPS}" [path-to-gpsd]

و با اجرای این دستور به عنوان یک کاربر عادی، بررسی کنید که قابلیت‌ها تنظیم شده‌اند:

getcap [path-to-gpsd]

اگر چند فرستنده NMEA به طور همزمان جملات RMC، GLL و GGA را به یک دستگاه سریال واحد ارسال کنند (که با یک مبدل RS422 متصل به برخی سامانه‌های ناوبری دریایی ممکن است رخ دهد)، یک پاسخ 'TPV' ممکن است پس از رسیدن جمله دوم، ارتفاع حاصل از جمله GGA یک دستگاه را با عرض/طول جغرافیایی جمله RMC/GLL دستگاه دیگر ترکیب کند.

برنامه gpsd ممکن است تنظیمات کنترلی روی GPS شما را تغییر دهد (مانند بسامد ارسال جملات یا بسته‌های مختلف) و هنگام خروج، تنظیمات اصلی را بازیابی نکند. این امر ناشی از نارسایی‌های پروتکل NMEA و پروتکل‌های باینری اختصاصی سازندگان GPS است که معمولاً هیچ راهکاری برای استعلام مقادیر تنظیمات کنترلی در اختیار کلاینت‌ها نمی‌گذارند تا بتوانند بعداً آنها را بازگردانند.

برخی از گیرنده‌ها مقادیر VDOP/TDOP/GDOP و برآوردهای خطای مرتبط را گزارش نمی‌کنند. در این صورت، این ارقام ممکن است توسط gpsd محاسبه شوند. این محاسبات دقیقاً با آنچه تراشه‌ها به طور داخلی انجام می‌دهند (که شامل نوعی وزن‌دهی به ماهواره‌ها با استفاده از پارامترهایی است که برای gpsd نامرئی هستند) یکسان نیست.

تنظیم خودکار نرخ باد (Autobauding) روی GPSهای Trimble در صورتی که سرعت دستگاه با سرعت GPS همخوانی نداشته باشد، می‌تواند تا ۲۰ ثانیه یا بیشتر طول بکشد. از گزینه -s برای جلوگیری از تأخیرهای مربوط به تشخیص خودکار نرخ باد استفاده کنید.

تولید برآوردهای خطای موقعیت (eph, epv, epd, eps, epc) از داده‌های ناقص ارائه‌شده توسط پروتکل‌های گزارش‌دهی GPS، هم نیازمند محاسبات پیچیده ریاضی است و هم بر فرضیات شکننده و وابسته به سخت‌افزار تکیه دارد. این بخش از کد در گذشته مستعد اشکال بوده و ممکن است هنوز مشکلاتی در آن نهفته باشد.

رمزگشایی AIDVM برای انواع ۱۶-۱۷، ۲۲-۲۳ و ۲۵-۲۶ تأییدنشده و آزمایشی است.

در حال حاضر GPSD تنها سطح ۲٫۱ از پروتکل RTCM2 را به طور کامل شناسایی می‌کند (انواع پیام‌های ۱، ۳، ۴، ۵، ۶، ۷، ۹، ۱۶). انواع پیام‌های ۲٫۳ شامل ۱۳، ۱۴ و ۳۱ شناسایی و گزارش می‌شوند. انواع پیام‌های ۸، ۱۰-۱۲، ۱۵-۲۷، ۲۸-۳۰ (تعریف‌نشده)، ۳۱-۳۷، ۳۸-۵۸ (تعریف‌نشده) و ۶۰-۶۳ هنوز پشتیبانی نمی‌شوند.

منطق ISGPS به کار رفته برای رمزگشایی RTCM2 و زیرفریم‌ها به اندازه‌ای پیچیده است که برخی از بهینه‌سازهای کامپایلر (به‌ویژه در GCC 3.x در سطح -O2) را به اشتباه انداخته و کدهای معیوب تولید می‌کند.

دستگاه‌هایی که قرار است از PPS برای زمان‌سنجی با دقت بالا استفاده کنند، در صورتی که پس از راه‌اندازی و از طریق دستور سوکت کنترل مشخص شوند (برخلاف تعیین در خط فرمان اولیه دیمن)، ممکن است با شکست مواجه شوند. امتیازات ریشه در ابتدای کار رها می‌شوند، و برخی از مشتقات یونیکس برای تنظیم خط انضباطی PPS (line discipline) به این امتیازات نیاز دارند. در لینوکس قابلیت POSIX برای تنظیم این خط انضباطی حفظ می‌شود، اما سایر بسترها نمی‌توانند از این کد استفاده کنند.

دستگاه‌های GPS مبتنی بر USB اغلب خود را از طریق زیرسیستم USB معرفی نمی‌کنند؛ آنها معمولاً به صورت کلاس 00h (تعریف‌نشده) یا کلاس FFh (وابسته به سازنده) از مبدل‌های USB به سریال ظاهر می‌شوند. به همین دلیل، اسکریپت‌های اتصال گرم لینوکس باید به gpsd اطلاع دهند تا داده‌ها را از تمام مبدل‌های USB به سریال که فعال شده و از انواع شناخته‌شده مورد استفاده در GPSها هستند شنود کند. تا زمانی که یک دستگاه به عنوان GPS شناسایی نشود هیچ رشته پیکربندی برای آن فرستاده نمی‌شود، و gpsd هرگز دستگاهی را که توسط فرایند دیگری باز شده باشد باز نمی‌کند. اما یک فرصت زمانی بسیار کوتاه برای دستگاه‌های غیر GPS بازنشده وجود دارد؛ اگر برنامه‌ای که خواهان آنهاست در رقابت زمانی با GPSD شکست بخورد، باز کردن دستگاه توسط آن ناموفق بوده و باید پس از شنود دستگاه توسط GPSD مجدداً تلاش کند (که معمولاً کمتر از یک ثانیه بعد رخ خواهد داد).

/dev/ttyS0

دستگاه TTY نمونه اولیه. پس از راه‌اندازی، اگر هیچ دستگاه GPSای در خط فرمان مشخص نشده باشد یا وجود نداشته باشد، gpsd شناسه گروهی خود را به گروه مالک این دستگاه تنظیم می‌کند.

/etc/gpsd/device-hook

پرونده اختیاری حاوی اسکریپت فعال‌سازی/غیرفعال‌سازی دستگاه. توجه داشته باشید که اگرچه /etc/gpsd دایرکتوری پیش‌فرض پیکربندی سیستم است، می‌توان کدهای منبع GPSD را با فرضیات متفاوتی کامپایل کرد. برای جزئیات بیشتر درباره سازوکار device-hook به بخش‌های بالا مراجعه کنید.

/@RUNDIR@/chrony.XXX.sock

سوکت دامنه یونیکس اختیاری ارائه‌شده توسط chronyd که با یک ساعت مرجع SOCK پیکربندی شده است، که در آن XXX نام دستگاه سریال است (مانند ttyS0). هنگامی که gpsd اجرا می‌شود، تلاش خواهد کرد به این سوکت متصل شود. در صورت برقراری اتصال، اطلاعات زمان‌بندی PPS را به منظور همگام‌سازی ساعت سیستم به chronyd ارسال می‌کند.

/@RUNDIR@/chrony.clk.XXX.sock

مشابه با chrony.XXX.sock است، اما برای انتقال اطلاعات زمان‌بندی به chronyd استفاده می‌شود که به جای PPS، از زمان‌بندی سریال (احتمالاً NMEA) مشتق شده است.

با تنظیم متغیر محیطی GPSD_SHM_KEY، می‌توانید مقدار کلید استفاده‌شده برای ایجاد قطعه حافظه مشترک مورد نیاز برای ارتباط با کتابخانه کلاینت را کنترل کنید. این ویژگی عمدتاً هنگام جداسازی نمونه‌های آزمایشی gpsd از نمونه‌های عملیاتی مفید خواهد بود.

0

در صورت موفقیت.

1

در صورت بروز خطا یا شکست.

استانداردهای رسمی پروتکل NMEA برای NMEA0183 و NMEA2000 از سوی انجمن ملی الکترونیک دریایی (NMEA) در دسترس هستند، اما انحصاری و گران‌قیمت می‌باشند؛ توسعه‌دهندگان gpsd تعمداً از مشاهده آنها خودداری کرده‌اند. وب‌سایت پروژه GPSD به چندین سند پیوند می‌دهد که اطلاعات علنی منتشرشده درباره این پروتکل را گردآوری نموده‌اند.

برنامه gpsd جملات NMEA زیر را تجزیه می‌کند: RMC، GGA، GLL، GSA، GSV، VTG، ZDA، GBS، HDT، DBT، GST. این جملات را با پیشوند استاندارد GP talker-ID، یا با پیشوند GN مورد استفاده در GLONASS، یا با پیشوند II صادرشده توسط سامانه‌های ناوبری دریایی Seahawk Autohelm، یا با پیشوند IN صادرشده توسط برخی دستگاه‌های Garmin، یا با پیشوند EC صادرشده توسط واحدهای ECDIS، یا با پیشوند SD صادرشده توسط ژرفاسنج‌ها (عمق‌سنج‌ها)، یا با پیشوندهای HC و TI صادرشده توسط تجهیزات Airmar شناسایی می‌کند. همچنین برخی افزونه‌های اختصاصی سازندگان را می‌شناسد: PGRME صادرشده توسط برخی مدل‌های GPS گارمین، PTNTHTM صادرشده توسط قطب‌نماهای دیجیتال True North، PMTK صادرشده توسط برخی GPSهای San Jose Navigation، و جملات PASHR صادرشده توسط برخی GPSهای Ashtech.

توجه داشته باشید که خروجی JSON برنامه gpsd درجات را به صورت اعشاری خالص برمی‌گرداند، نه در قالب ترکیبی درجه/دقیقه که در استاندارد NMEA آمده است.

تصحیحات تفاضلی GPS توسط پروتکل‌های RTCM منتقل می‌شوند. استاندارد مربوطه برای RTCM-104 V2 استاندارد پیشنهادی RTCM برای خدمات تفاضلی GNSS (سامانه ماهواره‌ای ناوبری جهانی) تحت عنوان RTCM Paper 136-2001/SC 104-STD است. استاندارد مربوط به RTCM-104 V3 استاندارد RTCM 10403.1 برای خدمات تفاضلی GNSS - نسخه ۳ تحت عنوان RTCM Paper 177-2006-SC104-STD است. دستورالعمل‌های سفارش استانداردهای RTCM در وب‌سایت کمیسیون فنی رادیویی خدمات دریایی در بخش "Publications" قابل دسترسی است.

سامانه AIS توسط توصیه‌نامه ITU M.1371 با عنوان مشخصات فنی برای سامانه شناسایی خودکار سراسری شناورها با استفاده از دسترسی چندگانه تقسیم زمانی تعریف شده است. قالب AIVDM/AIVDO قابل درک برای این برنامه توسط IEC-PAS 61162-100 تحت عنوان تجهیزات و سیستم‌های ناوبری دریایی و ارتباطات رادیویی تعریف شده است. شرحی در دسترس‌تر از هر دو را می‌توان در صفحه منابع وب‌سایت پروژه GPSD در بخش AIVDM/AIVDO Protocol Decoding یافت.

داده‌های زیرفریم توسط IS-GPS-200، مشخصات رابط مهندسی و یکپارچه‌سازی سامانه‌های بال GPS (IS-GPS-200) تعریف شده است. قالب قابل فهم برای این برنامه در بخش ۲۰ (پیوست II) تعریف شده است.

قالب JSON توسط RFC 7159 با عنوان قالب تبادل داده نشانه‌گذاری اشیاء جاوااسکریپت (JSON) مشخص شده است.

رابط برنامه‌نویسی برای سرویس زمان PPS توسط RFC 2783 با عنوان رابط کاربری برنامه‌نویسی پالس در ثانیه برای سیستم‌عامل‌های شبه‌یونیکس، نگارش ۱٫۰ مشخص شده است.

قابلیت‌های gpsd از استاندارد پیشنهادی اما لغوشده POSIX 1e بخش ۲۵٫۲ با عنوان Capabilities پیروی می‌کنند. به capabilities(7) مراجعه کنید.

نویسندگان: Eric S. Raymond، Chris Kuethe، Gary Miller. نویسندگان پیشین که کدهای آنها در تغییرات و بازنویسی‌های پروژه دگرگون شده است: Remco Treffcorn، Derrick Brashear، Russ Nelson.

این صفحه راهنما توسط Eric S. Raymond نگاشته شده است <esr@thyrsus.com>.

gpsctl(1), gps(1), gpsprof(1), gpsfake(1). gpscat(1), *ntpshmmon(1),

libgps(3), libgpsmm(3)

gpsd_json(5)

capabilities(7)

chronyd(8), gpsd(8), gpsdctl(8), ntpd(8)

وب‌سایت پروژه: https://gpsd.io پرسش‌های متداول (FAQ): https://gpsd.io/faq.html راهنمای سرویس زمان (Time Service HOWTO): https://gpsd.io/gpsd-time-service-howto.html مقدمه‌ای بر سرویس زمان: https://gpsd.io/time-service-intro.html

کپی‌رایت این پرونده متعلق به پروژه GPSD است
SPDX-License-Identifier: BSD-2-clause

2025-11-04 GPSD, Version 3.27.5