Allora, da quello che mi ha detto james l'uscita del tacho è abbastanza affidabile, ovvero viene 'sparata' nella routine di decodifica della ruota, ed è legata all'angolo dell'albero della ruota fonica.
Che alla fine è quello che avevo scoperto io oscilloscopio alla mano, anche se avevo notato un errore di qualche grado ad rpm elevatissimi (no so se per latenze sw o per latenze hw), ma la cosa non mi preoccupa, se la finestra di windowing si sposta di 1 o 2° non cambia nulla.
Quindi, l'idea continua ad essere quella di sfruttare il tacho per rilevare il pms, con futura opzione un integrato che permette la decodifica al volo della ruota.
Nel caso volessimo sapere quale cilindro ha detonato, penso la cosa piu' semplice sia interfacciarsi ad una uscita digitale che poi va verso le bobine, così da avere il riferimento del primo cilindro. Nel caso di cpu aggiuntiva per decodifica ruota in modalita' 'standalone' (separata dalla ms) il chip stesso si occupera' di decodificare anche il segnale di camma.
Come dicevo, preferisco fare in questo modo, così a chi interessa averlo solo attaccato alla ms non deve pagare per una mcu piu' costosa e relativi circuiti di condizionamento, ed il codice risulta piu' pulito e snello.
Ad ora sapere che cilindro ha detonato non credo sia una cosa indispensabile, tanto se non è la centralina a tirare indietro l'anticipo di quel singolo cilindro non serve a molto...
Sul sito msextra c'e' uno che si è cimentato a fare un circuito simile, che vende alla 'modica' cifra di 150$... Ha applicato anche la procedura di autoapprendimento del rumore di fondo come pensavo di farla io
Io penso di poter stare entro cifre molto piu' ragionevoli.
Lui per mandare il segnale di knock alla centralina usa dei DAC, e per campionare il segnale di detonazione usa il canale analogico... Non mi sembra un buon metodo...
Io pensavo di leggere il livello di knock via spi, e sfruttare l'uscita analogica della tpic da mandare alla centralina. Peccato che il segnale di uscita durante il tempo di integrazione fa una rampa, che darebbe fastidio sicuramente alla megasquirt (la stessa non fa per ora windowing, fa un pooling a tempo fisso del segnale analogico del livello di knock, non relazionato agli rpm).
Il tpic è pensato per acquisire il valore solo alla fine della finestra di windowing. Per risolvere questa rogna, pensavo di usare un semplice circuito di sample & hold, che mantenga costante il segnale di uscita fino a che non c'e' una nuova campionatura disponibile.
Tanto il segnale di uscita della tpic è direttamente proporzionale al livello di detonazione, perchè farlo entrare nella mcu per poi doverlo fare riuscire?
Una volta impostati i parametri della tpic (costante integrazione, amplificazione, frequenza, etc), è la stessa a dare il valore corretto... La mcu legge il valore solo per statistiche 'interne', o per accendere un buzzer o una spia. Mentre la megasquirt riceve il suo segnale analogico.
Usando questi accorgimenti mi risparmio dei passaggi inutili di ADC/DAC, lavoro di processore, costi che ritengo inutili, etc.
Che ne dite?
... Enrico
Ho perso il rispetto di me stesso al Megaraduno 2012 :-)
