woodyads

We use the Avenir HZDG 12240P lens, its a 12~240mm lens we typically look at trucks 500 to 2000 meters away.

Some really great points there in your post! I think the quote above encapsulates a big reason why a lot of old-school CCTV guys are so against IP (read: are afraid of it): because they simply don't understand it, and we tend to fear what we don't understand. Just to explain a little more on this. With the advent of voice on IP I thought the skill set of the IT average person in larger organisations would expand into the Comms area. However IT in many large companies has gone backwards. While the knowledge of the architect has moved forward in his skill set, after commissioning the network support gets handed over to individuals who are blinded from why it works and the other devices it talks to. The architect moves on to the next job and the knowledge of how the system runs is lost. So when you say people in CCTV are "afraid of it" I don't blame them, good information about how to setup these network protocols not passed on though the larger companies and you just can't rely on your client's network engineers of smaller companies to know exactly the pitfalls of designing and running this stuff. My team doesn't fall under IT so we are not constrained to the IT kind of budget and outsourcing job division issues that normal IT departments are.

Four years ago I installed (replaced) my first CCTV system. We were running an analogue system over wireless links in an open pit mine. Having a strong background in IT I didn't look past NVR and still wouldn't. I expected it to overthrow the market but I was wrong and I can't see it taking over any time soon. The reason is my IT department still haven't got their head around it and would really struggle to do it properly. Yes we have people that could do it but keeping them is a real problem. So for simplicity I can see most people sticking with DVR and Analogue systems. I see a few people saying IP is just a transmission method, may I correct this. It is also a routing method and a security method. It can also be measured for billing purposes and can be dismantled and reconstructed out of order. It can be unicast, broadcast, multicast, encapsulated, secured, encrypted, trunked, meshed, filtered, grouped and the list goes on. Most importantly it was designed to be war proof. This was done by making the IP protocol and system self routing and not reliant on single core infrastructure. What does all this mean for CCTV. For a start IP is not CC. Closed circuit means your addressing and security is done by Layer 1 of the ISO model, the physical layer. If you want to secure or route analogue you do it with the use of cables, splitters, manual switches multiplexors and de-multiplexors. In IP routing is done at layer 3, the IP address in the packet. And security can be done at several different layers from Layer 3 and upwards, for instance the application layer. So if its not CC what is it? I would describe it as Packet Routed. The big advantage with this is you don't need to change physical infrastructure to control it, everything can be done remotely, over the same interface that the video data travels. The next debate is the NVR vs. DVR. The advantage with NVR is your IP conversion is done at the edge not at a computer, eliminating any special hardware in the computers. This way your servers are standard builds. So what does this mean in real life to the CCTV industry, not much. 100% IP on NVR is costly, hard to understand and setup, requires substantially more knowledge than analogue or DVR. What does this mean to me. Everything! Why? 1: My network was paid for by 2 other systems. Modular, an IP based heavy vehicle fleet management system, and Slope Radars, a Pit wall monitoring system. So I have a sophisticated network system already in place. 2: My back office currently split between site and Perth some 1100km away and about to be moved again to Dallas on the other side of the world. So my servers don't even need to be on site, I don't support them and I don't want to support them. Not possible with DVR only NVR. Not to mention 100% of my cameras are sitting on wireless infrastructure and mobile. 3: My clients (viewers not customers) are in two control rooms 1km apart viewing cameras another 2km away. More clients are spread over several different offices over a 3km radius as well as having access from Perth 1100km away and one internal consultant working in Singapore. I can give access to anyone in the company network anywhere in the world. Once the data leave the pit it is on the company network. So there is no infrastructure installed by me. The synergies I can create by using NVR and IP far outweigh the cost. And I can keep a very small focused team to deploy and maintain it. What I can achieve with NVR and IP is far superior to DVR or straight analogue. Quite simply there are not enough RF channels available to bring back the bandwidth I require from all my systems. If is wasn't on IP, then video would be off the agenda completely. IP and NVR are far superior if you have the skill set and the imagination to deploy it. However the planning and foresight that needs to go into the network tends to be out of the reach IT's imagination and the people needed to invest in the infrastructure in the first place. These installation are probably only reasonable where you have extensive IP infrastructure already in place. These places include mines, heavy industry, manufacturing, airports and banks where IP is used extensively for control and monitoring system.

