Construire un serveur NTP Stratum-1 Stratum-Pi – Serveur d’impression

A titre d’expérience, j’ai acheté l’un des modèles à faible coût taille de carte de crédit Framboise Pi ordinateurs, et l’ont configuré pour exécuter NTP (Network Time Protocol). J'ai également utilisé cette carte avec un récepteur GPS avec une sortie impulsions par seconde (PPS) pour Stratum-1 serveur NTP, mais comme je connais peu de Linux, il a fallu un certain temps pour atteindre cet objectif! Il y a quelques commandes utiles Linux dispersées à travers cette page. Ces notes sont presque autant pour mes propres disques pour la prochaine fois que je devrai visiter ce projet, mais j’espère qu’ils pourront vous aider. autres. Si vous voulez commencer rapidement avec les meilleurs résultats pour minimum de bruit, s'il vous plaît voir mon Raspberry Pi NTP entrée rapide page. S'il vous plaît voir aussi cette page pour des problèmes avec la version de Jessie de Linux, et avec la plus récente Raspberry Pi modèle 3. Je commence par décrire comment faire fonctionner le Raspberry Pi avec juste une connexion LAN – sans écran, clavier ou souris – un soi-disant sans tête opération. Je décris ensuite comment configurer NTP pour votre environnement, et ajout d'un récepteur GPS / PPS pour convertir votre boîte en un serveur NTP de strate-1 y compris les mises à jour du système d'exploitation nécessaires. Ensuite, je note quelques J'ai eu des problèmes avec le premier récepteur GPS que j'ai essayé et comment j'ai guéri ceux qui avaient un récepteur GPS différent pour produire un serveur NTP strate-1 consommant environ 4 watts. L'approche la plus simple avec de bonnes performances est décrite ici. Depuis le début de cette page, deux développements ont eu lieu qui facilitent quelque peu le processus – un programme a été développé qui permet l'utilisation d'un système d'exploitation non modifié en travaillant en mode utilisateur plutôt que PPS en mode noyau, et un module est maintenant disponible qui se branche directement sur l'en-tête GPIO à 26 broches du Raspberry Pi, afin non la soudure est impliquée. Mes remerciements à Folkert van Heusden et Anthony Stirk pour ces développements. Notez que le GPS Hat Adafruit utilise GPIO 4, broche physique 7, vous devrez donc changer les commandes données dans ce document. Les ajouts ultérieurs ont inclus la télécommande surveillance du serveur NTP performance, et surveillance plus générale de la framboise Pi en utilisant les fonctions standard SNMP, avec un supplément CPU Température surveillance add-on. Mon principal Framboise Page Pi peut également être d'intérêt. Notez que de bonnes performances dépendent du fait que l’unité GPS a une vue dégagée du ciel, en particulier la partie sud du ciel si vous êtes en l'hémisphère nord. Avec les anciens récepteurs GPS, cela nécessitait une installation extérieure. antenne, mais des unités plus modernes telles que celles mentionnées ici pourraient bien fonctionner à l’intérieur à condition que du ciel soit visible, peut-être au dernier étage de la bâtiment (comme je suis). Si vous avez un toit "résistant aux RF" (plombé, peut-être?!) ou certaines fenêtres avec une doublure pour arrêter la chaleur entrante, ou la construction du mur y compris le métal, vous aurez peut-être encore besoin d’une antenne extérieure, et presque certainement si vous vivez dans un sous-sol! Alors que le temps aura normalement seulement une petite effet dans le signal – par ex. forte pluie – il est possible qu'une couche de neige pourrait atténuer suffisamment le signal pour empêcher le GPS de recevoir suffisamment de signal. Le suivi des performances peut vous aider à détecter ces problèmes. (Merci à Joe, HB9DRT pour l'information sur la neige – Je n'ai vu ce problème qu'une fois ici pendant un hiver exceptionnellement froid). introduction Le Raspberry Pi est un ordinateur au format carte de crédit. disponible chez les distributeurs du monde entier. J'ai acheté un bleu attrayant boîtier et alimentation 5 V, 2 A de ModMyPi. Vous pouvez voir le fil Ethernet à gauche et la carte SD de 4 Go avec le système d’exploitation à droite, ainsi que le cordon d’alimentation micro-USB. Il existe un modèle B (illustré et utilisé ci-dessous) et un modèle A de spécification inférieure qui peut devenir disponible à un moment dans l’avenir. J'utilise le modèle B de 512 Mo, introduit à l'automne 2012.

Ci-dessous, les résultats offset avec le Raspberry Pi en trois configurations: avec des connexions WAN uniquement synchronisées sur Internet (comme pourrait trouver une situation typique de la maison), avec Connexions LAN à un serveur local de strate 1 et agissant en tant que le serveur Stratum-1 avec deux petits récepteurs GPS / PPS différents comme horloge de référence. Tout problèmes dans les données en direct sont susceptibles d'être le résultat de mon redémarrage, rendant la configuration changements, ou le signal GPS étant inférieur à la normale. La configuration NTP normale est listée ici. Comme prévu, la synchronisation depuis le réseau local produit de meilleurs résultats que depuis Internet. (WAN), et en transformant le périphérique en serveur de la strate 1, le résultat est encore plus bas. compensations. Le décalage zéro correspond à la ligne médiane du graphique, comme l'utilité que j'utilise est incapable de tracer des valeurs négatives. J'ajoute donc la moitié de la plage de l’axe Y aux valeurs réelles avant de tracer. Remarque: celles-ci les graphiques sont ne pas tous à la même échelle verticale! Décalage utilisant uniquement des serveurs Internet – échelle milliseconde La performance qui en résulte est bonne, mais cela dépendra à la fois du chargement du lien entre moi et le FAI, et la charge générale sur le réseau du FAI et l'Internet général. Les décalages seraient d’environ +/- 5 millisecondes (et donc hors échelle). une fois sur le graphique ci-dessous). Les quatre lignes ntp.conf en cours d’utilisation est indiqué sous le graphique.

Raspberry Pi # 1512 Mo, Linux / 3.2.27 + Synchronisation WANéchelle milliseconde

# Fichier de dérive pour mémoriser la fréquence d'horloge lors des redémarrages driftfile /var/lib/ntp/ntp.drift # Les serveurs pool fr.pool.ntp.org iburst

Décalage à l'aide de serveurs LAN locaux interrogés toutes les 32 secondes – échelle en microsecondes Le passage à un couplage étroit avec un serveur de strate 1 local sur le réseau local produit beaucoup mieux résultats, avec un chronométrage de l’ordre de 30 microsecondes. J'ai ajouté un deuxième graphique avec une échelle de +/- 500 microsecondes pour montrer les excursions les plus importantes.

Raspberry Pi # 1512 Mo, Linux / 3.2.27 + Synchronisation de réseau localéchelle de précision

Mêmes données mais sur unéchelle microseconde

# Fichier de dérive pour mémoriser la fréquence d'horloge lors des redémarrages driftfile /var/lib/ntp/ntp.drift # Les serveurs serveur 192.168.0.3 minpoll 5 maxpoll 5 iburst préfère serveur 192.168.0.2 minpoll 5 maxpoll 5 iburst serveur 192.168.0.7 minpoll 5 maxpoll 5 iburst pool fr.pool.ntp.org minpoll 10 iburst

Décalage à l'aide du module GPS de synchronisation Trimble Resolution-SMT Des résultats bien meilleurs sont obtenus avec un Trimble Resolution SMT Module GPS, avec sa broche PPS connectée à la broche GPIO 24 pour un mode noyau "ATOM" horloge de référence. Cette unité est un GPS "de synchronisation", avec 15 ns précision spécifiée pour le signal PPS. Chaque seconde sur le GPIO pin provoque une interruption dans laquelle l’horloge de la CPU est notée, puis utilisée par NTP pour faire des ajustements fins à la vitesse d'horloge du logiciel. le transitoires d’une amplitude de quelques microsecondes d’une durée d’une heure environ peuvent être dus à une changements de température ambiante affectant le cristal utilisé par l'horloge de la carte Générateur. Non indiqué sur le graphique, mais le décalage dû à une tâche gourmande en ressources processeur (recompilation de NTP à partir de la source, environ 25 minutes) a entraîné une excursion positive de 20 µs, suivi d'une excursion négative de 10 µs avec le refroidissement des températures et du NTP rétabli.

Raspberry Pi # 1512 Mo, Linux / 3.2.27 + Synchronisation PPS du noyauRésolution Trimble SMTchronométrage récepteur GPS

Décalage lors du passage à un module GPS NEO-6M u-blox Lors de l'utilisation d'un GPS u-blox MEO-6M module, avec sa broche PPS connectée à la broche GPIO 24 pour un mode en mode noyau "ATOM", on obtient des résultats similaires. Le transitoire au milieu du graphique est lorsqu’un deuxième appareil était connecté à la ligne 5 V de l’USB. Cette unité est un GPS de "navigation", où le PPS est spécifié à environ 100 ns, plutôt qu'un "timing" GPS – mais la différence entre les deux unités est le plus souvent masquée par les autres variations du système.

Raspberry Pi # 1512 Mo, Linux / 3.2.27 +

Synchronisation PPS du noyauModule U-blox 6Mrécepteur GPS de navigation

Plus tard, il a été remarqué que le décalage variait périodiquement, ce qui est un résultat inattendu. Ci-dessous un exemple des 19 au 21 décembre 2012, avec les moins stables période débutant le 19 décembre 2012 et se terminant le 20 décembre. Un examen plus détaillé des données de loopstats montre une période réelle d’un peu plus de 100 secondes, et il est alias par l'échantillon de 5 minutes de MRTG.

Raspberry Pi # 1512 Mo, Linux / 3.2.27 +

Synchronisation PPS du noyauModule U-blox 6Mrécepteur GPS de navigation

Pour tester, j'avais changé le récepteur GPS d'U-blox 6M à Adafruit MTK3339 module de navigation GPS, puis modifié à nouveau du module de navigation à un module GPS de chronométrage basé sur le U-blox LEA-6T, pour voir si l’oscillation était affectée. Ces changements n'a fait aucune différence ni pour l'amplitude ni pour la période de l'oscillation, et l'amplitude de l'oscillation était considérablement plus grande que ce qui serait attendu même d'un récepteur GPS "de navigation". Donc mon plus tôt Théories sur la navigation par rapport à la synchronisation, les modules GPS, le chargement USB et les E / S série le chargement était incorrect. Ce problème a finalement été résolu par un firmware mise à jour sur Raspberry Pi # 1, de la version 337601 à la version 346337.

Performance actuelle – cliquez sur un graphique pour accéder à la page de performance de chaque ordinateur. J'ai ajouté un deuxième ordinateur Raspberry Pi et j'ai maintenant les deux connectés aux deux récepteurs GPS / PPS mentionnés ci-dessus, mais avec le antennes pour ces récepteurs dans un emplacement intérieur similaire. Ci-dessous est un comparaison de la performance. Raspberry Pi # 1 est situé dans un endroit non chauffé chambre avec un mur orienté au nord. Raspberry Pi # 3 est également dans le bureau, mais situé un peu plus près d'un radiateur, fournissant les transitoires quotidiens. Mi-novembre 2013, je suis passé à un nouveau noyau qui a été compilé localement avec une option pour améliorer les performances NTP.

Raspberry Pi # 1512 Mo, Linux / 3.6.11 Synchronisation PPS en mode noyau Adafruit MTK3339récepteur GPS de navigationdans une pièce non chauffée

<! –

Raspberry Pi # 2512 Mo, Linux / 3.6.11 Synchronisation PPS en mode noyau Adafruit MTK3339récepteur GPS de navigationen environnement de bureau

->

Raspberry Pi # 3512 Mo, Linux / 3.6.11 Synchronisation PPS en mode noyauU-blox 6M navigationRécepteur GPSen environnement de bureau

Raspberry Pi # 4512 Mo, Linux / 3.6.11 Synchronisation PPS en mode noyauU-blox 5S navigationRécepteur GPSdans une pièce non chauffée

Raspberry Pi # 5512 Mo, Linux / 3.6.11 Synchronisation PPS en mode noyauCalendrier U-blox 7QRécepteur GPSen environnement de bureau

et voici une façon légèrement différente de regarder la valeur du décalage, tracer la valeur absolue du décalage, le rouge pour les décalages positifs et le bleu pour compensations négatives. Les événements transitoires tels que les redémarrages ont été supprimés.

Raspberry Pi # 1512 Mo, Linux / 3.6.11 Synchronisation PPS en mode noyau Adafruit MTK3339 la navigation Récepteur GPS dans une pièce non chauffée

<! –

Raspberry Pi # 2512 Mo, Linux / 3.2.27 + Synchronisation PPS en mode noyau Adafruit MTK3339 la navigationRécepteur GPS en environnement de bureau

->

Raspberry Pi # 3512 Mo, Linux / 3.6.11 Synchronisation PPS en mode noyauU-blox 6M navigation GPS receveur en environnement de bureau

Raspberry Pi # 4512 Mo, Linux / 3.6.11 + Synchronisation PPS en mode noyauU-blox 5S navigation GPS receveur dans une pièce non chauffée

Raspberry Pi # 5512 Mo, Linux / 3.6.11 + Synchronisation PPS en mode noyau Calendrier U-blox 7Q GPS receveur en environnement de bureau

Création d'une carte SD avec le système d'exploitation Vous pouvez acheter une carte SD avec le système d'exploitation Linux installé et prêt aller. Sachant que je devrais apporter des modifications au système d’exploitation, j’ai acheté un carte SD prête à être programmée au cas où, mais j’ai fabriqué la mienne par en suivant les étapes ici: http://www.raspberrypi.org/downloads

Téléchargez une image de système d'exploitation pour la carte SD – 2012-09-18-wheezy-raspbian.zip Décompressez le contenu de l'archive Zip dans un fichier .IMG Téléchargez le programme d'écriture de carte SD: Win32DiskImager Utilisez l’imageur de disque pour écrire l’image du système d’exploitation sur la carte SD.

J'ai ensuite branché la carte SD au Raspberry Pi, connecté au réseau, et le pouvoir appliqué …

Beaucoup de gens ont demandé d'ajouter un GPS à le Raspberry Pi sans avoir besoin de soudure, et maintenant cela est devenu une réalité grâce à la NTPI GPS Addon Board produit par Nevis Computers Ltd au Royaume-Uni. J'ai utilisé le rpi_gpio_ntp programme a été développé par Folkert van Heusden et annoncé dans la liste de diffusion Time-Nuts, qui permet de travailler en mode utilisateur avec PPS signal, ne nécessitant donc pas de version spéciale du système d’exploitation. Les versions actuelles de Raspbian n'en ont plus besoin. C’est ce que vous obtenez dans la boîte du GPS NTPI Raspberry Pi Carte d'extension (avec l'option antenne puck):

Une carte avec le périphérique GPS de qualité de synchronisation et le connecteur SMA qui se branche sur le connecteur GPIO à 26 broches du Pi. Un optionnel antenne GPS à rondelle magnétique, ou vous pouvez utiliser votre propre antenne avec un connecteur SMA. Vous aurez peut-être également besoin de: Une pile de secours CR2032, qui s’ajuste sur la face inférieure de la carte.

(Notez que l’antenne est une option supplémentaire et que vous devez acheter votre propre batterie) Pour que cela fonctionne avec un Raspberry Pi, voici les étapes que je a pris. J'ai inclus les étapes pour ajouter la surveillance MRTG et le fichier distant accès à partir de systèmes Windows, mais vous pouvez les omettre si vous n'en avez pas besoin.

Configurer mon routeur pour réserver une adresse IP au Raspberry Pi Modification du nom de l'appareil – Comment à. NTP configuré pour utiliser la directive pool, permettre la surveillance à distance, et bûche statistiques. NTP mis à jour pour le développement actuel version (j'ai utilisé une copie FTP d'un autre Pi). Configurez les E / S série sur le Tarte aux framboises. Gpsd installé et configuré et ses utilitaires. NTP configuré pour utiliser la mémoire partagée pendant un temps approximatif (type de pilote 28.0). Installé les outils PPS (sudo apt-get install pps-tools) Installé le rpi_gpio_ntp programme de Folkert van Heusden (seulement pour très tôt Raspbian versions). NTP configuré pour utiliser le partagé mémoire pour PPS (type de pilote 28.1). SNMP installé et configuré divers collecteurs de données MRTG (facultatif). SNMP configuré pour surveiller la CPU Température (optionnel). SAMBA installé, pour que je puisse accéder aux statistiques NTP à partir du PC (facultatif). Configurer le PC pour la mise en réseau sans fil Clé USB Wi-Fi (en option).

Installé sur le Raspberry Pila carte ressemble à ceci. lele fil d'antenne peut être retiréà travers un trou dans le boîtier près du connecteur Ethernet. Notez que cette carte utilise GPIO 18 pour son signal PPS, donc tout logiciel doit être configuré de manière appropriée.

Vous pouvez demander à quel point ce mode utilisateur fonctionne correctement. bien c'est plutôt bien, mais pas assez aussi bon que le mode noyau, mais plus que suffisant pour la précision offerte par le Raspberry Pi. Peut-être le mieux que le Pi pourrait faire sinon serait la synchronisation via une connexion LAN à un Stratum-1 serveur NTP. La comparaison de tracé ci-dessous montre le Pi synchronisé sur un serveur de strate-1 mais sur Wi-Fi, puis sur les performances après l'installation le panneau d'addition GPS NTPI. Un terrain idéal serait une ligne droite à la Niveau 500 microsecondes sur ce graphique (je dois ajouter un décalage car MRTG ne peut pas tracer nombres négatifs). La gigue moyenne sur 6 heures rapportée par NTP est passée de 100-150 microsecondes à moins de 4 microsecondes. L'amélioration de la marche de la synchronisation Wi-Fi à la synchronisation PPS, c'est évident!

Mise à jour vers la dernière version de Raspbian Linux La version de Linux que vous utilisez est affichée lorsque vous vous connectez, mais vous peut également utiliser la commande: $ uname -a pour montrer quelle version est en cours d'exécution. J'ai commencé avec: Linux raspberrypi 3.12.26+ # 702 PREEMPT Wed Aug 6 17:43:49 BST 2014 armv6l GNU / Linux Pour mettre à jour mon logiciel, j'ai exécuté les commandes: $ sudo apt-get update $ sudo apt-get dist-upgrade $ sudo rpi-update et après le redémarrage, j'ai terminé par: Linux raspberrypi 3.12.32+ # 721 PREEMPT Fri Nov 7 16:50:31 GMT 2014 armv6l Configuration de Linux pour PPS sur le port GPIO Grâce aux courriels de Olav Andrarde et Timo Kokkonen, j'ai découvert que Le support PPS a été ajouté à Linux disponible pour le Raspberry Pi, bien que vous ayez besoin d'ajouter quelques lignes à la configuration pour l'activer. Comme Raspbian évolue continuellement, la méthode exacte pour effectuer ces changements évolue également, donc en fonction du moment où vous avez téléchargé Raspbian, vous devez suivre soit le novembre 2014 ou le février 2015 sections ci-dessous. J'ai mis les informations les plus récentes en premier, bien que je préfère normalement que les choses soient énumérées dans l’ordre chronologique, comme dans un journal intime! Versions Raspbian vers février 2015 Après avoir mis à jour un autre Raspberry Pi vers le dernier Raspbian – pour un nouveau Raspberry Pi 2 que j'avais acheté – j'ai découvert que les choses avaient changé une fois encore. Ces détails de mon démarrage rapide page. Versions de Linux: 3.18.6+ 3.18.7-v7 $ sudo nano /boot/config.txt – Ajouter dtoverlay = pps-gpio, gpiopin = 18 sur une nouvelle ligne. Si vous avez précédemment ajouté bcm2708.pps_gpio_pin = 18 à la fin de cmdline.txt, supprimez-le. Sauver et fermer. $ sudo nano / etc / modules – Ajouter pps-gpio sur une nouvelle ligne. Enregistrez, fermez et redémarrez. Maintenant, vérifiez que PPS fonctionne. Versions Raspbian vers novembre 2014 Pour activer PPS sur le port GPIO, vous devez suivre deux étapes: l’une pour indiquer au noyau pour inclure le support, et un pour amener le module de support à être chargé. Tout d’abord, indiquez au noyau que la broche 18 de GPIO doit être utilisée. Cela active la prise en charge de PPS-GPIO dans le noyau. Ajouter ce texte au Fichier /boot/cmdline.txt: $ sudo nano /boot/cmdline.txt ajouter: bcm2708.pps_gpio_pin = 18 à la fin de la ligne. Ce doit être sur le même ligne, pas sur un Nouveau ligne, comme l'a découvert Ray Hunter! Ensuite, vous devez dire au noyau de charger le module qui fournit cette information. soutien. Pourquoi cela ne peut pas être automatique, je ne sais pas! Ajouter le nom du module à la fin du fichier / etc / modules. $ sudo nano / etc / modules ajouter: pps-gpio à la fin si la liste, et redémarrez. Vérifier que PPS fonctionne Pour vérifier que le module est chargé, vous pouvez utiliser la commande lsmod, par exemple exemple: $ lsmod | grep pps La sortie devrait être semblable à: pps_gpio 2529 1 pps_core 7943 2 pps_gpio Vous devriez maintenant pouvoir exécuter la commande ppstest et voir les transitions une fois par seconde, par exemple: $ sudo ppstest / dev / pps0 # appuyez sur Ctrl-C pour annuler .. essayer le source PPS "/ dev / pps0" a trouvé la source PPS "/ dev / pps0" ok, trouvé 1 source (s), commencez maintenant à récupérer les données … source 0 – assert 1351501153.999956346, séquence: 47481 – effacer 0,000000000, séquence: 0 source 0 – assert 1351501154.999954601, séquence: 47482 – effacer 0,000000000, séquence: 0 source 0 – assert 1351501155.999951856, séquence: 47483 – effacé 0,000000000, séquence: 0 ^ C

Notez qu'il n'y a pas de valeur donnée pour le temps "clair". Gary E Miller rapporte que le pilote pps-gpio ne cherche qu’un seul avantage, le positif bord allant. Si vous utilisez un appareil GPS différent de ceux mentionnés Dans ce cas, vous aurez peut-être besoin d’un onduleur de sortie de 3,3 volts dans la ligne PPS du GPS.

L'approche de Hauke Lampe Uniquement des informations historiques: Depuis que j'ai écrit cette page pour la première fois, Hauke Lampe a disponible une image préconfigurée de Raspberry Pi OS ici. Son article est basé sur sa version d’un GPS série comme je le décris ici, mais vous devez le faire. aucun des travaux de construction et de configuration que je mentionne ici. Ma framboise La Pi # 3 fonctionne à partir de cette image de système d'exploitation et je développe l'installation GPS à l'adresse le moment. Les commentaires et les changements jusqu'à présent:

Modification de l'adresse IP du port Ethernet en un numéro fixe adresse (statique) – Comment à.Remarque: Si vous faites cela, vous devrez peut-être éditer le fichier hosts sur votre ordinateur. systèmes pour permettre l'accès à l'appareil par nom plutôt que par IP adresse. Ajouter une ligne telle que: 192.168.0.51 framboise-pi-1 au fichier (avec l'adresse et le nom de votre RPi, bien sûr). Sur Windows-8, notez que Windows Defender peut essayer de remplacer un hôte modifié fichier avec celui par défaut, supprimant ainsi vos modifications! Sous Windows, le Le fichier à modifier est Windows system32 drivers etc hosts, et vous devrez peut-être Accès de niveau administrateur pour éditer ce fichier. Modification du nom de l'appareil – Comment à. NTP configuré pour utiliser la directive pool, permettre la surveillance à distance, et bûche statistiques. SNMP installé et configuré divers collecteurs de données MRTG. SAMBA installé, pour que je puisse accéder aux statistiques NTP à partir du PC. Configurer le PC pour la mise en réseau sans fil avec un ancien NetGear Clé USB Wi-Fi (remplacée plus tard par une unité Edimax).

Quelques utilitaires "standard" de Raspberry Pi ne sont pas présents dans cette image de système d'exploitation, et devront être téléchargés séparément avec apt-get. Voici à quoi cela ressemble pour le moment. L'antenne patch est attaché au ModMyPi blanc avec du ruban adhésif double face, et la carte réceptrice avec un écrou simple et boulon. Les dérivations provenaient également de ModMyPi et la longueur de 150 mm n’est pas nécessaire ici! Le dongle Wi-Fi est à gauche. Graphiques de performance sont ici.

Comme mon application d’essai est pour un serveur NTP, je n’ai pas besoin de afficher sur le Raspberry Pi, ou d'ailleurs un clavier et une souris connectés en permanence. Tous mes l'interaction se fera via un terminal, et même cela sera émulé via programme fonctionnant sur un ordinateur distant, avec une connectivité via le port Ethernet du Tarte aux framboises. Une telle opération est communément appelée un serveur sans tête. Un bloc d'alimentation et un boîtier sont les seuls éléments que j'ai ajoutés au Raspberry fourni Pi. Il y a quelques conseils pour courir sans tête ici: http://glynrob.com/hardware/raspberry-pi-headless/ Vous avez besoin d’un programme terminal qui fonctionnera en mode SSH – I mastic utilisé sur un PC Windows XP. J'ai regardé sur mon routeur qui exécute DD-WRT pour voir l'adresse IP qui avait été affecté au Pi, et j'ai ensuite utilisé cette adresse pour exécuter PUTTY en mode SSH. J'ai tout de suite une connexion avec l'utilisateur par défaut nom et mot de passe. Vous pouvez enregistrer les paramètres du Pi depuis PUTTY. (J'ai appelé le mien "RaspberryPi"), et fais un raccourci Windows pour se connecter à votre Pi avec des valeurs telles que:

Cible: C: Tools PuTTY PUTTY.EXE -load RaspberryPi Commencez dans: C: Tools PuTTY

Votre chemin d'accès et le nom des paramètres enregistrés seront différents. Commande Linux pour se déconnecter et se déconnecter: se déconnecter Au fait, en ajoutant un serveur X-windows programme tel que Xming sur votre PC, vous pouvez voir les graphiques du Raspberry Pi aussi, si vous voulez, mais c'est ne pas nécessaire pour les opérations décrites ici – vous pouvez tout faire directement à partir de la ligne de commande. Mise à jour du système d'exploitation J'ai suivi le conseil ici pour mettre à jour le système d'exploitation, bien que je ne pense pas que c'était vraiment nécessaire car le système d'exploitation téléchargé n'avait qu'un mois. Pour exécuter les commandes nécessite des privilèges accès, obtenu ici en préfixant la commande avec sudo. L’exécution de ces commandes prend beaucoup de temps et nécessite un accès Internet depuis votre Pi. Prévoyez 30 à 45 minutes.

$ sudo apt-get update

$ sudo apt-get dist-upgrade

Vous devrez probablement redémarrer le système d'exploitation après avoir apporté les modifications suivantes:

$ sudo reboot

Si vous souhaitez déterminer quelles mises à niveau sont en attente, essayez:

$ sudo apt-get --just-print upgrade

et redirigez la sortie vers un fichier texte. Merci à Graham dans le comté de Durham, au Royaume-Uni, pour ce conseil. Réglage du fuseau horaire Vous voudrez peut-être vérifier que le Raspberry Pi est configuré pour vous donner l'heure dans votre fuseau horaire local: Utilisez la commande:

$ sudo dpkg-reconfigure tzdata

et sélectionnez la région et la ville appropriées. Pour le Royaume-Uni, J'ai choisi l'Europe / Londres. La procédure reflétera les données du fuseau horaire et date et heure actuelles à l'heure locale et à l'heure UTC à la fin. Bien qu’il existe une interface graphique avec laquelle configurer le Wi-Fi, cela ne semblait pas fonctionner pour moi. En tout cas, si vous fonctionnent sans tête, vous pouvez même ne pas avoir accès à l'interface graphique. le adaptateur réseau que j'ai utilisé était l'adaptateur USB nano sans fil 150Mbps Edimax EW-7811UN unité, que j'ai reçu d'Amazon (juste prix et bonne livraison). Il semble y avoir trois étapes:

Convertissez le mot de passe Wi-Fi en chaîne hexadécimale (cela peut être optionnel): $ sudo wpa_passphrase VotreSSID Votre mot de passeVous obtiendrez un résultat hexadécimal tel que "b7d90db3ddbd11d5ddb3dbfd81de" dont vous aurez besoin plus tard. Editez le fichier /etc/wpa_supplicant/wpa_supplicant.conf $ sudo nano /etc/wpa_supplicant/wpa_supplicant.confpour le faire ressembler à ceci: ctrl_interface = DIR = / var / run / wpa_supplicant GROUP = netdevupdate_config = 1réseau = {ssid = "YourSSID"proto = WPA RSNscan_ssid = 1key_mgmt = WPA-PSKpaire par paire = CCMP TKIPgroupe = CCMP TKIPpsk = b7d90db3ddbd11d5ddb3dbfd81deNotez que le ssid doit être entre guillemets.

Editez le fichier / etc / network / interfaces $ sudo nano / etc / network / interfacespour le faire ressembler à ceci: auto lo iface lo inet loopbackiface eth0 inet dhcp allow-hotplug wlan0auto wlan0iface wlan0 inet dhcpWireless-Essid YourSSIDpre-up wpa_supplicant -B w -D wext -i wlan0 -c /etc/wpa_supplicant/wpa_supplicant.confKillall -q wpa_supplicant iface default inet dhcp

Vous pouvez ensuite utiliser le $ sudo ifdown wlan0 et $ sudo ifup wlan0 commandes à redémarrez le réseau sans fil. Je conseillerais également un redémarrage pour assurer que tout s'est passé comme prévu. Comment éditer la configuration NTP Le fichier de configuration NTP réside dans le répertoire / etc, de sorte que vous peut changer dans ce répertoire pour éditer le fichier. Parce que le fichier est un fichier système, vous devez sudo commande permettant de sauvegarder la version modifiée du fichier, mais d’abord, j’ai fait une copie (cp) du fichier fourni juste au cas où je me suis planté et a dû revenir à la configuration de travail NTP. J'ai utilisé le vi éditeur qui est fourni avec le système d'exploitation, et il y a des instructions pour vi ici, et aussi à Guru99.com dans le cadre d'un Linux / Unix tutoriel pour débutants. le nano éditeur que j’ai découvert plus tard, et qui est fourni avec le Raspberry Pi, est un bien meilleur choix – beaucoup plus facile à utiliser!

$ cd / etc

$ sudo cp ntp.conf ntp-original.conf

$ sudo nano ntp.conf

Je voulais pouvoir surveiller NTP depuis un autre PC sur mon réseau local, plutôt que d’ajouter le programme de surveillance MRTG au Pi, mais il existe des lignes qui limitent l’accès au NTP fonctionnant sur le Pi par défaut installation. Ces lignes du fichier ntp.conf commencent par le mot clé "restreindre". J'ai supprimé ces restrictions en les commentant lignes – ce qui est réalisé en ajoutant un caractère de hachage au début de la ligne. Par exemple:

Remplacer: restreindre -4 par défaut kod notrap nomodify nopeer noquery

Avec: # restreint -4 par défaut kod notrap nomodify nopeer noquery

Après avoir modifié ntp.conf, vous devez redémarrer le démon ntp:

$ sudo /etc/init.d/ntp restart

Si la sécurité sur votre réseau vous préoccupe, vous pouvez souhaite être plus sélectif en modifiant les restrictions. Bien que le contenu par défaut de ntp.conf fonctionne correctement Dans la plupart des cas, ils ne profitent pas de la nouvelle directive NTP POOL pour spécifier les serveurs de pool. J'ai également modifié le pool générique "debian" à la piscine plus locale "UK". J'ai donc changé le serveur bassin. lignes à une directive de pool unique:

Remplacer: serveur 0.debian.pool.ntp.org iburst serveur 1.debian.pool.ntp.org iburst serveur 2.debian.pool.ntp.org iburst serveur 3.debian.pool.ntp.org iburst Avec: pool fr.pool.ntp.org iburst

Mon propre réseau local possède trois serveurs NTP de strate 1, un sur FreeBSD et deux exécutant Windows, alors j'ai ajouté ceux avant les serveurs de la piscine. Bien sûr, cela est spécifique à mon réseau local. Pour l'offset minimum, j'ai fait interroger NTP les serveurs locaux à 32 secondes (2 ^^ 5) intervalles, et n'a pas permis que cela dérive vers le haut vers les 1024 secondes intervalle maximum que NTP atteindrait laissé à ses propres périphériques. j'ai fait ça avec les qualificatifs minpoll et maxpoll. Cependant, je ne voulais pas forcer les serveurs Internet à interroger que souvent (on considère au mieux au pire pourrait vous faire bloquer par un serveur), alors j'ai donc fait l'intervalle d'interrogation minimal pour les serveurs Internet, 1024 secondes (2 ^^ 10). J'ai enlevé les choses qui avaient été commentées pour simplifier le fichier, et le rendre plus facile à comprendre. C'est pourquoi mon fichier ntp.conf s'est terminé comme suit:

# /etc/ntp.conf, configuration pour ntpd; voir ntp.conf (5) pour obtenir de l'aide

# Fichier de dérive pour mémoriser la fréquence d'horloge lors des redémarrages driftfile /var/lib/ntp/ntp.drift

# Les serveurs serveur 192.168.0.3 minpoll 5 maxpoll 5 iburst préfère serveur 192.168.0.2 minpoll 5 maxpoll 5 iburst serveur 192.168.0.7 minpoll 5 maxpoll 5 iburst pool fr.pool.ntp.org minpoll 10 iburst

N'oubliez pas de redémarrer NTP après avoir apporté les modifications. De PC de surveillance Windows avec NTP installé Je vois maintenant:

C: > ntpq -p raspi référence distante st t lorsque l'interrogation atteint le décalage de retard de gigue =============================================== ============================ * pixie .PPS. 1 u 26 32 377 0,467 -0,010 0,023 + feenix .PPS. 1 u 4 32 377 0,603 -0,226 0,039 + stamsund .PPS. 1 31 31 377 0,586 0,004 0,040 -dns0.rmplc.co.u 193.62.22.74 2 707 1024 377 21.915 3.490 2.295 -dns1.rmplc.co.u 193.62.22.74 2 u 177 1024 377 23.736 4.609 3.621 -dawn.rt.uk.eu.o 193.79.237.14 2 277 1024 377 20.508 3.150 3.065 -lyla.preshweb.c 129.215.42.240 3 u 544 1024 377 28.082 5.937 3.944

C: > ntpq -c rv raspi associd = 0 status = 0615 leap_none, sync_ntp, 1 événement, clock_sync, version = "ntpd 4.2.6p5@1.2349-o ven. mai 18 20:30:57 UTC 2012 (1)", processeur = "armv6l", système = "Linux / 3.2.27 +", saut = 00, strate = 2, precision = -20, rootdelay = 0.467, rootdisp = 2.387, refid = 192.168.0.3, reftime = d4365966.98133154 sam., 27 oct. 2012 14: 00: 22.594, clock = d4365984.f4e4138b sam. 27 oct. 2012 14: 00: 52.956, homologue = 49569, tc = 5, mintc = 3, offset = -0,010, fréquence = -43,888, sys_jitter = 0,023, clk_jitter = 0.015, clk_wander = 0.008

Une approche pour que le NTP voie la partie série du flux de sortie du récepteur GPS (pour la partie grossière du temps, les secondes) est d'installer le pilote gpsd, et cela permet une vérification de la base connectivité. Le GPS que j'ai commencé à utiliser était un Trimble Resolution SMT, pour lequel j'ai réussi à obtenir à la fois une carte d'évaluation et une carte d'interface converti la sortie série en RS-232 et USB. J'ai utilisé le feuilleton via USB plutôt que le RS-232 pour le Raspberry Pi.

C'est le GPS que j'ai utilisé. Il est une carte d’évaluation pour un récepteur de synchronisation GPS monté en surface, le Trimble Resolution SMT. C'est un peu inhabituel d'avoir un format TSIP sortie plutôt que le format NMEA standard, mais le gpsd Linux peut reconnaître et accepter ce format. La sortie est sur un en-tête à 8 broches avec un non standard espacement des broches! Il est assez sensible pour utiliser un support magnétique. Rondelle GPS dans ma salle informatique à l'étage supérieur.

Juste comme j'ai acquis le conseil, il y avait une offre sur la liste de diffusion time-nuts pour un interface prête à l'emploi. Cela a un connecteur correspondant à 8 broches, et fournit une sortie PPS, une sortie série aux niveaux RS-232 (non utilisé ici) et dispose d'un convertisseur série-USB intégré! Idéal! Faites attention en utilisant d’autres unités GPS que vous n’aurez pas dépasser +3,3 V sur le signal PPS transmis au Raspberry Pi, sous forme de signal 5 V niveau sera dommage le dispositif. J'ai utilisé un diviseur résistif (non représenté) pour réduire le niveau à une valeur nominale de 3,2 V. J'ai soudé un diviseur résistif 3k9 * + 6k8 au PPS en-tête, puis a soudé un câble double alimenté en un en-tête de 0,1 pouce que j’ai eu à traîner. Je l'ai connecté à des broches GND et GPIO-24 sur le 26 broches Raspberry Pi GPIO entête.* – incorrectement donné comme 1k0 plus tôt.

Tout d’abord, j’ai connecté l’appareil au port USB inférieur, puis vérifié ce qui était vu sur les ports USB.

$ sudo lsusb Périphérique de bus 001: ID 1d6b: 0002 concentrateur racine Linux Foundation 2.0 Bus 001 Appareil 002: ID 0424: 9512 Standard Microsystems Corp. Bus 001 Appareil 003: ID 0424: ec00 Standard Microsystems Corp. Dispositif de bus 001 005: ID 04d8: 00df Microchip Technology, Inc.

Il semble que mon GPS apparaisse sous le numéro 005 dans cette liste, mais comment sera-t-il nommé? Pour vérifier cela, vous devez parcourir l’un des Fichiers journaux Linux:

$ more / var / log / syslog

et dans mon cas, au moment où j'ai branché l'appareil là-bas était une référence à: ttyACM0:et j'ai reconnu tty comme un port série (TeleType d'il y a longtemps!). Si vous utilisez un vrai périphérique série, il apparaîtra comme ttyAMA0. Les prochaines étapes sont à installez le logiciel gpsd et démarrez le service gpsd pointant sur l'appareil nom vient de découvrir:

$ sudo apt-get installez gpsd gpsd-clients python-gps

À partir d'un rapport que j'ai reçu, si vous rencontrez des erreurs avec l'étape ci-dessus, vous devrez peut-être exécuter une mise à jour vers apt-get: $ sudo apt-get update et éventuellement alors: $ sudo apt-get upgrade qui peut mettre à niveau l'ensemble du système d'exploitation vers la version actuelle.

$ sudo gpsd / dev / ttyACM0 -n -F /var/run/gpsd.sock

À ce stade, vous devriez pouvoir voir une sortie en mode texte depuis votre récepteur GPS en exécutant la commande "cgps -s", quelque chose comme ce qui suit.

$ cgps -s

Notez qu’il s’agit d’un GPS en mode chronométrage, il préférera satellites qui ont une altitude plus élevée, car ceux-ci sont moins susceptibles d'avoir effets multi-chemins ou réflexions. Cependant, pour le niveau de précision de que nous visons (microsecondes, pas nanosecondes), ce raffinement n’est pas essentiel, et je ne pouvais voir aucune différence significative entre un "timing" GPS and a "position" GPS on the microsecond level. Note that you will need to make gpsd start automatically at boot time, and to tell the configuration tool what device to use, and add the "-n" option for working with NTP. See the note later in this document. Telling NTP the seconds from the GPS Now that gpsd is working, we can edit the NTP configuration to add a type 28 reference clock which will make NTP look at the shared memory created by gpsd. This can be done for both the coarse time (seconds) and the fine time (PPS edge) with a 28.0 and a 28.1 driver, although I only use the 28.0 driver here as the Raspberry Pi supports PPS via a kernel-mode driver (more later). The first step is to get the seconds alone, and be aware that this will ne pas be better than Internet time alone due to the offset of the serial/USB data from the true second, and because of the variability and drift in this offset. We will need to add a connection later between the PPS signal and one of the Raspberry Pi's I/O pins to generate a PPS interrupt. Here is my modified ntp.conf file. I've used 0.000 for the time1 modifier to start with, so that we can determine an approximate value for the delay of the serial data from the GPS after ntp is up and running. I changed the refid for the type 28 driver to "SHM" to indicate more clearly that the data is coming from the SHared Memory provided by gpsd. Note that I have marked more than one server as "prefer". This is because if the first preferred server goes offline, it appears that NTP will no longer accept the PPS data as valid (is that wise?), so a second preferred server is configured to cover that possibility. In my case, it happens because 192.168.0.3 sometimes has an NTP update, causing its NTP to go offline for some seconds, and hence causes a glitch in the connected servers. Having more than one preferred server should prevent that.

# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help # Drift file to remember clock rate across restarts driftfile /var/lib/ntp/ntp.drift # Server from shared memory provided by gpsd server 127.127.28.0 minpoll 4 maxpoll 4 prefer fudge 127.127.28.0 time1 0.000 refid SHM stratum 15 # Local LAN servers server 192.168.0.3 minpoll 5 maxpoll 5 iburst prefer server 192.168.0.2 minpoll 5 maxpoll 5 iburst prefer server 192.168.0.7 minpoll 5 maxpoll 5 iburst prefer # UK pool servers pool uk.pool.ntp.org minpoll 10 iburst

Note that when using a PPS source you doit have one other server marked "prefer". In the example above I have added prefer to the shared memory driver (type 28) so that the combination of PPS and GPSD would provide the correct time even with no Internet servers. Looking at the output from ntpq -p after some time we might see:

C:>ntpq -p raspi remote refid st t when poll reach delay offset jitter ============================================================================== xSHM(0) .SHM. 15 l 15 16 377 0.000 -353.23 1.277 *pixie .PPS. 1 u 25 32 377 0.484 -0.016 0.105 +feenix .PPS. 1 u 31 32 377 0.592 -0.120 0.044 +stamsund .PPS. 1 u 16 32 377 0.546 -0.037 0.083 xns0.luns.net.uk 157.44.176.4 2 u 1656 1024 156 31.904 3.702 5.455 xtime.videxio.ne 131.188.3.223 2 u 45m 1024 74 31.765 8.590 2.796 xlyla.preshweb.c 129.215.42.240 3 u 510 1024 377 25.568 4.793 5.990 -dawn.rt.uk.eu.o 193.67.79.202 2 u 492 1024 367 20.308 2.408 2.903

and while the SHM driver is present and connected (reach = 377), it has been rejected by NTP (the "x" in the first column), perhaps because its offset was consistently too great compared to the other servers. That's the purpose of the time1 modifier in the "fudge" commander. We can see that the SHM output is some 350 milliseconds later, so we can use that value for time1 to bring the GPS output approximately into line with UTC, as shown in the edited /etc/ntp.conf below. (The time values in the ntpq -p display are all in milliseconds). Hint: if at this point the reach field for the SHM device stays at zero, likely the gpsd wasn't started with the "-n" option. You can make the gpsd always start at system boot time with that -n option as described later in this note.

# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help # Drift file to remember clock rate across restarts driftfile /var/lib/ntp/ntp.drift # Server from shared memory provided by gpsd server 127.127.28.0 minpoll 4 maxpoll 4 fudge 127.127.28.0 time1 +0.350 refid SHM stratum 15 # Local LAN servers server 192.168.0.3 minpoll 5 maxpoll 5 iburst prefer server 192.168.0.2 minpoll 5 maxpoll 5 iburst server 192.168.0.7 minpoll 5 maxpoll 5 iburst # UK pool servers pool uk.pool.ntp.org minpoll 10 iburst

The output from ntpq -p then shows the offset for the SHM driver to be much nearer to zero, and this /might/ be good enough for you if you are out in the field with no other reference. But we can do better, and the next step is to use the precise PPS signal from the GPS to improve the accuracy down to the microsecond level.

C:>ntpq -p raspi remote refid st t when poll reach delay offset jitter ============================================================================== -SHM(0) .SHM. 15 l 1 16 17 0.000 1.766 0.943 *pixie .PPS. 1 u 13 32 3 0.421 -0.325 0.194 +feenix .PPS. 1 u 13 32 3 0.528 -0.644 0.969 +stamsund .PPS. 1 u 11 32 3 0.409 -0.336 0.145 -dns0.rmplc.co.u 195.66.241.2 2 u 35 1024 1 22.872 3.604 5.037 -mail1.itdojo.or 10.10.120.2 2 u 34 1024 1 38.472 3.324 7.084 ntp.fundamental 193.62.22.82 2 u 33 1024 1 30.980 2.450 3.837 82.113.154.206 193.62.22.82 2 u 32 1024 1 19.219 0.683 5.880

Note: if you are working stand-alone, without any Internet servers, you may need an extra "flag1 1" in the fudge for the type 28 ref-clock. Please see the notes here for further information. Thanks to Whitham D. Reeve Anchorage, Alaska USA for the testing. But my time is 16 seconds out! I did notice with the GPS unit that I have that it doesn't have battery backup, so when it first starts it has to download quite a lot of data from the GPS satellites before it has full lock. While the PPS signal is acquired quite quickly, it takes a few minutes for the receiver to determine the number of seconds offset between GPS-time GPST) and the usual UTC. As I write, that GPST-UTC offset is 16 seconds – the offset is because recent leap-seconds are not applied to GPS time – plus information. The implications of this are different depending on what other servers you have configured in your ntp.conf file

If you have some Internet or LAN servers, ntp is clever enough to ignore the obvious "bad chimer", and may simply display a large offset for the GPS in the ntpq -p output when starting up. Après a few minutes, the offset will revert to the correct value. The delay is not a problem in this case. If you have no other source than the GPS, then you should probably wait a few minutes before assuming that even the coarse seconds part of the time is correct. I haven't checked how long it will take NTP to step the clock by the 16 seconds needed after the GPS starts sending UTC rather than GPS time. If your GPS does this, consider adding some sort of battery backup so that the GPS-UTC offset is stored while the unit is down.

Quite why I saw this issue while using gpsd is uncertain. Since writing the above I have been in contact with the auteur de gpsd who tells me that protection is incorporated into the gpsd software whereby it will not pass on the time to its shared memory until the output from the GPS receiver has a (GPST-UTC) value in excess of 10 seconds. So I should never have seen the 16 seconds faster value at all. Please note that this problem is likely peculiar to my particular GPS receiver – an evaluation board with no battery backup. Just be aware of this problem in case it bites you! It doesn't happen with the u-blox pure serial GPS receiver I describe later, as this board has battery backup. "Your mileage may vary", as they say! The next step was to get the PPS working. This requires updating the Linux kernel for the Raspberry Pi, and while you can do that yourself, there is a ready-made kernel image and support modules available on the Web. Much of the information below is based on David K's Web page: https://github.com/davidk/adafruit-raspberrypi-linux-pps You can check the version of the kernel you are running at the moment by:

$ uname -a Linux raspberrypi 3.2.27+ #250 PREEMPT Thu Oct 18 19:03:02 BST 2012 armv6l GNU/Linux

First you need to get the updated kernel image and modules. At the time of writing, these were available for the current version of the OS from chrisprt as mentioned here: Kernel image: https://docs.google.com/open?id=0BznvtPCGqrd3ZElKZHEtUDRpUEUModules: https://docs.google.com/open?id=0BznvtPCGqrd3VTZ2TmxFTktYM0E These come down as Zip files and, as I wasn't sure about downloading these from Google Docs directly on the Raspberry Pi, I downloaded them to a local Windows FTP server first, and then installed an FTP client on the Raspberry Pi to drag the Zip files across in FTP image mode – i.e. binary files.

# Installing an FTP client: $ sudo apt-get install ftp

I could then use standard FTP command to drag the files from my local FTP server to the Raspberry Pi. I created a directory named pps below the home user directory for the files, and then unzipped the archives I had copied:

$ mkdir pps

$ cd pps

# FTP get 3.2.27-pps-g965b922-dirty.zip in binary (image) mode. # FTP get kernel-pps-gpio24.zip in binary (image) mode (substitute your own commands here).

$ unzip kernel-pps-gpio24.zip

$ unzip 3.2.27-pps-g965b922-dirty.zip

In the pps/kernel-pps-gpio24 directory you will find a file kernel-pps-gpio24.img. This must be renamed and moved to the /boot/ directory, while we first take a safety copy of the original kernel image.

$ sudo mv /boot/kernel.img /boot/kernel.img.orig

$ sudo cp kernel-pps-gpio24.img /boot/kernel.img

Now we need to move the module files into the area where the new kernel expects to find them. I found the command on the Web page either confusing or wrong, as I ended up with the wrong structure to start avec. What it appears to need is:

/lib/modules/3.2.27+ /lib/modules/3.2.27+/kernel /lib/modules/3.2.27+/modules.* /lib/modules/3.2.27-cutdown+ /lib/modules/3.2.27-cutdown+/kernel /lib/modules/3.2.27-cutdown+/modules.* /lib/modules/3.2.27-pps-g965b922-dirty /lib/modules/3.2.27-pps-g965b922-dirty/kernel/ /lib/modules/3.2.27-pps-g965b922-dirty/modules.*

You will find both the kernel directory and the modules files in the unzipped 3.2.27-pps-g965b922-dirty directory, so the following command may work correctly for you. I made a mess of this having followed the Web page verbatim, and not having made allowances for the differences in the file Nom. Assuming you are now in the pps directory, move the required files to the /lib/modules directory, and add the pps-gpio module to the module list:

$ sudo mv 3.2.27-pps-g965b922-dirty /lib/modules/3.2.27-pps-g965b922-dirty

$ echo "pps-gpio" | sudo tee -a /etc/modules (Command corrected, thanks Matthew Huxtable! Alternatively edit /etc/modules using the nano editor to add the pps-gpio at the end. $ sudo nano /etc/modules

$ sudo reboot

You will see the changed kernel name at the next login, and you can check with the uname -a command as before:

$ uname -a Linux raspberrypi 3.2.27-pps-g965b922-dirty #1 PREEMPT Sat Sep 22 16:30:50 EDT 2012 armv6l GNU/Linux

An aside – what is a module in Linux?

You may be used to the idea of device drivers for Windows – those .SYS files – but what are "modules" in Linux and how do they relate to device drivers? I asked that question on the time-nuts list, and got this reply from Michael Tharp:

"Linux modules are the same, although Linux modules almost always need to be compiled against the specific kernel version while Windows drivers are typically only bound to which release you're running. That is the reason you have to compile the kernel, rather than just plop down a driver downloaded from the internet. "That said, the reason your PPS driver is a module is that it makes it easier to tweak options. Almost all modules that are part of the main kernel source (which PPS is, for a year or so) can be compiled in rather than as a separate module, but you can pass options to a module as you load it while you cannot do that with a built-in. It also makes it possible to tweak the source, recompile just that module, and test it on the fly rather than recompiling the entire kernel and rebooting."

Many thanks, Michael. Checking the PPS is working To check that you are running the new kernel and that the pps-gpio module is loaded, then install the pps-tools et run it to see the changes on pin 24 (assuming you have a 3.3 V PPS signal connected. Warning: faire ne pas connect a 5 V signal to the GPIO pins!

$ uname -a Linux raspberrypi 3.2.27-pps-g965b922-dirty #1 PREEMPT Sat Sep 22 16:30:50 EDT 2012 armv6l GNU/Linux

$ dmesg | grep pps [ 0.000000] Linux version 3.2.27-pps-g965b922-dirty (root@bt) (gcc version 4. 6.2 (Ubuntu/Linaro 4.6.2-14ubuntu2~ppa1) ) #1 PREEMPT Sat Sep 22 16:30:50 EDT 20 12 [ 1.866364] usb usb1: Manufacturer: Linux 3.2.27-pps-g965b922-dirty dwc_otg_h CD [ 12.797224] pps_core: LinuxPPS API ver. 1 registered [ 12.803850] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giome tti [ 12.824858] pps pps0: new PPS source pps-gpio.-1 [ 12.832182] pps pps0: Registered IRQ 194 as PPS source [ 133.043038] pps_ldisc: PPS line discipline registered [ 133.044841] pps pps1: new PPS source acm0 [ 133.044879] pps pps1: source "/dev/ttyACM0" added

$ sudo aptitude install pps-tools # may take some time

$ sudo ppstest /dev/pps0 # press Ctrl-C to cancel.. trying PPS source "/dev/pps0" found PPS source "/dev/pps0" ok, found 1 source(s), now start fetching data... source 0 - assert 1351501153.999956346, sequence: 47481 - clear 0.000000000, sequence: 0 source 0 - assert 1351501154.999954601, sequence: 47482 - clear 0.000000000, sequence: 0 source 0 - assert 1351501155.999951856, sequence: 47483 - clear 0.000000000, sequence: 0 ^C

The "clear" entries showing as zero is correct for this driver implementation. Note that if you don't have a PPS signal connected to GPIO pin 24 the last three lines from the dmesg output may be missing. In the output above, the PPS source was only registered some 133 seconds after startup, possibly the length of time it took the GPS to lock. On a second system with no PPS connected the last three lines were missing. This test should still work even with NTP running and using the PPS signal. Unfortunately, the version of NTP supplied with the Raspberry Pi Linux does not support PPS. Likely it has been compiled to minimise its memory and disk footprint. These are the steps to download, compile and install NTP (with help from jbeal's posting). You can choose between a release and a development version as shown in step 4 below. You could also use a copy of the development tarball on your own local FTP server. So from logging in, here are the steps. The lines below are shown for development version ntp-dev-4.2.7p397, but you will need to alter the version number to suit the version you wish to compile. The two time-consuming steps (configure and make) appear to be CPU limited rather than SD-card I/O access limited. You can see which version I am currently running here.

$ mkdir ntp # make a convenient working directory, if you don't already have one

$ cd ntp # enter that directory

$ sudo apt-get install libcap-dev # once-off, required to prevent later file not found error $ sudo apt-get install libssl-dev # once-off, you may not need this, but reports suggest you might to build keygen

# Get the desired tarball, current or development - use one of the following: $ wget http://archive.ntp.org/ntp4/ntp-4.2/ntp-4.2.8p10.tar.gz # release $ wget http://archive.ntp.org/ntp4/ntp-dev/ntp-dev-4.2.7p397.tar.gz # development (May redirect to: https://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-4.2/ntp-4.2.8p10.tar.gz)

$ tar xvfz ntp-4.2.8p10.tar.gz

$ cd ntp-dev-4.2.8p10

$ ./configure --enable-linuxcaps # takes 11-15 minutes

# If your PPS doesn't work and you get a "clock type 22 invalid" message, be sure to install pps-tools # first, and clear out the directory: cd ~/ntp, rm -r ntp-dev-4.2.7p397, and start again from step 5.

# It seems that the --enable-linuxcaps flag may not be required on other Linux variants, # or on the RPi with later versions of Linux with PPS and pps-tools installed. # It is required for the more recent Raspbian Jessie (later 2015).

$ make # takes 18-25 minutes (use "make -j5" for faster execution on the four-core Raspberry Pi 2/3.)

# This removes the original NTP and installs the new. # Step may not be needed - see below. # Recommend: omit this step. $ sudo apt-get remove ntp # get rid of previously existing install of ntpd

$ sudo make install # puts ntp* in /usr/local/bin/ntp*, takes 30-60 seconds

It is not entirely clear to me whether step 9 above is required. It does not appear to be when updating from 4.2.7p304 to 4.2.7p321, for example. je suis ne pas using step 9. Once you have a new set of NTP binaries, you first need to stop NTP, use super-user mode to copy the binaries to their final directory, and then restart NTP. Once restarted, a simple check that it's working correctly. I recommend these steps, although there are alternatives. See the note below about step 2.

$ sudo /etc/init.d/ntp stop

$ sudo cp /usr/local/bin/ntp* /usr/bin/ && sudo cp /usr/local/sbin/ntp* /usr/sbin/

$ sudo /etc/init.d/ntp start

$ ntpq -crv -pn # optional step to check for version and basic function

Remarque: on some more recent versions of Raspbian steps 1 and 3 may require:

$ sudo service ntp stop

$ sudo cp /usr/local/bin/ntp* /usr/bin/ && sudo cp /usr/local/sbin/ntp* /usr/sbin/

$ sudo service ntp start

Remarque: that on some systems the binary ntp* files will be written to a mixture of /usr/local/bin et /usr/local/sbin, according to the paths defined in sntp/loc. I have been told that the "sbin" is for system files (i.e. ones not usually run by users such as servers and daemons, and the "bin" is for files usually executed by users). For Debian, for just the ntp* files, this is:

# Debian installations and man page suffixes MDOC ntp-keygen,sbin,8 ntp-wait,sbin,8 ntpd,sbin,8 ntpdate,sbin,8 ntpdc,bin,1 ntpdsim,sbin,8 ntpq,bin,1 ntpsnmpd,sbin,8 ntptime,sbin,8 ntptrace,bin,1

so you may need to check both directories to get the most recent files. Check with "ls -l" which shows the file date. A confession: I did alter one system to point the NTP start-up to the directory I preferred, rather than leaving it pointing to an old version. I suspect that in my own personal use, only the ntpd and ntpq executables matter. Updating multiple Raspberry Pi cards If, like me, you have multiple Raspberry Pi cards, you will not want to waste almost an hour compiling and updating NTP on each card. Fortunately, my experience so far using the development versions of NTP (4.2.7p…) suggests that simply copying the binaries from one Pi to another works as expected. This may be luck, or it may be because the OS differences between Linux/3.2.27+ and Linux/3.6.11+ are not that great. Si you have access to an FTP server (I used a Windows PC running IIS) you may be able to use commands such as those below to save a compiled version from one Pi and load it onto another. You may need to use sudo apt-get install ftp if FTP is not already available. Step 5 is required once. Étape 7 is required for each new version you save. Replace "368" in the steps below with the version number you have just compiled. To save the newly compiled versions:

$ ftp

(Login as Anonymous or known user)

bin (forces binary mode)

mkdir RaspberryPi (step only needed once)

cd RaspberryPi

mkdir 397-safe (step needed once per new version)

cd 397-safe

prompt (may disable prompting for steps 10 and 13)

lcd /usr/local/bin

mput ntp*

(respond Y to the prompt for all the files)

lcd /usr/local/sbin

mput ntp*

ls -l (to check that all eight files are there and have the date you expect)

quitter

To load a new version onto another Raspberry Pi:

$ cd /usr/local/bin

$ sudo ftp # sudo allows writing to system directories

(Login as Anonymous or known user)

bin (forces binary mode)

cd RaspberryPi/397-safe

ls -l (to check that the files there are correct and have the date you expect)

mget ntp*

(respond Y to the prompt for all the files)

quitter

$ sudo /etc/init.d/ntp stop

$ sudo cp /usr/local/bin/ntp* /usr/sbin/ && sudo cp /usr/local/bin/ntp* /usr/bin/

$ sudo /etc/init.d/ntp start

$ ntpq -crv -pn # to check the NTP version, and that it is still working

See the discussion above about the combined commands in step 11. An alternative to steps 1 to 9 might be, if you are brave:

sudo wget -P /usr/local/bin -N ftp:///RaspberryPi/397-safe/ntp*

Making updating other cards even easier – use a fixed directory name: After storing the working version on your FTP server, copy it on the FTP server to a directory with a fixed name such as:

/RaspberryPi/ntp/

You can then write a script for updating other Raspberry Pi cards something like this:

$ nano update-ntp

with the following contents:

sudo wget --no-passive-ftp -P /usr/local/bin -N ftp:///RaspberryPi/ntp/ntp* sudo /etc/init.d/ntp stop sleep 1 sudo cp /usr/local/bin/ntp* /usr/sbin/ && sudo cp /usr/local/bin/ntp* /usr/bin/ sleep 1 sudo /etc/init.d/ntp start sleep 4 ntpq -crv -pn

remplaçant with the name or IP address of your own FTP server. With a Microsoft FTP server, I found that I needed to add –no-passive-ftp after the wget command, as shown above. Remember to make the script executable:

$ chmod +x update-ntp

and run it from your local directory:

$ ./update-ntp

You can tell another Raspberry Pi to run the update by using the SSH command thus:

$ ssh pi@the-other-raspi "./update-ntp"

You will need to enter the password for the user "pi", although this can be avoided (I am told) by using public key based authentication, if that fits with your security model. Once you have managed to copy your key to the second machine (man ssh-copy-id) you need no password either. I'm afraid I don't know how to do that, though. To get NTP to use the PPS data which is now available to it, the timestamps of the transitions on the GPIO pin, we need to add another refclock (server) line to the ntp.conf file. The server we use is a type 22 server called the ATOM refclock, and we can give it a reference ID of "PPS". I also changed the reference ID of the serial data to "GPS". Note that with a type 22 clock you doit have one other server marked as "prefer".

# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help

# Drift file to remember clock rate across restarts driftfile /var/lib/ntp/ntp.drift

# coarse time ref-clock, not really needed here as we have LAN & WAN servers server 127.127.28.0 minpoll 4 maxpoll 4 fudge 127.127.28.0 time1 +0.350 refid GPS stratum 15

# Kernel-mode PPS ref-clock for the precise seconds server 127.127.22.0 minpoll 4 maxpoll 4 fudge 127.127.22.0 refid PPS

# LAN servers server 192.168.0.3 minpoll 5 maxpoll 5 iburst prefer server 192.168.0.2 minpoll 5 maxpoll 5 iburst server 192.168.0.7 minpoll 5 maxpoll 5 iburst

# WAN servers, "pool" will expand the number of servers to suit pool uk.pool.ntp.org minpoll 10 iburst

Remarque: when using the ATOM (type 22) refclock, one of the other servers doit be marked as prefer. This is because the type 22 clock only supplies the timing dans the second, and another server is required to determine the courant second. Checking that NTP is seeing the PPS data When you have restarted NTP with the new binaries, you should see a new line in the output from an ntpq -p command, and the word "kern" should be present in the output of an ntpq -c rv command:

C:>ntpq -p raspi remote refid st t when poll reach delay offset jitter ============================================================================== SHM(0) .GPS. 15 l 13 16 377 0.000 33.837 3.510 oPPS(0) .PPS. 0 l 12 16 377 0.000 0.002 0.002 *pixie .PPS. 1 u 18 32 377 0.498 -0.030 0.025 +feenix .PPS. 1 u 5 32 377 0.619 -0.078 0.035 +stamsund .PPS. 1 u 29 32 377 0.614 -0.017 0.051 uk.pool.ntp.org .POOL. 16 p - 1024 0 0.000 0.000 0.002 -ntp.uk.syrahost 192.93.2.20 2 u 405 1024 377 30.031 8.487 0.274 -ntp2.exa-networ 195.66.241.10 2 u 217 1024 377 26.263 3.167 1.277 -resntp-a-vip.lo 182.7.208.171 3 u 49 1024 377 17.854 2.828 1.460 -time.shf.uk.as4 91.208.177.20 3 u 75 1024 377 18.825 0.680 1.974

C:>ntpq -c rv raspi associd=0 status=011d leap_none, sync_pps, 1 event, kern, version="ntpd 4.2.7p314@1.2483 Mon Oct 29 15:30:42 UTC 2012 (3)", processor="armv6l", system="Linux/3.2.27-pps-g965b922-dirty", leap=00, stratum=1, precision=-19, rootdelay=0.000, rootdisp=1.180, refid=PPS, reftime=d439fe8b.16dba50f Tue, Oct 30 2012 7:21:47.089, clock=d439fe97.4d7ac44d Tue, Oct 30 2012 7:21:59.302, peer=63905, tc=4, mintc=3, offset=0.001547, frequency=-45.081, sys_jitter=0.001907, clk_jitter=0.000, clk_wander=0.000

You may find that by adding the directive "nohz=off" to the end of your /boot/cmdline.txt that jitter is decreased by up to 50%. Try it and see for yourself. Some systems it helps, and others it does not, depending, I suspect, on which OS and firmware versions you have. Comme guide, you may get to average jitter in the range:

Modèle Averaged jitter

Raspberry Pi B 3.9 us, but may be better

Raspberry Pi B+ 4.2 µs

Raspberry Pi 2 B 2 µs

Raspberry Pi 3 B 1 µs

Thanks to the folks here for their help. With the replaced version of NTP we lose the automatic running de ntpd at startup which was present in the original install. We also need to start gpsd so that the coarse time is available to NTP.

# To configure gpsd to auto-start, try: $ sudo dpkg-reconfigure gpsd

This seems to work as expected, and allows the gpsd to automatically start up. To check that, I rebooted, and logged in, and could run cgps -s right away. However, NTP won't see the time from the GPS until après cgps -s is run. This is fixed as follows (thanks to A Carver): by default, gpsd won't connect to the GPS receiver until there is client software such as cgps with requires it. This allows for some power-saving in the GPS receiver. To circumvent this, the gpsd needs to be started with the "-n" option. These options are set in the directory /etc/default, so you need to edit the file /etc/default/gpsd to change the line: GPSD_OPTIONS="" to GPSD_OPTIONS="-n". Method A is to do this through dpkg-reconfigure gpsd, method B is to edit the file directly.

$ sudo nano /etc/default/gpsd

NTP will auto-start after a reboot with either Method A or Method B above. There is a cut-out area in the ModMyPi case which will allow connections to the GPIO connector such as ribbon cable which you can easily break out and file down to a neat edge. The sharp-eyed amongst you will notice that three wires are shown – this is because the surplus header had three wires connected, but I only used two – ground (blue) and GPIO 24 (red). The black lead would be GPIO 23 but it is unused and not connected.

GPS Receiver Issues There are two issues which are now becoming apparent with the particular GPS receiver I have and the Raspberry Pi.

It seems that after a power-down reboot, the GPS receiver isn't correctly detected, and need a disconnect/reconnect of its USB connector before it is seen by gpsd. The pulse-per-second signal still comes through, though, so the precise seconds are working, but the coarse seconds are ne pas. This is clearly unacceptable as you would not get the correct time unless you also had an Internet NTP server available.It is possible that a power-up followed by a reboot mai resolve this problème. During the booting of the GPS receiver (if it does not have a battery) it mai output GPS time (which is 16 seconds adrift from UTC at the time of writing). Bien que gpsd est supposed to catch this situation, it could mean that the Raspberry Pi will not know what the correct time is for some time after booting, and even then it could take 10-20 minutes to be sure that the correct time was actually being sent by the GPS and for NTP to make the 16 seconds step correction required.

If your receiver has this 16-second ambiguity, be sure you have a source of coarse time available such as an Internet NTP server. Because of the problem (1) above, I bought a serial GPS receiver from China. By following the instructions here I was able to make the serial port available on the Raspberry Pi independent of its use as a login or boot-up terminal port.

(make a safety coppy of the file we are about to edit) $ sudo cp /boot/cmdline.txt /boot/cmdline_backup.txt

$ sudo nano /boot/cmdline.txt (remove the parameter including the string "ttyAMA0": console=ttyAMA0,115200 In Raspbian Wheezy there are two parameters: console=ttyAMA0,115200 kgdboc=ttyAMA0,115200)

$ sudo nano /etc/inittab (Comment out the line like "2:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100" by putting a hash (#) at the start of the line. Note that the line was not 2:23 on my version of Linux, so be sure to look for the actual line with ttyAMA0. It was the last line of the file, as it happens).

(You need to reboot to bring these changes into effect) $ sudo reboot

(Minicom then works - to exit minicom, Ctrl-A, release, Q or X.) $ minicom -b 9600 -o -D /dev/ttyAMA0

(If minicom gives command not found, you need to install it:) $ sudo apt-get install minicom

Note that the Raspberry Pi requires 3.3 V signals on the serial pins – ne pas RS-232 level which will damage the device. Toi should now be able to configure gpsd to talk to ttyAMA0 (using sudo dpkg-reconfigure gpsd), and the cgps -s command should work as above. 3.3 V GPS receiver I found a 3.3 V I/O very compact GPS receiver board here described as: "GPS Receiver u-blox NEO-6M Module with Antenna USART TTL & IIC Interface". It includes the patch antenna and cost less than £20. Such modules seem to be a standard for flight control for model aircraft and similar applications. It does require one minor modification, which is to solder a wire to pin 3 of the NEO-6M module to extract the PPS signal. This unit was later replaced by a Adafruit Ultimate GPS Breakout which requires no additional soldering, and has a built-in antenna.

The U-blox board from China and supplied antenna under test.

The Adafruit GPS mated to the Raspberry Pi. Only le GPS Tx => Pi Rx lead (yellow) is connected, and thesecond ground lead (blue) isn't connected either.

Raspberry Pi #2 with its Adafruit GPS. Red/brown are+5V/0, orange the GPS Tx, and yellow the PPS.

One the left is the receiver undergoing initial tests. Vous pouvez see the patch antenna on the left raised on a block of foam so that it can "see" past the clutter of the receiver, the receiver itself on the blue PCB mounted vertically in the breadboard, and you might just see the orange-pink wire at the top-right corner of the receiver which has been carefully soldered to pin 3 of the NEO-6M to get the PPS signal. The wire is anchored in the top-right mounting hole for strain relief. You don't need surface-mount tools to make this connection, mais toi faire need a very fine soldering tip and considerable care! Like the TX/RX signals from this module, the PPS signal is at 3.3 V level and therefore ideal for feeding the Raspberry Pi. The board will accept either 3.3 V or 5 V power while retaining 3.3V I/O levels, and I'm using 5 V to power the board to reduce the load on the 3.3 V regulator on the Raspberry Pi board. The U-blox device is specified at less than 50 mA supply current. For the final installation, the Adafruit module was used as its single package was more convenient. Not all the leads are connected as there is only one place to connect ground on the module (so the blue is left open), and for simplicity the green Pi Tx => GPS Rx was not connected. Judge the size of the Raspberry Pi by the Ethernet connector on the left! The next step was to set up the Raspberry Pi to talk to the new module, use serial GPS data via gpsd for the coarse time, and to use its PPS line to provide precise time just as described above. To preset the serial line speed to 9600 at Linux start-up, edit the file /boot/config.txt to include the line: init_uart_baud=9600 as it says in: http://elinux.org/RPi_config.txt. You can check using the command:

stty -F /dev/ttyAMA0

I found that the speed was already set to 9600 on a recent Raspberry Pi installed from the NOOBS software. I gather that on a typical Linux system you might use the command: stty -F /dev/ttyAMA0 9600. Raspberry Pi GPIO multi-pin connector This time , not only were PPS and ground connections required, but also the serial port and the +5 V line, so I used a piece of 6-way ribbon cable to connect between the Raspberry Pi and my serial GPS device. I happened to have a 10-pin header which fitted the GPIO connector, so these are the connections I chose to make:

macable Tarte aux framboisesconnecteur Commentaire GPS moduleconnecteur

rouge + 5V My unit takes less than 50 mA 1 +5V

+ 5V

Bleu Sol One of two ground connections 2 GND

vert TXD Not connected, see below

Jaune RXD Receives serial data sent from the GPS 3 TXD

GPIO 18

Sol

GPIO 23

blanc GPIO 24 Receives the PPS sent from the GPS PPS pin on u-blox device

Noir Gnd One of two ground connections 6 GND

I actually didn't connect the TXD lead to the GPS module in the first instance, as the GPS receiver powers up sending data in the correct format, so there is nothing which the computer Besoins to control. There is a description of the GPIO pin header here. Again, please note that 3.3 V signals are required, ne pas the 5 V level, and absolument ne pas the RS-232 level! Converting from USB to native serial – software changes We need to tell gpsd to look for input from a different source: ttyAMA0 instead of ttyACM0

$ sudo nano /etc/default/gpsd

and change the DEVICES= to point to "/dev/ttyAMA0". You could use "sudo dpkg-reconfigure gpsd" instead. You may also find that the delay between PPS and TXD on the serial line is different from that over USB, so you may wish to edit your ntp.conf accordingly – it makes the output look nicer at least and may make prediction of the nearest second more accurate during the initial acquisition. In my case I needed to change the 0.35 second offset seen in the earlier device to the 0.13 second offset seen with the U-blox device, hence the following changer ntp.conf, from

fudge 127.127.28.0 time1 +0.350 refid SHM stratum 15

à:

fudge 127.127.28.0 time1 +0.130 refid SHM stratum 15

This configuration has been running since Friday, November 09, 2012. On reflection, I am unsure why I chose to make the stratum 15 in the example above, Possible stratum 2 or 3 might be better, otherwise NTP may think that the source is of very poor quality and fail to sync to it. Robin Scwab notes that you could try using the value of "Time offset" displayed in cgps -s as the starting value for the time1 parameter. This sounds to be a gooo idea, except that on one system here I happened to check Time Offset was about 0.640 seconds, but the best value for time1 (i.e. the value resulting in the smallest average offset) was 0.130 seconds. Where did the extra 0.5 seconds come from? Number of NTP clients which can be handled Someone asked: "How many NTP clients can it handle?" Well, I have not done any extensive testing on how many clients this NTP server can handle (as it will easily be enough for use on a LAN, and it's not fit for public use in its present security date). I did manage to locate one NTP stress-testing program here, but the maximum rate I could get it to produce on my PC was about 75 packets per second, and the Raspberry Pi can handle that rate with ease. With NTP client PCs polling at 64 second intervals (the fastest normally used), that's 4800 clients, so easily enough for a small organisation. If you were using this for a small organisation, I would recommend using two or three stratum-1 servers so that you are covered in the event of failure – perhaps mark one of the servers "prefer" on the client PCs to avoid NTP from "clock-hopping". If you have better stress-test data, as Kasper Pedersen did, please let me know and I can publish it here. Kasper Pedersen notes: I did one a few years ago that goes a bit faster (Linux): http://n1.taur.dk/permanent/ntpload.c To test a Raspberry Pi you need 4 instances running, at which point the Pi runs out of CPU, and settles on 3520/s. That ought to be enough for most small homes.. 🙂 These are brief notes only, on an alternative approach which does not require a modified kernel with PPS support in the OS, nor does it require a recompiled NTP, but which produces slightly less accurate timekeeping. It may, however, be quite good enough for most purposes. The program was developed by Folkert van Heusden, see: http://vanheusden.com/time/rpi_gpio_ntp/ and announced in the Time-Nuts mailing list. Base installation – check you meet these requirements You can start here assuming that you have your Raspberry Pi basically working with GPSD and NTP, meaning that:

You have installed the current operating system and any updates. You have made any optional IP address or computer name changes. You have got NTP working, preferably connected to your country's pool servers. You have recompiled and installed NTP to get a full version (is a re-compile required?). You have the PPS signal from the GPS receiver connected to the GPIO, e.g. GPIO-8 (pin 24), or GPIO 18 for the no-soldering planche. You have installed and configured the gpsd Logiciel and utilities, and made gpsd auto-start. You have a GPS device connected either via a serial or a USB connection. le cgps -s command produces a correct display. You have configured NTP to talk to the type 28.0 shared memory driver, and can see the GPSD output in ntpq -pn.

Optional first step – to determine the offset of your GPS serial data from the exact second The objective is to determine the offset between the PPS signal from your GPS and the serial data which typically follows some hundred or more milliseconds later. NTP can use that offset either to make a better sync when using just a GPS receiver with no PPS, or to present a slightly less déroutant ntpq -p output when using PPS. To measure what offset should be specified for the time1 factor when using a GPS receiver (type 28 reference clock driver), we can use NTP as a measuring tool by making it sync to existing servers and have it monitor the shared memory #0 written by gpsd. I.e. NTP will not use server 28.0 for timekeeping, but it volonté display the offset in the ntpq -p commander. To do this, you add these lines to your ntp.conf (if they are not already there):

# Server to be monitored only, not selected for syncing server 127.127.28.0 minpoll 4 maxpoll 4 noselect fudge 127.127.28.0 time1 0.000 refid GPSD

Watch the results from ntpq -pn, and look at the offset for the server with the refid GPSD. On one of my RPi cards it varied between -322 and -336 (units are ms in the ntpq report). Take an average of those values, and replace the 0.000 after time1 with that average. In this case, the average was -329 ms, so try:

server 127.127.28.0 minpoll 4 maxpoll 4 noselect fudge 127.127.28.0 time1 0.329 refid GPSD

i.e. if the reported offset is negative, you need to make time1 a positive value. Now you should see much smaller offsets for the GPSD server. Ce n'est pas essential to do this, but it gives you confidence that things are working as expected, it may help NTP in the early startup, and it produces a less déroutant ntpq display. Don't forget to remove the noselect when you have the best value for the offset, and set the flags to include préféré so that NTP knows it can use that source as a seconds provider! Là must be at least one préférer for PPS to work. This now has the NTP daemon seeing the GPSD device, and the next step is to add in some PPS support.

server 127.127.28.0 minpoll 4 maxpoll 4 prefer fudge 127.127.28.0 time1 0.329 refid GPSD

Getting the average value for time1 automatically Angelo Mileto writes: What I did to get a good sample of data for the time1 value was let the ntpq -p command run for a period of time and capture the results. Then, using awk, calculate the average/mean of the values collected. If you look at the static ntpq -p output, you will see something like this: remote refid st t when poll reach delay offset jitter ============================================================================== SHM(0) .GPSD. 2 l 13 16 377 0.000 33.837 3.510 oPPS(0) .PPS. 2 l 12 32 377 0.000 0.002 0.002 along with other pool/server entries. As noted above, you need to ensure you have a good preferred source for the comparison to work. To capture your data, execute the following at the command line from your user's home directory:

watch -n0.5 "ntpq -pn | grep '.GPSD. 2 1 1' | tee --append GPSD_Offset.txt"

Pay attention to the single and double quotes in that command. If you notice, the grep is looking for the exact line from the ntpq -p output that contains your GPSD refid. So if you named it something different, that would replace the .GPSD. in the command. Also, notice the "2 1 1", that is the stratum, t and when fields. The stratum is whatever you set it to in the ntp.conf; the t should always be a 1 and the when is going to capture the output seulement when the timer reaches 1 meaning that it just updated the value. There is no sense in capturing data every .5 seconds for data that doesn't change! So the easiest way to get the value to grep for is to manually run the ntpq -p and copy from your refid through the when fields and that's what will be grepped for. Let that run for a good while – probably not really needed – but that's the point of getting a good sample size. This will capture the output from the ntpq command filtering to just your SHM/GPSD. This will all be saved to a file GPSD_Offset.txt in the current directory – that's what the "tee –append GPSD_Offset.txt" does. You can tail -f that file if you want while the watch command is running to see what is going into that file. NOTE: If you need to restart the process because you changed some setting and want to start over, delete any existing GPSD_Offset.txt file first. Once you have a sufficient sample size, you can then use the following command to get the actual value for the average/mean:

awk 'total=total+$9; count=count+1 END print "Total:"total; print "Count:"count; print " Avg:"total/count' GPSD_Offset.txt

This steps through every line of the GPSD_Offset.txt file and totals up all of the offset values. It will also count how many lines/values are there. Finally it just prints the information: Total, count and average. The average value is what you would put into the time1 value as noted above. Don't forget to change the noselect to prefer when you are in there to add the time1 value. Angelo Mileto DJT: This is somewhat beyond my Linux, so my thanks to Angelo for the scripts and the detailed explanation. Angelo can be contacted here. Downloading and compiling Folkert van Heusden's program As of 2013-Jun-18, rpi_gpio_ntp-0.3 was the current version, but thanks to Thomas Erthner I know that version 1.5 is now available, so I've updated the lines below. However, I've only tested version 0.3, not version 1.5. For more details, please see Folkert's page.

$ wget http: //vanheusden. com/time/rpi_gpio_ntp/rpi_gpio _ntp-1.5. tgz

$ tar xvfz rpi_gpio_ntp-1.5.tgz $ cd rpi_gpio_ntp-1.5 $ sudo make install

This places the resulting binary in /usr/local/bin/. You don't need this for current Raspbian versions. To test you are receiving a PPS signal, from GPIO pin 8:

NTP unit: 0 GPIO pin: 8 Fudge : 0.000000 "Fork into the background" disabled because of debug mode. 1371475664.752146325]poll() GPIO 8 interrupt occurred 1371475665.000148935]poll() GPIO 8 interrupt occurred 1371475666.000147203]poll() GPIO 8 interrupt occurred 1371475667.000160470]poll() GPIO 8 interrupt occurred 1371475668.000159739]poll() GPIO 8 interrupt occurred (Ctrl-C pressed) $

