Hi we have a project with cctv poles, which we cannot finalize because of problems with conectivity. On nvr cameras are sometime show sometime not assuming because of loosing connection because of not good configuration.
Each pole have 2 x cctv IP dahua 5mp camera and sxt mikrotik sxt2 lite antena, connected in gigabit 5 port switch.Total 15 poles - 30 cameras
In base station house on roof we put 2 sector antenas - MikroTik RBD22UGS-5HPacD2HnD-15S, mANTBox 52 15s Dual Band Sector Antenna for position A and Position B.(left sector and right sector) and NVR for cameras connected in 8port gigabit poe switch.
Al antenna are on fix ip adress including cctv cameras.
Sector antena are configured as ap bridge(pic 1) , and sxt2 like station bridge(cpe - check pic 2)
Range of signal is from -60to - 75 db (what is working optimal and min/max range?)
Some antennas connect to sector antennas without problems, some connects and just disconnect from time to time (se picture 3)
some poles connect to sector antennas some just loose connection.
strange thing is when i connect on switch on sector antenna i se only 2 poles antennas even 7 poles work normal
anyone have any advice for setting up.
5 Mpix — near-UHD! — real-time streaming over wireless…who decided this was a good idea?
Are you making things even worse by doing something like MJPEG instead of H.265?
I think it goes through h265, I have to check. what is your suggestion about losing conectivty between antennas?
Your presumption is that you have a hardware failure, but my guess is that you have a hardware misapplication.
WiFi is a shared medium; the only way you get a clear spectrum is to move everything into an RF test chamber. Therefore, you should never do anything over WiFi that cannot withstand being interrupted and retried.
Real-time streaming allows neither of these. With 30 FPS video, every frame has to get across the link in 1/30 of a second or less, and if it fails, no amount of retrying will reopen that closed time window.
With MJPEG and similar protocols, frames are huge targets, making them easy to knock out. Streaming implies UDP, so there is no retrying, and each video frame must span many network frames. It is possible to drop one WiFi frame and prevent the entire video frame from decoding.
H.265 solves some of the bandwidth problem by introducing “P” and “B” frames that are much smaller, making them harder to kill, but the tradeoff is that one frame might depend on hundreds of those surrounding it in the stream. Knock just one tiny “B” frame out and you might prevent 5-10 seconds of video from being decoded. (300 frame GOP / 30 FPS = 10 seconds, giving 5 seconds average interruption for random blips.) Do this repeatedly, once every few seconds, and now nothing can be decoded correctly.
All of this is why the big Internet video services have moved to pseudo-streaming protocols like HLS over HTTP. The TCP layer adds retrying, and the HLS layer allows large (multiple-second) buffers that can be re-pulled at need. The downside is higher latency, which is why it isn’t common in the “CCTV” realm. (IPcam is a more accurate term here.)
Is there anyway you can physically tie together some of the devices on the same side of the water and thus reduce the number of RF connections.
Then you could possibly use 60Ghz connections for the transfer of ( better protocols indicated above ).