#apertus IRC Channel Logs

so the efficiency change by having the extension hold by a second materia/air is 1% to 0.1% ?

they are on oposite sides and they will be separated by several PCBs

i.e. it should first pass the sensor cooler and then the FPGA part before it gets exhausted

(if there is active cooling)

we didn't get hotter than 55/60° C on the Alpha without cooling

you might want to try to insulate it somehow to see where it can raise :)

we did some funny tests with our head vs the RED camera... ours get to 55deg, red was hot so we could not touch it... all what we did is to put it into a paper box :)

(assuming we are talking °C here)

yes

but the red must gone much higher

did you do that?

yeah, that was enough?

interesting

Bertl: btw even if there is a Peltier in Axiom Beta, the camera should still be able to function when it is off - suppose we're running out of our batteries

Alpha is big :)

it is all about air flow and convection

and a radiator on Zynq?

and yes, there is a heat sink on the zynq

also, can it be that future PL for Zynq will make it hotter?

PL?

ah, yes, of course, the fabric configuration is the main cause for heat

well, it is hard to tell what would produce most heat

wire in some lut maps 4/4 and feed with random data?

probably the switching at cells + interconnect is the biggest source

yes

on mgt that i can expect.. but on standard io?

do not underestimate LVDS switching

the zynq has a thermal shutdown

yes

gagabit trancivers on 7015/7030? can they add heat?

well the question which I most want to ask you now is this: do you have any ambition to build a sealed camera?

sealed? like waterproof?

with my "proprietary" concept: no

large heat fins, liquid cooling for underwater, or something like that

my vision was this: a more or less sealed brick of aluminium, maybe even slighty bigger than it would have otherwise been, say with flat square back of 120mm * 120mm

and if that is not enough a silent 120mm fan could be attached to the back externally

"the dimensions are correct, just the fan is smaller" ;)

Bertl: how hard would be to devise a sensor interface which can be shared/reused for free/nonfree sensors? (you wont be needing sockets anymore, and the replacement will go with the piece of rigid-flex pcb or b2b plug)

__anton___: have you got any sketches of the cooling layout?

intracube: Plan C

i.e. to have an intermediate FPGA/CPLD whatever which provides a standartized interface to the ZYNQ

intracube: there is an alternative layout suggested by Berl. I haven't made sketches yet. Basically you use the back panel as a radiator for Zynq, all of the back panel, and the front panel is connected via Peltier to the sensor

that seems to be rather an overkill if you wish to stick to xilinx... but with an igloo or xo2 i could imagine it

intracube: yes

is there a list + dimensions for all the components of the Beta?

intracube: Zedboard is 2.25" * 4"

intracube and 25.5mm high (because of Ethernet/USB connector)

intracube: CMV12000 is 47mm * 34mm

this is the lens mount: https://github.com/apertus-open-source-cinema/beta-hardware/blob/master/Enclosure/Version%20002/NikonLensMount01.pdf?raw=true

57mm external diameter

I didn't have any other sizes when I was doing my sketches, but this is more or less enough to estimate possible layouts

maybe I'm crazy but I'd rather see the baby sealed with an optional external fan :)

there must be a % of userbase which would feel the same, I'm just not sure how large this % is

we already changed some design aspects during the campaign (thanks to the feedback and input provided)

...and in a sealed layout sensor and Zynq need to be placed further apart - which can be achieved either by making sensor board larger or by introducing 2 connector boards between sensor pcb and zedboard

but it definitely makes cooling a challenge

just IMO, but my preference would be a camera similar in size to the Alexa

intracube: however Beta is going to have controls and monitor/viewfinder as separate modules

well the future ssd raid will take space

__anton___: yep, but a larger internal volume would give more options for passive heat cooling

intracube: no problem with that, you can always pack it into different cases

to cool it down I mean :-D

there is nothing to be bolted on the back on the Beta

Yeah, just a fan!

Bertl: ah ok, I didn't realise

or actually if it is aluminium you can have mounting holes

and if you don't need a radiator to those mouting holes you can attach stuff - remote control, monitor, battery

we will make sure that they can be easily compared (software and hardware monitoring) so that we get good results

well, once the layout of the internal modules has been fixed there isn't that much freedom in how you can modify the case

most likely, sensor on a single or double PCB module

then the actual Beta board

(which breaks out the gigabit tranceivers)

and the last board is the optional dual microSD/fan controller board

another potentially hot component

the 6-40V switching DC/DC will be a separate PCB

inside or outside, we haven't decided yet

the one we built and tested didn't really get hot, a little luke warm, but that's it

we are also investigating DC/DC modules for this part

Microzed has got two FCI 61082-101400LF sockets

and two connector boards were provided with 61083-103400LF on each

The only thing they would need for a new camera layout would be new connector boards

not sure how you want to connect them?

btw, why move the beta board and the MicroZed apart?

well if they are clipped together there is no so much variation you can have in camera case

yes

that would IMHO make a lot more sense

assume the height of the MicroZed (2.25) as square

*though