Yes AC is not AC. there is all kinds of dirt you can get in power and different quality power supplies that can filter out spikes etc. The DC if converted from AC won't be clean power either. (different if run from batteries like in a remote solar location) So the DC power can be made dirtier if run next to an AC cable. The effects of dirty DC power. Computer components. Gates Ramdacs and Memory are effected if they don't get clean DC power. If they can't pick up a clean signal from where the Clock switches from 5v to 0v then they can fail to synchronise filling their bit registers with data split from two different time cycles. The most vulnerable devices tend to be the those with the fastest clock synchronisation, In a computer this tends to be the video card ram. So the video card fails to boot and the whole computer fails. Due to the massive power fluctuations at start-up time in any electronic device dirty power is most likely to effect the device at start-up and the device is more resilient to dirty power once running. You here of old stories of servers that ran for years then when they moved the server room the server failed. The fact is the device that failed was u.s. ager ago but needed the reboot to fail. So if your camera is running then it will probably be ok from the internal processing side. The only other thing the dirty power can effect is analogue signals so if the video looks ok then it is. The only floor in this statement is after time running components loose their resilience to dirty power so one day it might not boot because of power problems and you will blame the camera. The one last thing that AC power can effect is any RS232 or similar data cable. Ethernet etc you can get shielded cat 5 and 6 but finding the patch pannels is painfull. Finally current creates EMF which creates the magnetic field that induces itself on nearby cables. Not voltage. Low voltage can create a strong current its the over all current that matters. For those who are not bored yet keep reading. Here is a scenario I had years ago. We built a ***ing workstation for Post Production video cost about $60 it had 7 PCI cards in it. As you put more devices into a computer the total capacitance sucks the guts out of the clock signal. The signal should look like a square but it turns into a sign wave. It should be +5 volts or 0 volts nothing in-between. As the signal definition becomes weaker the components are trying to decide if 2.5v is 0 or 5 volts and different components take different sides. The video card failed and the system doesn't boot. You use a post code card which tells you the system freezes at the video card. Swap the video card with an identical one working in another machine and it doesn't fix the problem. So you start pulling the other cards out and it boots. Your immediate response is the video card is ok and its another card to blame. The real fix is replace the power supply with a cleaner power supply, replace the main board with a better designed board and change the video card to a card with better quality ram. Hope this post wasn't too boring

I work in a very lightning fertile environment. Lost 70% of my main comms room once and it took me 3 months to get it all going again only to have it taken out again this time about 80%. We lost 80% of a PABX ie 80% of the cards had blown lines. Main Router, Mobile Phone Power supply fried 2 x 2way repeaters. 1 Minilink (Ericcson Microwave) Main Microwave Voice Mail Server 2 x ISDN boxes Several Data modems Fried a 150 pair Phone cable The list goes on My diagnosis was the hit came from the earth. I had a data modem that had its feet melted and a great big burn mark on the bottom, So I threw it in the definitely stuffed pile. When I finished fixing everything I tested this modem and it was still working. The strike had come up through the earth and jumped to the chassis of the group switch it was sitting on. The power supply and the main board were unaffected. When I started on this job 8 years ago. I had about 5 devices which would self destruct every thunder storm. I would loose the Minilink (Ericcson microwave connecting our village to the site) about 5 time a year. So I eventually replaced all copper between buildings with fibre and got rid of the Minilink and replaced it with a more robust device. Took me ages to diagnose why the Voice mail server stopped working. It ended out that the Parallel port got fried. So the whole thing was working apart from the licensing dongle. But there was no obvious sign this was the problem. The machine had 4 ISA cards in it and I could no longer buy another main board with 4 ISA slots. So I couldn't just migrate the box to another machine to diagnose the problem. Most of the PABX took hits to the filter cards that are designed to be a low cost sacrificial card. Still a pain when 70% of them go. A few of the main cards got fried as well. Microcell lost its main board on the power supply. This was a big 32ru rack power supply. Cisco Router, I lost this about 4 times in 4 years. Just totally fried every time. So what's the lesson. Several device I would loose all the time but all these other devices would normally survive. But when you get a direct hit nothing is sacred. You can't stop lightning, a fuse won't be enough as the weakest component in your device may go before the fuse and lightning can come from any direction, up from the ground, building to building. The best you can do is put in fibre everywhere but if you get a direct hit only luck will save you. But when you do loose gear it can quite often be fixed especially if there is no big black marks on them. It doesn't take a lot of voltage differential to destroy some devices at their weak points. Here is another rule. When you have to running copper between infrastructure you only earth the shield at one end. Don't earth it at both ends. The Voltage differential between two buildings can be enough to destroy electronic equipment even with out a lightning strike. True story, Group of soccer players standing in a circle around their coach at training during a thunder storm. Lightning hit the ground near by and the guys with one foot closer to the lightning than the other got killed and the ones with their feet equal distance to the strike survived. Same with buildings the building closer to where the lightning hits the ground has a higher potential than the building further away. So if two buildings are joined by a copper cable then the voltage will flow done that cable to equalise. I recon most of the carnage we experienced was from ground strikes. The big one's where from direct hits to the main tower but I believe it was venting to earth to other buildings was killing most things.

