Non ho mai usato un GPS, ma incuriosito sono andato a guardare la libreria linkata da @Maurotec; effettivamente non ci sono "richieste", ma solo letture, cioè dopo aver istanziato la classe, la seriale inizia a ricevere, e la getDataGPRMC, quando richiamata, legge il buffer della seriale, inoltre, quella libreria usa SoftwareSerial, credo la peggiore in termini di gestione degli interrupt.
Nell'ipotesi che il problema iniziale dell'OP sia effettivamente software e non risolvibile in maniera "lecita", una soluzione drastica come la seguente potrebbe funzionare?
Come primo tentativo, modificare la libreria per fargli utilizzare AltSoftSerial (mi ci trovo bene), che sembra avere una miglior gestione degli interrupt; se ho capito bene, si parla di una latenza di latenza di circa 4µs rispetto a circa 170µs di SoftwareSerial!
Se anche questo tentativo fallisse e visto che l'OP parla di usare il GPS una volta al giorno (correggi se sbaglio), si potrebbe aggiungere un metodo alla libreria GPS, che ferma la ricezione seriale (AltSoftSerial ha un metodo end()), quindi di fatto libera l'interrupt.
In pratica si istanzia la classe, che di fatto l'unica cosa che fa è inizializzare la seriale, e una volta fatta la lettura, la si distrugge, interrompendo così la seriale e liberando l'interrupt.
Che ne dite, potrebbe funzionare? Ci sono controindicazioni?
oppure ieri sera era meglio se bevevo acqua?
Come già avevo detto, NON ho mai visto GPS che fonissero le indicazionni on-demand, anche se questo non esclude che possano esistere ...
La soluzione è molto semplice:
studiarsi il manualetto del GPS, tranto già so che fornirà in uscita, tra le altre, la solita sentenza RMC:
$GPRMC,123519,A,4807.038,N,01131.000,E,022.4,084.4,230394,003.1,W*6A
Where:
RMC Recommended Minimum sentence C
123519 Fix taken at 12:35:19 UTC
A Status A=active or V=Void.
4807.038,N Latitude 48 deg 07.038' N
01131.000,E Longitude 11 deg 31.000' E
022.4 Speed over the ground in knots
084.4 Track angle in degrees True
230394 Date - 23rd of March 1994
003.1,W Magnetic Variation
*6A The checksum data, always begins with *
NON usare librerie ma usare direttamente la AltSoftSerial per leggere la seriale del GPS SOLO quando serve e quando NON si aggiona la striscia di LED.
fare il parsing di ciò che si è ricevuto, ovvero tutte le varie sentenze ed estrarre dalla RMC i dati che servono.
... tutti quelli che consco sono degli oggetti che "normalmente" (alcuni posso fare molto di più) sparano ogni X secondi (di base 1 secondo) una serie di stringhe (terminate da CR/LF) rappresentative di una serie di sentenze NMEA.
Si tratta di scegliere quelle di proprio interesse, leggere dalla seriale la singola riga (o, ancora meglio, l'intero blocco aumentando il buffer della seriale) e poi cercare quella/e che interessano e ... spesso la $GPRMC è più che sufficiente
Naturalmente adesso mi vien voglia di prenderne uno, ma devo resistere
Più in la ti chiederò consigli su cosa prendere in funzione del progettino che ho in mente.
Ho studiato i vostri suggerimenti e ora funziona. GRAZIE A TUTTI!!!
Ho eliminato dal codice le seguenti librerie:
a) SoftwareSerial.h , sostituendola con AltSoftSerial.h
b) TinyGps.h, inserendo direttamente la lettura della stringa RMC
void RecuperaOraGPS(void) // Recupera i dati dal GPS
{
do
{
if (altSerial.available())
{ //leggo la prima riga
char c = altSerial.read();
if (c != '\n')
NMEA += c;
else
{ //della stringa che mi interessa,GPRMC, con substring estrapolo i dati usando come parametri
//la posizione iniziale e finale
posizione_delimitatore = 0;
index = 0;
campo = 0;
if (NMEA.substring(0, 6) == "$GPRMC")
{
while (posizione_delimitatore != -1)
{
posizione_delimitatore = NMEA.indexOf(",", index);
switch (campo)
{
case 1:
ora=NMEA.substring(index, index + 2 ).toInt();
minuti= NMEA.substring(index+2, index+4).toInt();
secondi = NMEA.substring(index+4, posizione_delimitatore).toInt();
break;
case 9:
gg=NMEA.substring(index, index + 2 ).toInt();
mm= NMEA.substring(index+2, index+4).toInt();
break;
}
index = posizione_delimitatore;
index++;
campo++;
}
}
NMEA = ""; //resetto la stringa
if (gg !=0)
gpsOK=true;
}
}
} while ((minuti==minute())&&(gpsOK==false)); //continua a ricercare i dati per il minuto successivo o fino a salvataggio effettuato
if (gpsOK==true)
{
// CtrlOraSolare(); // controlla ora solare/legale
Update_RTC(); // aggiorna RTC
updateOK=true; // disattiva la sincronizzazione
LedClockDisplay(); // Visualizza l'ora accendendo i led
}
}
Della libreria TinyGps.h utilizzavo anche l’informazione sul giorno della settimana, ma ho visto che non è difficile da codificare, più tardi lo sistemo.
Ho collegato il tutto seguendo i vostri suggerimenti (eccetto quello sull’RMC, scusate…, così funziona e ne ho già fumato uno…):
Ho tolto il collegamento rosso fra la striscia e il pin 5V di arduino
Il gps, l’ho collegato con il 5V, il gnd, i pin 8 e 9 di arduino
L’RTC l’ho collegato con il pin 3,3 V, gnd e i pin 4 e 5.
Ho allegato lo schema.
Per Maurotec: io ho utilizzato dei connettori a molla… (come quelli allegati)
Ho collegato il tutto seguendo i vostri suggerimenti (eccetto quello sull'RMC, scusate…, così funziona e ne ho già fumato uno…):
Non insisto per nulla su RTC a 5V ma ci dai un link al prodotto che hai acquistato?
L'importante è che funziona e che puoi procedere con la presentazione, più in la se dovessi continuare con arduino e affini approfondirai.
Una sola cosa ti chiedo di modificare, si tratta del GND che nel disegno parte dall'alimentatore arriva alla striscia e poi va su GND di arduino. Bene questo passaggio non ci deve essere, per le connessioni GND la connessione a "stella" evita grattacapi. Non trovo alcuna immagine per le connessioni a stella, comunque basta fare partire ogni filo GND dal nodo a più bassa impedenza che è il GND dell'alimentatore.
Spiegazione peseudo tecnica: La corrente che scorre nel filo rosso scorre anche su quello nero, il filo ha una sua resistenza, per la legge di ohm V=RxI. Supponiamo che la R del filo sia 0.1ohm e I (la corrente) sia 2A ai capi del filo nero misuri una tensione di 0.1x2=0.2V. Se usiamo questo nodo come riferimento gnd per arduino il suo potenziale varierà in base alla corrente che scorre nella striscia led.
Ok visto i connettori a molla, mai usati, ma se sono affidabili e comodi perché no.
Ho sistemato tutto il codice, anche la parte sul giorno della settimana.
Relativamente alla tua modifica se ho capito correttamente:
va bene se il nero parte dall’alimentatore e (diviso in tre) va verso USB arduino, inizio striscia e fine striscia.
Non va bene che dall’inizio striscia torni al gnd di arduino, giusto?
Però non ho capito:
a) Se il filo nero che esce dall’inizio striscia non devo proprio collegarlo.
b) Se devo collegarlo all’alimentatore
c) Se devo cambiare anche il gnd dell’RTC e del GPS.
Piuttosto l'uso di una stringa dinamica C++ come buffer di ricezione, invece di una stringa "classica" C (array di char statico), può dare problemi di frammentazione ed esaurimento della memoria dopo un certo tempo di funzionamento.
Ho disegnato anche le piste del circuito stampato di arduino, per mostrare il percorso di gnd, USBVCC (+5V), 3.3Vout. Vero non ho disegnato il mosfet e il comparatore ma per quello si può scaricare il pdf dello schema di arduino UNO.
Dovrebbe essere più chiaro che non serve il collegamento aggiuntivo che avevi fatto per GND.
Piuttosto l'uso di una stringa dinamica C++ come buffer di ricezione, invece di una stringa "classica" C (array di char statico), può dare problemi di frammentazione ed esaurimento della memoria dopo un certo tempo di funzionamento.
Verissimo, tuttavia per la presentazione agli alunni questo problema non si verificherà ed eventualmente basta un reset. Il problema della frammentazione si presenta poiché la classe String usa allocazione di memoria ram dinamicamente, cioè a run-time, sostanzialmente usa malloc che può restituire un puntatore NULL se fallisce, poiché non c'è sistema operativo che virtualizza la ram questa ha dimensioni finite e continue riallocazioni possono portare a deframmentazione frammentazione con il risultato che malloc fallisce nel trovare la memoria richiesta.
Riguardo alla striscia se preferisci fai partire dalla morsettiera due fili (rosso e nero) poi per ridurre la resistenza elettrica delle piste del circuito stampato della striscia altri due spezzoni di cavo saldati su inizio e fine striscia, questo per praticità e comodità.
Dallo schema di @Daniela76 mi sembra manchi una resistenza (300/470 Ohm) in serie sulla linea dati della striscia led, ed eventualmente anche un condensatore (1000 µF) in parallelo tra 5V e GND, non sono fondamentali, ma fortemente consigliati.
Federico66:
... una resistenza (300/470 Ohm) in serie sulla linea dati della striscia led ...
... SI, le striscie basate su WS2812/neopixel sono "piuttosto delicate" sul pin dei dati.
Per proteggere la striscia ed evitare di distruggere il primo chip della striscia, è bene mettere in serie al pin dei dati una resistenza attorno ai 470Ω.
una soluzione drastica come la seguente potrebbe funzionare?
