Clock regenerering fra tilfældigt signal

vide

e 5

v=E6re

mangler lidt mere info for at ku' gi' noget s=E6rligt konkret svar.

F=2Eeks : hvor mange ens bit kan der komme i tr=E6k? Skal du ha' en stabil clock l=E5st til de ~5Mbit/s eller skal du bare ha' fat i bits?

USB er 12Mbit/s og der er garanteret en skift i bit str=F8mmen mindst hver syvende bit periode. Det er nomal lavet med en 48MHz state maskine der ved hver flanke i bit str=F8mmen justerer sig ind p=E5 hvor midten af en bit er.=20

-Lasse

Det giver jeg da gerne :)

I princippet uendeligt mange, da signalet jo er stort set tilfældigt. Jeg ved godt at dette er et problem, men lad os bare antage at der kan komme N ens bit i træk; så kan jeg selv regne sandsynligheden ud bagefter for at det sker. :)

Egentlig skal jeg bare have fat i bit-strømmen (overført til PC). Så hvis du har en metode til dette uden at generere en clock først er det jo også fint. Jeg havde selv spekuleret på bare at oversample et par gange og derefter klare bithåndteringen i post-processering; men jeg kan kun (nemt/billigt) overføre 8 Mbps til PC så det bliver ikke den vilde oversampling (men muligvis nok nu jeg tænker over det?).

Jeps, kiggede selv på dette; umiddelbart virker det til at gå til, men problemet er så at det kræver et krystal der er meget tæt på den clock man er interesseret i.

Med venlig hilsen Preben

"Preben Mikael Bohn" skrev i en meddelelse news:44a24764$0$20306$ snipped-for-privacy@dread16.news.tele.dk...

Indeholder det pågældende signal kun data eller er det en kombination af data og clock?

Hvilke informationer indeholder signalet? Er det datapakker så du muligvis har noget preamble at kunne låse systemet fast på?

Overholder signalet nogle former for standarder som vi kan kigge på?

Serielporten bruger en metode med 16x oversampling, men det er muligvis lidt voldsomt i dit tilfælde. Men hvis du ikke kan trække klokken ud af signalet så bliver oversampling og lidt databehandling nok den eneste løsning.

Mvh. Rune Christensen

Kun data.

Der er ingen systematiske datapakker; det er effektivt set bare støj der er digitaliseret.

Nej.

Spørgsmålet er så om 8/5 (=1.6)x oversampling er nok... Ellers skal jeg nok ud og have fat i en hurtigere datagrabber.

Med venlig hilsen Preben

Hej Preben

"Bare" lav en high-speed udgave af denne:

PIC16F84 Based Morse Code Reader:

Citat: "...The rate adaptive algorithm responds quickly to code speed changes, so you can copy both halves of a QSO, even when the parties transmit at different rates..."

mvh/Glenn

Hej Preben

Kig på:

mvh/Glenn

Det ville så kræve at min frekvens ville blive 8 gange så høj (ca. 40 MHz); det skulle nok kunne klares på køkkenbordet hvis jeg kan finde et krystal der er tilpas tæt på den rigtige frekvens og kredse der kan klare fekvenserne (og kredsløbet da ikke er afhængigt af at det er en FPGA). I sidste ende er det nok nemmest bare at sætte en FPGA til det; men så er kravet om pris så ikke honoreret... :)

Med venlig hilsen Preben

Andet citat: "The decoder is designed for code speeds ranging from about

6 words per minute (WPM) to greater than 36 WPM". Der skal lidt mere til for at komme op på 5 Mbps... :-)

Med venlig hilsen Preben

Har du mulighed for at vise et diagram af det kredsløb som danner data strømmen?

Du kunne prøve at se om du kan finde en seriel til parallel converter som er hurtigt nok til det ønskede kredsløb.

f.eks. 74hc164 fra

den burde kunne køre op til 60MHz, så hvis du anvender en 40 MHz crystal osc til at drive den. Så vil du få en 8 bit datastrøm på 5 MHz, som du så skal have ind i computeren. Så hvis du med din datagrabber har en clock indgang så kan du dele de 40 MHz ned til 5 MHz som passer til den nye 8 bit datastrøm.

Mvh. Rune