Cos'è ElectroYou | Login Iscriviti

ElectroYou - la comunità dei professionisti del mondo elettrico

Open-source OBD-II diagnostic tool

Progettazione collaborativa: dall'idea alla formazione del gruppo di lavoro per la realizzazione di un prodotto finito.

Moderatore: Foto Utentebrabus

3
voti

[31] Re: Open-source OBD-II diagnostic tool

Messaggioda Foto Utentecarloc » 7 nov 2013, 17:45

Certo che il tuo schema è proprio molto simile (uguale?) a quello venduto da Sparkfun :? :? ... l'unica differenza mi pare la sostituzione di una coppia NMOS/PMOS con una coppia NPN/PNP :D ... cosa è una application note del 1110??

Comunque anche se evidentemente già commercializzato e funzionante io ci troverei alcune cosette da migliorare un pochino, riferendosi al tuo schema (le sigle dei componenti e le pagine sono diverse)

i) i driver L_LINE e K_LINE a pag 2 mi fanno venire i brividi lungo la schiena.... basta un corto anche breve verso l'alimentazione e ci fumiamo i BJT :(
Mi piacerebbe inserire un limite di corrente...

come nello schema di destra.

Se dimensioniamo con cura limite e BJT lo facciamo pure che resista ad un corto permanente verso VBAT.
Certo ci perdiamo forse 0,5V (ma forse anche meno) nella VOL ma credo che nessun protocollo con swing di circa 12V possa avere specifiche così strette (P.S. servono queste specifiche per consultarle :D )

ii) Nella stessa pagina 2 abbiamo il "ricevitore K_LINE" U2A, intanto vediamo che la soglia è fissata intorno a VBATT/2 (che fan ben sperare per la specifica sulla VOL che dicevo prima).

Poi però si nota che K_LINE può arrivare a VBATT, (forse anche a VBATT_RAW se cìè anche un pull-up esterno) mentre il range in modo comune del comparatore si ferma a Vcc-1,5V, considerato poi che Vcc del comparatore significa VBATT- (vedi alimentazioni a pag.5) direi che violiamo la specifica forse anche di un paio di volt :(

Ora si dirà che il circuito in kit funzionerà, è anche possibile che non accadano "cose strane" pur volando la specifica, ma a me non piace :( cercherei di risolvere magari cambiando comparatore e sostituendo la protezione serie (D4 di pag 5) con una parallelo.

Poi l'isteresi: ne introdurrei un po' per aumentare l'immunità al rumore.
Poi un po' di passa-basso sull'ingresso: a seconda delle specifiche del BUS trovo indispensabile "chiudere la banda in alto", anche se un po' in generale tutto la scheda mi sembra fatta dimenticando completamente problemi di compatibilità EM.
..ricordiamo a tutti i passeggeri presenti di spegnere i loro dispositivi mobili durante il decollo controllo del BUS...

:mrgreen: :mrgreen:

iii) Il driver CAN U3 a pag3, qui più che altro un dubbio, generalmente si mette una bias ad alta impedenza per dare uno stato definito al BUS nel caso restino aperte le sue linee, è compresa in U3?

iv) Poi abbiamo un errore di distrazione a pag 4 intorno a VBAT,C10,U4

v) e poi sempre lì la domanda è che LM317 mettiamo? Perché in base al tipo cambia la corrente di cortocircuito che deve essere poi sopportata da Q5 e D2, d'altra parte servono le specifiche anche di questo secondo BUS (il JS1850) per capire che cosa ci si aspetta da noi all'altro lato del cavo :D
Di sicuro un LM317 si fuma tranquillamente un 1n4148 e un 2N3906 :(

Insomma si deve scegliere il regolatore che fulfils le specifiche del BUS e poi mettere diodo e BJT adeguati.

vi) Poi il driver JS1850-, stessa pagina, anche qui protezione cortocircuito verso VBATT da inserire. Qui le tensioni sono un po' più basse (la soglia del ricevitore stessa pagina è 4V) e si deve considerare con più attenzione l'aumento di VOL introdotto :D

