Motion Detection too slow?

[Bg~]

Edit: I see that string in the A720 firmware, but I don't have IDA Pro. Are there other options?

you can try this my lazy method

Thanks mx3. I'm going to quote it again and mention that the find_diffs.bat and zzz.bar are in the attachment below mx3's post (since it took me a bit to figure that out). 

[fudgey]

Okay, I got the speedup to work on my a570is. Using my MDFB-080419-DigicIII.bas with default settings (apart from 4s review for readout) and my dusty LED blinker I used a few months back for these things, I now got the following MD response times (statistics from 3 separate sets of 32 consecutive detections, all successful, 96 shots in total):

fastest: 81 ms +- 3 ms
slowest: 111 ms +- 3 ms
median: 87 ms
average: 90 ms

Only 4 shots out of 96 were slower than 99 ms +- 3 ms.
56% of the shots reacted at 87 ms +- 3 ms or faster.

This is a significant improvement over current trunk. The fastest response time didn't improve (of course), but the distribution is now much tighter. It used to go up to 150 ms or more and have average and median a couple of tens of ms higher (I also re-checked with a recent unpatched build and it performed like in my old measurements, so I didn't repeat them).

It looks like my old dumps in this thread were useful after all (http://chdk.setepontos.com/index.php/topic,405.msg3451.html#msg3451)... I grabbed trunk 430 and patched platform/a570/sub/100e/lib.c with the function in oidipos's post above using adresses 0x65CC and 0x65DC (diff below).

Code: [Select]

24,26c24,33
< void *vid_get_viewport_live_fb()
< {
<     return (void*)0x0;
---
> void *vid_get_viewport_live_fb() {
>     void **fb=(void **)0x65CC;
>     unsigned char buff = *((unsigned char*)0x65DC);
>     if (buff == 0) {
>         buff = 2;
>     }
>     else {
>         buff--;
>     }
>     return fb[buff];


[Bg~]

A720IS

Code: [Select]

CRW_0001.jpg is the dark frame ram dump.

find_diffs CRW_0001.JPG CRW_0002.JPG 10 6400 > 720.regions.txt

(0x00658BD0 + 0x1900 = 0x0065A4D0) bytes: 3F480
(0x006D74D0 + 0x1900 = 0x006D8DD0) bytes: 3F480
(0x00755DD0 + 0x1900 = 0x007576D0) bytes: 3F480

find_u32s CRW_0001.JPG CRW_0002.JPG 1900 0065A4D0 006D8DD0 007576D0 1065A4D0 106D8DD0 107576D0> 720.refs


[0x000020DC] : 1065A4D0
[0x00002148] : 107576D0
[0x000021D0] : 1065A4D0
[0x000021D4] : 106D8DD0
[0x000021D8] : 107576D0
[0x0000930C] : 107576D0
[0x00009338] : 107576D0
[0x0000933C] : 107576D0
[0x0000937C] : 1065A4D0
[0x00018434] : 1065A4D0
[0x000184A8] : 1065A4D0
[0x000184B4] : 1065A4D0
[0x00018560] : 1065A4D0
[0x000418D8] : 1065A4D0
[0x000B0428] : 1065A4D0
[0x000C5738] : 1065A4D0
[0x00187298] : 1065A4D0
[0x00304008] : 107576D0
[0x00304908] : 1065A4D0
[0x003140E0] : 106D8DD0
[0x003140E4] : 106D8DD0

This works for the A720IS. I'll do a speed test comparison shortly.

Code: [Select]

void *vid_get_viewport_live_fb() {
    void **fb=(void **)0x20DC;
    unsigned char buff = *((unsigned char*)0x20EC);
    if (buff == 0) {
        buff = 2;
    }
    else {
        buff--;
    }
    return fb[buff];
}


[Bg~]

Well I get very consistent 120ms response with MD_B. With the unmodified code, i get between 100ms and 160 ms (A720). I'll try fudgey's script later. What are you using for testing your response time, fudgey? I'm using jonnythe's program.

One thing I don't quite understand is why the code speeds up the response. I know about the three live images buffers updated sequentially, but

Code: [Select]

    if (buff == 0) {
        buff = 2;
    }
    else {
        buff--;
    }
doesn't select any specific buffer, it just cycles through them. How do we know that it's using the latest buffer?

[cyril42e]

One thing I don't quite understand is why the code speeds up the response. I know about the three live images buffers updated sequentially, but

Code: [Select]

    if (buff == 0) {
        buff = 2;
    }
    else {
        buff--;
    }doesn't select any specific buffer, it just cycles through them. How do we know that it's using the latest buffer?

Because of this right before:

Code: [Select]

unsigned char buff = *((unsigned char*)0x20EC);
So it doesn't cycle through the buffers, it takes the previous one (which is the latest).
Could have been written:

Code: [Select]

void *vid_get_viewport_live_fb() {
    void **fb=(void **)0x20DC;
    unsigned char buff = (*((unsigned char*)0x20EC) - 1 + 3) % 3;
    return fb[buff];
}
(But I have to admit that I had the same reaction than you the first time I read this code )

[Bg~]

Ah..duh. That should have been obvious. But it brings up another question: How do we know that the previous buffer is the most recent? Was that derived from some insight from the disassembled firmware (per DataGhost's similar thread on the subject)?

[fudgey]

Well I get very consistent 120ms response with MD_B. With the unmodified code, i get between 100ms and 160 ms (A720). I'll try fudgey's script later. What are you using for testing your response time, fudgey? I'm using jonnythe's program.

See my earlier shutter speed test post since the hardware is the same:
http://chdk.setepontos.com/index.php/topic,32.105.html
http://chdk.setepontos.com/index.php?action=dlattach;topic=32.0;attach=248

Now, the LEDs are numbered like this:

1  2  3  4  5  6  7
14 13 12 11 10 9  8

First LEDs 12 and 14 are enabled for 60 ms (the "flash"), then they are disabled and at virtually the same time LED1 is enabled for 6 ms. When LED1 is disabled, LED2 is enabled at the same time. After the last LED shuts down, all LEDs are off for 10 seconds. This is when I read the result during shot review (I write down the lowest number led that is shining in the photo).

During the sequence there is no off time. Thus, if I get a shot with no LEDs shining, I know the delay was greater than the entire sequence or 60ms + 14*6ms = 144 ms.

When I say "virtually at the same time", it's all below 400 ns. The ms delays are accurate to about 0.5% or so. The delays are obviously configurable (it's an xtal stabilized uC running code written in C, timing verified on an oscilloscope).

[Bg~]

For the A720

I've been doing some more looking around and have gotten a very nice improvement in response (from 120 ms to 90ms).

I used DataGhosts advanced memory viewer to check out the addresses I got from mx3's program. I did not find a changing index at the location I had previously posted. Then I scrolled around the memory a bit (after adding some code to read buttons in DataGhost's viewer) and came across a memory location cycling across 0,1,2. (0x2084). I looked around some more in that general area and noticed a location that repeated 3 addresses (0x2148). These addresses corresponded to the three addresses that mx3's find_u32s.exe produces (in the right hand list). I then figured I needed to find the address where these three addresses exist sequentially, which turned out to start at 0x21D0. Note that 0x21D0 is the third address given by mx3's program (see one of my above posts).

So, the following code gives 90ms response on the A720:

Code: [Select]

void *vid_get_viewport_live_fb() {
    void **fb=(void **)0x21D0;
    unsigned char buff = *((unsigned char*)0x2084);
    if (buff == 0) {
        buff = 2;
    }
    else {
        buff--;
    }
    return fb[buff];
}

I also tested using the current and next index, and both resulted in slower performance.

So, I'd suggest verifyng the memory locations obtained with mx3's program if you're trying to get the fastest response.

Edit: Now that I went through all that, I see that the step that I didn't understand for using mx3's program correctly is to look for the addresses that are right next to each other in memory. The first address is the one you want (0x21D0). However, I'm still in the dark on how to find the index location (other than looking around in the memory viewer).

[cyril42e]

That's strange, for now everybody has found base & index addresses distant by 0x10, as you did find before. I looked at this address for my camera, and it is actually cycling throug 0/1/2. I looked around in memory (+- 0x200), and the only address quickly changing I found is 0x6E98, which is cycling through 1/2 and sometimes 4 too.
So I haven't found similar improvement for SD1000

[Jucifer]

<snip>
[0x000021D0] : 1065A4D0
[0x000021D4] : 106D8DD0
[0x000021D8] : 107576D0
<snip>

and in platform/a720/sub/100c/lib.c:
void *vid_get_viewport_fb()
{
    return (void*)0x1065A4D0; // 0x107D5FD0
}



But for A710:

[0x0000522C] : 105F25E0
[0x00005230] : 10670EE0
[0x00005234] : 106EF7E0

void *vid_get_viewport_fb()
{
    return (void*)0x1055A7E0; //0x105f25e0;
}

Huh?

Also the index really seems to be at 0x522C+0x10=0x523C, verified with freshly patched memory viewer. ;)

[Bg~]

cyril, maybe it's a DryOS thing. Maybe someone with a different DryOS camera could take a look with the memory viewer and verify the index location.

Jucifer, I'm basically poking around in the dark. I've no idea how mx3 and Grand and those guys figure all this stuff out from scratch.

[cyril42e]

cyril, maybe it's a DryOS thing. Maybe someone with a different DryOS camera could take a look with the memory viewer and verify the index location.

Oh yes you are right, I forgot that A720 is DryOS, there are probably some differences in how the memory is organized even with the same code...

[chris07]

Hello,

I think I found the vid_get_viewport_fb values for SD870 / Ixus 860 (mx3's program and comparing in IDA):

Code: [Select]

void *vid_get_viewport_live_fb()
{
    //return (void*)0;//0x10670ee0;
void **fb=(void **)0x8FCC;
    unsigned char buff = *((unsigned char*)0x8E90);
    if (buff == 0) {
        buff = 2;
    }
    else {
        buff--;
    }
    return fb[buff];
}

For me this works faster than the default. Perhaps someone else could verify this.

Regards,
Chris

[whoever]

Been a bit slow on the uptake... Well anyway, the tweak positively confirmed in IXUS950/SD850 1.00c, giving the expected 30ms improvement with the resulting response in the 120-130ms range. This was obtained with DataGhost's java script md_meter.html; johnnythe's utility generally gives "faster" and more scattered results. The patch code reads:

Code: [Select]

void *vid_get_viewport_live_fb()
{
    void **fb=(void **)0x8C58;
    unsigned char buff = *((unsigned char*)0x8C74);
    if (buff == 0) {
        buff = 2;
    }
    else {
        buff--;
    }
    return fb[buff];
}
so whoever feels like/able to, please add to the plant.

[oh2ski2002]

hello there everyone...first time poster here. 

Joined yesterday and have spent most of last night, the majority of my day at work today (shh dont tell) and also tonight searching the boards, finding new things to add-on to my S5, and trying to figure things out.  I do, however, unfortunately agree with some other newbies that the boards are tough---many many pages, deleted posts that leave the threads confusing to say the least, and tons and tons of additional updates without a sticky post with the latest and greatest scripts (in their fullest, updates and all).  I am finding it very tedious going through and seeing what was added, where, and why.  Further, im worried im missing parts due to the deleted posts!  Does anyone have a full MD script with all the updates for the S5? Trying to get it as fast as possible!  Also--im willing to test out the speeds i get---is it MD_Test that does that? If so where is it---that seems to have disappeared as well....

anyone able to help out here?  Thank you much in advance!! :-)