Johdanto-osan käyttämisellä manchesteri-koodatun datapaketin aloittamiseen on kaksi pääasiallista syytä:

1. Anna datanleikkaimen asettua. Manchesteria käytetään usein radiolinkkien ja fyysisten linkkien kautta, joissa ei ole suoraa yhteyttä ja korkean ja matalan tason välistä eroa ei nimenomaisesti tiedetä etupuolella. Tämä tarkoittaa yleensä, että anlogisignaali esitetään datanleikkurille , joka havaitsee ja välittää digitaalisten ylä- ja alamäiden sekvenssin.

   Yksi manchester-koodauksen ominaisuus, joka tekee siitä hyödyllisen tällainen linkki on, että se on keskimäärin 1/2 korkea ja 1/2 matala lyhyin väliajoin. Jokaisella bitillä on sama keskimääräinen taso 1/2. Tämä tekee tietojen viipaloinnista suhteellisen helppoa, koska se voi olla yksinkertainen vertailija 1/2 tasoon nähden. Tämä tarkoittaa kuitenkin, että sinun on tiedettävä, mikä on 1/2 taso. Vanhat vastaanottimet tekisivät tämän laitteistossa suodattamalla alipäästösuodatin manchester-virtaa. Tällaiset suodattimet eivät tarkoituksella reagoi paljon yhden bitin aikana, joten ota muutama bitti laskeutumaan. Johdanto sisältää heittää bittiä, joita vastaanottimen ei ole tarkoitus havaita oikein, kun sen tiedonsiirtäjä löytää 1/2 tason.

2. Ilmoita paketin alku. Koska useimmilla manchester-vastaanottimilla on olennaisesti automaattinen vahvistuksen hallinta 1/2 tason kautta, jota käytetään datan viipaloimiseen, kuten edellä on kuvattu, vastaanotin tulkitsee taustakohinan sarjana korkeita ja matalia tasoja aivan kuten todellinen signaali. Yleensä ei ole signaalia vastaanottimen digitaalisen virran tulkintaosalle, vain että virralla on merkitystä, kun on todellista signaalia.

   Manchester sisältää joitain tarpeettomia tietoja, jotta jotkut tasosekvenssit voivat havaitaan virheellisiksi suoraan ilman korkeamman tason tulkintaa. Esimerkiksi jokaisen bitin keskellä on oltava transistio. Kolme saman tason puolibittiä on laitonta, kuten esimerkiksi kaksi-yksi-kaksi.

   Vaikka paketin alkuasetusten palauttaminen aina, kun yllä olevan kaltainen rikkomus havaitaan, auttaa, satunnaisella roskapostilla on silti riittävästi mahdollisuuksia tehdä siitä edelleen paketti, johon useimmissa tapauksissa on puututtava. Et halua, että korkeammat tasot ovat syvällä pakettien dekoodauslogiikassa melusta, kun tulee todellinen paketti, joka näyttää vain enemmän tietoa väärältä paketilta. Lopulta väärä paketti todennäköisesti epäonnistuu paketin tarkistussummatestissä, mutta löysit silti todellisen paketin.

   Hyvä strategia on sitten tehdä johdannosta ainutlaatuinen sekvenssi, joka ei ole voimassa muussa paketissa . Kun tämä sekvenssi havaitaan, ylemmän tason pakettien tulkintalogiikka palautetaan paketin alkuun riippumatta siitä, mitä se ajatteli tekevänsä tuolloin.

   Teen tämän yleensä tavarabittimen avulla. Jos todelliset tiedot sisältävät esimerkiksi 7 0s peräkkäin, lähettimen on lisättävä 1 tavarabitti 0s jälkeen. Vastaanotin tietää tämän ja kuorii 1 bitin 7 peräkkäisen 0 bitin jälkeen. Tämä tarkoittaa, että koskaan ei ole 8 peräkkäistä 0 bittiä, mikä olisi hieman täyte-rikkomusta. Jos havaitaan vähän täytteen rikkomista, pakettien tulkintalogiikka voidaan palauttaa turvallisesti paketin alkuun, koska se ei todellakaan ollut kelvollisessa paketissa tuolloin. Johdanto sisältää tarkoituksellisesti tällaisen tavarabittirikkomuksen pakottaakseen tulkintalogiikan palauttamaan paketin alkuun.

   Tämä tavarabittimalli ja paketin alkuun palauttaminen ei ole tavallinen manchester, mutta jotain, jota haluan käyttää tehdä manchesteristä luotettavampi radion kaltaisissa linkeissä.

