Réception des trames GPS

[Temps-x]

Bonjour pspic, et tout le forum,

Merci pour ta réponse, ça va m'aider à me renforcer dans mon programme, comme ça si ça fonctionne pas je serais que ça vient pas du branchement.

Bon j'ai des bibliothèques à développer en ASM, je sens que je vais vraiment m'amuser avec ce GPS, je mettrais comme d'habitude la source sur Fantas-Pic avec vidéo, de plus je compte faire un petit programme pour PC.

C'est vraiment pratique pour avoir l'heure, date, position, de plus on peu activer n'importe quelle dispositif à la date et heure programmé.

Par contre il faut quand même prévoir un comptage de temps si pas de réception GPS

J'ai remarqué avec U-center qu'il faut une bonne antenne, ça fonctionne du moment que l'antenne soit à l'air libre ou peu couvert.

Je que s'obtient sans antenne extérieur, mais avec un passage de satellite favorable à cette heure là

U-center.jpg

A+

[pspic]

Bonjour Temps-x,

C'est vraiment pratique pour avoir l'heure, date, position, de plus on peu activer n'importe quelle dispositif à la date et heure programmé.

Pour obtenir la date et l'heure avec précision, je préfère utiliser un module RTC DS3231 alimenté par une pile CR2032 (non rechargeable) et à lequel je fais subir une intervention chirurgicale pour supprimer la fonction "pile rechargeable".
Pour la mise à jour après remplacement de la pile j'utilise une App Android en liaison Bluetooth.
Dans les deux cas il faut gérer le changement d'heure été / hiver par programme.
Bon dimanche.

[Temps-x]

Bonjour pspic, et tout le forum,

Source du message Pour obtenir la date et l'heure avec précision, je préfère utiliser un module RTC DS3231

Je n'utiliserais pas ce module, j'ai une autre idée que j'ai vu sur un forum, j'en reparlerai en section ASM.

Source du message alimenté par une pile CR2032 (non rechargeable) et à lequel je fais subir une intervention chirurgicale pour supprimer la fonction "pile rechargeable".

ils sont terribles ses chinois, toujours en train de grappiller quelle centime d'euros, bon après, ça peut devenir dangereux leurs bêtises.

Un super-Condensateur pour remplacer la pile, c'est bien mieux, ça tient très longtemps, et c'est pas chère.

Source du message Pour la mise à jour après remplacement de la pile j'utilise une App Android en liaison Bluetooth.

Sous Windows XP en général le Bluetooth n'est pas gratuit, il faut payer pour s'en servir , j'ai donc renoncé à ce protocole.

Mais bon, si la mise à l'heure et date est faite une fois par GPS, ça suffit largement pour que le microcontrôleur corrige son écart de comptage.

On peut très bien envisager un comptage par la sortie du Gps sur la broche PPS qui est réglable à la nanoseconde près, même sans réception
du signal

Enfin, il est vrai que sur certain Gps cette broche n'est pas présente, le mien en possède une

Source du message Dans les deux cas il faut gérer le changement d'heure été / hiver par programme.

Et, c'est la que ça devient amusant

pour tous ses infos

A+

[Claudius]

Bonsoir à tous,

Tutoriel très intéressant...

Je souhaiterais apporter une précision constructive par rapport au 1st post; à savoir : "Pour cela nous utilisons Time_dateToEpoch de la librairie Time, qui transforme une date heure en une valeur LongInt qui représente le nombre de secondes depuis le 1er janvier 1960 à 00:00:00."

Pourquoi partir d'une date aussi "vielle" car, sauf erreur de ma part, cela ne fonctionnera plus au delà de 2028 car un LongInt est un 32 bits signé qui ne peut dépasser la valeur fatidique de 2147483647 (cf. SIMPLES TYPES (Page 68))

Explication: En considérant des années de 365 jours sans compter les années bissextiles; sachant qu'il y a 86400 secondes par jour, le nombre d'années pouvant être codé dans un 32 bits signé à partir de leur valeur en secondes est : ((2147483647 / 365) / 86400) = 68 et donc (1960 + 68) = 2028

