#apertus IRC Channel Logs

good morning

good morning all!

(heatpipes to case, etc...?) Ventilators are imho loud, they might cause problems when recording audio.,.Dust might also be an issue...

are there any Temp.measurements of the Sensorchip ? How long should the sensor work?( clip lenght)

for the clip lenth, I'd say a few seconds to a few days :)

*length

yep

where can I find this data, to aoid asking "stupid" questions?

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

ok, so we have 20 Kelvin to disipate...I´ll check some possibilities ;)

Hi! I'm online.

welcome to the internet :D

it is and will be our pleasure

so the right time to get comfy with IRC then :)

magnus will talk to nvidia next week at embedded world in nürnberg

and to PLX about PCIe swtiches

so far we considered LVDS pairs between modules for data transfer and SPI or i2c as communication bus

yep, please do so

now I am off lor lunch

back

what are the pros of SPI?

cons: spi is point to point right? would need a separate line/method to handle routing to/from multiple endpoints right?

(which is similar but allows chaining)

with SS/enable, yes

i.e. SDI,SDO,SCK,SS

with jtag it is also four lines, TDI,TDO,TMS,TCK

i.e. neither I2C nor JTAG have a concept of "routing"

I2C uses slave/broadcast addresses (see wikipedia)

ah ok, so both are by default for multiple endpoints, but the master has to be predefined right?

I2C allows for multimaster mode, specifically with the SMB (system management bus) variant

different, but similar

well is CAN open much different?

it is a lot more complex than SPI or IIC

added to table

probably an important factor, also noise (emission and sensitivity) as well as electrical requirements are important IMHO

Yes, CAN could be rather complex. It is very robust.

nope, no time at the moment

seems my encoding is wrong, let me check

joro and cbohnens I just sent you invitations to the google doc

go2sh won't participate much in the project from our side, so I don't think he needs access

ok

http://irc.apertus.org/

like today: http://irc.apertus.org/index.php?day=19&month=02&year=2015

most likely yes

I was just thinking of bandwidth/latency requirements

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

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

think of it like the AUX channel on (e)DP

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

would be nice, but not a requirement

there are things like "Hot swappable I2C-bus and SMBus bus buffer"

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 :-)

some applications might require precise timing information exchange between sensor/module...

I think for timing purposes we should provide a shared/buffered clock

I agree, a separate line would be better.

yup

its a start point concept

nice work!

ok, thanks for stopping by

alesage: we used imageJ or some imagemagick scripts together with gplot for some analysis

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

for example I wrote a script that captures an exposure time list for +- 8 fstops

averages them

we will automate and commit those kind of scripts once the beta is operations

se6astian, let me browse a little and maybe I'll have questions

back now ...

Bertl, thanks, will join ML

so that's an area you're interested in, I presume?

well possibly so :) , have some visual science experience

agreed!

if we manage to make them "self contained", that would be awesome

i.e. if the camera can do most of the tests without external tools, etc

Bertl, ok hmm, like board-level?

I'm envisioning a self test and quality report which can be generated by the camera

only external intervention could be "point camera at a constant light lit white wall for example

you just start some kind of script/procedure which asks you to do a few simple things

it could even run as php/javascript on the cameras own webserver if you want to plot realtime data

there are probably a few levels at which to test, hadn't considered in the camera itself, interesting

most cameras paper over the fact that the sensor has defects

begins with the operating conditions over time

as well as several temperatures and other interesting details

I'm also envisioning some kind of near failure detection

"you have 10 minutes till meltdown"

:)

heh

right it sounds many projects springing from this suggestion :)

setting up a standardised test to measure MTF would be very useful

time for bed!