Hello Oleg, Thank you for the information. Compared to the cam of Andrey & Sebastion the cam we try to build is minimalistic. The reason is, that it should be mounted on flying devices e.g. a quadcopter.
Your cascading option 2, (1 + 1) x10359 would be best, but option 1 is also ok The question is, if the 4 pictures can be combined into one frame. A combination like 1 3 2 4 would be fine. Andreas Oleg Dzhimiev schrieb: > Hi Andreas, > > If you think about cascading 10359s - never tried it. I need to test > if the all the boards are programmed in this case and solve the board > I2C addressing problem. > > For a 4 sensor setup you will need at least 2 10359 boards: > > With cascading 10359 (1x10353): > 1) (1+2)x10359 - this seems to be easy to handle > 2) (1+1)x10359 - not a problem also > > Without cascading: > 1) separate 2x(10359+10353) (so far, this is the most reliable, I think) > > I'll try cascading the boards as soon as I have time and will write > you about the results. > > Btw, Andrey & Sebastian use 3x(3xsensor+10359+10353+10369+HDD) for the > panorama camera. > > Best regards, > Oleg > > On 18 March 2010 11:57, Andreas Bean <[email protected] > <mailto:[email protected]>> wrote: > > Hello Oleg, > > Thank you for fixing these issues! > > Can you answer me please the following question: > For a 4 sensor setup, how many 359 boards do I need? And, what > would be > necessary to combine 4 frames into one image? Can that be done? > Because > I'm currently working on a panorama camera like the one of > Sebastian and > Andrey, but I mine is a two sensor setup. Basically it's working > but the > quality is not satisfying. That's why it might be interesting to > extend > it to a 4 sensor version. > > Andreas > > Oleg Dzhimiev schrieb: > > Dear Andreas, > > > > Sorry it took me so long - was busy with other things. > > I just added an option by which the start of the direct channel > allows > > buffering the second channel. It was less strict before and somehow > > buffering could happen one trigger earlier than direct transition. > > > > Could you please try the latest bitstream (I tried it with my camera > > and so far it works fine): > > > > http://elphel.cvs.sourceforge.net/viewvc/elphel/elphel353-8.0/fpga/x359/x359.bit > > > > Also found and corrected a bug when you could get broken buffered > > frames if the trigger period was so small that the it occurred > before > > the buffered frame was read. And in this case an error writes to > > memory were made. > > > > Oleg > > > > On 8 March 2010 00:33, Oleg Dzhimiev <[email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>>> wrote: > > > > Hi Andreas, > > > > 1. Can you sometimes get correct frames when you switch on this > > mode? Or is this a permanent problem? > > 2. Can the delay disappear if you make stop-start to the mode? > > > > In any case, I'll try to reproduce it. > > > > Best regards, > > Oleg > > > > > > On 7 March 2010 14:26, Andreas Bean <[email protected] > <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>> wrote: > > > > Hello Oleg, > > > > There is a problem with the combining frames mode. On > the combined > > picture the frames are not taken at the same time. > > There is a difference of one frame. Do you know why? > > > > Andreas > > > > > > > >
<<attachment: office.vcf>>
_______________________________________________ Support-list mailing list [email protected] http://support.elphel.com/mailman/listinfo/support-list_support.elphel.com