on main Beta board

the sensor and the sensor power supply, and we are considering a low power FPGA/CPLD to create a standartized interface

yes that's on sensor board

?

the JTAG interface

if the 3 are firmly attached to each other than there is only so much variation in body that can happen

agreed. I did not thing the sensor board could be broken apart

you still need a PCB to mate to the MicroZed

which will be almost the size of the Beta board

so, instead of gaining more flexibility there, you only add one/two boards

Bertl: after I started drawing I realised that what I had in mind was not possible and what was possible was a lot less useful

here Beta board and Microzed can be moved further apart

with that there is more isolation between it and Zynq

which is not that unexpected, because we originally planned the sensor on the Beta board at least for the KAC

what kind of a connection could they have?

no it doesn't

well, that's the interesting part, if we manage to make a proper standartized sensor interface

we can connect the sensor board with the beta board in different ways

i.e. we can optimize the communication between sensor board and beta board to the connection

whatever sensor can do should be available?

yes, but it doesn't always need to be available

no need to trasnfer 4k at 300FPS

does it mean that use these IO's on Zynq for smth else?

where's the win?

also you can use cables of lower quality if you use some coding tricks

and of course, the big advantage is that you can change the sensor easily

otherwise if we do not take Gamma into account you could probably as well mount the sensor on Beta board and swap Beta board together with sensor since the cost of everything else on Beta board would be a lot less than of the sensor

no worries, we won't make it _that_ abstract

wouldn't be without interest to see what % of people would prefer a compact camera over a sealed one and vice versa

I wouldn't worry about a low power FPGA/CPLD, you probably produce 10 times the heat with a peltier

well we're prepared to spend 20wt on the Peltier to remove 2wt generated by the sensor; now in the direct vicinity of the sensor there comes something which generates another 2wt... maybe I'm misguided as usual though :)

I'm almost off to bed as well have a good one

off for now ... bbl

aombk, where ?

site is slow as hell to load

still loading :-)

Isn't that like expected when you have a 12 bit ADC?

seems like a lot of comments in that thread haven't taken on board that it's the Axiom -Beta-

have you heard about the robbery in blackmagic distribution center?

could anyone try to reach this ip : http://81.240.158.194:5000/

yes works

no

ok thanks :-)

are you insured and secured about robbery attempts there at apertus? :P

you should see the phabricator login screen

feel free to test it, while my computer is up :-)

you are going to host it on your computer?

i registered and now i wait

(my connection is crappy)

to approve the account

sorry

http://81.240.158.194:5000/M1 for example a mockup anotation tool

Support is a real one.

So I am unsure calling it negativity is entirely fair.

troy_s: what sort of support do you mean?

if the latter, for a similar price-point, are Sony or other big names better?

if I notice a bug in the field with my $5k Sony camera. Can I speak directly to a sony engineer to resolve the problem quickly?

I doubt it somehow

of course I'd expect more support if I bought a $100,000 Arri

sony has a premium service for support... (but it might be just longer/quicker warranty repair)

arri being more into rental would care much more thought, especially the rental only equipment comes with a support team :))

troy_s: but for what camera?

intracube: F65.

And that is something that has always hurt OSS / Libre and always will until it is tackled (ala Red Hat)

troy_s: I agree 100% it'd be an issue for a production doing TV/film

maybe that last part is wishful thinking, idk

intracube: compare rather to some hardware providing firms, than sw/service suppliers

troy_s: but was that down to their linux/support division?

intracube: Example is an offline workflow. Would a smaller project use it? The reasons are that the issues apply to a smaller project, so yes they could / should given context.

intracube: While it is seductive to believe in OSS / Libre, you have to counter it with the rather dismal penetration in industrial imaging and other contexts.

intracube: Well they are a company and they have to hit a baseline metric of satisfaction

intracube: and of course they will listen to last years academy award winner more than Josey Average.

'money talks' is at the root of all this

intracube_: Yes. For better or worse, the ideology of the model drives it.

intracube_: But even in the Axiom range

intracube_: The client list isn't exactly obsessed with quality... There is a fuzzy balance line with quality versus comvenience

(Most larger budgets do not, but _many_ average ones do)

of course. would be nuts to shoot raw, do a really high quality post

all for a commercial with a 2 month shelf life and being played on 'HD' channels that are 8Mbit/sec h.264

intracube_: Hence if Axiom focuses on cinema, then many design decisions take on greater weight. Just as it would have to focused on news, or commercials, etc.

I mean, I know it's in the name and all

that's why I've been here on IRC suggesting on-board lossy compression at some point in the future

troy_s: ^ I missed that

And every design decision pulls away from another design element

Design is a 3D Cartesian coordinate system, and context transforms the clustering of needs.

intracube_: Practical versus desired audiences

troy_s: clarify

That is a feedback loop that can fine hone a design

how's going?

Both can be viable approaches

troy_s: but the latter requires a lot more capital I suspect :)

Red have huge finances relatively

;)

The only issue would be if there were a muddling of design visions; when the audience shifts from AudienceA to all.

