Current Server Time: 07:15 (Central Europe)

#apertus IRC Channel Logs

2019/07/01

Timezone: UTC


05:19
Bertl_oO
off to bed now ... have a good one everyone!
05:19
Bertl_oO
changed nick to: Bertl_zZ
05:47
BAndiT1983|away
changed nick to: BAndiT1983
07:19
LemonDealer
joined the channel
07:35
BAndiT1983
changed nick to: BAndiT1983|away
07:44
comradekingu
left the channel
07:58
se6astian|away
changed nick to: se6astian
08:21
sebix
joined the channel
09:09
LemonDealer7
joined the channel
09:10
LemonDealer
left the channel
11:36
LemonDealer7
left the channel
14:05
Y_G
joined the channel
14:30
Bertl_zZ
changed nick to: Bertl
14:30
Bertl
morning folks!
14:35
se6astian
changed nick to: se6astian|away
15:00
RexOrCine|away
changed nick to: RexOrCine
15:02
danieel
left the channel
15:04
danieel
joined the channel
16:16
RexOrCine
changed nick to: RexOrCine|away
16:22
Y_G
Hi Bertl,Could you help me with what is the current requirement for LUT files
16:23
Y_G
Do we want to send them via daemon ?
16:28
Bertl
yes, we definitely want to upload them in a synchronized way
16:29
Bertl
so there should be some way to 'transfer' all the values to the daemon
16:29
Bertl
and then tell the daemon to update them via the memory space
16:29
Bertl
(ideally synchronized to the HDMI output)
16:32
Y_G
is this what an sample LUT file would look like https://pastebin.com/42r9k9xi
16: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
16:34
Bertl
i.e. they are 4096 values of 16 or 18 bit
16:39
Nira|away
changed nick to: Nira
16:40
Y_G
Most files I found had 32768 lines with 3 values .Could you help me with what do these values mean
16:41
Bertl
the list you linked is a 3D lut, i.e. it describes a complete RGB -> XYZ mapping
16: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
16:42
Bertl
so a LUT file format, if it was designed, would probably need to list 4096 x 4 values
16: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
16:43
sebix
left the channel
16:45
Y_G
And instead we want values from out LUT file to fill up these registers ?
16:45
Bertl
we just want to fill those registers in a coordinated way via the daemon
16:46
Bertl
let me explain the purpose of the daemon in regard of config and registers
16:47
Bertl
there are huge number of different peripherials in the Beta which need to be 'adjusted' to make everything work as intended
16:47
Bertl
we have devices on I2C busses (yes, several of them)
16:47
Bertl
we have virtual devices with memory mapped regions created by the FPGA bitstream
16:48
Bertl
and we have PS peripherials connected to the ARM CPU
16:49
Bertl
in general, there is a problem if more than one 'user' or 'client' adjusts those registers or changes values of those peripherials
16: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
16:50
Bertl
in addition to just preventing two 'clients' from accessing those registers at the same time (and causing huge provlems, maybe even lockups)
16:51
Bertl
it is also desireable to synchronize those changes with the FPGA image pipeline
16:51
Bertl
e.g. change sensor specific registers only when the sensor is not acquiring a new frame
16:51
Bertl
change HDMI output registers only during blanking, etc
16:55
Y_G
Ok ,Makes sense
16: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
16:55
Y_G
Thanks :)
16:56
Fares
joined the channel
16:56
Bertl
so there needs to be some kind of interface which can be used from bash, python, etc
16:56
Bertl
as well as from C and other compiled languages
16:57
Bertl
for the LUT tables, I can imagine a number of interfaces which would work quite well
16:57
Bertl
for example the data could be transferred as simple ASCII format (like the one you pasted)
16: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
16:59
Bertl
which then can be simply piped into whatever CLI command or socket interface is available from the daemon side
16: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
17:02
Bertl
so, it's about meeting time, but sebastian is still away ...
17:02
Bertl
but he asked me to take over for him if he doesn't make it here
17:03
Bertl
so I'd say we give it another five minutes and then we start
17:03
Bertl
I'm sure you all have plenty to report this week ;)
17:10
Bertl
okay, please let me know if you want to report today
17:11
Bertl
(via PM, as usual)
17: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
17:13
Bertl
he reported: 'I wrote the deserializer module for the machXO2 side' and 'Working on word alignment'
17:13
Bertl
so the first one to report today is Nira, please go ahead ...
17:13
Nira
hi everyone!
17:14
Nira
this week I have been working on interrupts, so coding PIC16 and making and improving basic code for making a debouncing test
17:15
intrac
left the channel
17: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
17:16
intrac
joined the channel
17:16
Bertl
sounds good, any new code to look at?
17:17
Nira
not at the moment, but soon I will send you something more
17:18
Bertl
okay
17:19
Bertl
anything else to report?
17:19
Nira
that's it from me, thank you
17:20
Bertl
great! Fares please go ahead then
17:20
Fares
Hi everyone!
17: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)
17: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.
17:22
Fares
and I tested them in the FPGA as well.
17:23
Bertl
excellent
17: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.
17:25
Fares
They only will be for testing purposes so configuration will be minimum.
17:25
Fares
that would be all. thank you!
17:25
BAndiT1983|away
changed nick to: BAndiT1983
17:25
Bertl
sounds good to me, thank you!
17:25
Bertl
apurvanandan[m]: you'r up ...
17:26
Bertl
*you're
17:26
apurvanandan[m]
Hi everyone
17: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.
17:31
apurvanandan[m]
This is what I did mostly this week, apart from giving little time to documentation
17:32
apurvanandan[m]
Thats all from my side
17:33
Bertl
okay, thanks!
17:33
Bertl
Y_G: please go ahead
17:34
Y_G
Hi all,
17:34
Y_G
This week didn't have much coding done as most of work was reading about gamma configuration and LUT tables.
17: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.
17:35
Y_G
Work was also done to update the wiki about more sample DaemonCLI commands.
17:35
Y_G
That would be all from my side .
17:35
Bertl
okay, thanks!
17:36
Bertl
anybody else who would like to report?
17:37
niemand
joined the channel
17:38
Bertl
doesn't look like, so we don't have any info from dev and se6astian is still away ...
17:38
Bertl
thus we conclude the meeting for today.
17:38
BAndiT1983
Dev was working on OC frame server, wondering why he misses this meeting, will urge to attend IRC more
17:39
Bertl
aSobhy, apurvanandan[m]: we'll hold a metting tomorrow evening to discuss the first evaluation and further tasks
17:40
apurvanandan[m]
Yes okay
17:41
Bertl
so if there is anything to discuss while most of the students and mentors are here ... please go ahead
17:45
Fares
left the channel
17:49
Y_G
Nothing for now ,but will ping later for the LUT conf part .
17:49
Y_G
Off for now ,need to get somewhere .
17:49
Y_G
left the channel
17:52
Fares
joined the channel
18:07
se6astian|away
changed nick to: se6astian
18:09
se6astian
good evening
18:09
se6astian
sorry for the delay
18:16
anuejn
a bit late, but i will also report some stuff :)
18:17
anuejn
i was working on the axiom micro recorder lately
18:17
anuejn
it has now a converter tool which can debayer images and assemble them to an mp4 file
18:18
anuejn
also the preview is now configurable which is good for performance on low end devices which can use halfres debayering
18:19
anuejn
the tool is generally also interesting to you, apurvanandan[m] because maybe we want to implement a datasource for the usb3 plugin
18:20
anuejn
so that the recorder can directly be used with the beta
18: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
18: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?'
18:26
anuejn
ah no it is only software :)
18:27
anuejn
https://github.com/axiom-micro/recorder
18:27
anuejn
no, it can ultimately output mp4 files
18:28
apurvanandan[m]
Okay, I will see if I can understand how it can be helpful
19:00
Fares
left the channel
19:01
Fares
joined the channel
19:08
Dev_
joined the channel
19:10
Dev_
Hello everyone. Sorry, I was outside at that time and away from Internet that's why couldn't attend the meet
19:13
Dev_
I am working on aviencode , I will try to resuse my code from oc_frameserver
19:14
Dev_
This will be done before in first half and then we will go for Fuse
19:16
Dev_
Using webclient now , its is looking cool :)
19:16
Dev_
Now
19:16
Nira
changed nick to: Nira|away
19:20
Dev_
left the channel
19:31
Nira|away
changed nick to: Nira
19:31
Bertl
changed nick to: Bertl_oO
19:32
Nira
changed nick to: Nira|away
19:34
niemand
left the channel
19:42
niemand
joined the channel
19:46
niemand
left the channel
19:46
niemand
joined the channel
19:56
niemand
left the channel
19:56
niemand
joined the channel
19:56
niemand
left the channel
19:56
niemand
joined the channel
20:41
Fares
left the channel
20:44
niemand
left the channel
20:44
Fares
joined the channel
20:56
Fares
left the channel
21:38
Y_G
joined the channel
22:04
BAndiT1983
hi Y_G, could you please create a task in trello, for evaluation of data blob packet
22:05
BAndiT1983
how many parameters at max do we need for general tasks? 3 or 4?
22:13
Y_G
Hi BAndiT1983, will create
22:14
Y_G
For now most work is done with 1/2 parameters.
22:16
Y_G
But with the last requirements
22:16
Y_G
1)"i2c set/get" through DaemonCLI requires 4 parameters
22:17
Spirit532
left the channel
22:17
Y_G
2) For gamma_config we need another data blob packet
22:17
Spirit532
joined the channel
22: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
22:26
Y_G
So should we go with 3 different data packets for testing purpose now ?
22:26
Y_G
Data arrays and the blob
22:27
BAndiT1983
why 3?
22:27
BAndiT1983
we have one for general settings, max 4 params, second one for data blobs
22:28
BAndiT1983
what would be the third one?
22:28
Y_G
Oh ,if we are increasing to 4 parameters then only 2
22:30
BAndiT1983
as long as it's not getting out of meaningful boundaries, then we are free to adjust
22: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
22: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
22:32
se6astian
changed nick to: se6astian|away
22: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
22:35
BAndiT1983
not that many, at least for 4 params
22:35
BAndiT1983
have you understood the thing with packet header and payload?
22:38
Y_G
packet header would be an additional parameter in the daemon request ?
22:39
BAndiT1983
no, this would be an additional structure ->
22: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
22:40
BAndiT1983
and of course you would have payload, like current packet or new one for data blobs
22:41
BAndiT1983
just as example -> http://solace.com/wp-content/uploads/2016/05/solace-message_payload.png
22:42
BAndiT1983
header could hold general infos, e.g. module, command etc.
22:42
BAndiT1983
so you just have to split current packet in 2 suitable parts and extend header with enum
22:42
BAndiT1983
example for flatbuffers enums -> https://google.github.io/flatbuffers/md__schemas.html
22:47
BAndiT1983
off for today, see you
22:47
BAndiT1983
changed nick to: BAndiT1983|away
22:48
Y_G
Will have a look and update you with the procedure tomorrow
00:06
Y_G
left the channel