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@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 <off...@voxel.at
<mailto: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 <http://www.voxel.at>
DI Dr.techn. Simon Vogl |si...@voxel.at <mailto: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
<mailto: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
--
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
