Läste http://157.158.56.13/Electronics_Firm_D ... AS/tb1.htm om egenskaper hos transmissionsbussar.
Om jag förstått det rätt borde man kunna beräkna maximal bithastighet för ett open-collector nät med pull-up motstånd. där man endast använder ledningen för att skicka data mha:
Pull up resistansens strömtillförsel:
Vdd = Systemspänning (spänning som resistorn drar mot) [Volt]
Voh = Högnivå spänningsnivå. [Volt]
Rpull = Pull-up resistans. Ω
Iup = (Vdd-Voh)/Rpull = (5-2.2)/4700 = 0.6 mA
Bithastighet som beroende av transmissions kapacitansen:
Cl = Kapacitans per meter [Farad]
length = Kabelns längd [meter]
Iup = Tillförd ström från pull-up motstånd [Ampere]
1/((Cl * length * Voh)/Iup) = 1/((52*10**-12*36*2.2)/Iup) = 144654 bps
Eftersom en utgång från t.ex. en PIC16F54 klarar att sänka 25 mA som är betydligt mer än 0.6 mA borde det iaf inte gå långsammare.
Stämmer dessa beräkningar..?
Bithastigheten verkar riktigt låg.
Några synpunkter som dokument författaren hadde var att:
* Jorda ej ledningar i kabeln som ej används då detta ökar kapacitansen.
* Scotchy diod med anod mot jord i slutet av transmissionskabeln förhindrar vissa transienter.
För 1-wire fantaster kan dessa vara intressanta:
* Använd DS2409 för att dela upp bussen i mindre delar.
* Använd DS2480 för att koppla in en PC med rs232 smidigt.
* Resistans i serie med kapacitans i slutet av transmissionskabeln förhindrar reflektioner utan att interferera med strömförsörjningen via parasitkapacitans.
Transmission line effect..
No-brain tumregler för digitalknuttar.... och då blir det inte bättre fart än så...
Skall du ha hög fart över längre distanser så föreslår jag att läsa lite transsmissionsteori (då inser du också vilken 'enkel' värld digitalknuttarna lever sorglöst i med sk. 'tumregler' - tills det skall gå fort) - där är bara impedanser på sändare/mottagare och mediats karaktäristiska impedans, frekvens och bandbredd som är det intressanta - inte en ev. drivers strömförmåga och hur mycket kapasitans den måste sänka då det ändå är ointressant efter några meter distans då det är kabeln (transmissionslinan) som bestämmer reglerna!! 'Drivern' ser inte mer än 10-20% av använda signalens våglängd på kabeln och därmed bara den 'kabelbitens' kapacitans! - som av någon anledning upplevs av drivern som samma resistans som kabelens karaktäristiska impedans oavsett frekvens (över ca 200 kHz) .
Tar man inte hänsyn till kabelns egenskaper så blir sådana kattskitsgrejor som IDE-bussen och senare USB1.0 och USB1.1 som åter igen gjorde samma misstag som IDE-bussen enligt det tänkesättet som din länk hänvisar till - typisk digital-knutte resonemang där man försöker bygga regler efter vad man har sett på oscilloskåpet...
En bättre, dock ej perfekt lösning om man vill vara kvar i TTL-nivåernas värld (framförallt på mottagarsidan) är att titta på hur SCSI-bussen är principiellt byggd - där har man termineringar i ändarna och OC-som driver - finessen är de DC-matade termineringsmotstånd på 330 Ohm mot jord och 220 Ohm mot 5 Volt som gjorde att 'vilspänningen' i 'mitten' låg inom '1' för en TTL-ingång och OC behövde bara jorda för att få en '0'
220//330 Ohm parallellt kopplade (AC-mässigt räknat) ger 132 Ohm vilket ligger nära bandkabelns karaktäristiska impedans på runt 110 Ohm vilket gjorde systemet mer eller mindre helt reflexfri och därmed kan man packa nivåomslagen tätt då man inte behöver vänta på att ringningarna från förra växling skulle hinna klinga ut innan nästa nivåväxling - just detta är det som bergränsa IDE-bussens kapacitet....
Än mer korrekt transmissionssystem är tex RS485 med balanserad drives och mottagare, och även där terminerar ändarna av kabeln med normalt 100 Ohm - just denna system kan köra upp till 2 Mbit på 2 km kabel och mycket hänger faktiskt på mottagarens känslighet då kabeln dämpar signalen kraftigt.
Med balansering så är man väldigt okänslig för omgivande skärmningsåtgärder - ev. ökad kapacitans mot skärmen pga skärmningsåtgärder/jordplan för att klara EMC-krav har nästan ingen verkan på signalerna som går i paret.
ökad kapacitans mellan ledarparet (men bibehållen karaktärisktisk impedans mha också ökad induktans) påverkat inte driverns lastgrad utan ger bara att signalen går långsammar fram genom kabeln.
---
En sista sak - för att pulserna skall nå mottagaren utan allt för mycket envelopdistorsion (kurformsändring) så måste alla frekvenskomponenter som bygger kurvformen/data ligga över ca 200 kHz - över 200 kHz så har kabeln ingen större 'diskantdämpning' utan är frekvensrak och fasrakt upp till många MHz (skinneffekten dämpar dock sakta med högre frekvens). Alla frekvenskomponenter under 200 kHz är i kabelns (i stort sett oavsett typ) komplexa impedansområde vilket innebär olika mycket dämpning beroende på frekvens ( den bekanta diskantdämpning i kabel) samt också olika fasgång som distorderar envelopen och gör den svårigenkännlig för mottagaren - det är därför det är svårt att få fungerande RS232-anslutning i 115200 Baud på 25 meter kabel, men förmodligen fungerar bättre med 1152000 Baud om man också fixade impedanserna i ändarna på driver och mottagare av RS232-kretsen (typ 100 Ohm i serie med utgången och 100 Ohm mot jord på mottagarsidan)...
Skall du ha hög fart över längre distanser så föreslår jag att läsa lite transsmissionsteori (då inser du också vilken 'enkel' värld digitalknuttarna lever sorglöst i med sk. 'tumregler' - tills det skall gå fort) - där är bara impedanser på sändare/mottagare och mediats karaktäristiska impedans, frekvens och bandbredd som är det intressanta - inte en ev. drivers strömförmåga och hur mycket kapasitans den måste sänka då det ändå är ointressant efter några meter distans då det är kabeln (transmissionslinan) som bestämmer reglerna!! 'Drivern' ser inte mer än 10-20% av använda signalens våglängd på kabeln och därmed bara den 'kabelbitens' kapacitans! - som av någon anledning upplevs av drivern som samma resistans som kabelens karaktäristiska impedans oavsett frekvens (över ca 200 kHz) .
Tar man inte hänsyn till kabelns egenskaper så blir sådana kattskitsgrejor som IDE-bussen och senare USB1.0 och USB1.1 som åter igen gjorde samma misstag som IDE-bussen enligt det tänkesättet som din länk hänvisar till - typisk digital-knutte resonemang där man försöker bygga regler efter vad man har sett på oscilloskåpet...
En bättre, dock ej perfekt lösning om man vill vara kvar i TTL-nivåernas värld (framförallt på mottagarsidan) är att titta på hur SCSI-bussen är principiellt byggd - där har man termineringar i ändarna och OC-som driver - finessen är de DC-matade termineringsmotstånd på 330 Ohm mot jord och 220 Ohm mot 5 Volt som gjorde att 'vilspänningen' i 'mitten' låg inom '1' för en TTL-ingång och OC behövde bara jorda för att få en '0'
220//330 Ohm parallellt kopplade (AC-mässigt räknat) ger 132 Ohm vilket ligger nära bandkabelns karaktäristiska impedans på runt 110 Ohm vilket gjorde systemet mer eller mindre helt reflexfri och därmed kan man packa nivåomslagen tätt då man inte behöver vänta på att ringningarna från förra växling skulle hinna klinga ut innan nästa nivåväxling - just detta är det som bergränsa IDE-bussens kapacitet....
Än mer korrekt transmissionssystem är tex RS485 med balanserad drives och mottagare, och även där terminerar ändarna av kabeln med normalt 100 Ohm - just denna system kan köra upp till 2 Mbit på 2 km kabel och mycket hänger faktiskt på mottagarens känslighet då kabeln dämpar signalen kraftigt.
Med balansering så är man väldigt okänslig för omgivande skärmningsåtgärder - ev. ökad kapacitans mot skärmen pga skärmningsåtgärder/jordplan för att klara EMC-krav har nästan ingen verkan på signalerna som går i paret.
ökad kapacitans mellan ledarparet (men bibehållen karaktärisktisk impedans mha också ökad induktans) påverkat inte driverns lastgrad utan ger bara att signalen går långsammar fram genom kabeln.
---
En sista sak - för att pulserna skall nå mottagaren utan allt för mycket envelopdistorsion (kurformsändring) så måste alla frekvenskomponenter som bygger kurvformen/data ligga över ca 200 kHz - över 200 kHz så har kabeln ingen större 'diskantdämpning' utan är frekvensrak och fasrakt upp till många MHz (skinneffekten dämpar dock sakta med högre frekvens). Alla frekvenskomponenter under 200 kHz är i kabelns (i stort sett oavsett typ) komplexa impedansområde vilket innebär olika mycket dämpning beroende på frekvens ( den bekanta diskantdämpning i kabel) samt också olika fasgång som distorderar envelopen och gör den svårigenkännlig för mottagaren - det är därför det är svårt att få fungerande RS232-anslutning i 115200 Baud på 25 meter kabel, men förmodligen fungerar bättre med 1152000 Baud om man också fixade impedanserna i ändarna på driver och mottagare av RS232-kretsen (typ 100 Ohm i serie med utgången och 100 Ohm mot jord på mottagarsidan)...
* USB - Måndagsdesign..vars interfacechip blev inlödda på ens moderkort utan alternativ. Mao något som blev påtvingat av marknadsförare hos Intel. Klarar ingen längd, ej separerad tx/rx osv. Håller med pile-of-shit.
* För open-collector TTL verkar FPT terminering vara en än bättre termineringsteknik än både aktiv och passiv. freeopenbook.com upgrade & repair
Med tanke på att SCSI-1 klarade iaf 5 MHz med passiv terminering. Och vid linjärt förhållande för 36 meter borde hastigheten som kan hanteras bli 833 kHz. Förutsatt att man kör scsi terminering då.
* Kan man öka P-ATA (IDE) längden genom att införa aktiv terminering på befintlig utrustning?, iofs är P-ATA en måndagsdesign som mycket annat på x86-PC.
* Ang, 200 kHz begränsningen. Är det flanktiden som skall hållas till 5 us, eller den omodulerade bithastigheten..?, eller både och?
* För open-collector TTL verkar FPT terminering vara en än bättre termineringsteknik än både aktiv och passiv. freeopenbook.com upgrade & repair
Med tanke på att SCSI-1 klarade iaf 5 MHz med passiv terminering. Och vid linjärt förhållande för 36 meter borde hastigheten som kan hanteras bli 833 kHz. Förutsatt att man kör scsi terminering då.
* Kan man öka P-ATA (IDE) längden genom att införa aktiv terminering på befintlig utrustning?, iofs är P-ATA en måndagsdesign som mycket annat på x86-PC.
* Ang, 200 kHz begränsningen. Är det flanktiden som skall hållas till 5 us, eller den omodulerade bithastigheten..?, eller både och?
Andra kommentaren:
med klassisk 330/220 Ohm terminering ala standardvärden så får man parallellt 132 Ohm impedans - men bandkabeln är inte 132 Ohm utan snarare runt 100-110 Ohm vilket innebär att man får rester av ringning ändå - i 5 MHz system så gör det ingen - inte 10 MHz system heller men kör man riktigt fort som dagens system så börjar även dessa 'rester' bli störande och man måste ha bättre, mer 'perfekt' terminering mot kabelns faktiska impedans - har inte analyserat FPT i detalj, men gissar att just FPT gör detta samt strömmanagenment så att utrustningen själv kan slå av och på aktiva termineringen utan aktivitet från användaren - det är just termineringshanteringen som har gett strul/fuskat hos mindre vana användare att man inte har placerat någon terminering alls/bara ena ändan och så undrar man varför dessa strular ibland... Idag så gömmer man alltid termineringarna inne i utrustning så att användaren inte ser och vet om dessa - det gäller USB2.0, firewire, TP-Ethernet, S-ATA - ja alla höghastighestlänkar i prinsip - för det är den enda sättet.
näst sista frågan:
I prinsip borde man ha kunnat göra detta - men av någon anledning så gjorde man inte detta utan 'trimmade' med mångledade smalare ledare (högre resistans) och kortade längderna för att minska kapacitansen mellan ledarna och får ringningen att gå snabbare (kortare längd) samt att klinga av fortare (ökad ledningsresitans) - med all möda med nya kontaktdon och tätribbade kablar etc. så borde aktiv terminering ha varit billigare lösning... - men man gjorde det inte...
terminering är nyckel för att kunna köra fort över längre kabelsträckor - det finns ingen annan väg hur mycket man än önskar.
Sista frågan:
Energirika delen av frekvensinnehållet på dina 'viktiga data' bör inte har för mycket sidband som går under 200 kHz. Med andra ord så kanske man får modulera sin data på en 'bärvåg' av säg 1 Mbit med '101010101' och avvikelse från det mönstret bär dina data i ditt datapaket - den tekniken var man tvungen att använda på tex. hårddiskskrivhuvuden då man magnetiskt inte kunde lagra 'DC'-värden utan istället löste det med FM och MFM-modulering - dessutom skramblar man datat så att datat inte kom med för många nollor eller ettor efter varandra (tex inte mer än 5 '1' eller '0' efter varandra om man skall hålla sig över 200 kHz) samt energimässig balans mellan antal '1' och '0' (dvs lika många av varje räknat över lite större tidsfönster) - och motsvarande måste man göra även för datapaket över längre kabelsträckor - med denna teknik så fins det heller ingen DC-komponent vilket möjligör uppbrytning med ferrittransformatorer för galvansik isolering - görs i varenda TP-Ethernet koppling idag med 2000-4000 Volts tålighet mellan A och B-sida i varje steg.
Designa man in detta rätt redan från början i avseende HW mot använd media och använd vettig protokoll från början så har man stor flexibilitet - Men kör man med traditionell överföring på DC-nivå ala TTL som USB-buss etc. så får man ett helsike den dagen då man har 15 Volt 50 Hz AC mellan sändare och målet pga. olika skyddsjordreferenser och med DC-beroende överföring så får man ett helsike att isolera upp det och kan i stort sett bara göras med en eller flera optokopplare - som dessutom måste vara mycket bredbandiga med många MHz kapacitet...
Tänk stort topologiskt med rätt transportmetod - men implementera bara det som behövs för tillfället så kan du växa med möjliga lösningar allt eftersom man stöter på problem ( isolationsproblem?? - enket löst - skarva in en billig ethernettrafo i standard RJ45 uttag - bara för att man topologikt tänkte innan på att bygga data i paketform med slängbara träningsskvenser i början och med 1 Mbit 'bärvåg' samt utan DC-beroende samt balanserade drivers och impedansanapssat mot 100 Ohm kabel!!!
- Skitsvårt att i efterhand fixa med vanlig TTL-signalering och ogenomtänkt DC-beroende protokoll på basband och okontrollerad kablar impedansmässigt samt ingen terminering... (the Intel way...)
med klassisk 330/220 Ohm terminering ala standardvärden så får man parallellt 132 Ohm impedans - men bandkabeln är inte 132 Ohm utan snarare runt 100-110 Ohm vilket innebär att man får rester av ringning ändå - i 5 MHz system så gör det ingen - inte 10 MHz system heller men kör man riktigt fort som dagens system så börjar även dessa 'rester' bli störande och man måste ha bättre, mer 'perfekt' terminering mot kabelns faktiska impedans - har inte analyserat FPT i detalj, men gissar att just FPT gör detta samt strömmanagenment så att utrustningen själv kan slå av och på aktiva termineringen utan aktivitet från användaren - det är just termineringshanteringen som har gett strul/fuskat hos mindre vana användare att man inte har placerat någon terminering alls/bara ena ändan och så undrar man varför dessa strular ibland... Idag så gömmer man alltid termineringarna inne i utrustning så att användaren inte ser och vet om dessa - det gäller USB2.0, firewire, TP-Ethernet, S-ATA - ja alla höghastighestlänkar i prinsip - för det är den enda sättet.
näst sista frågan:
I prinsip borde man ha kunnat göra detta - men av någon anledning så gjorde man inte detta utan 'trimmade' med mångledade smalare ledare (högre resistans) och kortade längderna för att minska kapacitansen mellan ledarna och får ringningen att gå snabbare (kortare längd) samt att klinga av fortare (ökad ledningsresitans) - med all möda med nya kontaktdon och tätribbade kablar etc. så borde aktiv terminering ha varit billigare lösning... - men man gjorde det inte...
terminering är nyckel för att kunna köra fort över längre kabelsträckor - det finns ingen annan väg hur mycket man än önskar.
Sista frågan:
Energirika delen av frekvensinnehållet på dina 'viktiga data' bör inte har för mycket sidband som går under 200 kHz. Med andra ord så kanske man får modulera sin data på en 'bärvåg' av säg 1 Mbit med '101010101' och avvikelse från det mönstret bär dina data i ditt datapaket - den tekniken var man tvungen att använda på tex. hårddiskskrivhuvuden då man magnetiskt inte kunde lagra 'DC'-värden utan istället löste det med FM och MFM-modulering - dessutom skramblar man datat så att datat inte kom med för många nollor eller ettor efter varandra (tex inte mer än 5 '1' eller '0' efter varandra om man skall hålla sig över 200 kHz) samt energimässig balans mellan antal '1' och '0' (dvs lika många av varje räknat över lite större tidsfönster) - och motsvarande måste man göra även för datapaket över längre kabelsträckor - med denna teknik så fins det heller ingen DC-komponent vilket möjligör uppbrytning med ferrittransformatorer för galvansik isolering - görs i varenda TP-Ethernet koppling idag med 2000-4000 Volts tålighet mellan A och B-sida i varje steg.
Designa man in detta rätt redan från början i avseende HW mot använd media och använd vettig protokoll från början så har man stor flexibilitet - Men kör man med traditionell överföring på DC-nivå ala TTL som USB-buss etc. så får man ett helsike den dagen då man har 15 Volt 50 Hz AC mellan sändare och målet pga. olika skyddsjordreferenser och med DC-beroende överföring så får man ett helsike att isolera upp det och kan i stort sett bara göras med en eller flera optokopplare - som dessutom måste vara mycket bredbandiga med många MHz kapacitet...
Tänk stort topologiskt med rätt transportmetod - men implementera bara det som behövs för tillfället så kan du växa med möjliga lösningar allt eftersom man stöter på problem ( isolationsproblem?? - enket löst - skarva in en billig ethernettrafo i standard RJ45 uttag - bara för att man topologikt tänkte innan på att bygga data i paketform med slängbara träningsskvenser i början och med 1 Mbit 'bärvåg' samt utan DC-beroende samt balanserade drivers och impedansanapssat mot 100 Ohm kabel!!!
- Skitsvårt att i efterhand fixa med vanlig TTL-signalering och ogenomtänkt DC-beroende protokoll på basband och okontrollerad kablar impedansmässigt samt ingen terminering... (the Intel way...)
The Intel way måndagsdesignade x86 arkitekturen också..
Efter att sett olika hemautomationsprojekt. Funderade jag på en smart lösning för att låta många billiga noder kommunicera effektivt. Dom kommunikations sätt som verkar överkommliga är:
* TTL Open collector gör att man kan använda en GPIO per enhet både för att sända och ta emot. Samt plocka +5VDC + GND från ett annat ledarpar.
* TTL Open collector med två GPIO kopplade via varsin kondensator så att man får differentiell signalering. Frågan är ifall det fungerar.
* RS-485, det klart bästa. Men kräver en extra drivare förutom ev PIC/AVR. Vilket ökar komplexitet och kostnad. Kanske kan man blanda RS-485/TTL så att höghastighetsnoder kan sätta långsamma noder i väntläge medans höghastighetsdata skickas.
Om man AC kopplar ett bidirektionellt RS-485 drivsteg med varsin kondensator per tråd. Borde endast ev kapacitans hos långsammare noder påverka. Och möjliggöra nyttjande av samma tråd.
Ang FPT:
När jag tittade på konstruktionen verkar det som att den nyper allt under 0V till GND. Och allt över ~2.2V till en 2.2V rail skapad med transistorn. Blev inte klok på vilken späningsnivå som transistorn ger upphov till. Basen verkar få 1.4V. Och sen kan den dra ett motstånd till TERMPWR (+5VDC).
Efter att sett olika hemautomationsprojekt. Funderade jag på en smart lösning för att låta många billiga noder kommunicera effektivt. Dom kommunikations sätt som verkar överkommliga är:
* TTL Open collector gör att man kan använda en GPIO per enhet både för att sända och ta emot. Samt plocka +5VDC + GND från ett annat ledarpar.
* TTL Open collector med två GPIO kopplade via varsin kondensator så att man får differentiell signalering. Frågan är ifall det fungerar.
* RS-485, det klart bästa. Men kräver en extra drivare förutom ev PIC/AVR. Vilket ökar komplexitet och kostnad. Kanske kan man blanda RS-485/TTL så att höghastighetsnoder kan sätta långsamma noder i väntläge medans höghastighetsdata skickas.
Om man AC kopplar ett bidirektionellt RS-485 drivsteg med varsin kondensator per tråd. Borde endast ev kapacitans hos långsammare noder påverka. Och möjliggöra nyttjande av samma tråd.
Ang FPT:
När jag tittade på konstruktionen verkar det som att den nyper allt under 0V till GND. Och allt över ~2.2V till en 2.2V rail skapad med transistorn. Blev inte klok på vilken späningsnivå som transistorn ger upphov till. Basen verkar få 1.4V. Och sen kan den dra ett motstånd till TERMPWR (+5VDC).
Edit: glöm svamlet om FPT här - jag måste analysera kopplingen innan vidare uttalande 
RS485: - farligt, farligt - filtreringsverkan blir inte så bra som du tror med bara kondingar och de olika in och utgångsstegen ser varandra rent impedansmässigt med största sannolikhet och tillsamman ger fel impedans gentemot använd kabel..
Diplexlösningar är iofs. lockande tanke att studera om det övh. alls går att göra - men komplexiteten för diplexarna kommer att bli värre än att sätta dit en RS485-krets efter som en diplexer med tillräklig branthet kräver ett flertal passiva kondingar och drosslar då frekvensnivåerna är så höga att det inte kan lösas med OP-ampar etc. lösningar.
Om du har en Spice-simulator med goda modeller av TTL/CMOS-ingångar/utgångar (samt RS485) så bör du prova detta där innan praktisk design...
tyvärr är frekvenserna ändå så låga att det inte räcker med typ 100nH-drosslar från coilcraft eller liknande...
RS485: - farligt, farligt - filtreringsverkan blir inte så bra som du tror med bara kondingar och de olika in och utgångsstegen ser varandra rent impedansmässigt med största sannolikhet och tillsamman ger fel impedans gentemot använd kabel..
Diplexlösningar är iofs. lockande tanke att studera om det övh. alls går att göra - men komplexiteten för diplexarna kommer att bli värre än att sätta dit en RS485-krets efter som en diplexer med tillräklig branthet kräver ett flertal passiva kondingar och drosslar då frekvensnivåerna är så höga att det inte kan lösas med OP-ampar etc. lösningar.
Om du har en Spice-simulator med goda modeller av TTL/CMOS-ingångar/utgångar (samt RS485) så bör du prova detta där innan praktisk design...
tyvärr är frekvenserna ändå så låga att det inte räcker med typ 100nH-drosslar från coilcraft eller liknande...
Re: Transmission line effect..
Kanske man kan sammanfatta det som att en bra bus:
* Använder terminering
* Korrekt vilopunkt spänningsmässigt (balans). I SCSI har man passiv terminering på 220 + 330 ohm som ger 132 ohm karektiristisk impedans.
* Differentiellt signalering
* Håller signaleringen inom korrekt frekvensdomän med modulering, t.ex tvinga bitomslag tillräckligt ofta (GCR, Manchester, osv).
* Energibalans mellan 0 och 1 över längre tidsfönster (som t.ex TMDS)
Hittar ingen DC-balans i 10BASE-T .. knepigt
Jag har iaf hittat förklaringen till FPT termineringen:
http://www.faqs.org/faqs/scsi-faq/part1/
"QUESTION: What is FPT (Termination)?"
"Using the values shown, transients would be clamped at 0.2V and 3.0V."
(med vilonivå på 2.8 V)
* Använder terminering
* Korrekt vilopunkt spänningsmässigt (balans). I SCSI har man passiv terminering på 220 + 330 ohm som ger 132 ohm karektiristisk impedans.
* Differentiellt signalering
* Håller signaleringen inom korrekt frekvensdomän med modulering, t.ex tvinga bitomslag tillräckligt ofta (GCR, Manchester, osv).
* Energibalans mellan 0 och 1 över längre tidsfönster (som t.ex TMDS)
Hittar ingen DC-balans i 10BASE-T .. knepigt
Jag har iaf hittat förklaringen till FPT termineringen:
http://www.faqs.org/faqs/scsi-faq/part1/
"QUESTION: What is FPT (Termination)?"
"Using the values shown, transients would be clamped at 0.2V and 3.0V."
(med vilonivå på 2.8 V)
Re:
...för att inte tala om att den inte är galvaniskt isolerad.blueint skrev:* USB - Måndagsdesign..vars interfacechip blev inlödda på ens moderkort utan alternativ. Mao något som blev påtvingat av marknadsförare hos Intel. Klarar ingen längd, ej separerad tx/rx osv. Håller med pile-of-shit.
Sedan var det ett gäng programmerare som gjorde ett fullständigt hopplöst Tisdagsprotokoll ovanpå den Måndagaskonstruktionen. Att inte ha stöd för mer än en "host" är obegripligt... det finns en massa annat man kan säga om USB protokollet. Bland annat verkar det vara extremt känsligt för störningar och lägger ner kommunikationen om man stör den tillräckligt.
Är det någon som har erfarenhet av Firewire? Den verkar ju iallafall kunna köra utan "host" och var byggd för höga hastigheter från början.
Re: Transmission line effect..
Firewire går under namnet IEEE 1394 och används bl.a för DV videokameror. Problemet där brukar vara att det är synkront, och man riskerar att tappa information.. doh. Dock klarar den 400 Mbit/s kontinuerligt vilket är rätt användbart för A/D, video, och liknande synkrona aktiviteter.
Bussen kan ge upp till 45 W med sina 30 V.
"IEEE 1394b is used in military aircraft. Developed for use as the data bus on the F-22 Raptor, it is also used on the F-35 Lightning II.[33] NASA's Space Shuttle also uses IEEE 1394b to monitor debris (foam, ice) which may hit the vehicle during launch.[33]"
(tja.. undrar varför dom hoppade USB ..
)
USB:s onsdagslösning är "USB OTG".
Bussen kan ge upp till 45 W med sina 30 V.
"IEEE 1394b is used in military aircraft. Developed for use as the data bus on the F-22 Raptor, it is also used on the F-35 Lightning II.[33] NASA's Space Shuttle also uses IEEE 1394b to monitor debris (foam, ice) which may hit the vehicle during launch.[33]"
(tja.. undrar varför dom hoppade USB ..
)USB:s onsdagslösning är "USB OTG".
Re: Transmission line effect..
Joo.. finns många anledningar att man säger "USelBuss" istf USB.
Funkar ungefär lika bra som "bredband" genom 3G... mycke snack och liten kaka.
Funkar ungefär lika bra som "bredband" genom 3G... mycke snack och liten kaka.
Re: Transmission line effect..
mycket av problemen ligger också på protokollnivå - med paketorienterad nät så har man redan sagt adjö till 50% av kapaciteten samt skapat stort tidsgitter när det gäller leverans av datapaket vilket gör det omöjligt att använda i tidskritiska system och först med mycket pusslande strategimässigt på host och klientsidan så kanske man kan komma upp till 70% av teoretiska kapaciteten.
IEEE 1394 är vad man skulle kalla liknande kretskopplad nät - dock lite flexiblare än telefonnätens PCM-länkar. Med kretskopplade nät så kan man både garantera sig transportkapacitet och kontrollerade fördröjningstider när det gäller paketleverans vilket är nyckelfaktorer i realtidssystemsapplikationer.
inom radiomätsystem där tidsfaktorn är viktig och att datapaketen kommer i exakt jämn takt och aldrig får riskera att stalla (som det kan göra i paketorienterade system) så används IEEE-1394 som kommunikationslänk eftersom det är helt omöjligt att få till liknande med USB
IEEE 1394 är vad man skulle kalla liknande kretskopplad nät - dock lite flexiblare än telefonnätens PCM-länkar. Med kretskopplade nät så kan man både garantera sig transportkapacitet och kontrollerade fördröjningstider när det gäller paketleverans vilket är nyckelfaktorer i realtidssystemsapplikationer.
inom radiomätsystem där tidsfaktorn är viktig och att datapaketen kommer i exakt jämn takt och aldrig får riskera att stalla (som det kan göra i paketorienterade system) så används IEEE-1394 som kommunikationslänk eftersom det är helt omöjligt att få till liknande med USB
Re: Transmission line effect..
RS485 valde jag för mitt hemmanätverk helt enkelt eftersom det är mycket enkelt att implementera det som krävs är i stort sett en krets för 10 spänn, och är det för stor kostnad ja då tror jag man är på djupt vatten ändå RS232 är mycket drygare iom att där ska vara kondensatorer i massor och stora såna också 
RS232 är mycket drygare iom att där ska vara kondensatorer i massor och stora såna också 
