Håller på att titta på ett isolerat RS485 gränssnitt.
Är det någon som är insatt i ämnet?
Har hittat 3 kretsar som fixar det.
MAX 1480 från Maxim 250/2500 kbps, 1000V.
LTC1535 från Linear Tech 250 kbps 2500V.
ADM2483 från Analog Devices 500 kbps 2500V.
Alla verkar använda olika tekniker för att uppnå isolation.
MAXen använder optokopplare.
LTCn använder kopplingskondingar.
ADMen använder intergrerad "järnfri trafo".
Det är uppenbart att det är för och nackdelar mellan de olika teknikerna.
Naturligtvis skiljer ju priset en del också
MAXen ca $10:-/1k
LTCn runt $5:-/1k
ADMen ca $3:-/1k
Både LTCn och ADMen kräver en separat isolerad nätdel, MAXen verkar ha den inbyggd.
LTCn har inbyggd switchregulator men kräver extern trafo, diod och konding.
ADMen har inget inbyggt.
Länkar
MAX1480
LTC1535
ADM2483
Ideer och förslag? Mottages taksamt.
Isolerad RS485 frågor
Hej Tomas!
Vi använder en del isolerad 485 men det är en tämligen diskret variant så det hjälper kanske inte dig. Tre optokopplare för RX, TX och strobe och sedan en switchad nätdel på korten med en isolerad matning för 485-delen. Vad gäller jämförelsen mellan dom du nämner så har jag inte erfarenhet nog av dom för att bedöma.
Vi använder en del isolerad 485 men det är en tämligen diskret variant så det hjälper kanske inte dig. Tre optokopplare för RX, TX och strobe och sedan en switchad nätdel på korten med en isolerad matning för 485-delen. Vad gäller jämförelsen mellan dom du nämner så har jag inte erfarenhet nog av dom för att bedöma.
Jag byggde ett isolerat DMX-interface (RS485, 250 kbit/s) för ett tag sen.
För att få ner storleken blev det en IL485WE kombinerat med en TME0505S som isolerad strömförsörjning. Båda finns på Elfa och kostar ungefär 175 kr + moms tillsammans.
Det är kanske lite dyrt, men det var enkelt att bygga och ganska smått. Grunkan är bara testad med korta ledningar än, så jag kan inte säga hur det fungerar med 100m kabel.
Som överspänningsskydd används 29 ohms PTC-motstånd (elfa 60-265-95) i serie med dataledningarna och innanför dem, 1N5341B (5W-zener, 6.2V) till isolerad GND. Anoderna till jord förstås. Det är inte min konstruktion, utan den kommer från några DMX-scheman i pdf-format längst ner på den här sidan: http://www.avolites.org.uk/support/ecns/ecn-0152.htm
För att få ner storleken blev det en IL485WE kombinerat med en TME0505S som isolerad strömförsörjning. Båda finns på Elfa och kostar ungefär 175 kr + moms tillsammans.
Det är kanske lite dyrt, men det var enkelt att bygga och ganska smått. Grunkan är bara testad med korta ledningar än, så jag kan inte säga hur det fungerar med 100m kabel.
Som överspänningsskydd används 29 ohms PTC-motstånd (elfa 60-265-95) i serie med dataledningarna och innanför dem, 1N5341B (5W-zener, 6.2V) till isolerad GND. Anoderna till jord förstås. Det är inte min konstruktion, utan den kommer från några DMX-scheman i pdf-format längst ner på den här sidan: http://www.avolites.org.uk/support/ecns/ecn-0152.htm
-
limpan4all
- Inlägg: 8444
- Blev medlem: 15 april 2006, 18:57:29
- Ort: Typ Nyköping
Är ditt dataprotokoll lämpligt utformat med '1010101' några byte synsekvens innan viktig data och slänga bort allt skräp som inte käns igen etc. så hade det räckt med en ethernet-trafo i en modularjack för att lösa isolationsproblemet - dessutom dubbelriktat och duplexdrift - och tom. kanske flera steg trafo efter varandra för högre spänningstålighet på vägen till målobjektet... - vissa tänkte på detta redan i tidig 80-tal (tex skaparna av ethernet) medan dom flesta även år 2008 upprepar fortfarande misstagen från 1890-talet (telegrafi) när man skapar sina kommunikations och dataprotokoll med att envisas avända giltiga DC-state för att signalera/aktivera respons från målobjekten...
Att transportera DC-nivå som indikerar state/information är jäkligt jobbigt om man skall ha isolerade länkar - och då är det i prinsip bara optokopplare kvar med dyra isolerad strömfösörjningskrav på var sida om barriären. I fallen med dubbelriktad trafik på samma par måste man dela upp från duplexdrift (prata i båda riktningarna samtidigt på samma gång) med hybrider - föra över barriären (optokopplare/HF-trafo) i respektive riktning och på andra sidan slå ihop dessa igen med hybridkoppling med frekvensomfång från just DC och man får höghastighetsprestandaproblem istället (långsamma optokopplare) - skall man spara pengar på extern utrustning för isolerad ihopkoppling så skall man börja titta på sin kommunikationsprotokoll _NU_ för ren växelströmsöverföring via trafo - samt all information och dess sidband håller sig över 200 kHz om man också inte skall slåss med kabelns komplexa impedans som skapar amplitud och envelopdistorsion, innan protokollet byggs fast överallt i olika produkter...
Ni som sitter och fila på egna dataprotokoll till era byggen via RS485 etc. - tänk rätt nu redan från början - och provkör alltid via ett par ethernetrafo i serie (för isolering i båda ändarna) och en bit CAT-5 kabel (även från RS485-drivsteg med 100 Ohm terminering) och justera era kommunikationsalgoritmer där tills det fungerar övertygande så slipper ni ett helvetes massa problem den dagen när målutrustningen kopplas mot annan skyddgjordreferens och längre kabelsträckor [1] samt ESD och överspänningståligheten kommer i en helt annan klass... ethernettrafo eller själv linda dito på en toroid är mycket billigare lösning än någon annan bufferlösning med isolation i sig!, och har man gjort protokollet rätt så behövs dessa inte slängas in förrän när det behövs om man jagar dom få kronor för dessa i kostnad.
Hårdvara kan inte kompensera utan stora extra kostnader för en dålig vald mjukvarukommunikationsalgoritm - och för att välja en bra sådan så bör man känna till lite fysik, lite signal och informationsteori och transmissionslinjeteori, samt kännedom om redan gjorda allvarliga designmissar när det gäller informationöverföring på media, om man inte stjäl rakt av en redan utprovad koncept...
[1]
Långa kabelsträckor bör också provas ut då tajta tidsfönster i protkollet kan balla ur fullständigt när man får in kabelfördröjningen... - det är bl.a en sådan som begränsar USB:ns räckvidd till under 10 meter och måste ha aktiva 'repetrar' för längre länkar... - ytterliggare exempel på idiotisk design där konstruktörerna inte vet om att kablar har fördröjningar... - eller avsiktligt för att just sälja 'repetrar/hub'...
Att transportera DC-nivå som indikerar state/information är jäkligt jobbigt om man skall ha isolerade länkar - och då är det i prinsip bara optokopplare kvar med dyra isolerad strömfösörjningskrav på var sida om barriären. I fallen med dubbelriktad trafik på samma par måste man dela upp från duplexdrift (prata i båda riktningarna samtidigt på samma gång) med hybrider - föra över barriären (optokopplare/HF-trafo) i respektive riktning och på andra sidan slå ihop dessa igen med hybridkoppling med frekvensomfång från just DC och man får höghastighetsprestandaproblem istället (långsamma optokopplare) - skall man spara pengar på extern utrustning för isolerad ihopkoppling så skall man börja titta på sin kommunikationsprotokoll _NU_ för ren växelströmsöverföring via trafo - samt all information och dess sidband håller sig över 200 kHz om man också inte skall slåss med kabelns komplexa impedans som skapar amplitud och envelopdistorsion, innan protokollet byggs fast överallt i olika produkter...
Ni som sitter och fila på egna dataprotokoll till era byggen via RS485 etc. - tänk rätt nu redan från början - och provkör alltid via ett par ethernetrafo i serie (för isolering i båda ändarna) och en bit CAT-5 kabel (även från RS485-drivsteg med 100 Ohm terminering) och justera era kommunikationsalgoritmer där tills det fungerar övertygande så slipper ni ett helvetes massa problem den dagen när målutrustningen kopplas mot annan skyddgjordreferens och längre kabelsträckor [1] samt ESD och överspänningståligheten kommer i en helt annan klass... ethernettrafo eller själv linda dito på en toroid är mycket billigare lösning än någon annan bufferlösning med isolation i sig!, och har man gjort protokollet rätt så behövs dessa inte slängas in förrän när det behövs om man jagar dom få kronor för dessa i kostnad.
Hårdvara kan inte kompensera utan stora extra kostnader för en dålig vald mjukvarukommunikationsalgoritm - och för att välja en bra sådan så bör man känna till lite fysik, lite signal och informationsteori och transmissionslinjeteori, samt kännedom om redan gjorda allvarliga designmissar när det gäller informationöverföring på media, om man inte stjäl rakt av en redan utprovad koncept...
[1]
Långa kabelsträckor bör också provas ut då tajta tidsfönster i protkollet kan balla ur fullständigt när man får in kabelfördröjningen... - det är bl.a en sådan som begränsar USB:ns räckvidd till under 10 meter och måste ha aktiva 'repetrar' för längre länkar... - ytterliggare exempel på idiotisk design där konstruktörerna inte vet om att kablar har fördröjningar... - eller avsiktligt för att just sälja 'repetrar/hub'...
Protokollen är redan låsta eftersom jag skall prata med befintlig utrustning, har dock inte kikat så någrant på algoritmerna, men gissar att paketen börjar med en startbyte, datalen, data, kontrollsumma och stoppbyte.
Onekligen är MAXen trevlig, då man slipper alla kringkomponenter, men man får en hel del komponenter för $7 om man jämför med ADM
Gissar att jag får göra en av var sort, och se vilken som är bäst.
Onekligen är MAXen trevlig, då man slipper alla kringkomponenter, men man får en hel del komponenter för $7 om man jämför med ADM
Gissar att jag får göra en av var sort, och se vilken som är bäst.
Sitter precis i den sitsen och tyckte ovanstående lät intressant så jag passar på att lånar tråden lite. Förstod inte riktigt allt ovan, ska man låta RS485 drivern sända in i trafon och sen ut på kablen eller ska man köra vanlig TTL in den och skippa RS485 huvudtaget ?xxargs skrev:Ni som sitter och fila på egna dataprotokoll till era byggen via RS485 etc. - tänk rätt nu redan från början - och provkör alltid via ett par ethernetrafo i serie (för isolering i båda ändarna) och en bit CAT-5 kabel (även från RS485-drivsteg med 100 Ohm terminering) och justera era kommunikationsalgoritmer där tills det fungerar övertygande
Jag är ute efter en lösning för snabb enkelriktad kommunikation på minst 10Mbit eller högre från en master till flera slavar över ett tiotals meter kabel. Vill ha en kedjetopologi där varje enhet har en kabel in och en ut och vidare till nästa.
RS485 har rätt topologi men standarden säger max 10Mbit däremot finns det kretsar som är specade för 35Mbit som kanske kan vara en lösning. Däremot är bekymmret om man ska isolera trancivern eller om man ska koppla ihop alla enheters jord via ett extra par.
Ethernet är frestande när det gäller hastighet och isolation men känns lite överdrivet med alla protokoll för såpass enkel kommunikation plus att det har en stjärntopologi med en hub i mitten. Men om man kunde använda hårdvaran enklare protokoll hade det varit intressant.
Inte nödvändigt, du kan alltid köra "Token Ring" också, dvs koaxial-kabel, med ett "T" på varja mottagande enhet och ett slutmotstånd i bortesta ändan.Ethernet är frestande när det gäller hastighet och isolation men känns lite överdrivet med alla protokoll för såpass enkel kommunikation plus att det har en stjärntopologi med en hub i mitten.
Skulle det inte gå att använda sig av en färdig PHY krets som kommunicerar med FPGA via MII bussen. Tillsammans med en trafo så har man all hårdvara för att kunna överföra nibbles i 100 Mbit. Men eftersom jag är ute efter en busstopologi och det enbart är enkelriktad kommunikation så sätter man dit två kontakter och där den ena bara kan ta emot data och den andra bara skicka vidare till nästa enhet. Sen skriver man en MAC och något protokoll som skickar startsekvenser och tar hand om addresseringen av enheterna. Det bästa skulle vara om första enheten tog sin del av data och skickade vidare det som kommer efter till de efterföljande enheterna utan att behöva ställa in addresser fysiskt. Det blir med andra ord ett sätt att komma åt att använda ethernets fysisk lager men på sitt egna sätt. Skulle ovanstående lösningar fungerar elller finns det några uppenbara nackdelar. Eller är det kanske bättre att satsa på att implementera fullständiga nätverksportar med riktiga protokoll ändå ?
