Hi, When stacking images vertically the mux board let's the 1st sensor (top image) through w/o buffering in SDRAM. The second is buffered. So, it could be SDRAM phase.
1. What firmware version are you using? ~# cat /etc/issue or ~# cat /etc/release 2. If the firmware is 8.2.16 (hopefully), then the phase settings are available through the camera parameters: http://192.168.0.9/autocampars.php -> check 'unsafe' - in the table you will find: > MULTI_PHASE_SDRAM > MULTI_PHASE1 > MULTI_PHASE2 > MULTI_PHASE3 Check the values from a camera that works ok. And try to fix them for a bad camera from this autocampars page (not 10359_controls.html, which communicates directly with fpga - cannot not store settings across reboots) Once you set the values, go back to http://192.168.0.9/autocampars.php and 'save' the config in the second table. Then reboot. 3. Has anything changed recently? Like you stored a new configuration? Reboot often? Applied any changes? The camera stores and loads its firmware from flash - sometimes the fs or some file there would get corrupted when changes to the filesystem are applied but not properly synced. With a single lens camera most of the trouble was usually caused by /etc/autocampars.xml going corrupt. Then backing it up, removing the file and then rebooting (it autoregenerated on reboot if not there) might help. Note - if you manipulate files manually from a command line - run 'sync' when done. Then repeat step 2 if firmware is 8.2.16. Regards, Oleg On Mon, Jun 22, 2020 at 10:29 AM Simon Vogl <off...@voxel.at> wrote: > Dear all, > > we have a bunch of 353-based stereo cameras that are in operation for > seven years meanwhile and we've been very happy with them. Over the last > weeks, some of them have image errors, at first sight it looks like one of > the sensor is not configured correctly, a combined image looks like: > > I found that this seems to be a problem with the 10359 multiplexer board > -- exchanging this resolves the issue for a camera. > > When booting, the relevant portion of dmesg reports this error on the > affected cameras: > > arch/cris/arch-v32/drivers/elphel/framepars.c:390:initGlobalPars > GLOBALPARS(G_DEBUG)=0 > initSequencers:resetting both sequencers > arch/cris/arch-v32/drivers/elphel/framepars.c:420:initMultiPars > GLOBALPARS(G_MULTI_NUM)=0 > Initializing DMA registers for EXTDMA3 - > sensor clock set to 48000000 > 10359 bitstream version =0x0359a054 > 10353 sensor clock set to 96000000 > 10359A sensor clock set to 96000000 > removing MRST from the sensor > Found MT9P001 2592x1944 sensor on 10359A port 1, chip ID=1801 > Found MT9P001 2592x1944 sensor on 10359A port 2, chip ID=1801 > Setting internal HACT generation > Found MT9P001 2592x1944 sensor, chip ID=1801 > arch/cris/arch-v32/drivers/elphel/framepars.c:420:initMultiPars > GLOBALPARS(G_MULTI_NUM)=f > **** ERROR adjusting SDRAM clock phase in > arch/cris/arch-v32/drivers/elphel/multisensor.c:1697:multisensor_adjustSDRAM > low90=3, low_l=249, high90=3, high_l=-250 > arch/cris/arch-v32/drivers/elphel/multisensor.c:1310:multisensor_pgm_sensorphase > **** ERROR adjusting SDRAM clock phase in > arch/cris/arch-v32/drivers/elphel/multisensor.c:1311:multisensor_pgm_sensorphase, > result=0xffffffff > Resetting MT9X001 sensor > Reading sensor registers to the shadows: > Initializing MT9X001 registers with default values: > Starting hardware sequencers > arch/cris/arch-v32/drivers/elphel/quantization_tables.c:211:init_qtable_head_cache > > > I have tried to set the clock parameters from a functioning specimen via > the /359/10359_controls.html which temporarily resolves the issue, but > after a reboot the problems reappear. > > Any chance to resolve this in software or do we need to exchange boards? > If so - are they still available? > > All the best from Austria, stay healthy, > > Simon > > > > > -- > VoXel Interaction Design | www.voxel.at > DI Dr.techn. Simon Vogl | si...@voxel.at > Tomaschekweg 46 | +43 650 2323 555 > A-4040 Linz - Austria | > Office address: Industriezeile 35, 4020 Linz (2nd floor) > > _______________________________________________ > Support-list mailing list > Support-list@support.elphel.com > http://support.elphel.com/mailman/listinfo/support-list_support.elphel.com > -- Best regards, Oleg Dzhimiev Electronics Engineer phone: +1 801 783 5555 x124 Elphel, Inc.
_______________________________________________ Support-list mailing list Support-list@support.elphel.com http://support.elphel.com/mailman/listinfo/support-list_support.elphel.com
