Funderar på att bygga om bil-el på 87'a

[cetex]

Beställt lite prylar!
ATMega328 DIP28
mcp2515 DIP18 - Can Controller med SPI Interface (hanterar can-logiken, behöver även en MCP2551)
mcp2551 DIP8 - Can Transceiver (hanterar can-interfacet / differentiell kommunikation)
mcp25050 DIP14 - Can Bus I/O Extender med 8I/O (varav 4 dubblar som A/D), 2PWM (fristående I/O Extender, behöver kombineras med MCP2551)

Ska sätta upp det på breadboard innan jag fortsätter med ritandet.

[Swech]

Skall vara lite "tråkig" men... bil el är inte det lättaste att få till då det
finns riktigt otrevliga störningar och skit på 12V ledaren.

Startmotorn är otrevlig.
Lossar matningen på batteriet så sparkar den ut otäckt höga spänningar. din 30v diod går åt h...

Det finns något som kallas loaddump bl.a. som beskriver vad elektroniken skall klara störningsmässigt.

Du bör sätta en tranzil (minst 1500W) över + och - som släcker de värsta pulserna.

Säkringen kan du ersätta med PTC så behöver du inte fram med lödkolven om den går

0402 betyder 40 x 20 hundradels tum (mil)


Swech

[cetex]

Tack för info!
Har läst lite om load dump nu.

Hittade bl.a en sida från en snubbe som tänkt lite längre utan att göra det alltför komplext.
smart dc generator


Det behövs väl inga större förändringar egentligen?
Glassäkringen hamnar i säkringslådan, stoppar in en ptc på kortet istället. Om ptc'n ens behövs? (Skulle vara om den sitter före tvs'en, men då brinner den väl upp om jag med min 100A generator rycker batteriet eller motsvarande (winchar..))
En tvs (transient voltage suppressor) på typ 24v före ptc'n tar det jävligaste. I värsta fall brinner säkringen i säkringslådan, men den är det ju bara att byta.

D.v.s:
Batt - glassäkring - tvs - ptc - schottky ...

[blueint]

1BV Zener tillsammans med SCR:en fungerar som crowbar? och SB550 dioden som skydd mot fel polaritet?

Blir intressant att se om detta håller för bil-el

[cetex]

Det är ju en del folk som kör arduino i sina bilar, och det bör ju inte vara spec svårt egentligen.. (t.ex denna Jeep wrangler.)
Jag hittar inte någon info om hur dom löst matningen, men jag gissar att dom gjort det rätt enkelt. ingen garanti för att det håller dock..

Det senaste alternativet jag hittat är LM2940T-5.0, Datasheet som är speccad "for automotive environments". Billig, enkel, har skydd mot load-dump och stänger ner vid transienter utanför dess specifierade område. Så dom menar att den kan kopplas direkt mot batt+, bör jag stoppa in en PTC på 1A följt av en TSR för att lösa ut PTC'n vid kraftiga transienter?, och nån större konding efteråt för att hålla spänningen uppe de gånger regulatorn stänger ner.

Lite andra exempel..
Xarias verkar inte vara spec genomtänkt på psu'n, dom kör en 7805 utan några transientskydd o dyl, om dom nu inte gömt det någon annanstans.
schema för xarias

Load-dump skyddad regulator, en mosfet dödar matningen när spänningen stiger. Skulle ni rekommendera något sånthär istället för LM2940?, får sätta någon fetare konding efter regulatorn som levererar när fet'en klipper under några ms.
Automotive switching regulators get input transient voltage protection - Schematic

[Pajn]

Det finns vissa saker man inte bör göra själv på bilar.
Jag har inte riktigt förstått vad du vill göra så jag tar upp sånt
som hade kunnat varit med om jag gjort ett liknande projekt.

Styrning till bromsar - Om du får en bugg eller vad som helst
så att bromsen nyper på motorvägen när du har bil bakom dig
med Audi-avstånd mellan bilen och dig så är din nacke körd.

Bromsljus, detta bör dras direkt utan buss - Detta är lite samma
anledning som ovan.

Gas - Som ovan fast omvänt, en "hängd" gas är mycket farligt.
Även om man i lugnt tillstånd har vett att trycka ner kopplingen
och stänga av motorn är det mycket få som har det i paniksituationen
som urartar innan du ens har förstått vad som hänt.

Och även om jag inte tror det så bra att nämna:
Airbag - Sprängladdningen är mycket kraftig och kan vid utlösning i
fel situation vara dödande. Ett barn i en bakåtvänd barnstol är nästan
garanterad en snabb död vid utläsning av airbag.

Sen är det bara att mecka
Som sagt är bilens "12V" lina sällan 12V, dimensionera minst för 30V.
Sen bör man ju som alltid väga skyddet mot det man vill skydda.
Är det man vill skydda inte så mycket värt och lätt kan bytas ut
(tex. en arduino) så kan det vara onödigt att lägga ut en massa pengar
och tid på att se till att inget händer den.

[cetex]

