Dekódování dat

Zpráva

fcharlief · #1 Příspěvek od **fcharlief** » 01 úno 2014, 10:58

Ahoj, potřeboval bych vytvořit čtečku dat ze zařízení, které vysílá infračerveně a cyklicky bez přestávky.

V zařízení se nacházi EEPROM, ze které jsou vysílána data "tak jak jsou" přes infraledky. Pokud se podívám osciloskopem, vidím jednotlivé byte, ale nemůžu je přečíst.

Přenosový rámec je velmi podobný klasické RS232 při nastavení 8N1 9600, ale pokud se snažím takto přečíst, jsem neúspěšný.

Otázka: Musí být v protokolu RS232 mezi STOP bitem a novým START bitem mezera? Můj názor je, že je datový rámec tohoto přenosu pouze podobný s RS232, ale takto číst nejde. Jakým způsobem by zde sériový kanál poznal, že zrovna "toto" je začátek nového byte? Může mi toto tvrzení někdo potvrdit nebo vyvrátit?

Přiložil jsem fotografii osciloskopu (mám bohužel analog bez paměti) a vyznačil v jednotlivé byte. Na fotografii chybí ze začátku a konce byte 255, je to znázorno jako spojitá čára se stop bitem na konci.

Děkuji,
Karel

Zmije · #2 Příspěvek od **Zmije** » 01 úno 2014, 11:39

Pokud se u RS232 vysílají rámce těsně zasebou, bez větší mezery, tak v závislosti na přenášených datech může dojít k falešné synchronizaci, tzn. že přijímač není schopen přesně určit co je start/stop bit a co data.

ZdenekHQ · #3 Příspěvek od **ZdenekHQ** » 01 úno 2014, 12:28

Pokud se to synchronizuje tou hodnotou 255, pak se krátké pakety dat takto přenášet dají.

procesor · #4 Příspěvek od **procesor** » 01 úno 2014, 14:26

Prijímač musí byť ready pred zahájením vysielania. Dovtedy vysielač musí mať na výstupe úroveň stop-bitu. Žiadalo by si to aspoň jeden riadiaci signál. Prijímač oznamuje vysielaču pripravenosť prijímať.

Jenda_KL · #5 Příspěvek od **Jenda_KL** » 01 úno 2014, 15:24

Hlavně na konci je další start-bit, takže celkem přečteno uartem bude 7B. Ta koncová mezera úrovně stop-bitu musí být tedy delší než 1B aby stihl reciver za 7B správně zastavit.
Absence mezery mezi stop-start není kritická, pokud jsou rychlosti srovnatelné, což třeba nejsou vlivem nepřesnosti použitého zdroje hodin a to i třeba v závislosti na teplotě.
Možná i proto se používají 2 stop-bity.
Bez znalosti na čom je to přijímané, jak je to zapojené a co je výsledkem příjmu se dál nehneme.

Jenda_KL · #6 Příspěvek od **Jenda_KL** » 01 úno 2014, 15:29

Zmije píše:.. přijímač není schopen přesně určit co je start/stop bit a co data.

Přijímač považuje za start-bit cokoliv kdykoliv po vypršení doby (start-bit+8databit+případná parita). stop generuje vysílač a přijímač nijak nekontroluje, respektive stopbit je ta pauza mezi vysíláníma.

edit: Ještě že jsem se do toho tak pěkně zamotal. Pokud je tedy po vypršení té doby linka ve stavu stop, odblokuje se reciver a čeká na start.

fcharlief · #7 Příspěvek od **fcharlief** » 01 úno 2014, 18:33

Vysílající zařízení by se dalo popsat jako IR vysílač ve venkovním prostředí, který vysílá nepřetržitě tento krátký řetězec. Problém je, že v jeho dosahu můžu být třeba jen 2-3s a data se musí přenést. Jedná se tedy o komerční výrobek, který já musím testovat. Rád bych si zjednodušil práci a vyrobil čtečku s textovým LCD, která vypíše informace v blízkosti. Víc přiblížit bohužel situaci nesmím.

Nemůžu tedy přidat žádný řídící signál a ani změnit protokol. Potřebuji vyhodnotit tento řetězec tak jak je. Nemůžu ani ovlivnit kdy začne vysílání, do dosahu zařízení se dostanu vždy v jiný okamžik. V komerční čtečce (kterou bohužel nemůžu mít trvale) je na dekodovaní IR demodulátor a jde na Rx nohu procesoru. Proto mě udivuje, že nelze data vyhodnotit sériákem a ani naprogramovaný PIC jim též nerozumí. Měl by někdo ještě jiný nápad? V nejhorším případě napíšu kód kde bude synchronizace se spádovou hranou po bytu 255.

Díky,
Karel

p32 · #8 Příspěvek od **p32** » 01 úno 2014, 18:51

fcharlief píše:
Přenosový rámec je velmi podobný klasické RS232 při nastavení 8N1 9600, ale pokud se snažím takto přečíst, jsem neúspěšný.

Otázka: Musí být v protokolu RS232 mezi STOP bitem a novým START bitem mezera?

