#apertus IRC Channel Logs

off to bed now ... have a good one everyone!

morning folks!

good day

MEETING TIME!

just curious, who is present?

preetimenghwani is here

* bluez_ is here

thats all from my side

btw GSoC news: https://developers.google.com/open-source/gsoc/timeline

June 1 Coding officially begins!

bluez_[m]: your turn

hello everyone

i find there are many levels of abstraction layers... like jtag and then mxo2 specific commands and all...was trying to figure out how to implement it in my code

and i added some enums to identify different operations on pic16

https://github.com/Swaraj1998/axiom-beta-rfdev/blob/master/rfdev.c

thats it from me!

thanks bluez_[m], whats the status of https://lab.apertus.org/T1207 ?

ah, I see, tx

Bertl: also do check out the header file there... the enums are there..

good work!

maybe Bertl can help

I assume its just requiring one or two bash commands? :)

<se6ast1an "I assume its just requiring one "> that is what i have to write? really? i thut something else then ':D

<Bertl "good work!"> thanks!

so please check in with Bertl about the required commands

<se6ast1an "so please check in with Bertl ab"> sure!

so I am working on the test framework, also learnt how to program remote zynq, couldn't work much this week as was sorting out my academic stuffs so that i have only one thing to focus on from now i.e GSoC itself. Will start coding of the pixel remapper in a day or two. Hope that is fine :)

please make sure the remote setup is working for your development.

yeah sure!

metal_dent[m]: please go ahead

also i compiled and checked out the remote_e and remote_w asm files in radare and compared them with the BL present in the repo

i read more about the icsp writing as the coding period has started from today and my first task is to flash pic16 (the flow charts in the microchip pic16 pdf are really helpful and explain what i need to do)

the remote_w is almost similar to the one we have in repo (not same as the latter one has some problem)

that's it from my side!

whats the current status of https://github.com/apertus-open-source-cinema/AXIOM-Remote/pull/17 ?

great, thanks

Thanks, se6ast1an. Hello everybody!

Also this initial version will help me testing theremote FPGA flashing process.

great, thanks!

<panintended> I'm afraid I don't have any substantial update on my tasks this week.

megora: okay, also please make sure the remote setup is suitable and complete for your purposes

Quick update from my side, small side project was visiting the mechanical concept of the AXIOM Micro R3 which is now envisioned to consist of a single 3d printed part connecting the image sensor board and a C/CS mount adapter ring together, the base will have a 1/4-20 thread for a tripod mount. A small UV/IR filter can be glued into this 3d print part.

https://cloud.apertus.org/index.php/apps/gallery/s/PGHsr9PjkaxLoJC

its a holiday today in most european countries so I assume BAndiT1983|away anuejn and vup are not here currently

Bertl: maybe you can also share some insight into the HDMI debugging you and vup did?

yep, will do

we have expanded the remote setup over the last week to contain not only the bits an pieces required for our students, but also some gimmicks and gadgets to play with ourselves

the idea was to compare the received values (original firmware on the CamLink4k) between a working (RPi) and our (failing) signal

well, we didn't know why it failed

but thanks to the extensive provisioning done by the Elgato folks, we already have all the necessary tools in place to read out the HDMI receiver registers on the CamLink4K with original firmware

correct, it works up to 1080p60 (even higher) on a normal PC monitor

understood

note that the CamLink4K works just fine with other sources as long as they provide one of the supported resolutions/framerates

the next idea here was to use a different HDMI generator on the Zynq to test with

the advantage here is that the Zybo features an HDMI output (and input) very similar to our setup (just without the redriver chip)

so it sounded like a straight forward approach to us

first, the demo is not available as SD card image or similar, only as Vivado/SDK project

this in turn required download (several hours) of huge software packages (Xilinx) to install the ancient 2016 version of Vivado and the SDK

so we also had to create a container running centos 6.8 to be able to get the Vivado tools working and additionally guess and install a bunch of unusual packages to actually make it work

anyway, after we finally managed to build the demo, we found out that it also didn't work at 1080p60

we adapted the demo to use 1080p30 and that worked fine though

this led to what we should have thought about in the first place (with the good SHOGUN)

so the conclusion so far is that there is something wrong with the way we generate the sync signals

would a known working hdmi source device (non open) be of any help? like a commercial camcorder

right

ok

which can be considered a 'good' HDMI signal

which turned out to have a bunch of unexpected issues

so it was replaced by a new one, only to find out that the FPCs on that one didn't make contact to the FFC

so I had to replace those as well, but after that and some testing, it all seems to work now

I also added a jtag adapter to Beta-B to allow for remote debugging

a bunch of scripts were added as well to remotely control everything and to query the current status

great!

some testing was done on the ultra-96 but nothing worth mentioning so far

great, many thanks!

then thanks everyone for attending and sharing!

thanks for having us!