next topic »

[Reply #885 on:]

scusa Leo, ma stai lavorando al bug riscontrato o non te ne puo' fregar di meno ?  
http://arduino.cc/forum/index.php/topic,73496.msg760934.html#msg760934

[Reply #886 on:]

scusa Leo, ma stai lavorando al bug riscontrato o non te ne puo' fregar di meno ?  
http://arduino.cc/forum/index.php/topic,73496.msg760934.html#msg760934

Non me lo ricordavo neanche 
Cmq sono un po' incasinato in questi giorni. Ho i figlioli sempre in casa perché domani è il patrono del paese dove vivo per cui non vanno a scuola, forse riesco a darci un'occhiata martedì. Se me lo ricordo  :smiley-sweat:c'è con

[Reply #887 on:]

infatti non e' mia norma fare degli UP del genere, ma conoscendoti avevo intuito che te ne fossi dimenticato.
Visto che questa volta sono seriamente intenzionato di usare la swRTC mi serve sapere se assegnare 0 per la domenica o per il lunedi' 

logicamente non c'e' nessuna fretta di fare nulla, "se fa pe' ride" 

[Reply #888 on:]

se non ho capito male l'errore è in setClockWithTimestamp
controlla che il valore ritornato dalla funzione sia 0, se non lo è dimmi che valore ha che identifica quale operazione è andata storta

sarebbe anche utile sapere che anno di riferimento hai usato, e se usare un altro anno cambia la data di bug (se poi mi trovi anche l'altra data di bug sei un tesoro)

ps. Leo non ho notato la sezione "bug noti" sulla pagina di download, io la metterei
pps. grazie per la menzione  

se mi date queste info ci do un'occhiata io

[Reply #889 on:]

L'errore è proprio in getTimestamp.
Usando questo servizio qui:
http://www.unixtimestamp.com/index.php
(più affidabile degli altri link, anche il secondo citato ha un bug)

Inserendo 29/02/2000-12:00:00 il timestamp calcolato dalla swRTC e da quel sito corrispondono perfettamente; ah, piccola cosa: dovete mettere 06:00:00 come orario sul sito perché lo script calcola il fuso orario dal vostro browser, adeguando i calcoli delle ore per l'UTC ed il DST.

Il 28/02/2001 ha già un ritardo di 24 ore. Però calcolando per il 13/04/2012-12:00:00 ho una differenza di 23 ore!  Poi perché tornano 23 ore di scarto? Boh.

[Reply #890 on:]

Eh sì, l'errore è in getTimestamp. 29/02/2000 e 01/03/2000 danno lo stesso timestamp, per cui il calcolatore ha qualche problema con il 29/02/2000, che è un bisestile particolare (l'anno è divisibile per 4, per 100 e per 400 e come tale non è bisestile per la regola dei secoli ma lo è per la regola dei 400 anni).

Allegata c'è la nuova versione 1.0.2 che introduce un fix temporaneo per il calcolo dei timestamp appartenenti a giorni successi al 29/02/2000. E' temporaneo perché ho notato una certa imprecisione nel calcolo del timestamp dovuto all'uso dei float. Mi sa che prima o poi devo ricontrollare l'algoritmo.

Ah, ho modificato il nome interno della variabile che mantiene i secondi dell'orologio. All'esterno non cambia nulla per l'utente ma internamente questa modifica permette di compilare la libreria anche a chi ha modificato il core secondo i miei suggerimenti per introdurre la gestione dei secondi accanto a quella dei millis.

[Reply #891 on:]

uhmmm

Code:

if (time>951847199) { time +=86400; } //year 2000 is a special leap year, so 1 day must be added if date is greater than 29/02/2000

che è questa roba? perchè l'anno 2000 dovrebbe essere un caso particolare di leap year? perchè hai messo il valore in secondi, quindo invece il punto di riferimento può variare in base a che l'anno sia 1900 o 1970? è forse un tentativo di correzione al bug sopracitato, o magari la sua origine??

[Reply #892 on:]

E' una correzione temporanea. Come ho spiegato in cima al thread, questa soluzione è "posticcia", nel senso che ci sono errori interni ben più subdoli introdotti dall'uso dei float. Difatti se si calcola il timestamp per il 13/04/2012 e lo si confronta con quello calcolato sul sito segnalato, si nota una differenza di 1 ora. Non va bene.

Il 2000 è un anno particolare perché in teoria non dovrebbe essere bisestile dato che è sì divisibile per 4 ma lo è anche per 100, e la regola dice che gli anni divisibili per 100 non sono bistestili. Ma lo diventa perché contemporaneamente è divisibile anche per 400. Perché è particolare? Perché gli anni quadrisecolari servono per introdurre un giorno aggiuntivo per correggere gli arrotondamenti minori introdotti dall'uso dell'arrotondamento nel computo della durata dell'anno solare.
Si assume infatti che l'anno solare duri 365.25 giorni, per cui 0.25*4=1 che è il giorno che ogni 4 anni si aggiunge al calendario. In realtà la durata dell'anno solare è di 365.2422 giorni. Ecco la spiegazione dalla Wiki:

Nel calendario giuliano è bisestile un anno ogni 4 (quelli la cui numerazione è divisibile per 4): la durata media dell'anno diventa così di 365,25 giorni (365 giorni e 6 ore) e la differenza rispetto all'anno tropico si riduce da 5,8128 ore in difetto ad appena 11 minuti e 14 secondi in eccesso. Il calendario gregoriano riduce ulteriormente questa approssimazione eliminando 3 anni bisestili ogni 400 anni di calendario rispetto al calendario giuliano: in questo modo la durata media dell'anno diventa di 365,2425 giorni (365 + 97/400), riducendo la differenza a soli 26 secondi di eccesso.

Insomma, ciò che ho fatto io è un sistema rozzo: controllo se la data è successiva al 29/02/2000. Nel caso, aggiungo un ulteriore giorno (86400 secondi) per far sì che sia tenuto conto dell'anno bisestile "forzato".

Rivedrò la formula mettendo un vero conteggio dei giorni realmente passati, perché questo sistema basato sui float non è preciso.

[Reply #893 on:]

ma noi usiamo già 365.2422, quindi ne tieni già conto.

Non capisco perchè usi i float a questo punto, passa agli unsigned long direttamente.

per quanto riguarda il fatto che la funzione deve riconoscere il 2000, fai
if (anno%100 == 0) return '1'

[Reply #894 on:]

ma noi usiamo già 365.2422, quindi ne tieni già conto.

Non capisco perchè usi i float a questo punto, passa agli unsigned long direttamente.

per quanto riguarda il fatto che la funzione deve riconoscere il 2000, fai
if (anno%100 == 0) return '1'

Sì si usa 365.2422 però il problema è che a livello civile è che l'anno bisestile viene introdotto ogni 4 anni, quindi un anno dura 365.25. Ecco che l'arrotondamento viene fuori.
L'algoritmo basato sui float lo presi da internet però non era il sistema migliore, solo uno che funzionava.

[Reply #895 on:]

o fai l'arrotondamento con l'if e usi il .25 o fai senza if e usi il valore preciso. visto che in questo caso vuoi i secondi, vai di preciso e fregatene dell'if.

[Reply #896 on:]

o fai l'arrotondamento con l'if e usi il .25 o fai senza if e usi il valore preciso. visto che in questo caso vuoi i secondi, vai di preciso e fregatene dell'if.

A parte che ho capito metà di quello che mi hai scritto  ma la parte decimale serve in quell'algoritmo proprio per come è strutturato.

[Reply #897 on:]

ho testato la 1.0.2, tutto ok con il time stamp

ricordati di rtc.getWeekDay quando ci rimetterai mano.

Inoltre credo sarebbe comodo e bello che nello sketch di esempio ci inserissi tutte le funzioni, quindi includere timestamp e weekday

non so se e' una svista, ma nel primo post del topic sono inserite due versioni, perche' non lasci solo l'ultima ?

[Reply #898 on:]

ho testato la 1.0.2, tutto ok con il time stamp

ricordati di rtc.getWeekDay quando ci rimetterai mano.

Inoltre credo sarebbe comodo e bello che nello sketch di esempio ci inserissi tutte le funzioni, quindi includere timestamp e weekday

non so se e' una svista, ma nel primo post del topic sono inserite due versioni, perche' non lasci solo l'ultima ?

Sarà fatto.

[Reply #899 on:]

Buongiorno a tutti, stò provando da un bel pò di giorni ad usare la swRTC, come ben sapete, però non riesco a trovare il delta corretto per far in modo che l'arduino non perda moltissimo in un giorno... Al momento ho risultati discontinui e sbaglia anche di diversi minuti in un giorno, può dipendere dal fatto che è alimentato dal pc?