[ML] PTP protocol thoughts

[Trammell Hudson]

> So... with this development do you think it would be possible to use a
> Vinculum chip to interface over the USB port?

Once we have the PTP operations defined, any device that can implement
the host side will be able to communicate with the Camera. I know there
are some ARM and AVR implementations over libptp that will do this for
you.

Each PTP message has a 16-bit ID and up to five 32-bit parameters
(without doing a bulk transfer). This should be plenty for most
common things. Here are the messages that I have thought of; please
make suggestions so that we can define a good protocol.

Start/stop recording
- Replies with ACK when recording has started

Query Camera config
- Replies with Shutter, Aperture, ISO, Focal length, Focus dist

Adjust camera config
- Parameter to adjust (enum for shutter, aperture, iso, focus dist)
- Adjustment amount or absolute value

Time adjust
- Use NTP like protocol to ensure sync?

Query camera capacity
- How much space is left?
- How long have we been recording?
- Timestamps?

Press button
- Emulate an on-camera button press
- (Might be doable via script instead)

Execute script command
- Once we have a scripting language (Lua?)

Read/write memory

Read/write files

Boot new firmware?

Dump debug log

Another topic for consideration is external, non-control devices. It
might be useful to have messages that can communicate battery status,
wireless signal strength, hours since last tea-break, etc. We could
have a way to store this data and display it on the camera's screen
when necesary or requested. The battery would be neat if we could
monitor voltage levels over time and draw a bar-graph.

Please add your ideas!

--
Trammell

[Jim Noetzel]

All ideas below sound great.  I'd love the ability to sync times across multiple cameras.  I'm not sure how accurate the camera's internal clock is.  

Remote start/stop and focus control would get my vote for the first implementation.

--
http://magiclantern.wikia.com/

To post to this group, send email to ml-d...@googlegroups.com
To unsubscribe from this group, send email to ml-devel+u...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/ml-devel?hl=en

[Trammell Hudson]

On Mon, Nov 30, 2009 at 09:16:57PM -0600, Jim Noetzel wrote:
> All ideas below sound great. I'd love the ability to sync times across
> multiple cameras. I'm not sure how accurate the camera's internal clock is.

My SMPTE tests showed that it will keep sync for a while. I saw
about one frame missing after about an hour of free run, although
my test was not scientific in its setup and did not verify the
behaviour when the camera was powered off, temperatures were
allowed to swing, etc..

> Remote start/stop and focus control would get my vote for the first
> implementation.

Those are the first big ones on my roadmap, too. I have the relative
focus command implemented:

http://bitbucket.org/hudson/magic-lantern/src/5a2631e2eac9/ptp.c#cl-93

Absolute focus will be a bit trickier. As a first approximation
I plan to try zeroing the position by moving to the near point,
then just integrating the relative commands and hoping that

a) No one touches the manual focus ring
b) We don't run off the infinity end of the lens
c) We don't drop any lens focus commands

Start and stop recording should be pretty easy. I plan to re-architect
the way the handlers are installed to use an ELF segment similar
to the trick that we use for tasks. This eliminates the coupling
of different pieces so that any routine that wants to can declare
its own PTP handlers.

Another idea that occured to me is the ability to talk to external
devices like motion control tripod heads would be really useful.
That way it would be possible to sequence entire moves, perhaps
even while recording 3D.

--
Trammell

[Trammell Hudson]

On Tue, Dec 01, 2009 at 07:16:55PM -0500, Trammell Hudson wrote:
> On Mon, Nov 30, 2009 at 09:16:57PM -0600, Jim Noetzel wrote:
> > Remote start/stop and focus control would get my vote for the first
> > implementation.
>
> Those are the first big ones on my roadmap, too.

And they are working!

http://bitbucket.org/hudson/magic-lantern/changeset/87102ff59c8d/

> [...] I plan to re-architect

> the way the handlers are installed to use an ELF segment similar
> to the trick that we use for tasks. This eliminates the coupling
> of different pieces so that any routine that wants to can declare
> its own PTP handlers.

This is in the code, too. The way to create a PTP handler is to
define it at file scope with the PTP_HANDLER() macro, like this:

/** Start recording when we get a PTP operation 0x9997 */
PTP_HANDLER( 0x9997, 0 )
{
call( "MovieStart" );

struct ptp_msg msg = {
.id = PTP_RC_OK,
.session = session,
.transaction = transaction,
.param_count = 1,
.param = { param1 },
};

context->send(
context->handle,
&msg
);

return 0;
}

This will automatically register the PTP handler at boot time
and add it to the DryOS reported list of handlers.

--
Trammell

[Jim Noetzel]

Schwing!  Now comes the fun part for me.  Need to break out the arduinos and order a Vinculum dev board.  Unfortunately I'll be out of town for the next couple of weeks.  

Awesome.

--
Trammell