tesc_cctvpro

Hi there, For Multi-POS integration with TCP/IP, you have to work with the NC-Series devices to convert through COM(COM port data from POS machine) to network(a RJ45 port to connect to the HUB/Router to transffer data), here I make a pic to show how to set the multi-POS system. By the way, right now, Multi-POS Playback at the same time is supported, up to 4 channels at the same time. Thanks and you can PM me if you have any problems. Hi William, Thanks for taking the time to respond. Our guys have no problem with the TCP/IP functionality - the problem is when they don't want to use the TCP/IP feature, and they want to use RS232 in the case of a single pos, or RS232 to RS485 for multiple serial pos connected to the DVR's Serial ports. Following the manual and cable configurations exactly has not yet achieved success for any of them?

Thats a point which makes sense to me: NVR vs DVR are as susceptible to failure as the other. But LAN Hardware introduces "additional points of failure" - and let's not imagine network hardware, rarely fails! I can understand that one cable failure on a HDcctv system could lead to loss of video/recording on one camera - what does it take for all the cables on a HDcctv system to fail simultaneously? A dead switch, or other piece of hardware failure can be accommodated, depending on the topology you employ, i suppose. Yes i did read Carl's words. In fact those words moved me to further research which I sited - so a bit obvious that I did read his words. Is it a given that someone who doesn't terminate properly on an HDcctv system, is apt to do so on a LAN system? Cable problems account for the majority of issues in any cctv system. Not only does it seem that HDcctv is sensitive to cable issues - but apparently common coaxial cable and BNC connectors are not going to suffice for anything over 2MP and everything would have to be optimal to even handle 2MP The additional benefit of IP in providing a second NVR would seem a somewhat mute point in this area of the discussion ---- LAN Failure, wouldn't it? At this point in the discussion i am getting the idea that yes " LAN introduces additional points of failure that would not be present in an HDcctv system" Cable and cable failure is common to both systems. The effect of cable failure on an HDcctv system is likely to be less than on a LAN system HDD/Storage failure is common to both systems Network Hardware creates additional points of failure and the more complex the network, the higher the factor of failure. The cable issue still seems significant, take away the ability to upgrade an existing analog system to HDcctv and then we have to start comparing both systems from the perspective of new installs!

I noted that your motivation for wanting an IP camera is so that you can log into it from wherever you are! This functionality is available on analog, ip, gsm camera systems. Is that the only reason for wanting an IP camera? and how many cameras are you looking at installing? --- if it's just one, IP should be ok!

No: Just confirmation that your dyndns url is bringing your traffic to your gateway. As you say you have already attempted port forwarding settings, why don't you give me the DYNDNS url --- or better yet somebody on the forum who is in the same country as yourself, and let them check if the traffic is stopping at the gateway, or if it's being forwarded to your DVR. You usually cannot check this from within your own LAN - at least with the service providers we have in my country. If it's only getting to the router logon --- then you will need to review your port forward settings in the router.

Just to add to what's been said above, the divide between monitoring (10% screen estate) and identification is quite wide. With the specs you envisage you are right on the boundary of minimum accepted monitoring parameters., bordering on almost unusable images. There are many measures used - but mine happens to be as follows: Monitor - detect- Recognize - Identify Monitor - following the movement of targets whose presence is already known, without the requirement to search for them. Detect - following an alert, the operator can determine to a high degree of certainty whether a person is visible to him. Recognize: Is able to say with a high degree of certainty , whether the person being observed is the same person as someone he has seen before. Identify - sufficient detail to be able to establish the identity of a person beyond reasonable doubt. It is not a simple step from Monitor to Identify If your sole purpose of installing the cameras is "deterrent" - this could even be achieved with some really large dummy cameras. I think the above advise is spot on, you will invariably regret providing for "monitoring" only!

Thanks for the input ---? Is it fair to say then that interrupted recording on all cameras from a LAN failure on an IP system is far more likely than interrupted recording on all cameras on an HDcctv system? I have added your insights on the cable to my list, and will be doing some research and questioning of our manufacturers about it, thanks for that! --------------------------------------------------------------- The cable issue I am assuming would relate to SMPTE 424M (1080p) Regarding the connectors - the standard requires better than -15dB Return Loss between 5Mhz and 1.485Ghz, better than -10dB between 1.485Ghz and 3Ghz. (HDcctv in the region of 3Ghz and higher) Apparently -15dB is marginal, and it seems that the best BNC design currently rates around -30dB. I see some manufacturers are coming out with enhanced BNC designs in an effort to meet the requirement of SMPTE 424M for HDcctv transmission over coaxial cable. The standard allows for bit-rates of 2.970 Gbit/s and 2.970/1.001 Gbit/s over a single-link coaxial cable. These bit-rates are sufficient for 1080p video at 50 or 60 frames per second according to this latest SMPTE standard. So I imagine when looking at 1080p video in the 3Ghz + range, that even standard RG6 with standard connectors is going to be marginal. With RG59 certified to work above 2Ghz, problems are likely to arise with 1080p HD cctv signals, and compound with a non compliant connector. RG6 certified to work at 3Ghz, would likely also present problems as this is right at the upper margin, and would be compounded with a non-compliant connector. Very interesting stuff! That has to be hugely significant in the case made for upgrading existing analog systems. What percentage of those systems are running on RG6, I suspect a large volume are running on RG59 with apparently inappropriate connectors

