#apertus IRC Channel Logs

off to bed now ... have a good one everyone!

I would take it out of the remote setup today and do some IR/UV filter tests

yes I'll but it will be late ?!

when exactly?

22:00 CEST

It may be later than that so take your time :)

xD

He's not allowed out after 6pm you see.

Good morning Bertl

lucky me :)

I tried what you said, so when two words are transmitted alternatively, they are received correctly but there are erroneous words received during change/transit from one word to another

So any suggestion where might the problem be?

Sync in which part

i.e. the receiver is leading or lagging behind on the data

after or in word formation right?

how do you word synchronize sender and receiver atm?

you have a generator, which starts to generate random data (as 8bit words) at some point

on the receiver side the 10bit codes are deserialized and then decoded to 8bit words

the 8bit words are then compared with 8bit words from the same generator

I am not comparing the generator, remember?

your constant values (or alternating values) are a generator as well

I have sort off unplugged the comapring module(BER calculation module) ie I am just priniting the data received. So I sent two words 165 and 211 alternatively 16 times each. On the receiver side, I saw that approx 8 times correct value is printed. When there is a change from 211 to 165 or vice versa , rubbish values are printed. Maybe this is due to direct connection of 60MHz data to 100MHz FT601 :/

you cannot simply 'connect' two clock domains

But it can't be due to direct connection of FT601 without async fifo, as when I connect counter to FT601 in similar way(60MHz connected to 100MHz without async fifo), I am able to see the counting on my PC.

well, what kind of clock domain crossing do you use?

So I can check majority values for testing

so you are expecting corrupted data in your tests?

from 60MHz to 100MHz, I'd expect half of the data to be crap

when the data doesn't change, it doesn't matter

Means I can only test BER with current setup?

because everytime the output value changes, you will have a high chance of bad data

Its frequency is 0.5 Hertz, so it remains constant for most of the times

I shouldn't have jumped to testing

note that lowering the clock rate doesn't really help things

(unless you set proper timing constraints)

Okay, this will be a lesson for me :)

you can do a handshake

sample it on the other clock domain and pass back a 'done' signal

e.g. if your data is generated at ~25MHz and the FT domain is at 100MHz, you can be sure that you will have at least one stable cycle

Ok thanks for correcting me!

https://github.com/kakashi-Of-Saringan/opencine/commits/dev

please write to RexOrCine in case anything with it needs on site interaction with it

OK, thanks se6astian :)

aSobhy: Note, I'll be away from the camera in the next hour onwards... but it appears to running fine.

good night

nn