Soundy

Dear ini, Here I compare NUUO Nvrmini with VS-5012. 1. NUUO supports about 400 cameras 2. NUUO supports compression formats: h.264, mjpeg, mpeg4, mxpeg(mobotix) 3. NUUO supports upnp. 4. NUUO supports autodetection for cameras. 5. NUUO offers GUI to change recording schedules 6. NUUO supports video backup 7. NUUO supports video export into AVI or ASF 8. Video supports video enhancement. 9. NUUO suppots PTZ-presets. 10. NUUO supports automatic data backup 11. NUUO nvrmini has reports of system info, hdd usage, disk status 12. Support for NUUO CMS 13. Support for POS For more information, please go to http://support.nuuo.com/mediawiki/index.php/Nvrmini NUUO Tech Support Hmm. http://dictionary.reference.com/browse/compare The above isn't comparing anything... it's just spam.

because no dynamic-DNS service, free or not, is 100%effective. i've had ISPs that force IP changes every 1-2 hours... when DDNS updates can take up to an hour to propagate, DDNS becomes nearly useless.

It's possible the program isn't sending the right control codes... I've had similar strange issues using Pelco P and D via Vigil software. Some cameras seem to expect different control codes to kick them into their setting menus, and the problem with such "generic" protocols is that different software and cameras handle anything outside the most basic controls differently. On one site, for example, I have two Capture PTZs (both Fastrack II, but one a much older revision) and two Pelco PTZs (one a Spectra III dome, the other an Esprit). One Capture doesn't like computer serial control AT ALL, the other all functions work great . The Esprit also works fine with all tour/preset/menu commands through the software... but with the Spectra, the menu buttons just open up the iris (which is odd, because I've seen lots of other sites using Spectra IIIs successfully with Vigil).

More commonly known as "Siamese cable" - it can be convenient to have both in one, but it can also be a hassle, as it doesn't wrap as easily as separate cables (ie. if you have to create a service loop or coil it up for later payout), and doesn't slide as easily through tight spaces or around tight corners when you're pulling it.

Not so - the only thing that would change is your "outside" IP. If you're using dyndns.org, that shouldn't be an issue, as the name will update to reflect the change. The DVR's IP would (and should) stay the same, since it's getting that address from the router on the internal network. That doesn't seem right... the DNS entry should have either the router's internal IP (192.168.1.1) or an outside DNS server. Is there not another entry for an IP address for the unit? When you're on Static, it should have spaces for you to enter an IP, a Netmask, and a Gateway address. None of that should have any effect on this issue. That should all be correct, as long as the DVR's IP is right... I still think something is wrong there, though. Also, you only need to forward TCP; UDP isn't required for this. Is Video Server E also using port 80? If it uses other ports, they'll need to be forwarded as well. DHCP stands for Dynamic Host Configuration Protocol. In short, it allows the server (your router, in this case) to automatically tell the clients (your PCs and DVR) the proper network settings to communicate on that network: an IP, the netmask and gateway settings, the DNS server address(es), and so on. Since each device must have a unique IP address, it gives each of them an address from its "pool" - usually something in the range of 192.168.1.100 to .150 or so. If you're setting the router's IP to "static", you need to enter the IP, netmask, gateway and DNS info manually... since the DHCP Client Table lists what addresses the router has given out to connected devices, and the DVR is not getting that information from the router's DHCP server now, the Table won't have a listing for the DVR. Now all that aside, assuming everything else is set up correctly (I still think there's something missing in that network config), if it still doesn't work, it's possible that your ISP is blocking port 80 (many of them do). In that case, you could try using a different port, such as 81, 88, 8000, 8080, or any other port that's not in use by something else. You'll need to change it in the router as well as the DVR; then when trying to access that from an outside web browser, add the port number to the end of the URL like so: http://aliciac.dyndns.org:8080 (assuming you used 8080). Note that, especially with Internet Explorer, the "http://" is *required*, or it will get confused (other, more intelligent browsers, will assume http by default).

"Best" for what? What sort of features is he looking for? What form factor? Standalone or PC-based? Does he want/need IP camera support? POS integration? Access controls? Redundancy? Multi-site support? What are the storage/retention requirements? From my own experience, Camacc/3xLogic have a great system in their Vigil DVRs. I've installed systems that will do up to 30fps on each of 32 analog channels (960fps total) as well as supporting a wide range of IP cameras and network storage. They have advanced POS integration and great technical support and have even created customized code for one of our clients to support their Squirrel POS systems. Their new versions now have built-in analytics as well. Compared to other similar systems I've seen, they're also quite reasonably priced for what they give you.

I've worked with a professional stock-car team - believe me, anything that will add weight or rob power is NOT desirable in a pro car. A PoE switch would be a big waste of power: you'd have to step the power up to 120VAC through an inverter, which is a horribly inefficient device to begin with, just so the switch can knock it back down to 48VDC. The only way to improve that would be to have a switch or injector that can take 12VDC in and bump it up to the required 48VDC, which would still require some form of inefficient voltage inverter. Now, if the OP is just a racing hobbyist or racing in an amateur division, it might not be as much of a concern...

shoreview is on the right track - the movement of the "snow" in low light is probably what's triggering your motion. I've also seen it where a B&W camera (such as a day/night camera in night mode) triggers motion because the shifting color artifacts are seen as moving objects by the DVR - the fix there is to reduce the saturation on that channel.

Yeah, DC resistance of that wire should be AT MOST a couple ohms over a hundred feed... that's your problem, something is introducing a LOT of resistance in that wire (probably poor manufacturing), which is causing excess voltage AND signal drop.

That's what it really comes down to - basic motion detection 99.9% of the time is too unreliable for an alarm system, usually because false positives are way too common. A bush or tree moving in the wind can trip it, or an animal, the glare of passing headlights... lines of electrical noise... even the shifting of color artifacts when a day/night camera goes to B&W mode can cause constant tripping of the motion detection.

Plz don't type as one line post I hate scrolling Not his fault... the board will normally size the display to your browser and wrap the text automatically, but in this thread, the extra-wide pictures are forcing the display to a wider size. test 111111111111111111111111111111111111111111111111111111111111 222222222222222222222222222222222222222222222222222222222222 333333333333333333333333333333333333333333333333333333333333 444444444444444444444444444444444444444444444444444444444444 u see my point Yeah, you hit ENTER after each line of numbers. Unless you're breaking something up into paragraphs, most people don't do that as a matter of course, especially when the text-entry box is a lot narrower and does display with wrapping. If you keep typing a sentence though, it will naturally go to the display width of the page, which on a page with big pictures, will be wider than normal. And you get long sentences with no linefeeds that force you to scroll...........................................................................................................................................................................................................................................!

Not necessarily - it depends on your internet provider. Since DVRs typically run 24/7, they don't randomly connect to the 'net and don't usually change their IPs on a frequent basis, unless the ISP forces a change (like some DSL providers I've dealt with). The best solution is to ask your ISP for a static IP. Most broadband providers will accommodate it for a small extra fee ($10/mo isn't uncommon). Some provide it automatically if you have a business internet account.

Should probably be discussed in the Vendors' forum, but it seems impossible to get access to that anymore... I first asked I think close to two years ago, never even got so much as a "no" reply.

Plz don't type as one line post I hate scrolling Not his fault... the board will normally size the display to your browser and wrap the text automatically, but in this thread, the extra-wide pictures are forcing the display to a wider size.

Kinda depends on exactly what "these" are... I've (re)built a number of Vigil DVRs using HiCap and XECAP (ComArt-based) capture cards on a wide range of boards using Intel, SiS, and VIA chipsets, mostly using Windows 2000 and XP Pro, but I did experiment with Windows 7 as well. Vigil run without a hiccup on all of them.

What sort of DVR is this? If it's PC-based, you can probably just go into the data drives and back up the necessary files...

I fully respect the quality and reliability level of a system like this. thewireguys touched on the constant light levels and since the thermal cameras don't use light you're both saying the same thing. I guess if an installer put in artificial light and wrote more than one alogarithm for the software detection of the camera it might work in a simliar way as a thermal system. But nowhere near as well. Thanks a lot for all your help. CK Actually, the main factor in our system's reliability is the video analytics. Standard motion detection just looks for short-term (within a couple seconds) changes in the image - shadows moving with the sun and lighting changes from day to night won't trigger it, it's just sampling and comparing pixels for variations within a span of maybe 10-100ms. What the analytics does, is look for SPECIFIC movements. For example, "tripwire" is a common, very basic detection type for most kinds of analytics: watch for an object crossing a line that the user defines. This is often refined by watching for movement in a specific direction, or crossing one line and then another. The system can also be programmed to recognize types of objects based on their size - say, to differentiate between a person, a car, or an animal. You can then combine these to, for example, trigger an alarm if a person or car crosses a fenceline, but not if an animal does it. Or you could have to trigger if a car enters a fenced area, but not if it's leaving the area, and not if a person enters or exits. A lot of that ability has to be defined by the user: for example, you'll draw boxes on an image to show the system what size a person is, what size a car is, etc. Doing this at the "front" and "back" of the scene will let it know the perspective it's dealing with, so it can interpolate the sizes of those objects at points in between. It can take a good deal of time to fully set up the system for a detailed level of "intelligence".

Good in some instances... depends on how many cameras you have and how much stuff you want to save. Drives are cheap on their own, but once you get into needing five or six 1.5TB drives, you have to start factoring in the cost of enclosures and/or controllers for them as well. Some can also record at a slow speed on a constant basis, then kick to higher framerate, resolution and quality settings when motion is detected. We do have software-triggered monitored alarms on one site... the alarms are triggered by video analytics software (much more advanced that just basic motion detection), and the cameras are FLIR thermal cameras, which are unaffected by varying light levels. Of course, that's not a CHEAP option - I think the FLIR/VA system alone ran around $80k for the hardware... installation to a 50' tower in the middle of a two-square-block storage yard not included.

Just as a side note, this is why megapixel cameras aren't generally as good at low-light as analog, too... and the same reason pocket snapshot cameras have lousy low-light performance compared to digital SLRs and other large-sensor cameras. Think of the sensor as a field of buckets, and the light photons as raindrops. The bigger the buckets, the more rain you'll collect in a given period of time (say, 1/60 of a second), and every raindrop gives you more data about the water you're collecting. If you want to increase the number of buckets (pixels) in a given size of field (sensor), you have to make the buckets smaller and smaller... so they can't collect as many raindrops (photons) and thus won't provide data as accurate as you get with the bigger buckets. The only way to improve the ability to collect while maintaining the resolution is to increase the size of the field to allow for larger buckets... or in our case, using larger sensors. Beyond that, you either need to devise a better way to process the minimal data you ARE getting, or you need to come with a more efficient bucket.

Ahhh, got it. Okay, consider me enlightened. Thanks Back to the original problem then, he's not likely to be able to get around using conduit to run the wiring - not because of Pelco's specs, but because in most of the civilized world, electrical code would require it

Baluns don't REQUIRE twisted pair - I've run video baluns over station wire (four un-twisted 22ga conductors), I've run them over Cat3, even over 18/2 speaker wire. That's just FYI... I can't think of any possible causes or solutions right off the top of my head. Sounds like you've done pretty much all the necessary troubleshooting steps. The only question I might have is whether you tested the voltage AT the camera with it powered up, to make sure it's not dropping too much, but you've tried powering the cameras locally as well, so... Only other thing that comes to mind is that it IS a bad batch of cable with overly high resistance - not enough that the cable tester fails, but enough that the voltage and signal are dropping below usable levels. What sort of Cat5 tester do you have? Will it give you things like capacitance and resistance/impedance readings, or is it just a continuity tester? I would assume either way, it's showing all the pairs are wired correctly? That's the only other thing I can think of, if the pairs are mis-matched...

Uh... is there not a version of the Arecont software that will run on Win2K? I went to add an AV5100 to a Win2K-based Vigil today and the software install says it only supports XP or W2K3 Server. Now how stupid is that??

Thanks... so the bead isn't required for "proper" operation, just to fit the rules. Good to know ...Assuming the cam does not generate enough interference to lock up a switch, etc..... Not likely, but a possibility, nonetheless. My point was that the beads were just another sign of a design that wasn't fully thought through. Yeah, I'm noticing a lot of that with these cameras.

Why would you not just run the control cable separate from the AC??

Hmm, without looking at the manual, just a couple thoughts: I doubt that the control wiring is 115V; though it may be powered with standard line AC, control is usually via low-voltage RS-232/422/485 (+5 or +12VDC). Either way, use of conduit for the AC is likely required by electrical code, and if so, there's no way around it, unless your local code also allows BX. Even if the platform does use 115VAC for its control signals, it would still have to conform to your local code.