RS485 PTZ Control

jameswilson · Post by **jameswilson** » Wed May 24, 2006 8:49 pm

it has external triggers as Phil rewrote this part, all it needs is a script and zm will respond accordingly. Ideally what i need is an expandable io system ie 8 inputs and 4 outputs. 485 link re ptz is already done and supported but i was thinking of using 485 for io that way for example you could fit multiple movement sensors adjacent to a ptz camera and use the sensors to trigger alarms and move the ptz to presets, plus use the outputs to fire lighting. I also want to be able to fire outputs via zm4ms and the web interface for controlling barriers, sounders door locks etc. It also needs to be an opto isolated input else interference damage lightning etc would stick voltage into the server. I have yet to find a suitable device that is a resonably cheap b relativly accesible and c professional looking

marv2097 · Post by **marv2097** » Wed May 24, 2006 9:30 pm

Initially I hadnt thought of making the IO board sit on the same bus as the PTZ. Althought it could well be possible and maybe a good starting point.

I would be using a PICmicro to do the decoding of the data and control of the IO's. I would think a variation of pelco/bbv protocol but with different start and stop bytes would be easiest to implement quickly. This would make modifying the control code a lot easier.

I currently have a device called an USB IO/24 which has 24 IO ports and is controlled via usb as a virtual com port. This seems to work well but was about 60USD. Unfortunately it can nly sink 30mA and its inputs have to be 5v. We would need to look at suitable input and output stages and as you mention use Opto-iso's for them. All devices on a RS485 bus should be isolated from it anyway.

As for your comment about moving a dome to a preset position etc I think this would be handled by by ZM or whatever app is controlling this. Rather than the device doing this itself.

When I get some time over the next couple of weeks I will look at making a proto type and try and get it to respond to Pelco commands for a start and see where it goes from there..

jameswilson · Post by **jameswilson** » Wed May 24, 2006 9:45 pm

As for your comment about moving a dome to a preset position etc I think this would be handled by by ZM or whatever app is controlling this. Rather than the device doing this itself.

Definetly should be done by zm with a note entered in the notes field for the images etc so that only a particular preset when in alarm can be played back.

re the modified protocol, i will bow down to you on this. The only thing with modifying it is if we test it on say a pelco and a bewater dome and it works great ut is icompatible with a different product that supposibly supports the same protocol it would be a pain. I like to stick to the standard unless its totally guaranteed not to be an issue.

Also alot of domes have alarm inputs but dont seem to send the status over the 485, is this true or are the status's just ignored?

I can see where your going re your usb thing and it will be a help. re the low sink current, we would just have to hang some trans relays of the back of it i suppose. I wanted to find a device like the cbus alarm expander from dm, but i doubt they would release there 485 protocol for this

Regards JAmes

marv2097 · Post by **marv2097** » Thu May 25, 2006 9:37 am

jameswilson wrote:re the modified protocol, i will bow down to you on this. The only thing with modifying it is if we test it on say a pelco and a bewater dome and it works great ut is icompatible with a different product that supposibly supports the same protocol it would be a pain. I like to stick to the standard unless its totally guaranteed not to be an issue.

I think with this we would need to use our own variant of a protocol that is easy to replicate. If we use Pelco-P or D then any other pelco devices on the bus might cause a conflict if the have the same address. Also if ZM is up to it it should be able to transmit multiple protocols down the same port. Another reason not to use pelco is that this protocol is designed for PTZ functions and not as suitable for IO as a custom protocol would be.

jameswilson wrote:Also alot of domes have alarm inputs but dont seem to send the status over the 485, is this true or are the status's just ignored?

On many devices I think you have to poll the status of the alarm inputs. This is something we would need to consider: Do we send a message as soon as a IO state change has occured or only when the state is polled by the host app. Maybe both is the best answer.

jameswilson wrote:I can see where your going re your usb thing and it will be a help. re the low sink current, we would just have to hang some trans relays of the back of it i suppose. I wanted to find a device like the cbus alarm expander from dm, but i doubt they would release there 485 protocol for this

I have a copy of the this protocol and sent the some info to Phil on it, not sure if he got it? Does anyone have the VCL protocol as I have a dome I want to test out with it..

jameswilson · Post by **jameswilson** » Thu May 25, 2006 11:06 am

im sure someone on here said they had it. If not im sure i can get it

Post by **zoneminder** » Thu May 25, 2006 3:37 pm

I _think_ I may have it somewhere. It's a bit of a fiddly one though if I recall.

deridere · Post by **deridere** » Tue Jun 20, 2006 5:46 pm

Check this out
http://norbain.co.uk/downloads/manuals/HBZRM-E.pdf
http://norbain.co.uk/downloads/datasheets/zr34lft.pdf

Probably It will be easier to control this type of receivers if we can find Baxall Telemetry specifications.

They are very cheap on ebay

Hope this helps...?!

jameswilson · Post by **jameswilson** » Tue Jun 20, 2006 6:12 pm

Baxall is very similar to bbv protocol but is (at least i think) uk specific. Plus not widely supported outside of baxall kit (pyrimid etc) I for one would love to have baxall and bbv telemetry as it would i/f directly with som eo the kit i have!