#apertus IRC Channel Logs

good day

vup was any progress made with https://github.com/apertus-open-source-cinema/axiom-firmware/issues/179 ?

happy monday!

the goal is to create a skinable client for web, mobile, desktop and command line

good day Bertl

Hello!I'm participating here for the first time. Nice to meet you : )

looking forward to hear more about the FOSS/OH movement in Japan!

se6ast1an : )

no worries, IRC is a very patient medium

I see!

somebody will answer sooner or later but it might not be immediately

Is everyone chatting on #apertus only, or are there more specialized channels?

while there are some other 'related' channels, the main action is here

there are also private messages which work just fine if only two people want to coordinate or so

you're welcome!

hi Shohei! great to see you here

Great to see you here, too! se6ast1an : ) Thank you very much for the link!

why not? :)

who is here?

is here

* bluez is here

metal_dent[m]: do you have something to share and start the reports?

please do

Then I stumbled upon my old PR ':D where I tried to reduce the redundant code and now waiting for BAndiT1983|away 's approval

video: https://user-images.githubusercontent.com/54789531/103020612-bf1d0000-456e-11eb-9566-c41b178acc67.mp4

We have also created a new task (T1215) to add a desaturation filter on the remote display, I have added the shader code which works fine on the camera preview image (Bertl's image)

<se6ast1an "metal_dent: did you push a revis"> Yes, you can see the new commit there (sorry for the other mess as there was a lot of conflicts ':D )

https://github.com/apertus-open-source-cinema/AXIOM-Remote/pull/17

thanks

That's it from my side!

This is the last commit:

very good, thanks!

sure.. thanks!

so last week Bertl helped me get up to speed with vhdl and the tcl side of vivado

re: xthenode: what is the purpose of the client? a generalized client to be used a control which can be mapped to a particular platform...

had to lot to learn on the vhdl side ':D

xthenode: we are currently having our weekly meeting

xthenode: please wait till it is your turn to report :)

great, bluez, many thanks!

maybe some people followed the email conversation with you already but live is always better :)

Hello, everyone. I'm mechanical engineer in Japan, and also running small startup focusing on open hardware.I'm very interested in this project, and personally joined : )

great, thanks Shohei!

I was already thinking of things we could work on together in the enclosure/CAD area

vup you also have some news for us!

yeah, well not too much got done over the last week

I will be happy to join you!

there are still a few problems even there (the input and output image do not match exactly for some reason, even when doing lossless compression)

currently we think this is due to wrong rounding and too few bits for the intermediate values in the gateware compressor

nonetheless, we have figured out a buffering / processing scheme for the gateware that does not use too many bram's / should be quite efficient with them, so thats a big progress

any news on the usb3 front as well?

also I looked at the firmware of the ft601 again and we will hopefully dump the firmware of the ft602 in the next couple of days and maybe we can figure out how to add such a sidechannel for the ft601 aswell

ah, great!

so the compression can just be done on the output path (maybe to the usb3 module) and things like the HDMI preview still "just work"

or how big buffers are required by the different compression algorithmn steps?

so those just get put into bram's in the fpga

for the FTDI it would probably be most interesting to get bandwidth allocation working (on the USB side) not sure how complicated that would be though

Bertl: yeah, the usb2 part probably supports isochronous transfers, as the "officially" programmable ftdi mcu's support that

but yeah that would also be very nice, I agree

alternatively we can consider switching to the cypress EZ-USB chips

se6ast1an: yep, I was quite surprised it can actually be done this way, we probably will need a bit more buffers in the future, but at maximum a factor of 1.5 more I think (we currently only do grayscale, we probably should split the colors for the bayer images)

or even just a ecp5 (but thats of course a lot more work)

sure, but size is of no concern for development no?

a 0.8mm pitch bga should be doable in 4 layers probably, and with the new 6 layer oshpark runs it should certainly be possible

great, fine for me :)

many thanks vup!

not that much happened as I was away over christmas and returned yesterday

should arrive in a week or 2

and nextpcb has started to discuss the stackup with us

the proposed prepreg thickness would be a perfect impedance match but some things need to be confirmed/corrected first

contacted 2 companies

which would be suitable for milling such foam most likely

but overkill for such a soft material

so if you have tasks for collaboration let me know

Bertl: please be the closer!

mostly busy with x-mas and similar

because there was some interest to build that and I made sure that the design is current and the bom can easily be dreived

so no changes to the design itself?

ah yes, forgot to report about thta

what I want to test is the feature of the CMV12000 where it can be exposed while data is being read out

but it comes with some drawbacks and artefacts affecting pixels read out values

the custom gateware bertl built should enable doing that

Bertl: the sata plugin module design did not contain any design changes I assume?

no

ok then, anyone else who wants to report/share/comment on anything specific?

many thanks everyone participating!

off for now ... bbl