Anledningen till att jag gör detta är att jag är osäker på statusen på bilens el just nu.
Bilen har blivit ombyggd i etapper sedan den var ny (1987) och en del saker i det elektriska är mer genomtänkta än andra. En hel del eldragning är inte original och jag vill riva mycket av den för att sedan göra om det med vettiga kabeldimensioner, göra det snyggt och enklare att felsöka enskilda delar (buss-system tillför ju dock komplikationer, men det är jag beredd att ta)
Det slog mig att det vore väldigt schysst om man kunde skippa kabelstammen till motorutrymmet och ha alla relän där ute nära förbrukare och strömkälla, istället för inne i kupen. Mindre kablar, lite mer elektronik, men större möjligheter att jacka in mer utrustning utan att det ser ut som en cockpit i ett gammalt militärplan..
Och det är ju ett ypperligt tillfälle att fundera över hur man skulle lösa det med lite modernare teknik samt lära sig nåt på kuppen.

Allt kritiskt förutom lyset och matning till tändspole / bränslepump är mekaniskt på bilen så det är ju inte ett enormt projekt som riskerar säkerheten på något sätt annat än om jag utökar bussen till baken av bilen och kopplar in bromslyse på den och systemet fallerar, men det är inte aktuellt i första taget. D.v.s, inga airbags, inget elektriskt styr/bromssystem o.s.v.
Om jag gör detta handlar det alltså om:
Start
Tändning
Bränslepump
Lyse
Så småningom luftfjädringen (höjdreglering, sänka från kupen så man kommer in i vanliga garage vore nice)
Larm (med gsm-modul kanske?)
Monitorering
temp
avgasvärden (oklart hur, men kanske)
strömförbrukning av lampor m.m (detektering om defekt)
... Mer kul saker kommer nog allt eftersom.

Startmotorn är en sån sak jag ogärna överlåter till detta helt, så den ska ha dubbelkommando (nyckel i startläge + mcu måste vara överens för att kunna ge ström till solenoiden)

Den behöver dessutom nån form av stöldskydd, och det är ju kul att bygga in sitt egna system i bilen.

Edit, förtydligande..

[blueint]

Koppla en GPS till GSM sändaren så gör tjuvarna sig inte besvär..

[gkar]

Varför ha en kofotskoppling?
En kofotskppling hör hemma som skydd i en nätdel så att den garanterat inte skickar ut för hög spänning.
En produkt med kofotskoppling som överspänningsskydd skulle aldrig kunna sitta i en bil från fabrik.
Man har allttid som krav att en elektronikmodul/produkt skall återställa sig/återstarta sig själv efter en transient.

Gör istället så här:
Lägg en schottkydiod i serie för felpolarisation.
Lägg en serieregulator, LDO, diskret uppbyggd med en P-kanal FET som begränsar till någon bra spänning. Detta gör även att du inte behöver tåla full överspänning och långsamma transienter i efterföljande komponenter.

Ett annat sätt är att bryta matningen med en FET när det kommer överspänning. Sedan återgår man till det normala när den försvinner.

Lägg ett pifilter för att ta bort störningar och snabba transienter.

Läs bla i ISO 7637, ISO 16750 och ISO 10605 vilka tester och krav man normalt brukar ställa, och behöver uppfylla för elektronik skall fungera stabilt i en bil.

[cetex]

Hoj!

Tack för input!
Jag har inte dött, PSU ligger på is en liten stund tills jag får behov av en och vet mer om vad den behöver hantera för last.

Under tiden har jag satt upp ett 2nods CANbus-nät, utökat libraries till arduino och jag jobbar på addresseringen just nu.
En första skiss på addressplanen:

Kod: Markera allt

Standard CAN V2.0A
11bits id    | RTR | R1 | R0 | DLC  | Data (0-8B)
000 00000000 |  0  | 1  | 1  | 0000 | 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

Extended CAN V2.0B
The reserved R1 is moved further down, IDE is set in it's place to lets the host know that it's a V2.0B Frame.
SRR is 0 to ensure that if there's a V2.0A frame with RTR set sent the Data frame will get priority.
11bits id    | SRR | IDE | 18bits identifier    | RTR  | R1 | R0 | DLC  | Data (0-8B)
000 00000000 |  0  | 1   | 00 00000000 00000000 | 0    | 0  | 0  | 0000 | 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

My Standard..
Pri | 8bits sID | SRR | IDE | 10 bits function   | 8 bits dID | RTR | R1 | R0 | DLC  | Data (0-8B)
000 | 00000000  |  0  | 1   | 00 00000000        | 00000000   | 0   | 0  | 0  | 0000 | 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

ID is 8bits, the master is given a low ID to get priority if multiple nodes tries to send with the same priority at once.
ID is programmed by an 8-bit dip switch, or written to flash.
sID is Source ID.
dID is destination ID.
Pri is Priority, 0-7 where 0 is the highest.
function is the function i wan't to call.

