RTC 3231 unixtime en millisecondes

Bonjour,

Y a t'il moyen d'avoir un unixtime en millisecondes ?
J'utilise la librarie DS3231-master qui me permet d'avoir un unixtime en secondes manquant de précision dans mon projet.

Ce n'est pas un unixtime alors... la définition posix est en secondes.

Notez dans une variable (unsigned long) startMillis la valeur de millis() juste après avoir interrogé votre horloge RTC, multipliez son unixtime par 1000 (attention à l'overflow utilisez des unsigned long) et ajoutez la différence
unixtime*1000ul + ( millis() - startMillis) pour affiner votre précision résolution et avoir un temps cohérent en ms.

Par curiosité intellectuelle - Posez vous la question de l'overflow sur un système avec des unsigned long sur 32 bits et si vous utilisez juste un long, sur 31 bits

Pensez à relire la RTC de temps en temps et remettre startMillis à jour pour potentiellement un dérive dans le temps

Juste une petite précision, si je puis dire : ce n'est pas pas parce que vous allez découper les secondes en petits morceaux que votre horloge sera plus précise ; vous aurez seulement une meilleure résolution. C'est peut-être simplement ce que vous rechercher. Pour autant, attention à ne confondre ces définitions.

Cordialement.

Pierre

Bon point - résolution, pas précision par rapport au temps réel

Très bon article.
Dommage que dans les liens à suivre l'article sur le calcul d'incertitude soit trop théorique et n'explique pas les quelques opérations simples de base pour l'évaluation de l'accumulation des erreurs.

J'ajouterai que pour moi la fidélité est le plus important : placé et replacé dans les mêmes conditions un capteur donnera le même résultat.
Si cette condition est remplie il devient possible de faire un étalonnage et une calibration.

Là aussi les mots ont une signification :
Etalonnage :
On note l'écart entre le résultat du capteur et celui obtenu avec un étalon.
Les corrections des résultats du capteur seront manuelles.
Calibrage :
On modifie le capteur pour que ses résultats restent dans un canal fixé par rapport au résultat obtenu avec l'étalon. Avec un micro-contrôleur la calibration devient très simple.

Pour revenir au sujet le DS3231 bien que trés précis pour cette gamme d'horloge n'est pas un étalon de temps.
Malgré la compensation interne en température il possède encore des dérives qui ne sont pas nulles.
Il dérive aussi sur le long terme.
Tout est expliqué dans sa datasheet qu'il serait préférable de lire pour voir si le produit est adapté à ton application.
Info : Sur ce forum (un des premiers sujets de Réalisation et produits finis) notre modo a publié une synchronisation périodique d'un DS1307 sur internet.

Bonjour,
Bonne Année à toutes et tous,
"Une mesure exacte vaut l'avis d'un millier d'experts" (Grace Hopper, mathématicienne américaine 1906-1992)
:wink:

pepe:
Certes, mais dans le cas présent, je trouve que c'est chipoter pour pas grand chose.

Je ne sais pas lequel des deux chipote :wink: . Je ne fais que rappeler quelques définitions. Mais je m'en arrêterai là.

Cordialement.

Pierre

En mathématiques le terme consacré est 'Précision arithmétique' - faut être précis :slight_smile:

Cf Précision — Wikipédia

On peut considérer la RTC comme un appareil de mesure, non? Dans ma phrase ci dessus le bon terme était effectivement résolution.

Sans pinailler - je dis juste que dans MA phrase qui a lancé le débat, Le terme résolution était plus adapté car je n'améliorais pas la précision de la RTC.

Oui si j'avais parlé purement du chiffre alors je conviens que précision est en mathématiques largement convenu (c'est pour cela que je l'avais d'ailleurs utilisé, force de l'habitude)

Ensuite la discussion reste intéressante pour se challenger les neurones mais on ne se prend pas au sérieux vous savez :slight_smile:

Oui bien sûr mon commentaire ne vous pas destiné :slight_smile:

Oui pour la partie technique - mon avis l'OP ne veut qu'un timestamp qui permet de différencier 2 événements consécutifs pour poster sur un serveur genre IOT... mais bon seul lui pourrait nous le,dire :slight_smile:

Bonjour à tous.

Je suis impressionné et flatté par le bon débat qu'a engendrée ma question :slight_smile: :slight_smile: :slight_smile:

Mon projet est une station météo qui comporte un histogramme de pressions heure par heure sur une période de 24 heures permettant d'alimenter en données un algo de prédiction météo. Pour éviter de perdre l'historisation suite à un reset ou à un chargement d'une mise à jour du code, je mémorise les valeurs de pression de l'histogramme sur une carte SD ainsi que la dernière heure d'enregistrement (en timestamp du RTC3231).

Le premier enregistrement de pression se fait 3600000 ms après le démarrage de l'Arduino, les suivants se font toutes les 3600000 ms (utilisation de l'horloge de l'Arduino MEGA).
Au redémarrage de l'Arduino, une vérification est faite (avec le timestamp enreg.) pour voir si l’arrêt est inférieur à 1 heure, si c'est le cas, les valeurs de pression sur 24 heures sont rechargées et une synchronisation est faite pour que le prochain enregistrement soit fait une heure après la dernière valeur enregistrée rechargé.
Pour cela, un calcul du delta entre l'heure actuelle et l'heure du dernier enregistrement inférieur à 1 heure est fait :

timeDelta = ((dt.unixtime - mTimeH0.toInt()) * 1000);

Ce delta est ajouté au Timer de rèf dans le loop pour retomber sur mes pattes :

void loop()
{
Timer = (millis() + timeDelta);

Mon problème est que le Timer est en ms et le timeDelta est issue du calcul avec le dt.unixtime en secondes depuis le 01/01/1970 00:00:00 que je multiplie par 1000.
Cela provoque au fil des heures, un décalage dans l'heure d'enregistrement.
C'est pour cette raison que j'aurai besoin d'un timestamp en millisecondes.

Merci à tous pour votre participation.

Pour répondre à J-M-L, c’est bien d’un timestamp en ms qui permet de différencier précisément 2 évènements dont j’ai besoin. :slight_smile: :slight_smile: :slight_smile:

votre explication n'est pas convaincante...

Pour cela, un calcul du delta entre l'heure actuelle et l'heure du dernier enregistrement inférieur à 1 heure est fait :

timeDelta = ((dt.unixtime - mTimeH0.toInt()) * 1000);

Ce delta est ajouté au Timer de rèf dans le loop pour retomber sur mes pattes :

void loop()
{
Timer = (millis() + timeDelta);

Mon problème est que le Timer est en ms et le timeDelta est issue du calcul avec le dt.unixtime en secondes depuis le 01/01/1970 00:00:00 que je multiplie par 1000.
Cela provoque au fil des heures, un décalage dans l'heure d'enregistrement.
C'est pour cette raison que j'aurai besoin d'un timestamp en millisecondes.

quand vous redémarrez il vous suffit de relire le timestamp du dernier enregistrement en heure UNIX, provenant de votre RTC.

vous demandez à votre RTC l'heure actuelle et vous calculez la différence. Si c'est plus d'une heure, vous avez raté des créneaux, si c'est moins d'une heure, vous vous recalez....

je ne vois pas où est le pb?

A ce niveau, il n'y a aucun problème, c'est fait au démarrage (calcule de la variable timeDelta). Le problème est de faire l'enregistrement suivant, 1 heure après le dernier rechargé après redémarrage et les autres toutes les heures. Cela est fait grâce à Timer = (millis() + timeDelta);. Mais au fil des heures, un décalage se produit et augmente entre la dernière heure d'enregistrement du fait du manque de précision du timestamp en seconde.

Je veux simplement savoir s'il y a un moyen d'avoir un timestamp en millis et une heure à la millis avec un RTC3231, ce qui me permettrait de régler ce problème.

Je ne comprends pas pourquoi vous auriez un décalage...

Disions que vous avez enregistré à 8:10:05, 9:10:05, 10:10:05 et que - pas de bol - panne de courant

Si votre arduino redémarre à 10:11:08, Il voit qu'il y a moins d'une heure d'écart et reprends ses sauvegardes pour 11:10:05, 12:10:05, etc... le premier délai est plus court et ensuite vous repassez sur 1H

Si votre arduino redémarre à 12:20:00, pas de bol vous avez raté 2 échantillons. Il faut décider ce que vous faites; soit vous dites j'enregistre unechantillon quand même tout de suite à 12:20:00 et Le prochain je me recale sur 13:10:05, ou vous générez des "faux" échantillons estimés en faisant une approximation linéaire ou quadratique (apprentissage des coefficients par analyse du comportement passé) entre la dernière mesure et mesure courante et en trouvant approximativement quelle valeur vous étiez sans doute aux 2 instants que vous avez raté, puis vous reprenez comme si de rien n'était, ou vous reprenez l'échantillonnage à partir de cette heure de début et une heure d'intervalle par rapport au nouveau départ et vous conserver un trou dans vos échantillons. Comme vous avez un timestamp si vous voulez représenter cela sur un graphe vous n'avez pas de pb sur l'axe des abscisses vous verrez ce trou

Je ne vois pas où vous devriez dériver?

Sinon pour la question non cette horloge travaille en secondes. Je crois que au mieux les composants grands publics descendent au dixième ou centième de seconde (genre M41T82, M41T83, pcf8583) mais attention à la vitesse de communication du bus I2C qui sera un facteur déterminant...