CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD - page 7 - Creative Uses of CHDK - CHDK Forum
« previous next »
Pages: 1 2 3 4 5 6 [7] 8 9 10 11 12 ... 71   Go Down

CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD

  • 704 Replies
  • 194950 Views
*

Offline SticK

  • *****
  • 779
Re: CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD
« Reply #60 on: 02 / November / 2012, 15:11:42 »
Advertisements
NEW INFORMATION on IS ERROR OVERRIDE ATTEMPT

As described earlier in this thread, when the camera is put into REC mode, the IS goes through a brief self-calibration procedure and then camera centers the lens.  If I obstruct self-calibration by jamming the lens to one side before setting REC mode, E32 occurs about 1 minute later and the camera shuts down.  My original assessment of the operational window therefore was not accurate.  More accurately, even though the lens is jammed (ie in an error-prone condition), the camera does continue to operate (shoot etc) for about 1 minute, but without displaying E32, and then after the minute it displays E32 on the LCD screen and shut down immediately.  So the error condition has to persist for 1 minute before E32 and shutdown.  Thus there is no time to issue the two functions.  Nevertheless I tried this ... if I issue:
  =return('call_event_proc("Mecha.Create")')
  =return('call_event_proc("DisableISDriveError")')
after REC but before shutdown, I get return values 4 and 5 respectively so the calls appear to be swallowed up OK.  But there is no effect // shutdown still occurs.

All this begs the question: can I still use your technique by setting it up *before* the error if I find the exact error as you just suggested by examining the ROM log?

Quote "Newer cameras also have DisableLensError, yours unfortunately not."
Oh so too bad // that's what I am trying to accomplish.  Could there be in the S90 something equivalent, like a general "Disable shutdown regardless of error" that could be dug out of firmware?

By the way, I discovered today that the IS lens assembly has a secondary function and that is to report camera orientation.  After a good self-calibration, subsequent force against the lens changes the orientation icon.
« Last Edit: 02 / November / 2012, 15:13:46 by SticK »
Logged
*

Offline casrap

  • **
  • 90
Re: CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD
« Reply #61 on: 02 / November / 2012, 16:21:13 »
@SticK
My experience with firmware is limited, i only discovered chdk  a few weeks ago. I'm more into the hardware side of things (dslr). But like you i'm looking at possibilities to use ps cameras for astro purposes.
Logged
*

Offline SticK

  • *****
  • 779
Re: CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD
« Reply #62 on: 02 / November / 2012, 16:32:11 »
ROMLOG & PARAMDMP

I had E32s today by jamming the lens which do not appear to be saved in flash.  This last ROMLOG is from yesterday at the time I figure when I reversed the connector //  a hard error -vs- soft error?

Can you conclude anything from this?  Are the two correlated?
Logged
*

Offline reyalp

  • ******
  • 14128
Re: CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD
« Reply #63 on: 02 / November / 2012, 17:28:05 »
Quote from: SticK on 02 / November / 2012, 15:11:42
  =return('call_event_proc("Mecha.Create")')
  =return('call_event_proc("DisableISDriveError")')
If this is a direct copy of what you entered, it is not correct syntax. This would return the literal string call_event_proc("DisableISDriveError")

chdkptp prints the script ID with the return value, e.g.
Code: [Select]
con> =return 1+1
1:return:2
1 is the id of the script that returned the result, 2 is the return value. The fact you get 4 and 5 suggests you are looking at the script ids.

The correct syntax to call the evenptrocs would be
Code: [Select]
=return call_event_proc("Mecha.Create")
=return call_event_proc("DisableISDriveError")
-1 generally indicates an eventproc is not registered, while eventprocs usually return 0 if they don't have any other specific return value.
Logged
Don't forget what the H stands for.
*

Offline SticK

  • *****
  • 779
Re: CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD
« Reply #64 on: 02 / November / 2012, 18:02:42 »
Thanks for the tip.  "Mecha.Create" returns 0 and "DisableISDriveError" returns -1, so it looks like the 2nd function is not available according to what I understand.  Can I register it?  Is there another way I can try this?
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD
« Reply #65 on: 02 / November / 2012, 18:37:10 »
Quote from: SticK on 02 / November / 2012, 18:02:42
Thanks for the tip.  "Mecha.Create" returns 0 and "DisableISDriveError" returns -1, so it looks like the 2nd function is not available according to what I understand.  Can I register it?  Is there another way I can try this?
Try calling "StartImStEventProc" after "Mecha.Create".
Your romlog has this: "Occured Time  2012:10:01 17:33:54", so it's not recent. Canon errors like E32 do not get recorded into the romlog. I can't see anything related in the parameter dump either (the error message should be there as string).
Logged
*

Offline SticK

  • *****
  • 779
