Serial (RS232) remote control of non-remote-enabled cameras - General Discussion and Assistance - CHDK Forum

Serial (RS232) remote control of non-remote-enabled cameras

  • 9 Replies
  • 7335 Views
Advertisements
This is essentially a continuation of this old thread.

Summary: Additional code in the subroutine monitoring the USB port voltage makes it possible for the camera to decode serial data (currently, data sent at 4800 baud). This ability is RECEIVE ONLY (no data can be sent from the camera to the host device)

Compatible cameras: Currently only tested on A640 and A630.

Demonstration:

YouTube - CHDK Canon A630 Serial Remote Control Demo
The host device is a modified PC - Mobile Phone cable (a cheap copy of a Nokia CA-42 cable [note - the genuine CA-42 cable actually wouldn't work in this instance]). The mobile phone connector has been removed and replaced by a USB female connector, which the camera USB cable is then plugged into.

(Shown as an overlay over the A630's display) A Visual Basic 2005 program is run on the computer which monitors the position of two sliders (zoom, focus) and a shutter button. When any of the sliders are moved a command is sent to the camera; to ensure the command is received the program continuously repeats the command, 10 times per second.

The camera receives and decodes the data and, using a uBasic script, performs the relevant action.

The second part of the demonstration shows the simultaneous control of two cameras; an A630 and A640. The signal is simply sent to both via a splitter (in this case, a USB hub which has had its circuitry disabled.

Advantages: Does not require use of the Canon SDK. Allows remote-control of cameras which cannot be remote-controlled by PC. Host device can be a PC, handheld computer or inexpensive microchip. Allows interface with CHDK scripts.

Disadvantages: Unproven on other cameras. Slow rate of transfer (not really a problem for most purposes), data is one-way only, errors may increase under high CPU load. (The current code also slows down the camera such that the camera is sluggish to respond to button presses etc. I think this is just poor coding on my part rather than a real technical limitation.)


Code & build: The included code is based on Fingalo's build 125 (from last December) and is designed for TTL logic RS232 devices such as the aforementioned USB - mobile phone cable. ONLY TESTED ON THE A630 / A640. Further build details will follow.

(Post cut short due to lack of time - further information to follow later)

Re: Serial (RS232) remote control of non-remote-enabled cameras
« Reply #1 on: 31 / May / 2008, 17:43:53 »
Well done!! With some modifications it could be used in some future versions of StereoData Maker. However, it would require microcontroller on other side...

Re: Serial (RS232) remote control of non-remote-enabled cameras
« Reply #2 on: 31 / May / 2008, 17:48:59 »
t would require microcontroller on other side...

and you are too busy learning video editing   :)

Re: Serial (RS232) remote control of non-remote-enabled cameras
« Reply #3 on: 31 / May / 2008, 18:03:48 »
further information to follow later

Excellent work, and for two-camera stereo !

Look forward to further details.


*

Offline fudgey

  • *****
  • 1705
  • a570is
Re: Serial (RS232) remote control of non-remote-enabled cameras
« Reply #4 on: 01 / June / 2008, 05:00:20 »
Great!

On a quick look it seems the code is an extension of the USB supply voltage trigger. In platform/generic/kbd.c, the remote code in my_kbd_read_keys() has been extended significantly to decode RS-232 bytes instead of measuring the length of a single button press. Understandably that can make the camera sluggish when the USB remote is enabled. The ubasic interface seems to remain the same, but returns bytes instead of length information.


*

Offline zeno

  • *****
  • 885
Re: Serial (RS232) remote control of non-remote-enabled cameras
« Reply #5 on: 01 / June / 2008, 06:41:24 »
Nicely done. James Gentles GentLED CHDK2 (see gentLED Camera Remote Control: Options) does a similar job for R/C, letting you use two joysticks/servo slots to control camera functions via a script (wthout mods to CHDK).
« Last Edit: 01 / June / 2008, 09:38:54 by zeno »
A570, S100, Ixus 127
Author of ASSIST, STICK, WASP, ACID, SDMInst, LICKS, WICKS, MacBoot, UBDB, CFGEdit

Re: Serial (RS232) remote control of non-remote-enabled cameras
« Reply #6 on: 01 / June / 2008, 07:10:58 »
That's exactly it. I should have emphasised that this is by no means a user-ready build; there's still a lot to be done. The implementation is extremely crude and I'm sure the sluggishness can be reduced to more manageable levels by modifying the timeouts etc in the code, or simply activating/deactivating the serial monitoring in uBasic scripts or by other means.

One thing I should definitely emphasise is that this code has been in this state since early last December and I don't plan to do much in the way of development on it - I'm hoping to make it a bit easier for others to continue the work with this information.

Some further information on the technicalities of the code:

Each data packet sent to the camera currently consists of:

1 'handshake' byte with a value of 0 (binary 0b00000000)

1 data byte with 8 bits. eg 4 (binary 0b00000100)

1 error-checking byte which is the inverse of the data byte. eg for a data byte of 4: 251 (binary 0b11111011)

There's no technical reason why there should only be a single data byte. The handshake and error-checking bytes were added by necessity, but are not optimised:

Most significantly, I currently begin each packet with a byte with a value of zero, because electrically that appears as a single long pulse (start bit, 8 inverted data bits and stop bit). I've called this the handshake byte.

To identify whether the first signal received by the code is the handshake byte it is necessary to determine the length of the pulse. Because we have no way of accurately timing at this level I record the number of times I have polled the USB port voltage. If this number is significantly different to a precalibrated value (which may well be different for different cameras, and especially for Digic II vs Digic III) then the data is rejected and the subroutine exits.

I had to include the handshake byte because I was encountering a lot of timing errors due to varying CPU load in the camera. The handshake byte is effectively a measure of CPU load using an external signal.

After the data byte an error checking byte is transmitted; at the moment that's just the inverse of the data byte. (there's a name for this which I can't remember!) This is a very crude and inefficient form of error checking and sheer laziness on my part!

------------------------------------

Details of the USB - serial cable.

I've been unable to determine how accurate the timing is on this particular USB converter (no oscilloscope), but it's likely to be better than the timing on microprocessors which bit-bang [ie the electrical signal is generated by software rather than dedicated hardware] serial, such as PICs. As timing is likely to always be the main issue with this code, I suggest constructing a USB - serial cable if you plan to do any development of this serial code or hardware interfacing with it; it may be useful to troubleshoot errors.

The cable I used was a cheap imitation of a Nokia CA-42, found on eBay.
ebay link
(That's the cheapest supplier I could find for the UK)

I believe this contains a Prolific PL-2303 chip, as used in most USB - serial adaptors: Welcome to Prolific

In any case, the cable sends 5V TTL RS232.

The female USB connector was taken from a short extension lead packaged with a cheap USB hub. This particular moulded connector was very easy to disassemble and reassemble, which is rare with moulded connectors. I've seen these a lot in 'Poundland' shops in the UK. (Also seen here:
ebay link
)

Wiring is as follows:

Serial cable TX -> USB female Vcc
Serial cable ground -> USB female ground

To determine which cable is the serial transmit you can use a multimeter connected between ground and the suspect wire; when a connection is opened to the COM port the TX wire will go from 0V to 5V (because of inverted logic, 5V is the idle state in this case)

You may also be able to determine the wires via working backwards from this diagram: Nokia 2112, 2115,  2270, 2272, 2280, 2285, 3100, 3105, 3108, 3120, 3125, 3200, 3205, 3220, 3585, 3586, 3587, 3588, 3589i, 5100, 5140, 6011i, 6012, 6015, 6015i, 6016i, 6019i, 6020, 7210 pop-port LIKE-DKU-5 or CA-42 cable schematic pinout and signals @ pinouts.ru

The only device that is safe to connect to this cable is your camera. Any other devices may draw current from the serial cable and result in damage to the serial cable (and possibly the device. Not very likely, but that's disclaimers for you).

That's all for now.

(Thanks, zeno, but I'm keen to keep this thread fairly concise and on-topic. Would you mind starting a new thread discussing your scripts and amending your post to link to that thread, rather than posting a direct link to the scripts [to avoid questions on those scripts ending up in this thread]?)
« Last Edit: 01 / June / 2008, 07:21:41 by staylo »

Re: Serial (RS232) remote control of non-remote-enabled cameras
« Reply #7 on: 01 / June / 2008, 07:49:55 »
this is by no means a user-ready build; there's still a lot to be done.

As it uses the generic version of kbd.c and USB_REG and USB_MASK are defined it should work on the A530,A540,A610,A620,A630,A640,A700,A710,ixus65 and ixus800.


*

Offline fudgey

  • *****
  • 1705
  • a570is
Re: Serial (RS232) remote control of non-remote-enabled cameras
« Reply #8 on: 01 / June / 2008, 08:14:34 »
Thanks for the details.

Because we have no way of accurately timing at this level I record the number of times I have polled the USB port voltage.

Is this true? Or rather, can it be made false? :D

I believe get_tick_count() is a wrapper to the firmware GetSystemTime() function and returns time with millisecond resolution, which indeed is not accurate enough for 4800 baud... but do we know if this is the actual hardware timer value (that would mean it's a pretty slow pre-scaled timer), or something updated by a faster timer in an interrupt?

If there's a faster timer, we can probably find it, read it and use it with get_tick_count() for increased time resolution. Architectures tend to specify standard locations for timer peripherals, is that true for ARM?

Re: Serial (RS232) remote control of non-remote-enabled cameras
« Reply #9 on: 01 / June / 2008, 08:56:31 »
A good question, and entirely outside my experience :) I experimented with using get_tick_count for slower baud rates and IIRC found that it only appears to be updated every 10ms.

 

Related Topics