#apertus IRC Channel Logs

welcome Sasha_C!

(or evening, if you're in Austria?)

Good, it's a beautiful Saturday morning here in Sydney

How are you?

so I'm coding and debugging :)

Yes, I see

Always wonderful to hear that :)

So, do you have an actual copy of the cmosis cmv12000 now attached to the SFE hardware and zedboard?

I've a cmosis sensor here sitting on my desk, plugged into the sensor board, which in turn is attached to the zedboard I'm working on :)

Wow! Sounds very cool!

Great work man!!

And is the lens mount also attached? Are you saying the hardware is ready to go and capture footage with once the software side of things has been taken care of?

But I imagine, when the time is ready, it won't be difficult to attach the lens mount to the SFE?

i.e. working on that :)

it's actually quite complicated to get that data from the sensor, which probably isn't that obvious to the public

those signals carry the clock and data to and from the sensor

the data itself is broken down into serial streams of 8, 10 or 12 bits

to get meaninful data, then you have to align the bitstream on word boundary

Do you think it would be beneficial for me to write about this on the apertus site, explaining the difficulty of getting data from the sensor?

well, all this is not really unexpected, i.e. it is how LVDS works, but yes, I guess for the typical movie folks following the axiom development it might be quite interesting

interesting analogy

or if you want the computer analogy:

to consider how transistors (switches) form gates, and millions of gates form a processor which then executed assembler code which was generated by a compiler processing a C program

Amazing how all this fits onto a small chip/board!

down to the smallest transistor and gate and up to the highest level where we execute shell scripts on the arm cores of the zedboard

How long do you estimate this could take to work out?

That is FANTASTIC news man!!!

I'll probably get the first real image data this weekend, but it won't be that useful from the photographic point of view

precisely

you haven't seen the pictures yet?

well, I guess you saw the ones on the axiom site, yes?

http://vserver.13thfloor.at/Stuff/AXIOM/axiom_alpha_6.png

on the right side, directly into the FMC connector

http://vserver.13thfloor.at/Stuff/AXIOM/pmod_assembled_top_600dpi.png

at the bottom, we have a cable to connect the PMOD on the frontend

This is SOOO cool! Thanks for sharing this with me

I've also a rainbow colored cable attached at the second PMOD connector at the bottom, which feeds debug data into my analyzer

then the usual cables attached to the zedboard, like power, ethernet, dual micro usb, hdmi

on the PC I have quite a number of PDFs open (mostly datasheets and documentation)

This is all so amazing to hear! I'll start writing up an article referring to this now

well, let me know if you need more detail on anything in this regard

night everyone!

morning everyone!

hey se6astian! did you see the gerber url yesterday?

let me dig them up

http://vserver.13thfloor.at/Stuff/AXIOM/cmv12k-adapter-v1.1.tar.xz

done

hey there

how are you gabe

please check with Bertl on the latest development news ;)

sorry

hey gcolburn!

how's it going?

so you're eager to start with axiom/alpha development/testing, yes?

it was simple board (kind of cupboard) which gets attached to the wall to carry a speaker

helped a friend there

well, we have a wooden handle planned :_

the thing with wood and electronics is that they do not go that well

yeah, I as thinking there would have to be something sealed inside so the electronics aren't in contact with it. It was just an idea. not sure which route I'd go

(both electrical and magnetically)

yes, a lot

it's all high frequency (300MHz and more) and a lot of data which needs to be transported without any distortion

an involuntary one that is :)

so what's the status of the prototype?

receiving test patterns and implementing the training stuff to get reliable LVDS transmissions

spi for control settings and retrieving status information

back

correct, the LVDS training patterns

I read about that in the datasheet

well, I currently mainly have the ZedBoard

okay, makes sense, we will figure out a way to get boards and sensors to developers

have you set up a development environment (on Linux?) for your ZedBoard?

okay, we switched to Vivado a few weeks ago, after Aaron (from Xilinx) suggested that we have a look

from the VHDL PoV not much changed, XDCs have replaced UCFs

for scripting?

you basically start with a TCL shell where everything happens (or can happen :)

okay. so it probably makes a custom build chain a bit easier?

well if you guys are switching to completely to that I'll make the jump

are they still using SDK based on eclipse?

I've built my own kernel and userspace and there is no need for the SDK ATM

I haven't had time to get into building a custom kernel, so I've just done bare metal apps in SDK

btw, you can grab the kernel and userspace and if you like I can tell you how to roll your own as well

sure, that would be great

the kernel and initramfs is part of the HDMI test package

yeah okay

