Le câble USB est-il nécessaire ? En mobilité c'est peu pratique de se balader avec une forêt de câbles autour de soi (déjà qu'il faut un câble pour une antenne externe, voire déjà des cables chargeurs USB pour connecter cet appareil et le smartphone à une batterie externe ou un hub USB sur un véhicule ou une prise allume-cigare si on veut de l'autonomie. A pied ou en vélo, ces câbles sont gênants.
Une version avec connexion Bluetooth (ou USB Wireless) permettrait au même smartphone de suivre le flux des géolocalisations fournies par l'appareil avec pour chacun leur batterie intégré. Reste à voir la consommation du composant de connexion sans fil (je pense que Wifi est déjà hors jeu, mais Bluetooth convient très bien). Evidemment il reste alors à développer l'appli pour le smartphone détectant le GPS externe ; que ce soit par cable USB, ou une connexion sans fil, voire Wifi si vous optez ce choix, et la méthode d' appairage et reconnaissance des appareils entre eux. A moins que le GPS que vous comptez faire se contente de diffuser librement vers n'importe quel appareil à proximité reconnaissant son protocole envoyé en mode "broadcast", sans besoin de faire aucune manipulation préalable d'appairage Sur le smartphone en revanche la réception de flux de données diffusées en "broadcast" sans appairage peut constituer un blocage de sécurité propre à l'OS mobile utilisé et donc pourrait nécessiter une élévation de privilège ou le "rootage" du smartphone, ce qui n'est pas toujours facile à faire et parfois pas possible, ou qui demande parfois sur certains appareils des manipulations constantes pour réactiver les autorisations nécessaires. Une connexion par appairage classique en revanche est bien plus stable et ne nécessite aucun "rootage", juste l'activation éventuelle d'un mode "débogage USB" dans les options d'Android, iOS, ou Windows Phone, ou l'activation du mode "Hub Wifi" pour le smartphone (à la place du mode "client wifi" par défaut). Tous les smartphones en revanche n'ont pas le mode "connexion Wifi Ad-Hoc" (pair-à-pair, d'égal-à-égal) qui est en revanche le mode le plus proche de connexion avec BlueTooth (sans aucun "hub"). On peut aussi imaginer que l'appareil GPS ne sera pas utilisé qu'avec un smartphone mais avec un PC ou un portable classique sous Windows, Linux, MacOS. Le protocole de connexion doit utiliser des techniques les plus standards de connexion et ne pas nécessiter là aussi des privilèges élevés sur l'OS, ni même l'installation d'un pilote système, il devrait fonctionner avec les pilotes de base des OS les plus courants, avec leur panneau de configuration système (réseau, et sécurité) classique. Le stockage sur le GPS devrait être accessible en mode "storage mass" (type MTP par USB : on voit une liste de fichiers dans un dossier partagé, mais si la connexion MTP est active, il peut être difficile de synchroniser les fichiers si le GPS est en cours d'enregistrement; sur de nombreux smartphones, la connexion MTP est "captive" et bloque les accès en écriture aux dossiers partagés par MTP, c'est le PC connecté qui les contrôle durant toute la connexion et peut lui seul modifier ces fichiers ou en supprimer; pour bénéficier de flux "live" en USB, c'est l'option "débogage USB" qui active sur le Hub interne du smartphone une route d'entrée pour ces flux, et il faut un privilège pour pouvoir ensuite les lire depuis une application: les autres applis sur le smartphone ne doivent pas pouvoir les lire si elles n'ont pas été autorisées explicitement). Donc faire un choix : juste USB, ou bien USB avec l'ajout de Bluetooth ou USB Wireless ? Et quelle classe de débit ? (Il me semble que le débit nécessaire pour capter en continu les positions GPS est très faible, quelques octets par seconde, et qu'à ce débit la consommation d'énergie devrait rester très faible, ce qui n'est pas le cas du Wifi en général.) Le Wifi me semble plus compliqué à gérer et plus gourmand en ressources (et avec beaucoup plus de barrières de sécurité qui se sont ajoutées à cause des nombreux risques d'Internet : parefeu, limitations de bande passante, adaptation de débit, ports privilégiés, protocoles de routage, UPNP, restrictions sur UDP et ICMP, tailles des tampons pour TCP, taille maxi des MTU, fragments IP, options de routage IPv4 ou IPv6, authentification, détection et autorisation des routeurs, plages d'adresses IPv4 ou IPv6 non routables réservées pour l'adressage local sans conflit avec les plages des routeurs, le fait aussi que les connexions Internet mobile utilisent aussi des adresses IP "locales" avec le routeur-proxy distant, etc.). Il me semble qu'il vaut mioeux ne pas y toucher et laisser ça sur les smartphones et PC pour leur communications Internet et ne pas y toucher pour autoriser des accès aux périphériques locaux comme un GPS portable à proximité (au risque sinon de compromettre ou réduire la sécurité de l'accès Internet). Le 23 mars 2018 à 02:20, <osm.sanspourr...@spamgourmet.com> a écrit : > > 6) Autre chose ? > > Un point important pour moi est de pouvoir photographier l'écran > facilement pour pouvoir garder trace de la position d'une photo car les > appareils réflex n'ont généralement pas de gps intégré. Donc cela implique > un écran qu'il soit possible de rétro-éclairer. > > Peu compatible avec la version "sans écran" ;-). > > Les appareils numériques même sans GPS ont une horloge interne. Si elle > est règlée correctement (et sinon en calculant le décalage après coup), un > logiciel peut prendre les données EXIF des photos, le GPX du collecteur > GNSS. > Je serais même pour simplifer encore : mettre un câble µUSB entre le > collecteur GPS et le téléphone pour que ce soit le téléphone qui > enregistre. Si tu veux plus de mémoire, tu changes la carte µUSB du > téléphone. > Si le collecteur envoi du NMEA, les applis doivent savoir gérer quitte à > en avoir une qui marche (style hyperterminal en version brute). > > J'ai un câble tient très bien mais c'est un RS232/DB9 à l'autre bout. Les > USB marine (pas fileté sur contre écrou) tiennent aussi bien mais c'est > plus gros qu'un µUSB classique. > > Oui il faut que les câbles tiennent bon et ce n'est pas gagné. > Jean-Yvon > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
