#apertus IRC Channel Logs

morning folks!

back to Austria now ... Maker Faire is over, should be back around 18:00 CEST

What does this mean? "This task also involves implementing features like reading multiple frames of RAW video" https://summerofcode.withgoogle.com/projects/#5659888368222208

@bertl or sebastion: how does the beta assembly make progress? Did you find fitting parts to replace those that dissapeared from the market? Any chance to, as a backer, get a beta compact until the end of 2019?

Hi aleb ,

It was written by me for the project description , implementing features like reading multiple frames " is in reference to framesever task , as oc cannot handle more than one frame right now for MLV files

OCcore will deliver infos about the video, like resolution etc., frame server will use it to create basic AVI container and also ask for image data, but it's not like frame server is the one who does playback, it's only a data provider for video players/editors, you can compare it to OCcore which provides data to frame server

Good evening !!

hi

raw inputs in frame server? Dev__, are you sure what to do for gsoc?

have you read my explanation in the logs?

Dev__: raw inputs are not visible thru frameserver

Dev__, please describe the pipeline, as my doubts rise that you know what to do for the gsoc task

maybe not clear enough, so i will explain it with a diagram

-> frame server requests information about resolution, maybe also FPS etc., prepares AVI container and pre-calculates offsets

-> frame server intercepts the read routine and asks OCcore to provide the required frame, afterwards the frame data is sent to the player

think of OCcore as the "meat" of what OC does

frame server as BAndiT1983 said, just intercepts read requests (maybe buffers some things as well) but it just replies with what OCcore already has

Dev__: think of it this way, if I write some bad debayering algorithm in OC, the frameserver should just send it through...

XD

and the PRs there burn my eyes

usual stuff, was lucky and got to work with spring boot

is planned at least, but we were at the maker faire, so Bertl_oO and se6astian|away were on the way from Berlin to Vienna today at the morning, as they drive a car, it can take a while plus traffic jams

Yes, as explained by BAndiT1983 , It was supposed to be the prime task but then playback on top of it , made me confused

playback is not on top of it, it's the substance of the task, first playback, even simple brute force which preload frames, afterwards frame server

hi Nira

Hi!

so BAndiT1983, it is not showing anything right now I recon?

so we are looking at how the playback thing will work logically (without frameserver) right now

and the buffering mechanisms maybe

Dev__: are you clear on our heading?

as i said, it would be ok to preload several frames and hold the in buffer as looping video for first tests, later we need quick exchange of old frames with new ones, so the static allocator and similar stuff will be necessary, basic implementation is there, but maybe we can use something sophisticated from github to not reinvent everything

something like a circular queue :P

Dev__: ...

yes supragya_ , I m with u

For testing Purpose , i guess

not really, first you have to implement features for playback, before moving on to frame server

Dev__: could you elaborate on what you think our heading is... so we all are on same page?

is there are questions, throw away :P

yet*

have you audited the code regarding this?

hi Davelister

As far as i was able to understand. For handling Multiple Frame , we can use static allocators which i had proposed in My proposal too

Dev__: static allocators are something different

Dev__, don't focus on higher difficulty tasks, just start with a big chunk of memory, allocate as much as you need for e.g. 15 frames and load the whole image data sequentially into it, but you have to keep track of where the data is for each frame, so you can request it, e.g. by frame number

static allocator, Dev__ are just big chunks of preallocated memory...

they can save anything... whatever you feed

http://www.gingerbill.org/article/2019/02/16/memory-allocation-strategies-004/

BAndiT1983: ?

Davelister: hello :)

supragya_, it would be better to get a big chunk and store data there, as it is working already, but in very basic way

https://github.com/apertus-open-source-cinema/opencine/blob/dev/Source/ProcessingTest/Presenters/ProcessingPresenter.cpp

This the approach which i thought, not for stating point but I thinl this is what we can do : Take position of frame into static allocator or big chunk memory and then send (debayered frames) to OC

dumppng works?

Dev__: what?

??

send to OC : Load frames

which we will controlled by slider

hello supragya_

Davelister: I don't think you are here as a gsoc guy? have i seen you in 2018?

supragya_: not at all

I have only been here on IRC

BAndiT1983: I hate when people do that :-)

looked already up where Davelister worked and so on, very easy to find, whois is our friend :D

nah, not stalker, but people post so much, anybody can look it up

even human resource departments do it a lot, so think twice before uploading party photos on facebook or similar

yeah, human resource has some taste to it as a term

I will try to explain which i could understand for playback using some doc

Here are a few references:

Yes please

back now ...