Není důvod, proč by tam musela být. Lze to přečíst tak jak to leze. Ale ty jsi vůbec nenapsal, proč ti to nejde přečíst a ani čím nebo jak se to snažíš číst.

ZdenekHQ · #9 Příspěvek od **ZdenekHQ** » 01 úno 2014, 19:16

Ten poslední start bit může znamenat další byte "255" plus stop bit, já tam žádný problém nevidím a mezery netřeba.

Správně řečeno je tam v klidu logická 1 jako na UARTu, start bit je 0, stop bit je 1, 8 bitů, a podle mě to sedí. Delší stop bit ničemu nevadí.

fcharlief · #10 Příspěvek od **fcharlief** » 01 úno 2014, 20:39

Snažím se to přečíst pomocí IR demodulátoru, ten má na výstupní noze 10k pull-up rezistor a jde do max232. Výstup z demodulátoru je sejmut osciloskopem a je na fotce. V klidu (pokud je vysílač mimo demodulátor) je výstup v LOG1.

Čtu to pomocí Term95 a mnou napsaným prográmkem, výsledek je stejný. Leze z toho hatmatilka..

Teoreticky bych mohl špatně odhadnout přenosovou rychlost. Odhadnul jsem jí podle délky jednoho bite na osciloskopu. (1 / 0.000105).

Mohu poprosit o objasnění jak tedy pozná sériák jednotlivé datové rámce pokud není přítomna mezera? Představuji si to jako změtici jedniček a nul co jdou za sebou a jelikož je mezi znaky stejná mezera, netuším jak to pozná.

ZdenekHQ · #11 Příspěvek od **ZdenekHQ** » 01 úno 2014, 22:40

Sériák to nepozná, pokud mu nesedí pozice-úrovně start a stop bitů, ohlásí chybu rámce či jak se to jmenuje. Pokud se ztratí, chytí se až na, jak říkáš, pauze.

To zařízení může používat vlastní krystaly a přenosová rychlost vůbec nemusí být standartní, takže to na pár bytech ujede...

Navíc podobná zařízení někdy používají složitější kódování, jako třeba Manchester, a ta podoba s UART může být čistě náhodná, i když tady to na to nevypadá.

fcharlief · #12 Příspěvek od **fcharlief** » 02 úno 2014, 00:16

ZdenekHQ píše:Sériák to nepozná, pokud mu nesedí pozice-úrovně start a stop bitů, ohlásí chybu rámce či jak se to jmenuje. Pokud se ztratí, chytí se až na, jak říkáš, pauze.

To zařízení může používat vlastní krystaly a přenosová rychlost vůbec nemusí být standartní, takže to na pár bytech ujede...

Navíc podobná zařízení někdy používají složitější kódování, jako třeba Manchester, a ta podoba s UART může být čistě náhodná, i když tady to na to nevypadá.

Složité kódování zde nebude určitě. Jelikož vím co vlastně mám přečíst, kódování je celkem vidět z osciloskopu. Data jsou shodná s EEPROM v desce 1:1. Jestli myslíš hodinový krystal, tak MCU je taktován na 8.432MHz. Jeslti se mohu zeptat, jaký bys navrhoval postup čtení ty?

Díky

petrfilipi · #13 Příspěvek od **petrfilipi** » 02 úno 2014, 08:44

Víš aspoň jeden byte, který má ve zprávě být? Nebo to jsou náhodná data?
Jako částečné řešení bych viděl přijimát jednotlivé bity a ty pak ručně napasovat do rámce tak, aby bezi nimi byly bity 10.
Prostě bity ukládat a ukládat (pokud víš nějakou délku, pak uložít 2x tolik bitů), pak najít první výskyt 10 a zkontrolovat, zdali za dalších 8 bitů je taky 10 atd.
Jenže se stejně může stát, že když vysílač bude cyklycky vysílat 10101010 10 10101010 10 10101010 10, tak to stejně nezasynchronizuješ. Potřeboval bys vědět aspoň jeden byte, který by pořád ve zprávě byl. Ten pak použít jako synchronizační (za ním musí být 10) a už jedeš.
Teď jsem koukal, že na obrázku se dva byty opakují (je to ten 3. a 6. - dejme tomu hodnota 170) - ty se opakují stále?
Ale budeš muset programově zjistit délku jednoho bitu, abys poznal více bitů stejné hodnoty za sebou.

Ať se daří.
Petr Filipi

p32 · #14 Příspěvek od **p32** » 02 úno 2014, 09:29

Mimochodem, ta tvoje definice start bitu, 8 bitů a stop bitu je divná. Jak jsi přišel na to, že to tak má být ? Nemůže to být posunuto např. o 1 nebo 2 bity doleva ?

petrfilipi · #15 Příspěvek od **petrfilipi** » 02 úno 2014, 09:39

p32 píše:Jak jsi přišel na to, že to tak má být ? Nemůže to být posunuto např. o 1 nebo 2 bity doleva ?

Když ví co má přečíst, tak to asi u vzorlu dat může napasovat do rámce správně.

PF