We are in a corporate IT environment (BHPB). So by using an NVR, IT are oblivious to the use of the server. It just looks like an SQL server to them and they look after all service packs and virus scanning etc. Be warned that any SQL is far more susceptible to virus's and hacking than a normal server. This is because it advertises its existence and there are powerful queries you can run to exploit the server if not properly secured.

Hey Rory We use lots of Mil spec and other connectors on our machinery. We then wrap them in Rubber weld tape. Probably the same stuff as the cold shrink stuff mentioned above. Its good cause there is no sticky residue when you take it off. We opperate in 60c heat, dust and hyper saline water. Nasty as they come. And it works a treat.

Banks IT infrastructure is just at another level. Banks will all be running decent high speed WAN. T1 / A or multiple B services to their small offices and will have leased fibre between their data centres so bandwidth will not be an issue. They typically buy Hitachi storage at $15k per terabyte (hard disks), and are leaders in server virtualisation. So It would be sweet if you could land an integrated deal. Find their IT capacity manager. He should have an idea of server, storage and comms capacity and how to go about integrating the services. Banks IT departments are top tier, so don't even discuss DVR go straight for NVR. If you propose a DVR system they will just think you are out of your depth. They will supply the storage, servers, and comms, and will need to implement the most of the system in particular server NVR virtualisation and comms QOS. You will not need to do a thing apart from fitting the cameras and setting up the NVR software. Try to get their IT department to do as much as possible. You could learn some really neat tricks. They will have Virtual servers, multiple data centres, Tier 1 storage on SAN and layer upon layer of inbuilt redundancy. They will be able to run the NVR database any where and the captured video anywhere else and move it all at the drop of a hat. All of this infrastructure will already be in place. It will be a real eye opener. If they don't go for an integrated system, then you can look at anything that fits the budget, DVR or whatever. but they won't let you use any of their infrastructure with out going the whole hog as banks won't tolerate any down time of their financial systems.

Ethernet you are looking at 10, 100, 1000 mb/s ADSL is 8mb/s and 24mb/s no where near as quick, and I have my doubts that you will ever get it. If you want to get to a camera further than 300m away on Ethernet, turn the network speed down for that link. If you set it to 10mb/s half duplex you will get the longest distance. However 10 full will probably suffice. CAT 6 cable could possibly deliver longer distances. 10mb/s should be fine for 1 camera and possibly 2. Big difference between Analogue and Digital signals is Digital (if it gets through will guarantee integrity.) Analogue will not. The digital signal carries parity checking. TCP/IP can guarantee packet delivery, UDP/IP doesn't. With live video viewing you only want UDP because if you miss a packet, too late, forget it grab the next. However if your tight you can set your recording stream to TCP so when you review you pick up everything. Short answer is if you go over 300m you do need to chose another medium. You can use Ethernet over copper which is designed for low quality cables (phone cables). But in reality fibre is best. While this limitation may seem retarded for this industry, The real question is what other devices in the area could use IP and therefore justify a switch in the initial design. One area you guys in the security industry could look at is Power on IP (not PoE). For about $500 you can get power boards that can be controlled remotely with IP. Find an excuse for a power board and you have an excuse for a switch. There are many other devices that can utilise IP control and monitoring. I am looking at water pumps, two way radio's, RAP's (remote area power systems) and more traditional process control serial devices are being moved to IP. So we are using any excuse to put IP switches in as many remote areas as possible.