Manchester-koodauksessa on enemmän, kun ajattelet yksityiskohtia todella. Voit tehdä paljon nopeammin vastaavan datanleikkurin esimerkiksi digitaalisessa prosessorissa, jolloin voit käyttää muita keinoja kuin bittitäytteitä paketin alun luotettavan havaitsemiseen, mutta se on koko aihe itselleen.

Yksi Manchesterin tärkeimmistä eduista on se, että synkronointi molempien osapuolten välillä on helpompaa.

Manchesterin koodauksen helpottama synkronointityyppi on synkronointi bittitasolla , ei sana- tai pakettitasolla . Itse asiassa se ei auta lainkaan jälkimmäisessä. Ja siksi sinun on ehkä siirrettävä joitain tunnettuja bittejä ennen tietobittejäsi.

Se auttaa edellisessä (bittitason synkronointi), koska se helpottaa kellon palautusta.

Miksi minun on siis lähetettävä bittiä ennen siirtoa?

Joten ne auttavat sinua synkronoinnissa sana- / pakettitasolla. Manchesterin koodaus ei auta sinua tällä tasolla.

Manchester on koodausmenetelmä, ei protokolla, joka kuvaa paljon enemmän viestinnästä. Ethernet on protokolla, joka käyttää Manchesterin koodausta.

Manchesterin koodaus toimii bittitasolla, se näkee vain yhden yksittäisen bitin, se ei välitä edellisistä tai peräkkäisistä biteistä. Sillä ei ole väliä onko se ensimmäinen vai viides bitti, ja sellaisenaan se ei voi sanella lähettämään ylimääräisiä bittejä ennen siirron alkua.

Tarkoitat todennäköisesti sitä, että protokolla aloittaa paketin / sanan siirron tunnetulla sekvenssillä (myös Manchesterin koodatulla tavalla, joten tästä tulee ensimmäinen bitti).

Harkitse seuraavaa neljän negatiivisen menevän pulssin sarjaa:

\ $ \ mbox {1 1 1 1 1 0 1 0 1 0 1 0 1 1 1 1 1} \ $

Ei ole mitään tapaa tietää, onko kyseessä 0x0000 vai 0x1111 , eikä Manchester välitä siitä. Sinun on määriteltävä ylimääräisiä bittejä tietoihin, jotta voit purkaa ne. Esimerkiksi, jos protokollasi sanoo, että jokainen viesti alkaa 1 -bit johdannolla, sen on oltava 0x1111 . Useiden bittien johdanto helpottaa synkronointia, mutta heikentää myös kanavan tehokkuutta.
BTW, tällaiset sekvenssit, vain 1 s tai 0 s, ovat ainoat, jotka voivat Älä purkaa. Mikä tahansa sekvenssi, jolla on vähintään 1 1 ja 1 0 , voidaan dekoodata. Bittitäyte voi auttaa välttämään kaikkia 1 -merkkejä tai kaikkia 0 -malleja.
Jopa silloin johdanto on hyödyllinen, koska dekooderi pystyy tuottaa bittiä, kun ne vastaanotetaan. Ilman johdantoa data, kuten 0x0000001 , voidaan purkaa vain, kun 1 -bitti vastaanotetaan.

Johdanto ei kuitenkaan ole Manchesterin koodausvaatimus!

Manchesterin koodaus johtaa kaksivaiheiseen signaaliin: joko puoli bittiä aika matala, jota seuraa puoli vähän aikaa korkea (esimerkiksi looginen 1 ), tai puoli vähän aikaa korkea, jota seuraa puolibittinen aika matala (looginen 0 ). Se ei vaadi ylimääräisiä bittiä.

On mahdollista, että seuraava korkeampi protokollataso vaatii johdannon ennen todellisen hyötykuorman siirtämistä, mutta Manchester ei ole määritellyt sitä. Manchester vain käsittelee yksittäisten bittien koodausta, se ei tunne käsitteitä, kuten viestejä tai paketteja.

