Étape 3: limites
Il y a beaucoup d’agents en jeu dans ce projet :
(1) le MTKLIO(s), besoin d’un GPS "fix" pour publier leur emplacement, le nombre de satellites vu et fixé à un moment donné dépend de divers facteurs tels que la question de savoir si l’unité est à l’intérieur ou à l’extérieur, avoir un ciel clair etc.. Les plus de satellites, nous pouvons obtenir un correctif sur, la plus précise la localisation du rapport.
(2) communication de données s’effectue sur le réseau GPRS (c’est à dire un réseau cellulaire, c’est pourquoi nous avons besoin de la carte SIM) et est soumis à l’unité obtenir un signal "sur le terrain".
(3) l’appareil est alimenté par une batterie lorsqu’il est déployé, puissance niveaux vont souffrir avec la poursuite de l’utilisation GPS.
(4) messages voyagent à travers les canaux tiers (i.e PubNub flux de données), même si je n’ai jamais trouvé c’est autre chose que résistant, robuste et éclaircissante rapide ! [*]
(5) si le contrôle navigateur web accède à un modem câble les données de localisation obtenues n’est pas très précises et dans le cas d’une clôture de petite rayon, peut donner des faux positifs lors du calcul si une unité est hors de portée.
Les images à cette étape, voir la sortie série (utile de savoir ce que fait l’appareil à n’importe quel compte tenu du temps lors du débogage) et le tombant et la re-connexion automatique d’un canal au cours des essais. On voit bien l’unité de réception d’une notification de « violation », suivie d’un « OK » comme le nombre de satellites vu a varié.
[*] au cours des essais, j’ai trouvé que le défaut de branchement avec un canal [publish() ou subscribe()] 7 sept fois de suite fera l’unité "se bloquer". Je devine ici, mais c’est sans doute un moyen de défense de sécurité à la fin du PubNub pour protéger l’intégrité de la network(?) de flux
