[Elphel-support] combining frames

[Andreas Bean]

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 <office at beanbox.com
> <mailto:office at beanbox.com>> 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 <andersonnotgood at gmail.com
>     <mailto:andersonnotgood at gmail.com>
>     > <mailto:andersonnotgood at gmail.com
>     <mailto:andersonnotgood at gmail.com>>> 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 <office at beanbox.com
>     <mailto:office at beanbox.com>
>     >     <mailto:office at beanbox.com <mailto:office at beanbox.com>>> 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
>     >
>     >
>     >
>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: office.vcf
Type: text/x-vcard
Size: 254 bytes
Desc: not available
URL: <http://support.elphel.com/pipermail/support-list_support.elphel.com/attachments/20100326/cbd76970/attachment.vcf>