vii) Poi ancora i ricevitori U2B e U2C, qui non dovremmo avere problemi di modo comune ma comunque restano le issues per l'isteresi mancante, limitazione della banda e immunità EM come già detto prima.

viii) Per l'alimentatore di pag.5 direi che come minimo ci manca un fusibile (magari una PTC auto-ripristinante)....

Insomma, sono proprio spietato :evil: , progetto da buttare? Ma no :ok: :ok: :ok: , basically va bene, non è che ci sia molto da inventare, con IC così specifici si può solo seguire il datasheet, ma solo alcune rifiniture, limature qua e là che secondo me fanno la differenza :D
Se ti serve il valore di beta: hai sbagliato il progetto!
Avatar utente
Foto Utentecarloc
33,8k 6 11 13
G.Master EY
G.Master EY
 
Messaggi: 2153
Iscritto il: 7 set 2010, 19:23

0
voti

[32] Re: Open-source OBD-II diagnostic tool

Messaggioda Foto Utentetheking0 » 7 nov 2013, 20:48

carloc ha scritto:Certo che il tuo schema è proprio molto simile (uguale?) a quello venduto da Sparkfun :? :? ... l'unica differenza mi pare la sostituzione di una coppia NMOS/PMOS con una coppia NPN/PNP :D ... cosa è una application note del 1110??

Ho seguito le indicazioni dei datasheet.
Comunque anche se evidentemente già commercializzato e funzionante io ci troverei alcune cosette da migliorare un pochino, riferendosi al tuo schema (le sigle dei componenti e le pagine sono diverse)

i) i driver L_LINE e K_LINE a pag 2 mi fanno venire i brividi lungo la schiena.... basta un corto anche breve verso l'alimentazione e ci fumiamo i BJT :(
Mi piacerebbe inserire un limite di corrente...

come nello schema di destra.

Se dimensioniamo con cura limite e BJT lo facciamo pure che resista ad un corto permanente verso VBAT.
Certo ci perdiamo forse 0,5 V (ma forse anche meno) nella VOL ma credo che nessun protocollo con swing di circa 12 V possa avere specifiche così strette (P.S. servono queste specifiche per consultarle :D )

ii) Nella stessa pagina 2 abbiamo il "ricevitore K_LINE" U2A, intanto vediamo che la soglia è fissata intorno a VBATT/2 (che fan ben sperare per la specifica sulla VOL che dicevo prima).

Poi però si nota che K_LINE può arrivare a VBATT, (forse anche a VBATT_RAW se cìè anche un pull-up esterno) mentre il range in modo comune del comparatore si ferma a Vcc-1,5 V, considerato poi che Vcc del comparatore significa VBATT- (vedi alimentazioni a pag.5) direi che violiamo la specifica forse anche di un paio di volt :(

Ora si dirà che il circuito in kit funzionerà, è anche possibile che non accadano "cose strane" pur volando la specifica, ma a me non piace :( cercherei di risolvere magari cambiando comparatore e sostituendo la protezione serie (D4 di pag 5) con una parallelo.

Poi l'isteresi: ne introdurrei un po' per aumentare l'immunità al rumore.
Poi un po' di passa-basso sull'ingresso: a seconda delle specifiche del BUS trovo indispensabile "chiudere la banda in alto", anche se un po' in generale tutto la scheda mi sembra fatta dimenticando completamente problemi di compatibilità EM.
..ricordiamo a tutti i passeggeri presenti di spegnere i loro dispositivi mobili durante il decollo controllo del BUS...

:mrgreen: :mrgreen:

iii) Il driver CAN U3 a pag3, qui più che altro un dubbio, generalmente si mette una bias ad alta impedenza per dare uno stato definito al BUS nel caso restino aperte le sue linee, è compresa in U3?

iv) Poi abbiamo un errore di distrazione a pag 4 intorno a VBAT,C10,U4

Ah.. questo mi era proprio sfuggito :oops:

v) e poi sempre lì la domanda è che LM317 mettiamo? Perché in base al tipo cambia la corrente di cortocircuito che deve essere poi sopportata da Q5 e D2, d'altra parte servono le specifiche anche di questo secondo BUS (il JS1850) per capire che cosa ci si aspetta da noi all'altro lato del cavo :D
Di sicuro un LM317 si fuma tranquillamente un 1n4148 e un 2N3906 :(

sul datasheet usano un LM317LD.
Insomma si deve scegliere il regolatore che fulfils le specifiche del BUS e poi mettere diodo e BJT adeguati.

vi) Poi il driver JS1850-, stessa pagina, anche qui protezione cortocircuito verso VBATT da inserire. Qui le tensioni sono un po' più basse (la soglia del ricevitore stessa pagina è 4V) e si deve considerare con più attenzione l'aumento di VOL introdotto :D

vii) Poi ancora i ricevitori U2B e U2C, qui non dovremmo avere problemi di modo comune ma comunque restano le issues per l'isteresi mancante, limitazione della banda e immunità EM come già detto prima.

viii) Per l'alimentatore di pag.5 direi che come minimo ci manca un fusibile (magari una PTC auto-ripristinante)....

Insomma, sono proprio spietato :evil: , progetto da buttare? Ma no :ok: :ok: :ok: , basically va bene, non è che ci sia molto da inventare, con IC così specifici si può solo seguire il datasheet, ma solo alcune rifiniture, limature qua e là che secondo me fanno la differenza :D


Wow .. già sono saltate fuori diverse migliorie. :mrgreen:
Io purtroppo non sono un progettista elettronico. ma solo un appassionato autodidatta quindi tante cose mi sfuggono proprio. :roll:
Mi piacerebbe se analizzassimo una a una quelle modifiche che hai proposto, così che possa comprenderle e modificare gli schemi di conseguenza.
Il progetto sta prendendo una bella piega, penso che possiamo arrivare a un progetto finito veramente serio.
Avatar utente
Foto Utentetheking0
1.442 1 6 11
Master
Master
 
Messaggi: 605
Iscritto il: 11 feb 2012, 22:37

4
voti

[33] Re: Open-source OBD-II diagnostic tool

Messaggioda Foto Utentecarloc » 7 nov 2013, 21:59

Ok :D , se sopporti i "miei tempi" :roll: una mano te la do volentieri, insieme a chiunque vorrà naturalmente :D ....

per iniziare direi che sarebbe interessante vedere qualche documento sui protocolli utilizzati, sopratutto da un punto di vista hardware, tensioni minime e massime a livello alto e basso, correnti, tempi.... li hai da linkare o hai idea di dove cercarli?
Se ti serve il valore di beta: hai sbagliato il progetto!
Avatar utente
Foto Utentecarloc
33,8k 6 11 13
G.Master EY
G.Master EY
 
Messaggi: 2153
Iscritto il: 7 set 2010, 19:23

1
voti

[34] Re: Open-source OBD-II diagnostic tool

Messaggioda Foto Utentetheking0 » 7 nov 2013, 22:05

carloc ha scritto:Ok :D , se sopporti i "miei tempi" :roll: una mano te la do volentieri, insieme a chiunque vorrà naturalmente :D ....

Grande ! Grazie !!! >-O-<
per iniziare direi che sarebbe interessante vedere qualche documento sui protocolli utilizzati, sopratutto da un punto di vista hardware, tensioni minime e massime a livello alto e basso, correnti, tempi.... li hai da linkare o hai idea di dove cercarli?

Cerco di trovare tutta do documentazione necessaria, faccio qualche ricerca e posto quello che trovo :ok:
Avatar utente
Foto Utentetheking0
1.442 1 6 11
Master
Master
 
Messaggi: 605
Iscritto il: 11 feb 2012, 22:37


0
voti

[36] Re: Open-source OBD-II diagnostic tool

Messaggioda Foto Utentetheking0 » 11 nov 2013, 18:20

Non sono sparito eh ... ho dovuto formattare il PC e sto reinstallando tutti i programmi (compreso kicad), a giorni mi rimetto sotto con lo schema, inizio a sviluppare le modifiche suggerite da Foto Utentecarloc. :ok:
Avatar utente
Foto Utentetheking0
1.442 1 6 11
Master
Master
 
