Serveur d'impression

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

Le 5 octobre 2019 - 81 minutes de lecture

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).

Sommaire

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 # 1
512 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 # 1
512 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 # 1
512 Mo,
      Linux / 3.2.27 +

Synchronisation PPS du noyau
Résolution Trimble SMT
chronomé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 # 1
512 Mo,
      Linux / 3.2.27 +

Synchronisation PPS du noyau
Module U-blox 6M
ré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 # 1
512 Mo,
      Linux / 3.2.27 +

Synchronisation PPS du noyau
Module U-blox 6M
ré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 # 1
512 Mo, Linux / 3.6.11

Synchronisation PPS en mode noyau

Adafruit MTK3339
récepteur GPS de navigation
dans une pièce non chauffée

Raspberry Pi # 2
512 Mo, Linux / 3.6.11

Synchronisation PPS en mode noyau

Adafruit MTK3339
récepteur GPS de navigation
en environnement de bureau

Raspberry Pi # 3
512 Mo, Linux / 3.6.11

Synchronisation PPS en mode noyau
U-blox 6M navigation
Récepteur GPS
en environnement de bureau

Raspberry Pi # 4
512 Mo, Linux / 3.6.11

Synchronisation PPS en mode noyau
U-blox 5S navigation
Récepteur GPS
dans une pièce non chauffée

Raspberry Pi # 5
512 Mo, Linux / 3.6.11

Synchronisation PPS en mode noyau
Calendrier U-blox 7Q
Récepteur GPS
en 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 # 1
512 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 # 2
512 Mo,
      Linux / 3.2.27 +

Synchronisation PPS en mode noyau

Adafruit MTK3339
      la navigation

Récepteur GPS
      en environnement de bureau

Raspberry Pi # 3
512 Mo, Linux / 3.6.11

Synchronisation PPS en mode noyau
U-blox 6M navigation
 GPS
receveur
      en environnement de bureau

Raspberry Pi # 4
512 Mo, Linux / 3.6.11 +

Synchronisation PPS en mode noyau
U-blox 5S navigation
 GPS
receveur
      dans une pièce non chauffée

Raspberry Pi # 5
512 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

  1. Téléchargez une image de système d'exploitation pour la carte SD – 2012-09-18-wheezy-raspbian.zip
  2. Décompressez le contenu de l'archive Zip dans un fichier .IMG
  3. Téléchargez le programme d'écriture de carte SD: Win32DiskImager
  4. 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 Pi
