D20's, hall effect sensors and stereo-photography

Recyclojunk64

D20's, hall effect sensors and stereo-photography

« on: 26 / December / 2013, 12:01:09 »

Advertisements

It's been awhile since I posted any progress in the other thread: http://chdk.setepontos.com/index.php?topic=10385.0 due to school commitments so I thought I might need to start a new thread.

I have recently obtained a second (and previously a first) D20 waterproof camera, with plans for underwater stereo-photography. Of course this also presents the problem of syncing the cams without compromising the waterproof aspect of them. I don't want to risk a DIY seal solution; the doors must both be closed.

I've come up with four ideas that may work; if anyone has any others they would be appreciated aswell.

1. Use a Hall-Effect sensor (with an external electromagnet to trigger it). It will be permanently attached to the back of the battery. As Hall effect sensors draw a continuous current of about 15mA, it will drain the battery over time. I have tested an unamplified hall-effect sensor attached straight to the battery and temp-input, and it measures a magnetic field change without too much trouble using print(peek(0xc090004a,2))

2. Same as above, except that I open up the cameras and put the sensor inside (I got them second hand anyway so no warranty to void) and power the sensor from somewhere that loses power when the cam is off, so no need to worry about battery drain while off. Has anyone else ever opened up a D20? (maybe to try to fix one?)

3. Use an inductive coil pickup (rectified to dc) attached to the temp-input. Another external coil will send out a pulse or two which will be picked up by the internal one. A small Zener diode will protect the voltage from going too high. I'm not sure whether or not the image stabilizer will be interrupted by the pulse though.

4. Use a lightening-capture motion sensing script and a flash. However I plan on using this rig mainly to take photos in daylight settings where there's moving subjects and no need for a flash, so not sure how this would work. Also I don't imagine they would be synchronized that well.

I'm thinking the hall effect sensor sound the most pleasing, the sensors (obtained out of old floppy-disc drives) are only about 3x1.5x1.5mm in size and are quite versatile; mounting one on the battery or inside the camera will not be a problem. If anyone has any other ideas or suggestions they would be greatly appreciated too.

Also, in order to make it usable, I will need to modify the CHDK code somehow to monitor the A-D temp input for changes like it currently monitors the USB voltage input. Previous attempts at using scripts to read the temp-input were no where near fast enough to sync properly. If anyone could set me off in the right direction here with where to that would be great.

Logged

reyalp

11487

Re: D20's, hall effect sensors and stereo-photography

« Reply #1 on: 26 / December / 2013, 15:27:01 »

Quote from: Recyclojunk64 on 26 / December / 2013, 12:01:09

1. Use a Hall-Effect sensor (with an external electromagnet to trigger it). It will be permanently attached to the back of the battery. As Hall effect sensors draw a continuous current of about 15mA, it will drain the battery over time. I have tested an unamplified hall-effect sensor attached straight to the battery and temp-input, and it measures a magnetic field change without too much trouble using print(peek(0xc090004a,2))

Rather than a hall sensor, it seems to be that you could also use a very simple magnetic switch. It would draw zero current when open, and if the battery compartment is like my d10, you could probably mount it on the battery or battery door with no mods at all. The circuit could just be a resistor that brings int the normal battery thermistor range.

Something like http://www.mouser.com/new/Hamlin-Electronics/Hamlin-MDCG-4/

Quote

Also, in order to make it usable, I will need to modify the CHDK code somehow to monitor the A-D temp input for changes like it currently monitors the USB voltage input. Previous attempts at using scripts to read the temp-input were no where near fast enough to sync properly. If anyone could set me off in the right direction here with where to that would be great.

You essentially have to replace get_usb_bit() with something that reads your desired input.

If this turns out to be fast enough and usable, it seems like it would be worth adding to the stock to code.

If the GetAdChValue works, this could probably made generic and allow users to select any of the available A/D channels.

Logged

Don't forget what the H stands for.

Recyclojunk64

Re: D20's, hall effect sensors and stereo-photography

« Reply #2 on: 29 / December / 2013, 13:39:34 »

