Vai al contenuto
PLC Forum


precisione di un Convertitore AD 12 bit di un microcontrollore microchip


davideversari

Messaggi consigliati

davideversari

salve a tutti

non mi sono mai posto la domanda "ma che precisione puo'offrire un conv AD 12 bit di un microcontroller?"

devo realizzare un minidatalogger per leggere ed archiviare la temperatura di 3 termometri 1 volta al minuto.

ho realizzato il Pcb scritto il firmware, si tratta di un PIC 18F27J13.

funziona benissimo salvo che nella precisione della Conversione

Ho inserito un Vref di precisione per settare la Vref+ a 2,500V +/- 2 mV (e'un max6070 pecisissimo)

ho settato come da datasheet sviscerando ogni possibile sfumatura a partire dalla calibrazione prima della

conversione ...alla conversione fatta bene attraverso ADRESH e ADRESL 

ho provato anche ad usare il registro VBGEN x usare il riferimento interno 1,2 V

ma la conversione su tutti e tre i canali NON e' precisa ; o meglio a 2,495 V  misura correttamente 4095 bit

ma nelle misure intermedie tipo 0,05/2,4 V ho una sovrastima molto alta , tipo  + 15 bit rispetto al valore teorico

 

ho provato a misurare lo stesso valore sui tre canali e la misura e' ,  +/- 3 bit,  pressche'  uguale ....ma distante dal valore teorico +15 bit come dicevo.

 

15 bit rappresentano circa 8 mV che NON sono pochi per l'applicazione di cui ho bisogno

 

Vref- l'ho settato = Vss

ho pensato a Vref-  perché a inizio scala , prossimi allo ZERO,   misura sempre in eccesso.

 

e' un incertezza normale per un PIC?

li facevo piu'precisi

qualcuno ha esperienza maggiore di me in merito ?

 

Link al commento
Condividi su altri siti


Se si potesse vedere lo schema ed avere le caratteristiche delle sonde, sapere come è stato scritto il firmware, se è stato rispettato quanto prescritto per l'acquisition time ecc ecc ecc.... si potrebbe anche tentare di azzardare un' ipotesi, altrimenti la risposta che si può dare è:

 

sì è preciso, come da specifica.

 

Ho avuto 3 casi distinti con misure non ripetibili

 

1) Ripple eccessivo sull'alimentazione delle sonde

2) Acqusition time

3) Ground loops

 

ma ce ne sarebbero altri di fattori come ad esempio il rispetto dell'impedenza di ingresso

 

 

 

 

 

 

 

 

 

Link al commento
Condividi su altri siti

Un dato fondamentale dei convertitori A/D è anche quello relativo alla linearità.

Nel tuo caso sembrerebbe esserci un off set di partenza. Le cause potrebbero essere quelle che ti ha indicato Stefano.

Comunque con 610µV di risoluzione è indispensabile che tutto il circuito sia accordato con un violino da concerto.

Ti basta un poco di ripple sull'alimentazione del PIC per portarti via qualche bits, idem se la'limentazione delle sonde non sono più che pulite.

Fai conto che se hai 2 mV di ripple sull'alimentazione delle sonde ti ritrovi già un errore che può arrivare anche a 6 bits, solo per il rumore.

 

Poi molto dipende anche da come misuri la tensione in ingresso e con  quale strumento.

Il fatto che con 2495 mV tu abbia il valore di fondo scala, sigifica solo che sei già saturo, probabilmente otterrai 4095 anche con qualche mV in meno.

Link al commento
Condividi su altri siti

davideversari

ciao,

grz x la risposta

premetto NON sono un fenomeno; ma vorrrei provare a trovare la causa ! quindi provo a darti le indicazioni che mi hai chiesto.

tralascio x ora il firmware, scritto in MIKROBASIC

 

le sonde sono dei semplici MCP9700 e vengono alimentate tramite uno step down MCP 1640 (si tratta di un sistema alimentato a batteria)

per ora lálimentazione e'tramite un HP6632

 

'per comodita' le sto simulando il segnale delle sonde , su due canali,  con un alimentatore HP6632

sul terzo canale con una sondaMCP9700

 

l'impedenza del segnale quindi e' quella dell alimentatore  sui due primi canali e quella del MCP9700 (20ohm) sul terzo canale

 microchip prevede max 10K a 12 bit

 

lácquisition time l'ho impostato a 16TAD come prescritto da microchip per 12 bit

FOSC 4

 

riguardo al ground loops immagino tu intenda un problema sulla struttura del pcb?

spero non sia quello davvero

 

come procederesti?

 

davide

 

 

 

 

Link al commento
Condividi su altri siti

Quote

MIKROBASIC

 

Ah ecco...la spiegazione. 

 

Immagino userai la comoda funzione di libreria ADC_Read(n)  e magari richiamandola più volte di seguito.

...ma se vuoi qualcosa di preciso, devi gestirti il convertitore AD  bit per bit, registro per registro e rispettare il timing

ampiamente descritto in  22.1 A/D Acquisition Requirements del datasheet

 

Si può incorrere nello stesso errore anche con il fratello maggiore MikroC.

Ci son caduto anch' io, attratto dalla comodità delle funzioni di libreria, ma purtroppo capita spesso che per farle funzionare come si deve, specialmente su MCU recenti,  serva più codice di quanto non serva se si gestisse autonomamente la periferica, in questo caso l' AD

 

E' un problema di timing. Tutte le risposte sono sempre nel datasheet :smile:

 

 

 

 

 

 

 

Link al commento
Condividi su altri siti

davideversari

ciao,

dott.Cicala 

No la funzione ADC_read non la uso, come giustamente hai riscontrato e'comoda ma imprecisa;  calcolo la lettura direttamente con i registri ADRESL ed ADRESH

il problema temo sia Hardware piuttosto che firmware....come Livio ha suggerito

 

comunque il capitolo 22.1 l ho letto ed ho capito che ti permette di calcolare TAD; immagino si tratti del TAD che poi si va a settare in ADCON1  <5-3>?

ho fatto alcune prove (ho un quarzo 8Mhz e lavoro a 12 bit)  onestamente empiriche settando TAD 8 12 16 ....non e'cambiato nulla

qualcosa e'cambiato solo quando ho sostituito a tutti i segnali da misurare con una pila 1,5 V (1,475V).

in quel caso la misura si e' mantenuta entro +/- 2 bits  anche se stranamente solo su 2 canali ; sul terzo un po peggio.

visto che hai piu' esperienza tu il TAD lo calcoli in modo fine o vai x tentativi come ho fatto io ?

poi TAD si puo'settare solo con ADCON1 con quei valori riportati sul datasheet?

 

Livio:

 

offset: se fosse solo un problema di offset potrei correggerlo e non pensarci piu'.

pero'vicino al fondo scala dovrei correggere via firmware perche&#39;' da 2,4 V in su l offset scema verso ZERO.

saturazione: NO ho fatto delle prove e raggiunge correttamente il fondo scala ; a 2,492 4085bits......mi sembra OK

 

 

 

Link al commento
Condividi su altri siti

davideversari

ho tagliato la testa al toro....

x eliminare possibile rumore ho  alimentato tutto con una batteria 3,1 V

risultato  su tutti e 3 i  canali , compreso quello che legge un MPC9700 ho ottenuto almeno che la stabilita', ripetibilita', sia entro  +/-2bits

 

a me +/- 1,22 mV sembrano un buon risultato piu' accettabile

visto che dovro'' misurare degli MPC9700  10mv/C!

purtroppo la misura di cui stiamo parlando,  tensione di  1,474 V della pila alkalina,   risulta sovrastimata di ben 20 bits!

