[TuneECU] rimappare la centralina motore della tua Triumph da soli e gratis: DOMANDE e RISPOSTE

[Dennis]

l ho testata per il seghettamento, facendo varie prove ad andatura costante dai 2000 ai 5000 rpm, con un apertura tps che variava in funzione delle marce che avevo inserito...
risultato : molto meglio di prima, seghettamento molto meno invadente sul range 2200/3500 , un po di piu dai 3500/4500 circa....
comunque , testerò meglio, ma se rimane così potrebbe essere un buon compromesso, o almeno un buon punto di partenza...

Proprio dove ti rimangono i famosi "14.50".... per la prossima prova, direi che sai che cosa fare...

Premetto di non aver letto nulla a riguardo e nel caso di doppio post mi scuso!
[I][U][COLOR="Red"]
Se si cambiano le impostazioni della porta da 9600 (classico tramissione FAX) al massimo permesso dal driver si legge e scrive la centrale in meno di 3 minuti!...

Interessantissimo, da provare... soprattutto se questa impostazione consente di far aggiornare i dati della schermata dei sensori più velocemente..!

[Fra881]

Interessantissimo, da provare... soprattutto se questa impostazione consente di far aggiornare i dati della schermata dei sensori più velocemente..!

mmh non credo, il segnale che mandano i sensori è di pochi bit e il problema non è la banda, ma la frequenza di aggiornamento dei sensori stessi

[pippo.sk8]

Se si cambiano le impostazioni della porta da 9600 (classico tramissione FAX) al massimo permesso dal driver si legge e scrive la centrale in meno di 3 minuti!...
e quindi si puo' evitare di staccare i fusibili:

Interessantissimo, da provare... soprattutto se questa impostazione consente di far aggiornare i dati della schermata dei sensori più velocemente..!

mmh non credo, il segnale che mandano i sensori è di pochi bit e il problema non è la banda, ma la frequenza di aggiornamento dei sensori stessi

Confermo, aggiungo solo che si parla di massima banda disponibile e dipende sempre da quanto il dispositivo collegato sia capace a "negoziare" il collegamento!
Si consideri poi che ogni mappa è di massimo 290k
Ribadisco si evita di staccare i fusibili dei fari per salvaguardare la batteria!!

[la mela verde]

Confermo, aggiungo solo che si parla di massima banda disponibile e dipende sempre da quanto il dispositivo collegato sia capace a "negoziare" il collegamento!
Si consideri poi che ogni mappa è di massimo 290k
Ribadisco si evita di staccare i fusibili dei fari per salvaguardare la batteria!!

io non riesco a trovarle le impostazioni della porta

eppure vado in pannello di controllo-sistema ecc ecc
ho xp professional

[cary73]

scusate e' possibile cambiare mappa su una street originale scarichi e filtri e se si quale?
grazie

[automan73]

Qualcuno di voi ha avuto problemi di timeout?
Praticamente riesco ad accedere alla ECU, leggo serial number, codice mappa e checksum: nella pagina diagnostics leggo correttamente tutti i valori dei vari sensori.
Ma se entro in modalità mappa e cerco di leggere quella caricata nella ECU, la barra verde in basso inizia ad avanzare progressivamente e la spia verde a dx è accesa fissa. Dopo pò la spia verde a dx inizia a lampeggiare e la barra verde si blocca ad una percentuale random: dopo qualche secondo che permane questa situazione esce fuori il messaggio "Timeout, transfer failed."
Windows XP SP3, tuneecu v1.6.7 (provato con risultato analogo anche la v1.6.6), FTDI drivers v2.06.02 e framework 3.5 SP1. ECU Sagem, VIN 177XXX.
Spero di essermi spiegato bene: avete idea di cosa potrebbe essere?
Interessante la funzione history:

History :
Reading in progress... 1 - Map : ???? (10113), Checksum : 80E
2 - Map : 10093 (10093), Checksum : C8A3
3 - Map : 10119 (10093), Checksum : 41C9
4 - Map : 10152 (10152), Checksum : C7BC
5 - Map : 10158 (10152), Checksum : 6B
6 - Map : 10152 (10152), Checksum : C7BC
7 - Map : 10156 (10152), Checksum : 40E2

Praticamente credo sia la storia delle mappe caricate sulla ECU.

[Dennis]

mmh non credo, il segnale che mandano i sensori è di pochi bit e il problema non è la banda, ma la frequenza di aggiornamento dei sensori stessi

eheh no, i sensori sono elementi analogici e la centralina esegue calcoli alla velocità di un computer a 32 bit, l'eventuale delay sul programma è dato dall'interfaccia di collegamento al Pc e dai protocolli usati per la comunicazione.
Comunque ottima la conferma di firemaker, così com'era faceva abbastanza pena la schermata dati.

[Fra881]

eheh no, i sensori sono elementi analogici e la centralina esegue calcoli alla velocità di un computer a 32 bit, l'eventuale delay sul programma è dato dall'interfaccia di collegamento al Pc e dai protocolli usati per la comunicazione.
Comunque ottima la conferma di firemaker, così com'era faceva abbastanza pena la schermata dati.

meglio così, anche l'equilibratura dei corpi era abbastanza difficile da controllare con quella frequenza di aggiornamento.
anche se mi rimane sempre il punto interrogativo sopra la testa... il segnale già digitalizzato dalla centralina e mandato al pc dovrebbe essere davvero piccolo, alla fine dentro cosa c'è, il numerino e le informazioni relative al sensore di provenienza del segnale, cioè se quello è il dato map, rpm ecc. non dovremmo andare oltre i pochi byte

[firemaker]

eheh no, i sensori sono elementi analogici e la centralina esegue calcoli alla velocità di un computer a 32 bit, l'eventuale delay sul programma è dato dall'interfaccia di collegamento al Pc e dai protocolli usati per la comunicazione.
Comunque ottima la conferma di firemaker, così com'era faceva abbastanza pena la schermata dati.

si prima era veramente lento nell'aggiornarsi... ora tutte i sensori rispondono in tempo reale...anche la lettura sui giri,tipo ora si riesce a leggere di quanto oscilla il minimo senza leggere dei valori random 1 volta al secondo heheh