Pour infos, Linux 32 bits (et bien d'autres logiciels) faisant tourner des applications 32 bits natives (i.e. non recompilées) ont le même problème car l'année de référence est le 1er janvier 1970 (cf. Bug de l'an 2038)

En conclusion, je préconiserais de prendre une date plus récente comme l'an 2000 voire 2020 (on gagne 40 voire 60 ans de fonctionnement sans bug ;-)

[pspic]

Bonjour à tous,

Je n'utiliserais pas ce module, j'ai une autre idée que j'ai vu sur un forum, j'en reparlerai en section ASM.

J'attends avec impatience cette solution.

Sous Windows XP en général le Bluetooth n'est pas gratuit, il faut payer pour s'en servir

Je ne comprend pas ce qui est payant ?
J'utilise des modules HC-06 pour communiquer entre PIC, PC et Smartphone.

Merci Claudius pour votre remarque pertinente concernant le bug de l'an 2038.

[Temps-x]

Bonjour pspic, Claudius, et tout le forum,

Source du message Je ne comprend pas ce qui est payant ?

Si tu utilises ton Smartphone pas de problème, car les pilotes sont intégrés.

Sous Windows 95, 98,2000, XP seulement... il y a aucun pilote pour le Bluetooth, car à l'époque ça n'exister pas, il est bien détecté quand tu branches la carte Bluetooth, mais Windows ne peut pas l'installer, seule quelque programme comme BlueSoleil possède leurs pilote, mais ce n'est pas gratuit.

De plus, un programme qui gère mon port série, je n'aime pas ça, paulfjujo à fait un tutoriel sur ce programme ICI

Comme je suis avec mon très vieux Windows XP ou j'ai aucun problème, je ne prendrais pas cette technique.

Pour l'instant j'écris un petit programme sur PC pour avoir l'heure, date, longitude, latitude, ça seras un bon départ pour le Pic, ou le programme va être beaucoup plus compliqué.

A+

[Claudius]

Bonjour,

pspic a écrit :
Merci Claudius pour votre remarque pertinente concernant le bug de l'an 2038.

En fait, Time_dateToEpoch retourne le nombre de secondes depuis le 01/01/1970 et le bug n'arrivera qu'en ... 2038

Maintenant, il est facile de réécrire cette fonction (ci-après en Langage C et tirée de mktime de la libc standard) et pouvant aisément être portée en Basic

Code : Tout sélectionner


// Année de référence
#define REF_YEAR        (1970)

// Années bissextiles jusqu'en 2099 ;-)
#define LEAP_YEAR(year) ((year % 4) == 0)

typedef struct {
  int tm_sec;    /* Seconds. [0-60] (1 leap second) */
  int tm_min;    /* Minutes. [0-59] */
  int tm_hour;   /* Hours. [0-23] */
  int tm_mday;   /* Day.   [1-31] */
  int tm_mon;    /* Month. [0-11] */
  int tm_year;   /* Year - 1900.  */
} ST_TM;

static byte                 g__monthDays[12] = {31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31};

/* Convert broken time to calendar time (seconds since 01/01/REF_YEAR)
 *
 * Warning: Date limite en (REF_YEAR + 68) ;-)
*/
long my_mktime(ST_TM *timeptr)
{
  int  year  = timeptr->tm_year + 1900;
  int  month = timeptr->tm_mon;
  int  i;
  long seconds;

  // Seconds from REF_YEAR till 1 jan 00:00:00 this year
  seconds = (long)(year - REF_YEAR) * 60L * 60 * 24 * 365;  // seconds is a long

  // Add extra days for leap years
  for (i = REF_YEAR; i < year; i++) {
    if (LEAP_YEAR(i)) {
      seconds += 60L * 60 * 24;        // Add one day for each leap year
    }
  }

  // Add days for this year
  for (i = 0; i < month; i++) {
    if (i == 1 && LEAP_YEAR(year)) {
      seconds += 60L * 60 * 24 * 29;  // seconds is a long
    }
    else {
      seconds += (long)g__monthDays[i] * 60L * 60 * 24;  // seconds is a long
    }
  }

  seconds += (long)(timeptr->tm_mday - 1) * 60L * 60 * 24;  // seconds is a long
  seconds += (long)timeptr->tm_hour * 60L * 60;
  seconds += (long)timeptr->tm_min * 60L;
  seconds += (long)timeptr->tm_sec;

  return seconds;
}


De plus, on peut choisir l'année de référence pour reporter le plus loin possible la limite des 68 ans qui reste toujours vrai car un 32 bits est utilisé