la carte ressemble à ceci. le
le 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.

  1. $ sudo apt-get update
  2. $ sudo apt-get dist-upgrade

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

  1. $ sudo reboot

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

  1. $ 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:

  1. Convertissez le mot de passe Wi-Fi en chaîne hexadécimale (cela peut être
        optionnel):
    $ sudo wpa_passphrase VotreSSID
        Votre mot de passe

    Vous obtiendrez un résultat hexadécimal tel que "b7d90db3ddbd11d5ddb3dbfd81de"
        dont vous aurez besoin plus tard.
  2. Editez le fichier /etc/wpa_supplicant/wpa_supplicant.conf
    $ sudo nano /etc/wpa_supplicant/wpa_supplicant.conf
    pour le faire ressembler à ceci:

    ctrl_interface = DIR = / var / run / wpa_supplicant GROUP = netdev
    update_config = 1
    réseau = {
    ssid = "YourSSID"
    proto = WPA RSN
    scan_ssid = 1
    key_mgmt = WPA-PSK
    paire par paire = CCMP TKIP
    groupe = CCMP TKIP
    psk = b7d90db3ddbd11d5ddb3dbfd81de

    Notez que le ssid doit être entre guillemets.

  3. Editez le fichier / etc / network / interfaces
    $ sudo nano / etc / network / interfaces
    pour le faire ressembler à ceci:

    auto lo

    iface lo inet loopback
    iface eth0 inet dhcp

    allow-hotplug wlan0
    auto wlan0
    iface wlan0 inet dhcp
    Wireless-Essid YourSSID
    pre-up wpa_supplicant -B w -D wext -i wlan0 -c /etc/wpa_supplicant/wpa_supplicant.conf
    Killall -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!

  1. $ cd / etc
  2. $ sudo cp ntp.conf ntp-original.conf
  3. $ 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:

  1. $ 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 [email protected] 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.

  1. $ 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:

  1. $ 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:

  1. $ sudo apt-get installez gpsd gpsd-clients python-gps
  2. À 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.
  3. $ 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.

  1. $ 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:

  1. $ 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=0BznvtPCGqrd3ZElKZHEtUDRpUEU
Modules: 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.

  1. # 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:

  1. $ mkdir pps
  2. $ cd pps
  3. # 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).
  4. $ unzip kernel-pps-gpio24.zip
  5. $ 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.

  1. $ sudo mv /boot/kernel.img /boot/kernel.img.orig
  2. $ 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:

  1. $ sudo mv 3.2.27-pps-g965b922-dirty /lib/modules/3.2.27-pps-g965b922-dirty
  2. $ 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
  3. $ sudo reboot  

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

  1. $ 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!

  1. $ uname -a
    Linux raspberrypi 3.2.27-pps-g965b922-dirty #1 PREEMPT Sat Sep 22 16:30:50 EDT 2012 armv6l GNU/Linux
  2. $ dmesg | grep pps
    [ 0.000000] Linux version 3.2.27-pps-g965b922-dirty ([email protected]) (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
  3. $ sudo aptitude install pps-tools # may take some time
  4. $ 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.

  1. $ mkdir ntp                  # make a convenient working directory, if you don't already have one
  2. $ cd ntp                     # enter that directory
  3. $ 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
  4. # 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)
  5. $ tar xvfz ntp-4.2.8p10.tar.gz
  6. $ cd ntp-dev-4.2.8p10
  7. $ ./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).
  8. $ make					# takes 18-25 minutes
    (use "make -j5" for faster execution on the four-core Raspberry Pi 2/3.)
  9. # 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
  10. $ 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.

  1. $ sudo /etc/init.d/ntp stop
  2. $ sudo cp /usr/local/bin/ntp* /usr/bin/  && sudo cp /usr/local/sbin/ntp* /usr/sbin/
  3. $ sudo /etc/init.d/ntp start
  4. $ 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:

  1. $ sudo service ntp stop
  2. $ sudo cp /usr/local/bin/ntp* /usr/bin/  && sudo cp /usr/local/sbin/ntp* /usr/sbin/
  3. $ 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:

  1. $ ftp 
  2. (Login as Anonymous or known user)
  3. bin  (forces binary mode)
  4. mkdir RaspberryPi  (step only needed once)
  5. cd RaspberryPi
  6. mkdir 397-safe  (step needed once per new version)
  7. cd 397-safe
  8. prompt   (may disable prompting for steps 10 and 13)
  9. lcd /usr/local/bin
  10. mput ntp*
  11. (respond Y to the prompt for all the files)
  12. lcd /usr/local/sbin
  13. mput ntp*
  14. ls -l  (to check that all eight files are there and have the date you expect)
  15. quitter
     

To load a new version onto another Raspberry Pi:

  1. $ cd /usr/local/bin
  2. $ sudo ftp 	# sudo allows writing to system directories
  3. (Login as Anonymous or known user)
  4. bin  (forces binary mode)
  5. cd RaspberryPi/397-safe
  6. ls -l  (to check that the files there are correct and have the date you expect)
  7. mget ntp*
  8. (respond Y to the prompt for all the files)
  9. quitter
  10. $ sudo /etc/init.d/ntp stop
  11. $ sudo cp /usr/local/bin/ntp* /usr/sbin/  &&  sudo cp /usr/local/bin/ntp* /usr/bin/
  12. $ sudo /etc/init.d/ntp start
  13. $ 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:

  1. 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 [email protected] "./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 [email protected] 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.

  1. # 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.

  1. $ 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.

  1. 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.
  2. 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.

  1. (make a safety coppy of the file we are about to edit)
    $ sudo cp /boot/cmdline.txt /boot/cmdline_backup.txt
  2. $ 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)
  3. $ 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).
  4. (You need to reboot to bring these changes into effect)
    $ sudo reboot
  5. (Minicom then works - to exit minicom, Ctrl-A, release, Q or X.)
    $ minicom -b 9600 -o -D /dev/ttyAMA0
  6. (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 the
second 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:

ma
cable
Tarte aux framboises
connecteur
Commentaire GPS module
connecteur
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

  1. $ 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:

$ sudo rpi_gpio_ntp -g 8 -d
rpi_gpio_ntp v0.2, (C) 2013 by [email protected]

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:

MRTG plot of offset

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:

Offset plot

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.

Jitter plot

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 [email protected] 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

Commentaires

Laisser un commentaire

Votre commentaire sera révisé par les administrateurs si besoin.