hardwired

This usually indicates that the checksums are being computed in hardware on the Ethernet card. As you noted everything is working fine so it's safe to ignore those errors. You can look for a setting called "TOE" or "TCP offload engine" in the card settings, or BIOS for onboard NIC. If you want to turn this off temporarily for testing, you can. You typically will want it on, though, it reduces processor load by doing some of the work, and the errors shown by Wireshark are just because it's seeing the packets before the TOE engine has worked on them, and fixed them, before going out on the wire.

I did a few grocery stores with 64 camera systems with separate 18/2 and RG59, working with the bundle coming out of the ceiling at the head end was like wrestling with an Anaconda!

Snow is actually a reasonably good insulator. Even ice has a lower thermal conductivity than aluminum, so it would add some insulation value to an aluminum housing.

I'm having a really difficult time not adding something tasteless here......

Depending on what kind of network you have, you might have to be creative. If you want ALL the traffic, you'll need to put an old-fashioned hub in between your target, and the network, then hook your sniffer machine to that hub. Hubs repeat all packets to all ports. Alternatively, you can overflow or poison the ARP cache on a switched network and get the data that way. This is another good reason why to get decent quality managed (or at least "smart" switches) that you can configure a port on to mirror all traffic going through that switch (some switches call it "mirroring", some call it a monitor port, etc) That will allow your Wireshark monitor to see all traffic (at least on that switch). I haven't explored the option, but I would think you would also be able to assign that monitor port to an individual VLAN from each switch, and then send whichever VLAN you want to look at to an central exit port with the Wireshark monitor on it (it would add a lot of traffic to the network, though).

Yes, it seems to be a YMMV sort of situation from cellular carriers in regards to DNS and double NAT issues. I remember getting a public IP a few years ago on a standard 3G USB modem from Verizon, but recent checks one of one of our 3G dongles, and my 4G LTE phone, show both of them getting a 10.x.x.x private IP allocation, which will break the ability for DDNS to work. Just something for people to be aware of if they can't get a cellular connection to work, and probably part of why thewireguys suggested getting a static IP, that way you wil eliminate a number of variables.

Not sure of Sprint, but both Cricket wireless, and Verizion (both 3G and LTE) use double NAT unless you buy a static IP allocation. Basically, rather than having a directly connected public IP, you are on the LAN side of a carrier provided router, with no options for setting port forwarding rules on it, only ports selected by them to allow browsing, while blocking server-side applications (like DVR's and NVR's). The only way I've been able to make a double NAT connection like that work is by using a tunneling client like Hamachi (which works by creating a virtual NIC on your PC, and then translating all traffic into something that looks like browsing traffic to the ISP), but that's only an option with a PC based recorder, and viewing client.

You can use a 12VDC battery into one of these http://www.powerstream.com/inv-12dc-24vac.htm for 24VAC, 40 Watt output. It's a pretty expensive option, though.

Not sure if you are in the US or another area, but in the United States, the electrical code says you can't run an extension cord through a wall like that. You'd need to run Romex cable inside walls, and terminate it in junction boxes.

Check to see if the camera has a setting for flicker reduction, or try changing shutter speeds (if possible on your camera).

