a 3D printed "fake" battery adapter - page 2 - Hotwire! Hardware Mods, Accessories and Insights - CHDK Forum supplierdeeply
« previous next »
Pages: 1 [2]   Go Down

a 3D printed "fake" battery adapter

  • 16 Replies
  • 5340 Views
*

Offline apaolucci

  • *
  • 6
Re: a 3D printed "fake" battery adapter
« Reply #10 on: 03 / February / 2015, 04:49:24 »
Advertisements
@reyalp It seams a good opportunity. Unfortunately I have to redesign the battery, since the commercial one doesn't use the third pole and so I have not implemented it. I'll design a new one with 3 pole and cable. I suppose that for the third pole is not necessary a 16 gauge wire, is it right?
Logged
*

Offline waterwingz

  • ******
  • 12123
    • Waterwingz
Re: a 3D printed "fake" battery adapter
« Reply #11 on: 03 / February / 2015, 07:48:10 »
Quote from: apaolucci on 03 / February / 2015, 04:49:24
I suppose that for the third pole is not necessary a 16 gauge wire, is it right?
That  is right - a smaller wire will be fine.  You might want to put the resistor in the battery too.
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline apaolucci

  • *
  • 6
Re: a 3D printed "fake" battery adapter
« Reply #12 on: 04 / February / 2015, 10:29:10 »
Hi all, I've made some tests last night implementing these improvements:
  • Remade the wiring of the battery using a 1,5mm^2 wire (I don't know how many gauge is but is more than 16), ie a normal electrical wire
  • Parallel wiring from power supply and batteries, so that daisy chain was no more a problem
  • Power on sequentially 3, 4 and 5 cameras as compare test

The result was extremely cheering, since the cameras worked ok. :D :D
As expected with 5 cameras (as said by waterwingz) I experiment again voltage drop with two cameras shoutdown. So for 1 power supply max 4 cameras. That's good! :D

But "All that glitters ain't gold!" ... since I've experimented two chdkptp software bug (I believe), as reference I'm using chdkptp v658 executable and chdk v1.3 stable build 3947.
I try to detail it, the sequence of commands to init the cameras in chdkptp console (I do not use gui) I use is:

Code: [Select]
!mc=require('multicam')
!mc:connect()
!mc:start()
!mc:init_sync()
!return mc:cmdwait('rec')
and everything works ok, than to shot the photos I send:

Code: [Select]
!return mc:cmdwait('preshoot')
!return mc:cmdwait('shoot_hook_sync',{syncat=100})
here I received the first error, as reported by the log:

Code: [Select]
___> !return mc:cmdwait('shoot_hook_sync',{syncat=100})
1:shoot_hook_sync 42883
2:shoot_hook_sync 41570
3:shoot_hook_sync 40335
4:shoot_hook_sync 38953
=true,{
 [1]={
  done=true,
  failed=true,
  status={
   status=true,
   cmd="shoot_hook_sync",
  },
  err="status from unexpected cmd:shoot_hook_sync",
 },
 [2]={
  done=true,
  failed=true,
  status={
   status=true,
   cmd="shoot_hook_sync",
  },
  err="status from unexpected cmd:shoot_hook_sync",
 },
 [3]={
  done=true,
  failed=true,
  status={
   status=true,
   cmd="shoot_hook_sync",
  },
  err="status from unexpected cmd:shoot_hook_sync",
 },
 [4]={
  done=true,
  failed=true,
  status={
   status=true,
   cmd="shoot_hook_sync",
  },
  err="status from unexpected cmd:shoot_hook_sync",
 },
}
What does it mean: err="status from unexpected cmd:shoot_hook_sync" ? And how to work out?

The second bug is manifested by a specific sequence of commands as reported later.
After setting the cameras in play mode all the 4 cameras shutdown with the same behavior as in voltage drop (aaarrrggghhh the Nightmare!!).  :o
The comands I use, just after shot command, are:

Code: [Select]
!return mc:download_images({verbose=true, delete=true, dst="Scans/TestIxus5/${id}-${name}"})
!return mc:cmdwait('play')
!mc:cmd('exit')
instead if I change the order in:

Code: [Select]
!return mc:cmdwait('play')
!return mc:download_images({verbose=true, delete=true, dst="Scans/TestIxus5/${id}-${name}"})
!mc:cmd('exit')
everything works correctly. What could be the reason?

Thanks a lot in advance,
Bye
Logged
*

Offline reyalp

  • ******
  • 13718
Re: a 3D printed "fake" battery adapter
« Reply #13 on: 04 / February / 2015, 20:56:56 »
Quote from: apaolucci on 04 / February / 2015, 10:29:10
What does it mean: err="status from unexpected cmd:shoot_hook_sync" ? And how to work out?
This is a bug in the multicam code, the command actually succeeds, but the error checking is wrong .  It should be fixed in chdkptp revision 665. This is in lua code, so you can just replace your multicam.lua with https://www.assembla.com/code/chdkptp/subversion/nodes/665/trunk/lua/multicam.lua (edit: or you could just ignore it)

Quote
After setting the cameras in play mode all the 4 cameras shutdown with the same behavior as in voltage drop (aaarrrggghhh the Nightmare!!).  :o
Most modern cameras crash if you delete files in rec mode and then switch to play. This is a known issue, without a good solution yet. See http://chdk.wikia.com/wiki/User:Nafraf/RemoteShootIssues

To work around, either don't delete the images while you are still in rec mode, or don't ever switch to play.
« Last Edit: 04 / February / 2015, 20:58:55 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline apaolucci

  • *
  • 6
Re: a 3D printed "fake" battery adapter
« Reply #14 on: 05 / February / 2015, 09:32:25 »
@reyalp Thanks for the new version of multicam.lua I prefer to not receive any error, so I've replaced the lua script ... and since I was using v658, I've upgraded all the lua directory to v665 :D

I'm very happy (if I may say it) that is not a voltage drop issue but only a know bug of the new cameras. This means that I have NEW Cameras :D:D  Seriously, the workaround is very simple so I have not to worry about.

These days I'l make the hyperspace jump, connect 16+ cameras and begin to make test for the second phase.
About the third battery wire, for the moment, I've parked the thread at a later date. I'm very busy on my current tasks and I have no more time.
 
Thanks a lot to you and waterwingz for the support. I'll post the progress,
Bye
Logged
*

Offline mr.burns

  • ***
  • 220
Re: a 3D printed "fake" battery adapter
« Reply #15 on: 07 / May / 2015, 09:58:56 »
@waterwingz

Quote
That said, if you print more fake batteries, it would make sense to allow for the option of wiring up the temperature line in case you ever need better sync in the future.

Very slowly but step by step I want to go ahead and sync two S110s using a microcontroller.
You say now with the battery terminal we can get better sync compared to USB?
Is this true? If yes why is battery terminal faster than USB?

Thanks!
Logged
2 x IXUS 860IS 100c
2 x Powershot S110 103a
*

Offline waterwingz

  • ******
  • 12123
    • Waterwingz
Re: a 3D printed "fake" battery adapter
« Reply #16 on: 07 / May / 2015, 11:54:46 »
It's no faster or more precise   It's just a different way to do the same thing.  Use the method that is easiest for you to implement
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
Pages: 1 [2]   Go Up
« previous next »
 

Related Topics