masterx81 ha scritto:Allora, mi sono divertito a simulare con ltspice il circuito da me proposto:

(per c1 4.7uf è un valore piu' consigliato per evitare errori alle basse frequenze)
E questa è la forma d'onda risultante:

La traccia verde è la tensione di ingresso (20vpp), in blu è la traccia dopo resistenza e condensatore (i 20vpp di ingresso non erano sufficienti a far clippare il segnale ai diodi, ma anche se clippavano non cambiava nulla), quella azzurrina è il segnale del pin invertente (riferimento fisso a 2,5v), mentre il rosso e' il segnale di uscita.
Direi che sembra tutto corretto...
Credo proprio di avere capito ed hai ragione, l'incomprensione è dovuta ad un problema di condensatore...non so perche' ma mi ero fissato su un C di tutt'altro valore, molto piu' piccolo; per mia curiosita', potresti provare a cambiare solo quello nella simulazione (mettendo, chesso', 220pF) per vedere se cambia stato in prossimità delle creste come (forse erroneamente) avevo supposto ?
Per la logica di funzionamento, un convertitore f/v e relativo filtro passabasso e successiva acquisizione adc non dovrebbe causare particolari errori, forse rallenta un po la risposta, ma alla fine è lo scopo di prendere piu' campioni via sw... Cert che se vuoi precisione assoluta non è la soluzione migliore.
Si, è un discorso di precisione...vorrei evitare condensatori e resistenze "pregiati" come tolleranza ed avere una risposta immediata.
Se no se preferisci comunque farlo via sw tutto in digitale (per avere la max preciisone), un'altra alternativa è usare una pic piccolissima ed economica per ogni segnale, ognuna lavora il suo sensore, poi via una comunicazione seriale di tipo master/slave comunicano con un altro microcontrollore che prende i segnali e li elabora. Ammettendo che ogni chip deve trasmettere 1byte (velocita' da 0 fino a 255km/h con tolleranza di 1kmh), con una velocita' seriale di 115kbps dovresti farcela a fare tutto in pochisimo tempo. Persino con 2 byte non dovresti avere problemi.
La cpu principale oltre la linea seriale utilizza anche un pin connesso ad ogni chip, che una volta alzato abilita la trasmissione della lettura di velocita', così non avvengono collisioni sulla unica linea di comunicazione, e la mcu principale gira a rotazione tutte le mcu secondarie.
Si', è una buona idea...nella mia scheda di acquisizione c'e' una cosa del genere : visto che dovevo misurare il duty cycle degli iniettori ed i timer nel processore principale (16F877) erano finiti, ho messo un piccolo 12F675 che, oltre a misurare il dutycycle, legge ulteriori ingressi analogici (cosi' ho evitato multiplexer analogici). I dati sono trasmessi periodicamente via seriale a quello principale...
Poi volendo fare una cosa strafiga puoi fare che la mcu principale trasmetta all'accensione alle mcu periferiche i parametri come numero di campioni da prendere prima di aggiornare il registro (il discorso del compare che facevo prima), oppure ad esempio la circonferenza della ruota per il calcolo della velocita', etc. Così se cambi ruote non devi riprogrammare tutti i chip.
Questo mi sembra il modo migliore per avere precisione di lettura assoluto, e direi che rimarrebbe un gran bel progettino.
Un altro uso interessante potrebbe essere di rilevare una ruota che sis sta sgonfiando, se in un arco di tempo da decidere una ruota non gira alla medesima velocita' delle altre, sai che è sgonfia

Che ne dici?
Ci penso

A me piacciono da morire ste cose perchè ci son 1000 modi per realizzarle, ed il solo limite è la fantasia...
Carino il sistema di acquisizione, che cosa è? Come ci entri dentro per loggare la velocità?
E' un sistema basato su un pic 16F877 e, come detto sopra, un 12F675, che campiona una serie di parametri ad intervalli regolari e li trasmette in continuazione al principale in seriale a 19.2 kbps. Il fatto di avere un pacchetto sempre della stessa lunghezza ed un checksum alla fine, mi ha permesso di evitare handshaking. Comunque, il dato è letto da un display e reso disponibile ad un eventuale pc per fare il datalog...il display è questo

.
Nel corso del tempo ho aggiunto funzioni sempre nuove, tra le varie cose :correzione % della velocita' per compensare differenti rotolamenti, 2 contakm parziali, consumo istantaneo km/l che diventa lt/h quando mi fermo, consumo medio (associato ad un trip parziale), allarmi per temperature eccessive, pressione olio bassa, % duty cycle iniettori, % farfalla, un cronometro impostabile a step di 10 kmh (da 10 a 100, da 20 a 200, ecc) con precisione 1/10, il cronometro per la pista (visualizza il tempo per 5 sec. quando il ricevitore, un TSOP1738, riceve il pacchetto IR trasmesso dalla torretta) ed altre cose che ora mi sfuggono...
Ora, vorrei sviluppare ulteriormente il sistema rendendo la comunicazione piu' "razionale" ed aggiungendo magari l'accelerometro, le velocita' delle ruote dietro, ecc...
Velocita' e giri le prendo come detto prima con i due capture...se intendi a livello hardware, partitore resistivo e diodo 1N4148 tra pin del pic e +5 per tagliare sopra i 5.7 V (anche se non sarebbe necessario perche' i diodi ci sono internamente...), il segnale fornito dallo speed sensor è un'onda quadra 0/12V, mi pare sui 66 Hz @ 100 kmh.