Current Server Time: 08:29 (Central Europe)

#apertus IRC Channel Logs

2019/02/15

Timezone: UTC


02:22
RexOrCine
changed nick to: RexOrCine|away
03:08
BAndiT1983|away
changed nick to: BAndiT1983
04:47
parimal
joined the channel
05:27
futarisIRCcloud
left the channel
06:14
parimal
left the channel
06:30
BAndiT1983
changed nick to: BAndiT1983|away
06:51
se6astian|away
changed nick to: se6astian
07:17
se6astian
changed nick to: se6astian|away
07:17
se6astian|away
changed nick to: se6astian
07:26
BAndiT1983|away
changed nick to: BAndiT1983
07:43
futarisIRCcloud
joined the channel
09:06
Cyna_
joined the channel
09:35
LordVan
joined the channel
10:31
futarisIRCcloud
left the channel
11:52
BAndiT1983
changed nick to: BAndiT1983|away
12:07
vup2
BAndiT1983: is there a more detailed description of the current control daemon api than https://lab.apertus.org/T865 ?
12:23
BAndiT1983|away
changed nick to: BAndiT1983
12:25
BAndiT1983
vup2, which parts are you interested in? trying to bring wiki up to date and maybe to incorporate the protocol, as there will be 2 of them, for handshake and general usage
12:26
BAndiT1983
other than that, there is the Schema/ folder and corresponding schema file, which contains current state
12:32
vup2
so the communication is done using flatbuffers only?
12:32
vup2
is anything regarding the handshake protocol done already?
12:32
BAndiT1983
to/from daemon yes
12:33
vup2
i am guessing the handshake protocol does things like publishing what parameters are available?
12:33
BAndiT1983
some discussions, implementation is on the list as next task, after some tests of CMV config registers from command line
12:33
BAndiT1983
hope to do it in the next days at the hub or via ssh
12:33
LordVan
left the channel
12:34
BAndiT1983
handshake will use second structure, which will be extended by such properties, like min / max range
12:36
BAndiT1983
and this will be sent as bigger block of nested structures on first request
12:36
BAndiT1983
so the web UI knows what is available on the camera, like modules, parameters etc., also ranges, maybe also descriptions etc.
12:37
vup2
ok thats about what i had imagined
12:37
vup2
has there been any discussion regarding the names of certain parameters?
12:37
vup2
like gain and exposure time
12:38
BAndiT1983
currently there are 3 parameters, which are named analog_gain, digital_gain and config_register
12:38
BAndiT1983
we agreed on lower case and underscores
12:39
vup2
what i mean is, that every sensor should probably have some general registers
12:39
vup2
like gain, exposure time, framerate and so on
12:40
BAndiT1983
as we have only one binding at the moment, there is no base class for that yet
12:40
vup2
ok
12:40
BAndiT1983
but it's easy to add a base class, which can register some general methods to override
12:41
BAndiT1983
should i prepare it?
12:41
vup2
the context is that i have been writing a control daemon for the micro and it would make sense, if it implements the same protocol as the beta control daemon
12:43
BAndiT1983
i'm open for discussions, if you need infos or have suggestions
12:45
BAndiT1983
what have you implemented so far?
12:47
vup2
well we are lucky and have found a xml description of every (public) register of the sensor the micro uses at the moment (there seems to be such a description for every aptina / onsemi sensor)
12:47
BAndiT1983
nice
12:48
BAndiT1983
still thinking about adding a JSON file with settings, which will be used for handshake and current values filled in
12:48
vup2
so the current daemon can parsing that / converting it to yml and exposes all the registers over a fuse interface at the moment (the description is quite comprehensive and has min, max, description and format)
12:48
BAndiT1983
this requires some tests, to be sure that it covers our needs
12:49
BAndiT1983
how is the performance with FUSE?
12:50
vup2
performance seems ok at the moment, about ~10000 reads or writes per second
12:50
BAndiT1983
sounds not bad
12:51
vup2
at the moment i think a two level approach might work reasonably, a basic config format for the registers with min, max, address, format and description
12:51
BAndiT1983
what is required to control it from web UI? which communication can be used?
12:52
vup2
and everything which is more complicated like starting the sensor then uses these basic registers and is implemented as normal code
12:53
vup2
the web ui currently uses the flatbuffer api?
12:53
BAndiT1983
web UI uses websockets, which sends data to dedicated WSServer and this one sends the data to daemon
12:53
vup2
ah ok
12:54
BAndiT1983
same idea here, that certain routines can be executed through daemon, like init
12:54
vup2
so probably only implementing the flatbuffers api is what is missing, then the wsserver should be able to talk to the daemon
12:55
BAndiT1983
yep
12:56
BAndiT1983
https://github.com/apertus-open-source-cinema/axiom-control-daemon/blob/master/API_WS/MessageHandler.cpp
12:56
BAndiT1983
there is the JSON format at the top of the file
12:57
BAndiT1983
this is used to send and receive data to/from WSServer
12:57
BAndiT1983
more or less same as flatbuffers
12:57
BAndiT1983
but it was split, to prevent malicious usage or similar
12:59
vup2
yes looks reasonable
13:48
se6astian
vup2: can you extend the wiki: https://wiki.apertus.org/index.php/Control_Daemon with what you just talked about? I am sure others would benefit from this informationas well
13:49
siddhantsahu
vup2: Yes pl update the wiki
13:50
vup2
sure
14:04
BAndiT1983
changed nick to: BAndiT1983|away
14:11
se6astian
changed nick to: se6astian|away
14:12
se6astian|away
changed nick to: se6astian
14:26
se6astian
changed nick to: se6astian|away
14:27
se6astian|away
changed nick to: se6astian
14:53
se6astian
changed nick to: se6astian|away
16:13
sebix
left the channel
17:08
Kjetil
joined the channel
17:26
niemand
joined the channel
17:26
niemand
left the channel
17:26
niemand
joined the channel
17:52
Bertl_oO
off to bed now ... have a good one everyone!
17:52
Bertl_oO
changed nick to: Bertl_zZ
18:51
rohan_
joined the channel
18:51
rohan_
left the channel
19:00
RexOrCine|away
changed nick to: RexOrCine
19:08
rohan_
joined the channel
19:23
rohan_
For the T872 challenge, should the conversion from 12 bits data to 8 bits be done by scaling it down by some algorithm or by ignoring the 4 least significant bits from the 12 bits?
19:27
rohan_
left the channel
20:02
BAndiT1983|away
changed nick to: BAndiT1983
20:57
rohan_
joined the channel
21:09
rohan_
left the channel
22:25
Dev
joined the channel
22:37
Dev
left the channel
22:41
BAndiT1983
changed nick to: BAndiT1983|away