Soundy

SO what was it?

No, they're not IR - they don't need it. They're one of the best-performing low-light cameras around. 30fps is overrated and unnecessary in most cases. Most people won't even see a difference between 30 and 15fps, and unless you're in a casino trying to watch a dealer's hands, you won't miss anything at 7fps. This DVR is fine. Please. Hundreds if not thousands of baluns installed now in the last five or six years, and I've maybe three fail in the field once they're in service. This is the only concern with the EV01P-VP-T - it won't fit inside the VCM's back-box. It also only has a male jack for the power connector, so you can't plug the power splitter into it. Instead: if you're going to flush-mount the cameras, go with the EV01P-VP - it's a package with two baluns, one with a male plug for the camera end (which you're going to cut off for this camera anyway), one with a female plug to plug the power adapter into. OR... if you're surface-mounting the cameras (using the back-boxes), get two EV01P-VPDs, which have both male and female plugs, to put at the head end and plug the power supply into... then for the camera end, find a pair of these: Split out the camera end of the Cat5e, connect the video pair to this, and the power pairs directly to the camera's terminals. These baluns are a nice snug fit inside the VCM back-box, which helps keep the wiring in place while you assemble the camera into it. It will look something like this (although with different colors IF you're using the EV01P baluns at the other end):

What does this camera need to do? High-res? WDR? Low-light color? Day/night?

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.

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.

You can get baluns that have RJ45 jacks and split out to BNC and pigtails... but I just do it like this: Heavier by a whisker 23 AWG vs 24), but not necessary. Considering these cameras can be happily powered at 12V over a single 24AWG pair, which is pretty much the lowest you can go... yeah, not needed. Certainly not worth the added expense. Sorry for the noob questions, but after looking at your photos why not just use this: http://www.easterncctv.com/accessories/ev01p-vp-t.htm Only reason I ask is because I'm going the balun route too and just doing research. EDIT: I should mention I plan on using a EV08P-VPS I've used those as well, with the EV16P-VPS... main reason is that the EV01P-VP-T won't fit inside the VCM's back-box. They work great if you're flush-mounting the camera or have an electrical gang-box behind it, but when surface mounting, I use the GEM mini-baluns pictured - they fit inside nice and snug and help keep the wiring in place

http://www.flir.com/thermography/americas/ca/view/?id=51351

Gotta be careful going the other way, too - working out in the heat, you definitely have to take precautions. We did one warehouse job, my coworker spent the better part of a 12-hour day in a zoom-boom lift, 20' up an all-white, south-facing wall... so he not only got the direct sun all day, he got it reflected right back from the other side too. By the end of the day he was so punch-drunk from the heat, he drove the lift off the sidewalk and dropped one wheel into thick, fresh sod

Pictures of the unit... any and all information from any labels on it... even photos of the screen(s) if possible, will help determine the actual unit you have there. Problem with a lot of low-grade brands like this, they're just re-selling units from a number of different manufacturers, and the process you need will depend on who this DVR is actually made by.

And thank YOU - your first post gave all the info needed to solve it. So often it's just "My thing isn't working, how can I fix it" followed by three pages of back-and-forth trying to extract enough information to figure it out. More people should take a lesson from you when they come asking for help

px2fjhliA8s

??

He'll come around the first time a serious incident happens and the video is completely useless...

Outdoor installations often have to wait on the weather. Environmental housings and domes have to stay dry inside and thus shouldn't be installed in rainy weather. Below freezing, wire can become brittle and caulking/sealant might not set up properly, or may simply crystalize. And of course, when snow and ice come into play, there are safety concerns. We started one week-long out-of-town job last October, and the second day there the snow came to stay... since we had to install the cameras off ladders and run some cabling across the roof, the exterior cameras ended up being put off until... well, about a month ago.

Remember the old weakest-link theory - you only 450Mbps if the router supports it as well, and only under ideal conditions. In reality, even on wireless-G adapter (54Mbps max) is more than enough. Keep in mind that the LAN ports on that unit are only 10/100 so the link between the adapter and the DVR is only 100Mbps at best.

