MaxIcon

40 Mbps So, pnyxxpress, at 40 Mbps total, you can run 8 cams at 4096 kbps, 6 cams at 6144 kbps, 4 cams at 8192 kbps, and so on. Just keep the (# of cams) * (bit rate) below 40Mbps, and you should be good. Likewise, running some at higher bit rates and some at lower is fine, as long as the total is below 40 Mbps. I'd keep a few Mbps free as a buffer. In general, 4096 kbps will suppor 3MP at 15 fps with no problems. I never run higher than that, so if you want higher frame rates, you'll have to test and see.

There's currently no way to do this in software, though Hik said they planned to incorporate it in the 5.1 firmware release before the end of the year, according to another post. Some cams will let you unplug the IR board with no problems (like the Dahua 2100 and 3300), while others use the light sensor for day/night switching (like the Vivotek IP8332) and lose functionality if you unplug the board. I haven't tested this on the Hik, though, and it is a pain to take them apart.

I'm saying I don't use the multi-cam timeline feature on the Aver software very often. Generally, when I'm looking at the Aver recordings, it's because something happened that I partially missed on the motion detect system. I know what cam's got the area of interest, and the motion detect indicators on the Aver timeline let me get to it quickly. In these cases, I'm looking at a specific time window and a specific cam. I don't have a lot of need to review multiple cams at the same time, but when I do, it's a very handy feature. If it showed motion detect indicators for all the cams' timelines on the multi-cam view at once, I'd probably use it more. I don't know if the other multi-cam view systems do this or not. I'm also a rev or two behind on the Aver software, so don't know if they've added anything like that.

Actually, even when I'm viewing these on the Aver software, which does use multi-cam sync views, I mostly use single cam views, since you get the motion detect indicators on the 24x7 timeline, and don't get those on the multi-cam views.

And the Wrightwood firmware version appears to be 130618, right? They don't list the version number in the post, but that's the date on the digicap file.

Interesting - I just checked my cams from the N-place, and the firmware is V5.0.0 130412. I'm curious about what's different between the identical version numbers with different date codes. The model number is NC-KBU32 - presumably these are Derytech? Nothing on the packaging or in the firmware mentions this brand. They don't have any logo, as they're still on the firmware they shipped with.

You don't need this calculator for the dahua - this kind of thing was used for analog cams - but you can calculate an average frame size if you'd like. Your bandwidth is set by the bit rate setting on the camera. If it's set for 4096 kb/s, that's your bit rate and your bandwidth, and you can calculate the storage requirements based on this as well. For instance, the storage size required per minute is: ((bit rate in kb per second)/8)*60 = MB/minute To calculate an average frame size, record for a certain time (say 60 seconds). Multiply the frame rate times the seconds recorded, and that will give you the total frames. Divide the file size by the total frames, and that gives you the kB or MB per frame. Be aware of the differences between bits (small b) and bytes (capital B).

zikronix, thanks for all your testing! Nothing like repeatable checks to verify the issues. I was starting to get worried, as the reason I bought these rebranded Hiks was to have easy access to firmware from an official source, but it sounds like it's good to go with 5.0.0 or later. Do we know which version causes the password reset problem? The Swann I tested upgraded to the Hik 5.0.0 firmware without any issues. I'll have to look back in my notes to see what it had before the upgrade.

What's the bandwidth limit on the NVR? That's what you need to know to set the limit for the cams.

Yeah, as 1080p and 3MP cams have gotten suddenly affordable, I'm finding my system load goes up steadily. I originally used the Aver as a hybrid card (starting with an NV5000. limited to 4 IP cams), but having retired all my analog cams, it's really just acting as a dongle to enable the software to record on all the channels. This gives me 2 completely separate redundant systems, with BI recording motion detect and the Aver recording 24x7. My NV6480 doesn't have any analog cams attached, and doesn't do any processing of the IP video, as far as I can tell. It lets me record 16 IP cams on a relatively low power PC, and the Aver software, while a bit old school, is robust and reliable, doesn't require per-cam licensing, and supports a wide range of cameras. I was using all 16 channels for a while - 8 cams with motion detect, and the same 8 recording 24x7 - and it never skipped a beat. The main CPU load is how many cams you view at once, not how many it's recording.

Hik has released a new version of the Raptor firmware, 5.0.2, build 130805. I saw it on the European portal, and couldn't connect to the US FTP site to check there. http://www.hikvisioneurope.com/portal/index.php?dir=Product%20Firmware/DVR%20NVR/Cameras/Raptor%20Platform%20IPC%202%20series%20firmware/ Hikvision Baseline Firmware_IPC_Raptor series_En_V5.0.2 130805 The readme doesn't have a lot of info, but here it is: Release Note Network Camera Basic information Firmware: V5.0.2 build130805 Supported models: DS-2CD2012-I;DS-2CD2032-I;DS-2CD2112-I;DS-2CD2132-I;DS-2CD2212-I3/I5;DS-2CD2232-I3/I5;DS-2CD2312-I;DS-2CD2332-I;DS-2CD2612F-I(S);DS-2CD2632F-I(S);DS-2CD2712F-I(S);DS-2CD2732F-I(S) Function 1. Solve the problem of obtaining sub-stream abnormally when accessed to NVR;

The system really depends on your NVR, so some testing may be in order. I have experience with Blue Iris and the Aver NVR for their hybrid cards; I ran Xprotect Go briefly, but didn't like the limitations and troublesome setup. Blue Iris needs a fair bit of horsepower for MP cams, and there are a lot of variables that affect CPU requirements. There are a lot of PC performance threads over at their community forum, cam-it.org. The Aver system runs a lot lower power, and an NV-6480 board runs fine on my low power i3-540, recording 20MP at 10 fps without breathing hard. These cards are expensive if you buy them new, though. With Blue Iris, my i5-3570k box runs 14MP at 10 fps with no problem, and some room for more. My older i3-540 box tops out at about 8MP at the same settings. Here's a thread with some detail on this: http://www.cam-it.org/index.php?topic=4583.msg23966 Passmark benchmarks: i3-540 - 2669 i5-3570k - 7119 FX-6100 - 5417 Now, benchmarks need to be taken with a grain of salt, but as a general guideline, you may be able to run 12MP of cams at 10 fps, but you may be hitting the limit. Best bet is to download the demo version of BI and see how it does. In terms of general differences between Intel and AMD, the main thing is power usage. A CPU uses more power as the CPU utilization increases, so a less powerful CPU with a lower TDP that runs at 90% may use more power than a more powerful, higher TDP CPU that runs at 30%. The i5-3570k chip has a TDP of 77W, and my box runs about 90W or so typically, using the on-CPU video (a video card will add a good bit to that), and running around 60% CPU. The FX-6100 has a TDP of 95W, and how much the system power will be will depend on things like hard drives, motherboard chips, and how much CPU % it runs. Where I live, power is expensive, and the $100 price difference between an i5-3570k and an FX-6100 would be covered in probably 6-12 months of running the i5, with it's lower power draw. Add to that the ability to add more cams (or even better, go for the 4th gen i5 CPU for a few dollars more and even more overhead), and the Intel chips really pay off in the long run, in my opinion.

Ah! Another challenge! No shortage of those...

On most IP cams, one of the settings is for bit rate, which is usually in multiples of 1024 kb/second, though some let you set any random number. You can often set fixed or variable bit rate as well. It's important to note the difference between kb/s (bits) and kB/s (bytes); networks use bits, and you'd divide bits by 8 to get bytes, which hard drives use! For fixed bit rate, the cam will send out data at whatever you've set, regardless of the content. If you have 4 cameras set for 4096 kb/s, your network traffic from the cams will be 16,384 kb/s, or 16Mb/s. As long as the NVR and network will handle that, you're good. If you added 4 more cameras, that would take you to nearly 33Mb/s, and if your NVR only handled 30MB/s, you'd have to reduce the bit rate on one or more of the cams to keep it below that limit. As you change the resolution and frame rate, this will often change the limits you can select for bit rate. At a low resolution like D1, you may not be able to choose more than 2048 kb/s, while 3MP may go as high as 8192 or 16384 kb/s. The relation between bit rate, resolution, frame rate, and video quality is complex, and depends a lot on how the programmers have implemented the h.264 encoding. Generally, though, 4096 gives good quality for 2MP and 3MP cams, though high frame rates might benefit from higher bit rates. 2048 is usually fine for lower frame rates, like 10 fps. This also directly affects how much video you can record on a hard drive. So, 4096 kb/s (bits) is 512kB/s (bytes). Multiply that times 60 for 30,720 kB/minute, or about 31 MB/minute. Multiply again by 60 to get 1.8 GB/hour, and by 24 to get 44 GB/day, recording 24x7. Variable bit rate can reduce or increase the network traffic, depending on how it's implemented by the software people. Some cams (I believe the Hiks do this) cap the bit rate and won't let it go above that, but will let it drop below if there's little motion or detail. Others will increase bit rate for more motion or high detail.

There were 2 basic conclusions from the data in the paper: - Different sensors have different sensitivities (but we knew that already). - The sensitivity to 940 nm is about 1/2 to 1/3 that of 850 nm. What this means: whatever camera you have, you'll lose half to 2/3 of the sensitivity going from 850 nm to 940 nm at the same radiated IR power. The rule of thumb is half the sensitivity. Now you're back to the problem of knowing what the radiated IR power is for both illuminators so you can compare apples to apples. If the demand grows enough for 940 nm, we'll see improvements in sensor IR sensitivity, more efficient 940 nm LEDs at lower cost, or both.

This appears to be the 3200S with a new sensor and more efficient IR LEDs. I haven't seen it anywhere.

3mp and 15 fps can't be that much more then 2mp and 30 fps. The bandwidth is determined by the bit rate setting on the cams. The resolution and frame rate don't affect it directly, but can affect the image quality at a given bit rate.

Not all in one go. Lorex refused to give me a ftp or telnet password, when I went to a higher tech support level. I got an email from the tech support in Spain, who told me they didn't have them. On the Hik cams, the telnet and FTP logins are the same as the admin login, if I recall correctly. I don't know about on the NVR.

How well would that box hold up to a crowbar or a large screwdriver?

Back in the day, people had trouble with green drives and lower RPM drives not being able to keep up with an assortment of cams. This seems to be mostly gone now, as many NVRs are coming with green/slower RPM drives installed from the factory. It may be better performing disk subsystems, or better interfaces on the HD in general, but this doesn't appear to be the issue it was some years ago. It might be worth going with a slower green drive to help keep the case temps down and contribute to overall reliability.

Well, that's an odd duck! Here's a pretty comprehensive list of standard mounts and sizes; yours looks to be about 56mm, which matches a few mounts, but it doesn't make any sense to use those mounts on IP cams. http://en.wikipedia.org/wiki/Lens_mount

Most cams that offer both 1080p and 3MP give the same pixels per foot (or whatever), but show more pixels for a wider FOV at the higher resolution. The Hiks have a smaller horizontal FOV and a larger vertical FOV at 3MP than at 1080p, for the equivalent of a zoomed in image with the same lens. One image or the other is interpolated, rather than a pixel to pixel image, but it's not clear which. This gives more pixels per foot, but a smaller FOV, at 3MP. I'm not aware of any other cams that handle these two resolutions in this fashion.

Theoretically, yes, the lens mount assembly shifting seems most likely, since focus is all about lens to sensor spacing, and even a small amount of shift will cause focus change. There's really not much else, unless the sensor itself is shifting position, which seems unlikely, but these cams keep surprising me. I haven't found the problem to be repeatable enough to test, but it's a hot weekend, so I'll try setting up my Dahua in the sun to see what it does. I haven't seen this problem on my Hiks, which only get the morning sun.

Most compact cameras don't have alarm inputs these days, though larger ones are more likely to have them. I've been unable to find an alarm input board or USB device for this kind of thing, but I haven't searched very hard. If your NVR software takes software inputs or commands, you can use a variety of things, like Raspberry Pi, X10, or Sealevel to monitor motion detectors, then send commands to the software. Blue Iris lets you do this, but I've never tried it personally.

Most of my cams run at around 100-115 degrees case temp when the ambient temp is in the 70-80 degree range. Some internal components will definitely be hotter, as Swann Tech points out, and small cams build up more internal heat than larger cams. Since a focus shift would be caused by the lens moving relative to the sensor, and the actual lens mount above the sensor is plastic, this is what would be likely to shift. The Hik lens doesn't have a setscrew (setscrews are worst case for stability) or lock ring, but is held in place by a drop of glue, so the lens relative to the lens mount doesn't seem a likely candidate for shifting.