problema lettura su porte analogiche, arduino in fumo :-/

Uwe,
Non ti so spiegare il perchè ma ho ricontrollato di nuovo le misure e ho pochi Ohm sia tra +5 e A5 sia tra A5 e GND, quindi è quasi in corto ma arduino funziona lo stesso, forse perchè alimentato via USB c'è un limite di corrente ?

Le celle Lipo le devo monitorare perchè devo evitare che una cella scenda sotto il voltaggio critico di 3V. Se per ipotesi monitorassi solo la tensione dell'intero pacco non potrei sapere se una cella è scesa piu' delle altre oppure sono scese tutte e 6 in maniera uniforme.

Per il discorso dell'impedenza ho un dubbio, per le ore che il sistema ha funzionato correttamente io leggevo circa 855 come ADC sugli ingressi, la batteria era carica al massimo quindi se non sbaglio 855 * 5/1023 = 4,17 V che è in linea con quello che leggo realmente all'uscita del partitore ( diciamo da 4.1 a 4.2 V ).

L'idea dello zener mi piace e se riesco a trovare posto sulla board li mettero', ma sinceramente ancora non mi spiego come il guasto sia avvenuto.

Se il problema fosse software...
Domanda:

I Pin analogici non devono essere dichiarati come Input come avviene per i Digitali ? Se si qual' è la procedura corretta ?

MatrixGTI:
Quindi escludi che il problema dell'impedenza possa aver causato il guasto ?

L'impedenza vista dal ADC crea problemi solo a livello di precisione se è troppo alta, non rompi nulla nemmeno se colleghi l'input dell'ADC direttamente ai 5V.

Ergo A5 è in corto sul +5 e a GND :frowning:

Questo non è possibile perché altrimenti sarebbe in corto l'alimentazione stessa, dato che alimentando la scheda il tutto funziona salvo A5 è
ovvio che non c'è nessun corto tra Vcc e GND.
Senza poter verificare le cose direttamente è molto difficile fare una diagnosi, però ritengo molto probabile che hai qualche problema sul pcb, p.e. piste/isolamento/saldature difettosi che mettono in corto direttamente A5 con la tensione della batteria senza passare per il partitore quando il pcb flette.

i pin sono dichiarati bene altrimenti non ti funzionerebbe.
Non dimentichiamoci che il circuito funziona per molt0o tempo. solo in secondo momento si guasta, quindi saltano anche le ipotesi di pcb difettosa.
metti gli zener ed investi i un'altra arduino. la tua difettosa la compro io a meta' prezzo :slight_smile:

Testato:
non ha senso seguire la strada dell'impedenza.

La questione impedenza d'ingresso invece è molto importante, Atmel ha almeno una ventina di Application Note su questo punto dove si "sgola" a spiegare perché deve essere minore di 10k se vuoi usare più di un canale per volta e devi fare misure veloci, cosa che ho ampiamente spiegato in altro thread.
Nel caso in questione non c'è nessun problema di velocità in quanto il fenomeno da misurare varia lentamente, ma c'è il problema che si usano più canali ADC, e dato che l'ADC vero è proprio è solo uno se l'impedenza d'ingresso è maggiore, e in questo è enormemente maggiore, di 10k non puoi leggere in modo corretto le differenze di tensione tra canali.

Testato:
quindi saltano anche le ipotesi di pcb difettosa.

Mai visto un circuito che funziona benissimo per ore/giorni/mesi e poi non appena lo tocchi va tutto in fumo ? Io ne ho visti anche troppi e la causa è sempre un difetto del pcb o delle saldature.

Intanto grazie a tutti per le rapide e precise risposte.

