[Elphel-support] Elphel 353 / 359 stereo camera problem
Simon Vogl
office at voxel.at
Mon Jun 22 11:24:32 PDT 2020
Hi Oleg,
thanks for the timely feedback, let me answer inline:
Am 22.06.20 um 19:44 schrieb Oleg:
> 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.
>
Well, this is definitely involved - when I set the right clock
parameters, I could get reasonable picture content again (although only
on one image).
> 1. What firmware version are you using?
> ~# cat /etc/issue
> or
> ~# cat /etc/release
>
[root at Elphel353 /root]817# cat /etc/release
JFFSID="8.2.15"
close to .16 but not exactly - does an upgrade in the field make sense?
> 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.
>
ok great, will try it this way, guess that's what I was missing.
> 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.
>
The maintenaince guys did a few reboots last week (suspected troubles
with a poe switch) and I am hoping that this is the cause of the
trouble.... I bit-compared the bit files, they're identical to a running
camera. The xml files looked fine as well.
Will try around more and come back to you - thanks a lot!
Simon
> Regards,
> Oleg
>
> On Mon, Jun 22, 2020 at 10:29 AM Simon Vogl <office at voxel.at
> <mailto:office at 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 <http://www.voxel.at>
> DI Dr.techn. Simon Vogl |simon at voxel.at <mailto:simon at 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 at support.elphel.com
> <mailto:Support-list at 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 at support.elphel.com
> http://support.elphel.com/mailman/listinfo/support-list_support.elphel.com
--
VoXel Interaction Design | www.voxel.at
DI Dr.techn. Simon Vogl | simon at voxel.at
Tomaschekweg 46 | +43 650 2323 555
A-4040 Linz - Austria |
Office address: Industriezeile 35, 4020 Linz (2nd floor)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://support.elphel.com/pipermail/support-list_support.elphel.com/attachments/20200622/2cb04474/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: obnfpilahfcneomg.png
Type: image/png
Size: 46589 bytes
Desc: not available
URL: <http://support.elphel.com/pipermail/support-list_support.elphel.com/attachments/20200622/2cb04474/attachment-0001.png>
More information about the Support-list
mailing list