Soundy

There's not really such a thing as a "long range camera". Any camera will do, all you need is a lens with a long focal length. Depending on the area you need to cover and the size of the camera's sensor, you're probably looking at a minimum 50-70mm lens. Keep in mind that with that kind of throw, even the smallest amount of shake in the camera will be magnified greatly in the view, so you'll want to make sure the camera mounting is VERY solid.

Thanks for the tips, EBen. Vibration is a good concern too, although I've never yet known it to be an issue.

Well, since you haven't yet... I've always done it with USB-to-serial adapters as necessary. The exception to this has been this recent project with Camacc and Squirrel for a client that has 11 POS stations around a restaurant, which has led to their solution of having the Squirrel backend push the data over the network to the Vigil DVR, instead of taking an ASCII stream from the terminal itself. Serial adapters would work in this instance, but would be extremely unwieldy, particularly for the fact that you'd need a wire run to every terminal (well, you could run four feeds over a Cat5, but this site wasn't wired for that anyway). But in any case, I find the USB adapters work just fine - we use models made by A-Ten and have had no problems using them for POS interface, or for PTZ outputs off the DVR. Once the driver is installed, you can just keep plugging them in, and they keep popping up and more and more serial ports

The one other concern with wireless is, what's in the way? It may only be 20 meters, but I suspect that's not open air. Are there walls? And if so, what kind? Wood, steel stud, concrete? Each of these will successively have an adverse affect on your range...

Good advice in general, but we're specifically talking about CCTV lenses... There's not often a lot of choice in maximum aperture (most CCTV lenses are in the f/1.4 to f/1.8 range), first-party selection tends to be fairly limited (with not a huge range in quality between first and third party), there's not generally much in the way of "extra features" to be had (auto or manual iris is about the gamut), and even fewer reviews to be had. CCTV lenses simply aren't studied and debated to death the way SLR lenses are...

It's not a problem with IP specifically, but with 10/100 ethernet. Go to gigabit and it's not a problem anymore - heck, most basic cameras will work fine over 10Mbps, it's only with multiple ones that you start to have issues at 10/100. I have a site with 13 IP cameras, all feeding a gigabit switch, and an DVR with a gigabit interface, and no problems at all. When I was working in IT, I was on a site where the entire Head Office building used token-ring... most 16Mbit, but even at 4Mbit, users had no problem running MS Office directly from server shares.... using Netbios-over-TCP/IP. IP will work over pretty much every type of transport - ethernet is common and cheap, but it's by no means the BEST transport method. The aforementioned 13-IP-cam site, we put in a dedicated network for the CCTV system. In fact, all but one site I've rigged with IP cameras have used a dedicated networkin the last, the site's corporate people determined that the cameras would share a dedicated partition on their network switch). Lack of netowrk control is a cost/design decision, and hardly an argument against the viability of IP cameras. IP video itself has definite benefits for some applications, but the real benefit to CCTV is the ability to transmit higher-resolution video than analog, at relatively low cost with easily-available existing technology. Sure there are other methods available, but they're either non-standard or highly proprietary or still have limitations, and are far more costly to implement. For example, HDTV spec improves on analog, but requires either an expensive digital transmission method (HDMI, DVI, both of which are distance-limited and require thick, expensive cables), or a more complex, pricier analog method (component video), and still maxes out at effectively 2MP. Why? Main reason is cost, I would guess... additional hardware required for the capture system, which would be expensive for some time until the economy of scale can kick in. Other than that, it would be a nice solution if it could use existing coax put in place for CCTV. This is exactly the point, and is why arguments like cctvexpert's really grate me - it doesn't work well for one particular instance, ergo it must be useless for everything. Another thing is that "megapixel" and "IP" are used interchangeably, and they are NOT the same thing.

There are a few options for POS inclusion... and I've just been dealing with some of them recently, all using the Vigil DVRs from CAMACC/3xLogic. Vigil has a few different database options. It can accept plain ASCII input from a number of different POS systems via a serial port, and log it to a database that's synchronized to video, and each register can be assigned to a specific camera. We use this extensively with fuel services using Bulloch POS software. We're also testing a new interface for Squirrel POS systems that has the Squirrel backend pushing the POS data via network interface to the Vigil. That's kind of a beta thing right now, though. And Vigil has the ability to link in and read some other types of POS backend databases - I've tried it on one site that uses a Squirrel POS and can pull data directly from its MSSQL database. The trick to this one is that for proper synchronization, the DVR and POS clocks much match exactly, so you'll want some sort of NTP server/client on the two to keep them sync'd on a frequent basis. And there's the good old TVS text/video inserter... I've just recently installed the latest offering from Honeywell in a site, it's HIGHLY configurable (via web interface, nice) to work with a wide range of POS and ATM systems and overlays the text directly on analog video. It can also filter the data and feed it back out for DVR serial data capture. The catch with TVS is that it won't overlay on IP video, so in this one site, I have an IP cam and a small cheap dome side-by-side watching the paypoint, with the dome routed through the TVS. There are IP cameras, however, that have realtime analog output as well as the megapixel IP feed (such as the IQEye Alliance dome series) that would work great for this sort of situation.