Messaggi: 605
Iscritto il: 11 feb 2012, 22:37

1
voti

[37] Re: Open-source OBD-II diagnostic tool

Messaggioda Foto Utentecarloc » 11 nov 2013, 18:25

ok :D ...io stavo pensando ai tre driver open collector, K,L e JS1850-.... che ne dici di mettere tre NMOS in SOIC8 ? (non ho la sigla che avevo adocchiato su questo PC :( , ma tipo IRLqualcosa) :D Costano circa 0,30€ ciascuno e credo che con un po' di rame intorno riescano a reggere bene anche un corto verso +BATT.....

che ne pensi?
Se ti serve il valore di beta: hai sbagliato il progetto!
Avatar utente
Foto Utentecarloc
33,8k 6 11 13
G.Master EY
G.Master EY
 
Messaggi: 2153
Iscritto il: 7 set 2010, 19:23

0
voti

[38] Re: Open-source OBD-II diagnostic tool

Messaggioda Foto Utentetheking0 » 11 nov 2013, 19:12

carloc ha scritto:ok :D ...io stavo pensando ai tre driver open collector, K,L e JS1850-.... che ne dici di mettere tre NMOS in SOIC8 ? (non ho la sigla che avevo adocchiato su questo PC :( , ma tipo IRLqualcosa) :D Costano circa 0,30€ ciascuno e credo che con un po' di rame intorno riescano a reggere bene anche un corto verso +BATT.....

che ne pensi?


Certo, si può fare se dici che sia la soluzione migliore. :ok:
Avatar utente
Foto Utentetheking0
1.442 1 6 11
Master
Master
 
Messaggi: 605
Iscritto il: 11 feb 2012, 22:37

0
voti

[39] Re: Open-source OBD-II diagnostic tool

Messaggioda Foto Utentetheking0 » 23 nov 2013, 21:58

carloc ha scritto:ok :D ...io stavo pensando ai tre driver open collector, K,L e JS1850-.... che ne dici di mettere tre NMOS in SOIC8 ? (non ho la sigla che avevo adocchiato su questo PC :( , ma tipo IRLqualcosa) :D Costano circa 0,30€ ciascuno e credo che con un po' di rame intorno riescano a reggere bene anche un corto verso +BATT.....

che ne pensi?


Ciao, sto iniziando a riprendere in mano gli schemi sul nuovo sistema :mrgreen:
Foto Utentecarloc quando hai 2 min potresti dirmi le sigle esatte di quei NMOS che avevi proposto, che devo controllare se ci sono già per kicad (altrimenti le creo io .. no problem).
Avatar utente
Foto Utentetheking0
1.442 1 6 11
Master
Master
 
Messaggi: 605
Iscritto il: 11 feb 2012, 22:37

4
voti

[40] Re: Open-source OBD-II diagnostic tool

Messaggioda Foto Utentecarloc » 24 nov 2013, 23:09

Beh, prima cosa mi devo scusare :oops: ... va bene "i miei tempi..." ma così è proprio troppo :( :(

Comunque qualcosina ho fatto :-) , sfogliando i tuoi link avrei riassunto quello che riguarda il bus JS1850
J1850.jpg
J1850.jpg (320.81 KiB) Osservato 13382 volte


poi questo riassume lo stato attuale dei circuiti di alimentazione e pilotaggio di quel bus


su cui farei le seguenti considerazioni :D

i) Alimentazione bus
Non ho ben capito la necessità di due diverse tensioni di alimentazione, ma senza dubbio dipende dal fatto che ho solo velocemente scorso la descrizione dello standard :( ; comunque non mi pare sia la descrizione ufficiale e completa e da cui tra l'altro parrebbe sufficiente (vedi Voh) una tensione intorno ai 7...7,5V.
Comunque direi di fidarsi della necessità di due alimentazioni, e per quanto riguarda il loro valore nominale al più si tratta di cambiare una resistenza :D
Piuttosto la corrente:
considerando anche di portare l'uscita intorno a 8V in condizioni statiche il bus non richiede più di circa 8V/300Ω≈27mA.
Dinamicamente invece ci troviamo, ancora in worst case a caricare CL=17nF fino alla tensione Voh=8V per la metà del Baudrate=41,6kb/s volte al secondo, cioè circa 17nF x 8V x 21 kHz ≈ 3mA.

In sostanza con circa 30mA ci stiamo, quindi andrei per un bel LM317L che è totalmente autoprotetto per cortocircuito e temperatura.
Necessità di circa 3V di differenza in/out per lavorare correttamente quindi, ancora worst case arriviamo a lavorare fino a circa 8V+3V=11V di tensione +BATT.
Beh qui se si facesse sul serio (funzionamento garantito fino a una batteria di 9V :D ), e considerato anche un eventuale diodo serie su +VBATT andrei per un equivalente low-dropout, ma vedi un po' tu :ok:

Per quello che riguarda la dissipazione durante il funzionamento "normale" penserei alla batteria a 15V e l'uscita al minimo (5V) e quindi stimerei 30mA x (15V -5V)≈300mW che con i 165°C/W di resistenza termica giunzione ambiente riportati nel ds per il SOIC8 (ma montato come poi :? ...mah) darebbero al più una cinquantina di celsius tra giunzione ed ambiente.
Considerato poi che credo poco probabile che il bus stia a livello basso per lungo tempo (vista la topologia wired-and si presume lo stato idle alto) direi che ci potremmo stare.

ii) bypass uscita
Visto che mi pare di capire che la variazione di questa tensione è una "configurazione" dell'interfaccia, cioè non deve essere fatta "troppo spesso e velocemente" per trasmettere dati, visto questo dicevo metterei un bypass. Il datasheet riporta possibile tendenza all'instabilità per carichi capacitivi da 500pF a 5000pF che potrebbe proprio essere quello che ci capita con questa interfaccia e allora ci metterei un elettrolitico 22uF o un tantalio da 1uF come consigliato.
Piuttosto se opti per un lowdrop: questi sono più critici in questo aspetto, segui alla lettera i consigli sul carico capacitivo in uscita che troverai nel ds.

iii) switch
LM317 potrebbe fornire in corto un massimo di 300mA (magari non per molto tempo che poi va in thermal shutdown) comunque io mi assicurerei che questo switch possa sopportare questa corrente per un tempo indefinito. Due opzioni, il PNP come hai disegnato ma verificherei che rimanga saturo con quella corrente di cortocircuito, oppure un PMOS come nello schema Sparkfun. A me piace di più questa seconda soluzione che mi pare più elegante e spreca meno potenza per il pilotaggio.

iv) pulldown
Sì, un pulldown mi sembra necessario per "tirare giù la linea" ma non sono riuscito a trovare un perché a quel diodo D3, lo toglierei.

v) pullup
ok per il pullup della linea, ma mi parrebbe più logico farlo verso la tensione di alimentazione del bus 5V/7,5V. Anche in questo caso l'utilità del diodo mi pare dubbia/marginale

vi) il driver
qui metterei il "famoso" MOS IRL6342 con limitazione di corrente, non ti far "spaventare" dalla specifica di IDmax=9,9A, è solo un piccolo MOS in SOIC8, quello che interessa è che abbia una resistenza termica tale da sopportare un corto verso VBATT senza fumare :D (e possibilmente che sia ok anche per i driver K-LINE e L-LINE da vedere dopo).
....dimensionamento alla prossima puntata :D

Riassumendo:

qualcosa del genere :ok:

Critiche e suggerimenti welcome :D
Se ti serve il valore di beta: hai sbagliato il progetto!
Avatar utente
Foto Utentecarloc
33,8k 6 11 13
G.Master EY
G.Master EY
 
Messaggi: 2153
Iscritto il: 7 set 2010, 19:23

PrecedenteProssimo

Torna a Crowd Design

Chi c’è in linea

Visitano il forum: Nessuno e 2 ospiti