|
Utente
Posts: 32
10,37 ore
Rome
| arkymede74 - 17/11/2020 12:20 PM
Se puoi, cerca di essere un pelo più gentile con chi, per diletto come te, cerca di aiutarti. ... Aggiungo: se lo schema riporta gli optoisolatori e non i Darlington un motivo ci sarà..che dici? te lo dice un ingegnere elettronico.
Prima di collegarlo all'auto ho verificato I livelli di ingresso e di uscita, non sono esattamente un neofita ma nel dubbio hai fatto bene a scriverlo. Sospetto che multiecuscan usi le linee dtr e rts in modo non adatto al mio cavo, riducendo quindi i livelli al di sotto della soglia minima. Appena avrò tempo verificherò con un oscilloscopio.
Per la cronaca, prima che venissero eliminati, i 4 post consecutivi di pietro, Pietro sembrava un pelino aggressivo. Evidentemente sbagliavo. Pietro, non c'é veramente bisogno che rispondi a questo post (resisti), é chiaro che ho frainteso.
La mia DOMANDA rimane ancora senza risposta: qualcuno ha mai usato quel cavo col multiecuscan? Veramente grazie a tutti ma non mi occorrono altri suggerimenti. | |
|
1.9 JTDM Owner
Blu oltremare
Posts: 1262
867,32 ore
 