Milestone "Go" version is free for 8 cameras, and 5 days archive, but does only allow one concurrent client connection per server. (you could start there to see if it will work, and to test it's features). Their "Essential" version allows for five concurrent client connections, and is $100 USD list for base with two channels, and $50 per channel after that. Licensing is for the server PC, clients are free.

You should be able to fit that Acti 3701 inside the ATM, if you leave the dome off and trim the edges off of the camera body (it has a lot of area that's just a flange, with no parts there). It is tough to beat the analog DeView Pixim camera, though, I use a lot of them in elevators.

Not necessarily, it's more important in those cases to get a proper sightline with a low mounted camera (doorjamb, built into teller nameplate at counter, etc.). With these, as long as you are getting enough pixels on the target area, it doesn't matter if the camera is IP or analog (although megpixel cameras can allow a larger field of view and still get the same pixel density at the target area). Don't get me wrong, I use megapixel cameras almost exclusively, but that doesn't mean analog cameras are not an acceptable option, if used correctly.

Nice!! What nic card are you using? And, what server are you using that's able to handle 1.1Gbps of traffic, at 12% CPU?Tech porn, again!

According to the manufacturers, you are always supposed to daisy-chain (going from the TXD +/- terminals on the keyboard or DVR to the RXD+/- terminals on each Esprit, and then on to the next one, turning on the termination on the last one in the chain. The Esprit's do have a termination switch in them. In practice, star configurations, and other odd connection layouts will usually still work. If you have very long runs to each camera, you may want to use a RS422 distribution amp, something like the Pelco CM9760-CDU-T. (Although I'd try your system out without it first, if you need it, you can always add it later).

(1) either type of cable will work at that distance, but more people are moving towards single-mode, due to it's higher capacity for expansion later (higher data rates)-although multimode is more forgiving when terminating, and multimode equipment is slightly cheaper. (2) GBIC's are fine, no need for another piece of equipment in the rack. (3) Always! there's just too much of a chance of damaging your trunk cable, requiring a new cable pull, rather than just replacing a patch jumper when someone breaks it.

When you're talking four cameras, provided to you by your employer, and given to you before heading to site, well... you hope that they all work when you unpack them. Realistically, bench-testing 200 cameras for 24 hours each before deployment isn't really viable unless you're a large integrator with your own dedicated QA shop... and even then, I don't think it's reasonable for an integrator to have to be constantly on the lookout for a manufacturer's shortcomings. One SHOULD be able to expect the vast majority of equipment to work as delivered. 2-3% failure rate, sure... 50%?? NOT acceptable. I'm not sure it is even a good use of time to bench test ALL incoming gear, the time spent at that might exceed the time replacing a FEW defective cameras...The operative word there being a few, if you really have that much defective product coming in, you might want to rethink what product you're using. I tend to bench test product when it is either an exceptionally strange product mix, or the customer site is a significant distance away, and especially if I will not have remote access to the system later (prisons definitely fall in to this category). I will say that when I did a recent install almost three hours away, I pre-programmed and bench tested everything (NVR, wireless gear, switches, and cameras) fully configured as it would be on site. And, to tie this back into the original posting, I did this install with Avigilon products.... I would have been afraid to put Arecont product there.

I had an Arecont AV5105DN turn itself into a 3105(according to it's web interface, and the AV100 S/W). It happened when I put it in place of a defective existing 3105, and connected to it with Milestone Enterprise, it changed itself into a 3105 (no working images from the camera, just a scrambled mess). Arecont claimed that wasn't possible, either....

I agree... Tell that to Arecont, though. Their cameras (older ones I tested, anyway) only negotiated port connections at 100Mbps.

There should be no compatibility issues with ethernet-over-coax adapters like the HighWires - plug the camera's network port (ir switch, or whatever) into one end, coax into the other. The device handles the media translation; the camera/switch/etc. doesn't know the difference. I think he might have been referring to my comment that those inexpensive adapters only sync at 10Mb, and therefore don't work with all cameras.

I've used quite a bit of VDSL converters from Planet, http://planet.com.tw/en/product/product_list.php?mt=menu_product_3&id2=1257

DOCSIS gear is still fairly high-end, but there are a fair amount of products out there using MoCA protocol, like this one from Actiontec, http://www.actiontec.com/products/product.php?pid=192. That product is designed for CATV coax cable, but I don't think there would be a problem using CCTV coax, other than needing some F-to-BNC adapters. The adapters you listed will only work at 10Mb link speed, not all cameras will work that way (Acti will work, Arecont will not, for example). I've used those ones (they are sold under many different labels), as well as the higher end models they list, which will work with most cameras.

I"m still not sure why you need cameras to be operating at that temperature anyway. I guess I find it a little incomprehensible that anyone outside in those conditions would be in any shape to do anything criminal, other than litter your yard with their frozen corpse... But, I suppose you guys might find it difficult to work here too, as it reaches +44C/110F in the summers....But it's a nice, dry heat...kind of like a pottery kiln! On a more serious note, is there any CAT5/6 cable that's rated to be pulled into place during exposure to those kind of temperatures? I may be doing an install in an ice cream warehouse that's held at -15F or so.

You can also create your own iSCSI storage with FreeNAS, and some adequate PC hardware, as well. Avigilon (and Exacq, and some others) need direct block-level drive access (direct attached or iSCSI), versus file-level storage (what most standard NAS devices provide), because they need high speed, direct drive access to directly archive to. Some other VMS's (Milestone/ONSSI, for example) do their archiving differently, in multiple stages, allowing a small "first day" direct attached drive, and then archiving to a secondary location at a lower speed.

Your going to get all the Avigilon haters stirred up. I'm certainly not married to any one product or brand; I use what I think is best for a particular situation, and I'll pass along my opinion for other people, as well (you know what opinions are like, right? ) I've got my own particular perspective of product selection based on over fifteen years of experience in this business, but I'm not bold enough to make the statement that my word is gospel for every situation. For example, we specialize in large industrial, healthcare, and food processing/Agricultural, because that is a target market for my area. We don't do (with rare exceptions) residential, mini-markets, etc., and don't plan to. It simply doesn't fit who we are as a company, and we don't expect to be able to provide what these markets are usually looking for (often, lowest price, with light consideration for product quality, or aftersales support). I know that there are products (and installation companies) out there that are are a fine fit for those markets, a reasonable mix of quality and pricing, and I'm not out to bash them, they simply don't fit for our target customers. Does that make them bad? No, like anything else, you simply have to choose the proper products, and support them well, to maintain your customers, and grow. Avigilon, Milestone, Panasonic, and other products like them, fit OUR target market, so that's why I choose them. It doesn't mean they are the best choice for everyone.