Current Server Time: 00:54 (Central Europe)

#apertus IRC Channel Logs

2021/04/12

Timezone: UTC


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