[OSM-talk-fr] Smartphone Android avec GPS rapide?

Mer 11 Sep 14:46:58 UTC 2013

> Avec les 3 grandes constellations (américaine, russe, européenne, et
bientôt aussi
> la constellation chinoise) on devrait pourtant maintenant avoir un
positionnement
> précis à moins de 5 mètres et un rafraîchissement des positions toutes
les secondes
> ou moins (mais les GPS qui font ça ne sont pas vendus au grand public).

Nota : On ne gagne pas en précision en usage normal. Les derniers Garmin
comme beaucoup d'autres sont multi constellation (Glonass + GPS) mais la
meilleure précision est en GPS simple (d'ailleurs, Glonass est
automatiquement désactivé lorsque le GPS est correctement reçu). Le seul
intérêt du multi constellation est une acquisition plus rapide de la
position puisque plus de satellite sont dispo. Peut également etre utile en
milieu fortement perturbé. En cas nominal, c'est plutot une gene, la
précision est meilleure avec un GPS seul et idéalement un différentiel
(Wass/Egnos) en plus. On est déjà dans ce cas dans la plage 3/5m

Le 11 septembre 2013 15:56, Marc SIBERT <marc at sibert.fr> a écrit :

> Bonjour,
>
> et désolé d'alimenter le troll (et pourtant j'ai aussi mis en place une
> règle de suppression des messages (ad nominem) mais il y a trop
> d'approximations dans ce commentaire.
>
> Le 11 septembre 2013 15:30, Philippe Verdy <verdy_p at wanadoo.fr> a écrit :
>
> Un truc en cours de développement chez Microsoft devrait arriver sur les
>> smartphones pour les rendre moins énergivores sur leur fonction GPS:
>>
>>
>> http://www.futura-sciences.com/magazines/high-tech/infos/actu/d/technologie-puce-gps-moins-energivore-grace-cloud-computing-43848/
>>
>> Je me suis toujours demandé pourquoi le GPS bouffe autant d'énergie alors
>> qu'il ne s'agit que d'écouter un signal satellite avec un codec largement
>> matériel (pas plus compliqué que d'écouter un signal GSM) en veille, un
>> chrono précis par matériel qui devrait ne pas consommer plus qu'une montre,
>> et un peu de calcul de trigonométrie, un peu complexe certes mais seulement
>> une poignée de microsecondes et à faire toutes les 5 secondes maxi....
>>
>> Grosse erreur, il ne s'agit pas que d'écouter un signal et de le
> démoduler car ta culture que tu étales aurais du t'apprendre que tous les
> satellites GPS d'une constellation émettent sur la/les mêmes fréquences et
> qu'il faut donc bien plus qu'une démodulation en saut de fréquence... et
> pour aller dans les approximations, il me semble que le niveau du signal à
> l'arrivée est inférieur au bruit thermique de la puce ce qui laisse rêveur
> sur les algo pour extraire le signal.
>
>
>> Mais voilà les satellites GPS ont des trajectoires compliquées à suivre
>> et l'idée est d'utiliser un serveur sur Internet pour calculer leur
>> position instantanée et simplifier le traitement par des interpolations et
>> triangulations beaucoup plus simples. Malgré tout pourquoi cela devrait
>> diviser par 2000 la consommation de CPU comme l'affirme l'article ?
>>
> Une trajectoire compliquée, mais oui c'est bien connu que ces bestioles
> marchent en crabe. C'est n'importe quoi.
>
>>
>> Et pourquoi cela doit être sur un serveur cloud Microsoft, et pas sur un
>> projet open-source ? Est-ce que c'est à cause des licences et
>> spécifications propriétaires des fournisseurs GPS qui ne diffusent que des
>> bibliothèques pas assez optimisés ou alors qui tentent de corriger des
>> erreurs de mesure liés à certains effets de terrain ou des masquages
>> temporaires, en utilisation une longue liste historiques de mesures
>> successives.
>>
> Maintenant c'est la théorie du complot...
>
>>
>> Ceci dit, la précision obtenue par cette technique n'est pas
>> exceptionnelle : 35 mètres. Tout ceci laisse penser qu'en fait c'est la
>> densité encore trop faible des satellites GPS dans le ciel qui limite la
>> précision et ne permet pas des triangulations assez précises : données
>> insuffisantes statistiquement.
>>
> Non pas vraiment, ne te laisse pas aller à penser... Les perturbations
> sont différentes, lié aux stabilité des horloges (satellite et récepteur),
> aux perturbation des ondes lors du parcours satellite / récepteur et autres
> réflexions. Qui plus est les récepteurs récents sont capables d'utiliser
> les différentes constellations pour augmenter le nombre de satellite
> utilisables.
>
>>
>> Avec les 3 grandes constellations (américaine, russe, européenne, et
>> bientôt aussi la constellation chinoise) on devrait pourtant maintenant
>> avoir un positionnement précis à moins de 5 mètres et un rafraîchissement
>> des positions toutes les secondes ou moins (mais les GPS qui font ça ne
>> sont pas vendus au grand public).
>>
> Si ça vient, il a même des dev avec la RTKLIB (libre) qui permetent ça.
>
>
>> Et même si chaque constellation a ses spécificités en terme de
>> codification, chacune va finalement aboutir à utiliser les mêmes données de
>> base : la position de chaque satellite dans le ciel (convertie en
>> coordonnées cartésiennes), leur référence horaire, et un facteur de qualité
>> statistitique de leur signal capté. (??? ah bon ? t'as vu ça où ?)
>>
>> L'autre problème du GPS est aussi le fait qu'il faut syntoniser l'antenne
>> sur toute une série de canaux de fréquences, et même en parallélisant cela
>> par une réception unique, c'est la taille des transformées de Fourier à
>> calculer (selon le nombre de canaux à écouter) qui bouffe de la CPU
>>
> C'est hardcodé, pas en CPU
>
>
>> , même avec une assistance matérielle. Pourtant une puce GPS pourrait ausi
>>
> C'est pas la peine de faire des suggestions de conception aux fabricants
> de puces, ils ont déjà eu cette idée.
>
>
>>  intégrer une douzaine de syntoniseurs matériels programmables (selon la
>> liste des autres satellites observables, une liste qui nécessite un
>> balayage initial pour les chercher, mais qui n'évolue que très lentement)
>> sans avoir à faire des calculs lourds de transformées de Fourier pour
>> obtenir les signaux numériques nécessaires, sans consommer autant qu'une
>> puce de modem DSL.
>>
>> La fonction GPS des smartphones ne semble pas gérer en fait des données
>> historiques pour les éphémérides déjà précalculés.
>>
> Les puces le font (d'où la différence de temps de reprise du signal entre
> démarrage à chaud ou à froid - avec re-acquisition des éphémérides)
>
>
>> Ca peut expliquer un gaspillage des ressources si tout le calcul est
>> repris depuis le début comme si on n'avait aucune donnée préalable avant.
>>
>> Tout le reste c'est une triangulation 3D simple qui consiste à estimer le
>> centre d'intersection commune de plusieurs sphères (dont le rayon de
>> chacune dépend de la précision de mesure de chaque signal), avant de
>> reprojeter le point 3D obtenu en coordonnées géodésiques (on peut intégrer
>> aussi dans le calcul les sphères de positionnement des stations relais GSM,
>> ou comme le fait Google, celle des hotspots Wifi publics et privés
>> identifiés par leur leur SSID ou mieux encore par leur adresse MAC sur les
>> hotspots ouverts).
>>
>
>> S'il y a des spécifications publiques (ou du reverse engineering...) il y
>> a une large place pour un développement open-source, sans même avoir à se
>> connecter à un serveur cloud de Microsoft (ou de Google, qui voudra le
>> faire aussi pour obtenir notre géolocalisation sur ses serveurs avant même
>> de retourner l'information calculée à nos smartphones), et ça éviterait
>> aussi de consommer de la (chère) bande passante data sur un réseau mobile.
>>
> Déjà évoqué ! cf RTKLIB.
>
>>
>>
>> Le 11 septembre 2013 14:31, Shohreh <codecomplete at free.fr> a écrit :
>>
>>> Bonjour
>>>
>>>
>>> J'ai deux solutions pour prendre des photos avec infos GPS:
>>> - un smartphone  Google Galaxy Nexus
>>> <http://en.wikipedia.org/wiki/Galaxy_Nexus>
>>> - un APN  Sony DSC-HX20V
>>> <
>>> http://www.lesnumeriques.com/appareil-photo-numerique/sony-cyber-shot-hx20v-p12889/test.html
>>> >
>>>
>>> Je n'ai pas encore utilisé la fonction GPS du Sony, mais je sais
>>> d'expérience que le GPS du Nexus peut mettre plusieurs minutes à se
>>> repérer
>>> (vu ce que ça bouffe comme batterie, le mode GPS est éteint en temps
>>> normal), donc beaucoup trop lent lorsque j'ai envie de prendre une photo
>>> d'un truc et l'ajouter dans OSM en rentrant. Il est possible que le
>>> reflasher en CyanogenMod puisse améliorer la synchro.
>>>
>>> Existe-t-il des GPS plus rapides à connecter par la prise USB? Je pense
>>> par
>>> exemple à un  A-GPS <http://en.wikipedia.org/wiki/Assisted_GPS>
>>> externe
>>> qui pourrait assister le Nexus.
>>>
>>> Sinon, quels smartphones Android sont-ils connus pour être rapides à se
>>> connecter?
>>>
>>> Merci.
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://gis.19327.n5.nabble.com/Smartphone-Android-avec-GPS-rapide-tp5777133.html
>>> Sent from the France mailing list archive at Nabble.com.
>>>
>>> _______________________________________________
>>> Talk-fr mailing list
>>> Talk-fr at openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>
>>
>> _______________________________________________
>> Talk-fr mailing list
>> Talk-fr at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
> Ya pas, t'es un boulet. Aller je repasse en mode {ignore_P_Verdy = yes} --
> Ya un tag pour ça ?
>
> A+
>
> --
> Marc Sibert
> marc at sibert.fr
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20130911/2d230a14/attachment.htm>