That is bullshit language.

Always.

Complex is too

It isn't complex at all

No onboard sound is also defacto standard. Most can provide channels (as was the plan IIRC) but it is only a backup in their primary designed domains

Hello Bertl, how goes ?

There is no “good design�

heh

“Build me a vehicle that a formula racer can control well, that holds six sheets of plywood, has two child seats, goes from zero to sixty in 3.5 seconds, and rides on two wheels.�

Whereas his example nicely illustrates how design contexts pull against / toward each other.

"<troy_s> The only issue would be if there were a muddling of design visions"

I think to rephrase the audio example it is probably a complex question of not what is gained (audio) but what is the trade? (Time, functionality, forms, etc. Holistic)

anyway, as long as the base design can be expanded in different directions to suit different users

Where the gaps are much larger.

people that want to record prores + sound can buy an Atomos

And the act of making a sensor interchangeable is a design decision that has an impact, maybe unforseen.

There was a tremendous article by one of the authors of World Forge that I cannot find

And he was blunt in his assessment was that the architecture became never-ending; they were building architecture to support architecture

World Forge, I'd love to know what happened to the project, have spent countless hours trying to help for their media repository. Feature creep !

troy_s: good chat

Where the map maker's map ended up larger than the actual territory

It is design at the lowest level

In what regard (limited is a privileged term)

or is it fairly locked into standard HD broadcast formats

1920x1080 23.976, 24, 25, 29.97, 30

philippej_: Try to find that article. It wasn't feature creep.

it'd be nice if you could dump, say, 4096x3072 @ even limited to a few FPS over HDMI

Bertl: is it the case that DVI/HDMI are similar

yes, DVI/HDMI are the same for all practical purposes

HDMI adds audio and similar

yep :/

while any modern TFT screen can do hundreds

and it seems some of them are sharing a common base implementation

for example, the atomos HDMI->DVI module gave the same edid information as the black magic converter :)

helps to optimize things though

i think it is where reality meets the idea :) one has to agree on standards

although there's a fair change the actual encoder hardware in these devices support a significantly wider range of options

maybe they'd consider releasing modified firmware for axiom users

no communication yet, but feel free to contact them

but I think, even that is not an option, simply because they do not know themselves

danieel: thanks

bertl glad you liked it

wb se6astian!

maybe its easier to have a setting that works with atomos standards and formats than trying to persuade atomos to release a custom firmware

aombk: that's rather limiting

well in this example maybe you could use the onboard flashcard

do you suggest there should be communication after the beta is released or while it is being designed?

yes

then we're not going to atomos with a vague wish-list

my campaign failed miserably

but did you seriously expect a different outcome?

aombk: Let the work do the speaking. ;)

Thx Bertl :)

excellent!

yeahm the onsemi looked familiar to me as well

I just found out teh microzed only has 48 lvds channels so I was wondering how many of the 64 sensor channels would get used and it which mode...

that's why we plan to use smart sensor boards for up to 64 LVDS channels

I'm guessing that two-side readout mode is best in the case of 32 channels otherwise you'd lose a lot of features according to the specs

Is it some sort of daughter card with a regular fpga just for interfacing with the sensor?

yes, we had the dula side, 16 LVDS readout on the Alpga

and yes, we plan to add a low power FPGA to the sensor board

yes, that's the idea

might have impact on cooling I guess. Didn't read the whole backlog so sorry if it has been discussed already

Superb! Can't wait to get my hands on one, it would be a nice upgrade from my 2k sensor . Great work guys!

you too !

evening!

is anybody good this wordpress or css html?

has there been much discussion about PL mount?

not really

I guess thinking is that the camera is intended for amateurs who are more likely to have (D)SLR lenses around

no idea

I don't think that the mechanical part is very complicated for most mounts, the electrical part (for active lens systems) is more complicated

Knowning not much about mechanics, but about electronics and software, I think the electronic part should be easy and it's just a matter of finding the protocol to talk to the lens, which also shouldn't be that hard.

can anyone confirm that; initially, the Beta won't have any onboard RAW recording (other than MicroSD for still images)?

Bertl: yup, thanks. just wanted to be 100% sure :)

I don't want to go spreading wrong info, etc

Bertl: Everything is easy, until you actually start doing it? :)

Yes, it's not because it's easy that it doesn't take time.

and that was just one day. 20 minutes of filming

gentlemen, get your multi-terabyte ssds ready

isn't the purpose of MLVFS that you do not need to convert it?

i havent tried MLVFS yet, but ill surely try it. i think it wont be realtime on windows tho, as it will work through a webDAV server

oopsie . davinci resolve likes RAM. 4gigs after startup.

i would expect that it will consume whatever you give access to :)

wtf? https://www.kickstarter.com/projects/ryangrepper/coolest-cooler-21st-century-cooler-thats-actually

damn thats what we should have created

time for bed

I saw that cooler when it launched. I can't believe the response! If he can ship them they should be everythwere at Spring Break, and get a bunch more coverage.