Choix des composants pour traceur GPS

[yop21]

Bonjour,

j'ai pour idée de concevoir mon propre traceur GPS (fabriquer moi même mon PCB etc). Dans un premier temps je cherche à m'informer sur le sujet et peut-être par la suite en faire un projet dans mon école.

Pour commencer voici un petit schéma de principe:

Image supprimée

Tout serait articulé autour d'un microprocesseur. Il y aurait un module GPS pour capter la position et la donner au Uprocesseur qui la sauvegarderait dans sa mémoire ou une externe si besoin. J'aimerais ensuite pouvoir transférer ces données sur un PC ou smartphone par bluetooth. Bien entendu le système sera alimenté par une batterie (10h d'autonomie). Le connecteur USB servira a programmer le Uprocesseur et à recharger la batterie.

Comme je l'ai dit plus haut, j'en suis au stade de renseignement, je viens chercher vos conseils et vos expériences. Qu'est-ce que vous me conseiller comme composants?

J'ai déjà pensé à quelque-uns.

Microprocesseur: atmega32U4
GPS: MT3339 FGPMMOPA6H
Batterie: 3.7V 500mA

Qu'est-ce que vous en pensez?

Merci
-----

[JPL]

Les images doivent être postées en pièces jointes et non sur un serveur extérieur. Merci.

[inoxxam]

Oui, tu peux y arriver avec ça en principe, plus évidemment d'autres autour, mais le coeur est là. En revanche ça n'est peut être pas le plus adapté. Quels sont précisément tes besoins? (je pense notemment à la fréquence de log). Sur quels critères as-tu choisi ces composants?

[yop21]

Je pensais faire une acquisition par seconde pour commencer. Pour l'utilisation que j'en aurai cela suffit.

Une de mes principales préoccupation est la taille. Pour le choix des composants j'ai pris un peu ce que je trouvais . . . Je n'ai pas beaucoup d'expériences dans le domaine donc c'est difficile de trouver les composants adaptés.

Pour le mdule bluetooth j'ai trouvé ceci: http://www.distrelec.ch/fr/CI-faible...e=10&simi=99.8

[A voir en vidéo sur Futura]

[inoxxam]

L'expérience, ça viendra en faisant. Ce module peut faire l'affaire. Attention cependant, t'as déjà le GPS qui pompe pas mal de jus, le bluetooth c'est aussi plutôt gourmand en énergie, il va falloir bien gérer ça. Vu ce que tu décris, tu n'as cependant pas besoin d'avoir le bluetooth alimenté en permanence (juste pour récupérer les données si j'ai bien compris).
En revanche, logger 10h durant à 1Hz, ça fait un petit paquet de données déjà. Sur quoi comptes-tu stocker tout cela?

[Bluedeep]

En revanche, logger 10h durant à 1Hz, ça fait un petit paquet de données déjà. Sur quoi comptes-tu stocker tout cela?

Pas vraiment : il faut 12 octets pour stocker une coordonnées GPS 3D avec une précision "normale" (en IEEE 4 octets).
Soit environ 550 ko pour 10h de stockage en comptant l'horodatage. (sur 4 octets également, mais 2 suffisent pour 10h).

[inoxxam]

Pas vraiment : il faut 12 octets pour stocker une coordonnées GPS 3D avec une précision "normale" (en IEEE 4 octets).
Soit environ 550 ko pour 10h de stockage en comptant l'horodatage. (sur 4 octets également, mais 2 suffisent pour 10h).

550 ko pas vraiment un paquet de données? Et tu les fais tenir comment dans les 1024 octets d'EEPROM dont dispose un atmega32U4?

[Bluedeep]

550 ko pas vraiment un paquet de données? Et tu les fais tenir comment dans les 1024 octets d'EEPROM dont dispose un atmega32U4?

En effet !!

Désolé, l'embarqué n'est pas du tout ma spécialité. J'ai plutôt l'habitude de travailler avec des dizaines de To de données.

[yop21]

Effectivement je pensais mémoriser tout ça sur une mémoire EEPROM externe.

Pour la consommation le bluetooth sera presque toujours éteint donc c'est déjà ça d'économiser. Sinon pour économiser sur la consommation du processeur, j'ai pensé au ARM cortex M0+ qui est idéal pour les applications basse consommation. Des avis?

Il faut encore que je regarde comment communiquer avec les modules, bluetooth, GPS et EEPROM pour être sûr que le processeur que je choisirai fonctionne avec.

[bobflux]

Une EEPROM c'est, en gros, la même chose qu'une mémoire flash, mais on peut modifier les octets un par un au lieu de devoir effacer une page complète et la réécrire. C'est fait pour stocker quelques octets et les modifier facilement. C'est pas du tout fait pout stocker des "grosses" quantités de données, genre, plus de 1ko...

Un stockage sur carte µSD serait bien, c'est pas cher, et le problème du lecteur est résolu d'office.

[yop21]

Salut,

Merci pour ton idée bobfuck, mais l'utilisation d'une carte uSD n'est pas envisageable dans mon projet. Mais par contre je peux utiliser une mémoire flash de 1M comme ça je suis tranquille.

Si je résume un peu les modes de communications:

GPS: UART
Bluetooth: UART
Mémoire flash: SPI

Si je regarde les ARM cortex M0+, ils ont l'air d'avoir tout ce qu'il faut. Des avis?

[bobflux]

OK, 2ème choix : une flash SPI de plusieurs Mo à 50 centimes, c'est très bien aussi...

> Si je regarde les ARM cortex M0+, ils ont l'air d'avoir tout ce qu'il faut. Des avis?

Oui, ce sont des bons micro modernes sans les petites tares congénitales des 8 bits, genre "registres non génériques" (what ?) ou "2 timers 8 bits" (lol). Mais comme arm-gcc est au point, on regarde pas souvent le code machine....

J'utilise les chips de chez NXP (LPCxxxx) avec le kit de dév LPCXPresso et debugger LPC-Link 2.

L'avantage c'est que les outils et cartes coûtent que dalle (10-20 €...), l'environnement de dév est sympa (basé sur Eclipse donc un peu débile, mais bien utilisable).

Par contre la sonde de debug a ses humeurs. Faut le savoir. Quand elle boude, il faut débrancher et rebrancher l'USB... Il faut pas la provoquer, faut cliquer sur les boutons dans le bon ordre (par exemple si tu modifies ton code et que tu recliques sur "Debug" sans avoir cliquer sur "Terminer" pour sortir de ta session de debug en cours, tu auras le droit de débrancher et rebrancher )

Le LPC-Link 1 est d'une lenteur infâme. Le LPC-Link 2 est bien (genre 5s pour flasher le micro et lancer le programme, ça va).

Le debug est très bien. Tu peux examiner chaque variable, les emplacements mémoire, etc, enfin un vrai debugger, comme pour un programme de PC, en légèrement moins réactif certes. C'est bien de ne pas avoir besoin d'une sonde à 200€ pour faire ça...

Il paraît que les micro de chez ST sont très bien aussi dans le style.

Concernant la consommation, de toutes façons le module GPS consommera 10x plus que le micro, donc pas la peine de choisir spécifiquement un micro ultra-basse conso. Il suffira d'utiliser les modes sleep.

PS : Un GPS Garmin Dakota tient environ 20h sur 2 piles AA (plus en coupant l'écran) et fait ce que tu veux pour un prix raisonnable... quand à la qualité de la réception GPS, elle est plutôt bonne.

[yop21]

Merci pour toutes ces explications, c'est vraiment très intéressant.

Je vais regarder tout cela en détail et je vous tien au courant.

[inoxxam]

Les micros à base de Cortex M0+, pourquoi pas. Dans cette lignée je ne peux que te conseiller les STM32L0 qui sont d'excellents micros. Après, je n'ai pas d'actions chez ST, mais un petit biais pour leurs produits quand même.

[yop21]

Salut,

alors pour le microprocesseurje pense que je vais me tourner vers celui-ci: http://ch.farnell.com/jsp/search/pro...jsp?id=2212797
La plateforme de développement est bon marcher et un ami l'a utilisé pour un système embarqué alors il pourra toujours m'aider.

[Murayama]

Bonjour!

À tout hasard, j'ai fait un logger GPS il y a assez longtemps. Il est sur le net
avec explications du programme, il suffit de chercher. Mais il mettait les données
dans une carte SD uniquement.
Par contre, j'en ai fait un autre, avec affichage LCD, stockage dans une flash
SPI, (à tout hasard, j'ai mis aussi une carte µSD). Si ça peut vous donner des idées...
Il est de plus conçu pour fonctionner directement sur une dynamo axiale (dans l'axe de la
roue d'un vélo). J'ai donc utilisé un pont de FETs plutôt qu'un pont de diodes, ce qui
permet de ne pas perdre 1.4V. Il a aussi une batterie Li-Pol, un système de charge
(MCP73837), ce qui permettra de faire fonctionner le phare même à l'arrêt.
J'en ai profité pour ajouter un accéléromètre, un compas et un altimètre.
C'est du travail d'après 17 heures, donc les progrès ne sont pas fulgurants, mais ça
commence à donner des résultats.
La photo jointe montre l'appareil. Je n'ai pas encore soudé l'accéléromètre, le
compas et l'altimètre, mais je sais pour les avoir utilisés dans d'autres projets
qu'ils fonctionnent sans problème. Bon, je vais le brancher pour faire un petit essai
vu que ça fait un moment que je n'y ai pas touché [...]
La photo:
En haut à gauche: le circuit imprimé. J'ai mis une carte bancaire derrière pour donner
une idée de la taille (96 x 50 mm). Le processeur est un MSP430F5529.
Le strict minimum est soudé (pour vérifier que le GPS fonctionne et qu'on peut enregistrer
dans la flash SPI qu'on aperçoit derrière le câble. C'est une 32 MB, ce qui est déjà
beaucoup trop, et en plus j'en ai mis 2 (on voit la place de la 2ème).
À droite, une vue avec le LCD. Je n'ai pas encore taillé la pièce de plastique pour
le fixer.
Centre gauche: le revers. On voit le connecteur de batterie (Li-Pol) et la batterie.
(le + et le - ne correspondent pas à la place des contacts, erreur du fabricant. Ils sont
bien en face du connecteur 3 broches). On voit aussi, partiellement caché par la batterie
les contacts qui permettent grâce à un connecteur à ressorts de programmer l'appareil par JTAG.
Centre droit: les données NMEA affichées. J'étais à pied plutôt qu'à vélo parce que
c'est plus facile de prendre une photo en se déplaçant. Le format est un peu curieux:
degrés, minutes, et 1/10000 minute.
En bas: 2 autres écrans que j'ai récupérés d'une autre applications pour la mise à jour
du calendrier. Affaire à suivre.

Pascal

[yop21]

Salut Murayama,

vraiment très intéressant ! Merci de partager ton projet. Qu'as-tu utilisé comme GPS?

Yop

[Murayama]

Bonjour!

Le GPS, pour être franc, je ne sais plus où je l'ai acheté, et en plus il y a pas mal de temps.
Je viens de regarder: la première description que j'ai publiée date de début 2007...
D'ailleurs rien qu'à le voir, on comprend que ce n'est pas d'aujourd'hui.
Mais c'était chez Digikey ou Mouser.

Remarques en vrac:
- J'ai utilisé non pas des EEPROMS mais des FLASH. La raison est qu'il est difficile de trouver
des EEPROMS de grande taille en 8 pattes et au format TDFN / VDFN, etc...
Le maxi sur Digikey est 1 MBit pour les EEPROMs et 256 MBit pour les flash pour des prix
comparables. Évidemment, pour une flash, il faut écrire une page à la fois, donc avoir assez de RAM,
mais de nos jours, c'est presque toujours le cas. Une page est généralement 256 bytes
dans les flash SPI (264 pour les ATMEL AT45). En écrivant une interface, il est parfaitement
possible d'écrire un seul byte à n'importe quel endroit de la flash, donc l'argument concernant
la possibilité d'écrire byte par byte tombe de lui-même.
Concrètement, j'ai un objet FlashTool dans ce genre là:

class FlashTool {
public:
    // Constructor, destructor skipped
    void WriteByte(int32 where, uint8 what);
    uint8 ReadByte(int32 where);
    void WriteBuf(int32 where, uint8 * buf, int16 len);
    int16 ReadBuf(int32 where, uint8 * buf, int16 len);
protected:
private:
    int32 mCurrentPos;
    uint8 mCrtFlashPage[PAGE_SIZE];
}

Il est donc possible d'écrire un seul byte n'importe où.
- Le choix du processeur ne repose sur rien de solide: je l'utilise pour d'autres projets, donc
je peux pomper une grande partie du schéma et des drivers. Mais on pourrait faire la même chose
avec un MSP430F5510 qui doit être 2 fois moins cher que le 5529.
- On pourrait penser que vu que le GPS donne l'altitude, il n'y a pas besoin d'altimètre.
Par contre, d'après les essais que j'ai faits, l'altitude du GPS n'est pas précise du tout,
mais c'est une altitude absolue. L'altitude en utilisant un baromètre par contre a une grande
résolution, de l'ordre de 10 cm, mais pas de précision absolue puisque la pression change.
Les deux peuvent se combiner pour avoir le beurre et l'argent du beurre.
- Il serait possible d'ajouter un module Bluetooth sans trop d'effort. Par contre,


Pascal

[yop21]

Merci pour ces informations complémentaires Pascal.
Tout comme toi j'ai décidé d'utiliser une flash pour des raisons de capacité mémoire.

Je vous tiens au courant de mon avancement

[Murayama]

Bonjour!

Tiens, je m'aperçois que je n'avais pas fini ma phrase. Or donc:
Par contre, la bande passante de BlueTooth (en particulier low energy) me
semble un peu faible pour transférer les données sur le PC.
Ex: pour décharger ma flash de 32M, même à 10 k par seconde (ce qui ne
sera probablement pas le cas), ça prendra une heure.

Pascal

[bobflux]

> Évidemment, pour une flash, il faut écrire une page à la fois

Il faut effacer une page entière, mais après, on peut écrire octet par octet, voire bit par bit... L'effacement reset tous les bits à 1, l'écriture les met à zéro. D'ailleurs on peut écrire plusieurs fois au même endroit sans effacer, mais on ne peut que rajouter des bits zéros...

> l'altitude du GPS n'est pas précise du tout,

En effet...

Le Garmin Dakota que j'ai utilise l'altimètre (capteur de pression), et le calibre avec le GPS (peut-être aussi avec les données altimétriques de la carte). Le vrai altimètre c'est bien parce que ça permet d'avoir un vario, qui donne le taux de montée, très pratique en vélo pour arriver pas fatigué en haut... Beaucoup plus pratique que l'altitude d'ailleurs, qui ne sert qu'à se la péter en comptant le dénivelé.

[Murayama]

Bonjour!

Il faut effacer une page entière, mais après, on peut écrire octet par octet, voire bit par bit...

C'est juste, mais dans le cas général, si je veux écrire un byte à l'adresse a,
je dois:
- copier dans un buffer la page (a / PAGE_SIZE)
- écrire la valeur désirée à l'adresse (a % PAGE_SIZE) dans le buffer
- effacer la page (a / PAGE_SIZE) dans la flash
- recopier le buffer dans la page (a / PAGE_SIZE)

Mais c'est vrai qu'en écriture séquentielle, on peut d'abord effacer toute la flash et écrire
byte par byte.

Beaucoup plus pratique que l'altitude d'ailleurs, qui ne sert qu'à se la péter en comptant le dénivelé.

Ben le dénivelé est tout de même une bonne indication sur l'énergie dépensée...

Pascal

[bobflux]

> Mais c'est vrai qu'en écriture séquentielle, on peut d'abord effacer toute la flash et écrire

On efface une page et puis on l'écrit progressivement (il faut éviter de refaire toute la copie/effacement à chaque octet sinon ça va user la flash très vite)

[Murayama]

Bonjour!

On efface une page et puis on l'écrit progressivement (il faut éviter de refaire toute la copie/effacement à chaque octet sinon ça va user la flash très vite)

Je ne pense pas avoir dit qu'il fallait effacer une page à chaque fois quand on écrit séquentiellement.
Seulement quand on écrit un byte de façon aléatoire n'importe où, d'où la méthode proposée plus haut.

Pascal