La version simplifiée est opérationnelle ?
Bien, passons à l’étape suivante : enregistrer les données sur carte SD
Pour cela, il nous faudra installer la bibliothèque « SD » via le menu « Outils – Gestionnaire de bibliothèques »
Acheter un lecteur de carte SD tel que celui-ci pour moins de 10 € TTC :
Il va falloir également connecter le module lecteur de carte SD sur votre montage, puis téléverser le programme qui enregistre les données sur la carte SD.
Important
Les Arduino ne reconnaissent que les cartes formatées en FAT32 ou en FAT16 : Evitez le format NTFS ! Je conseille le format FAT32 puisque la version FAT16 est limitée à 4Go et qu’aujourd’hui, la plus petite carte qu’on puisse trouver dans le commerce fait au moins 8Go.
Câblage
La carte SD nécessite, en plus de son alimentation, d’être connectée à 4 PINS de l’Arduino. Ca commence à faire beaucoup avec l’Ecran LCD. D’autant que le port série émulé pour le GPS n’est possible que sur certains ports et que la carte SD nécessite impose d’utiliser les PINS du port SPI.
J’ai eu beau chercher dans tous les sens, ça ne passe pas. Heureusement il y a une solution : On peut piloter l’écran LCD par le port I2C de l’Arduino au travers d’un contrôleur dédié. Ceci libère 8 ports « classiques ».
Ils se connectent de manière naturelle, en plus on peut se débarrasser du potentiomètre car le contrôleur I2C en a un intégré. Sur l’image ci-dessous, on voit le contrôleur I2C comme s’il état « déplié » (lorsqu’il est connecté, il se trouve au dos de l’écran LCD, ces 4 PINS sont alors à votre gauche (au plus prêt du bord) si vous regardez l’écran LCD de face.
Comme l’écran LCD ne sera connecté qu’au travers du contrôleur I2C et plus directement, il va falloir modifier le programme. Et il nous faut installer une nouvelle bibliothèque : « LiquidCrystal_I2C » au lieu de « LiquidCrystal » précédemment utilisée.
Donc le GPS va changer de port ! son RX quitte le port D10 pour passer au D2
La briche signal du relais se connecte maintenant au D4
L’écran LCD se connecte en I2C aux ports SDA et SCL
Le lecteur de carte SD, lui se connecte au port SPI et sa broche CS (appelée quelque fois SS) va au D10.
Dans la 1ère version, j’ai utilisé la LED soudée à l’Arduino et reliée au D13 pour faire des clignotements lorsque le GPS fournit des données. Comme le port D13 fait parti du port SPI désormais nécessaire au lecteur de carte SD, je dois retirer le code qui réalisait cette tâche de clignotement.
Voici le tableau de câblage complet :
Notez bien que le port D3 de l’Arduino devient inutilisable (il est déclaré comme borne TX du port série et nous n’avons rien à envoyer au GPS)
| Connexion SDCARD | Connexion Arduino | Connexion SDCARD | Connexion Arduino |
|---|---|---|---|
| SDCARD GND | Alim GND | SDCARD VCC | Alim +5V |
| SDCARD MISO | Arduino D12 | SDCARD MOSI | Arduino D11 |
| SDCARD SCK | Arduino D13 | SDCARD CS | Arduino D10 |
| Relais + | Alim +5V | Relais - | Alim GND |
| Relais S | Arduino D4 | GPS VCC | Alim +5V |
| GPS GND | Alim GND | GPS TX | Arduino D2 |
| GPS RX | Non utilisé | GPS PPS | Non utilisé |
| Non utilisable | Arduino D3 |
Modification du programme pour utilisation de la carte SD
Il falloir que le programme puisse vérifier la bonne connexion du lecteur de carte SD, la présence d’une telle carte et que le type de format est bien exploitable (FAT16 ou 32).
Puis, on va disposer d’un espace pour enregistrer nos traces.
Ces traces seront dans un fichier. Il faut donner un nom à ce fichier. Si on se contente de « gps.txt », les traces seront chaque fois soit ajoutées, soit supprimées ce qui ne serait pas pratique.
Il vaut mieux que chaque trace soit associée à son propre fichier.
Comment le nommer ? Soit en utilisant une date/heure ,fourni par le GPS (un Arduino ne connait ni date ni heure sans périphérique qui la lui fournit) donc impossible de créer le fichier sans réception GPS (car lui seul fournis ces informations de date et d’heure). Mais est-ce grave ?
Soit par numérotation mais il faut mémoriser le numéro actuel hors le seul support de mémoire permanente accessible serait un fichier sur la carte SD.
Mais s’il porte un numéro, comment identifier le bon fichier à relire pour consultation d’une trace GPS sans les ouvrir tous ?
Bref, autant le nommer avec une date/heure de début d’enregistrement.
Mais problème : le système de fichier fournit par la bibliothèque SD est rudimentaire : nous ne pouvons utiliser que 8 caractères pour nommer le fichier ! Alors que vais utiliser le format DDHHMMSS (jour, heure, mois, seconde)
J’ai chercher à ajouter d’autres fonctionnalité (la gestion d’un horamètre interne. Mais malheureusement, même en faisant très attention, les 2Ko de mémoire de l’Arduino ne suffisent pas. Avec un Raspberry, cette tâche (et d’autres options) seraient aisément faisable.
Donc à chaque démarrage, le Arduino va vérifier que le lecteur de carte SD est bien présent et qu’une carte SD ey est insérée.
Puis il va lire les trames GPS. Si elles sont valides, il affichera des informations sur l’écran LCD. Si la vitesse mesurée est supérieur à speedmini, alors le relais se déclenchera ainsi que le début de la sauvegarde des trames GPS sur la carte SD.
Ces trames sont sauvegardées de manière brute. On ne dispose pas d’assez de mémoire sur le Arduino pour faire en même temps un fichier plus intelligent (comme un fichier kml)
Mais ce format (NMEA) est connu, sa structure est disponible sur internet (dont par exemple Wikipédia) et on peut transformer un fichier NMEA en fichier KML).
La prochaine étape sera la réalisation d’un tracker beaucoup plus intelligent à base de Raspberry. Là, les seules limites sont celles de votre imagination. Par contre, contrairement aux Arduino, les Raspberry sont de vrais PC, avec la problématique du temps de démarrage du système d’exploitation et de son arrêt propre.