This is my control room. Its all IP. Only 4 of the 18 monitors normaly display video however 14 of them can be used at a moments notice. 4 can't as they are physically on a different network and the boxes are running Unix. (two monitors are behind the photograph) So the other 10 monitors normally run email, heavy duty vehicle health monitoring systems, ground slope radar monitoring systems, GPS location systems, Lightning detection systems, databases and servers administration. There are 3 consoles (one you can't see because its on the back wall) that are on a shared KVM with direct connection to up to 31 computers. There are several heavy duty servers, that we never normaly veiw apart from administration. There are 3 SQL servers, 2 Unix servers, one backup server. There are 9 workstations each running duel monitors. All of these services can be replicated with the use of a password around the world (anywhere on our network)

Bandwidth is a bit more compex than reading the manual. Just cause it says something doesn't mean it work or is true. Best to fully test your devices to see what they deliver. You can save a lot of bandwith by using your head. Work out what image you need. Are you looking long distance, focusing on numbers, need every frame, how many frames per second do you need. What you need to record and what do you need to view. Also are you network bound or storage bound. Most people are network bound. Firstly if you can record what you view then you half you network bandwidth by sending the one stream instead of two. Then your recorder may have the ability to reduce the number of frames or bandwith again. So if you are network bound try to use one stream not two. Secondly if your cameras are mounted outside it is important to reduce movement as much as possible. Avoid using any poles of towers that have twisting movement. Many towers have legs that twist as the tower moves. So mount your cameras on the cross beams not the legs. Twisting creates greater image deflection than swaying especially when focusing over long distances. As mpg compression compares each frame with the previous frame then any change increases the bandwidth. After this look at all your standard stuff. Frame rate, resolution, flitering, compression, seconds to new frame, bit throttle and frame throttle. Most of these can be replicated again on the recording device. You should look for a system that has its own bandwidth report on it. Whatever format it come in. Mine has a test window that tells you howmany b/s are being transmitted. Or there are many different network monitoring devices. NetBoy is pretty user friendly. So in answer to your question you can limit the bandwidth to what ever you want. You just have to know how many frames per second you will get and quality you will sacrafice to get it. The more the picture moves the more bandwidth the mpg algorithm will create. Beyond this you will need to know if you are using a multicast address. in which case you need to know the bandwith capabilities of the weekest device on the network. The only other question is you asked for the bandwidth of the recording device. Are they talking about the encoder bandwidth. The server network card capabilities, in or out? Or are they talking about the servers disk bandwidth capabilities. Chances are they don't know either. Best you ask them all these questions. Knowing the answers yourself first. Next get a dev budget to do your testing during which time you thrash the network and find the weekest device and at what broadcast limit your weekest devices break. Most likely 10Mb-s. These are likely to be old printers or print servers, and wireless IP devices that do not have port filtering enabled. Best to know this before you break them rather than after. Hope that helps

For most of you learning how to setup a network for an enterprise environment would just be a waste of time. However you should look at different sized businesses and how they implement a network. The sizes are: 1-10 10-20 20-100 100-1000 1000+ Site distribution Single site Multi site Multi site + data enter. Multi site, data centre, Disaster recovery sites Comms infrastructure Public infrastructure (ADSL) Private infrastructure (Leased lines ATM, ISDN etc) Industry security level Small retailer service industry manufacturing Banks Different size and structure will set the network and IT standards. As the size of the business grows so does its yearn for control of its network and IT infrastructure. Cost of hardware starts to pail against the requirement for standardization and remote control. So things like enterprise switches that knit together into one management console become the standard despite their cost. DVR will be put aside for NVR. Duel fibre and redundant fibre loops, alternative backhaul, and advanced routers and firewalls become the norm. Server virtualisation, SAN, and locked down desktops pose other issues for vendors dealing with larger companies. While you may have implemented DHCP successfully in a 20 device environment things change when you hit 1000 devices in a subnet. DHCP isn't such a good thing for every device. One of my networks with over 200 devices all statically addressed. Learn at what sizes these changes start to occur. Know where you skill set is at and instantly recognise if a customer is at the next level to you. Know when it is beyond your knowlege and when to turn the job away. Be prepared when you take a jump to that next level and don't jump too many levels at once. And remember just because it works doesn't mean you have it right

