[Elphel-support] Elphel 353 / 359 stereo camera problem

Mon Jun 22 11:35:41 PDT 2020

Yes, 8.2.15 should be fine too... as long as you find the MULTI_*
parameters.
Regards,
Oleg

On Mon, Jun 22, 2020 at 12:25 PM Simon Vogl <office at voxel.at> wrote:

> 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> 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   |  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
>> 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 listSupport-list at support.elphel.comhttp://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)
>
> _______________________________________________
> Support-list mailing list
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://support.elphel.com/pipermail/support-list_support.elphel.com/attachments/20200622/16d41a80/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/16d41a80/attachment-0001.png>