Enregistrement trames GPS NMEA

Bonjour,

J’ai récupéré il y a peu un GPS (ou plutôt GNSS) de bonne qualité (XM1110) avec la capacité d’envoyer des trames à 5Hz avec SBAS (Satellite Based Augmentation System pour une meilleure précision en fait) et 10 Hz sans ces derniers. Couplé à une bonne antenne il semble d’une meilleure précision que les GNSS intégrés de smartphones. Coté radio ça se tient.

Autour de chez moi en vélo je référence des chemins sur OpenStreetMap (abrégé OSM), et ayant des arduinos de coté je souhaitait faire un enregistreur dédié sur une carte SD.

Le GNSS, tel que je l’ai paramétré envoi des trames NMEA toute les secondes (plus tard je passerais à 5Hz).

Mon but est d’envoyer ces trames directement à l’arduino qui lui, enregistre directement les trames brutes sorties. Je ne souhaite pas convertir les trames en GPX, je le fait depuis mon PC avec gpsbabel-gui qui le fait très bien.

Le projet est très simple mais j’ai toute les peines du monde a avoir un résultat correct ; j’ai tenté avec le sketch ci-dessous d’enregistrer les données mais ça ne fonctionne pas pourtant il est très simple.

Sur la première image on voit des données tout à fait correctes, issue d’un exemple Software Serial qui permet de recopier directement les données envoyées par le GPS sur le port série USB de l’arduino directement.

Sur la seconde on voit le fichier avec le début des trames uniquement, pas à la ligne, manque des données.

Auriez vous des idées afin de régler ce problème ? C’est une chose simple que je souhaite faire pourtant.

sketch_sep06a.ino (845 Bytes)

Voilà les trames qui ne sont pas passées au premier post.

Il faut procéder par étape. Comment se présente ton GPS? XM1110, c'est juste la puce. En général, elle est installée sur une carte pour pouvoir établir les connexions.

Ensuite, c'est avec quelle carte arduino?

Tu es sûr de tes vitesses de transmission?

Avant d'envoyer vers la carte SD, est-ce que tu peux simplement envoyer vers le terminal et regarder sur l'ordinateur si tu reçois bien ce qui attendu?

Bonsoir, merci d'avoir répondu,

Oui c'est juste une puce que j'ai isolé. En fait c'est une carte de récupération et ne pouvant pas la souder ailleurs proprement je l'ai gardé dessus d'autant que l'antenne est intégrée.
J'ai soudé directement sur les pin de la puce et retiré les connexions qui pouvaient perturber avec l'ancien microcontrôleur. J'ai installé donc deux fils + alim pour pouvoir parler avec la puce.

J'ai flashé le firmware pour avoir les valeurs par défaut (UART à 115200 bauds, actualisation des trames NMEA toute les secondes), tout ce qu'il faut.

Une fois ceci fait dans un terminal avec un adaptateur USB-TTL je pouvais voir les trames de manière très nette sans aucune coupure, résultat satisfaisant.
J'ai abaissé la vitesse de transmission de 115200 à 19200 pour éviter les erreurs de transmission au cas où. J'ai tenté sur un arduino nano de retranscrire tout ce que je recevais directement dans le terminal.
Ca fonctionne, ça laggue un peu plus mais globalement ça fonctionne, des fois ça oublie des caractères, pourtant c'est pas de la haute vitesse mais je finis par me demander s'il est capable de recevoir autant de caractères et de les faire suivre.

J'ai vu sur internet des "Openlog" a base de Atmel 328p, en somme le même processeur, mais je n'ai aucune idée de sa capacité dans cette application.

À la louche, quand je regarde ta copie d’écran, je dirais que tu as 1000 caractères par seconde. Rien d’extraordinaire. Est-ce qu’il peut y avoir des problèmes de buffer pas vidé assez vite?

Je travaille sur un enregistreur de données GNSS brutes. J’avais des problèmes d’enregistrement sur la carte µSD. J’ai résolu ça en réduisant la vitesse du bus SPI. Ensuite, j’ai essayé une acquisition à 10 Hz et ça va bien (30 ko/s). Rien à voir avec ton débit mais pas le même processeur non plus.

Bonsoir,
Justemment comment tu fais pour le gérer ce fameux buffer ? Il se vide tout seul ?

Ah oui je vois le F9P c'est plus gros, et tu n'enregistres pas les mêmes type de données. Tu va ensuite utiliser les RTKlib pour finir de corriger ?

Ca semble pas logique qu'en baissant la vitesse du SPI ça se passe mieux, ça devrait être 'inverse non ?
Tu utilises quoi comme processeur ?

Je pensais tenter d'utiliser le CR/LF comme déclenchement d'enregistrement, je vais me documenter sur le sujet sur le sujet du buffer déjà