Vad är den undre gränsfrekvensen för isolationstransformatorer som används i Ethernet ..?
Alltså lägsta frekvens som man kan mata igenom utan att få alltför stor dämpning.
Undre gränsfrekvens för ethernet trafo?
Re: Undre gränsfrekvens för ethernet trafo?
Det går inte att svara på den frågan, "alltför stor dämpning" är inte definerat.
Hursom så kan du köra ner till hur låg frekvens du vill om du samtidigt sänker spänningen. Dvs håller spänningstidytan konstant.
Hursom så kan du köra ner till hur låg frekvens du vill om du samtidigt sänker spänningen. Dvs håller spänningstidytan konstant.
Re: Undre gränsfrekvens för ethernet trafo?
Tänkte om man t.ex kan använda 100 kbit/s eller 1000 kbit/s kommunikation med EIA-485 drivare/mottagare + ethernettrafo och få det att fungera. Bakom transceiverserna sätter man någon ATmega eller ARM Cortex.
Ett mått jag sett användas är när dämpningen blir större än 3 dB. Fast frågan är hur stor skillnad det gör.
Ett mått jag sett användas är när dämpningen blir större än 3 dB. Fast frågan är hur stor skillnad det gör.
Re: Undre gränsfrekvens för ethernet trafo?
Kollade några datablad på transformatorer och Lp=350uH vid 100kHz och 0.1V så då borde man ju kunna blåsa på med i alla fall 1V vid 1Mhz. RS422 verkar ha en treshold på 0.2V max så 1Mbps gissar jag kan fungera.
Tänk på att du måste koda signalen med tex manchster.
Tänk på att du måste koda signalen med tex manchster.
Re: Undre gränsfrekvens för ethernet trafo?
Går det möjligtvis att skicka skurar av asynkrona tecken bara man gör det snabbt nog?, finns det någon kodning som är kräver lite av CPU:n ?
Tänkte mest för korta meddelanden som t.ex slå på/av relä, vad är temperaturen, "ping" osv.. som bör fungera säkert. Vill man köra snabbare kan man ju skicka "klarar du X bps med kodning Y?"
Tänkte mest för korta meddelanden som t.ex slå på/av relä, vad är temperaturen, "ping" osv.. som bör fungera säkert. Vill man köra snabbare kan man ju skicka "klarar du X bps med kodning Y?"
Re: Undre gränsfrekvens för ethernet trafo?
Jag antar att du menar att skicka som NRZ kodat.
Man får nog öka bithastigheten till 10 Mbits samt stoppa in lite "AA" tecken mellan varje tecken. Allt handlar om att inte mätta trafon.
Alternativt koda meddelandena som AA 55 AA AA 55 osv.
Man får nog öka bithastigheten till 10 Mbits samt stoppa in lite "AA" tecken mellan varje tecken. Allt handlar om att inte mätta trafon.
Alternativt koda meddelandena som AA 55 AA AA 55 osv.
Re: Undre gränsfrekvens för ethernet trafo?
Tänkte man kunde göra en fulis, skicka 7-bitar, och låta den 8:e biten indikera ifall överföringen är inverterad. På det sättet kan man DC-balansera precis som TMDS gör.
Re: Undre gränsfrekvens för ethernet trafo?
I princip borde det väl funka med att ha lämpligt högpassfilter på sändarens matning till trafon, och låta mottagaren ha en schmitdt-trigger (och en spänningsdelare som ser till att tomgångsspänningen ligger mitt i hysterersområdet). Schmidt-triggern behöver givetvis ha rätt storlek på hysteresen.
Enda nackdelen är att kopplingen behöver någon data mottagen för att garanterat hamna i rätt tillstånd. Man kan nog delvis hjälpa det med konstruktionen kring mottagaren. Jag tänker mig spänningsdelaren ansluten direkt på schmidttriggerns ingång, och där ansluts ena änden av trafons lindning. Andra änden av trafons lindning ansluts via en lämplig liten kondensator antingen till matningsspänning eller jord, beroende på vilket tillstånd man vill att mottagaren ska ha före någon signal mottagits.
Visst, det här är en fulmetod jämfört med att använda någon "riktig" kodning avsedd för överföringar som inte klarar likspänning, men den borde fungera hyggligt, åtminstone om man kompletterar med nån slags felkorrigering.
Enda nackdelen är att kopplingen behöver någon data mottagen för att garanterat hamna i rätt tillstånd. Man kan nog delvis hjälpa det med konstruktionen kring mottagaren. Jag tänker mig spänningsdelaren ansluten direkt på schmidttriggerns ingång, och där ansluts ena änden av trafons lindning. Andra änden av trafons lindning ansluts via en lämplig liten kondensator antingen till matningsspänning eller jord, beroende på vilket tillstånd man vill att mottagaren ska ha före någon signal mottagits.
Visst, det här är en fulmetod jämfört med att använda någon "riktig" kodning avsedd för överföringar som inte klarar likspänning, men den borde fungera hyggligt, åtminstone om man kompletterar med nån slags felkorrigering.
Re: Undre gränsfrekvens för ethernet trafo?
Det är sådana här spörsmål som spice-simulator är så bra att leka med - men stor del av jobbet är också att skapa hyffsade modeller på dom bitarna som skall analyseras - tex RS485 in och utgång finns det nog så pass mycket info att man kan skapa sig en hyffsad driv och ingångssteg-modell - sedan skall man inte glömma bort använd kabel (cat-5...) och ha modell av det före och efter trafon (typ använd TL modellen i spice och putta in kabelns primära parametrar - dvs dess L och R i serie och dess C och G mellan trådarna) och prova med aktuella längder då trafons beteende är till en stor del beroende på anslutande impedanser
På höga databittakter så behövs det inte många metrar för att det är kabeln som är dominerande i egenskap när det gäller kopplingen mot trafon - dvs. det är inte drivförmågan på RS485 som bestämmer reglerna längre - utan kabelns impedans som bestämmer hur mycket ström trafon får och bestämmer hur fort den drivs mot mättnad vid långa 11111 eller 00000 sekvenser om man tänker fuska sig fram utan NRZ-kodning eller liknande DC-neutral kodning.
...
'synd' att man är på semester - men det här skulle man ta och mäta upp på en nätverksanalysator och sedan se om man kan kan göra en hyffsad modell av med dess S-parameter som utgångspunkt, synd att jag inte har en sådan trafo liggande bara sådär - för då kanske man skulle ta en sväng förbi...
annars kan man ta dom tidigare nämda induktanserna i en trafomodell i tex spice och sedan se vad som händer vid olika pulståg och ingångstyper (tex RS485) och se hur lång 'bärvåg' man behöver före för att ta starttransienten innan trafons magnetfält börja vara något så när nära noll i genomsnitt igen - därefter synksekvens och datat.
om man inte har DC-biaserande kodning som NRZ-kodning för tex. dess krav på dubbla bandbredds skull så kan det till en del avhjälpas med scrambling - dvs. långa 11111 eller 0000-sekvenser omvandlas till mer slumpmässighet (ökar dess entropi) så att datat över ett visst fönsterlängd (antal bytes) är hyffsad DC-neutral - det är förstås beroende på hur fort magnetfälten i trafon rör sig (det beror på dess induktans) och nivån när den börja mätta sig och klippa signalen samt hur mycket distorsion man tål innan det börja bli läsfel på mottagardelen.
Givetvis kan man prova detta på praktiskt sätt fysiskt och studera det hela med oscilloskop med högimpediva probar och sedan någon MCU som spottar ur sig olika bitsekvenser inklusive avbrotten mellan dessa - men glöm för guds skull inte att koppla in olika längder kabel och prova - annars hamnar man i den så omtalade 'men, men, det fungerade ju i labbet!' när ett större, nykonstruerad system för första gången skall sättas upp hos en skeptisk kund och inget fungerar - för att man har glömt att räkna med kabelländerna och dess inverkan på last, pulsformsdist, dämpning och tidfördröjningar...
På höga databittakter så behövs det inte många metrar för att det är kabeln som är dominerande i egenskap när det gäller kopplingen mot trafon - dvs. det är inte drivförmågan på RS485 som bestämmer reglerna längre - utan kabelns impedans som bestämmer hur mycket ström trafon får och bestämmer hur fort den drivs mot mättnad vid långa 11111 eller 00000 sekvenser om man tänker fuska sig fram utan NRZ-kodning eller liknande DC-neutral kodning.
...
'synd' att man är på semester - men det här skulle man ta och mäta upp på en nätverksanalysator och sedan se om man kan kan göra en hyffsad modell av med dess S-parameter som utgångspunkt, synd att jag inte har en sådan trafo liggande bara sådär - för då kanske man skulle ta en sväng förbi...
annars kan man ta dom tidigare nämda induktanserna i en trafomodell i tex spice och sedan se vad som händer vid olika pulståg och ingångstyper (tex RS485) och se hur lång 'bärvåg' man behöver före för att ta starttransienten innan trafons magnetfält börja vara något så när nära noll i genomsnitt igen - därefter synksekvens och datat.
om man inte har DC-biaserande kodning som NRZ-kodning för tex. dess krav på dubbla bandbredds skull så kan det till en del avhjälpas med scrambling - dvs. långa 11111 eller 0000-sekvenser omvandlas till mer slumpmässighet (ökar dess entropi) så att datat över ett visst fönsterlängd (antal bytes) är hyffsad DC-neutral - det är förstås beroende på hur fort magnetfälten i trafon rör sig (det beror på dess induktans) och nivån när den börja mätta sig och klippa signalen samt hur mycket distorsion man tål innan det börja bli läsfel på mottagardelen.
Givetvis kan man prova detta på praktiskt sätt fysiskt och studera det hela med oscilloskop med högimpediva probar och sedan någon MCU som spottar ur sig olika bitsekvenser inklusive avbrotten mellan dessa - men glöm för guds skull inte att koppla in olika längder kabel och prova - annars hamnar man i den så omtalade 'men, men, det fungerade ju i labbet!' när ett större, nykonstruerad system för första gången skall sättas upp hos en skeptisk kund och inget fungerar - för att man har glömt att räkna med kabelländerna och dess inverkan på last, pulsformsdist, dämpning och tidfördröjningar...