Well the D20 battery compartment is rather small, here is a photo of it. The only place a reed switch would fit would be just above the battery. But if it's much larger than about 1.5mm diameter the battery will compress it against the door and may crush it (of course the battery can be ground down I guess)

I have figured out a way to use the hall effect sensor though, by powering it from the SD card: (yes there's tape between the test-points and the wires)

The metal contact then wedges against another one on the battery.

(will use larger cards later)

I replaced get_usb_bit() with *(short*)0xc090004a and some code, and it works fine on my ixus65. I'm not really sure how to use GetAdChValue though (I'm really still just a beginner with programming). I know it's call_event_proc('GetAdChValue',5) but how do I actually implement that without getting compilation errors? I'll probably add a menu option to select the channel and threshold values if I can get that working.

I'm probably going to also set it up with the option of a three-state input, either N, S, or no magnetic field. This way the shot can be easily cancelled or confirmed without wasting time releasing and repressing. It'll also make it easier to implement external control of functions such as zoom and exposure. I guess this could also be usefull with wired remotes too.

Logged

reyalp

11487

Re: D20's, hall effect sensors and stereo-photography

« Reply #3 on: 29 / December / 2013, 16:37:53 »

Quote from: Recyclojunk64 on 29 / December / 2013, 13:39:34

Well the D20 battery compartment is rather small, here is a photo of it. The only place a reed switch would fit would be just above the battery.

Yeah, that looks a lot like the D10 door, and was the position I was thinking of. The link was just for the general type of thing, not necessarily that particular one fit. Anyway, if the hall sensor works for you, that's great.

Quote

I replaced get_usb_bit() with *(short*)0xc090004a and some code, and it works fine on my ixus65.

Excellent. Do you have any measure of the response time?

Quote

I know it's call_event_proc('GetAdChValue',5) but how do I actually implement that without getting compilation errors?

That would be Lua code. To call it from C code, do the following:

Find the address of GetAdChValue_FW in funcs_by_name.csv for your camera
Add a line to stubs_entry_2.S, like
NHSTUB(GetAdChValue, [the address])

Add the following to platform/generic/wrappers.c

int GetAdChValue(int ch) {
return _GetAdChValue(ch);
}

In your code where you had *(short*)0xc090004a
use GetAdChValue(5); instead.

Logged

Don't forget what the H stands for.

Recyclojunk64

Re: D20's, hall effect sensors and stereo-photography

« Reply #4 on: 01 / January / 2014, 13:54:59 »

Quote

Excellent. Do you have any measure of the response time

