Current Server Time: 23:19 (Central Europe)

#apertus IRC Channel Logs

2021/04/12

Timezone: UTC


02:18
manav
left the channel
02:26
lexano
left the channel
04:27
lexano
joined the channel
05:05
Spirit532
left the channel
05:05
Spirit532
joined the channel
05:13
aSobhy|away
joined the channel
05:16
rahul
joined the channel
05:20
vedant16[m]
left the channel
05:20
metal_dent[m]
left the channel
05:20
aSobhy
left the channel
05:20
rahul_
left the channel
05:39
vedant16[m]
joined the channel
05:40
metal_dent[m]
joined the channel
05:45
Bertl
off to bed now ... have a good one everyone!
05:45
Bertl
changed nick to: Bertl_zZ
06:38
BAndiT1983|away
changed nick to: BAndiT1983
08:03
vnksnkr
joined the channel
10:16
se6ast1an
good day
10:26
lambamansha
joined the channel
11:25
vnksnkr
left the channel
12:32
Bertl_zZ
changed nick to: Bertl
12:32
Bertl
morning folks!
12:34
BAndiT1983
hi
12:36
se6ast1an
hello!
12:47
manav
joined the channel
13:55
markusengsner
joined the channel
14:05
lexano
left the channel
14:25
lexano
joined the channel
14:27
mumptai
joined the channel
14:59
Bertl
off for now ... bbl
14:59
Bertl
changed nick to: Bertl_oO
15:50
markusengsner
left the channel
16:59
Bertl_oO
changed nick to: Bertl
17:00
se6ast1an
-----MEETING TIME-----
17:00
se6ast1an
who us here?
17:00
eppisai
is here!
17:00
vnksnkr
joined the channel
17:00
Bertl
is here ...
17:00
metal_dent[m]
is present
17:00
se6ast1an
great, metal_dent[m]would you like to start as usual?
17:00
bluez
\me is here
17:00
bluez
is here
17:00
metal_dent[m]
Yes sure
17:02
BAndiT1983
is here
17:02
metal_dent[m]
Last week I worked on the UART connection, if you remember on the USB connection we could send a char and receive it back on minicom now same thing is also working on the UART
17:03
Bertl
yay!
17:03
metal_dent[m]
The problem I’m facing currently is when I send a string to the remote which also I expect to receive back but instead I’m getting blank output
17:04
metal_dent[m]
So this week with the help from Bandit I expect to solve this little hurdle
17:05
BAndiT1983
as my UART adapter has problems, i have to postpone this
17:05
metal_dent[m]
Yesterday I also guided eppisai with the memory management of PIC microcontrollers
17:06
metal_dent[m]
I have also started to write a report on this internship which I’ll need to submit to my college soon
17:06
metal_dent[m]
<BAndiT1983 "as my UART adapter has problems,"> Oh okay
17:06
metal_dent[m]
That’s it from my side then!
17:07
se6ast1an
many thanks!
17:07
se6ast1an
metal_dent[m]: I would like to discuss creating a remote/beta/PC communcation issue overview as its hard to keep track of the issues/solutions/status, lets discuss that later or maybe tomorrow if you are available
17:08
se6ast1an
bluez: what news do you have for us?
17:08
metal_dent[m]
yes sure!
17:09
bluez
hi! so i was able to put the appropriate constraints for the register HDL, which seems to align them as we require them to
17:09
bluez
align the LUTs i mean
17:10
bluez
next, i spend most of the time writing this script which allows editing/reading LUT INIT values directly given a bitstream
17:10
bluez
https://github.com/Swaraj1998/reg-test/blob/master/scripts/bitmod_init.py
17:10
bluez
this uses a customized database file derived from the one in project x-ray... which documents the bitstream
17:11
bluez
now this seems to read and write the LUT INIT values correctly... but somehow still actually uploading the bitstream to the FPGA has no effect on the logic of the LUTs
17:12
Bertl
main question here is, does the modified bitstream upload successfully?
17:12
bluez
maybe the writing part is not working correctly... but observation seems to say otherwise... i'm still trying to identify the issue here
17:12
Bertl
could be that the upload gets rejected
17:13
bluez
i think so yes, no error bits are set during upload
17:13
Bertl
okay
17:13
bluez
and also the DONE is asserted
17:13
bluez
i'll check that again properly though..
17:14
Bertl
in the bitmod_init.sh where do you write data back?
17:14
bluez
so other than this, i am also working on my internship report which i have to send to my college tomorrow
17:14
Bertl
s/.sh/.py/
17:14
bluez
i simply edit the file
17:15
bluez
in place
17:16
bluez
and i checked the checksums... also reading back the INIT values reflects the values I wrote..
17:16
Bertl
okay
17:17
bluez
so yea still trying to figure out this one... maybe some very obvious issue that i am overlooking..
17:17
bluez
that's it from me!
17:17
Bertl
so probably next step: modify the INIT content manually (HDL design) and generate a bitstream to compare with
17:17
Bertl
(checking for differences between the edited and generated version)
17:18
bluez
yes indeed...
17:18
se6ast1an
many thanks bluez!
17:18
bluez
right now just trying to be done with the report...
17:18
se6ast1an
let me know if the report requires anything from the org side
17:19
se6ast1an
eppisai: you have been quite busy, please share what you have been up to!
17:19
eppisai
hi! :)
17:20
bluez
se6ast1an: sure i will :)
17:21
eppisai
I have just been trying to complete my previous task, and was facing an error with memory allocation, so now i am trying to understand memory management in remote properly, looking and understanding linker scripts, and have been spending some quality time with PIC32MZ manual
17:21
eppisai
also, have written down documentation, for windows build
17:21
eppisai
https://github.com/eppisai/AXIOM-Remote.git
17:21
eppisai
sorry wrong link
17:21
eppisai
https://github.com/eppisai/AXIOM-Remote/blob/vis_windows_build/AXIOM_Remote_Firmware_Visualizer/README.md
17:22
eppisai
Thats it, not much of progress, but personal growth from my side :)
17:23
eppisai
Also have been analysing stack of firmware and trying to understand stack better..
17:24
se6ast1an
great, I assume this is the same or similar memory allocation issue me and BAndiT1983 also faced at one point
17:24
se6ast1an
so lets coordinate there soon
17:24
se6ast1an
BAndiT1983: would you like to report next?
17:25
BAndiT1983
can do
17:25
BAndiT1983
was mostly working on the visualiser, as my work was occupying me a lot
17:25
BAndiT1983
together with se6ast1an we've moved pretty far in prrof of concept -> https://apertus-open-source-cinema.github.io/cad-3d-viewer/
17:25
se6ast1an
your "dayjob" I assume?
17:26
BAndiT1983
yep
17:26
BAndiT1983
next steps would be: adding a better UI instead of dat.gui, animations of assembly, fix bugs, add custom shaders for metal and similar materials
17:27
se6ast1an
there is a dedicated lab workboard coloumn now: https://lab.apertus.org/project/view/16/
17:27
BAndiT1983
also tested USB on SAME70 further, it's working in general, but have similar problem with CDC ACM as on pic32, so investigation ongoing
17:27
se6ast1an
at the very right
17:27
BAndiT1983
that would be it
17:27
se6ast1an
called "Web 3D Model Viewer"
17:27
eppisai
https://apertus-open-source-cinema.github.io/cad-3d-viewer/ --> feels really interactive now.. just wow!
17:28
se6ast1an
thanks!
17:28
se6ast1an
quick updates from me:
17:29
se6ast1an
the hardware production was promised to start next week at the factory hub, so things are moving there, I will see if I can get a more detailed schedule on Thursday
17:29
se6ast1an
regarding GSOC we are in the middle or actually near the end of a rather hot phase
17:30
se6ast1an
with student application deadline tomorrow!
17:30
se6ast1an
followed by roughly 2 weeks in which mentors need to rate proposals and choose student slots to request from google
17:32
se6ast1an
on the raw recording front via hdmi I ordered a rock pi 4 which was delivered by the end of last week, I plan to put an M.2 ssd into it and benchmark write speeds this thursday
17:32
Bertl
@GSoC: note that during this time, students can start getting involved with apertus (if not done so already)
17:33
se6ast1an
yes, mentors can still be amazed with new contributions, just the application cant be changed anymore :)
17:33
Bertl
usually we will ask questions regarding challenge tasks and similar
17:33
se6ast1an
beside the cad viewer progress that BAndiT1983 described already I have been working with Shohei on various AXIOM Beta compact enclosure topics
17:34
se6ast1an
shim design and manufacturing discussion
17:34
se6ast1an
adding a spring to the CMV12000 Heatsink part that is pressed against a thermal pad at the back of the image sensor
17:34
se6ast1an
drawing review, etc.
17:35
se6ast1an
thats it from my side
17:35
se6ast1an
Bertl would you like to report next?
17:35
Bertl
if nobody else wants to report, then yes :)
17:36
Bertl
okay, then ...
17:37
Bertl
so I've been playing around with the Magewell device and I'm pretty confident, that we can get proper raw recording with the device, even with some error detection/correction features in case something goes wrong
17:38
Bertl
the custom resolutions also seem to allow to tailor the device settings for our purpose, but I have to make some more tests for a conclusive answer there
17:39
Bertl
we received another digitizer device from DigitNow! which claims similar features like the Magewell device, but costs a lot less
17:39
Bertl
I planned to test this device on the weekend, but I was otherwise busy so no results yet
17:40
se6ast1an
did you open up any of the two devices already?
17:40
Bertl
nope
17:40
se6ast1an
would be interesting to get a peak at the used chips
17:40
Bertl
yeah, I guess we will do that with our devices once we verified that they work as intended
17:42
Bertl
I've also been planning/designing a new gateware which should allow for simpler data transfer as we plan for raw recording
17:42
Bertl
besides that, some GSoC reviews and remote setup for GSoC 2021 ...
17:42
Bertl
that's it from my side for this week
17:43
se6ast1an
regarding new gateware, reenabling the "old" experimental raw mode is still a planned quick fix right?
17:43
Bertl
yes, indeed
17:43
se6ast1an
IIRC it worked around the 4:2:2 subsampling on harddisk HDMI recorder devices which we do not have now
17:44
se6ast1an
so the question is if it makes sense to improve that "old" mode at all or go right to a new better data transfer as you mentioned straight away
17:44
Bertl
well, we won't really need those workarounds anymore and we can split the 12bit information into two frames
17:45
se6ast1an
I guess it depends on the effort you estimate both will require, but modifying a working solution is always simpler I assume?
17:45
Bertl
I'll see what makes more sense when I have an idea what's possible ;)
17:45
se6ast1an
good
17:45
Bertl
in any case, we need to do some proper testing for the data transfer to make sure it works as intended
17:46
se6ast1an
agreed
17:46
Bertl
would be bad if we introduce any errors during transmission or conversion
17:46
se6ast1an
sure
17:46
se6ast1an
so anyone else who wants to report/discuss/comment/share anything?
17:49
se6ast1an
right then!
17:49
se6ast1an
----MEETING CONCLUDED----
17:49
se6ast1an
many thanks everyone!
17:49
eppisai
Thanks! :)
17:50
Bertl
thanks for the moderation!
17:50
Bertl
changed nick to: Bertl_oO
18:46
vnksnkr
left the channel
19:17
markusengsner
joined the channel
19:38
vnksnkr
joined the channel
19:59
danieeel
joined the channel
20:02
danieel
left the channel
20:16
BAndiT1983
changed nick to: BAndiT1983|away
20:18
BAndiT1983|away
changed nick to: BAndiT1983
21:10
lambamansha
left the channel
22:26
mumptai
left the channel
22:40
se6ast1an
off for today, good night
22:42
vnksnkr
left the channel
22:55
BAndiT1983
changed nick to: BAndiT1983|away
23:25
markusengsner
left the channel
00:40
manav
left the channel