Running the program To make NTP read the PPS timings on the GPSD shared memory, we need to use this command to start the program, assuming the PPS signal is being sent to GPIO-8 (physical pin 24 – see here). Use pin 18 is you are using the no-soldering board.

$ sudo rpi_gpio_ntp -N 1 -g 8

and to edit the ntp.conf file, to include the shared memory driver, on section 1 of the GPSD shared memory, replacing the earlier type 22 driver. Add:

server 127.127.28.1 minpoll 4 prefer fudge 127.127.28.1 refid UPPS

I suggest "UPPS" to show it's user-mode PPS (and not the more accurate Kernel mode). If you want to see the output pulse from the program, you can add the "-p 7" parameter:

sudo rpi_gpio_ntp -N 1 -g 8 -p 7

and you can then use an oscilloscope to compare the time of the PPS rising edge with the toggling line from GPIO pin 7 (connector pin 26). On my system, there was a variable delay of between 270 and 390 microseconds between PPS and program response. Auto-start More information to follow, for now, this from Folkert: modifier /etc/rc.local and add the following (BEFORE the exit 0 statement and AFTER the #!/bin/sh line):

/usr/local/bin/rpi_gpio_ntp -N 1 -g 8

Replace '8' by the gpio pin you are using, e.g. 18 for the no-soldering planche. Performance The original documentation suggested using minpoll=1, however on testing using ntpq -pn it appeared that NTP will automatically accept 3 as the minimum value. Comme the previous testing with kernel-mode PPS had been with minpoll=4, it seemed only fair to test with that value. You can see the change from minpoll=1 to minpoll=4 just after 18:00 UTC. Recall that 1 was replaced internally by 3, the lowest value NTP will accept. With minpoll=4, both the reported offset and the averaged jitter were reduced. First, what it looks like in MRTG for comparison with the results above:

Don't get confused: the MRTG plot above covers rather more than one day, whereas the plots below cover just under half a day. Sur le plot MRTG plot, you can see that the RPi was changed from kernel-mode PPS at 13:00 UTC and run for a short while with Internet servers alone, visible as the larger excursions on the plot above around 13:00). From my NTPplotter program graphs below, you can see more clearly that at 13:30 the user-mode PPS was started, and the just after 18:00 the minpoll was changed from 1 (actually 3) to 4, resulting in a slight drop of RMS offset from around 5 microseconds to 4 microseconds:

The jitter graph shows a drop in averaged jitter (green line) from just below 7 to just above 5 microseconds after 18:00, when the minpoll was changed from 3 to 4. The initial higher value of averaged jitter is the tail resulting from Internet-only sync.

On another Raspberry Pi you can see the dramatic difference between NTP sync over the network and that achieved with the user-mode PPS software. Dans this case, network sync was to a local NTP stratum-1 server over a Wi-Fi connection, and the PPS sync was with a U-blox 5S module. User-mode PPS was started just after 11:00 UTC in the middle of the graphs below. RMS offset dropped from a rather variable 48-80 microseconds to around 2 microseconds, and jitter averaged over 6 hours dropped from around 80 microseconds to under 2.5 microseconds.

To monitor NTP you can edit the ntp.conf file to turn on the generation of more detailed statistics data. Note that this data maybe a megabyte or more per day, so think about keeping only a few days worth, and only enabling statistics collection when needed as the number of writes to the SD card flash memory is limited. The detailed information can now be found here and I offer a program to plot the statistics data and produce offset and jitter graphs such as those above here. Transients I may have been unfortunate in locating one Raspberry Pi with an Adafruit module in a position where it was not getting as good a view of the sky as others, or it may be that other devices connected to that RPi or software installed is an issue. I have been seeing transient poor time-keeping (loss of GPS PPS signal) at intermittent times. I did discover that disconnections a lead to a USB hub connected to that RPi seemed to improve des choses. If the problem was caused purely by unfortunate GPS satellite position, I might have expected it to repeat in a near 24-hour pattern, which does appear to be the case. Thanks to John Ryan for correcting me about the GPS orbital period, I was originally thinking sidereal time and 4 minute earlier each day. However, on the Time-Nuts mailing list, in connection with another topic, Bob Camp commented:

"The GPS constellation repeats roughly once a day. It is not at all uncommon to have a “worst case” satellite geometry for a given antenna location. If you have one, it will repeat once a day and show up as a bump in the timing out of your GPS module…."

Although the GPS satellites repeat position in just less than 12 hours, there is also the rotation of the earth to take into account, so the position repeats at your location every 24 hours (well, ~23 h 56 m). On reflection, 2014 February 09, this is the only Raspberry Pi with certain radio software installed, and the problem only seems to occur some days after a reboot, so I think I will stop recording the problem ici. I am editing out the transients as they affect the P/N timekeeping graphs, but I leave the raw-graphs as-is.

Date Transient

Dec 31 20:00-20:45, 23:10-24:00

Jan-01 20:14-20:37, 23:17-23:28

Jan-02 01:29 02:45, 19:57..20:13, 20:14..20:29, 20:31, 23:13, 23:24 23:30..23:54

Jan-03 02:39, 03:44, 20:12..20:22, 23:24..23:52

Jan-04 02:37, 20:03..20:28, 23:06, 23:41..23:45

Jan-05 02:31

Removed USB extension cable from RasPi-2

Jan-06 19:33..1940, 19:54, 22:49..22:55

Jan-10 20:30 22:07-22:17 22:37-22:45 23:03

Jan-11 21:57-23:18

Jan-12 22:01-22:54

Jan-13 19:17-19:37 22:37-22:54

Jan-14 01:46-01:47 19:30 19:40 22:46-22:51

Jan 15 01:47 19:16-19:35 22:42-22:46 23:06

Jan-16 19:05-19:32 22:24-22:41

Jan-17 19:07-19:19 22:04-22:34

Jan-18 19:11-19:16 21:55-21:57

Jan-19 02:38-02:39

Jan-20 19:04-20:06

Jan-21 02:55-03:03 03:17 19:00 19:46 20:15 22:06

Jan-22 02:56-03:05

Jan-23 10:46 12:48

Jan-24 02:48-02:53 07:21 07:44 12:46-12:48 17:11 19:20-19:36

Jan-25 07:13 07:18 07:52-07:53 13:02-13:11

Jan-26 02:50 03:26 18:06 18:31-18:36 21:59

Jan-27 02:42 02:57-03:37 07:09 (reboot at 17:23)

Jan-31 21:19-21:21

Feb-05 20:59 23:12 (is this something which starts days after boot?)

Feb-07 18:03 18:41 20:52

Feb-08 15:09 15:42 18:37 20:33 20:46 21:24

Feb-09 00:13 00:37-00:43 01:37

If you are operating completely alone, with no internet connection and just the GPS, your NTP may need to be told about leap-seconds which change the offset between GPS time and wall-clock time every so souvent. Some GPS receivers provide this information automatically, but this can also be done by providing a file with the times of changes (in a standard format) and telling ntpd where to find that file. On my own systems I have set up a Samba share on the NTP servers so that I can update the leap-seconds file from a central location. To do this, add a new writeable share named "ntp-leapseconds" by adding lines to the end of smb.conf, and then restart Samba:

sudo nano /etc/samba/smb.conf [ntp-leapseconds]

comment = NTP leapsecond.file path = /home/pi/ntp writeable = yes guest ok = yes

sudo /etc/init.d/samba restart

I chose to put my leap-seconds file in the default user's "ntp" home directory, but you may prefer some where more secure! To tell ntpd where to find the file, add one line to the end of ntp.conf with nano, and restart NTP:

sudo nano /etc/ntp.conf leapfile /home/pi/ntp/leap-seconds.file sudo /etc/init.d/ntp restart

You can get the leap-seconds file from a variety of locations, including: ftp://utcnist.colorado.edu/pub/ ftp://tycho.usno.navy.mil/pub/ntp/ and it will be named leap-seconds.3582403200 with a different serial number as the information is updated (this file was found in December 2013). je copy the file to a constant name: leap-seconds.file so that I don't need to alter NTP each time. I then have a small Windows command file to update all my systems – Windows, FreeBSD and Raspberry Pi cards. Here's an extract:

XCOPY /D /Y leap-seconds.file \Altantpetc XCOPY /D /Y leap-seconds.file \Stamsundntpetc XCOPY /D /Y leap-seconds.file \Pixie-IIntp-leapseconds XCOPY /D /Y leap-seconds.file \RasPi-1ntp-leapseconds XCOPY /D /Y leap-seconds.file \RasPi-2ntp-leapseconds PAUSE

You can check whether NTP is using the file, and whether your file is stale, with the: ntpq -crv commander:

associd=0 status=01fd leap_none, sync_pps, 15 events, kern, version="ntpd 4.2.7p408@1.2483 Sun Dec 29 14:36:43 UTC 2013 (1)", processor="armv6l", system="Linux/3.6.11", leap=00, stratum=1, precision=-19, rootdelay=0.000, rootdisp=1.180, refid=PPS, reftime=d66b96d3.01b61b26 Mon, Dec 30 2013 6:53:07.006, clock=d66b96df.3df17b24 Mon, Dec 30 2013 6:53:19.241, peer=61352, tc=4, mintc=3, offset=0.000281, frequency=-34.180, sys_jitter=0.001907, clk_jitter=0.001, clk_wander=0.003, tai=35, leapsec=201207010000, expire=201406010000

Look at the two final lines. leapsec shows the latest leap second (here is was on 2012 Jul 01), and when the leap-second file expires (here: 2014-Jun-01). There will also be a warning if the file is stale. Update the file from time-to-time – say every six months – in May and November as leap-second changes usually happen at the end of June or December. There is more information here. If you keep getting a different ntp.conf from that which you edited, your router may be the cause. It seems some routers give out NTP information in DHCP which the Pi by default uses over /etc/ntp.conf. The fix I think is:

rm /etc/dhcp/dhclient-exit-hooks.d/ntp

and if you have the following file, remove it as well:

rm /var/lib/ntp/ntp.conf.dhcp

Then reboot. You can produce real-time graphs like those below using MRTG and a simple script which can get the statistics from NTP remotely. Là is more information here. I happen to run MRTG and the collection scripts on a Windows PC.

RasPi-2 RasPi-4

Information on general SNMP monitoring may now be found here. This allows monitoring of the network I/O on the card, and a number of other parameters which are exposed for measurement by the OS. An example graph follows:

RasPi-3

As NTP tries to keep the clock on the card at a constant frequency, it is often compensating for the effects of temperature changes which cause frequency changes. It is therefore worthwhile monitoring the CPU temperature monitoring as described here, although with a PPS signal and when used as a stratum-1 server, temperature effects may be less obvious. Example graphs are shown below:

RasPi-4

The MRTG monitoring scripts (which I actually run on a Windows PC covering several Raspberry Pi cards) are in this Zip archive. I extended the SNMP pass function to allow monitoring of ambient temperature using the DS18B20 "single-wire" device. Cette is well written up for use with the Raspberry Pi here, and the detailed description is now here. Sample results:

RasPi-4 Indoor temperature °C

Outdoor temperature °F

Merci! My thanks to Webshed for uploading the information about using the DS18B20. Running a publicly accessible NTP server If you are running a server which is accessible from the public Internet – perhaps you are contributing to the NTP bassin project – there are some simple precautions you should take to ensure that your server is not used as the source of an attack on other PCs. Remarque that this doesn't apply to most end-user clients sitting on your local PC, you would need to have specially opened a port in your firewall or router to allow public incoming unsolicited UDP port 123 packets into your local network. If you are using a development version (4.2.7p26 or later) you are already protected. The following notice explains more:

NTP users are strongly urged to take immediate action to ensure that their NTP daemon is not susceptible to use in a reflected denial-of-service (DRDoS) attack. Please see the NTP Security Notice for vulnerability and mitigation details, and the Réseau Time Foundation Blog pour plus d'informations. (January 2014)

Raspberry Pi: 86 x 56 x 21 mm Raspberry Pi in its box: 91 x 62 x 29 mm Trimble evaluation board: 66 x 32 x 8 mm Trimble evaluation board with interface: 66 x 32 x 24 mm U-blox interface card: 39 x 22 x 6 mm (excluding connection pins) Patch antenna supplied with interface card: 25 x 25 x 7 mm

What else have I done with the Raspberry Pi?

Receiving ADS-B signals on 1.09 GHz with a cheap TV dongle and feeding the results to Plane Plotter over a Wi-Fi link. This allows you to put the receiver right up close to the antenna, avoiding an expensive (or lossy) piece of cable, and avoiding the need for a cable run at all. Details are here. It's not much more than following someone else's instructions, but at least I can vouch for every command on that page, and perhaps you will find something useful there. A Digital Wall clock using the Raspberry Pi – synchronised with NTP, of course!

Acknowledgments I would like to support NTP Click to rate this post! [Total: 0 Average: 0]

Construire un serveur NTP Stratum-1 Stratum-Pi – Serveur d’impression

Quick overview

Key points

Structured content

Topics and keywords

License & attribution