sono sicuro della tensione perché ho 3 multimetri 61/2 dig   e danno tutti la stessa misura (uno e' costantemente calibrato)

 

se il problema fosse lineare si parlerebbe di un offset.

potrei correggere via software prevedendolo e calcolandolo x ogni circuito?!

 

ma l'offset e'un problema accettabile? insito nel convertitore per capirci

oppure tipico di un problema esterno al Pic ed al Conv AD?

giusto x capire .

 

 

 

Link al commento
Condividi su altri siti

Dai un'occhiata a

 

22.2 Selecting and Configuring Automatic Acquisition Time

 

Se il problema è questo lo verifichi facilmente:

 

Applichi 3 valori diversi di tensione ai tuoi ingressi

Ne tieni 2 fissi e ne vari uno

Se c'è un problema,  anche le altre letture subiscono delle variazioni e potrebbe essere che selezioni l'ingresso successivo troppo presto.

 

Per evitare qualsiasi problema (non sarà un metodo scientifico ma funziona benissimo) a fine conversione, solo dopo aver disattivato l' AD

 

Seleziono il pin tramite       ADCON0.CHS(n)  

Attivo l'AD                           ADCON0.ADON =1

Aspetto 1us                        

Attivo la conversione:         ADCON0.GO =1

 

Quando la conversione è completata il micro richiama un interrupt dove disattivo l'AD e ricomincio come sopra

 

Se invece è un problema hardware, cioè il mio caso 1 - ripple eccessivo - è sicuramente più difficile da eliminare.

Può essere un disturbo indotto (cavi di collegamento delle sonde lunghi e schermati male o non schermati)

Può arrivare dall'alimentazione. Se è così, alimentando il tutto con una batteria lo identifichi...sempre che sia possibile farlo.

 

Prova a chiudere i tre canali il più possibile vicino alla scheda e vedi se le letture sono simili e vicine allo zero e soprattutto immobili.

 

Oppure....niente di tutto questo...e con una risoluzione del genere leggi ogni cm di differenza della lunghezza dei cavi delle sonde (ma quanto sono lunghi?) e quindi devi fare una calibrazione/compensazione delle sonde....in pratica un offset

Link al commento
Condividi su altri siti

davideversari

ciao,

la prova dei 2 fissi e del variabile l'ho fatta subito e "purtroppo" i due fissi non variano al variare del variabile.

se ho capito bene il consiglio software che mi dai e ' di usare l interrupt generato dalla fine conversione , registro ADCON<1>  ADON per capirci?

questa cosa l ho fatta subito nel firmware.

ho inserito anche dei delay qua e la e tra i cambi di canale

 

e'quello che intendevi tu?

 

adesso faccio le prove a ZERO e immobilita'della lettura

 

riguardo all alimentazione e' a battteria , quindi direi che rumore non ne dovrebbe indurre. il cavo alimentazione e'5 cm , non schermato

 

 

Link al commento
Condividi su altri siti

Se cortocircuiti a zero volt i pins d'ingresso degli A/D dovrai leggere sempre 0 o, al più, 1. Se leggi più conteggi c'è un offset che puoi provare ad eliminare dando un leggero negativo a -Vref.

Po,i come dicevo prima, c'è il problema della non linearità dell'A/D, non linearità i cui limiti son dichiarati nel data sheet.

Link al commento
Condividi su altri siti

Se la prova fissi-variabile....i fissi rimangono fissi.....:superlol:....è inutile che modifichi il codice....almeno per questo scopo....

 

Quote

ho inserito anche dei delay qua e la e tra i cambi di canale

 

Sì, non proprio qua e la, ma solo dove serve....

 

 

Quote

e'5 cm , non schermato

mi immaginavo almeno una decina di metri.....

 

E rimane come dice Livio la non linearità, però essendo 1 solo AD multiplexato,  l'errore dovrebbe essere ripetibile.

Cercando nel datasheet non ho trovato nulla in proposito

 

ab83f8b1039d9e48c33413284fb5f93c.JPG

 

A questo punto....mi chiedo....come converti da counts alla tua grandezza?        Immagino °C

 

Io trovo comoda questa notissima funzione

 

act_temp=((AnVal-In_min)/(In_max-In_min))*(Out_max-Out_min)+Out_min;

 

Dove

AnVal  = risultato dell' AD

In_min = Valore minimo di AnVal

In_max = Valore max di AnVal

Out_min - Out_max = valori min e max che può assumere la grandezza in uscita

act_temp = grandezza in uscita (°C)

 

 

 

 

 

 

 

Link al commento
Condividi su altri siti

davideversari

ciao,

riguardo alla funzione utilizzo qualcosa di simile anche se per ora mi sono soffermato sul puro valore conversione.

ci ho lavorato sopra tutto oggi e alla fine per tentatitivi sono riuscito a capire il problema/i

anzitutto rumore tirato su dai cavi che collegano la batteria che genera i segnali (con partitore) ; i cavi non erano schermati e anche se corti, 25 cm

tiravano su un bel disturbo!  li ho messi in ordine ed accorciati e pur non avendo usato ne schermati ne twistati  e'cambiato gia' molto ; in pratica i valori sono stabili e pressoche' identici tra loro

ho raggiunto un +/- 2bits ,  +/- 1 mV all incirca , ampiamente tollerabile .

 

si evince che l'utilizzo di cavi schermati e twistati per le sonde sara' d'obbligo.

 

ho inserito nel firmware un piccolo delay, 1 ms , immediatamente prima della conversione, ed uno identico prima della successiva immediatamente in uscita dall INTERRUPT ADON

 

ho inserito ad inizio della fase conversione la CALIBRAZIONE dell ADC come da datasheet; questo ha reso molto precisa la conversione che ora +- 2 bits e' come il valore teorico.

 

NON ho usato VBGEN  il Vref 1,2 V   anche non ho ben capito se e' preciso come riferimento , la deriva termica , e se migliora le cose ?!

 

 

era un gourmet di problemi; l'essenziale e'che non fosse il PCB in quanto ne ho fatti fare gia 50 pz e ci ho lavorato sopra molto nella progettazione

sarebbe stato un vero problema

Ora almeno so che eventuali errori GROSSOLANI saranno da attribuire alle sonde

 

Vorrei sinceramente ringraziare chi mi ha aiutato e consigliato

 

Link al commento
Condividi su altri siti

1ms non è poi così piccolo, di solito a me basta 1us....ma se va bene così....ok

 

Per le sonde, quando si lavora in tensione come minimo si intrecciano i fili, altrimenti si lavora in corrente 0-20 oppure 4-20mA e si converte in tensione tramite resistenza in prossimità dei pin di ingresso, ma in ogni caso, onde evitare rogne è sempre buona norma twistare.

 

Anche per le resistenze nei partitori di segnale è necessaria un po' di cura. Se per la logica possono andar bene più o meno tutte, sul segnale è bene usarne di qualità-precisione e a strato metallico.

 

 

Link al commento
Condividi su altri siti

davideversari

ciao,

si intendevo 1 uS, scusami.

 

oggi ho lavorato ancora un po ed ho notato che un condensatore di filtro tra segnale e GND migliora ancora la "stabilita'" del segnale in uscita dagli MCP9700

 

in fine come da datasheet ho messo un resitore 200 ohm nella linea di alimentazione ed ho ottenuto delle conversioni a dir poco OTTIME!

 

purtroppo le sonde devono essere complete dei componenti passivi, i condensatori di filtro sono quindi a diversi metri dal datalogger  , quindi ho usato dei cavi twistati per portare il segnale al datalogger 2 coppie da 0,25 per evitare di tirare su altro disturbo.

 

 

 

Link al commento
Condividi su altri siti

Crea un account o accedi per commentare

Devi essere un utente per poter lasciare un commento

Crea un account

Registrati per un nuovo account nella nostra comunità. è facile!

Registra un nuovo account

Accedi

Hai già un account? Accedi qui.

Accedi ora
×
×
  • Crea nuovo/a...