Best Baud Rate????

[gmark 0]

Given that I can set my PTZ controller and my camera to any baud rate, what's the best choice?

 

The controller is much faster than the camera itself, and a higher baud rate would be more prone to errors, right?

 

So why not just set everything to the lowest possible baud rate, i. e., 2400?

 

Mark

[ssnapier 0]

We typically use 9600, Iwould not worry about errors until you get above 15200.

[gmark 0]

Well, the baud rate only applies to the PZT controls since the video is sent via

analog. It seems to me that 2400 is much faster than the cameras could use.

 

Also, is it possible to connect these PZT lines in serial rather than parallel? The fact that

the DVR only has a small, 2-wire concoctor seems to indicate this is intended or at least

considered. Perhaps it's possible to connect them with some groups in serial and

some group?

 

Anyone try this?

[ssnapier 0]

Yes, that is quite common actually. The PTZ's each have an address, so you set each one to a different address and the cameras sort it all out.

[gmark 0]

Well, it would seem that signal attenuation along a long serial connection would be worse and more prone to screwing up, and even worse at higher baud rates.

 

But the original question still bugs me -- why are my cameras not stopping? These are Huacam, but the Swann had this problem, too. Do these cameras keep moving, in general, until the button is released? Or do they keep moving until they receive a "stop" command from the interface? And why would all of them be affected (all three) -- different loops, different lengths of cable, different locations, different addresses -- unless I've screwed up something common to them all?

 

I suppose I could just keep trying combinations, but I'd really like to avoid taking each down and reinstalling them each time.

 

Has anyone else run into this situation? Cameras that don't stop moving?

[ssnapier 0]

I guess it depends on how the control is written. I have seen some of them move until you stop it and some only move until you release the mouse button. As for the long runs attenuating, you can go hundreds of feet before that is an issue. How long are we talking here?

[gmark 0]

Pretty safely within the expected range -- all four are stock 25 or 50-foot Swann cables.

 

But you bring up a good point, and one I asked Swann about, but I don't recall getting an

answer. The start-stop protocol is a factor of the controller, right? I mean, the standard for

Pelco P or D have a set pattern, and the cameras themselves adhere to that pattern, right?

 

Does that standard require a continuous stream of "move" commands, or does it simply run on a move command and then stop when a "stop" command is received?

 

And how does a pre-set position work? Does the camera protocol understand absolute positioning? Or does it have absolute position *in addition* to being able to respond to move/stop commands? And how precise is it? Within a degree or a tenth of a degree from whatever "home" is?

 

I'd LIKE to modify my controller to take care of that stuff, but I can't get to those parameters or to the code.

 

Is there an open-source controller somewhere?

 

Thanks!

[ssnapier 0]

Wait a second, are using a physical joystick or are you using the software interface in the DVR software?

[gmark 0]

Using MyDVR from a remote computer.

[ssnapier 0]

ahhhhhh, ok...

 

The remote computer throws a big wrench in the works because it adds a bit of unpredictable latency.

[gmark 0]

Unfortunately, this is the prescribed solution from Swann, and you'd expect they would have tested

the system for this latency. However, the three cameras are Huacam models, so it may be that this

particular combination was not tested. Perhaps the Huacams expect different timing in some way.

 

What I would like to do is tinker with the timing or protocol exchange generated by the MyDVR software.

Or perhaps find another open-source solution.

 

I do want to make it clear, however, that the request is coming from the MyDVR application over

my home network, but it terminates at the DVR, and the DVR itself sends the Pelco commands

from that local interface and not from my laptop where MyDVR is running. I think I'll experiment with

some sort of attenuation on the control line.

[ssnapier 0]

If you put a monitor on the DVR and control it directly from there do you have the same issues?

[gmark 0]

Very good call. No, it does NOT have that problem when a monitor is connected directly to the DVR and I control it directly from there. Also, a cable length of only a foot has no effect on the problem at all. That is, the cameras all exhibit this no-stopping problem regardless of cable length -- 1 foot to 100 feet -- so it does not seem to be an electrical propagation problem. Another thing I notice is that the DVR has a selection for Camera Speed - 1 to 64 -- and the MyDVR application does not have that. I wonder if there are other differences as well, such as the DVR possibly sending an explicit "stop" command and the Mac application from Swann just sending continual move commands or a single move command and NO stop.

 

I'll try to ask these questions again to Swann technical support, but I don't know if anyone's around who knows the internal working of the interface software or at least of the MyDVR application.

 

Does anyone know if there are other PC/Mac-based DVR-controlling applications? Possibly some that are modifiable in control protocol?

[gmark 0]

Ummm… I should have spent a bit more time looking on the web for applications rather than all the stuff about the DVRs and the cameras and protocols and everything else. There are dozens. So now, I'll see how the others do…

[gmark 0]

Well, I've looked over about a dozen apps, and there don't seem to be any that will actually control the Swann DVR except the MyDVR application provided by Swann. I'm not sure latency is the actual problem, although it's possible. I can stop the camera by hitting the "Iris" command, which a Swann tech tells me sends a sort of "enter" or "return" or something instead of an Iris command. I have no idea why that would be or how something that kludgy was implemented. However, it would be great if I could reconfigure this software OR some open source program to simply concatenate this "Iris" or "stop" command onto each "unclick" or button release.

 

So my previous question stands -- does anyone know of some other software I can use to remotely view and control my Swann DVR BESIDES MyDVR?

[survtech 0]

Many PTZs require multiple hexadecimal (base 16) command strings to perform actions. Take Pelco-D protocol for instance. The command to Pan a camera at Address 1 Left at high speed is: FF,01,00,04,3F,00,44. This string must be sent almost continuously to continue panning. In the absence of a follow-up command string, the PTZ would continue panning for ~500ms then stop unless another FF,01,00,04,3F,00,44 string is received or a "Stop" string (FF,01,00,00,00,00,01) is received.

 

In the strings above,

Byte 1 (Sync) - the synchronization byte, fixed to FF

Byte 2 (Camera Address) - logical address of the camera being controlled (Address 1 is 01)

Byte 3 & 4 (Command 1 and 2)

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)

 

To pan and zoom at the same time, two commands must be sent with no more than 500ms between repeating commands (ie, pan - zoom - pan - zoom - etc.).

 

Some VMS manufacturers fail to send the stop string, hence the camera will "overshoot" for approximately 1/2 second. Avigilon demonstrated this issue during my tests of it last year. It's possible that your VMS has the same problem. The "run-on" problem can also occur with improperly calibrated joysticks.