Klub zajemcu o datovou IR komunikaci

[ahorky@tero.cz]

Dovolim si castecne nesouhlasit.

Nevidim duvod, proc opatrovat prenasenou datovou informaci kontrolnim 
souctem, kdyz je jiz v prenasenem paketu obsazen. Hodlame tady nahradit 
"klasicke" prenosove medium optickym spojem, to znaci ze menime nejnizsi 
vrstvu v referencnim modelu ISO. Co v pripade, ze kontrolni soucet nebude na 
prijmaci strane spravny? To by totiz muselo zarizeni obsahovat dostatecnou 
vyrovnavaci pamet, aby se dal prenos znovu uskutecnit. Muze totiz nastat 
situace, kdy se prenos nekolikrat nepodari, ale sitova karta bude dale 
posilat data. To vlastne chceme, aby si klasicky medeny spoj mezi kartami 
sam pocital kontrolni soucty. O toto se musi starat ovladaci driver, ktery 
si v pripade nutnosti vyzada opetovne poslani vadneho paketu. Vy tady resite 
otazku kontrolnich souctu a zabezpeceni prenosu a co potom reseni kolizi pri 
soucasnem vysilani obou stran? Toto vse je prece vyreseno ve stavajicim 
propoji kabelem pomoci software.


Ales Horky
ahorky@tero.cz 