Bit 0 is the rightmost one, Bit 7 is the leftmost bit.
Bit 0:
ID 0 is used for bus clock (if clock missing for more than 100ms all nodes should enter failsafe mode / safe shutdown and wait for master to resume clock)
ID 1 is reserved.
Bit 2-0:
ID 2-7 is reserved for master node(s)
Bit 3-0:
ID 8-15 Critical Priority nodes (Brakes.. won't be implemented ... yet..)
Bit 4-0:
ID 16-31 Very High Priority nodes (Reserved bits...)
Bit 5-0:
ID 32-63 High Priority nodes (Lights, Ignition..)
Bit 6-0:
ID 64-128 Low Priority nodes (Starter, Air Suspension, Winch activation)
Bit 7-0:
ID 128-255 Measurement nodes (Temperature, Voltage, ride height)

00000000 Clock
00000001 Reserved
00000010 Master1
00000011 Master2
00000100 Master3
00000101 Master4
00000110 Master5
00000111 Master6
00001000 Crit Pri 1
00001001 Crit Pri 2
00001010 Crit Pri 3
00001011 Crit Pri 4
00001100 Crit Pri 5
00001101 Crit Pri 6
00001110 Crit Pri 7
00001111 Crit Pri 8
00010000 Very High Pri 1
00010001 Very High Pri 2
00010010 Very High Pri 3
00010011 Very High Pri 4
00010100 Very High Pri 5
00010101 Very High Pri 6
00010110 Very High Pri 7
00010111 Very High Pri 8
00011000 Very High Pri 9
00011001 Very High Pri 10
00011010 Very High Pri 11
00011011 Very High Pri 12
00011100 Very High Pri 13
00011101 Very High Pri 14
00011110 Very High Pri 15
00011111 Very High Pri 16
00100000 Medium Pri 1
....
00111111 Medium Pri 32
01000000 Low Pri 1
....
01111111 Low Pri 64
10000000 Measurement/Others 1
....
11111111 Measurement/Others 128

Jag klurar på hur jag ska fördela 10 Bits Function nu, och vad jag egentligen vill uppnå med de bitarna. Jag har ju möjlighet att sätta flera funktioner på samma nod (lyse, start och tändning är ett exempel, Bromsljus, blinkers och luftfjädring är ett annat..), i det fallet skulle dom ju dela ID.
Idéer?

[Pajn]

Det låter ju som om du ska ha ett ID per fysisk nod (varje "låda"),
samt en "funktion" för just varje funktion. D.V.S. bakljus, fjädrar, m.m.
Varje nod kan ha flera funktioner och alltså då ha flera "funktions idn"

Prioritet har du ju rikligt av innan så det bör väl bara vara att plocka
ett nummer för varje funktion du implementerar.

Tycker det verkar vettigt.

[cetex]

Ok!
Jag ändrar lite. (F*n vad lätt det är att fastna i idiotiska tankegångar ibland..)

Tips på hur jag ska hantera definitionen av vad en position är?
Utgångar kommer ju skilja beroende på vart en device sitter, och jag vill ju ha samma device-typ överallt så jag kan ha en standard-spare liggandes. (i alla fall för kritiska noder med funktionerna för start, tändning, bränslepump, lampor.. I och försig oklart om det ens blir fler än 3-4 noder totalt)

Ska jag hårdkoda ett ID till en viss funktionsuppsättning? - Det blir ju rätt oflexibelt, men lätt att byta ut. (sätt rätt adress för devicens position så definieras funktionerna korrekt)
t.ex:
ID "3" kan definiera att utgång 1 styr halvljus, 2 styr helljus, 3 styr startmotor..
ID "4" kan definiera att utgång 1 styr bromsljus, 2 styr luftfjädring upp, 3 styr luftfjädring ner..

Edit:

Kod: Markera allt

Pri | 8bits sID | SRR | IDE | 10 bits function   | 8 bits dID | RTR | R1 | R0 | DLC  | Data (0-8B)
000 | 00000000  |  0  | 1   | 00 00000000        | 00000000   | 0   | 0  | 0  | 0000 | 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

• sID blir ett ID som assignas av en DIP Switch på kretskortet.
• Det konfigurerade ID't på modulen definierar vilken funktion modulen har på vilken port.
• Alla moduler har samtliga funktioner definierade, och vilka som är aktiva bestäms av sID't.
• dID är 0x00 om man bara ska göra en allmän request (t.ex slå på halvljus, spelar ingen roll om en eller 10 noder gör det samtidigt, så länge dom har den funktionen definierad korrekt)

• En funktions-address har en bestämd data-typ och längd.
• Första data-blocket definierar vad som ska göras med funktionen. t.ex 1 för på, 0 för av. Andra värden kan definiera t.ex pulsbredd, intervall m.m.
• Är det en RTR (Remote Transmit Request) - Förfrågan om data (t.ex läsa en sensor) skickas svaret i data-blocket enligt funktionens definition.

• För mer specifika requests som att slå på höger halvljus-strålkastare defineras dID till den devicens ID.
• Om den specifierade devicen inte har den funktionen definierad skickar den ett error tillbaka (samma funktions-address men data-block 0 satt till t.ex 0 eller 255?) Vilket bör lyfta ett error på mastern (eller loggas, eller visas på LCD'n, eller nåt..)