help with RS-232 serial comms?

[ljarrald 0]

i have some PIRs and beam sensors that i will soon be installing to cover several of my cameras FOV.

 

the detectors will put the DVR into 'event' mode. i am using sensors because i am fed up with the unreliability of using motion detection from the camera feed.

 

the only inputs my DVR has are alarm inputs which i DO NOT want to use!

 

the only way i can put the DVR into event mode externally is through the RS-232 port.

i have never done any serial comms before so don't really understand what the manual is telling me.

to start with, i will be using my computer to test things out (i already have a usb to rs232 adaptor)

 

please, could someone explain to me what the manual means? and what would i have to send to the DVR to, for example, put camera 3 into event mode, and then take camera 3 out of event mode?

 

thanks in advance!!!

 

[Soundy 1]

Your PIR would have to actually generate a string of ASCII characters to send to the serial port... I'm sure they exist, but they're probably pretty spendy. Plus you can only connect one device at a time to an RS-232 input port.

 

What you'd need is some sort of external unit that will take the various inputs from the sensors and generate the serial output accordingly. Note that there is a "camera" string in the message, which would tell it which camera to affect - this is so an input from one sensor isn't triggering ALL cameras to a different mode, but only the one camera associated with that sensor.

 

Something like these would do the trick:

http://www.advantechdirect.com/eMarketingPrograms/L021113P1%20Sensor/ADAM4052_page.htm

http://www.advantechdirect.com/eMarketingPrograms/L021113P1%20Sensor/ADAM4053_page.htm

http://www.advantechdirect.com/eMarketingPrograms/L021113P1%20Sensor/ADAM4050_page.htm

 

You'd still have to program it, of course, to send the messages in the format your DVR requires.

 

OR...

 

You could just use the DVR's alarm inputs, as this is exactly the sort of thing they're intended for.

[ljarrald 0]

yes iknow. sorry, i didn't mention that i will be making and programming a device that turns dry contacts into the correct data string.

BUT. before i make it, i want to know what i am doing, hence why i want to play around with a computer connected to it first. so that i know *exactly* what i need to send for each thing.

it will make programming and debugging easier.

 

alarm inputs are not an option as the alarm inputs for most of the cameras are already used. each camera channel needs to have alarm input, AND event input. this is the reason i can't use the alarm inputs.

 

basically, i will be making something like the thing you have linked to.

i would buy the one you linked to, but i am trying to do it for as little money as possible.

 

i just need some guidance as to what to actually send to the DVR to get me on my feet. is it wanting binary, text, etc?

 

thanks for your help

[Soundy 1]

Ultimately it's looking for binary strings, but as far as programming, you'll usually be entering hex strings of ASCII characters. The "0x" prefix just tells the human that the following string is hex.

 

So the first thing you'll send is the "FF" delimiter (which will actually transmit "11111111 11111111") - that tells the DVR this is the start of a new message.

Looks like the Class and Command bytes are always the same - hex 14 and 40.

Then you have two bytes to tell it the length of the rest of the message, up to 502 total characters - that would have to be calculated once you know what the rest of the message is. The first two in that count would be the camera number, and the alarm/event field, then up to 500 more for the text.

 

Next would be a byte to tell it which camera, from 00 to 0F (decimal 0 to 15, which would be channel-1). So for camera 11, you'd send 0A (hex for "10").

 

For the Alarm/Event, you'd calculate the hex to match the binary...

- Event Start would send 01

- Event Stop would send 02

- Alarm Start would send 04

- Alarm Stop would send 08

If you wanted to send an Event Start and Alarm Start together, the binary would be 00000101 - hex would be 05 (add the two bits).

Sending Start and Stop bits together will just do a momentary Event or Alarm action - 03 for a momentary Event, 0C (12) for a momentary Alarm. Sending momentary Event and Alarm together then would be 00001111, or 0F (15).

 

The last is just plain text strings - for example, "This Alarm Start was brought to you by the letters J and Q".

Without the quotes, that's 58 characters. So going back a little ways, the "Data Length" bytes is where you'd tell it the length of this string, plus the camera and event bytes... total in this case would be 60 bytes, or 003C in hex. (If you don't want to add this string, the "Data Length" bytes would just be 0002, to cover the camera and event bytes).

 

So putting it all together... if you want an input to trigger an Alarm Start on channel 12 and add the text above, the full message you'd send would be:

"FF1440003C0B04This Alarm Start was brought to you by the letters J and Q". The system expects data up to the end of the event alarm/field, and then expects everything after that to be plain text, *up to the length that you specified*.

 

After that it's looking for a checksum, which the docs should continue on to tell it how that's calculated - basically the previous message would be added up in such a way to produce a certain result... that result is then entered in the Checksum field. When the DVR receives the message, it applies the same math, and if everything has arrived intact, will get the same checksum. If there's any data corruption, the checksum you give won't match the one the DVR calculates, and it will know there's a problem.