CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD - page 26 - Creative Uses of CHDK - CHDK Forum
« previous next »
Pages: 1 ... 21 22 23 24 25 [26] 27 28 29 30 31 ... 71   Go Down

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

  • 704 Replies
  • 195138 Views
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
Re: CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD
« Reply #250 on: 01 / December / 2012, 15:51:22 »
Advertisements
In this post http://chdk.setepontos.com/index.php?topic=6635.0, srsa_4c said "I'm not really a programmer, and if I do code, it's usually not c."

Wow, imagine what you could do if you were a programmer then   :)
Logged
*

Offline SticK

  • *****
  • 779
Re: CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD
« Reply #251 on: 01 / December / 2012, 15:56:14 »
Quote
Are there any side effects (is file numbering or the camera's clock affected)?
I didn't know to check that, but looking at the console file transfer record right now, all looks normal.  The RTC looks good too // not affected.  Of course it remains yet to test with other components.

Quote
Yes. The following version issues DisableISDriveError after each play -> rec transition (after a 2 sec delay).
Two seconds sounds good // it should handle the worst case mecha start up delay by a long shot ... perfect choice I think. 

Quote
You won't need to call any of the above 3 event procedures any more.
That will be *very* handy.  Please look forward to some test results posted by tomorrow I hope.

BTW ... I've documented ZOOM motor behavior, and it looks like a solution may be possible using an ATtiny.  With 6 IOs, it might turn the trick.  I have not used Arduino before, but it looks pretty trivial to burn one of these with an Arduino board.   If that works on the motor, I will attempt a conversion of the three dummies from 555s to an ATtiny.  The hope is to have just 2-3 8-SOICs on the back of the mecha connector.  That would be the next best solution to a firmware solution which I believe appears improbable, correct?  What is you opinion?

@Microfunguy
Quote
Wow, imagine what you could do if you were a programmer then
I'd wholeheartedly second that! 

@srsa_4c
What are your strengths, then?  Are you familiar with ARM (like a BeagleBoard?) under Java for example?
« Last Edit: 01 / December / 2012, 15:58:05 by SticK »
Logged
*

Offline SticK

  • *****
  • 779
Re: CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD
« Reply #252 on: 02 / December / 2012, 10:10:06 »
FW DisableISDriveError TEST RESULT

Fundamentally works, that is, after ->REC there is no shutdown and camera takes shots.  Great step forward. 

Caveat?  Shooting in M mode as usual, I don't know how significant this is but I notice an interference with IRIS.  For example, at idle IRIS is at f/2 (max open on S90),  if I shoot Tv 4s Av f/2 (4 seconds is arbitrary), the IRIS steps up to what appears as f/3.2 momentarily (maybe 200-300 ms), then opens to f/2 and takes the shot.  The same occurs with shoot Tv 4s Av f/8: IRIS also momentarily stops at 3.2 before going to f/8 to take the 4second shot.

Could this be a problem?  I have not checked anything else for interference.

edit:
I found the problem ... my side ... I had previously set Canon to f/3.2 manually and did not reset back to f/2.  So when you issue the shoot cammond with Av override, Canon actually stops down the IRIS to the Canon menu value momentarily before executing your Av override.  That is interesting.

So srsa, *absolutely* brilliant, in the UK sense and the American sense!
« Last Edit: 02 / December / 2012, 10:23:49 by SticK »
Logged
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
Re: CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD
« Reply #253 on: 02 / December / 2012, 11:19:31 »
Just remind me, which bits are currently disconnected ?
Logged
*

Offline SticK

  • *****
  • 779
Re: CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD
« Reply #254 on: 02 / December / 2012, 11:42:54 »
If you are referring what I call "Canon lens components" or "components" for short, the IS is currently disconnected and camera continues to work.  srsa's newest solution covers two important aspects: a) suppressing PUP component auto-test, and b) IS error disable.  That means, with IS disconnected, all that is needed to do is boot from his last FW and go ->REC.  You don't need to issue the lua commands anymore.  And ... you can now cycle REC->PLAY|PDN  PUP|PLAY->REC *without* having revive the camera with the very clumsy and damage-prone temporary component reconnect.  So the FW part of the entire solution is perfect, with IS for now.  It remains to test with the other components.

Hence ... I am presently building HW dummies for IRIS, FOCUS, and ZOOM unstow.  Because the HW solution is uni-directional (ie covers PLAY->REC unstow only, fails REC->PLAY), his solution is supposed handle the REC->PLAY FAIL condition as though it hadn't happened.  That will be the BIG test, probably tomorrow if lucky.
« Last Edit: 02 / December / 2012, 11:50:27 by SticK »
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD
« Reply #255 on: 03 / December / 2012, 12:16:19 »
Quote from: SticK on 01 / December / 2012, 15:56:14
That would be the next best solution to a firmware solution which I believe appears improbable, correct?
It's complicated and may not happen, so if you want a solution that is working, you should go for the external dummy circuits.
Logged
*

Offline SticK

  • *****
  • 779
Re: CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD
« Reply #256 on: 03 / December / 2012, 12:53:58 »
Good to know.   In any case IRIS and FOCUS unstow electric dummies should be up today.  That should be enough to validate the general solution. 

If it works (I expect so), the ZOOM motor will have to be dealt with by a microcontroller // if possible // not sure yet, likely a good two weeks work.  Should you ever manage to achieve a complete FW dummy by the way, then I'd be happy to replace all the electric dummies with your solution.

If we can eliminate the ZOOM motor, there is an important function that will be needed to complete the PFP arrangement:
  ==>> A time-predictable PHANTOM FULL ZOOM when ->REC.  Is there a way to issue a FULL ZOOM by FW, sort of like what you did for DisableISDriveError?  Ideally, it would go to FULL ZOOM in one shot just after unstow of the ZOOM lens.  The reason for this is that at wide angle which is the default ->REC position, the camera applies barrel correction to the images (the JGPs), and that distorts a PFP CCD image.  No correction is applied when the lens is at the FULL ZOOM position.  So in order to create an electric dummy that respects the FULL ZOOM, I will have to simulate the encoder revolutions in the dummy microcontroller, and predictable timing will be very useful to develop the microcontroller firmware.

Can you think about this and let me know?

« Last Edit: 03 / December / 2012, 12:56:28 by SticK »
Logged
*

Offline SticK

  • *****
  • 779
Re: CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD
« Reply #257 on: 04 / December / 2012, 01:28:41 »
NO IS & NO IRIS // TWO TO GO

IRIS electric phototransistor dummy with srsa solution passes concept-proof.  IRIS was adjusted to ~715 ms unstow.  The 1.5 ms board-generated pulse passes through as required.  The IRIS motor is dummy-loaded so it appears good to the mainboard driver.  In fact, everything worked first time.

The most important part of this functionality is seamless REC->(PLAY|PDN) and (PUP|PLAY)->REC ->M >shoot etc: it works perfectly.

So now the whole solution can move forward.  It will be easy to find the unstow tolerance window.

Tomorrow: FOCUS
Logged
*

Offline SticK

  • *****
  • 779
Re: CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD
« Reply #258 on: 04 / December / 2012, 12:48:26 »
@srsa_4c
FOCUS DUMMY TEST

With IS, IRIS and now FOCUS disconnected, on first PUP->PLAY->REC ->M shoot, all worked as predicted, another major step forward. 

However, when going back REC->PLAY, it showed "E32 lens error restart camera" message in the viewfinder and closed PTP (recall we are not providing "good stow" dummies).  So unlike IRIS, FOCUS is "more sensitive" to a lens error, which conceptually overrides your lens test bypass solution.

Next after the error and PDN, the camera was unable to revive with the electronic dummies.  That means unlike IRIS stow fail, when FOCUS stow fails, the camera changes unstow timing and expectancy windows on the next PUP, and we end up in an endless loop with no way out.  The converse would be to make a dummy stow fake for FOCUS that would not generate the error and REC->PLAY mode would work.  That is a hardware solution possibility, but is rather complicated.

The result of all this had a trickle effect: *both* FOCUS and IRIS Canon components had to be physically reconnected to revive the camera.

Could there be another override, flag etc, different from the current one, in the code that is affected by FOCUS?  From the code perspective, could you please share your thoughts on this caveat?

Code: [Select]
Canon PowerShot S90
P-ID:31E1  NT D
Firmware Ver GM1.01A
Oct 28 2009   15:47:24

Adj Ver.005.001             
Mecha Firm Ver.  2.02

2012.12.04 11:46:16  E18 IrisError  (finally revived after hardware reconnect)
2012.12.04 11:45:04  E18 IrisError
2012.12.04 11:44:08  E18 IrisError  =>> trickle effect
2012.12.04 11:40:17  E18 FocusLensError  REC->PLAY : "E32 lens error restart camera"
2012.12.03 22:31:27  E32 ISDriveError  <<== always handled
2012.11.30 12:16:56  E32 ISDriveError
2012.11.30 12:10:40  E32 ISDriveError
2012.11.29 15:39:44  E32 ISDriveError
2012.11.29 15:38:28  E32 ISDriveError
2012.11.27 22:22:48  E32 ISDriveError
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: CHDKPTP: S90 Primary Focal Plane Configuration - hacking out the CCD
« Reply #259 on: 04 / December / 2012, 16:28:09 »
Quote from: SticK on 03 / December / 2012, 12:53:58
The reason for this is that at wide angle which is the default ->REC position, the camera applies barrel correction to the images (the JGPs), and that distorts a PFP CCD image.  No correction is applied when the lens is at the FULL ZOOM position.
I have found some routines in fw which appear to be related to lens distortion correction (firmware module: CorrectDistorTBL.c). These are called in a task named DevelopModule, which I think is responsible for the "development" of still images. So, instead of zooming there might be an easier way to disable lens distortion correction. I have not investigated this yet.

Quote from: SticK on 04 / December / 2012, 12:48:26
However, when going back REC->PLAY, it showed "E32 lens error restart camera" message in the viewfinder and closed PTP
I would expect E18, as it appears in your firminfo.
Quote
Next after the error and PDN, the camera was unable to revive with the electronic dummies.
I haven't expected something like this. Seems like your terminology was more correct and there are error flags stored somewhere.
Quote
That means unlike IRIS stow fail, when FOCUS stow fails, the camera changes unstow timing and expectancy windows on the next PUP, and we end up in an endless loop with no way out.  The converse would be to make a dummy stow fake for FOCUS that would not generate the error and REC->PLAY mode would work.  That is a hardware solution possibility, but is rather complicated.

The result of all this had a trickle effect: *both* FOCUS and IRIS Canon components had to be physically reconnected to revive the camera.

Could there be another override, flag etc, different from the current one, in the code that is affected by FOCUS?  From the code perspective, could you please share your thoughts on this caveat?
My problem with these (focus, zoom, iris) hw parts is that all of them are controlled by state machine code in the firmware, which consist of several dozen functions each. They are too complicated for me. I'm trying to "attack" these monsters with various methods, but there still isn't any useful progress. I would have to dig out and duplicate many of their code to even getting a clue about their operation (side note, in case somebody could help with it: I've tried using Magic Lantern's cache hacks, but they haven't had any effect - I suspect that VxWorks frees up the locked cache somehow).

Can you try the following:
- What happens when you shut down the camera from REC mode? Can the camera start normally after it?
- Is the failure at rec->play transition related to lens retraction? There's a setting in Canon menu about lens retraction, what happens if you set that to "1 minute" instead of "0 sec."?
Logged
Pages: 1 ... 21 22 23 24 25 [26] 27 28 29 30 31 ... 71   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal