Soundy

Well put

But that's the point: pretty much everything required to make an ATX supply work for this purpose is a work-around. Most of them are fairly minor and the idea will work without them (like adding a fused breakout board). Without a reliable way to trigger a restart after a power loss, though, it's pretty limited for the purpose.

Thanks, Carl. Well, it IS a bunch of Spectra IIIs that Sean has, so I'd say it's a likely scenario, that they were upgraded to IVs by simply swapping the new cameras into the existing enclosures...

I think most analog "box" cameras I've seen have a ground screw, but I've never used it... few dome cameras do, of those I've used, other than the Panasonic SuperDynamic models, but I've never used those either. Quite simply, don't worry about it. My understanding is that it's included for the sake of obtaining UL certification, but really isn't needed in most cases.

^This. In addition to all the rest, you also need to rig a momentary switch to trigger the power-on circuit... fine for experimentation, but a lot of screwing around for a production environment. One other MAJOR issue nobody's mentioned yet: unless you're using an old AT power supply, is that if you lose AC power, the thing won't fire back up by itself when the power comes back on. Really not desirable behavior for a security system. But there's nothing wrong with using one as a bench supply...

I've found it iffy on anything but Seagate drives... as manufacturers' diagnostic tools go, I've found Western Digital Data Lifeguard works really well for Windows-based utilities... good old Maxtor PowerMax for DOS-based.

Seatools doesn't do realtime monitoring on multiple drives.

How would I find this mysterious feature is enabled? I don't see any obvious place to look. That's the main thing that pisses me off with GV - different config options are scattered all over the place.

There is that... plus, it makes it easy to upgrade if you build multiple cameras with the same connectors. Look at survtech's pictures, for example: the Spectra II, III and IV all use the same connector, meaning the backboxes are probably interchangeable. You're probably seeing all these older cameras without the backboxes because someone is just pulling the old Spectra II cameras out and snapping new Spectra IVs in.

"VA" is the proper mathematical statement for "volts times amps". Similar to watts (P=V*I). There's some good discussion of VA vs. Watts here: http://forums.pcper.com/showthread.php?t=423853

They're probably using the cheapest resistors, rated at +/-20% tolerance, so it's possible that set of LEDs is getting up to 20% higher current than the others... combine that with the fact the LEDs probably aren't rated for very much current, and that would certainly shorten their lifespan, especially if the design runs them near their limit already.

Things will vary a bit depending on the specific DVR manufacturer and how they do things, but in general, your biggest choke-point for high FPS will be disk I/O, followed by CPU speed. Most DVR software I've seen actually recommends disabling hyperthreading. I don't know of any that will actually take advantage of multiple cores, either. GPU should have NO bearing on performance - it's really only a factor when doing 3D graphics, something that's not needed for DVRs. This is mostly just a concern because some cards (or their drivers) don't get along well with some chipsets. As long as the DVR package lists the chipset on their "supported" list, one should be as good as the next. RAM speed will make negligible difference. Amount should have no effect on FPS, as long as you have enough for proper operation of the OS and DVR. The main place you'll see a difference with more RAM is if your system maintains a search database, and you should be fine as long as there's enough RAM for it to load the entire database. Anything over 3.5GB will require a 64-bit OS to take advantage of anyway, at which point you have to be sure your DVR package supports 64-bit operation. RAID0 will help disk I/O if you find yourself maxing it out, but will cause its own hit on system performance if done in software - use a motherboard or add-on card for hardware RAID if possible. Of course, all the performance in the world won't do you any good if you lose one of the drives, and thus the entire array with it... If you want stupidly fast I/O, look into 10,000 rpm drives. SSD is still inordinately expensive for the space you get, and there's a lot of debate over its long-term reliability for repeated continuous read/write operation.

How much does the Bosch list for? It's really not a complicated design - buncha IR LEDs wired series/parallel with appropriate current-limiting resistors is little more than a basic electronics project; adding a photosensor to turn it on and off based on ambient light level adds a fraction to the complexity. Quality of construction and assembly is really (theoretically) the only thing you're paying for with the name-brand versions.

Radio Shack should have all your DB9 connectors - male and female - as well. We've been using fairly generic A-TEN USB-to-Serial adapters for both POS integration and PTZ output, and haven't had a single problem with them yet.

