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