Hmm, a few things to consider: One, wireless transmission takes a lot more power than simply storing the image locally... thus, you may want to consider a camera that just records to an internal flash card. There are lots of them out there, from "covert" designs to megapixel cams. Second, if you're recording to internal memory, I don't think you'll see substantial POWER savings choosing constant vs. motion-activated recording: the camera must still be active and capturing images; the only difference is with motion recording, it won't store the images unless there's movement. The alternative would be to have some other sort of motion-sensing device (PIR, etc.) that triggers the camera, but that too will drain power. Third, if the camera runs on DC power, you can probably use a gel-cel (sealed lead-acid) battery to get significant runtimes out of it. Maybe pick up a couple of 5-7Ah batteries and swap them on a regular (weekly? bi-weekly?) basis - run on one, charge the other in another location. If you're recording to a flash card, you might want to check and/or change that out regularly as well, so there's the opportunity to do both at once. Also, you shouldn't need to get 120VAC (or 240, depending on where you live) all the way to the camera... you just need a small wire to carry the 12VDC or 24VAC to it, and the power supply can go in another location.

That's good advice. That way you can always use baluns to run analog over the cat5 if you choose not to go full IP. Agreed, this is good advice. Just a word of warning, though: be sure to spec 24VAC cameras if you're using analog over baluns - I've had several occasions of 12VDC cameras having ground-loop problems over baluns, if running them all off a single power supply. If each is going to have its own wall-wart transformer, that's fine, but it gets kinda messy and cluttered that way. Just to clarify, it won't ALWAYS happen, but there's a lot higher likelihood of it. With 24VAC cameras, I've never had an issue with baluns. And back to the original question: no, you don't TECHNICALLY need a capture card to run all-IP cameras, HOWEVER... Iknow of at least one system where the software is fully "hybridized" (analog and IP cams within the same interface), yet the software won't run WITHOUT a capture card. It doesn't need analog cameras connected (in fact, I'm running one site with 13 IP cams and no analog at all), but the software does check for the card. Kinda dumb, really, and I'm hoping they'll do away with that in future versions. Oh, one other thing to note: some systems limit the software to the same number of channels as the capture card - that is, if it has a 16-channel card, the software only gives you 16 channels, period. This is a problem if you have, say, 10 analog cams and want to add 10 IP cams, and it's something to be aware of when you're spec'ing your DVR. This is the same system I mentioned above, BTW, and again, I'm hoping it will be addressed soon, because this limitation IS an issue on one site of ours.

Actually Soundy, there are a lot of 4CIF or D1(standard res) IP fixed and PTZ cameras made by Axis, Sony, Toshiba, Lorex, IQInVision, Trendnet and many others. Of course, there are also many megapixel IP cameras too. That's why I said, "TEND to be".

First of all, take what you read on Wikipedia with a grain of salt The definition of a "digital" camera is pretty nebulous, depending on each manufacturer's literature. Most modern cameras with analog video output claim to be "digital", mainly due to internal digital processing... doesn't mean they can transmit over a network. The term you're really looking for there is usually "network camera" or "IP camera". They tend to be significantly more expensive because of the hardware encoding and network interface additions. Most IP cameras also tend to be "megapixel" cameras... briefly, standard analog video is very limited in its resolution (740x480, or about 0.355 megapixels, for NTSC), and regardless of how high the resolution of the camera itself is, it still has to be scaled down for analog transmission. Adding IP support to a standard-resolution camera is rare, because it adds cost without significant benefit. If you want to go beyond those resolutions, you need a different method to move the video... HDTV uses component and/or HDMI, for example (and even that is limited to under 2MP). Megapixel CCTV cameras generally start at 1.3MP and currently go to about 5MP in "common" designs. Naturally, the higher resolution makes them worth the added cost of adding the network support. Hope all that makes sense... to summarize, with standard PTZ cameras, you won't have built-in encoders or network interfaces, they'll still just be outputting basic analog video (the same as comes out the back of your DVD player and into your TV via the yellow A/V jacks, for example) and you'll still need a capture device to encode it on your computer. Your recording is probably using software encoding. A card/adapter with hardware encoding will help that a lot. With a dedicated DVR, you're not usually going to tell it to stop and start recording, because there's simply no need to - just leave it running all the time, and if space is an issue, set it to only record when it detects motion. Almost all of them have this capability built-in. And actually, I don't think I've ever seen one that ACCEPTS Pelco control... I don't think D/P protocols even have "stop/start" recording commands...??

Not really. I use an Adaptec Gamebridge TV, a USB video-capture adapter with built-in TV tuner. Paid about $30 for it. They have (or had, at the time) a non-TV variant that I think was about $20. The downside to this particular Adaptec unit is that all the video processing is done in software, so it is a fair bit more taxing on the computer. There are hardware-encoding units available for <$100 though, that do all their own video processing and would present relatively little load on the machine. With Mac though, your selection may be a little more limited. Depends. If it's just something to tinker with, I wouldn't bother with a separate DVR. If you want something to permanently record video for security purposes, then you probably do want a dedicated system, be it a standalone DVR or a separate PC-based DVR. You don't send control signals to a DVR, though... all it does is receive, digitize, and record the video. Some do have PTZ control capabilities, which means the DVR would then control the camera and you wouldn't have to code anything... but where's the fun in that? All the Pelco commands do, is tell the camera how to behave: tilt up, pan left, zoom in, etc. Nothing relevant is sent back to the computer (there would probably be some serial checksum data and such for command confirmation, which may be useful to you when writing the software, so you know the camera is receiving and responding to your commands, but other than that, there camera doesn't send back any data over serial lines).

