Prova a vedere questa soluzione (ti ho anche un po' "ripulito" lo schema).

A questo indirizzo trovi i relè da 5V: www.electronic.it/product/22550/Rele-a-doppia-Bobina-x-Start-e-Reset-(ON-e-OFF)-1-scambio.html

Se il tuo problema è lo sbroglio con Eagle, sono a tua disposizione.

Tuttavia credo anche si potrebbe fare una notevole semplificazione usando un darlington ULN2803.

Inoltre ti ho trovato i relè da PCB adatti a questo uso

Potresti anche usare un normale programma tipo Hyper Terminal che consenta di salvare su file il testo ricevuto.

Normalmente il numero di telefono è una stringa contenente una sequenza di caratteri ASCII lunga al massimo 16 caratteri.

Il numero telefonico (a parte il prefisso) non può essere più lungo di 10 caratteri (11 per zone ad alta concentrazioni di telefoni).
Quindi 11 caratteri più 5 di prefisso sono appunto 16 caratteri.

La stringa deve perciò essere un vettore char di 16 + 1 elementi.

Ad esempio "+393401234567890" conterrà in esadecimale i seguenti elementi:
 1  2   3   4   5   6   7   8   9   0   1   2   3   4   5   6   7
 +  3   9   3   4   0   1   2   3   4   5   6   7   8   9   0  <null>
2B 33 39  33 34 30  31 32  33 34 35  36 37 38  39 30  00

Non puoi inserire, dunque, la cifra come numero ("1" ad esempio vale 1 come numero, ma vale 31 esa = 49 dec come carattere)

Mi sa che vuoi accendere un globo di plasma...

Se è così fai molta attenzione:
1 - generazione di gas esplosivi
2 - generazione di radiazioni pericolose (gamma, se no ricordo male)

Come ti ha detto già l'ottimo UWE, la RAM è una forte limitazione per il tuo progetto.

Sei sicuro di non poter trattare vettori più piccoli?

Ad esempio potresti memorizzare la stringa nella Flash o nella EEPROM e poi recuperarla a "pezzi" più piccoli.

Vorrei completare parzialmente quanto detto prima.

Il prescaler dell'ADC in Arduino è stato fissato su 128 è di conseguenza il clock ADC vale 125kHz.

Il tempo normale di acquisizione della misura impiega 13+1.5 cicli corrispondenti a circa 8620 sample/s (e non 9600 come erroneamente affermato in precedenza).

Di conseguenza il numero massimo di campioni è 8620 / 50 = 172 sample/periodo.

E' possibile aumentare l'ADC clock a 250kHz usando un prescaler a 64. Purtroppo però si perde in precisione (cosa che nel nostro caso non è consigliabile).

sicuri che usando analogRead si arrivi solo a 9600 campioni al secondo?
da dove arriva? prove sul campo?

Nei processori Atmel 8 bit il tempo di conversione ADC è 13 us (min) sino a 260 us (max) in free running mode.

Ho letto da qualche parte quel dato di circa 10kHz con Arduino (non ricordo dove), ma comunque sono confortato dalle mie "prove sul campo".

Considerando due letture nel ciclo (tensione e corrente), il tempo di un periodo (20ms) e relativi calcoli, i campioni sono stati 83 (sia per la corrente che per la tensione) usando un Arduino MEGA.

Poiché siamo un po' al di sotto della frequenza minima di campionamento, ho compensato con la scelta di N=2 periodi ed i risultati sono stati piuttosto buoni: non solo tensione e corrente precise ma anche il "famigerato" cosFi.

Sto sviluppando ora una versione dell'apparecchio usando un Arduino MICRO.

Pubblica lo schema elettrico

Ho appena affrontato il problema e vedo che in giro ci sono diverse correnti di pensiero.

Per avere RMS affidabili devi campionare all'interno di un un certo numero N intero di periodi e campionare in modo costante (tempo di campionamento il più breve possibile) e con una frequenza di campionamento di almeno 2 volte la frequenza del segnale (2x50=100) dal teorema di Nyquist.

L'ADC di Arduino campiona alla velocità massima di 9600 sample/s corrispondenti a circa 192 sample/periodo.

Il problema è che questo accade per letture continue, mentre nella realtà questo non accade poiché, ad esempio, ci sono le istruzioni di somma, per non parlare di eventuali interrupt.

Anziché leggere tot campioni (che potrebbero leggere, ad esempio, 1.3 periodi falsando la misura) conviene campionare (il più velocemente possibile) entro una finestra temporale di N periodi (ad esempio 2 periodi cioè 100ms).

Per ridurre il tempo di calcolo ti conviene convertire solo la somma finale ottenuta sommando i quadrati delle misure ripulite delle sola componente continua. Non sarebbe male inserire un filtro passa basso hardware con taglio a 4.8 kHz sulla linea ADC.

Ci sarebbe altro da dire, ma non posso andare oltre: il PowerMeter da me ideato fa parte di un progetto per un mio cliente.

Stai parlando di carattere checksum per verificare da parte del ricevente la validità dei dati ricevuti?

Cerca checksum e troverai vari algoritmi più o meno validi.

Io adotto questo sistema:

Code:

boolean DigInVal;  // stato pulsante
...
void GetDigIn() {

  boolean Status;
  const unsigned long Debounce = 20;                // antirimbalzo 20ms - 100ms

  Status = digitalRead(DigInPin);
  if (Status != DigInVal) {
    delay(Debounce);
  }
  DigInVal = digitalRead(DigInPin);
}

Code:

char SMSRx[];
...
while(c=sms.read()) SMSRx += c;
SMSRx += 0;              // terminatore stringa

Potrebbe essere un problema del parasite mode: prova ad alimentare in modo normale il sensore.

C'è una cosa che non capisco: la logica vorrebbe che i morsetti rispettassero la norma del passo 200 mil = 5.08 mm, invece è più facile trovare in commercio quelli da 5 mm.

Anzi, nella libreria di EAGLE mi sembra che non siano presenti quelli da 5.08 mm.

Qualcuno sa spiegarmi perché?