Current Server Time: 19:21 (Central Europe)

#apertus IRC Channel Logs

2019/02/15

Timezone: UTC


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