Well I did some tests today on the ixus 65 again to measure the delay for both trigger methods (using an analogue oscilloscope). I measured approx. 84ms for the hall sensor and 88ms for the USB port as minimum delays (the delays varied between shots by about 4ms so I don't think the difference is that significant).

As for the GetAdChValue, I added it as you said, but unfortunately calling GetAdChValue(5) returned a value of -1 (well actually printed as 65535). I realise it probably needed Driver_EnableEventProc called first (as per http://chdk.setepontos.com/index.php?topic=10385.msg102962#msg102962) so I added that aswell the same way and called it once such as this:

Code: [Select]

...
if (driver_enable)
{
    Driver_EnableEventProc() ;
    driver_enable=0;
}

if (GetAdChValue(5) < 570)
{
...

However it still returns -1. Running a Lua script with print(call_event_proc('GetAdChValue',5)) (without calling Driver_EnableEventProc first) returns the actual value from the A/D (whereas it normally wouldn't without Driver_EnableEventProc) which proves that Driver_EnableEventProc worked. Any idea of what is going on here?

As for the control system, what I plan on having is a remote that can send data such as exposure time, zoom focal length, ISO, and other settings, including ND filter and RAW saving. Possibly even the ability to simulate standard button presses (to access stuff in the Canon menu). Is there any other projects that have already implemented any of this or am I starting from scratch here? I know there's a 47 page long thread for usb remotes. I'm pretty sure some settings can be changed via a remote in SDM, but that isn't available for the D20s

Logged

waterwingz

11567

Re: D20's, hall effect sensors and stereo-photography

« Reply #5 on: 01 / January / 2014, 14:32:26 »

Quote from: Recyclojunk64 on 01 / January / 2014, 13:54:59

As for the control system, what I plan on having is a remote that can send data such as exposure time, zoom focal length, ISO, and other settings, including ND filter and RAW saving. Possibly even the ability to simulate standard button presses (to access stuff in the Canon menu). Is there any other projects that have already implemented any of this or am I starting from scratch here? I know there's a 47 page long thread for usb remotes. I'm pretty sure some settings can be changed via a remote in SDM, but that isn't available for the D20s

Changing setting via the remote is done with either a pulse width modulation (PWM) or pulse counting scheme. You basically toggle the USB remote signal on and off and the camera interprets the on/off time intervel or counts in a set period as discrete commands. Both are fully supported by the CHDK USB remote code and CHDK scripting.

If you need sample scripts I can look around for you.

Logged

Ported : A1200 SD940 G10 Powershot N G16

reyalp

11487

Re: D20's, hall effect sensors and stereo-photography

« Reply #6 on: 01 / January / 2014, 15:27:25 »

Quote from: Recyclojunk64 on 01 / January / 2014, 13:54:59

Quote
Excellent. Do you have any measure of the response time
Well I did some tests today on the ixus 65 again to measure the delay for both trigger methods (using an analogue oscilloscope). I measured approx. 84ms for the hall sensor and 88ms for the USB port as minimum delays (the delays varied between shots by about 4ms so I don't think the difference is that significant).

That sounds very promising.

Quote

As for the GetAdChValue, I added it as you said, but unfortunately calling GetAdChValue(5) returned a value of -1 (well actually printed as 65535). I realise it probably needed Driver_EnableEventProc called

Good guess, but not the problem in this case. Technical details, skip to the tl;dr if you don't care:

When you are calling it from Lua, you are using the canon "Event procedure" (eventproc) system, which is a way to call functions by a human readable name. To be callable, eventprocs need to be registered with the system. "Driver_EnableEventProc" is an event proc (registered by default) which registers "GetAdChValue" in the system.

If you add the GetAdChValue in stubs_entry_2.s, you are directly telling CHDK the address, so the registration is unnecessary.

tl;dr:
There is some other problem when you are calling it directly.
As it turns out, my off the top of the head code was slightly wrong for ixus65, on this camera GetAdChValue expects the channel number to be passed by reference, rather than the value itself. So for that camera your C code should look like

int GetAdChValue(int ch) {
return _GetAdChValue(&ch);
}

Unfortunately, this varies by camera. The D20 will expect the first version I posted. The eventproc system handles this automatically, so the event proc calls are the same on cameras where the C call is different.

Logged

Don't forget what the H stands for.

waterwingz

11567

Re: D20's, hall effect sensors and stereo-photography

« Reply #7 on: 01 / January / 2014, 15:44:21 »

Quote from: Recyclojunk64 on 01 / January / 2014, 13:54:59

Quote
Excellent. Do you have any measure of the response time
Well I did some tests today on the ixus 65 again to measure the delay for both trigger methods (using an analogue oscilloscope). I measured approx. 84ms for the hall sensor and 88ms for the USB port as minimum delays (the delays varied between shots by about 4ms so I don't think the difference is that significant).

I'm curious about what you measured with your scope? What triggers the measurement and what are you watching to determine the response time?

Logged

Ported : A1200 SD940 G10 Powershot N G16

Recyclojunk64

Re: D20's, hall effect sensors and stereo-photography

« Reply #8 on: 02 / January / 2014, 05:21:48 »

Yep thanks, the GetAdChValue works now. Interestingly enough, when printed out alongside *(short*)0xc090004a in the OSD, they don't appear to be exactly the same; there seems to be some noticeable latency between GetAdChValue and the other one at times. Would I be right in assuming this is just the fault of the OSD and not something more serious?

Code: [Select]

    if ((conf.show_temp == 6) || (conf.show_temp == 5))
        draw_ad("A/D", *(short*)0xc090004a, yofst++);

    if ((conf.show_temp == 5))
        draw_ad("AdCh", GetAdChValue(5), yofst++);

(draw_ad is the same as draw_temp but without the degrees symbol)

Quote

If you need sample scripts I can look around for you

Well if you know any of the top of your head that'd be great, otherwise I'll have a look for some.

Quote

I'm curious about what you measured with your scope? What triggers the measurement and what are you watching to determine the response time?

Well basically, the scope input is connected to the USB port power or a solenoid (which triggers the hall sensor), and is set to trigger on a falling curve. When the power is disconnected from the solenoid or the USB remote button is released, the scope will trigger and the camera will take a photo of the screen; the position of the dot determines the delay (yes the beam is set to start from the start of the graph). Probably not the most precise method but it was all I could think of at the time.

(scope is set to 20ms/div)

I think the trigger wasn't set properly for the tests I did earlier on the ixus 65 so I've done them again, this time with about 50 photos each. Of course I didn't actully make a plot of them all or anything.

Fastest and slowest time for each was consistently about 78ms and 86ms respectively. Results varied evenly between these two times (other than obvious outliers). All options were set to manual including subject-distance override. This difference represents about 6mm on the scope graph, so I'm fairly sure that the inconsistent delay would be the fault of the camera itself and not the scope trigger. Also I've had some problems syncing my D20s to more than 5ms or so accuracy with the USB remote.

So this brings me to my next question; would it be possible to call a native function or something to take the photo directly, rather than simulate a full-shutter press? Would this make any difference? And would this have a significant chance of damaging hardware such as the sensor if something went wrong (especially when pointing at the sun)? I'm not really concerned about damaging the ixus 65 so if there's any experiments I can perform on it I will be more than happy to.

Logged

waterwingz

11567

Re: D20's, hall effect sensors and stereo-photography

« Reply #9 on: 02 / January / 2014, 10:03:44 »

Quote from: Recyclojunk64 on 02 / January / 2014, 05:21:48

Well basically, the scope input is connected to the USB port power or a solenoid (which triggers the hall sensor), and is set to trigger on a falling curve. When the power is disconnected from the solenoid or the USB remote button is released, the scope will trigger and the camera will take a photo of the screen; the position of the dot determines the delay (yes the beam is set to start from the start of the graph).

Thanks for that explanation. I'm doing a major "face palm" here. I built this when I now realize I could have just used my scope. I think I had a reason at the time for not doing so but it escapes me now.

Quote

Probably not the most precise method but it was all I could think of at the time. (scope is set to 20ms/div)

The actual delay time is not important to USB remote sync - just that the delay always be the same. Using expanded sweep and trigger delay should give more than enough precision to measure shot-to-shot variation once you know the average shot delay time.

Quote

I think the trigger wasn't set properly for the tests I did earlier on the ixus 65 so I've done them again, this time with about 50 photos each. Of course I didn't actully make a plot of them all or anything.

Fastest and slowest time for each was consistently about 78ms and 86ms respectively. Results varied evenly between these two times (other than obvious outliers). All options were set to manual including subject-distance override. This difference represents about 6mm on the scope graph, so I'm fairly sure that the inconsistent delay would be the fault of the camera itself and not the scope trigger. Also I've had some problems syncing my D20s to more than 5ms or so accuracy with the USB remote.

What you are measuring here has been discussed at length over the years on this forum as "sync". When shooting with two or more cameras (for 3D effects or "bullet time" rigs) you want the cameras to all open their shutters simultaneously. The ability to do that is called "sync" and getting them all within 1 mSec of each other is the goal. The data you show is typical for an older Canon Powershot - newer models are much worse.

Quote

So this brings me to my next question; would it be possible to call a native function or something to take the photo directly, rather than simulate a full-shutter press? Would this make any difference? And would this have a significant chance of damaging hardware such as the sensor if something went wrong (especially when pointing at the sun)? I'm not really concerned about damaging the ixus 65 so if there's any experiments I can perform on it I will be more than happy to.

If you enable the sync option in the USB remote menu, that might do what you need. The camera will start the shooting process when the USB power goes to 5V and then pause very close to where the shutter will actually release and wait for the USB power to drop.

There is more info in the thread I posted about attempts to improve sync quality. Initial results are quite good but its still a work in process.

Logged

Ported : A1200 SD940 G10 Powershot N G16