http://vserver.13thfloor.at/Stuff/AXIOM/ALPHA/hdmi_test_v0.1/ (here you can see the vivado.tcl stuff)

ok

did you configure TFTP booting yet?

okay, good

i've had a weird problem where when I have the TFTP/DHCP running from ubuntu linux my wifi connection seems to freeze up. I had specified the MAC of the zed board specifically

ok, well if I can find a cheap DVI->HDMI converter I can test it

maybe even a separate cable to the zedboard

yeah

but OTOH, there are USB to Ethernet dongles available nowadays

(the interface)

it just has ethernet, USB, and mini display port (which I use an adapter to DVI)

(and maybe more than sufficient for the ZedBoard boot)

i don't think I was, because it would try to get an IP over dhcp from my router, which I couldn't configure for TFTP

this could work I would think: http://www.amazon.com/DVI-HDMI-Cable-6ft-Male-Male/dp/B0002CZHN6

I'll go ahead and order one

yeah

I've considered purchasing a new desktop to use as a server and have a nice graphics card on it (I've done some GPGPU computing for research when I was at the university)

so what are some of the main areas of development you need help with?

also documentation is always welcome (for all areas)

we did a fake busybox devmem

okay

(notable exceptions are the temperature sensor for example)

I looked through the data sheet a bit ago and looked at how many of the register settings depending on what modes of operation one wants to use. do you guys have an idea of which modes of operation you'd like to demonstrate on the prototype?

we definitely want to play around and test different stuff

yeah

looks like it has a lot of capabilities, but that requires a lot of register configurations

we also want to target highest possible resolution and framerate with 32lanes

and we probably want to test the exposure curves

we definitely want to test the subsampling and windowing

I guess so, probably a smart script which can 'calculate' the settings for given input values/parameters would be a good solution as well

AFAIK, Thomas is working on some sensor related scripts, but I don't know what the current status is

I saw some of the emails from the other guy that helped with some of the exposure script. some of the calculations are a bit hard to read in the script, for me it would be easier to test the calculations in a spreadsheet and then write the script. other people could also easier check the equations than having to read the polish notation

not that you really need it for those calculations

okay. what do you have in mind?

the basic concept is to have something which can tell you exactly what state the sensor is in

how many lanes are used, where they are located, what the image area is, etc

because when something doesn't work as expected while testing with the prototype, I usually have to dig into those registers to find out why

with a mode that just dumps everything?

yes, I guess even cmv_info | grep -i exposure would suffice

yeah that could work

on a different page, we will be bursting sensor data into memory buffers (for snapshots and maybe even short recordings)

the data will arrive in a twelve bit raw format with (yet unknown) alignment

and we need some userspace tools to collect that data and write it in some format we can process/view

i tried a web search and couldn't find much

ok

my first code for that was in python (as it was quick to code), but I'm porting it to C

if that would be of any use

oh yeah

yeah

and they are in the well known bayer pattern

we probably will align every line to 4k

and we will burst/store the pixels (regardless of the number) one after the other

okay, so pleas walk me through the work flow

I ssh to the ZedBoard and start your tool 'A' which connects to the memory area (or receives the data from stdin?)

that could be done

there are two options

like?

or another idea

to generate a demosaiqed image

yeah

but I am off to bed :)

thanks

see you later!

dcraw is free to use

i.e. something like display from ImageMagic

and I guess it should be reasonably fast and allow to view the raw data somehow

yeah

?

i.e. I would ssh into the zedboard executing the image capture tool which outputs the dng

the output on the linux box is then piped into the viewer/converter

primarily for still images

ok, so it wouldn't be the end of the world if after you run the capture program it writes to a file, and then you ssh the file back to your computer to view?

not the end of the world, but definitely annoying ... although I could simply store the file in memory (if it is small enough) and 'cat' it to get the pipe data I'd prefer

but of course, simply dumping the data to stdout would be a lot simpler

does the dng writer need to seek?

not necessarily

so writing to a file and opening that file is perfectly fine

okay, I was thinking dcraw would be compiled on the zedboard

I don't see why we should bother with dcraw on the zedboard

(except for the fun of doing it :)

so I gues you have at least two areas now where you can go crazy the rest of the weekend, yes?

to read a dng you definitely have to do a lot of seeks

I basically have to create an index with the offsets to different TIFF tags and where the image data is located

to add support for raw data

the capture utility can write to STDIO no problem though, since we (or I) would write that.

so from there you could view it with ImageMagic

okay. I'll start working on some code from that

I guess probably just leave it at full resolution? it seems like 4k isn't completely a defined size