----------------------------------------------------------------------------
>Return-Path: <fsg-news@mobil.cz>
>Received: from mobil.cz ([194.213.194.6]) by ns.znojmo.bohem-net.cz
>          (Netscape Mail Server v2.02) with ESMTP id AAA278
>          for <ahorky@tero.cz>; Tue, 12 Jan 1999 21:20:03 +0100
>Received: from diana (localhost [127.0.0.1])
>	by mobil.cz (8.9.1/8.8.8) with SMTP id VAA10001;
>	Tue, 12 Jan 1999 21:25:27 +0100
>Date: Tue, 12 Jan 1999 21:25:27 +0100
>Message-Id: <Pine.LNX.4.05.9901121956460.29810-
>100000@Aldebaran.feld.cvut.cz>
>Errors-To: rehak@mobil.cz
>Reply-To: fsg-news@mobil.cz
>Originator: fsg-news@mobil.cz
>Sender: fsg-news@mobil.cz
>Precedence: bulk
>From: Vladimir Myslik <xmyslik@Aldebaran.feld.cvut.cz>
>To: Multiple recipients of list <fsg-news@mobil.cz>
>Subject: Klub zajemcu o datovou IR komunikaci
>X-Listprocessor-Version: 6.0 -- ListProcessor by Anastasios Kotsikonas
>X-Comment: FSG-News List, nejruznejsi informace o Free Single Chip Group
>Content-Type: TEXT/PLAIN; charset=US-ASCII
>MIME-Version: 1.0
>
>
>Zdravim,
>
>jelikoz se tu objevilo hodne dotazu ohledne komunikace svetlem na vetsi
>vzdalenosti, rad bych uvedl par bodu ktere si myslim ze jsou stezejni pro
>navrh _konecne_ pouzitelneho zarizeni
>
>
>* kolik lidi o to vlastne ma zajem a kolik by byli ochotni do toho vrazit?
>
>* Pokud to je mozne, Zjistit zda se da sehnat laserova InfraLEDdioda ktera
>je modulovatelna (pro dosah radu kilometru je to nutnost).
>
>* pokud se neda sehnat modulovatelna laserova infra LED dioda, alespon
>modulovatelny laser s trvalym provozem (aby se nevysvitil). 
>
>* Reseni s ukazovatky (ktere se vysviti a jdou desne blbe modulovat) jsem
>videl na inetu vcetne plosnaku pro 115200 bps (seriak) , zalozku mam nekde
>doma.
>
>* kolik by pripadne stalo parabolicke zrcadlo horsi kvality (neni nutna
>presnost jako u dalekohledu), ohnisk,. vzdal. tak 20-30 cm, prumer 10-15
>cm.
>
>* pokud by se pouzivala TP karta jako modulator vyssich rychlosti, pak
>prevodnik TP urovni (nebo AUI) na TTL.
>
>* umel by nekdo napsat programek do nejakeho jednocipu ktery by to zvladl
>ktery by bral ze serioveho portu data po osmicich (64 bitu) a zajistil je
>ECC kodem a vyslal seriove dale?
>Motivace tohodle bodu je zabezpecit seriovy tok dat proti chybam, anzto uz
>chybovost 10^-6 je dost nepouzitelna pro tcpip. Dosahl jsem chybovosti
>10^-8 a to je ok. Myslim ze je zbytecne zvysovat optickou intenzitu
>signalu jen proto, aby se snizila chybovost kdyz to jde zlepsit timhle.
>Pokud mohu totiz ze zkusenosti rici, tak prenos irda co jsme zkouseli je
>nachylny na ty jednotlive vypadnute bitiky - pri slabem signalu ma
>prijimac tendenci vypoustet prijmute pulzy cim slabsi je signal tim vice -
>na zlomu citlivosti prijimace je to markantni na osciloskopu, ale deje se
>to stale i pri silnejsim signalu jen s nizsi pravdepodobnosti.
>Napadlo me to uz i udelat to v programovatelne logice, pracuji na tom ve
>skole (pro vyssi rychlosti) ale do takovyho zakladniho xilinxe XC3000 se
>toho moc nevejde.
>
>Predstavoval jsem si to takhle
>S8 S8 S8 S8 S8 S8 S8 S8      ze seriaku
>SS[1.............64][1..8]O    z 1cipu ci pole pres irda
>   datove bity       ECC(SEC-DED)
>
>S je start bit
>O je nejaky interni bit kterym by se mohla cinit arbitraz pri half duplexu
>- treba predani prenos. media (predani aktivity)
>
>Ten ramec co bych chtel aby to umelo posilat by se dokonce mohl posilat
>stejnou frekvenci hodin jako prichozi znaky - bitove by to vychazelo
>(8*10=80 seriak a 2+64+8+1=75, 2 start bity proto ze kdyby jeden vypad aby
>se to tak nerozhodilo) navic by to bylo mene citlive na vypadnuti bitu coz
>je u asymetricke irda linky vlastne jedina chyba (opacne pribyti bitu je
>xxxkrat mene pravdepodobne). pokud se na seriove lince pouziva ppp tak je
>to na tohle extremne nachylne - vypadnutim bitu se rozhodi ramcova
>synchronizace spec. s kompresi paketu.
>
>Takze pokud nekdo vite:
>* jak velka progr. logika (kolik bunek) by byla potreba k zabezpeceni toku
>dat kodem SEC-DED napr. Hamm (72,64) aby se do ni vesel i stavovy automat
>pro prijem seriakem 8N1
>* ktery jednocip by to prip. zvladl
>to vse v prepinatelnem singl/half duplexu. Pro half duplex bych chtel aby
>to umelo nejakou arbitraz (CDMA) nebo nejaky flip-flop protoze na kratke
>vzdalenosti (pod 50 metru) se ji clovek 100% nevyhne.
>Ten half duplex zatim neni podminkou, my jedem na 200m(;-))
>
>S timhle bastlem by to uz ten kilometr s obycejnymi ledkami udelalo, pokud
>to bude v prog. poli. tak i ty 4 Mbity. V prog. poli jsem uz udelal dve
>jednotky ktere spolu komunikovaly pakety dle FIR modulace ale uz jsem na
>64CLBckach=plno (XC3020)
>
>
>
>Mozna ze kdyz bude HW Server na amperu, tak by se to do te doby dalo
>stihnout vzit tam aspon nejakou verzi kterou zatim pouzivame (ale chce to
>dodelat mechaniku).
>
>No a pokud mate dost $$$ kouknete se na www.cbl.cz
>
>
>Lada Myslik
>
> ------------------------------------------------------------------
> Vladimir Myslik  
>(if you experience delivery problems replying my mail, try the addresses 
>below)
>xmyslik@cslab.felk.cvut.cz , xmyslik@cs.felk.cvut.cz
>http://cs.felk.cvut.cz/~xmyslik/
>
>