I ran a series of test a while back, a near-full box of Cat5e (probably about 750', still coiled in the box) and a range of passive baluns from cheap ($13/pr.) to high-end ($45 ea.) and several models in between, including NVT, MuxLab, GVI and GEM (basically, all the brands carried by ADI/Burtek), connecting a CNB camera to my Vigil bench DVR... and there was practically no visible difference between any of them.

Do away with the adapters and just wire them directly - pins 3 and 5 on the POS to pins 2 and 5 (respectively) on the DVR. The "sniffer" hookup from that link (with the diode and resistor) is probably a good idea rather than just parallel-splicing the wires.

Send me one and I'll figure it out Actually, me have have a couple sitting around the shop, I'll see if I can tell from that.

The cat is already out of that bag - the topic of connecting POS setups has been discussed in detail here many times. It should be pretty straightforward, no trade secrets here - on a DB9 connector, pin 2 receives data, pin 3 transmits, pin 5 is ground. If the POS has a DB9, you want to use pins 3 and 5. If you're capturing to a serial port on the DVR, use ports 2 and 5 - 3 to 2, 5 to 5. After that, match up your comm settings - baud rate, data bits, parity and stop bits, and flow control options (I find disabling flow control usually works best, since pole displays don't generally us it) - should do the trick. You can test the output by firing up HyperTerm or a similar app (like PuTTY) on your computer, pointing it at the port you're connected to, and setting it "online" - you should see text coming into the terminal. That will confirm that the POS is sending properly. Just one thing though... I'm not sure a Y-splitter is the most reliable method. If the terminals don't have a second set of outputs, you might look at something electronic to properly split the output... or use a text inserter that has parallel outputs so you can run from the POS, to the inserter/DVR, then back to the pole display. Might be a stupid question, but... if you're running into the DVR, you ARE running into four separate serial ports, yes?

^What Rory said - a lot of PC-based DVRs include an option to reboot the system on a set schedule (on Vigils, the default setting if for 12:00AM every Monday). Since the log is showing a "normal shutdown" event, that means something is intentionally initiating the shutdown/restart sequence in Windows - the same as you clicking Start -> Shutdown -> Reboot -> OK. Question: is this causing problems, or are you just curious as to why it's happening?

Thanks... so far I haven't had the chance to put a lot of time into this, and I still haven't got a reply from RBH themselves regarding software versions and update downloads. Their website doesn't have much in the way of actual support info, and they don't seem to have a direct support contact number or email. WTF? If this continues to be a problem though, I suspect the property management will want to dig into it more deeply. We're also quoting on replacing a number of cameras that were stolen, and hopefully for a new DVR that can actually interface to the access system.

A few cameras, such as the IQ511, have a neat feature on their analog service port: the full screen shows the full view of the camera, while the center 1/3 or so of the frame has a full-zoom image along with a "focus meter". Works quite well, in my experience. But yeah, auto-backfocus is a lot nicer

Looks like a "hot pixel", which would be a defect of the sensor itself. Dust or physical object on the lens or sensor would generally be black or very dark, not bright white. Not much to be done about it, unfortunately, besides returning the camera.

I'm actually not sure if it's hardware or software... First call out, last Friday, the caretaker's key fob wasn't working on just one door. All other fobs worked on that door, and his fob worked on everything else... just not that one door. After muddling my way around the interface (this being the first time I'd ever touched this kind of system) I found my way into his fob's account, checked all the settings, updated it with the proper spelling of his name, and saved the changes... and then his fob worked. Then Monday we got a call that one of the other doors was stuck on green and wouldn't lock. Got on site and found the log full of errors showing various panels going online and offline. Rebooted the back-end system and the errors went away. I went into the Access section and found that the panel was set there as Unlocked... right-click on it and select "Lock" and it was back to normal. Seemed like a software error, but I could find nothing in the logs stating that the panel had actually been sent a command to unlock... just the entry from me re-locking it. There were also no logins shown between mine on Friday and mine when I got there Monday, so it didn't seem to be intentional tampering, either. I thought maybe there was some database corruption going on or something, so I ran a full Memtest and disk diagnostics on the system, and found no problems with the hardware. Then yesterday we got a call again: another door was stuck at green... as it turned out, the same one that wasn't accepting the caretaker's fob the first visit. Same thing: panel set to Unlocked, no sign of it being changed through software, nothing to indicate when it had actually become "stuck". Just thinking about it now, I'm wondering if it might be a hardware issue at the control panels (which are in a different room from the backend PC), something causing the panels to unlock, which the software then just detects as the current status... really wishing they had internet set up in the room there so I could get remote access to monitor the system.

£279 equates to about $444 (US/CDN)... which honestly is the lower end of the retail market for *good* megapixel IP cameras. You can go cheaper, but you're probably going to sacrifice either resolution, quality, or features (like the ability to FTP images on a schedule). Fortunately for your purposes, you can probably give up things like low-light performance, as you're probably interested more on daylight images anyway.