Tavallinen syy on antaa vastaanottimelle kellonaika synkronointiin / lukitsemiseen ennen varsinaisen datan saapumista. Tyypillisesti käytetään peräkkäisten ykkönen tai nollia.

Kun MIL-STD 1553 (avioniikkaväyläprotokolla) lähetetään 1,5-bittisiä jaksoja kestävä looginen (tai nolla). loogisella nollalla (tai yhdellä), joka kestää 1,5 bittiä. Tämä on itse asiassa Manchesterin koodin vastaista, mutta vastaanotin on helposti havaittavissa.

EM 4100 -protokollaa käyttävissä matalataajuisissa RFID-tunnisteissa datakehys alkaa otsikolla 9 Manchesteria. Synkronointi ei ole tässä kysymys, koska vastaanottimessa on jo kello (koska se säteilee sitä lähettävään tagiin). Data voi kuitenkin kääntyä, joten vastaanottimen on määritettävä napaisuus. Koska 9 peräkkäistä samaa polariteettia olevaa bittiä ei koskaan voi esiintyä todellisissa tiedoissa (pariteettibittien takia), otsikko voidaan havaita yksiselitteisesti yhtenä sarjana.

Nimeä vähintään 3 Manchester Code- tai Bi-Phase-menetelmää, a) Mark, Space, Transition

Nimeä vähintään 3 synkronointitasoa viestinnässä;

a) bittisynkronointi , b) sanasynkronointi (~ tavu) c) kehyssynkronointi

Mikä on optimaalinen kehyssynkronoinnille?

Ristikorrelaatiokoodi, jossa koodisanoilla on suuri ainutlaatuisuus synkronoituna vs. synkronointi. eli kuvion tunnistusjärjestelmä, joka on myös vähiten todennäköistä dataa.

Tämä on välttämätöntä, kun sarjabitit muunnetaan rinnakkaisiksi sanoiksi ja kehyssynkronoinniksi.Tämä tiesin 35 vuotta sitten, kun otin ensimmäisen kerran käyttöön SCADA-järjestelmän 70-luvun puolivälissä. Se on saattanut muuttua nyt. Kellon synkronointi voi olla yhtä yksinkertaista kuin XOR, jossa on 1 kuvan viive siirtymissä, jotta voidaan luoda ei-uudelleenkäynnistettävä kello, tai parempi PLL, jossa siirtymät näytteistävät erittäin vakaan VCXO: n käyttämällä sahanterän kellosignaalia ja datareunoja vaihevirran jännitteen ottamiseksi. Tietysti Bandpass-suodattimesi ja väliaineesi vievät värinää, joten sinun on opittava käyttämään korotettuja kosini-suodattimia, joissa bittisiirtymä on nolla. Bittivirhesuhde tai BER on kellosihottimen, kellon jitter & -vaihevirheen ja tietojesi värinän epäsymmetrian funktio. BER on suoraan ennustettavissa SNR: stä, ja vaihemarginaalitestit auttavat eristämään BER-ongelmiesi syyn käyttämällä pienennettyjä ja siirrettyjä aikaikkunoita pakottaaksesi kellosi pois keskuksesta ja tarkistamaan, ovatko tiedot edelleen kelvollisia.

Tämä on salainen menetelmä minkä tahansa marginaalisen viestintäjärjestelmän analysointiin. Hakeuduin SCADA-tietoliikenteeseen, telemenetelmään ilmailuun, kiintolevyn tietojen palauttamiseen ja Telecom T1 -päiviin.

(jos haluat lisätietoja sahahammasten VCO-näytteestä &-näytteen pitovirheestä tiedonsiirrosta .. kysy vain: p) yli 30 vuotta sitten suunnittelin, mutta luulen voivani tehdä sen vielä.

Se oli tietysti synkroninen kommunikointikanava .. Voit käyttää sitä myös ASYNC-kommunikointiin. ja ehkä sitä tarkoitit alustusosilla. . Käytin viipaleiden seurantasuodattimessa +/- huippu- ja pitotunnistimia.

Jos mikään näistä vastauksista ei toimi sinulle, kokeile toista kysymystä ....