Ho cantato vittoria troppo presto. Il portatile si accende correttamente, ma il problema è con la batteria: il led di ricarica si accende, ma la batteria non viene ricaricata e se da acceso con la batteria inserita e ancora carica all'83% (nuova di 4 mesi) tolgo l'alimentazione esterna, si spegne tutto
Che palle... dentro ci sono due flat che se li muovo ancora per l'ennesima apertura, si spezzano. Intanto li ordino e quando arriveranno riapro, sennò rimango senza portatile ancora.
Ho guardato tra i vari sketch vecchi, ma purtroppo mi è rimasta solo una delle prove fatte. Mi sembra impossibile non aver tenuto nulla! Probabilmente, non trovando il modo di farlo funzionare, l'ho modificato e l'ho salvato senza cambiare nome al file. D'altronde, in quel mese dove ho fatto tutto da zero, i giorni erano tutti molto concitati. Sono mortificato, davvero.
Non riesco nemmeno a fare delle prove, perchè arduino è tutto saldato al resto del circuito e la scatolina è sigillata.
Ricki, purtroppo non ti so essere d'aiuto, non mi ricordo nulla di quelle prime prove, perchè in questi due mesi sono successe talmente tante cose... o forse è l'alzheimer che si manifesta
#include <SoftwareSerial.h>
#define rxPin 1
#define txPin 0
void setup()
{
(La seriale va inizializzata solo se arduino la utilizza)
...
...
...
SoftwareSerial mySerial = SoftwareSerial(rxPin, txPin);
pinMode(rxPin, INPUT);
pinMode(txPin, OUTPUT);
mySerial.begin(115200);
...
...
...
}
Forse invertivo rx e tx col pinMode nel caso di un utilizzo piuttosto che un altro, o forse usavo il SoftwareSerial in un caso, mentre il normale Serial nell'altro.
Ti tocca fare un po' di prove, perchè il modo c'era. Oppure è stato proprio il problema del caricamento del codice che mi ha portato ad usare il relè... Bohhh
Ho un casino in testa...
Costruiamo un visualizzatore per 4 sonde EGT??
- Fabius72
- Messaggi: 878
- Iscritto il: 09/02/2013, 16:55
- ECU: MS2 V3.0
- Località: Valle d'Aosta
- ricki158
- Messaggi: 934
- Iscritto il: 20/04/2012, 16:51
- Auto: Fiat 127 mk2 900/C - 1980
- ECU: MS1 V2.2
- Località: Gorizia
Re: Costruiamo un visualizzatore per 4 sonde EGT??
tranquillo Fabio, cerco di fare da me e vedo che combino. per inizializzare le seriali non dovrei avere problemi, il problema è passare i dati dal software serial alla serial, quindi farli passare per l'ftdi
- Fabius72
- Messaggi: 878
- Iscritto il: 09/02/2013, 16:55
- ECU: MS2 V3.0
- Località: Valle d'Aosta
Re: Costruiamo un visualizzatore per 4 sonde EGT??
Ciao a tutti!!!
Scusate per la prolungata assenza, ma ho avuto un po' di casini e ho lasciato tutto in stand-by.
Ero andato un po' in crisi col progetto per i vari problemi che non riuscivo a risolvere e di tanto in tanto lo riprendevo migliorando un po' qua e un po' la, ma avevo grossi problemi di fondo col codice:
1- ho cominciato a combattere con la memoria di arduino che monta l'atmega328. Mi sono scontrato con la poca memoria che ha e ho scoperto che è di 2 tipi: circa 30KB per il programma e 2kB per le variabili e altre cose. Troooooppo pochi!! Non capivo il perchè dei malfunzionamenti, pur non occupando tutti i 30KB, poi scoprii che durante il funzionamento servivano ben più dei 2KB di sram e si impallava tutto in modi imprevedibili!
Quindi ho dovuto imparare alcune tecniche di ottimizzazione del codice per risparmiare singoli byte qua e la, e snellire a più non posso. Cazz è stata dura, veramente!
2 - Ho scoperto che il buffer di ricezione di arduino è di default di soli 64byte! Occorre quindi portarlo a 256 per poter leggere tutta la stringa! Anche qui, arrivarci... Quanto tempo!
All'inizio del file che posterò al più presto, come promesso, troverete tutte le informazioni necessarie, spero di aver spiegato TUTTO per bene.
3 - Letture seriali: ho scoperto la fonte dei miei problemi! E' NECESSARIO un delay di 100uSec (il minimo possibile da test fatti) tra la lettura di un byte e la successiva nella stringa che arriva dalla MS. In questo modo la seriale invia sempre ogni 125mS col comando "A" e le letture dei byte sono sempre perfette. Anche qui capirlo è stata un'impresa!
4 - incubo con valori di conversione CLT e MAT ---> risolto! Ne ho parlato qualche pagina indietro e ho scoperto che nel file ini sono riportati valori di conversione sbagliati! Devo segnalarlo a James.
5 - la libreria per poter fare i log su SD è troppo grande, occupa una montagna di KB sia di ram che di sram e ho scoperto ed usato la Fat16 che è snella e funziona alla grande!
Questi sono stati imuri fino a qualche tempo fa invalicabili, ma con costanza e tempo sono riuscito quasi a terminare l'opera.
Ora ho implementato il newSerial al posto del semplice comando "A", ma lo spiego più tardi, vado a preparare la pappa che è tardi!
Ciauuu
Scusate per la prolungata assenza, ma ho avuto un po' di casini e ho lasciato tutto in stand-by.
Ero andato un po' in crisi col progetto per i vari problemi che non riuscivo a risolvere e di tanto in tanto lo riprendevo migliorando un po' qua e un po' la, ma avevo grossi problemi di fondo col codice:
1- ho cominciato a combattere con la memoria di arduino che monta l'atmega328. Mi sono scontrato con la poca memoria che ha e ho scoperto che è di 2 tipi: circa 30KB per il programma e 2kB per le variabili e altre cose. Troooooppo pochi!! Non capivo il perchè dei malfunzionamenti, pur non occupando tutti i 30KB, poi scoprii che durante il funzionamento servivano ben più dei 2KB di sram e si impallava tutto in modi imprevedibili!
Quindi ho dovuto imparare alcune tecniche di ottimizzazione del codice per risparmiare singoli byte qua e la, e snellire a più non posso. Cazz è stata dura, veramente!
2 - Ho scoperto che il buffer di ricezione di arduino è di default di soli 64byte! Occorre quindi portarlo a 256 per poter leggere tutta la stringa! Anche qui, arrivarci... Quanto tempo!
All'inizio del file che posterò al più presto, come promesso, troverete tutte le informazioni necessarie, spero di aver spiegato TUTTO per bene.
3 - Letture seriali: ho scoperto la fonte dei miei problemi! E' NECESSARIO un delay di 100uSec (il minimo possibile da test fatti) tra la lettura di un byte e la successiva nella stringa che arriva dalla MS. In questo modo la seriale invia sempre ogni 125mS col comando "A" e le letture dei byte sono sempre perfette. Anche qui capirlo è stata un'impresa!
4 - incubo con valori di conversione CLT e MAT ---> risolto! Ne ho parlato qualche pagina indietro e ho scoperto che nel file ini sono riportati valori di conversione sbagliati! Devo segnalarlo a James.
5 - la libreria per poter fare i log su SD è troppo grande, occupa una montagna di KB sia di ram che di sram e ho scoperto ed usato la Fat16 che è snella e funziona alla grande!
Questi sono stati imuri fino a qualche tempo fa invalicabili, ma con costanza e tempo sono riuscito quasi a terminare l'opera.
Ora ho implementato il newSerial al posto del semplice comando "A", ma lo spiego più tardi, vado a preparare la pappa che è tardi!
Ciauuu
Fabio
- Vicus
- Messaggi: 2753
- Iscritto il: 15/11/2010, 19:59
- Località: Rossano Veneto
Re: Costruiamo un visualizzatore per 4 sonde EGT??
I miei complimenti.
- masterx81
- Messaggi: 14417
- Iscritto il: 15/11/2010, 16:43
- Auto: Corsa Gsi, Subby WWW
- ECU: MS3 EXP
- Località: Asti
Re: Costruiamo un visualizzatore per 4 sonde EGT??
Bel lavoro di sviluppo
... Enrico
Ho perso il rispetto di me stesso al Megaraduno 2012 :-)
Ho perso il rispetto di me stesso al Megaraduno 2012 :-)
- ricki158
- Messaggi: 934
- Iscritto il: 20/04/2012, 16:51
- Auto: Fiat 127 mk2 900/C - 1980
- ECU: MS1 V2.2
- Località: Gorizia
Re: Costruiamo un visualizzatore per 4 sonde EGT??
Sei riuscito a velocizzare le letture? Forse l'hai detto e sono rimasto indietro.
- Fabius72
- Messaggi: 878
- Iscritto il: 09/02/2013, 16:55
- ECU: MS2 V3.0
- Località: Valle d'Aosta
Re: Costruiamo un visualizzatore per 4 sonde EGT??
Ho qui pronto il codice che avevo terminato poco prima di Natale, ma col comando "A" ottenevo una lettura dei dati e un record su SD ogni 125ms, circa 8 record al secondo.
Ho avviato per prova il motore e fatto un log, ma 8 record sono un po' pochini se ci si vuole fare qualcosa di serio.
Così, tempo permettendo mi son messo a capirci qualcosa del newSerial.
Ho imparato ad usarlo e ho creato uno sketch per tutte le prove di lettura/scrittura e registrazione su SD, ma ora sto cercando di inserire tutto l'occorrente nel programma già fatto, e spero ci stia, sennò ho buttato un pacco di lavoro.
A vuoto, senza log attivo, ho letture ogni 26-27ms!!
Mentre registra su SD un record in circa 50ms, 20-21 record al secondo. Ora si ragiona!
Tra le prove fatte c'è anche quella di variare al volo l'angolo di iniezione sequenziale, col simulatore e la centralina funzionante a 1000RPM.
Il delay registrato su SD tra un record con angolo di iniezione vecchio e quello col nuovo valore è di circa 250ms senza false letture o casini vari in mezzo. Son troppo contento, anche perchè 200ms sono il delay necessario quando si cambia "pagina" di lavoro nella comunicazione con la MS, quindi meglio di così non posso fare.
Più avanti parleremo dei parametri che sarebbe utile poter cambiare al volo per vedere nell'immediato cosa cambia
I parametri che ho deciso di loggare sono questi:
Time SecL RPM km/h kml FuelLoad TPS veCurr ADV coldADV MAP Baro airtemp AFR AFRtgt egoV CLT MAT WUE BAROcor AIRcor EGOcor accEnr gammaE IAC Batt V Inj_adv PW1 PW2 PW3 PW4 veTrim1 veTrim2 veTrim3 veTrim4 EGT1 EGT2 EGT3 EGT4 TPSdot MAPdot dwell cl_idle_TgtRpm synccnt syncreason Engine
Vi viene in mente altro che sarebbe utile avere quando si logga? E perchè?
Grazie.
Dimenticavo... Ho scollegato il sensore VSS da Arduino perchè nella lettura perdeva dei colpi, evidentemente il codice faceva altro mentre cambiava il livello logico della porta alla quale era attaccato il sensore. Ho sentito parlare degli "interrupt" ma non ho idea di come si debbano usare.
Fatto sta che ho deciso di metterci al suo posto un LM35 per avere anche la temperatura ambiente (ancora da collegare).
Mentre il sensore VSS l'ho collegato all'AD6 della MS tramite un convertitore frequenza/tensione.
In questo modo avrò il consumo istantaneo tenendo conto della tensione batteria e dei 4 diversi dead time degli iniettori. L'ho solo testato al banco e spero funzioni anche nella realtà!
Fabio
- vitoos
- Messaggi: 5615
- Iscritto il: 24/09/2011, 18:30
- Auto: Fiat Panda 100HP
- ECU: MS3 EXP
- Località: salerno
Re: Costruiamo un visualizzatore per 4 sonde EGT??
veramente ottimo lavoro fabio! un valore che si potrebbe loggare potrebbe essere la pressione benzina giusto per capire come cambia con il motore sotto carico e come reagiscono gli inniettori
lasciate qui ogni speranza voi che entrate su questo forum......
comunque sia io grazie a questo forum ho svegliato vecchi tarli addormentati nel mio cervello ed ora mi tocca dargli da mangiare uno ad uno per tenerli buoni
comunque sia io grazie a questo forum ho svegliato vecchi tarli addormentati nel mio cervello ed ora mi tocca dargli da mangiare uno ad uno per tenerli buoni
- Fabius72
- Messaggi: 878
- Iscritto il: 09/02/2013, 16:55
- ECU: MS2 V3.0
- Località: Valle d'Aosta
Re: Costruiamo un visualizzatore per 4 sonde EGT??
Grazie vitoos, però forse mi son spiegato male: intendevo tra i parametri che ho deciso di scartatare.
Non sono molto pratico nello studio dei log e magari c'è qualche parametro che non sto loggando che invece è importante avere sotto controllo... per l'interazione che ci può essere con qualche altro dato.
Quel che dici te è vero, potrebbe dare indicazioni interessanti. Nel cruscottino della moto ho inserito il manometro elettronico ma non ho più ingressi liberi nella MS, per cui devo farne a meno.
Non sono molto pratico nello studio dei log e magari c'è qualche parametro che non sto loggando che invece è importante avere sotto controllo... per l'interazione che ci può essere con qualche altro dato.
Quel che dici te è vero, potrebbe dare indicazioni interessanti. Nel cruscottino della moto ho inserito il manometro elettronico ma non ho più ingressi liberi nella MS, per cui devo farne a meno.
Fabio
- Fabius72
- Messaggi: 878
- Iscritto il: 09/02/2013, 16:55
- ECU: MS2 V3.0
- Località: Valle d'Aosta
Re: Costruiamo un visualizzatore per 4 sonde EGT??
Fabius72 ha scritto:...
Il delay registrato su SD tra un record con angolo di iniezione vecchio e quello col nuovo valore è di circa 250ms senza false letture o casini vari in mezzo. Son troppo contento, anche perchè 200ms sono il delay necessario quando si cambia "pagina" di lavoro nella comunicazione con la MS, quindi meglio di così non posso fare.
...
Sbagliato. Ho chiesto a James e col newSerial non c'è più bisogno del delay.
Ho quindi modificato il codice per poter avere, con un unico comando, il read, il write, il burn e il controllo crc32.
Nei log che ho fatto di prova il burn impiega meno di 100ms, mentre le letture e scritture non si notano nemmeno.
L'unica cosa che rompe del burn, è che ferma il loop della centralina, quindi perde sincronismo e spegne il motore. Anche se per meno di un secondo, rompe le balle e non so se può causare qualche inconveniente.
Voi che viaggiate in macchina col portatile collegato per il tuning, fate il burn senza preoccuparvi dei giri motore?
Oppure è meglio evitarlo al di sopra del minimo, per via che lo spegnimento così brusco (ad esempio a 4000 giri) può meccanicamente compromettere qualcosa? Tipo le conseguenze del "colpo d'ariete"?
Fabio
Torna a “Elettronica generale”
Chi c’è in linea
Visitano il forum: Nessuno e 23 ospiti