hi Bertl, how was the trip?

exemplar downscaler: https://github.com/apertus-open-source-cinema/opencine/blob/dev/Source/OCcore/Image/BayerFrameDownscaler.cpp

but otherwise uneventfull

Bertl: do you remember me :P

still searching for the diagram of OC structure

don't remember where i have placed it, but maybe it was in some archive their

supragya_: who are you again? :)

there is the diagram of general structure

in case it's not clear how things interact

nasa or nada will be announced in the summer

Bertl, but there is also some NASA stuff besides plato

I will see it BAndiT1983, and i will try to start simple like loading frames by just saving them in memory for less number of frames and then comes static allocator which will optimise use of memory

Dev__: it would be appreciated if we could communicate on a regular basis using emails. That helps keep logs and everyone in the loop.

Dev__: try bringing in one frame, then a sequence

Okay supragya_

No supragya , I will try to understand more

Dev__, please create a task list and dissect it in subtasks, you can use some mind map software which is really good for such things

e.g. -> http://freemind.sourceforge.net/wiki/index.php/Main_Page

BAndiT1983 knows cool things - Project IGI, mind maps ... :)

counted at least 5 tasks i have to do for apertus in the next time, so Steam has to pause a bit

are we going to chat about the fast serial links today? had that in my calendar starting 25 minutes ago

felix_: I am here for hardware topics, so I think so

Not for the moment, sorry!

anybody else?

well, felix_ and Davelister the stage is yours please continue

ah, my mistake, not following fpga and electronics discussions much at the moment

Bertl, a bit different topic, regarding axiom remote, will try to use JTAG through platform cable, but is there some universal chip programmer out there, which is not costing arm and leg to acquire? had USBprog long ago and it could be outfitted with different programmer firmware for different MCUs and other chips

BAndiT1983: are you speaking about the JTAG TAP of the SoC or for another microcontroller?

at the moment the focus is on pic32mz, but maybe i can re-use such a device later for other things like atmega etc. etc.

waiting for Bertl to tell me the pinout, to try openocd with xilinx platform cable, otherwise i have some evaluation boards, which have a programmer attached to them and which can be broken off when not required anymore

nah, the zynq board has it's own stuff, i'm trying to work on the axiom remote board

oh ok ok :-)

Hi Bandit, can you discuss about openocd here on irc, it would help me

apurvanandan[m], what do you want to know?

using openocd with an artix7 works great; haven't used it with a zynq though

have only tried it with ISE for my spartan 6 board and virtex 5 or 4, but it worked after some fiddling, but as i lack proper ICSP/JTAG device, would try to access pic32 with the platform cable

maybe JTAG is compatible

apurvanandan[m], which OS?

I have ISE installed

is the cable recognized?

Actually I don't know where to start with, could you just brief what are steps involved

there are great tutorials on google, as it's a bit difficult to explain on IRC

used this also

No, I meant the cable is setup and have been using it since long. I wanted to know how to use openocd with the cable

ah, openocd should support it as it is

Ok, got it!

searched explicitly for DLC9G platform cable

if you look at the board layout (or board itself) and the JTAG is at the upper edge

then the upper left pin is pin 1, and the whole upper row is GND

pin 12 and 14 are unused

ICSP is on the lower edge (opposite site of the board) and the pins are labeled there

there is only the one JTAG connector (2x7 pin) on the Rremote

ok, will tri to reduce the lath size then

but you can get a cheap PICkit (preferably PICkit2 or an even cheaper chinese clone)

already considered, but haven't looked around yet

plan is to use the docker container, which builds our firmware for axiom remote already, so i don't have to bother with their tools under linux

another option would be to use 2mm dupont cables and make a cable connection to the jtag port

Davelister: so if I got that right, you want to help out with hardware design, yes?

Bertl: exactly

If I can give the project some help, that would be with pleasure :-)

(according to the files extensions)

at least i've used it to open schematics today at the morning

just did a quick search but couldn't find IRC logs, where the guys discussed problems here and there in kicad

don't worry, I'll have a quick lookaround by myself

no problem, haven't done anything special

the main reason for using eagle afaik was that when the hardware design started kicad wasn't that great yet

I ask the question cause I work a lot with KiCad, and even use it in a profesionnal context

I see

would it be a problem if we use KiCad for the new boards? The software is now as good as Altium for some parts (Step generation)

i don't see any problems with using kicad, and the long term plan is to switch to kicad someday

sounds a good plan, I may even help a bit about how to use it in a shared project

KiCad is perfect for new designs