A questo punto ho pensato di procedere in questo modo:

  1. Monto un nuovo nano sulla board e senza collegare la batteria al partitore verifico che A5 non sia a +5V ( nel caso significa che nel SW c'è qualcosa che non va )

  2. Cambio l'intero PCB con uno nuovo ( ne ho 3 identici non saldati ) e provo con un alimentatore da laboratorio a dare le tensioni che avrei sulla batteria ai vari ingressi leggendo cio' che mi ritrovo all'uscita del partitore, magari provando a flettere leggermente la scheda, se i valori sono tutti intorno ai 4.2 V allora installo il Nano nuovo e dovrebbe funzionare tutto.

  3. Se il problema non si ripresenta allora significa che ho fatto due errori simili su due board diverse e posso solo picchiare la testa al muro, se invece succede di nuovo dopo un periodo di funzionamento corretto allora mi tocca rifare il PCB da 0 aggiungendo gli zener come giustamente consigliato ( logico che se posso evitare di rifare i PCB il mio portafogli è piu' felice )
    Ma rimane comunque il dubbio sul perchè sia successo.

Non posso escludere a priori un doppio errore di disattenzione, però ci tengo a precisare che lavoro con un metodo preciso, la batteria è impacchettata e isolata da tutto, il connettore di bilanciatura arriva sulla scheda su un connettore per evitare errori di inversione etc, il pcb è montato su una basetta con 4 torrette e non subisce stress meccanico etc.
Questo per dire che l'errore è sempre possibile ma ho fatto il possibile per evitarlo... :slight_smile:

MatrixGTI:

  1. Monto un nuovo nano sulla board e senza collegare la batteria al partitore verifico che A5 non sia a +5V ( nel caso significa che nel SW c'è qualcosa che non va )

Ottieni i 5V su A5 solo le setti esplicitamente come OUT e ci scrivi sopra uno stato logico HIGH, altrimenti per default è un input ad alta impedenza.
Per caso hai disponibile un oscilloscopio ?
Se la risposta è si controlla se il driver dei led genera degli spike ad alta tensione, possono farlo, se ci sono possono essere loro la causa della dipartita di A5.

astrobeed:

Testato:
non ha senso seguire la strada dell'impedenza.

La questione impedenza d'ingresso invece è molto importante, Atmel ha almeno una ventina di Application Note su questo punto dove si "sgola" a spiegare perché deve essere minore di 10k se vuoi usare più di un canale per volta e devi fare misure veloci, cosa che ho ampiamente spiegato in altro thread.
Nel caso in questione non c'è nessun problema di velocità in quanto il fenomeno da misurare varia lentamente, ma c'è il problema che si usano più canali ADC, e dato che l'ADC vero è proprio è solo uno se l'impedenza d'ingresso è maggiore, e in questo è enormemente maggiore, di 10k non puoi leggere in modo corretto le differenze di tensione tra canali.

Non sto' dicendo che non e' importante ma solo che non e' la causa del problema attuale, e quindi non serve mettere mano ai partitori perche' nonostante sia molto maggiore di 10k funziona bene, la lettura e' precisa.
Quindi il problema e' da un'altra parte, voterei a questo punto anche io per la tua idea di pcb difettosa.

Dunque,
Nel codice non dichiaro A5 come output, ora mi viene un dubbio amletico, per pilotare il mosfet che stacca il carico usco il pin digitale 5

Dichiarato come:

int enable = 5;

pinMode(enable, OUTPUT); // SETTO IL PIN 5 COME OUTPUT PER PILOTARE IL MOSFET

e gestito lo stato come

digitalWrite(enable, LOW); //apro il circuito di alimentazione

digitalWrite(enable, HIGH); //chiudo il circuito di alimentazione

Questo non dovrebbe modificare lo stato di Input del pin A5 ?

Per avere il pin A5 come output dovrei dichiarare "enable" come A5 e non 5

Testato:
Non sto' dicendo che non e' importante ma solo che non e' la causa del problema attuale, e quindi non serve mettere mano ai partitori perche' nonostante sia molto maggiore di 10k funziona bene, la lettura e' precisa.

Io non ho detto che l'impedenza è la causa del guasto, ho detto che con quei valori l'ADC funziona male, le letture che fa sono inattendibili, ti faccio un esempio pratico:
Se le sei celle stanno tutte a una tensione molto simile l'ADC legge i cinque valori tutti uguali +/- 2 count del suo errore tipico, ed è la condizione standard.
Se una cella comincia a scaricarsi molto di più delle altre, p.e. cinque sono a 4.00 V e una è a 3.02 V questo'ultima viene letta come un valore molto prossimo a 4.00V perché il sample and hold del ADC non può caricarsi al nuovo valore di tensione abbastanza in fretta per via della elevata impedenza d'ingresso.

Ottieni i 5V su A5 solo le setti esplicitamente come OUT e ci scrivi sopra uno stato logico HIGH, altrimenti per default è un input ad alta impedenza.
Per caso hai disponibile un oscilloscopio ?
Se la risposta è si controlla se il driver dei led genera degli spike ad alta tensione, possono farlo, se ci sono possono essere loro la causa della dipartita di A5.

Purtroppo non ho un oscilloscopio disponibile, il drive che sto usando è questo : http://www.taskled.com/hboost.html , non so se possa creare spike ad alta tensione.

MatrixGTI:
int enable = 5;
pinMode(enable, OUTPUT); // SETTO IL PIN 5 COME OUTPUT PER PILOTARE IL MOSFET

Come buona norma di programmazione evita di usare variabili intere (16 bit = 2 byte di preziosa ram) per definire un pin, usa le define che non sprecano memoria e non sono alterabili da nulla.

#define  enable 5

pinMode(enable, OUTPUT);

e gestito lo stato come

Per utilizzare i pin analogici tocca indicarli come A0-A5 oppure come valori numerici tra 14 e 19.

Inzialmente usavo il #define ma mi cambiava dei testi nel codice se contenevano la variabile dichiarata, comunque è un consiglio prezioso perchè non sapevo che non utilizzasse ram. :slight_smile:

Ciao,

ho guardato la discussione e, come dice Astrobeed, io guarderei meglio il circuito.
Le resistenze che usi, se ho capito bene, sono SMD.

Hai fatto le misure all'uscita del ripartitore per controllare che la saldatura degli SMD non crei problemi?

Ciao,
Marco.

Si, tutte lemisure le ho fatte sul pcb con le R montate. A questo punto puo' essere un problema legato al Drive che fa salire la tensione della batteria con degli spike tali da bruciare la porta del micro dietro 500k di R ?

Astro stiamo dicendo la stessa cosa, lavoriamo solo in modo diverso :slight_smile:
Se mi si fulmina A5 non sto' a guardare l'impedenza del partitore. Per non far andare fuori strada il collega nemmeno la nomino.

Rosolto il problema si dice: oltre a questo ci sarebbe anche a-b-c-d, cosi' come ad esempio ora hai dato il consiglio del define, che e' ottimo, ma per come lavoro io non l'avrei nominato. Perche' nulla centra con il problema.

Poi logicamente ognuno fa come cavolo vuole :slight_smile:

Visto che non c'e' oscilloscopio monta gli zener come consigliato e si attende la diagnosi postuma. Se funziona ci sono degli spikes, da dove provengono lo si potra' solo supporre ma almeno il problema e' risolto, se invece si riguasta si continua.

Testato:
Visto che non c'e' oscilloscopio monta gli zener come consigliato e si attende la diagnosi postuma. Se funziona ci sono degli spikes, da dove provengono lo si potra' solo supporre ma almeno il problema e' risolto, se invece si riguasta si continua.

Se ci sono spikes ad alta tensione con gli zener non vai da nessuna parte, ti si bucano pure loro, vanno usati dei transil da 5.1 Volt.
Comunque visto il tipo di driver utilizzato è difficile che generi spike di ampiezza tale da fare danni di questo tipo.
MatrixGTI puoi mettere su un qualche server, p.e. Megaupload, delle foto ad alta risoluzione, possibilmente non sfocate e non accecate col flash, fronte e retro del pcb con i componenti montati ?

grazie anche per questo consiglio :slight_smile: gli zener sono lenti per gli spikes.
non c'e' il tasto GRAZIE su questo forum, ne dovrei mettere 50 al giorno :slight_smile:

Ecco di nuovo,
Dunque, per le foto ad alta risoluzione devo ingeniarmi un attimo perchè ho la reflex in riparazione e non ho altri strumenti adatti. Appena possibile lo faccio.

Stasera ho fatto questa prova, ho rimontato la board con il Nano che ha A5 bruciato. ho ponticellato l'uscita del partitore che andava su A5 e l'ho mandata su A6.
(tanto ormai quella board è spacciata, ho pensato che potesse anche morire in gloria ).

nello sketch ho aggiunto un timer che richiama la lettura degli ingressi ogni 500 ms e ad ogni passaggio del timer legge un ingresso alla volta, quindi completa la lalettura delle 6 celle in 3 secondi circa, il che è comunque accettabilissimo.

Ho alimentato per 5 minuti singolarmente ogni ingresso del partitore con l'alimentatore da laboratorio a 4 - 8.5 -12.4 - 16.8 - 21 e 25 V ( le letture da Arduini erano buone e le letture con il tester sul partitore erano corrette ).

A questo punto ho collegato il connettore della batteria (solo la bilanciatura) con arduino NON ALIMENTATO e sorpresa delle sorprese... si è acceso !
ho scollegato le singole celle e arduino è rimasto acceso finchè non ho disconnesso la cella1, quella connessa ad A0 direttamente dove avevo 4.1 V.
Non so se questa cosa sia normale, domani provo con una board nuova per vedere se con alimentazione su A0 si accende.

Comunque, a parte questa cosa curiosa ho riconnesso tutto come da origine , Alimentazione, Drive etc , con la sola differenza dell'ingresso A6 e ho lasciato un ora il tutto acceso, con il carico da 100 W che veniva gestito dalla temperatura, quindi con Pwm variabile.

Non ho riscontrato nessun problema, le letture erano peggiori che quelle ottenute con alimentazione singole ma tutto sommato accettabili.

Mi viene da pensare che il pin A5 sia in qualche modo diverso dagli altri ma sul datasheet del micro non ho trovato nulla a riguardo.

É normale che se dai tensine a A0 l' arduino si accende ma é una condizione proebita.
Su tutti gli integrati non si puó mettere tensione alle entrate / uscite senza alimentare l'integrato. Le entrate / uscite hanno dei Diodi di protezione che proteggono i CMOS da cariche statiche che altrimenti li romperebbero. Tramite tali diodi arriva tensione all'alimentazione del ATmega.
Ciao Uwe