Worst case, you could use a hacksaw (CAREFULLY) or Dremel with a cutting wheel to cut a slot in the nut head, and just use a slot screwdriver with it.

It's not really that complicated. All you need to do is send a series of command codes to a serial port - none of it is specific to any platform, OS, or coding language. Any comm libraries for use with modems and other serial comms should do the trick. If you're on a Mac, you'll need something like this: http://www.usbgear.com/USBG-232MINI.html - beyond that, just connect pins 3 and 5 to the camera's RX connectors (you only need to transmit to the camera, there's no need to receive from it), and code your software to transmit code strings over the port. There are some good examples here: http://www.232analyzer.com/RS232_Examples/CCTV/Pelco_D_Pelco_P_Examples_Tutorial.HTM#1 and http://www.codeproject.com/KB/cs/PelcoPDinC.aspx Note in the second link that they're doing it via C# classes, but C# isn't necessary to this - again, it's just simple code strings sent to the serial port, so any suitable classes in your dev platform of choice will suffice.

No idea, I'm not familiar with that specific system. I know older Video Insight systems only supported recording to a single drive; this may have a similar limitation. You may have to set the software to use only the 1TB drive (which should give you LOTS of storage anyway). In some cases, with the older VI setups, we set multiple drives/partitions as Dynamic drives in Windows, and then formatted them as a single striped set... you can go that way, but be aware that if one drive fails, it will destroy the stripe and ALL of your video data.

Assuming the system uses onboard video: If one of the new sticks is faulty, or if the driver doesn't like the timing or some other aspect of the new RAM, that could causing a problem with DirectX or the overlay (depending on which the system uses). You could try reinstalling the video driver, or put the old RAM back in, note the timing settings in the BIOS, and then set the new RAM to match.

Is it displaying ANYTHING on the main live screen, or does it just have little blank windows where the cameras go? If you take out the upgrade RAM, does the display go back to normal? If the PC uses onboard video, it's possible mis-matched RAM is causing a display problem. Have you configured the drive in Windows Disk Management so it's available to the system?

Have you ever been able to connect to your cameras from outside your home? When you're using your laptop AT home, it's generally connecting on your LAN and isn't affected by the router's firewall... when you want to connect from outside your home, you need to configure your router to pass on the appropriate port(s) to your DVR.

The most common protocols for PTZ cameras are Pelco D and Pelco P - a lot of cameras use their own specific control languages, but almost all support one or both of these as well, as do most DVRs. It's a relatively simple serial protocol, generally transmitted over RS-232, RS-422, or RS-485 (the transport protocol, BTW, is irrelevant to the control protocol, so you don't have to worry about that). A quick Google search led me to this page: http://www.control.com/thread/1026204047 There you'll find a number of sources listed for the Pelco D/P specs. As for doing research "first"... isn't asking here considered part of your research? Hopefully the above will give you a starting point, and you're always welcome to come back and ask more questions

