G11 issues - page 3 - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: 1 2 [3]   Go Down

G11 issues

  • 29 Replies
  • 10546 Views
*

Offline koshy

  • *****
  • 1096
Re: G11 issues
« Reply #20 on: 11 / September / 2019, 18:28:57 »
Advertisements
Quote from: reyalp on 11 / September / 2019, 15:50:17
Great, from the response times it looks like buffers are correct for fast MD. I'll check these changes in once I implement them for the other firmware versions.
Glad to have done this with you. This fast MD business, is that limited to select cameras or the whole lot? Can you grep - or whatever one does on Windows - all cameras that do not have CAM_AF_LED defined as camera_set_led identifier for AF in platform_camera.h? If so I could do the same thing (identify the AF Beam LED) for any cam I have that needs it.
Logged
Koshy had a little ELPH which wasn't white as snow but everywhere that Koshy went the ELPH was sure to go. (actually an SD, but that detail ruins the rhyme...)
*

Offline reyalp

  • ******
  • 14128
Re: G11 issues
« Reply #21 on: 11 / September / 2019, 21:49:31 »
Quote from: koshy on 11 / September / 2019, 18:28:57
This fast MD business, is that limited to select cameras or the whole lot? Can you grep - or whatever one does on Windows - all cameras that do not have CAM_AF_LED defined as camera_set_led identifier for AF in platform_camera.h? If so I could do the same thing (identify the AF Beam LED) for any cam I have that needs it.
Hmm. The main part of fast MD is having vid_get_viewport_live_fb correctly implemented. Having the AF LED lets you use MD_tune to verify the implementation is correct.

Grepping to find out if vid_get_viewport_live_fb is implemented (not just returning 0) would be a bit complicated but possible. It won't tell if the implemented ones actually work though.

Knowing which set_led number corresponds to which LED would be nice outside of just MD testing, but going through all the cams would be pretty tedious.

If you're looking for things to test, the chdkptp test I mentioned earlier would be nice to have over a range of cameras
Code: [Select]
chdkptp -e"exec require'camtests'.runbatch{bench=true,xfersizebugs=true,filexfer=true}"
This will detect cameras like D10 which crash if the native buffer workaround isn't enabled, and generally stress test the PTP system (background https://chdk.setepontos.com/index.php?topic=4338.msg140877#msg140877).
Logged
Don't forget what the H stands for.
*

Offline koshy

  • *****
  • 1096
Re: G11 issues
« Reply #22 on: 12 / September / 2019, 10:27:33 »
Quote from: reyalp on 11 / September / 2019, 21:49:31
The chdkptp test I mentioned earlier would be nice to have over a range of cameras
Code: [Select]
chdkptp -e"exec require'camtests'.runbatch{bench=true,xfersizebugs=true,filexfer=true}"
Ok, thought I'd weasel around it as the chdkptp setup didn't come together readily the other day  ??? But on revisiting it it just seems that current everything moved beyond what works... Attaching G11 result.

Also - perhaps useful to someone - I did write down what I did to compile CHDKPTP on some windows box...

Code: [Select]
Get: i686-4.8.2-release-win32-dwarf-rt_v3-rev2.7z
from: https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.8.2/threads-win32/dwarf/
And: msys+7za+wget+svn+git+mercurial+cvs-rev13.7z
from: from https://sourceforge.net/projects/mingwbuilds/files/external-binary-packages/

Unzip both into same directory to get suitable dev environment with msys shell.

For chdkptp chek out the latest version from the SVN.
In it create subfolder: extlibs/built/
And in that subfolders: "cd" "iup" "lua52" "libusb-win32-bin-1.2.6.0"

POPULATE WITH CONTENTS OF:
libusb-win32-bin-1.2.6.0.zip
from: https://sourceforge.net/projects/libusb-win32/files/libusb-win32-releases/1.2.6.0/

lua-5.2.4.tar.gz
from: https://www.lua.org/ftp/

cd-5.9_Win32_mingw4_lib.zip
from: https://sourceforge.net/projects/canvasdraw/files/5.9/Windows%20Libraries/Static/
in its lua52 subdir put contents of: cd-5.9-Lua52_Win32_mingw4_lib.zip
from: lua52 subdirectory of the above URI

iup-3.16_Win32_mingw4_lib.zip
from:https://sourceforge.net/projects/iup/files/3.16/Windows%20Libraries/Static/
in its lua52 subdir put contents of: iup-3.16-Lua52_Win32_mingw4_lib.zip
from: lua52 subdirectory of the above URI

With all in place call make from msys to build chdkptp

At some point later precompiled versions of "iup" and and "cd" stop working. Didn't find out where exactly but the current ones don't work as they seem to have been built in different environments.
EDIT: Re-ran tests and updated *.txt file. "mfilexfer:failed Permission denied" stuff was mine to fix...
« Last Edit: 12 / September / 2019, 12:17:37 by koshy »
Logged
Koshy had a little ELPH which wasn't white as snow but everywhere that Koshy went the ELPH was sure to go. (actually an SD, but that detail ruins the rhyme...)
*

Offline reyalp

  • ******
  • 14128
