Hikvision CCTV system using Point to Point link, viewing issues

[RobotSystems]

We installed a 5 camera CCTV system (all Hikvison cameras and 8 channel NVR). The 5 cameras are located about 300m away from where the NVR is located. The Point to Point bridge is created using a TPLink CPE kit.
When the TPLink was activated connection was made immediately with a 5 bar registration. At installation the cameras all came up successfully on the NVR. We have been viewing the cameras and recording via the IE chrome extension on a laptop, via the wireless LAN.
Since activating event triggered recording (motion detection) are experiencing significant 'stuttering' in the live view whenever there is movement in the camera viewing area. The feed will go for 2 or 3 seconds, then freeze, then resume after say 10secs or so. This is also happening when viewing recordings.
I have now turned off all event recording and all cameras are recording continuously. I have also reduced frame rate to 10fps and reduced the bitrate. But the issue is unresolved.
Has anyone got a similar CCTV installation using a wireless Point to Point bridge? Any pointers would be most welcome

 

[David]

We installed a 5 camera CCTV system (all Hikvison cameras and 8 channel NVR). The 5 cameras are located about 300m away from where the NVR is located. The Point to Point bridge is created using a TPLink CPE kit.
When the TPLink was activated connection was made immediately with a 5 bar registration. At installation the cameras all came up successfully on the NVR. We have been viewing the cameras and recording via the IE chrome extension on a laptop, via the wireless LAN.
Since activating event triggered recording (motion detection) are experiencing significant 'stuttering' in the live view whenever there is movement in the camera viewing area. The feed will go for 2 or 3 seconds, then freeze, then resume after say 10secs or so. This is also happening when viewing recordings.
I have now turned off all event recording and all cameras are recording continuously. I have also reduced frame rate to 10fps and reduced the bitrate. But the issue is unresolved.
Has anyone got a similar CCTV installation using a wireless Point to Point bridge? Any pointers would be most welcome

@RobotSystems what model of P2P link and antennas are you using?

 

[RobotSystems]

@RobotSystems what model of P2P link and antennas are you using?

It is the TPlink CPE210 kit CPE210 | 2.4GHz 300Mbps 9dBi Outdoor CPE | TP-Link United Kingdom

 

[David]

It is the TPlink CPE210 kit CPE210 | 2.4GHz 300Mbps 9dBi Outdoor CPE | TP-Link United Kingdom

@RobotSystems Could you attach a screen recording (60 seconds) of the status page from the Access Point and client?

 

[RobotSystems]

@RobotSystems Could you attach a screen recording (60 seconds) of the status page from the Access Point and client?

Evening David - I will be going on site tomorrow so will do the recording then and post it here
Many thanks

 

[David]

Morning @RobotSystems
The RF path between the two antennas maybe unstable so we need to put some temporary fixes in place. I think the radios are using a lot of processing power to correct errors across the link. The plan is to reduce the data load and improve the signal to noise ratio (SNR)

Record the videos before making the changes below.

Set AP and Client wireless speed to 72.2 Mbps (10MHz RF bandwidth)). Option change to 36.1Mbps, 5MHz. This will improve the SNR. Change the remote end first.

Change all camera video resolutions to 720p, 10fps, medium video quality. Option to record sub stream 360p.

 

[David]

@RobotSystems for troubleshooting make sure to test video live view / playback from the NVR. other devices could give misleading information.

 

[RobotSystems]

Good Evening David - thanks for the pointers. I did some troubleshooting on the cameras and NVR this morning. Viewing the cameras and playback recordings direct from the NVR, not using the router, showed that the video data seemed to be reaching the NVR and recording smoothly.
I had reduced the frame rate and bitrate so it seemed like the problem was dealt with. Then, when looking at some playback footage there were a couple of sections on one of the cameras where the recording 'stuttered' for a few seconds, as before. I determined that this was one of the cameras where I had left the Motion Detection enabled, (along with something called Motion Detection Dynamic Analysis), although the stream was being recorded continuously. On the playback bar there were a couple of green 'tags' on the timeline that seemed to coincide with the stuttering - the NVR 'key' notes the green tags as 'Smart Events' - again not exactly sure what that signifies.

To further test the hypothesis that these 'Smart Events' might be the trigger for the 'stutter', I have enabled 2 of the cameras with Motion Detection (no MDDA) for a couple of hours, then enabled the MDDA function for a few hours, I will then disable these functions and interrogate the NVR directly onsite tomorrow.

I did record the status page for the TPLink for your suggested 60secs - however I'm not going to upload the video as it is 70mb and will cripple my broadband for the foreseeable future...... (the joys of rural broadband 'service') However I attach a couple of screen shots - AFAI can tell it suggests a stable connection, but I admit to very basic knowledge re Access Point workings.

 

[David]

Good Evening David - thanks for the pointers. I did some troubleshooting on the cameras and NVR this morning. Viewing the cameras and playback recordings direct from the NVR, not using the router, showed that the video data seemed to be reaching the NVR and recording smoothly.
I had reduced the frame rate and bitrate so it seemed like the problem was dealt with. Then, when looking at some playback footage there were a couple of sections on one of the cameras where the recording 'stuttered' for a few seconds, as before. I determined that this was one of the cameras where I had left the Motion Detection enabled, (along with something called Motion Detection Dynamic Analysis), although the stream was being recorded continuously. On the playback bar there were a couple of green 'tags' on the timeline that seemed to coincide with the stuttering - the NVR 'key' notes the green tags as 'Smart Events' - again not exactly sure what that signifies.

To further test the hypothesis that these 'Smart Events' might be the trigger for the 'stutter', I have enabled 2 of the cameras with Motion Detection (no MDDA) for a couple of hours, then enabled the MDDA function for a few hours, I will then disable these functions and interrogate the NVR directly onsite tomorrow.

I did record the status page for the TPLink for your suggested 60secs - however I'm not going to upload the video as it is 70mb and will cripple my broadband for the foreseeable future...... (the joys of rural broadband 'service') However I attach a couple of screen shots - AFAI can tell it suggests a stable connection, but I admit to very basic knowledge re Access Point workings.

@RobotSystems
at least your P2P link is stable, if your link is in a rural area you should be relatively free from adjacent and co-channel interference.

what are your NVR / Camera model numbers / firmware versions?

Motion detection is renown for excessive false alarms, especially outdoor. Why not try intrusion detection, on the web GUI menu its configuration> event> smart event. There are other smart detection options available.

 

[RobotSystems]

I'm back! Sorry for the delay - argument with a drill resulted in a left arm injury so have been 'offline' for a bit.
So - the issue has become slightly clearer.
When the cameras are all set to a lower resolution (1920 x 1080) then live viewing and playback is fine. However yesterday I increased the resolution of one camera back to 2048 x 1536 plus activated motion detection on that camera alone and the live view stuttering has returned.
The cameras are Hikvision DS2CD2345FWD128 x 4, and 1 x DS2CD274 `fwd `92.8-12mm) varifocal
The NVR is 7600 series
The switcher is a Hikvision POE 8 port 10/100

The router being used is a Netgear DGN2200 300M model - I understand from the customer that it is about 9 years old. Could the router be causing the bottleneck? We are thinking that maybe if we try a new modern router that might help.

 

[David]

I looked at the V1 specs for this router and it should be capable, is the router used for any other high bandwidth tasks? If it is, reduce the data load on the router and increase the camera resolution.

I suspect the radio link maybe the problem. The radio link PHY rate is 300Mbps part of that will be used by the radios own link management overhead. If the link is compromised (first fresnel intrusion / co-channel / adjacent channel interference) a lot of the 300Mbps could be used for error correction. When you set the cameras to 1920x1080 that is the optimal point at which it works. I have worked on radio links that promise 500Mbps but after overhead and error correction 60Mbps was left for the user payload.

take a look along the radio antenna line of sight (LoS). If the antennas are "seeing" any nearby trees or buildings that may be the root cause.

 

[RobotSystems]

I looked at the V1 specs for this router and it should be capable, is the router used for any other high bandwidth tasks? If it is, reduce the data load on the router and increase the camera resolution.

I suspect the radio link maybe the problem. The radio link PHY rate is 300Mbps part of that will be used by the radios own link management overhead. If the link is compromised (first fresnel intrusion / co-channel / adjacent channel interference) a lot of the 300Mbps could be used for error correction. When you set the cameras to 1920x1080 that is the optimal point at which it works. I have worked on radio links that promise 500Mbps but after overhead and error correction 60Mbps was left for the user payload.

