Current Server Time: 04:01 (Central Europe)

#apertus IRC Channel Logs

2014/05/20

Timezone: UTC

1
00:47
FergusL
left the channel
2
01:29
FergusL
joined the channel
3
01:53
gwelkind
joined the channel
4
03:09
Bertl
back now ...
5
03:48
gwelkind
left the channel
6
06:27
intracube
joined the channel
7
07:37
intracube
left the channel
8
08:37
intracube
joined the channel
9
12:37
gcolburn
joined the channel
10
12:50
gcolburn
left the channel
11
13:12
Bertl
off for a nap ... bbl
12
13:51
aombk
joined the channel
13
14:02
mookyj
left the channel
14
14:14
aombk
left the channel
15
14:22
gcolburn
joined the channel
16
14:49
gcolburn
left the channel
17
16:06
Bertl
back now ...
18
16:35
se6astian
joined the channel
19
16:36
se6astian
good evening
20
18:51
se6astian
left the channel
21
18:56
se6astian
joined the channel
22
19:03
se6astian1
joined the channel
23
19:05
se6astian
left the channel
24
20:37
gustav-ans
joined the channel
25
20:48
gustav-ans
left the channel
26
22:02
se6astian1
time for bed
27
22:02
se6astian1
good night
28
22:02
mookyj
joined the channel
29
22:03
se6astian1
left the channel
30
22:21
mookyj
Hi I gave the cmv12k-adapter-v1.1 a look over onthe schematic you might add a termination resistor to the lvds clk in to the sensor. as to the board it appears that it is a work in progress?
31
22:23
mookyj
are there any assembly views? it is not clear as to how you are getting heat away from the sensor. Forgive my ignorance as I get up to speed
32
22:24
Bertl
http://iloveubuntu.net/pictures_me/Aximom%20Alpha%20second%20prototype%20main.jpg
33
22:25
Bertl
without cooling, the sensor gets about 50-55°C, 45°C below the sensor
34
22:26
Bertl
with cooling (the big fan) it stays about 4-5°C above room temperature
35
22:32
mookyj
any metal contacting back of sensor?
36
22:32
Bertl
nope, nothing there in the alpha
37
22:32
Bertl
we plan to put a peltier at the back of the sensor in gamma
38
22:33
Bertl
btw, thanks for spotting the missing termination!
39
22:33
mookyj
dark current doubles roughly every 3-4°C
40
22:34
mookyj
its the stuff one worries about onthe siicon side, some library IP for io's have termination, some don't
41
22:34
mookyj
LVDS io's are a significant structure on the pad frame
42
22:35
intracube
left the channel
43
22:43
mookyj
that big connector in the center keeps you from heatsinking away from the sensor
44
22:43
Bertl
correct
45
22:44
mookyj
if you could dump into a xilinx on same board you could greatly reduce pin count assuming that you could do all your post processing at a single port 14-20 bits (depends on where you allocate the LUT)
46
22:45
Bertl
hmm?
47
22:46
mookyj
with John's (Andon) socket you might have room to machine a piece to pull heat out
48
22:47
mookyj
ah I went back and looked you don't use all the ports on the sensor
49
22:47
Bertl
currently not, this will change in the future (i.e. for gamma)
50
22:48
mookyj
there are so many tradeoffs for each solution, personally I have wanted to do a large format module head forever, and Panavision would never go for it
51
22:49
Bertl
but I'm not sure I can follow you with the 'dump into a xilinx'
52
22:49
mookyj
much easy to do that, and design the rest of the camera seperately, conquering the unique design issues
53
22:49
mookyj
my term for pulling all the data off the sensor
54
22:50
Bertl
well, that's what we do with 'the xilinx'
55
22:50
mookyj
get it off quickly then consolidate where you can to reduce complexity downstream
56
22:50
mookyj
could be any large fpga
57
22:50
Bertl
the sensor is directly connected to the zynq
58
22:51
Bertl
what would be the advantage to add another FPGA before that?
59
22:51
mookyj
if the fpga is right next to the sensor, you drive much shorter lines at 300-400mhz
60
22:51
mookyj
possibly
61
22:51
Bertl
okay, but I still have to get the data to the zynq then
62
22:53
mookyj
it is my thought that if the front end module grabbed the data, did the basic corrections unique to the sensor, then sent iot to the main board camera, you could design a camera that would adapt much easier to other sensor platforms
63
22:53
Bertl
but it would also consume twice the power, cost more money, produce more heat?
64
22:54
mookyj
yes your would, but you could in a way standardize the frame data, and use the Zynq to handle the camera functions, formatting, and outputs that are required
65
22:54
mookyj
probably not double. but likely more
66
22:55
Bertl
okay, but I don't see an advantage there ATM
67
22:55
mookyj
it would take some looking looking at the overall system to see what goes on be clock, per instruction to see if any savings owuld occur
68
22:57
mookyj
I am looking at it purely as getting data to something more universal, and reduce the signal loops at the sensor
69
22:57
mookyj
oops mis type; per clock
70
22:57
Bertl
we would have to process the same amount of data in any case
71
22:58
mookyj
anyway just a thought
72
22:58
Bertl
it just would get sent over LVDS twice
73
22:58
mookyj
well maybe, depends on where you combine the ports
74
22:58
Bertl
combine what ports?
75
22:59
mookyj
you have two 16bit ports from the sensor correct
76
22:59
Bertl
the sensor has 64 LVDS pairs in full conenction, we use 32 pairs in our setup
77
23:00
Bertl
16 top, 16 bottom
78
23:00
Bertl
each transfers up to 12 bit of a pixel from two rows
79
23:02
mookyj
this may make a better solution should you go 64, as you can combine reduce downstream pairs,m however i am not sure what limitations there may be on the processing side
80
23:02
mookyj
all good on paper :)
81
23:03
Bertl
well, it would require higher LVDS rates, so more power in the transfer, but less pins
82
23:03
mookyj
well I have to get home for dinner, thanks for the info, and helping me understand a bit more of the project
83
23:03
mookyj
agree on pwer
84
23:03
Bertl
no problem! thanks for looking into it
85
23:04
mookyj
Let me know when and where I can help!
86
23:04
Bertl
will do
87
23:05
mookyj
left the channel
88
23:21
Bertl
off to bed now ... have a good one everyone!