Re: G11 issues
« Reply #23 on: 12 / September / 2019, 15:43:11 »
Quote from: koshy on 12 / September / 2019, 10:27:33
EDIT: Re-ran tests and updated *.txt file. "mfilexfer:failed Permission denied" stuff was mine to fix...
Thanks. I've also seen intermittent file permission errors on windows that I haven't figured out yet :(

The one failure on reconnect I think is another "normal" one that depends on timing.

I noticed this port doesn't have remoteshoot support, so that's something that could be added/tested. I think @nafraf actually implemented it at some point but didn't get test reports.
Logged
Don't forget what the H stands for.
*

Offline koshy

  • *****
  • 1096
Re: G11 issues
« Reply #24 on: 12 / September / 2019, 18:33:21 »
Quote from: reyalp on 12 / September / 2019, 15:43:11
Thanks. I've also seen intermittent file permission errors on windows that I haven't figured out yet :(
I figured I'd give my CHDKPTP source folder an NTFS Permission setting for "Everyone" and "Full Control" which I typically don't. Also I started the test from an elevated shell. Not much more one can do. No idea if that had any effect or if it was pure chance but the permissions stuff evaporated.

Quote from: reyalp on 12 / September / 2019, 15:43:11
I noticed this port doesn't have remoteshoot support, so that's something that could be added/tested. I think @nafraf actually implemented it at some point but didn't get test reports.
That would make sense, back when I tested this for a lot of cameras and @nafraf did the coding I had no G11, it just cropped up and who knows once those parts from China come in maybe I'll fix it maybe I'll ruin it, I'm inclined to think it shall be the former but who knows. I took off the strap and the hinge the strap goes through is as corroded as the inside of that display was. This camera saw saltwater I think. Never a good thing. Perhaps I'll open up the main body once I fix the LCD to be sure it was just a light soaking to that one side but who knows... Well, it will be enough to complete the tests with anyway and I'll try not to break it before adding FWT ;-)
« Last Edit: 12 / September / 2019, 18:36:17 by koshy »
Logged
Koshy had a little ELPH which wasn't white as snow but everywhere that Koshy went the ELPH was sure to go. (actually an SD, but that detail ruins the rhyme...)
*

Offline reyalp

  • ******
  • 14128
Re: G11 issues
« Reply #25 on: 13 / September / 2019, 01:56:33 »
Here's a build with nafraf's code integrated into the latest trunk. It should have remoteshoot support. There was a sort of ambiguous bug report from when he originally posted it: https://chdk.setepontos.com/index.php?topic=4647.msg123365#msg123365

I also turned on the building the "firm update" file. This was reported not to work in the original port: https://chdk.setepontos.com/index.php?topic=4647.msg46078#msg46078

May be hard to test without a working display. You can do the firm update process over PTP, the connection will drop after you confirm, and if everything is working you should be able to reconnect. However, I don't know if doing the firm update while already running CHDK would impact the original bug.
Logged
Don't forget what the H stands for.
*

Offline koshy

  • *****
  • 1096
Re: G11 issues
« Reply #26 on: 13 / September / 2019, 08:26:48 »
Quote from: reyalp on 13 / September / 2019, 01:56:33
I also turned on the building the "firm update" file. This was reported not to work in the original port: https://chdk.setepontos.com/index.php?topic=4647.msg46078#msg46078
Display is flaky again which is good. FW Update reboots the camera, displays E31 and shuts down. SHort after the display went into never never land again - black and blank. E31 is at the top of the screen one line above that is not displayed so there may have been something else...
Logged
Koshy had a little ELPH which wasn't white as snow but everywhere that Koshy went the ELPH was sure to go. (actually an SD, but that detail ruins the rhyme...)
*

Offline koshy

  • *****
  • 1096
Re: G11 issues
« Reply #27 on: 13 / September / 2019, 08:27:33 »
Quote from: reyalp on 13 / September / 2019, 01:56:33
Here's a build with nafraf's code integrated into the latest trunk. It should have remoteshoot support. There was a sort of ambiguous bug report from when he originally posted it: https://chdk.setepontos.com/index.php?topic=4647.msg123365#msg123365

Quote from: nafraf on 19 / August / 2014, 23:43:56
I think the following steps are enough to test remote capture, the same steps should be executed using single capture and continuous shooting mode:

  • Connect to camera using chdkptp
  • Go to REC mode
  • Set single capture | Set continuous shooting mode
  • Set maximum resolution
  • Set maximum quality
  • Remote capture (jpg)
  • Back to play mode
  • Check if camera connection is working

I thought there was more to it... Found it, good.

Quote from: reyalp on 21 / August / 2014, 22:51:44
Probably obvious, but just in case: for continuous mode you should test a burst of several shots, like
rs -jpg -cont=5
« Last Edit: 13 / September / 2019, 08:32:39 by koshy »
Logged
Koshy had a little ELPH which wasn't white as snow but everywhere that Koshy went the ELPH was sure to go. (actually an SD, but that detail ruins the rhyme...)
*

Offline koshy

  • *****
  • 1096
Re: G11 issues
« Reply #28 on: 13 / September / 2019, 08:35:26 »
Quote from: reyalp on 13 / September / 2019, 01:56:33
Here's a build with nafraf's code integrated into the latest trunk. It should have remoteshoot support.
It does, tested FWT in single and continuous mode with the old testing instructions. Worked fine. No connection problems on Rec / Play / Rec either.
Logged
Koshy had a little ELPH which wasn't white as snow but everywhere that Koshy went the ELPH was sure to go. (actually an SD, but that detail ruins the rhyme...)
*

Offline koshy

  • *****
  • 1096
Re: G11 issues
« Reply #29 on: 21 / November / 2019, 19:53:17 »
As a follow up to this, with the parts from China the camera got fixed alright. The LCD bit was a bit tedious because the metal frames did not match and the original and the new one had to be taken apart and re-combined. Either what I got had a slight defect or I broke something minor in the process. I now have a working LCD with one dead vertical line of pixels. It's bearable, like a grid line but I guess at below $10 I'll get another LCD one of these days and fix it fully early next year.
Logged
Koshy had a little ELPH which wasn't white as snow but everywhere that Koshy went the ELPH was sure to go. (actually an SD, but that detail ruins the rhyme...)
Pages: 1 2 [3]   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal