Soundy

Well to oversimplify somewhat, with the aforementioned systems, two processes are happening during recording: one, the video itself is being written to the hard drive in files; two, a database is updated with searchable information on the video - when motion was triggered, what timeframe is covered in what files, etc. When you want to look at recorded video, the system looks at the database for the time(s) you want, and then calls up the appropriate file(s). Now in some instances, the video is being written to its files, but the database isn't being updated to tell the software which files are which, so that when you go into Search, the software finds no entries in the database, and so doesn't know that there's video to match. In the case of this particular Vigil, a corruption in the database (caused by a failing hard drive) meant that it wasn't being updated, but since the video was recorded to a separate drive, the video files were still being written... the Search function just didn't know they were there.

You make some good points here... I'll add a couple of comments. Another limitation of analog is the analog video signal itself. Since NTSC video has a maximum of 525 TV lines, and PAL a maximum of 625 lines, that pretty much limits the maximum possible resolution regardless of the capture card. Cheaper cameras with smaller CCDs output even fewer lines - 480, 420 and 380 TVL is common. Some higher-end cameras do 520; some of the really cheap board cameras come in <300. Regardless of what resolution you sample at, your vertical image resolution will still be limited by the capabilities of the camera itself. There are a few others also in use that work well. The Vigil DVRs use an AZTECH codec, which I believe is based on H.264 but is optimized better for security recording (MPEG4 is also selectable as an option). The newer VideoInsight systems also allow (and include) Windows Media Video (WMV) 9, which in my experience works fairly well. A well-designed system will allow you to select the codec used on a per-camera basis to optimize for different viewing/recording conditions - Vigil and VideoInsight v3.x support this (VI 2.x and older don't). Some may also allow you to use any installable codecs available - DivX, for example (which is MPEG4-based). And the major drawback to hardware compression is, you're stuck with it. With software compression, the manufacturers could provide an updated codec with improved performance/quality... with hardware compression, unless the card is flashable (unlikely for cheap cards), you don't have that option. It should be noted, just for completeness, that there are QIF/CIF/4CIF IP cameras available as well. Some of the same advantages apply, such as on-camera compression, no need for a capture card, and so on, but of course still with the lower resolution. They tend to be sold as webcams and consumer-grade surveillance cams; not something you'd generally want to use is a pro installation, but as I said, I'm just tossing it in there for completeness of information That's what we've been doing for a while now. The Vigil systems support a mix of both analog and IP cams, so we're even retrofitting a few existing installations with IPs. VideoInsight has a separate "IP Server" module that can be installed stand-alone on a PC for an NVR system, or on one of their "Analog Video Server" systems to create a hybrid recorder. Others have their own variations on the theme; again, those are just the ones I'm familiar with.

Not being familiar with that particular system, I'll offer something based on a couple other systems I've used. On both VideoInsight and Vigil systems that I'm familiar with, searches are done via a database maintained by the software. If the database isn't being updated or the updates aren't being read, search won't show any recorded footage, even though it IS being recorded. I saw this several times with older versions of the VideoInsight software, where the database simply wasn't being read so the available clips weren't being displayed. Restarting the software forced it to re-read the database and the missing clips would then appear in the tree view. On a Vigil I'm fixing right now, the database wasn't being written to with new video for about the past month, even though it was recording the whole time. Running the database rebuild utility re-scans all the video footage and recreates the database (it's underway as I type this). So something to try is to look in the actual video folder(s) and see if the cameras in question have video clips there (and again, this is just a guess, as I have no first-hand knowledge of Netsafe systems - I know some others, like Capture, pre-generate "bank" files and then put the video within those).

I have a DVR here running 22 analog cameras on a 240fps/32-input capture card, plus five 1.3MP IP cameras. Cameras are all recording at between 3 and 7 fps. Needless to say, this eats up a lot of space: I have 3TB internal and the thing is barely keeping three weeks of data. The client wants 90 days(!!!) So I'm looking at a NAS RAID box of some sort... something rack-mount would be nice, but depth is limited, and all the rackmount units I've looked at so far only hold four drives... and we're looking at probably needing 8-9TB for the amount of storage they want. It would also require a new switch, as the one I have now only has two gigabit ports in addition to the 24 10/100s. I've considered a couple of DROBO boxes as well, but I don't think the USB interface will handle the throughput I need on a sustained basis. Anyone done something like this, and can you suggest anything for me? There's room in the bottom of the rack as well as on top of the rack for a larger box to sit, too...

How are you connecting to the PTZs? Onboard serial ports, USB-to-serial adapters, or other type of serial interface? Are you using RS-232, RS-422 or RS-485? I've seen a problem when using RS-232, where you have to connect the camera using proper polarity with the power down, power the camera up, then reverse the polarity on the serial wires, after which it works fine. Sometimes it just works, but sometimes this trick is required. If you're using an RS-232 to 422 converter, it shouldn't be a problem.

I've had no problems using an ATEN USB-to-Serial adapter cable. Works on both my laptops and with a variety of DVRs I've used them on. Should be available for $15-$20.

Typical CCTV lenses are set up thus: Ring closest to the camera body is focal length (wide/tele); may also be marked with W and T. Center "open/close" (or O and C) ring (if applicable) is manual iris. Ring farthest from camera body, or sometimes the entire end of the ring barrel, is focus, often labeled Near and Far. There are variations, of course... a lot of Panasonic auto-iris, fixed-length lenses I see, for example, don't have any adjustments on the lens itself. Since fixed-focal lenses don't have a zoom function, and the iris is controlled by the camera, the only thing left is focus, and these lenses rely on you using the camera's backfocus ring to adjust that (so instead of actually adjusting the lens, you're adjusting the position of the camera's sensor).

I have three different Capture PTZs - two older Fastrax models and a newer Minitrax - two of which are having issues accepting control from DVRs. They work fine with the Capture joystick, but for the life of me I can't get them work off any kind of PC/software control. But that's a story for another time... at the moment what I'm really after are manuals for the things, particularly the Minitrax. And the thing that's really pissing me off is that Capture doesn't have them on their site. There's a "View All Manuals" link that does nothing, and when you go to any particular product, they have links for product images and brochures... but not for a manual (example, for the Minitrax: http://capturecctv.com/product.php?prod_id=216) Capture's support is no help, they just tell me to go to AV Logics' site, where they have even less information and the support people I've tried there are even less helpful than Capture's... So, after all this rambling, does anyone have any other online sources for these manuals?

Thanks, looks like a pretty cool product line! Think I'll be contacting these guys...

I didn't really find any specific info on anyone doing this, so I guess I'll be the first to ask: is anyone retrofitting IP cameras and NVRs using ethernet-over-coax tranceivers? I've found these products that will do the trick - http://www.omegacubed.net/ethernet_over_coax/ethernet_over_coax.html - but they're UK-based... I'm wondering if anyone on this side of the pond knows of any products like this (Canada-based, ideally). We have one local supplier (sort of) but their adapters are pretty pricy.

Most analog cameras that have "day/night" modes switch to B&W in low light as well... This affects the industry as a whole, in my experience. I went on one site - a gas station - where a new corporate-selected CCTV supplier had sent some electricians to install a new DVR (replacing existing MUX and VCR), three LCD monitors, and replace a bunch of cameras and the power supplies (it had been running mostly on a bunch of 24/40 wall-warts on a couple power bars). The electricians had the place ripped up for close to a month, botched the job of hanging the monitors, and attached the car-wash cameras to nothing more than the soft vinyl siding inside the car wash. Instead of using a single 16-channel power supply, they used one eight-channel unit and two four-channel units... and then doubled-up a number of channels, so only 11 of the total 16 available screw terminals were actually in use. And then they HARD-WIRED them all into the line power running BX into a gang box. And these are monstrous Pelco power supplies that are now eating up a ton of shelf space in the office. Yuck! I really don't have much experience outside the IQEye cameras, but I find they have pretty good low-light performance. Not "amazing", but perfectly acceptable in most situations. Take a look at http://www.iqeye.com/IQeye750-Day-Night.html The biggest drawback I find, actually, to most IP cameras is their lack of auto-iris support - it makes fine-tuning them a little trickier in contrasty areas, and manual-iris lenses are getting harder to find.

Wow, don't ya love people bumping ancient threads? I've flipped through this debate (not reading EVERY message) and the one thing I haven't seen anyone mention is the RESOLUTION possible with IP cameras. NTSC analog cameras max out at, what, 520 vertical lines? Your basic capture card gives you maybe 720x480 resolution digitization. Anything beyond that is going to get VERY expensive, and you're still limited by the maximum resolution of analog video. The cheapest IP cameras we work with are 1.3MP - 1280x1024, almost twice the horizontal resolution and 2.5 times the vertical detail of analog capture. They're about twice the price of the most expensive analog fixed cameras, but I can use one 1.3MP camera to cover what would typically take me FOUR analog cameras. Working a lot with gas-station installs, they want to have clear pictures of people's license plates at the pumps. One analog camera set wide enough to see both sides of a pump will just BARELY result in a legible plate under ideal conditions, otherwise two cameras are required, one for each side. If you have two pumps on an island, that's four cameras to get good, clear plates. Alternately, I can put a single 1.3MP cam on the building or a pole off the end of the island and cover all four pumps easily... on one site I even have two cameras covering 6 pumps on three islands (12 fueling positions), both sides of an outer island and one overlapping side of the center island. Another station has three cameras in its store, and they get clearer views of faces and activities through the whole store than a similar station gets from 8 in-store cameras. TCO may still be lower on a "per-camera" basis with analog, but that difference quickly fades when you consider what you're able to see and how many cameras are actually required. And as HAS been noted, infrastructure CAN potentially be cheaper, because you don't need to use a star topology and home-run every cable. Yes, outfits like NVT make video baluns and multiplexing systems that will let you get away from the star topology, but that's going to drive the cost up again.

I have a customer with a Capture keyboard running three PTZ cameras, interfaced through a Capture HID2404CJL box. To facilitate upcoming upgrades, we need to move all their camera control to the DVR, but they're not happy about losing their existing keyboard/joystick control setup. Now this 2404 box has a DB9 RS-232 port labeled "DVR"... so I'm wondering if anyone knows, is this to allow passthru of DVR control signals... or is it for output TO a DVR? If the former, it would make my job of switching them over a LOT simpler.

If you're talking about web access, you could always create a web page on one of the DVRs consisting only of links to each machine's web interface at the appropriate port... something along the lines of (substituting for html tags) (url=http://dvr1:5550)click here for DVR 1(/url) (url=http://dvr1:5551)click here for DVR 2(/url) (url=http://dvr1:5552)click here for DVR 3(/url) Beyond that, you could implement a scripted install of the Multiview client, with instructions that they need only to run this simple package and all will be installed and configured as necessary. How well the base installer itself can be scripted, I have no idea - it may require a utility like SysDiff.

Did a bit of searching and couldn't find anything related... I'm just looking for some kind of basic (preferably freeware) PTZ control software that I can throw on my laptop for troubleshooting PTZ cameras. You know, connect laptop serial port direct to camera at the camera location, fire up software, test functionality. Most of the cameras I'm working with so far are either D, P, or Fastrack protocols, so nothing too fancy needed. Any suggestions?

Thanks, I'll give that a look.

Just as a point of interest, this particular length restriction is specific to *ethernet*. I've seen token-ring networks operating over Cat-3 shared with a phone line, pushing 500' without issue. One site that I worked on many years ago, we were switching all their T-R systems over to 10/100 as part of a new system rollout. All the existing lines were Cat-5 and routed through BIX-blocks in the server room before terminating at the patch panel. The client ends (mostly at user desks) typically had two or four runs into boxes with interchangeable jacks, which made things SO easy - want a phone there, punch down the appropriate jumpers on the BIX block, and drop in the appropriate jack at the desk. Want to switch from T-R to ethernet, just change one set of jumpers at the BIX, change the patch from the T-R hub to the new ethernet hub (switches weren't very common then), and drop in the appropriate jack at the desk. We did this in the building super's office at the far end of the building from the server room... and it worked... at first. Connection kept dropping out... so we pulled the jack sockets out of the wall to find... Cat-3. Then we traced it up the wall and out the top where it went up to the ceiling of a service bay... and into a splice point. Then it zig-zagged across the ceiling to another splice point... right beside an open 220V three-phase junction box. Then it zipped off into the ceiling of the office space. We estimated the actual length to be somewhere near 360'... Cat-3 all the way... at least two open splices (and we're talking, ends twisted together and taped up), one of them by an electrical junction... no wonder the new 10/100 connection didn't work! And yet the T-R handled it all without so much as a whimper. We actually put that one station back on T-R (the sites were using routers - REAL enterprise-level routers - and hubs, rather than switches, so it was possible to leave the T-R hub connected to the router and keep the guy online) and called someone else in to make new Cat-5 runs to the office... without the zig-zagging!

You didn't put any cost constraints on it, so... have you considered satellite internet? Lots of providers out there: http://www.google.com/search?q=colorado+satellite+internet

For a good, low-cost router, take a look at Belkin. I got a half-dozen wired broadband routers at a computer-superstore sale once for $10 each, and another store had some wireless ones for $15 each at a sale a couple years ago. They work well and are easy to configure. Everyone's high on LinkSys and I don't understand it - every client site I've ever run into that has one, I've ended up having to give their DVRs static IPs if they want remote access, because the router's DHCP server is constantly changing the DVR's IP (even if the DVR is never restarted), and it buggers up port-forwarding. I've always been a fan of D-Link and I've only ever had one bad one over the years - a DI-524 which even the store clerk admitted (when I brought it back) that that was a really poor model. Even my old DI-604+ is still running strong at a friend's place. As far as broadband routers go, Netgear's configuration pages drive me nuts. Very poorly organized, and unless you deal with them enough to find your way around blindfolded, many of the links to other sections are far from obvious.

Look at the VideoInsight DVRs - they'll handle up to 32 cameras on a single DVR as well, using a single card with a daughterboard.

Well the same advice applies... the most basic troubleshooting is to swap the suspect camera with a known good camera and see if the problem moves with it. Pretty simple, really, I don't understand why it needs to be repeated so many times.

Here's a good way to simplify it: "You get what you pay for." A lot of bullet and dome cameras I've seen all use the same type of basic small board camera. The basic design is the same; what really affects the final product is the quality control in the construction and component selection. Some better designs add a voltage-regulator board that can help increase the life of the camera, as the small components tend to be a lot more sensitive to voltage variations. Heat is also the enemy of electronics - I've seen one particular line of high-end dome cameras with a very high failure rate, because the dome for some reason retains heat, and the camera boards they use (including voltage regulators) seem to generate and excessive level of heat. Ultimately, though, the image quality of any camera depends on the lens. The sensor can only reproduce as good an image as it's given.

I've put a number of CRT-based rear-view systems in garbage trucks. Nothing wrong with them, really, the CRT just isn't as "sexy" as an LCD. Functionally they're the same, possibly even a little clearer without the LCD's pixelization.

Yup... and the only time I've seen the term applied to cameras is when a board camera is concealed in a (fake or operational) PIR motion sensor. I guess a camera with IR LEDs would technically be considered "active infrared".

Try the Diskspace Calculator here, it should give you a rough idea. Generally I'd say go for the most drive space you can afford - you can never have too much.