Current Server Time: 08:08 (Central Europe)

#apertus IRC Channel Logs

2015/02/19

Timezone: UTC


23:34
g3gg0
left the channel
00:15
fsteinel_
joined the channel
00:18
fsteinel
left the channel
00:41
intracube
left the channel
00:52
g3gg0
joined the channel
01:58
yannick
left the channel
02:16
yannick
joined the channel
05:49
g3gg0
left the channel
05:56
ItsMeLenny
joined the channel
06:20
ItsMeLenny
left the channel
07:36
fsteinel_
changed nick to: fsteinel
08:28
S3bastian
joined the channel
08:34
S3bastian
good morning
08:39
Bertl
morning S3bastian!
09:05
Fitz
joined the channel
09:05
Bertl
hello Fitz!
09:06
Fitz
good morning all!
09:09
Fitz
Bertl, @cooling, is there an alternative to the ventilator?
09:11
Fitz
(heatpipes to case, etc...?) Ventilators are imho loud, they might cause problems when recording audio.,.Dust might also be an issue...
09:12
Bertl
there are always alternatives to the fan, peltier, heat pipes, water cooling, you name it
09:12
Fitz
are there any Temp.measurements of the Sensorchip ? How long should the sensor work?( clip lenght)
09:13
Bertl
yes, the cmosis sensors feature an uncalibrated sensor on the die
09:13
Bertl
for the clip lenth, I'd say a few seconds to a few days :)
09:14
Fitz
I´m just beginning to read about the temperature issues of this kind of sensors, I saw often a maximum clip lenght of 12 minutes due to the heat on the chip...
09:14
Bertl
*length
09:15
Bertl
it doesn't seem to be a limiting issue, although a rise in temperature increases the noise in a nonlinear way
09:16
magnus___
joined the channel
09:16
Fitz
did you measure the sensor temp while filming over some hours?.
09:16
Bertl
yep
09:16
S3bastian
sounds like a typical issue of still image cameras that are suddenly used to record video and the cooling was actually never designed for continous sensor operation
09:16
Fitz
where can I find this data, to aoid asking "stupid" questions?
09:17
Fitz
I mean the measurement data...
09:17
Bertl
well, the uncooled sensor got about 15-20 degrees over room temperature IIRC and with the simple fan cooling we did on the alpha, it stayed below 5-10 degrees over environment
09:18
Bertl
note that this was with 4k at 60FPS
09:19
magnus___
changed nick to: masplund
09:19
S3bastian
hi magnus :)
09:22
Fitz
ok, so we have 20 Kelvin to disipate...I´ll check some possibilities ;)
09:22
Fitz
left the channel
09:22
masplund
Hi! I'm online.
09:23
Bertl
masplund: welcome online!
09:23
S3bastian
welcome to the internet :D
09:24
masplund
ok, short introduction: I'm Magnus from af inventions, we will work with you on the gamma hardware!
09:25
S3bastian
it is and will be our pleasure
09:26
masplund
We are happy about it too. Official project start for EU in less than 1 month.
09:32
Bertl
so the right time to get comfy with IRC then :)
09:33
S3bastian
exactly
09:33
S3bastian
magnus will talk to nvidia next week at embedded world in nürnberg
09:33
S3bastian
about tegra and co.
09:33
S3bastian
and to PLX about PCIe swtiches
09:34
S3bastian
another thing he suggested today was potentially using CAN open as communication bus between modules
09:35
S3bastian
so far we considered LVDS pairs between modules for data transfer and SPI or i2c as communication bus
09:35
S3bastian
so I guess it would be time to make a table listing pros/cons of each option?
09:35
Bertl
yep, please do so
09:39
S3bastian
please check the google doc
09:39
S3bastian
now I am off lor lunch
09:39
S3bastian
bs
10:14
S3bastian
back
10:18
S3bastian
so about the table
10:18
S3bastian
what are the pros of SPI?
10:19
Bertl
simple, no direction switching, relatively high datarates possible
10:19
S3bastian
cons: spi is point to point right? would need a separate line/method to handle routing to/from multiple endpoints right?
10:20
Bertl
yes, another alternative would be jtag
10:20
Bertl
(which is similar but allows chaining)
10:21
S3bastian
and from the tech implementations SPI are 4 lines right?
10:22
Bertl
with SS/enable, yes
10:22
S3bastian
ok
10:22
Bertl
i.e. SDI,SDO,SCK,SS
10:22
S3bastian
any other cons beside the missing routing capabilities?
10:22
Bertl
with jtag it is also four lines, TDI,TDO,TMS,TCK
10:23
Bertl
routing is not handled by non packet protocols
10:24
Bertl
i.e. neither I2C nor JTAG have a concept of "routing"
10:24
S3bastian
addressing?
10:24
Bertl
I2C uses slave/broadcast addresses (see wikipedia)
10:24
Bertl
SPI uses the SS (slave select) for this purpose
10:25
S3bastian
ah ok, so both are by default for multiple endpoints, but the master has to be predefined right?
10:25
Bertl
JTAG allows for long chains and discovery, which in turn allows sending data to/from a specific point in the chain
10:25
Bertl
I2C allows for multimaster mode, specifically with the SMB (system management bus) variant
10:28
S3bastian
so in summary the functionality is all the same? :)
10:30
Bertl
different, but similar
10:32
S3bastian
that makes choosing tricky
10:33
S3bastian
well is CAN open much different?
10:33
Bertl
CAN is a protocol designed for the car
10:34
Bertl
it is a lot more complex than SPI or IIC
10:35
Bertl
it is also a multi-master bus system by design
10:38
S3bastian
added to table
10:39
S3bastian
so I guess since speed is in general not an issue for a communication bus in this application and expandability is there in all options the only difference that will really matter is simplicity?
10:40
Bertl
probably an important factor, also noise (emission and sensitivity) as well as electrical requirements are important IMHO
10:41
joro
joined the channel
10:41
masplund
Yes, CAN could be rather complex. It is very robust.
10:43
masplund
@Bertl: will you visit the embedded world fair?
10:43
Bertl
nope, no time at the moment
10:44
go2sh
joined the channel
10:45
cbohnens
joined the channel
10:45
Bertl
joro, go2sh, cbohnens: problem with the client?
10:46
cbohnens
seems my encoding is wrong, let me check
10:47
cbohnens
left the channel
10:47
joro
left the channel
10:48
joro
joined the channel
10:48
go2sh
left the channel
10:48
masplund
joro (Johannes), go2sh (Christoph) and cbohnens (Carsten) are colleagues from af inventions, they will be working on this project as well
10:48
cbohnens
joined the channel
10:48
S3bastian
welcome!
10:49
go2sh
joined the channel
10:50
cbohnens
thanks :)
10:51
cbohnens
left the channel
10:51
cbohnens
joined the channel
10:52
S3bastian
joro and cbohnens I just sent you invitations to the google doc
10:52
S3bastian
go2sh: I dont think I have your email address yet, please pm me
10:53
cbohnens
go2sh won't participate much in the project from our side, so I don't think he needs access
10:53
cbohnens
S3bastian: ^
10:54
S3bastian
ok
10:54
S3bastian
there are public logs of this channel btw
10:54
S3bastian
http://irc.apertus.org/
10:54
S3bastian
in case you want to read up on something
10:55
S3bastian
like today: http://irc.apertus.org/index.php?day=19&month=02&year=2015
10:56
masplund
Is this communication (I2C, SPI, JTAG, CAN or so) only for management data?
10:57
S3bastian
most likely yes
10:57
S3bastian
what else could we use it for?
10:57
masplund
I was just thinking of bandwidth/latency requirements
10:58
Bertl
the basic idea is to have a "simple" means of communication and module discovery
10:59
Bertl
let's say a module is plugged in, then the main system will need to know what module was added, and also be able to configure and control it
10:59
Bertl
this includes coordinating bandwidth allocation and high speed routing
11:00
Bertl
note that we are not limited to existing protocols, we could define our own, starting from layer 0, but it might help for addon modules to have something which is already handled in a cheap microcontroller
11:01
masplund
ok, I understand
11:02
Bertl
think of it like the AUX channel on (e)DP
11:04
Bertl
for example, if we decide to go for JTAG, we would simply add a mux/switch to each module slot to add the module to the chain (or to remove it, if there are problems, etc)
11:05
Bertl
in the case of I2C, we would need/want a switchable level converter to allow attaching/detaching the module to the bus and probably some n-port mux to avoid address collissions
11:05
masplund
Are these modules hot-swappable?
11:06
S3bastian
would be nice, but not a requirement
11:06
Bertl
if we can pull that off, why not :)
11:08
mars_
there are things like "Hot swappable I2C-bus and SMBus bus buffer"
11:08
mars_
with a little magic around, a module could be made hot swappable
11:10
masplund
For such management communication maybe CAN would be overkill. With JTAG, I2C the signal integrity tends to suffer when using backplanes and modules from different places, but I think one could handle that :-)
11:12
S3bastian
should the communication bus also deal with timing/syncing related issues?
11:12
S3bastian
some applications might require precise timing information exchange between sensor/module...
11:13
S3bastian
or is that a task better moved to one of the data lanes?
11:14
Bertl
I think for timing purposes we should provide a shared/buffered clock
11:16
S3bastian
noted
11:17
masplund
I agree, a separate line would be better.
11:17
masplund
In the google docs document there is a 3D rendering of PCBs, connectors, housing etc. Where does it come from? Is it a starting point?
11:17
Bertl
yup
11:21
S3bastian
it comes from me
11:21
S3bastian
its a start point concept
11:21
S3bastian
by giving a visual impression its often simpler to start discussions in my experience :)
11:21
masplund
nice work!
11:27
masplund
I'll have to leave now.
11:29
S3bastian
ok, thanks for stopping by
11:29
S3bastian
come here anytime :)
11:30
masplund
left the channel
11:42
ItsMeLenny
joined the channel
12:39
seku
joined the channel
12:51
Bertl
off for a nap .. bbl
12:51
Bertl
changed nick to: Bertl_zZ
12:54
ItsMeLenny
left the channel
13:17
se6astian|away
changed nick to: se6astian
13:32
joro_
joined the channel
13:32
joro_
left the channel
13:34
go2sh
left the channel
13:35
joro
left the channel
13:38
kgugala
left the channel
14:23
cbohnens
left the channel
15:00
S3bastian
bbl
15:00
S3bastian
left the channel
15:30
alesage
joined the channel
15:31
intracube
joined the channel
15:35
alesage
random question: do we have a testing software and/or program to validate the quality of images, i.e. anything more formal than a human review?
16:20
g3gg0
joined the channel
16:45
comradekingu
left the channel
16:55
seku
left the channel
17:22
se6astian
back
17:23
se6astian
alesage: we used imageJ or some imagemagick scripts together with gplot for some analysis
17:23
se6astian
do you have any particular analysis in mind?
17:26
alesage
se6astian, a question came up in another context about validating camera images, thought I'd ask here for inspiration :) , also might want to contribute a little
17:27
alesage
se6astian, is that code committed somewhere?
17:28
alesage
is joining the lab
17:35
se6astian
these were standard histogram extractions or value averaging, nothing sophisticated outside the scope of the measurements at the time
17:36
se6astian
for example I wrote a script that captures an exposure time list for +- 8 fstops
17:36
se6astian
measures the digital values in the center of the image
17:36
se6astian
averages them
17:37
se6astian
and plots it all into a response curve chart
17:37
se6astian
we will automate and commit those kind of scripts once the beta is operations
17:38
alesage
se6astian, ok I get a sense for what you're working on thanks
17:38
alesage
se6astian, let me browse a little and maybe I'll have questions
17:39
Bertl_zZ
changed nick to: Bertl
17:39
Bertl
back now ...
17:41
Bertl
alesage: I think the ML folks, specifically alexML, has done a lot of analysis in regard of sensor quality, if that is what you're thinking about
17:42
alesage
Bertl, thanks, will join ML
17:43
alesage
might extend to optics also, i.e. an MTF test and that sort of thing
17:44
Bertl
so that's an area you're interested in, I presume?
17:44
Bertl
(i.e. you want to work on)
17:45
alesage
well possibly so :) , have some visual science experience
17:47
Bertl
I think that devising reliable and reproduceable tests and analysis methods for the AXIOM devices is something very valuable
17:47
se6astian
agreed!
17:47
alesage
I'd have to agree :)
17:47
Bertl
if we manage to make them "self contained", that would be awesome
17:47
alesage
Bertl, a little more on that pls
17:48
Bertl
i.e. if the camera can do most of the tests without external tools, etc
17:48
Bertl
just with simple print outs or so
17:48
alesage
Bertl, ok hmm, like board-level?
17:49
se6astian
the scripts and imagemagick could be run inside the cameras linux distro for example
17:49
Bertl
I'm envisioning a self test and quality report which can be generated by the camera
17:49
Bertl
so for example, if you want to know how "noisy" your specific sensor is
17:49
se6astian
only external intervention could be "point camera at a constant light lit white wall for example
17:49
alesage
ok interesting
17:49
Bertl
you just start some kind of script/procedure which asks you to do a few simple things
17:50
Bertl
and you get a high quality analysis of the results
17:50
se6astian
it could even run as php/javascript on the cameras own webserver if you want to plot realtime data
17:50
Bertl
we have the big advantage that we do not need to hide anything :)
17:51
alesage
there are probably a few levels at which to test, hadn't considered in the camera itself, interesting
17:51
Bertl
for example, take the bad pixels
17:51
Bertl
most cameras paper over the fact that the sensor has defects
17:52
alesage
other factors you could measure in-camera?
17:52
Bertl
begins with the operating conditions over time
17:53
Bertl
i.e. we will be able to measure voltages and power consumption on a subsystem level
17:53
Bertl
as well as several temperatures and other interesting details
17:53
Bertl
those should probably go to a database and of course, need to be evaluated
17:54
Bertl
I'm also envisioning some kind of near failure detection
17:54
Bertl
i.e. if something "unusual" shows up, or certain health parameters are outside the usual (to be expected) range
17:55
mars_
"you have 10 minutes till meltdown"
17:55
Bertl
something like that, yeah :)
17:55
mars_
:)
17:55
Bertl
core meltdown -> eject :)
17:56
alesage
heh
17:56
Bertl
but that is only one aspect of many ...
17:57
alesage
right it sounds many projects springing from this suggestion :)
17:57
alesage
anyway let me have a look at what's there to begin
19:50
intracube
setting up a standardised test to measure MTF would be very useful
19:50
intracube
to see the effect of different pixel binning modes and debayering
20:16
niemand
joined the channel
20:25
comradekingu1
joined the channel
20:31
danieel
left the channel
20:47
derWalter
joined the channel
21:02
danieel
joined the channel
21:08
niemand
left the channel
21:50
se6astian
time for bed!
21:50
se6astian
good night
21:55
derWalter
left the channel
22:08
se6astian
changed nick to: se6astian|away
22:43
g3gg0
left the channel