I've worked a lot with MIDI in the studio... I can state with 99.999999% certainty that you won't find any cameras accepting MIDI control. Aside from the fact that the two come from widely different industries, you'd have a hard time convincing any camera manufacturers to support it when MIDI cables have a range of (if memory serves) 50' maximum. Besides the camera supporting it, you'd need the control units (joystick controllers, DVRs, etc.) to support it as well. With so many established standards designed specifically for camera control, adding another, more complex, more limited one would be a hard sell for any designer. As for dolly systems... no idea there. I know computer-controlled broadcast cameras are the norm in newsrooms these days, perhaps something based on those designs could be adapted to CCTV. It wouldn't be cheap though - even simple fixed-mount PTZs are significantly pricier than standard fixed cameras.

Other than maybe Vise-Grips (long-nose?), I think the wedged-screwdriver trick is probably the best. All the maglocks I've ever dealt with, the nut and bolt come apart so easily, I can just hold the nut against the door with finger pressure while I undo it - did someone use threadlocker or something on this one?

This is a good point. Obviously the law will vary depending on the area, and I'm no lawyer either, but I'd think that yes, there would be a reasonable expectation of privacy in your *fenced* yard, and if nothing else, it shouldn't be hard to get a ruling against his camera(s) pointing into that area, especially if they're mounted specifically to allow them to view that area (high vantage point, etc.). It's one thing if he can claim that he just his cameras set up for a wide shot of the neighborhood and your house just happens to be in the field of view, but quite another if he has them placed and aimed such that they ONLY capture your house and yard. The key in this case, if you want to win the judge's favor, would be to NOT muddle the case with all the other BS the neighbor has pulled, but to stick to the issue at hand: his cameras are invading your privacy, and you want it stopped. Period. The judge likely won't care about all the background between this clown and the rest of the neighborhood, so just keep it simple and stick to the point.

Well the next question then is, what do you want to do with the signal? Are you going to record it, or just watch it on the TV? If you're planning to record it, are you going to get a dedicated DVR, or just an add-in card and software for an existing computer? Main thing is, is this going to be a serious security item, or just something to play around with? That determines how much more you're going to spend on it. First thing you need to do is run wires from the camera location, to wherever you want to control/watch it from. RG-59U coax is the cable of choice for the video signal; anything 18/2 or so will work for power, and another for control... or something in 18/4 (intercom cable or something of the sort). Lots of people here will recommend "siamese" cable, where the coax and power (and sometimes control) are all joined by a web to make a single cable - it's a lot easier to run (in most cases), but tends to be a little pricier and not always as readily available. Once you have that down, you'll need to be able to control the camera. If you go with a standalone DVR, you'll need to make sure it has this capability, and support for Pelco D and P protocols. If you're running into your PC, or if you just want to be able to watch it, you can control it from your PC's serial port (you'll need a DB9-female connector), using software like ike PTZ Contro. OR you can just get a dedicated PTZ keyboard/joystick unit (lots on eBay). That's your basics The one question I'd have is, what's the capacity of your transformer? PTZs tend to be pretty power-hungry, especially if they have heaters built-in, once you start driving them around. I'd recommend a transformer rated at 75VA or better, or you'll run into problems. Hope that helps

Short of hiding the whole DVR, it's a good idea. Take it one farther, and use a NAS box of some sort, as a network cable can be a lot longer and will be a lot less noticeable than "what's this USB cable running off to?"

A quick and easy way to determine whether the problem lies in the camera or elsewhere is to go into the camera's own web-based viewer (assuming it has one?) and see if the blur issue still exists there. If so, you can rule out the DVR, and avoid a lot of time playing with other systems and sending tons of stuff to tech support. Now assuming you narrow it down to the camera specifically: You've tried adjusting the shutter speeds, but to what? You ideally need to be 1/60s or faster. If you're in the 1/4s-1/15s range you can tweak it all day and it won't help matters. Remember your lens aperture as well - if it's closed down too much, you're reducing light and have to compensate with a slower shutter. Open up the lens more, if possible, to give you more range with the shutter. If it's already wide-open, maybe you need a "faster", larger-aperture lens. What's this lens's maximum aperture? It will probably be listed as something like 1:1.4 or 1:1.8, printed on the barrel of the lens.