Rosolini (SR)
| Acqua - 18/11/2020 7:04 AM arkymede74 - 17/11/2020 12:20 PM
Se puoi, cerca di essere un pelo più gentile con chi, per diletto come te, cerca di aiutarti. ... Aggiungo: se lo schema riporta gli optoisolatori e non i Darlington un motivo ci sarà..che dici? te lo dice un ingegnere elettronico.
Prima di collegarlo all'auto ho verificato I livelli di ingresso e di uscita, non sono esattamente un neofita ma nel dubbio hai fatto bene a scriverlo. Sospetto che multiecuscan usi le linee dtr e rts in modo non adatto al mio cavo, riducendo quindi i livelli al di sotto della soglia minima. Appena avrò tempo verificherò con un oscilloscopio.
Per la cronaca, prima che venissero eliminati, i 4 post consecutivi di pietro, Pietro sembrava un pelino aggressivo. Evidentemente sbagliavo. Pietro, non c'é veramente bisogno che rispondi a questo post (resisti), é chiaro che ho frainteso.
La mia DOMANDA rimane ancora senza risposta: qualcuno ha mai usato quel cavo col multiecuscan? Veramente grazie a tutti ma non mi occorrono altri suggerimenti.
Tralasciando il discorso di relazioni interpersonali, dove colleghi questa interfaccia? direttamente ad una serial port su pc o tramite adattatore USB? in quest'ultimo caso dovresti esser sicuro di usare un adattatore con un chip specifico, come suggerito nei primi post. Poi, hai provato a cercare su rete il software fiatecuscan? magari potrebbe esserti di aiuto per debuggare l'interfaccia.
Edited by arkymede74 18/11/2020 9:15 PM
| |
|
Utente
Posts: 32
10,37 ore
Rome
| arkymede74 - 18/11/2020 9:14 PM Poi, hai provato a cercare su rete il software fiatecuscan? magari potrebbe esserti di aiuto per debuggare l'interfaccia. non riesco a trovare il vecchio software fiatecuscan | |
|
Utente
Posts: 32
10,37 ore
Rome
| I livelli trasmessi e ricevuti sono idonei a supportare la comunicazione, non capisco quale sia il problema...
Ho appreso varie info: La velocità di questo protocollo è compreso tra 1200 e 10400 bps Oltre agli 8 bit di dati, come sulla linea 232, è presente un bit di start e uno di stop. A pagina 20 del protocollo di cui sopra troviamo lo scambio dati che ho potuto acquisire interponendomi tra multiecuscan e alfa Leggendolo scopriamo che i codici dell'alfa sono proprietari e non definiti dal protocollo, quindi le info per decodificare i messaggi vanno cercate altrove Ma ad ora non le ho trovate Di seguito riporto il Colloquio tra multiecuscan e alfa, su pressione del tasto "connect":
Il Multiecuscan trasmette 5 byte (da leggere invertiti, perché vengono invertiti sulla schedina di interfaccia): Byte 1: 1111110 - dopo inversione diventa= 10000001 - che in HEX corrisponde a 81 ->Significato: Format Byte Byte 2: 11110111 - dopo inversione diventa= 1000 - che in HEX corrisponde a 8 ->Significato: Target address Byte 3: 1110000 - dopo inversione diventa= 10001111 - che in HEX corrisponde a 8F ->Significato: Source address Byte 4: 1111110 - dopo inversione diventa= 10000001 - che in HEX corrisponde a 81 ->Significato: Request Service ID Byte 5: 111111 - dopo inversione diventa= 11000000 - che in HEX corrisponde a C0 ->Significato: Checksum
Dopo una pausa di 24msec l'Alfa 159 jtdm 1.9 del 2009 risponde:
Byte 1: 111110 - dopo inversione diventa= 11000001 - che in HEX corrisponde a C1 ->Significato: Format Byte Byte 2: 1110000 - dopo inversione diventa= 10001111 - che in HEX corrisponde a 8F ->Significato: Target address Byte 3: 11110111 - dopo inversione diventa= 1000 - che in HEX corrisponde a 8 ->Significato: Source Address Byte 4: 1111100 - dopo inversione diventa= 10000011 - che in HEX corrisponde a 83 ->Significato: Additional Length Byte 5: 1000 - dopo inversione diventa= 11110111 - che in HEX corrisponde a F7 ->Significato: Response Service ID Byte 6: 1110 - dopo inversione diventa= 11110001 - che in HEX corrisponde a F1 ->Significato: Key Byte Byte 7: 111100 - dopo inversione diventa= 11000011 - che in HEX corrisponde a C3 ->Significato: Checksum
Di seguito alcune foto:
Per motivi di spazio non vi mando tutte le foto... quanto condiviso rende l'idea. Ovviamente ho visto cosa viene trasmesso dal pc, cosa viene ricevuto dall'alfa, cosa risponde l'alfa e cosa riceve il pc. Il livello del segnale ricevuto e trasmesso dall'alfa é compreso tra 0 e 11 volt circa, mentre i livelli del segnale ricevuto dal pc son compresi tra 4,5V e -6 volt. Secondo il protocollo 232 gia' 3 volt sono sufficienti a discriminare il livello logico alto, quindi la comunicazione dovrebbe avvenire senza problemi...
Edited by Acqua 27/11/2020 7:40 PM
| |
|
Utente
Posts: 32
10,37 ore
Rome
| arkymede74 - 18/11/2020 9:14 PM dove colleghi questa interfaccia? direttamente ad una serial port su pc o tramite adattatore USB? in quest'ultimo caso dovresti esser sicuro di usare un adattatore con un chip specifico, come suggerito nei primi post. l'adattatore usb-232 usa chip PL2303. | |
|
Utente
Posts: 32
10,37 ore
Rome
| Rettifico in parte il mio precedente messaggio. Lo scambio acquisito corrisponde alla sequenza "start Communication" descritto sulla sezione 3 del protocollo (primo link), e l'alfa risponde correttamente. Ecco il messaggio decodificato correttamente:
Il Multiecuscan trasmette 5 byte (da leggere invertiti, perché vengono invertiti sulla schedina di interfaccia): Byte1->1111110->dopo inversione diventa->10000001->Poi i bit vanno invertiti per leggerli da destra a sinistra->10000001->che in HEX corrisponde a 81->Significato: Physical Address, trasmesso 1 byte(service ID request) Byte2->11110111->dopo inversione diventa->1000->Poi i bit vanno invertiti per leggerli da destra a sinistra->10000->che in HEX corrisponde a->10->Significato:Target address (l'indirizzo dell'alfa) Byte3->1110000->dopo inversione diventa->10001111->Poi i bit vanno invertiti per leggerli da destra a sinistra->11110001->che in HEX corrisponde a F1->Significato: Source address: indirizzo del multiecuscan Byte4->1111110->dopo inversione diventa->10000001->Poi i bit vanno invertiti per leggerli da destra a sinistra->10000001->che in HEX corrisponde a 81->Significato: Start Communication Byte5->111111->dopo inversione diventa->11000000->Poi i bit vanno invertiti per leggerli da destra a sinistra->11->che in HEX corrisponde a->3->Significato:Checksum - somma dei byte (corretto)
Dopo una pausa di 24msec l'Alfa 159 jtdm 1.9 del 2009 risponde: Byte1->111110->dopo inversione diventa->11000001->Poi i bit vanno invertiti per leggerli da destra a sinistra->10000011->che in HEX corrisponde a 83->Significato: Physical Address, trasmessi 3 byte(Service ID, 2 key bytes) Byte2->1110000->dopo inversione diventa->10001111->Poi i bit vanno invertiti per leggerli da destra a sinistra->11110001->che in HEX corrisponde a F1->Significato: Target address(l'indirizzo del multiecusan) Byte3->11110111->dopo inversione diventa->1000->Poi i bit vanno invertiti per leggerli da destra a sinistra->10000->che in HEX corrisponde a->10->Significato: Source Address(l'indirizzo dell' alfa) Byte4->1111100->dopo inversione diventa->10000011->Poi i bit vanno invertiti per leggerli da destra a sinistra->11000001->che in HEX corrisponde a C1->Significato:Positive Response Byte5->1000->dopo inversione diventa->11110111 (vanno letti da sinistra a destra) che in HEX corrisponde a->F7->Significato:Key byte1(LSB), vanno letti i primi 7 bit, così decodificati: Length supported, additional len supported, one byte header supported,Target/Source Header supported, Normal Timing parameter Set. Byte6->1110->dopo inversione diventa->11110001 che in HEX corrisponde a F1->Significato:Key Byte2(MSB)=Corretto, come previsto dal protocollo Byte7->111100->dopo inversione diventa->11000011->Poi i bit vanno invertiti per leggerli da destra a sinistra->11000011->che in HEX corrisponde a C3->Significato: Checksum - somma dei byte (corretto)
Edited by Acqua 28/11/2020 10:33 AM
| |
|
1.9 JTDM Owner
Blu oltremare
Posts: 1262
867,32 ore
Rosolini (SR)
| Acqua - 27/11/2020 7:42 PM arkymede74 - 18/11/2020 9:14 PM dove colleghi questa interfaccia? direttamente ad una serial port su pc o tramite adattatore USB? in quest'ultimo caso dovresti esser sicuro di usare un adattatore con un chip specifico, come suggerito nei primi post. l'adattatore usb-232 usa chip PL2303.
niki parla del FT232 della FTDI....
comunque, sinceramente non capisco tutto questo sbattersi per una cosa che esiste già....Hai tirato in ballo anche un bell'oscilloscopio!!!
Sarai uno smanettone..tanto di cappello, veramente  .. però, boh... a questo punto, fatto 30 fai pure 31.. ordina online gli optoisolatori e montali....
Edited by arkymede74 30/11/2020 6:53 PM
| |
|
Utente
Posts: 32
10,37 ore
Rome
| arkymede74 - 30/11/2020 6:52 PM
ordina online gli optoisolatori e montali....
Non serve. il circuito che ho realizzato è esattamente equivalente allo schema che ho trovato (di cui ho condiviso lo schema).
Ieri ho messo uno sniffer su seriale, che intercetta le chiamate al driver della Porta seriale. Ho visto che i messaggi dell'Alfa vengono ricevuti correttamente dal multiecuscan. L'unica anomalia é che vengono ricevuti anche gli stessi dati trasmessi dal multiecuscan. Questo potrebbe impedire al multiecuscan la corretta interpretazione dei messaggi ricevuti. Ho notato che il multiecuscan non muove mai il segnale RTS e DSR. Sicuramente il vecchio software agiva anche sul segnale RTS, permettendo di "cancellare" i messaggi trasmessi dal multiecuscan (cancellarli solo dal pin rx della porta seriale del PC). Il prossimo weekend provo a fare un circuito diverso che risolve il problema, usando gli stessi componenti.
Edited by Acqua 30/11/2020 10:17 PM
| |
|
Utente
Posts: 32
10,37 ore
Rome
| Aggiornamento: Ho scoperto che é normale che i dati tornino indietro sulla seriale, il multiecuscan sembra colloquiare con l'alfa, ma a un certo punto l'Alfa smette di comunicare. Di seguito riporto il colloquio acquisito con sniffer seriale (serial monitor, trovato su internet, gratuito per i primi giorni), poi successivamente decodificato secondo il protocollo (link al protocollo riportato qualche post sopra).
Con quadro Alfa acceso: Pressione tasto CONNECT su multiecuscan PC>ALFA StartCommunicationRequest: 81 10 f1 81 03 PC>ALFA StartCommunicationRequest: 81 10 f1 81 03 ALFA>PC StartCommunicationPositiveResponse: c3 f1 90 c1 ef cf c3 PC>ALFA AccessTimingParameterRequest: 82 10 f1 83 01 07 (set parameters to default values) ALFA>PC AccessTimingParameterPositiveResponse:c2 f1 90 c3 81 87 PC>ALFA AccessTimingParameterRequest: 82 10 f1 83 02 08 (read active timing parameters) ALFA>PC AccessTimingParameterPositiveResponse:c7 f1 90 c3 82 b2 82 ae 94 8a 8d (p2min=178 p2max=130 p3min=174 p3max=148 p4min=138) PC>ALFA ReadEcuIdentification Request: 82 10 f1 1a 97 34 PC>ALFA ReadEcuIdentification Request: 82 10 f1 1a 97 34 PC>ALFA ReadEcuIdentification Request: 82 10 f1 1a 91 2e PC>ALFA ReadEcuIdentification Request: 82 10 f1 1a 91 2e PC>ALFA ReadEcuIdentification Request: 82 10 f1 1a 92 2f Nessuna risposta dall'alfa. Il multiecuscan sembra ricominciare il colloquio in questo punto, ripetendo le seguenti interrogazioni: PC>ALFA StartCommunicationRequest: 81 10 f1 81 03 . PC>ALFA StartCommunicationRequest: 81 10 f1 81 03 Nessuna risposta dall'alfa, quindi multiecuscan chiude la porta seriale
Forse é un problema di timing, perché una volta ricevuti i parametri di timing (AccessTimingParameter Positive Response) i messaggi inviati dal pc non ricevono risposta dall'Alfa. | |
|