Thanks for covering my concerns in the first part, adequately! Yes your requirements are possible. The standard analog system shares this almost standard functionality with numerous other DVR's out there. However with the issues already discussed the motion detection on the dvr with those cameras may not be the most reliable method. Have you considered some kind of PIR beam , which could be wired to your recorder or IP cameras if that's the way you are going! In addition to being messaged, emailed and sent a snap shot of the event, an external alert can also be hard wired into the system. Basically everything you ask in this part of the question is almost a standard feature on all dvr's - so yes it is possible.

I'm always a little surprised that anyone falls for any part of the hdcctv gambit, but this is one that is especially puzzling. My objective has been to approach this with a totally blank sheet. I will not form an opinion until i have assessed the claims objectively, in tandem with soliciting objective views from professionals. Hence my interest in this thread. It seems that the HDcctv alliance correctly claims an advantage in terms of latency. I was interested in the Picture Fidelity issue - but I note that is no longer listed as a claimed benefit on the HDcctv alliance website- it now seems to merely address the facts of the standards. So, looking at the next item on the list. (The recording is immune to IP LAN failure) My initial impression is "yeah sure it would be , because it's not connected to the LAN" but I wanted to try and establish what part of an HDcctv systems correlates to the LAN in an IP system. Would it be correct to say that the cable between the camera and recorder would fit the bill? So the question arises: is HDcctv recording as susceptible to a cable failure between camera and recorder, as an IP systems recording would be to a LAN failure? What is the probability of complete recording failure on all cameras on an HDcctv system, compared to complete recording failure on all cameras within an IP system? How do redundancy measures intended to prevent total recording failure on an HDcctv system stack up against similar redundancy measures in an IP system. Of course I would also be interested in any other objective observations relating to this claim of the HDcctv alliance that HDcctv recording is immune to LAN failure?

If you are aiming for a field of vision wider than 81 degree's ? Your Surveillance objective is likely pure monitoring at no more than 10 meters. A human target will likely not even fill 10% of the monitor size at anything beyond 10m (32ft) with a 2.8mm lens. which is the minimum accepted for monitoring. I have managed to get something of a reasonable picture under those circumstances by going up very high, about 6m (18ft) -but that was less than desirable, a budget enforced solution. That solution will purely alert the observer to the fact that a target is present, it will likely tell you nothing about the target. Motion detection is a form of video analytics - it is notoriously unreliable outdoors with a cheap camera. I am wondering whether your objective is really to get such a low level of detail, unless you are only intending the camera to cover say up to 15ft at that width of angle?

You can get a full HD 16 Channel DVR with 8 Hard Drives from Comart - Korea, but get this ----- must be around $11000 for the recorder.

So now the HDcctv alliance claims that because they subscribe to the SMPTE standards, this will translate into a higher standard of picture fidelity, and motion picture type dedication to frame rates. Whats the comments on this issue versus ip image fidelity and frame rates.

Nothing is ever more meaningful than real case studies , situations on the ground. Thanks for that input!

Sounds like a service nightmare. How can you be great at anything if you do everything? LOL ---- Claiming that one product or one manufacturer meets all criteria, sounds like a service nightmare to me! I don't install -- but my customers are a diverse range of integrators. Some focus entirely on mining, some have specialized in gated community security, others are focussed on POS, and others on chain store, some do mid end analog, some need HD IP. We are actively engaged in every project with each of them from the design stage to completion, because ours is the logistics end - sourcing the proper equipment, and delivering it at the appropriate time.

Well that's it HDcctv has an advantage with latency. Great, can we focus on some of the other things that the HDcctv alliance claims as advantages on their site. I think another exhaustive debate will give me a pretty good idea of what the truth is! HDcctv has an advantage with latency, but are we willing to pay 10x the price for a recorder ?

tesc_cctvpro i asked a simple question. on what products you used if your seeing so much latency (your quote 90% of installs) it would have been good putting it into prospective . so it is part of the thread. you asked me to look at your website yesterday. your writing not mine. largest business ... Specializing in Surveillance System design and installation ... CCTV Video Surveillance, IP Technology & Solutions and before you have a go at me like you did yesterday. my questions were good but you dont seam to give a plain answer back. you go all around the the answer. you seem to be active on alot of forums. and what has come to light is you are doing alot of copy and pasting. so i can now see why you cant answer. another post were YOU say you install. Hi Guys, nice to join the group - off the bat, I want to start offering VAAS to my customers, where I only need to install IP cams on the premises. I don't know anything about it ---- so where do i go from here ill leave your posts alone now as it does not seam to be going anywere and when you ask people to look at your sit ( like me ) and you make a comment you dont install. and you have a go just because it says you do on your site does not make sence. I am not going to spend a lot of time replying: My company is a logistics solution which supplies a closed network of integrators. Yes we do specialize in surveillance system installation and design - we have to , because our customers are installers - but we don't install ourselves Again - we are looking at setting up a VAAS infrastructure and offering it to our customers, who are installers and will in turn offer the option to their customers. The tack you have taken in responding to my threads says enough i think. It is easy to read into anything - what we want to when we are pre dis-positioned. I won't engage you further as i think this type of contribution is not beneficial to the topic at hand.