IEEE standards are the institute of electrical and electronic engineers so they are aimed at electronic engineering protocols not at products. So you are unlikely to get an IEEE standard for video surveillance. The Video surveillance industry is already covered by many IEEE and other standards. For instance there are several hundred IEEE standards for LAN (IEEE802), then a handful for wireless IP(IEEE802.11). SCSI has many IEEE standard of which 1394 is an off-chute (firewire). POE now has an IEEE standard 802.3af. (part of the Ethernet standard) RS232 are standard set by the Electronics Industries Association (EIA) Issues like pixels density or frames per second could be video standards so you would look at VESA for standards. Video Electronics Standards Association. Database standards are really set by the vendor and the end user. MS, Oracle, Ingress etc. However there are groups of vendors or users setting standards etc. SQL, Java, Then some vendors in the industry will adopt other vendors standards. Pelco compatible PTZ's etc Management and support of the whole system should be covered by the ITIL standard.

Oldschool hey? Yeh I was looking for some photo's I had. I had an Ericsson Minilink (kind of microwave) which ran IP over coax. Fried it too many times in lightning strikes till there were no spare parts left world wide. It did 8mb/s. Ran a PABX and IP over it. Killer stuff. I also had a Fibre to coax media converter to E1/T1 (ISDN). Real pain cause I had was running ISDN over Cat 5 at both ends. But you cann't get Cat 5 to Fibre media converters to support ISDN. Took ages to find these and to work out the balun to convert the Cat5 to coax. A lot of stuffing around cause the boss wanted video conferencing. We get lots of lightning up here so I went to a lot of effort to run every protocol to fibre.

Yeh the other problem with Java is there is a standard, but no-one know what it is. We run over 200 applications on site and Java apps will constantly knock each other over if change management it left to the developers. .net should fix all that.

Come to think of it I have IP running over coax here too

And coax is everywhere right? Got to agree with Rory on one thing, Web is lame. You only use Web (HTTP) client if you don't want to distribute client software. And even then a proper IP / CCTV based web solultion will need to accept multicast traffic which can't be on port 80 or 8080. So the majority of the solution is not web at all. The other question is why do you want a security application that the rest of the world have the client to. While they still can't get past the security the know its there and what it does. PS. IP based CCTV is an oxymoron. Once it is on IP it is no longer closed curcuit.

Guys IP doesn't mean Internet. IP is internet protocol. The Internet is the IP based public connectivity between users. Don't have to use the public access ("The Internet"). If you have two sites with local area networks you can lease lines from your Telco, that can be IP based or encapsulate IP. For instance ATM lines or ISDN are not IP but you can send IP over them, just like 2.4GHz RF isn't IP but you can send IP over it. You can direct connect your two sites without going though the internet. You can also Dig a trench and lay fibre or use microwave, Wireless bridges, Satellite or Laser. Or run all or any of them. You can also go to an internet service provider and ask for redundant connectivity. So they will have two separate sites which you can use for connectivity. Being IP it will work out the cheapest (quickest route) cause that's what IP is designed to do. And you have instant redundancy. Or in my case I use both leased lines and public internet using a VPN. I connect out via Sydney and Singapore (4000km) and in via Kalgoorlie and Perth (600km) We use direct ISDN leased lines to Perth (1100km) and public lines to Leinster (100km) The ISDN are on a "A" class service which I break out to 10 "B" class lines on a JTEC (private B MUX). I send Video conferencing direct over the ISDN lines, also utilise other lines to send IP services when required. Another company on site uses ATM. I have a firewall and a PIX between the two networks and if required I can reroute our traffic though their lease ATM line. IP has so many options. So much infrastructure is in place most of us just don't know its there.