I don't think "top of the line" is required so much as simply "the right" adapter. I think this is the post you're referring to: viewtopic.php?f=1&t=30496&p=191094&hilit=wireless#p191094 Pretty much any "gaming" adapter should work - doesn't need to be an over-the-top unit. At home, I use multiple cheap routers running DD-WRT firmware. You could also look at ethernet-over-power adapters, which I think would be more reliable overall than WiFi.

I don't think "top of the line" is required so much as simply "the right" adapter. I think this is the post you're referring to: viewtopic.php?f=1&t=30496&p=191094&hilit=wireless#p191094

I'm not even sure you do. 30fps for NTSC *is* realtime. You can't go higher.

...maybe. SDI only does up to 2MP - even in IP cameras now, 2MP is bottom of the barrel.

Correct. Try using 192.168.000.001

You shouldn't (need to) use "http://" in the SMTP hostname. Your DVR should also have DNS entries of some kind, otherwise it won't be able to lookup the SMTP server by name. If your router supports DNS pass-through, just put the router's IP (192.168.0.1) as a DNS server in the DVR. Better yet, switch the DVR to use DHCP, see what settings it gets from the router, then set it back to your hardcoded address.

These are designed specifically for what you're trying to do: They're called "door loops" - search for that term and you'll find plenty. Another option would be to dig a small trench along the bottom of the fence; run the wire all the way across and up the far-left post. Mount the contact on that post, and the magnet on the gate. The contact can be near the bottom, it doesn't need to be up high - say, right above the bottom deadbolt. As far as the wire to use, I'd just go with the standard 22/4 station-Z wire. It's solid-core, but still pretty small and flexible. If you wanted to get really trick, you could use modular phone cord... that should be available in two-conductor stranded; it's flat, flexible, and it tends to withstand a lot of abuse.

If it's the same as the TENVIS iprobot3 I have here: IE uses an ActiveX control; Firefox and other browsers will use a Quicktime plugin. You could try a Firefox extension called "IE Tab". Again, assuming it's the same interface as this camera, the presets are the little "crosshairs" icon right under the PTZ controls. You drive the camera to where you want the preset to be, select the preset number from the dropdown list, then click the "hammer" button to Set it. After that, you select the preset number, and click the arrow button to go to that preset.

Personally, for analog cams, I'd use the CNB all around instead of any "night vision" cams. The 2MP dome is a nice little camera, but it does need a fair bit of light. It will be great at the front door if you have a decent porch light. As to some of the other questions: Correct. 2.8mm on a 1/3" sensor will give you pretty close to a 90-degree field of view. Any cameras that use NTSC composite video are compatible. That covers just about any analog cameras you'll find out there (at least until you go to Europe). The one exception will be cameras that came with a "package" video system that use a proprietary multi-pin connector - while those are *technically* compatible, making the physical connections will be an issue. You can get facial ID from even the cheapest, crappiest of cameras... under the right conditions. It all comes down to the resolution, and the field of view vs. the distance the person is from the camera (and to some degree, the actual image quality). A camera on the corner of the house with a wide (90-degree) view will not allow you to ID someone 50' away. A camera with a tight shot on a "choke point" (like a garden gate, say) at 30' probably will. Cat5 all the way, especially if you're starting with IP cameras. Smaller, cheaper, and easier to work with, and far more versatile. Swapping an analog cam out for an IP cam later on becomes a snap. The Dahua DVRs and IP cameras work great with remote operation. The DVR web client gives full control over the setup and operation of the DVR; it's arguably easier than controlling the DVR directly. The PSS software will let you view and manage the DVR, and the IP camera directly in the same window. Sure, but I don't recommend it. Wireless should be reserved as a last resort, if there's no practical way to get a wire to where you need to go. Remember that a camera still needs power, so you'll need at least one wire to it anyway. Pictures of Kate Upton.