#apertus IRC Channel Logs

there will be a lot we learn from the actual implementation and it will require some discussion/brain storming what can be improved in the future

Aha okay, i will include this in the sched.

Thanks so much for your time

hello

But I don't know how to use it...

best check with BAndiT1983|away when he comes back

np

Please review and comment on my first draft of the proposal so that I can improve it more https://docs.google.com/document/d/1kGqTBqHNRu6QBCnJ3S3Zgqod8BQ911QnNTKBaGmsdFg/edit

hey

Morning folks.

hi

Hello

Please note that I am still working on the appendix section. The rest of it is mostly complete

Thanks

Thanks, I had to change the file name, so proposal can now be found here: https://github.com/usmanwardag/gsoc17_proposal/blob/master/proposal.pdf

nitpick: in the introduction, you mention a single FET for the regulator, but in your schematic, you have the 'typical' two FETs for a synchronous buck where the diode is replaced by the second MOSFET

yes, correct

the reason for this is that strictly speaking you do not want to change Vf in the feedback block but you need to change in+ to create e.g. hysteresis

okay

5.6 s/youll/you'll/

Ah, TeX ommitted that, I will correct it

otherwise it looks good to me.

Okay

like for example ADC vs comparator (we still have no clue if the ADC would be worth the trouble, space and I/Os)

Alright, I will look through the logs

we will have 8+ switchers on the power board (most likely implemented in a single FPGA) for the 8+ power rails

otherwise there will be oscillation on the input rail

btw, Intersil has a number of nice documents regarding buck topologies and how to improve for certain conditions

Yes, I followed one by Texas Instruments. I will see if I can find other resources

Bertl, are maximum pf 2 parameters sufficient to set the registers of CMV? i know that gain required gain (of course) and ADC range, or can they be set separately?

don't think that would be enough, the image regions are for example a lot more complex than that

i've planned also to provide possibility to set parameter as payload with length, in short byte array

in general it might be worth to keep a register shadow and update the registers with some kind of commit

i.e. let the user 'modify' registers in a buffer with separate commands (keep them simple)

I thought about implementing this in the FPGA, which might be overkill but might also be a good idea to ensure that those changes happen at the right time

the memory mapped cmv registers are a direct interface to the SPI bus

so whatever you read will come directly from the sensor and what you write will be written immediately

haven't had time to think this through, but you can create a lab task for it so that I remember :)

just want to set a plan beforehand, as gsoc is approaching

task added, feel free to correct it, if it's not clear enough or wrong

tx

no problem, lab maintenance is important

i hope our lab will be updated at some point to the newest version

https://secure.phabricator.com

doesn't look very different to me

don't know if ours already has such infos -> https://secure.phabricator.com/T9893

possibly that they just renamed/added the project assigning to tags

\quit

off for now ... bbl

As far as I know admin was asked to update it over a month back.

Aye, like sorting my phone out finally. You're right.

(but this is worked on already)

Linux

off to bed

nn