Blades are more that raid. They are a diskless server. Available in two physical sizes. The larger size has 4 quad cores with up to 128GB of memory. There are two chassis available, the larger will hold up to 8 large blades. You can fit 4 large chassis in a 42u rack. Up to 128 quad cores 512 cores and 4094GB of memory in one rack. The disks are all SAN and can be virtual. You then use VMWare to run instance of the servers you require and allocate memory and processors to each virtual server. If you run into trouble you can start another instance of that server on the same blade cluster or on a different set of blades and move the server over seamlessly. You can allocate the memory and processing power as you see fit. The OS is loaded of flash and backing up the OS and system the old way becomes a thing of the past as the image is a live load. I have been looking at installation that use redundant blade server, switch fabric, fibre, San and San switch fabric. Each server runs 8 network cards crossing to the redundant switches. Then the switches are linked for cross redundancy then the entire data centre is replicated in two other disaster recovery sites. Each switch is cross linked with the redundant switches at the disaster recovery sites. As an exercise they flick over to DR sites at any moment then that site becomes live till the next test.

Ha ha can relate to that, I use to work in computer retail. They want everything available for less money delivered yesterday.

If the 1100km fibre cable gets dug up.....again. MOFO sat dish. Still waiting to close the loop to the North need about 300km of fibre buried then we will have redundancy. Old school disk array and tape (Dell) 15k disks One of the nastier apps to support. Alarms on about 150 onboard sensors on the trucks and shovels. CAN Bus to RS422 to IP, Saves us more money than CCTV, Shutting down a motor early can save around $300k on the rebuild. Wireless IP trailer, brings in trucks, cameras, two way radios, radars, and ground monitoring on IP Simulator, I are looking at retrofitting this to remote control autonomous trucks on IP. so using live IP cameras on the trucks. Also looking at drills New Small IP comms trailer. 2m long box with 19u rack space 15m pneumatic mast, work platform and 1400w solar power 125w continuous power 400kg batteries. About to build 3 more but 5m long boxes, 500w contiuous power with 60u rack space, 1600kg of batteries and 300Mb/s wireless bridges.

Ha ha ha Reply coming shortly you mean the network right? All three server rooms and two control rooms are currnetly Lan. The offsite network wan not internet

We have about 30 servers in 3 geographically independent server rooms in different buildings 28 databases on 22 servers, several databases on some of the servers. About 18 of those databases are low resource utilisation including the database component of the NVR. We can get rid of 20 servers and replace them with 6 blades, 2 in each sever room along with SAN. The result will be total redundancy, saleability and disaster recovery for all those services and databases and storage. We will still use dedicated high-end application servers for the heavy duty databases and separate the SAN based on a disk utilisation requirement. So the NVR will have dedicated high speed storage with arrays designed for contiguous writing but shared database and licensing services will be on the Blade servers. Other services to be placed on the blades will be Web, DHCP, DNS, AD, NTP, SNMP, F&P, OMS, Licensing services, and MS SQL. Been planning this about 3 years and have an even more elaborate 5 year plan to bring 5 or more sites together. Any server with dedicated hardware just doesn't fit the system. Even a USB or Parallel port dongle is unacceptable we favour internet based dongles. Puts things in perspective with you can reduce 20 servers down to 6 but 1 gets left behind because it had a non virtual piece of hardware attached. Guess we have different focus, You are looking at CCTV systems in multiple sites where I am looking at many different systems in one site. My biggest issue is not hardware cost but management cost, keeping a team together who know how the systems work. I am always concerned about all my systems and the best way to manage them all. The NVR system is one of the easiest systems we have to deal with, it is a subset of many of the other systems. Cost benefit analysis between NVR and DVR you would probably go DVR. But when you do a CBA on rationalising 30 server and 28 databases your focus changes to standardisation and small things like a dongle or a card make a huge difference, why build and maintain a sever when you don't need to. As you said you don't use blades, you don't have a 70+ different services to deliver at one site, so you don't have to. However that doesn't mean you customers shouldn't and aren't be thinking about it.

Can't put a capture card in a blade, you can't distribute storage transparently around the network. You are always bound by geography and physical presence.

I thought you had to put a capture card into the server?