# variable-speed focus PTZ protocol

I'm building camera systems to mount on top of a TV tower. When storm clouds roll, in the video is displayed on the TV weather report. No one wants to climb the tower to manually pan and tilt and zoom and focus the camera during a thunderstorm, so we control them remotely. Currently I control the systems with Pelco D protocol over RS485.

I'm building some camera systems that are capable of variable-speed pan, tilt, zoom, and focus. (PTZ). (The prototype has an Arduino that controls the zoom and focus motors).

Alas, my ancient copy of the standard Pelco D protocol (and the earlier Pelco P protocol) doesn't have a way to tell the camera what speed to zoom or focus. (The only variable-speed stuff it supports is variable-speed pan and tilt). So currently I hard-wire the speed, which everyone agrees is the wrong speed. About half the people say it's too fast, and the other say it's too slow :-). It would be much easier to frame a shot and focus if we could take advantage of the hardware I already have to do variable-speed control.

I control both ends of the RS485 cable, so I could make up yet another random protocol.

• Is there a standard or semi-standard extension to the Pelco protocol that supports variable-speed focus or zoom or both?
• Is there a good way to extend the Pelco protocol in such a way that, when I add a new cameras and a new camera controller to a common RS485 bus, they don't conflict with old cameras and old camera controllers already on the bus; and are less likely to conflict with new extensions others may add later?
• Is there maybe some other standard protocol for controlling TV cameras, preferably ones that support variable-speed zoom? Wikipedia says that Pelco D is used in "infancy". Are better protocols are available? If so, how do I get the information I need to implement those protocols in my camera systems?

Pelco command 0x25 is "Set Zoom Speed", 0x27 is "Set Focus Speed", both use the value in the 6th byte to set speeds from 0-3:

From the Pelco D Rev 4 manual:

These two commands accept values of 0 through 3, in byte 6, to change the speed of the indicated function. Some cameras (such as the X12 camera in the Spectra I) do not support these functions. If the camera does not support either, or both, of these functions, the command is ignored. 0 is the slowest speed, 3 is the fastest.

Failing that, you could use command 0x4F (goto zoom position) repeatedly to move the zoom slowly, or you could assign some other command or preset to indicate slow zoom.

Looking at this (unofficial) Pelco D/P tutorial there are message types to set the zoom/focus speed in the extended command set.

I've used wiper/washer/lamp and cam presets features on a Dedicated Micro DS2 controller before. You could always hijack those to send increment/decrement signals to a slew rate parameter tracked at the housing end. This might be useful if you want to use an existing control joystick unit that doesn't support the extended set.

You could try signing the NDA to get the official docs to confirm.

The current version of D Protocol is 5.2.10 from August of 2013. I work at Pelco and if you want a current version of the protocol, e-mail me at ehamilton@pelco.com and I'll send you a copy.

There are several ways of changing zoom/focus/iris speed. Our cameras do not support the type of speed changing that might seem to be the most useful, i.e. having the speed change in a variable manner. All our cameras can do is to do step changes, which is not as useful as it might be.

If you want to add new commands to D Protocol, the easiest way that will not interfere with the rest of D Protocol is to change the first byte from 0xFF to something else. Then all users should ignore the command and you have your "own D Protocol" extension. You could make changes directly into the protocol and as long as you don't connect to a "real" D Protocol system, no one will ever know.

• I tried to add another post but the system said I had to wait 10 mins. Here it is anyway. For anyone that wants to control D Protocol units, please e-mail me. We have a free Windows package, the GlassKeyboard, that generates D Protocol commands and will let you play with a D Protocol device. – Eric Hamilton Feb 5 '14 at 22:45
• I think it's OK to include your e-mail for anyone to request the protocol specs, although on SE sites additional questions / answers should be kept on site rather than via e-mails. – PeterJ Feb 5 '14 at 23:30
• I was laid off from Pelco in 2014, since that time they seem to have stopped sending out protocol documents. The best that I could find was dated 2008. (The last one I did was dated 2014.) There is a company that has a reasonable tutorial on D, and P, protocol. It is "www.commfront.com". In the past they also gave a simple command and protocol decoder away. Sorry, when I got laid off I had to leave all my information behind. Eric Hamilton. – user2207980 Oct 10 '16 at 17:56

PelcoD protocol command consists of 7 bytes as follows:

Byte 1 (Sync) - the synchronization byte, fixed to FF
Byte 3 & 4 (Command 1 and 2) are shown below
Byte 5 (Data 1) - pan speed, range from 00 (stop) to 3F (high speed) and FF for "turbo" speed (the maximum pan speed that the device can go)
Byte 6 (Data 2) - tilt speed, range from 00 (stop) to 3F (maximum speed)
Byte 7 (Checksum) - sum of bytes (excluding the synchronization byte), then modulo 100 (Decimal code: 256)