Re: CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD
« Reply #66 on: 02 / November / 2012, 21:01:16 »
Hmmm ... all 3 calls returned 0 this time.  More, looks like we have an open door ... this is becoming exceedingly interesting.  I did these tests with the toothpick still stuck in the lens with the known error condition.

) After PUP, REC M, the camera did not shut down for the 5 minutes I left it ON.  ***OK***

) I took a few shots and then issued shutdown, and it shutdown cleanly.  OK.

) Next I left in PLAY mode w/o error override code, and got the E32 error anyway.  Thus E32 does respond to a calibration error whether in PLAY or REC.  OK.

) Same as previous but now ran error override code in PLAY mode.  While in PLAY mode, no shutdown. OK.

) Put into REC mode w/o error override code.  Shutdown after 1 min.  Expected, according to your hypothesis.  OK.

) Restarted again, into REC mode, error override code, NO shutdown.  Still going strong after 20 minutes.

Very promising.  The upshot good news for IS is that the override code can be issued to prevent shutdown after the error condition has occurred, but before shutdown, that nice 1 minute window.  The BIG IF ... if all the other lens errors follow the same course for the window, then it is possible we could override those as well.  That would be the complete solution.  Can we try this with E18 etc?  Try to handle the other lens components?  Is there one specific solution for FOCUS? ... because that is easy to disconnect.

edit:
I can disconnect the IRIS or FOCUS easily for a test.  If I can override IRIS and/or FOCUS for now, I can test the electrical disconnection hypothesis.  ZOOM could be next because I can unsolder the motor leads.  I can go one step at a time.  Since the SHUTTER+IS are one ribbon cable, I'd like to leave that for last once I am confident from the others the disconnection should work // that's because the IS components cannot be disconnected/unsoldered easily without disconnecting the shutter signal.
« Last Edit: 02 / November / 2012, 23:15:12 by SticK »
Logged
*

Offline SticK

  • *****
  • 779
Re: CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD
« Reply #67 on: 03 / November / 2012, 00:02:25 »
IRIS (and FOCUS) ERROR BEHAVIOR

When the camera is PUPed it goes into PLAY mode.  At this stage the IRIS has not been activated and remains in the stowed position.  No error occurs whether the IRIS was connected or disconnected, as long as the camera doesn't go into REC.

When the IRIS is connected as usual, REC mode puts the IRIS out of stowed position into f2 and the liveview appears.

If I disconnect the IRIS before PUP, switching to REC mode immediately goes into error and camera shuts down.  I don't know what the error code is because it happens too fast and is not transferred to liveview, and, because this camera has no button panel, I can't read the code from the camera LCD.  In addition, with IRIS still disconnected, if I try PUP again then there is no USB // camera appears dead to the outside world.  If I reconnect the IRIS the USB comes back to life again.  That means firmware prevents normal restart once an IRIS error was detected and the hardware error condition has been not restored after subsequent PDN/PUP. 

Hence IRIS (and likely FOCUS because of similar topology) does not give the same 1 minute window of opportunity that IS does.

So from these tests what I am thinking is this:
  a) an error override for the IRIS would have to go into effect before the switch to REC mode
       -- and --
  b) that the error override would continue to trick the firmware into believing the IRIS is still connected after PDN.

Is there anything I could do to help me try this out?
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD
« Reply #68 on: 03 / November / 2012, 09:04:40 »
Some event procedures which are registered by Mecha.Create and have no parameters:
"EnableMechaCircuit"
"DisableMechaCircuit"
"EnableFocusPiCircuit"
"DisableFocusPiCircuit"
"EnableZoomPiCircuit"
"DisableZoomPiCircuit"
"EnableZoomEncoderCircuit"
"DisableZoomEncoderCircuit"
"EnableIrisPiCircuit"
"DisableIrisPiCircuit"
I really don't know whether calling these is safe or not... If you feel brave enough, try to experiment with them.
Also, if you find some time to do it, please dump the ROM of your camera with the E32. Would be interesting to know which kind of E32 errors can be prevented from showing up.
Logged
*

Offline SticK

  • *****
  • 779
Re: CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD
« Reply #69 on: 03 / November / 2012, 09:47:52 »
Quote "please dump the ROM of your camera with the E32"
Are you referring to the 8M fw binary?  ROMLOG.LOG?  If it's the binary please confirm and I can get you one.  If it's the ROMLOG, the one I posted here: http://chdk.setepontos.com/index.php?topic=8801.msg92741#msg92741 is the latest I have.  I believe that one occurred when I actually reversed the ribbon cable of the IS.  I have had E32s and an IRIS-disconnected shutdowns since then and those were not saved in the ROMLOG.  It seems to me when (most?) hardware errors occur gracefully they don't generate an ASSERT.

Quote "I really don't know whether calling these is safe or not"
What would be your definition of "safe" ? ... if I can recover camera operation (USB comm) after PDN/PUP reset that would be safe enough for me ... in others words, if these values do not get stored permanently memory, that's OK.

Can you please describe what "Mecha" is and what happens when I call "Mecha.Create" etc?

edit:
Do I have to call "StartImStEventProc" before each one of these, or one call ie "Mecha.Create" then "StartImStEventProc", then a series ...circuit calls?

« Last Edit: 03 / November / 2012, 09:51:48 by SticK »
Logged
Pages: 1 2 3 4 5 6 [7] 8 9 10 11 12 ... 71   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal