#apertus IRC Channel Logs

I am confused you said the current remapper works in 32sensel mode what does that imply?

please check the CMV12000 datasheet to get an idea what I'm talking about

For the final goal "emulate sensor behaviour and bit stream", the different sensor components will have to be designed, SPI, sequencer, AFE,.....etc. right?

For the image and video generation, is there some kind of a standard algorithm?

Should it be generated based on something or the image can be random pixels with random values?

pseudo random data is very valuable for testing

How can the pseudo random data be valuable while the random won't make sence? And when does it fail?

i.e. it is like noise

off to bed now ... have a good one everyone!

Good night

morning folks!

morning Bertl

url?

tx

there are some inconsistencies in the spacing for std_logic_vector ranges ... space vs no space before the () ... I do not mind which one you use but you should use it consistently

sorry, fixed it

ok, will fix them

no actually I have some timing violations that I wish you could give me hints on how to solve them

in your timing_report.txt, do you know what the line 'Timing constraints are not met.' means?

due to excessive path delay

yep, okay

I think sampling at both edges causes problems, I could reach more than double of this frequency with single edge

Bertl: For changing modes in CMV12000 programming of sequencer register is required using SPI interface do we need to take care of that also?

preetimenghwani[: the SPI programming happens from the Zynq/Linux side so you can assume that the sensor SPI registers are programmed accordingly

omar31: any ideas how to improve the situation or is 200MHz (the version you had without DDR) the upper limit?

you know Lattice TN1203?

so, might any of those solutions apply here?

Bertl: To synchronize zynq with LVDS outputs, training pattern is used is that you mean here?

preetimenghwani[: no, but maybe we are talking about different things here, please rephrase your question

Also it is necessary to to synchronize zynq with the LVDS using training pattern testing on hardware right?

I think the frequency can be increased at the expense of this time

synchronization and deserialization (including link training already happens, but could be improved of course

And also in discription of current remapper it says that one LVDS pin gives out 1 pixel in 1 clock cycle but the pins can give only 1 bit output at a time right?

check the CMV12000 data sheet for all the gory details how the sensel data is transferred

hi max_bxl

meeting tme!

I am!

maxime do you want to start with reporting?

nothing much to report

we try to do a night time liapse

to make any conclusions....

and I put a link to the ambrosia wiki page

check for yourself !https://wiki.apertus.org/index.php/Project_Ambrosia#Media

(the raw12 of the second TL are not online as it was not that interesting)

great, yes tech questions afterwards sounds good to keep the reports brief

hopefully more to come next week ;)

BAndiT1983: anything to share?

managing gsoc related stuff, trying to check the progress of students

other than that making plans for BL and firmware, but had no time to continue yet

BL?

thanks

great, hi vup and oscar

Bertl will share more about this inspection idea I assume when its his turn

vup any progress to report with the micro?

but other than than, nothing new

did you and Bertl plan an ecp5 plugin module already?

not yet

we definitely need 4mil trace and 7mil vias for the 17x17mm BGA

but four layers should be enough

to me it seemed like 0.2mm would also work

very interesting, thanks

anything else vup?

yes tech details after reporting please

right, thank you!

ah great

oscar, anything to report from your side?

yeah, I think I'm ready

so, besides the usual business (rework, design, planning, etc), and a quite intensive GSoC application week

and I also added new board renders for all three Power Board branches we currently have

had to adjust the renderer somewhat because of the obvious ImageMagick changes in v7

After the v1.x power board tests went smoothly last week, I decided to build a complete prototype, but I didn't want to probe the PCBs by hand (before populating them)

the basic concept here for a start is to do a single probe testing

it actually isn't just a single probe, but we'll get that shortly

I removed the filament feeder, the hot-end, the LCD (who needs that anyway? :), replaced the noisy power supply with a relatively silent PC power supply (no hotbed heating required)

I improved a number of things on the Ender-2 as well, mostly with existing MODS but also with some new designs

http://vserver.13thfloor.at/Stuff/AXIOM/PROBE/IMG_20200330_151918.jpg

modifications included: an elevated Z-limit switch and spacer for the Z-stepper: http://vserver.13thfloor.at/Stuff/AXIOM/PROBE/IMG_20200330_152154.jpg

I'll come to that in a minute :)

a Z-axis stabilisation with ball bearing: http://vserver.13thfloor.at/Stuff/AXIOM/PROBE/IMG_20200330_152513.jpg

and finally a stabilization for the hot-bed, which is simply done via nuts

http://vserver.13thfloor.at/Stuff/AXIOM/PROBE/IMG_20200330_152625.jpg

which can be adjusted in height and focus quite easily but is rigidly mounted

no, I'll provide some screenshots from that later

now to the probe itself: http://vserver.13thfloor.at/Stuff/AXIOM/PROBE/IMG_20200330_152415.jpg

I wasn't sure which pogo-pin size would be best for this purpose, so I added two pogo-pin holder for two different sizes

note: there are different probe heads so switching them out makes sense and we'll se what works best

the PIC can be reprogrammed via this converter and also provides probe information via the serial connetion

are you generating singals from the PC?

now the PCB itself is simply mounted on four spacers (the white thigies): http://vserver.13thfloor.at/Stuff/AXIOM/PROBE/IMG_20200330_151935.jpg

BAndiT1983: yes, everything is currently controlled from a PC/laptop

if you look closely at it on this image: http://vserver.13thfloor.at/Stuff/AXIOM/PROBE/IMG_20200330_152702.jpg

you can easily put a flexible wire in there and make a reliable connection to this plated hole

the probe can now use two different probing methods depending on the to-be-probed pads

and the other is by using a nifty trick of the ADC available in the PIC MCU

basically an ADC consists of a sampling capacitor and a circuitry to convert the voltage on that capacitor to bits

first the capacitor is charged to a well known voltage generated by the fixed voltage reference in the PIC

then the probe pin is tied to ground, to ensure that the pad is at a known voltage level as well (0)

this connects the capacitance from the probe (pad and trace) with the sampling capacitor, creating a capacitive voltage divider

we'll see how good that works but preliminary test were promising

is this following the concept discussed at the time? was called something like "one-probe..." analogue measuring?

well, yes and no

and they will weed out most of the problems we had so far

but for prototyping, as we always get 3 boards, it should be fairly easy to spot issues

right, many thanks!

also note that the concept we discussed back then (analog probe)

is not exactly what we do right now, because we do not test with a pulse but instead just use capacitive measurements

understood, great

I'm currently working on attaching a pi-zero with camera

resistance on a brand new PCB is not really that interesting, but we could measure that as well with the existing probe (at least to ground)

next step is to test the probing with the pad information generated from BAndiT1983's script

that's it from my side for this week

anyone else here in the meantime who wants to share/report and didnt so far?

note: applicants are welcome to participate as well

google delayed some later deadlines due to corona virus as a lot of universities are being closed all over the world right now...

*before

for the AXIOM Remote I modified the LCD holder (3d print part) to also hold Bertls additional remote control PCB below: https://cad.onshape.com/documents/12bc6fbd9b32fa10f6c16ff9/w/2b05098c1a8a2447a85fcae9/e/54a0b5d91cb3d6a04f899f00

PCB quotes collection progress is sluggish as suppliers have non engineers do all the customer communication and sales and so they mostly do not understand the technical requirements we have - its always one step forward, two steps back and then two steps forward....hopefully

in particular with the HDMI holder clamp, microphone holder attachment points and now with attaching the AXIOM Remote to the camera together with an NP-F battery. All in concept phase still but progressing.

thats it from me

meeting concluded!

thanks for having us!

\o/

see you!

or even 2048x1536px ?

I find out how to set registers with axiom-cmv-reg.sh

but I plan to update cmv_snap soon so it might make sense to put a wish list on a lab task :)

*ish

done : https://lab.apertus.org/T1168

updated ;)

what I meant was a description what features to add like for example vertical windowing etc

that's the main advantage over subsampling ?

off for now, bye !

Hey bertl, I have a couple of questions if you are free

What is the use of the digital offset in the CMV12k

What about the amplifier? Why would I want to add an analog gain to the pixel?

to get the best out of the sensor, you want to cover a good portion of the digital (ADC) range

instead of just from 23 to 234 for example

I see

you're welcome!

off for now ... bbl

Bertl: please check dm when you get time