as vup mentioned, one (hopefully not so far) day we'll simply switch to KiCad

Bertl: good. Is there any requirements in terms of costs?

we try to make it work with the OSHpark stackup and services whenever possible

ok I see. What about multiple BoM?

- Average board

is this a common practice here?

except for special parts, we try to use components which are readily available via the typical distributors, i.e. mouser, digikey, arrow, farnell, ...

Bertl: great

Bertl: is there any project with the highest priority where I could help?

BAndiT1983: we are still all using Eagle 7.7.0 which is the last version before the switch

felix_, what happened?

felix_: I was lucky, I got Jean Pierre Charras as one of my teachers :-)

Davelister: one quite important and also challenging task would be the 'Smart' Interface Board

well, i tried building kicad for osx and encountered spme problems and wrote a bug report that included a fix; unknowingly i hit the big hornet nest that noone wanted to touch at that time, and i got yelled at by the maintainer, that it should be obvious that i'm doing things wrong and that he wanted to nuke the part i hit the bug anyway and that it just causes trouble. well, after that i didn't bother to

felix_: you got angry mac os x users :-P

(I work with Mac os x too)

Davelister: we are currently using a 'Dummy Interface Board' to connect half of the 64 LVDS channels from the sensor to the Zynq on the MicroZed which basically halves the throughput

ok

yeah... and it's not that i didn't spend two evenings to get things running and would have spent another 5 evenings to make things smoother. anyway, enough being grumpy about things ;P

and it is more or less a high-speed signals dispatch board?

power supply should be available from the power board (two power rails are reserved for the interface board there)

it probably makes sense to go for a 7 Series FPGA (e.g. Artix)

it needs to work well with the Zynq interface

why the Zynq does not handle the signals? Was it an I/O or area limitation?

yes, it is simply a limitation of the MicroZed we are using

I see

I am afraid 1.2Gbits would be the limit of the Zynq7020

well, it might not be possible, but then it might just work

I did some breakout tests and it wasn't looking that bad

ok

we had a look at the PicoZed (which has those) but the connectors are in 'unfortunate' places and the board doesn't provide any of the PS features (Ethernet, USB, etc)

so it would complicate things more than necessary

Davelister: if you want to have a look at the sdi board https://github.com/felixheld/AXIOM-photonSDI-hw

sadly didn't get around yet to work on the bringup again :(

so all in all, it is a quite important piece which we didn't find the time to work on yet

it is 36 LVDS (2x18) on the Zynq side and 80 LVDS (2x40) on the sensor side IIRC

but you can easily see that when you check the dummy interface board schematic/layout or the interface of the main board and the sensor frontend

if you have any questions about the interfaces, just let me know and I'll try to answer as quickly as I can

I'll have a look this evening

Davelister: you should be able to find most schematics / boards here http://files.apertus.org/HARDWARE/AXIOM/BETA/

thank you very much vup

Davelister: not sure if you found that site yet, but the general structure of the pcb's is described here https://wiki.apertus.org/index.php/AXIOM_Beta/Camera_Structure (especially chapter 7)

great

and then I'll give you some inputs :-)

oh, one more question

(I am trained for EMC and electrical safety, but for bigger equipments :-) )

well, we try to keep emissions as low as possible and also try to design our boards somewhat resistant

vias do not cost extra at OSHpark, so you can have as many as possbile (stitching)

(who still charge for vias?)

in Austria?

strange, old school manufacturers I suppose?

OTOH, OSHpark stil doesn't do EC, so PCBs can have defects

maybe later we can give them some calls

vup: i think we talked about that at the congress, but i wasn't too convinced yet

Bertl: by stackups, you speak about multiple PCB Layers aren't you?

because we don't want to maintain two separate designs and still want to keep the OSHpark option

(not sure it matches the price however... It will be subject of a future discussion I suppose)

i think my main issue was compatibility; old boards driving signals on those pins might fry the gtps and you can only route one gtp if you want to reuse the signal pins on the axiom connector that go to the machxo2 without compromising too much on signal integrity

with old boards i meant extension boards, not the board taht currently has the two machxo2

no, other way around

the extension board driving the pins that currently connect to the machxo2 and then to the gtp

how many lvds lanes are between the microzed and each machxo2?

uh, that's not many :/

but a replacement for the MachXO2 could get all the 12 LVDS going to the plugin slots as well

so basically a proxy artix 7 inbetween

i kinda like the idea

maybe add a high-speed mux (those are rather cheap), so that some of the lvds lanes can be routed to the gtps instead

if in doubt, add another board to the stack to get some more board space ;P