it is staying on track. if your seeing network problems. then if you let people know what cameras of VMS you are using then we can compaire but you do install you have a blog and advert saying so. The topic is about HDcctv setting the new standard. And If i tell you that I don't install and you tell me that I do ---- then i really think you are better off just answering those questions on my behalf!

sorry but that just does not make sence. ok what have you used in the past and how did you find it. What doesn't make sense --- that some applications call for analytics, which some providers are better at than others, that some providers offer state of the art products at high prices, that some emerging manufacturers offer better pricing, that milestone has unique features that would make deploying something else just plain wrong --- and that you have to marry these issues to what is being defined in the ORD --- , that a plain CIF dvr may make the grade in some instances, that HDcctv might offer benefits in one case, while HDip may do so in another -----that doesn't make sense? The main stay of my low-mid end installs are built around Fibridge in China. Number 1 Chinese network brand, with advanced network and video transmission hardware, now expanded into surveillance products. If I had to go higher, I am not wasting my time ----we select Axis. But we have deployed Milestone applications in some instances , we have used some other providers too.......... I don't get into the this is better than that debate - thats for sales people and brand representatives. But yeah, Mostly I am using Fibridge, or we will use Axis.. How did I find it -----it worked! Of course it could take me a whole lot of time to answer that question exhaustively for you!

By the way ---- I don't install. We are a security logistics company , that is more involved in product sourcing, and logistics. I would have vastly preferred that the discussion stay on track ---- I think the issue of latency has been exhausted, so how about some discussion on the other aspects of HDcctv vs HDip. Like the SMPTE standards , etc........I am really interested in in-depth understanding of people's views around emerging technologies.

Whatever best meets the criteria of the Operational Requirements Document. We do not believe in loyalty to any brand or technology, we believe that the ORD will ultimately define the criteria for each project, and that equipment, software, etc will be selected based on those criteria. A major annoying feature of cctv installers is when they latch onto some technology and then try to force fit everything to that solution ---- they adopt a religious attitude and start to spew out ill principled logic in defence of their chosen solution. You could keep spinning them for days --- because the only right answer is that the Needs of the project will dictate the technology or solution that should be used.

Could you expand a little on how a closed dedicated network system for CCTV is a lot more valuable and useful to the end user than a closed dedicated RG59 network for CCTV? I shouldn't have to I feel like your probing us for information. if you wish not to -----> I thought I could learn something

So you don't think that your choice of Codec has more to do with latency then the network itself? I think your choice of codec may produce "processing latency" but - that occurrs prior to or after entering or exiting the network pathway. Network latency would also account for time taking by the hardware to process the data. So on top of network latency, you also have processing latency, which is not only affected by your choice of codec, but can be compounded by your choice of operating system as well. I am particularly trying to avoid being led down the intended path, which your choice of words such as most, or more implies. Trying to measure whether most latency is generated by hardware , or codec or operating system is an impossible paradigm in the absence of a specific reference network and hardware design, surely we cannot assume all topologies, hardwares and codecs to be equal.

So you don't think that your choice of Codec has more to do with latency then the network itself? I think your choice of codec may produce "processing latency" but - that occurrs prior to or after entering or exiting the network pathway. Network latency would also account for time taking by the hardware to process the data. So on top of network latency, you also have processing latency, which is not only affected by your choice of codec, but can be compounded by your choice of operating system as well.

Could you expand a little on how a closed dedicated network system for CCTV is a lot more valuable and useful to the end user than a closed dedicated RG59 network for CCTV?

Question tesc_cctvpro Do you think most of the latency comes from the network equipment? The ability of connected network hardware to process data packets received by it certainly is a large factor. But no -- the majority of latency i imagine comes from data queues - if the data packets sent to a single piece of hardware result in unreasonable delay (Queues) that cause network congestion beyond an acceptable tolerance - it's not the hardware that caused it --- rather the incorrect application of the hardware and poor network design. But fundamentally when a piece of hardware receives a packet, it wont forward the packet until the whole packet has been received, so it's apparent, the path of the packet across the hardware is not without delay. Add hundreds of pieces of hardware together and that delay could begin to become significant - the issue of Queuing of course adds additional delay to that fundamental reality of packet switching.

90% is high. a cctv network should be dedicated all brand new and not used in connection with anything else. along with good switchers. that way latency is so low its not worth talking about In the scenario you describe , yes 100% ---- in addition, that means it remains a security system with limited access!