take a look along the radio antenna line of sight (LoS). If the antennas are "seeing" any nearby trees or buildings that may be the root cause.

AFAIK the router only has general internet usage loading other than the CCTV system

Antenna LoS is uninterrupted, there are some trees on the periphery, but no buildings or other structures. Certainly when monitoring the TPLink stats over time there doesn't seem to be any wavering of the signal to point towards signal interference.

I take what you are saying about some of the 300Mbps being taken up by the link management system usage, but it appears that the user payload draw from the cameras is 20Mbps at most - and what is being transmitted from the remote station is getting received at the base station without significant data drop.

I am wondering whether I can take the TPLink off the router network and use it to extend the NVR network, this way I can then get the camera feed directly to the NVR without having to go through the router. I have made enquiries to Hikvision as to whether this is something that can be done.

 

[David]

my NVR wan port does not connect direct to the router, it connects to one of the the camera poe switch uplink ports. The other poe switch uplink port goes back to the router.

20Mbps is not a lot. Have you checked the latency (buffering) across the radio link? As the radio link data load increases latency may increase and give you playback problems. Ping will give you an indication of latency but bear in mind that ICMP packets are low network priority and may be dropped by error correction.

 

[RobotSystems]

The situation we have with this system is that the 5 cameras are at a remote location. They are connected to an 8 way POE switcher. The switcher is then connected to the remote TPLink station, the 'air bridge' then goes to the Base location, the TPLink is connected to the router and the NVR is connected to the router. The cameras and the TPlink are on the router network (192.168.1.*) whereas the NVR network is 192.168.254.* The NVR gateway is 192.168.1.64 onto the router network.

I have not checked the latency across the radiolink - will have to investigate how to do this

 

[David]

I think the NVR private subnet 192.168.254.* is for the POE ports on the back of the NVR. The NVR WAN side and the cameras will be on the same network as the router.

Can you let me know the TPLink RSSI and SNR readings for local and remote?

 

[RobotSystems]

I think the NVR private subnet 192.168.254.* is for the POE ports on the back of the NVR. The NVR WAN side and the cameras will be on the same network as the router.

Yes I know that - we have the same NVR here at home and we have some directly plugged into the NVR and they are on the 192.168.254.* subnet - we have other cameras on the home LAN which are then connected to the NVR via the home LAN so they have the home router network IP's

Can you let me know the TPLink RSSI and SNR readings for local and remote?

No idea.....I'm pretty certain I haven't got remote interrogation possibilities with the TPLink - I can only access it when on the customer site via the LAN IP address.

 

[David]

Yes I know that - we have the same NVR here at home and we have some directly plugged into the NVR and they are on the 192.168.254.* subnet - we have other cameras on the home LAN which are then connected to the NVR via the home LAN so they have the home router network IP's


No idea.....I'm pretty certain I haven't got remote interrogation possibilities with the TPLink - I can only access it when on the customer site via the LAN IP address.

I think the TPLink statistics you see are after error correction, video playback will be sensitive to any buffering delay during error correction. I've fixed quite a few wireless bridges that have this problem.

 

[David]

is the radio link across land or water?

 

[RobotSystems]

Link is across land, straight line about 150m However, the base station is probably about 25m higher than the remote link.

 

[David]

25m is a lot of vertical separation, it may be possible that one or both antennas are just outside the main signal lobe. Can the antennas be raised or lowered to compensate (keep line of site clear)? an option would be to angle one slightly up, the other down. At the same time change any white ty-raps for black UV stable ones, white ty-raps perish in sunlight. Don't forget to take time to make sure the antennas are aligned properly.

As this is a P2P link I would also enable MaxStream TDMA at both ends, that will get rid of the 802.11a/b/g/n overhead baggage and latency.

I would also reduce the RF transmit power (keep both ends the same power level) until it just peaks at 5 bars. This will stop the receiver front ends being unnecessarily swamped and make them more responsive to link changes.

All the above will help optimise the radio link and give you a good fade (operating) margin for poor weather conditions.

I helped a farmer who used P2P radios to connect cameras back to the NVR. After months of frustration I left him with a stable workable system.