Here is a list of some of the important commands in PelcoD protocol that you can write directly to the serial port, or if the camera is connected to you by ethernet you can send them as a network packet:

Function    Byte1   Byte2   Byte3   Byte4   Byte5   Byte6   Byte7
Up  0xFF    Address 0x00    0x08    Pan Speed   Tilt Speed  SUM
Down    0xFF    Address 0x00    0x10    Pan Speed   Tilt Speed  SUM
Left    0xFF    Address 0x00    0x04    Pan Speed   Tilt Speed  SUM
Right   0xFF    Address 0x00    0x02    Pan Speed   Tilt Speed  SUM
Upleft  0xFF    Address 0x00    0x0C    Pan Speed   Tilt Speed  SUM
Upright 0xFF    Address 0x00    0x0A    Pan Speed   Tilt Speed  SUM
DownLeft    0xFF    Address 0x00    0x14    Pan Speed   Tilt Speed  SUM
DownRight   0xFF    Address 0x00    0x12    Pan Speed   Tilt Speed  SUM
Zoom In 0xFF    Address 0x00    0x20    0x00    0x00    SUM
Zoom Out    0xFF    Address 0x00    0x40    0x00    0x00    SUM
Focus Far   0xFF    Address 0x00    0x80    0x00    0x00    SUM
Focus Near  0xFF    Address 0x01    0x00    0x00    0x00    SUM
Set Preset  0xFF    Address 0x00    0x03    0x00    Preset ID   SUM
Clear Preset    0xFF    Address 0x00    0x05    0x00    Preset ID   SUM
Call Preset 0xFF    Address 0x00    0x07    0x00    Preset ID   SUM
Query Pan Position  0xFF    Address 0x00    0x51    0x00    0x00    SUM
Query Pan Position Response 0xFF    Address 0x00    0x59    Value High Byte Value Low Byte  SUM
Query Tilt Position 0xFF    Address 0x00    0x53    0x00    0x00    SUM
Query Tilt Position Response    0xFF    Address 0x00    0x5B    Value High Byte Value Low Byte  SUM
Query Zoom Position 0xFF    Address 0x00    0x55    0x00    0x00    SUM
Query Zoom Position Response    0xFF    Address 0x00    0x5D    Value High Byte Value Low Byte  SUM


PelcoD command examples: Camera Address: 1
Pan Left at high speed: FF 01 00 04 3F 00 44
Pan Right at medium speed: FF 01 00 02 20 00 23
Tilt Up at high speed: A0 00 00 08 00 20 AF 27
Tilt Down at medium speed: FF 01 00 10 20 00 31
Stop all actions (Pan / Tilt / Zoom / Iris etc.): FF 01 00 00 00 00 01

Note: there will be no response from cameras in Pelco-D protocol

• Hi @David. Welcome to EE.SE. Thank you for sharing the answer with us. But "links only" answers are not recommended on this site. Answers should be self-contained as links may die in future. Please press on "edit" and include the important and relevant information from these links. You can still keep these links as references. – Hazem Jul 9 '18 at 12:30
• I edited the answer and removed all the links – David Jul 11 '18 at 9:17
• Upvoted since yesterday :) . You may keep the links as references in case you've taken some of these codes from them. – Hazem Jul 11 '18 at 9:24

This may seem a little left-field but I would be tempted to use the DMX format.

If you are not familiar with it, its an RS485 protocol normally used for lighting (including lights that pan,tilt,zoom) that is simply 512 8bit numbers repeated again and again with a break at the beginning (to indicate the next number is the first), if you need a 16-bit number you just use two consecutive 8-bit numbers together, multiple devices share the line by defining what the first number is they listen out for.

The idea is you are not getting tied up into device specifics, just providing the numbers it needs, you can use existing kit such as ethernet bridges and control desks and there are existing ardunio libarys and shields for working with it.

The disadvantages that come to mind is it does not have error detection/correction and its relatively fast speed means it doesn't have a huge cable length

• Hey, don't use the industry standard CCTV PTZ control protocol supported by millions of devices, use a commercial lighting control protocol instead... sorry, can't quite see the logic. – John U Aug 15 '13 at 13:35
• I would always say use an existing protocol if there is one but the poster found it lacking, hence my suggestion of another protocol that has proved itself doing ptz and id simple enough to repurpose without breaking the protocol. It is also a protocol that is open so he can build on others work, no nda required! – back_ache Aug 16 '13 at 14:25
• The pelco protocol is findable by googling with no NDA, as per my answer the proper commands are in there already, the OP just wasn't aware of them. – John U Aug 16 '13 at 15:30