#apertus IRC Channel Logs

Good morning Bertl

meeting time

please again message me now if you want to report

Hi everyone!

so I continued in the development of the core, completed the 0xFF fixer module and optimized two modules, then I put everything together and tested it on fpga.

I did several basic testing with several images, and it worked correctly but timing and efficiency is still something to work on.

that would be all, and I would like to get samples of a noisy images out of the sensor please

I found this, https://files.apertus.org/AXIOM-Beta/snapshots/BetaRawTests/2.2.2016-PropsRawSnaps/

there are tons of pictures here

but its hard to say which ones are the most noisy...

there are gainx4 raw12 files

great! I will test them out, the idea is that the noiser the image the bigger its size, that mean it will take more time to compress and go through usb, so the worst case frame will determine the maximum fps

what will you do, if a image compresses worse than that empirically determined "maximum"

will the compression be lossy or will frames be dropped?

hm... is there any "easy" way to make the compression lossy in that case

not sure either, we want to just drop frames...

lets discuss the details afterwards if that is ok for you?

sure I will be here to discuss it further

Can I start?

That would be all se6astian, thank you!

Hi everybody :)

So this week I completed major part of Zynq side of gearwork ie the BER testing model for the USB 3.0 module

I am successfully being able to setup 6 LVDS lanes between the USB module and Virtex-5 FPGA, and tested them by sending a 6-bit word to the HOST PC through the USB module :)

Also I formatted and cleaned up the code along with MAKEFILEs for the evaluation. Currently I am ahead of timeline :).

After that I will implement the ECC and CRC.

great, many thanks!

was any BER testing done so far?

*500MHz

I see ...

sorry Bad Internet

This week, I have added static allocators for playback and they are working fine MLV files.

that's it

BAndiT1983: any comments/questions?

Hi all,

can*

Time was also spent on researching which one is better . Could'nt find anything significant to discard either approach.

Implementation of "gamma_conf.sh" in daemon was delayed this week due to the reworking of I2CAdapter.Will try to make up for it this week

Thanks ,That would be all from my side.

so I2C register values can now be retrieved and set via daemon?

would be nice to see some of the I2C related scripts adapted to this

well, that certainly wouldn't work too well in a script :)

GetPac1720Info() could have a loop to avoid manual +=

sure

Y_G, this is another side of the story

aSobhy: please go ahead

Hi everyone

I choosed the hardest way to generate the seed of PRNG after Bertl told me the easy way

here what I have done https://github.com/aabdosobhy/Bi-Direction-packet-protocol

and I stucked in the desrilizer at the MachXO2 for a long time I used a seriliazer OSERDESE2 with SDR mode as my design and didn't find a primitive to receive it

the OSERDESE2 at the ZYNQ side

okay I should ask earlier

ah yes, it is even part of the 'useful links' section of the qualification task :)

ah, not qualification but task description

so again aSobhy & Bertl may I ask you to discuss the details after the reports?

sure

hi! i've written the video frame timing generator for photonsdi (that thing was way more convoluted than i expected) and fixed quite a few bugs when doing some build tests of the modules i had already written. no tests on real hardware and no a/b tests in simulation yet though

yeah

thanks for the update felix_ - I hope you can continue to work on this now

https://github.com/niratubertc/PIC16_blink

I should improve the explanation, but you can have a first look

I use pic32prog for uploading icsp_ser.hex on the PIC32, for being able to program PIC16

(KME on this case)

no big updates from my side this time, we went over to the equipmentcafe today - its not actually a cafe, its a equipment rental facility for cinema gear

with lenses and base plates

Bertl: do you want to provide the closing words as usual

nah, we can skip the closing words and dive into individual discussions :)

right!

please discuss the task details and next steps

also make sure that you are available during the evaluation period

well, I'd say it is the main functionality we are looking for, i.e. a way to modify all the scripts to use the daemon

Hmm, we may do this with a command like "./DaemonCLI i2c_module set i2c1_reg 0x38 0x01 b"

better add separate i2c modules, like i2c1_module or so, although you can also omit _module

do we need to control it from command line?

also chip address can be replaced by module, or not?

Bertl: I'm on the document now any advice?!

busAddress can be replaced with different modules. the command works like this `i2cset busAdd chipAdd dataAdd value`

aSobhy: there is no SERDES in the MachXO2s, but there is quite some capable DDR mechanism

note that a read=modify-write operation might be nice to have though

It is not necessary to change the ZYNQ side to DDR but the clk freq. on the MachXO2 will be 1/2 the freq of ZYNQ, right?

you can get up to 8:1 gearing on the MachXO2

can that happened not use the same design on both side

okay

please check it !

I wanted to confirm that , Can I go for adding sliders to playback.

Fares: yes, it is expected to see different compression sizes

dev__, will check it when i have some time, but not today, as i had pretty long day at work and a lot of coding was done

Fares: the simplest option is to have fixed frame slots and just pad smaller frames to the maximum

Okay , till then , I will try make a action plan for how to do it ? and read about MVP and other things

*thought

i remember

if you need an example then take a look at OCBackup and how data and events are passed around, event bus, signals etc.

Nice , That would be helpful

@bertl: that assume 100% utilization of usb3.0 bandwidth correct? I think that is not doable, since if compressed image is small, we are still bounded by the inputted pixels/clk so there will be gaps in the output stream, for example if two pixels/clk, the minimum time to input all pixels to the core @100MHZ for 4096*3072 is 31.45728ms

no there is no point in planning (size wise) for the worst case

and just make sure that frames which cross that amount can be identified

the sky is the limit, but you always end up with a 'worst case' which cannot be handled unless you have the full raw bandwidth or allow for lossy compression

how difficult is it to apply lossy compression?

Hi alex

annuejn: LJ92 is not designed to be lossy, although it can be done if we smooth the pixel values first

alexML: except that we do not have 'memory' to fill

ah tx, just read the wikipedia article

(and, 56% to 67% are typical numbers for us, too)

yes

http://theory.uchicago.edu/~ejm/pix/20d/tests/noise/noise-p3.html - fig. 18

if the bit depth is too low, you get posterization; if the bit depth is too high, it no longer makes a big difference

(that was at 11 bits at ISO 100 on 5D Mark III's sensor)

but how can this be applied to the beta?

how about: shorter exposure time in low light situations?

compared to what?

so you are saying that a 2x vs 1x analog gain doesn't provide any advantage over a digital gain of 2x, yes?

so, if you change the gain from 1 to 4, you get 0.4 stops of less noise in shadows, at the expense of 2 stops of highlights

well, that might be right, but if you can run at 60FPS instead of 15FPS it might be beneficial, no?

well, if there isn't enough light for a gain 1x to fill the 12bits

between gain 1 and 2, the difference may be noticeable, but between 2 and 4... not so much

of course, but that bit will have mostly random noise :)

yes

also, did you evaluate the 'gigabytes of data' we collected with the different sensor frontend configurations?

because I'm pretty sure we can still improve on the noise side

(DRAM refresh cycle neded)

k, cya

Bertl: I have question regarding overclocking and timing analysis, I do timing analysis on vivado with zynq7010-1 part on synthesized desing, is that similar to the beta configuration?

@overclocking: not sure how your do that, but it is likely the wrong approach

this will guarantee that the design can work at both speeds under 'normal' circumstances

okay, thank you!

np

off to bed, good night

nn