Current Server Time: 17:11 (Central Europe)

#apertus IRC Channel Logs

2019/07/01

Timezone: UTC


04:19
Bertl_oO
off to bed now ... have a good one everyone!
04:19
Bertl_oO
changed nick to: Bertl_zZ
04:47
BAndiT1983|away
changed nick to: BAndiT1983
06:19
LemonDealer
joined the channel
06:35
BAndiT1983
changed nick to: BAndiT1983|away
06:44
comradekingu
left the channel
06:58
se6astian|away
changed nick to: se6astian
07:21
sebix
joined the channel
08:09
LemonDealer7
joined the channel
08:10
LemonDealer
left the channel
10:36
LemonDealer7
left the channel
13:05
Y_G
joined the channel
13:30
Bertl_zZ
changed nick to: Bertl
13:30
Bertl
morning folks!
13:35
se6astian
changed nick to: se6astian|away
14:00
RexOrCine|away
changed nick to: RexOrCine
14:02
danieel
left the channel
14:04
danieel
joined the channel
15:16
RexOrCine
changed nick to: RexOrCine|away
15:22
Y_G
Hi Bertl,Could you help me with what is the current requirement for LUT files
15:23
Y_G
Do we want to send them via daemon ?
15:28
Bertl
yes, we definitely want to upload them in a synchronized way
15:29
Bertl
so there should be some way to 'transfer' all the values to the daemon
15:29
Bertl
and then tell the daemon to update them via the memory space
15:29
Bertl
(ideally synchronized to the HDMI output)
15:32
Y_G
is this what an sample LUT file would look like https://pastebin.com/42r9k9xi
15:34
Bertl
a 'LUT file' format wasn't defined yet, so yes, it might look like that ... note that the current LUTs are 12->16 or 12->18 bit tables
15:34
Bertl
i.e. they are 4096 values of 16 or 18 bit
15:39
Nira|away
changed nick to: Nira
15:40
Y_G
Most files I found had 32768 lines with 3 values .Could you help me with what do these values mean
15:41
Bertl
the list you linked is a 3D lut, i.e. it describes a complete RGB -> XYZ mapping
15:42
Bertl
in our case, we do not have a 3D LUT yet, instead there are four different LUTs for each 'channel' and a matrix to remap them
15:42
Bertl
so a LUT file format, if it was designed, would probably need to list 4096 x 4 values
15:43
Bertl
but as I said, most LUTs are currently created by some kind of mathematical formular and then 'uploaded' to the LUT table registers
15:43
sebix
left the channel
15:45
Y_G
And instead we want values from out LUT file to fill up these registers ?
15:45
Bertl
we just want to fill those registers in a coordinated way via the daemon
15:46
Bertl
let me explain the purpose of the daemon in regard of config and registers
15:47
Bertl
there are huge number of different peripherials in the Beta which need to be 'adjusted' to make everything work as intended
15:47
Bertl
we have devices on I2C busses (yes, several of them)
15:47
Bertl
we have virtual devices with memory mapped regions created by the FPGA bitstream
15:48
Bertl
and we have PS peripherials connected to the ARM CPU
15:49
Bertl
in general, there is a problem if more than one 'user' or 'client' adjusts those registers or changes values of those peripherials
15:49
Bertl
so it needs a central orchestration, i.e. some control process (the daemon) which coordinates any changes to those registers or any access to those peripherials
15:50
Bertl
in addition to just preventing two 'clients' from accessing those registers at the same time (and causing huge provlems, maybe even lockups)
15:51
Bertl
it is also desireable to synchronize those changes with the FPGA image pipeline
15:51
Bertl
e.g. change sensor specific registers only when the sensor is not acquiring a new frame
15:51
Bertl
change HDMI output registers only during blanking, etc
15:55
Y_G
Ok ,Makes sense
15:55
Bertl
for almost all settings, we already have some scripts, and there is a good chance that developers want to write their own scripts
15:55
Y_G
Thanks :)
15:56
Fares
joined the channel
15:56
Bertl
so there needs to be some kind of interface which can be used from bash, python, etc
15:56
Bertl
as well as from C and other compiled languages
15:57
Bertl
for the LUT tables, I can imagine a number of interfaces which would work quite well
15:57
Bertl
for example the data could be transferred as simple ASCII format (like the one you pasted)
15:58
Bertl
this is perfectly fine for unix commands and the C program to generate the various computed LUTs can be easily adjusted to produce this file format
15:59
Bertl
which then can be simply piped into whatever CLI command or socket interface is available from the daemon side
15:59
Bertl
for the synchronization part it would be benificial to store the 'new' LUTs somewhere in the daemon and have some 'activate config' command to actually transfer them to the respective registers
16:02
Bertl
so, it's about meeting time, but sebastian is still away ...
16:02
Bertl
but he asked me to take over for him if he doesn't make it here
16:03
Bertl
so I'd say we give it another five minutes and then we start
16:03
Bertl
I'm sure you all have plenty to report this week ;)
16:10
Bertl
okay, please let me know if you want to report today
16:11
Bertl
(via PM, as usual)
16:12
Bertl
aSobhy already let me know that he cannot make the meeting today ('for some reason') and reported what he had done last week besides cleaning up stuff for the first evaluation
16:13
Bertl
he reported: 'I wrote the deserializer module for the machXO2 side' and 'Working on word alignment'
16:13
Bertl
so the first one to report today is Nira, please go ahead ...
16:13
Nira
hi everyone!
16:14
Nira
this week I have been working on interrupts, so coding PIC16 and making and improving basic code for making a debouncing test
16:15
intrac
left the channel
16:15
Nira
I have had some problems, but solved most of them. I'm improving a lot my knowledges about all this. I will keep working on it
16:16
intrac
joined the channel
16:16
Bertl
sounds good, any new code to look at?
16:17
Nira
not at the moment, but soon I will send you something more
16:18
Bertl
okay
16:19
Bertl
anything else to report?
16:19
Nira
that's it from me, thank you
16:20
Bertl
great! Fares please go ahead then
16:20
Fares
Hi everyone!
16:21
Fares
last week I have been working on Axi lite module to set and read lj92 parameters (height and width and huffman encoding values)
16:22
Fares
Also I have write simple module to gather some data when the core is running and access them as well via axi lite - to understand where the bottleneck.
16:22
Fares
and I tested them in the FPGA as well.
16:23
Bertl
excellent
16:24
Fares
actually both of them can be enabled or disabled via flags. lastly I started working on axi hp reader/writer, wrote them in migen and will continue working on them next week.
16:25
Fares
They only will be for testing purposes so configuration will be minimum.
16:25
Fares
that would be all. thank you!
16:25
BAndiT1983|away
changed nick to: BAndiT1983
16:25
Bertl
sounds good to me, thank you!
16:25
Bertl
apurvanandan[m]: you'r up ...
16:26
Bertl
*you're
16:26
apurvanandan[m]
Hi everyone
16:30
apurvanandan[m]
This week I spent major time on implementing the deserializer for machXO2 of usb plugin. As the machXO2 doesn't has a ISERDES, I went through all documentation available figured out how to use IDDRX4B primitive for deserializeing the data. Deserializer has been written and I am writing other modules and then I will test it on hardware.
16:31
apurvanandan[m]
This is what I did mostly this week, apart from giving little time to documentation
16:32
apurvanandan[m]
Thats all from my side
16:33
Bertl
okay, thanks!
16:33
Bertl
Y_G: please go ahead
16:34
Y_G
Hi all,
16:34
Y_G
This week didn't have much coding done as most of work was reading about gamma configuration and LUT tables.
16:34
Y_G
Tried moving the `set_gain.sh` functionality to daemon using the MemoryAdapter,haven't tested it yet as zbox was down(Will do it today).Most probably it would require rework as BAndiT1983 said it should probably use different packet(for data arrays) for sending the parameters.
16:35
Y_G
Work was also done to update the wiki about more sample DaemonCLI commands.
16:35
Y_G
That would be all from my side .
16:35
Bertl
okay, thanks!
16:36
Bertl
anybody else who would like to report?
16:37
niemand
joined the channel
16:38
Bertl
doesn't look like, so we don't have any info from dev and se6astian is still away ...
16:38
Bertl
thus we conclude the meeting for today.
16:38
BAndiT1983
Dev was working on OC frame server, wondering why he misses this meeting, will urge to attend IRC more
16:39
Bertl
aSobhy, apurvanandan[m]: we'll hold a metting tomorrow evening to discuss the first evaluation and further tasks
16:40
apurvanandan[m]
Yes okay
16:41
Bertl
so if there is anything to discuss while most of the students and mentors are here ... please go ahead
16:45
Fares
left the channel
16:49
Y_G
Nothing for now ,but will ping later for the LUT conf part .
16:49
Y_G
Off for now ,need to get somewhere .
16:49
Y_G
left the channel
16:52
Fares
joined the channel
17:07
se6astian|away
changed nick to: se6astian
17:09
se6astian
good evening
17:09
se6astian
sorry for the delay
17:16
anuejn
a bit late, but i will also report some stuff :)
17:17
anuejn
i was working on the axiom micro recorder lately
17:17
anuejn
it has now a converter tool which can debayer images and assemble them to an mp4 file
17:18
anuejn
also the preview is now configurable which is good for performance on low end devices which can use halfres debayering
17:19
anuejn
the tool is generally also interesting to you, apurvanandan[m] because maybe we want to implement a datasource for the usb3 plugin
17:20
anuejn
so that the recorder can directly be used with the beta
17:21
anuejn
the recorder is still lacking in some regards (e.g. performance, ux and a simple to use actual recording feature ;)) but that can be sorted out
17:23
apurvanandan[m]
Is the USB module attachable to the axiom micro? You mean the mp4 files will serve as data source from the axiom?'
17:26
anuejn
ah no it is only software :)
17:27
anuejn
https://github.com/axiom-micro/recorder
17:27
anuejn
no, it can ultimately output mp4 files
17:28
apurvanandan[m]
Okay, I will see if I can understand how it can be helpful
18:00
Fares
left the channel
18:01
Fares
joined the channel
18:08
Dev_
joined the channel
18:10
Dev_
Hello everyone. Sorry, I was outside at that time and away from Internet that's why couldn't attend the meet
18:13
Dev_
I am working on aviencode , I will try to resuse my code from oc_frameserver
18:14
Dev_
This will be done before in first half and then we will go for Fuse
18:16
Dev_
Using webclient now , its is looking cool :)
18:16
Dev_
Now
18:16
Nira
changed nick to: Nira|away
18:20
Dev_
left the channel
18:31
Nira|away
changed nick to: Nira
18:31
Bertl
changed nick to: Bertl_oO
18:32
Nira
changed nick to: Nira|away
18:34
niemand
left the channel
18:42
niemand
joined the channel
18:46
niemand
left the channel
18:46
niemand
joined the channel
18:56
niemand
left the channel
18:56
niemand
joined the channel
18:56
niemand
left the channel
18:56
niemand
joined the channel
19:41
Fares
left the channel
19:44
niemand
left the channel
19:44
Fares
joined the channel
19:56
Fares
left the channel
20:38
Y_G
joined the channel
21:04
BAndiT1983
hi Y_G, could you please create a task in trello, for evaluation of data blob packet
21:05
BAndiT1983
how many parameters at max do we need for general tasks? 3 or 4?
21:13
Y_G
Hi BAndiT1983, will create
21:14
Y_G
For now most work is done with 1/2 parameters.
21:16
Y_G
But with the last requirements
21:16
Y_G
1)"i2c set/get" through DaemonCLI requires 4 parameters
21:17
Spirit532
left the channel
21:17
Y_G
2) For gamma_config we need another data blob packet
21:17
Spirit532
joined the channel
21:20
BAndiT1983
Y_G, sounds fine, please go on, will try to assist in the next days, but am rather busy with my job at the moment
21:26
Y_G
So should we go with 3 different data packets for testing purpose now ?
21:26
Y_G
Data arrays and the blob
21:27
BAndiT1983
why 3?
21:27
BAndiT1983
we have one for general settings, max 4 params, second one for data blobs
21:28
BAndiT1983
what would be the third one?
21:28
Y_G
Oh ,if we are increasing to 4 parameters then only 2
21:30
BAndiT1983
as long as it's not getting out of meaningful boundaries, then we are free to adjust
21:30
BAndiT1983
as you'Ve discovered that we require 4 params to be able to check on i2c, then i would say that is max
21:31
BAndiT1983
either we take them as is and extend setter signatures or check on suitable methods like tuples, but everything should be kept as simple as possible, no need to get all too fancy with templates and whatnot
21:32
se6astian
changed nick to: se6astian|away
21:33
Y_G
Yup , lot of changes would have to be made to MessageHandler.Going to stick with basics for now ,once things are in place will work to make them better
21:35
BAndiT1983
not that many, at least for 4 params
21:35
BAndiT1983
have you understood the thing with packet header and payload?
21:38
Y_G
packet header would be an additional parameter in the daemon request ?
21:39
BAndiT1983
no, this would be an additional structure ->
21:40
BAndiT1983
you would have a header, which would tell the type of payload (enum) and maybe an attribute for payload size, but this has to be checked
21:40
BAndiT1983
and of course you would have payload, like current packet or new one for data blobs
21:41
BAndiT1983
just as example -> http://solace.com/wp-content/uploads/2016/05/solace-message_payload.png
21:42
BAndiT1983
header could hold general infos, e.g. module, command etc.
21:42
BAndiT1983
so you just have to split current packet in 2 suitable parts and extend header with enum
21:42
BAndiT1983
example for flatbuffers enums -> https://google.github.io/flatbuffers/md__schemas.html
21:47
BAndiT1983
off for today, see you
21:47
BAndiT1983
changed nick to: BAndiT1983|away
21:48
Y_G
Will have a look and update you with the procedure tomorrow
23:06
Y_G
left the channel