I want to integrate quite a few IP Surveillance cameras to a dedicated PC (one that is unused at our office), I have looked at purchasing a NVR but I want to add about 16 overall and not many NVRs are capable to handle this amount if cameras.
Has anyone tried to setup a monitoring unit on a PC with IP cameras, did you use any specific software? How many HDD did you use?
Thanks for any replies
To build an effective IP securitysystem you will need the followings:
1. Broadband Internet connection:
Stable Internet connection is essentially needed.
2. One or more IP camera(s):
According to the specification of the camera you have mentioned, the IP camera you want to use is ONVIF-compliant.
(Quoting from onvif.org, ONVIF, that is Open Network Video Interface Forum, is an IP-based security standard: it is an open industry forum for the development of a global standard for the interface of IP-based physical security products. The ONVIF specification defines a common protocol for the exchange of information between network video devices including automatic device discovery, video streaming and intelligence metadata.)
The ONVIF standard ensures that there are interoperable products on the market, no matter what happens to individual companies. It increases flexibility and gives greater freedom of choices in case of developing an existing or creating a new surveillance system. Integrating a new equipment into the system takes only a little time.
3. PC:
In order to use your IP cameras with your PC you need to connect both of them to the same network. The best way to get the most out of your cameras if you install a camera viewer application or an IP camera device manager on your PC. By using such a device manager (or a simple camera viewer application) you can display the image of your cameras on your dedicated PC - even the image of multiple cameras simultaneously. You can find many device managers on the market that can be used to connect certain amount of cameras into one security system (this capacity depends on the product).
After connecting the cameras to your system, due to the ONVIF specification, you can control your surveillance system with the help of such useful functionalities as automated device discovery, video analytics, web-broadcasting, motion detection, PTZ control, etc.
NVRs vs. video recorder software
If you can not find any NVR on the market that is able to handle as many IP cameras as you want to use, a video recorder application can solve your problem. If you are not averse to C# development, you can take a look at this Codeproject article (How to Create a Video Recording Application (NVR/DVR software) for an ONVIF IP Camera using C#.NET) that demonstrates step-by-step how to implement a video recorder application that can be used on your PC and that is able to record and save camera videos without using any dedicated device. This way you can avoid using any NVR or DVR.
I hope I helped you to get started!
Related
I have a client with a 1-2 thousand viewer audience, with everyday streams, same concurrent number of viewers.
Ive got a server set up for their website etc, but am in the process of figuring out the best way to stream with OBS onto that server, and than re-distribute that stream to clients (as an embed on the website).
Now from the calculations i did, running that kind of concurrent viewers is very problematic, as it forces you into a 10gbit link - which is very expensive, and i would ideally like to fit within 1-2gbps, if possible.
A friend of mine recommended to look into "Multicast" which supossedly uses MUCH less bandwith than regular live streaming options. Is multicast doable? Ive had a NGINX live stream set up on my server by a friend before, but never looked into the config and if multicast is supported within that. Are there any other options? What would you recommend?
Also, the service of that live stream isnt a high profit / organisation type of deal, so any pre-made services just dont make sense, as it would easily cost 40+ dollars per stream, which is just too much for my client.
Thank you for any help!
Tom
Rather than Multicast, P2P is more practical solution on Internet, to save money not bandwidth.
Especially for H5 browser, it's possible to use WebRTC DataChannel to transport P2P data.
But Multicast does not work on internet routers.
Multicast works by sending a single stream across the network to edge points where clients can 'join' the multicast to get an individual stream for them.
It requires that the network supports multicast protocols and the edges align with your users.
It is typically used when an operator has their own IP network for service like IPTV, rather than for services over the internet.
For your scenario, you would usually use an organ server and a CDN - this will usually reduce the load on your own server as the video will be cached on the network and multiple user can access the same 'chunks' of the video.
You can see and AWS example for on demand video here - other vendor and cloud providers have solutions too so this is just an example:
https://docs.aws.amazon.com/AmazonS3/latest/userguide/tutorial-s3-cloudfront-route53-video-streaming.html
You can find more complex On Demand and Live tutorial also but they are likley more that you need: https://aws.amazon.com/cloudfront/streaming/
Exploring P2P may be an option also as Winton suggests - some CDN may also leverage P2P technology internally.
I'm looking into how one would create a network of embedded systems. What I'd like to achieve is for a device (basically a chip with network capabilities) to directly send data to a server but not use the internet(tcp/ip) or cellular data(like GSM etc).
I don't have much expertise in this field. Most of the networking protocols I've seen like ZigBee are designed for a Local Area Networks. Wide Area Network can be achieved perhaps over mesh or hoping etc. But is there a known protocol for long range networking, say for sensors, assuming there aren't low power constraints?
I am guessing you want to avoid the internet and GSM, not because you have anything against the protocols but because you want your solution to work without having to rely these networks.
If so then you don't have to rule out TCP/IP as this can be used in private networks also.
From your description it sounds like the closest thing that would meet your needs would be a satellite based communications system. So long as you are not worried about price, power and to a certain extend size, then your sensors can communicate from anywhere using satellite links.
There are also HAP - High Altitude Platforms. These are essentially like low flying Satellites, or high flying planes/blimps, so don't have the same coverage but need less power for a given communication bandwidth. If you search for 'High Altitude Platform Networking' you should find plenty of examples such as the following which is an up to date summary of the technology at the time of writing:
http://www.scielo.br/scielo.php?script=sci_arttext&pid=S2175-91462016000300249
As mentioned above, many if not all of these systems will support IP based communication protocols on top of their lower layers. Unless you really have some issue with the protocols themselves, it seems sensible to use them as there is such a wealth of experience, tools etc associated with IP communications, and using them does not make you dependent on the wider 'Internet'.
Its also worth mentioning that a common pattern is to have local groups of sensors communicate with each other and or with a gateway and the gateway then communicate over the long link back to your server. This allows the individual device be smaller, cheaper, lower power etc. This may not match your requirements if you are not likey to have clusters of sensors, however.
If you search for satellite sensor networks you may find you get a lot of hits for the gateway case mentioned above. This article 'A Survey of Architectures and Scenarios in Satellite-Based Wireless Sensor Networks: System Design Aspects' looks to be a good overview which includes HAPs also and it is available to download form this site at the time of writing:
https://www.researchgate.net/publication/250003254_A_Survey_of_Architectures_and_Scenarios_in_Satellite-Based_Wireless_Sensor_Networks_System_Design_Aspects
I would look into LoRa which is designed with these requirements in mind.
You still need infrastructure for that (gateways, network servers), you could roll out your own or (in urbanized areas) use pre-existing one like TTN.
The choice of networking technologies depends on many factors, such as range, power constraints, bandwidth requirements and so on.
User Raber already pointed out that you could look into LoRa / LoRaWAN. Since nobody else mentioned it yet, my suggestion is to also have a look at SigFox technology, which is slightly different from LoRa in what it offers and their business model.
I'm looking to establish a connection between my laptop and a remote PC in such a way that I can ping other devices connected to one of its network cards from my laptop.
That might be a little unclear- let me be more specific:
I am a PLC programmer, and my company just migrated to a brand of PLC that requires individual software licenses for each "station." So we're not going to be spending the money for the programming software at each location- instead, each technician will have a laptop, and he can physically visit whichever location needs troubleshooting.
However, that gets to be a lot of travel (international, in some cases), and I'm looking to come up with a way (using a VPN or something) so that I can connect to a PLC remotely.
Our setup is a Windows 7 Industrial PC at the customer's location with two network cards- one is hooked up to the customer's network (and the internet), and the other is hooked into the various PLCs, all with static IPs in the same range. I'm trying to minimize the amount of software I'll have to install/purchase for this project- we already use Teamviewer, but its VPN connection doesn't seem capable of accomplishing what I want (at least, I've never been able to manage a successful ping to one of the PLCs, no matter how much I mess with settings, and their support consists mainly of "buy our newest version").
I've seen lots of posts about this kind of stuff on the internet, but a lot of it seems directed to people who either already know how to set this stuff up and just want to know which software is cheapest, or it is specific to the brand of PLC (I'm using Lenze, which is not very common in english-speaking countries, or at least in america).
Anybody who has managed something like this- I'd really appreciate some sort of walkthrough, or at the very least some pointers in the right direction.
VPN is for TPC/IP communication. Whenever you need layer 2 from ethernet, you're stuck. I know that Step 7 TIA from Siemens can not find for PLCs via VPN. Explaination from support is that searching goes via layer 2. And this list can be made longer.
Most brands can now handle programming via memory cards. Just program local, write it to a memory card and plug it into your PLC.
Just contact the companies and see what they have to offer. The times are still here that PLC brands are fighting for customers. Let them do the work for you and enjoy. It works for our company. :)
We're about to design an inhouse industry network consisting basically of the following: 1 server connected via wire to up to 100 proprietary RF access points (basically embedded devices), which each can be connected via radio to up to 100 endpoint embedded devices. Something like this:
Now, I'm wondering about some design decisions that we need to take and I'm sure there are plenty of similar designs out there and lots of folks with experiences of them, both good and bad. Maybe you can chime in?
All endpoint devices are independent and will communicate their own unique data to the server, and the other way around. The server therefore needs to be able to target each endpoint device individually. Each endpoint device pairs itself with 1 access point and then talks a proprietary RF protocol to it, TCP/IP is not an option there.
The server will know which endpoint device is paired with which access point, so when the server needs to talk to an individual endpoint device, the communication must go through the paired access point. Hence, the server needs to directly address the access point.
Question: Considering the limited resources available in the proprietary access point, is TCP/IP between server and access point recommended for this scenario? Or would you suggest something entirely different?
I find the diagram confusing:
If this isn't its own network and the server to AP link is running on your internal company network, there isn't really an option, there must be a TCP/IP stack on the AP.
If this is its own isolated network then what is the router for?
If this is, in fact, its own isolated network then you are right, there really isn't a need for the Ethernet connectivity at all. The overhead you will see on the wireless is huge, your no overhead ideal data rate is 250kbit/sec, running ZigBee on 802.15.4 # 2.4ghz point to point your real data throughout is usually around 20kbit/sec. A custom protocol should be able to obtain lower overhead but this would need to be defined.
If I were designing this I would choose a SoC for the AP that had on board 802.15.4 and CAN (Controller Area Network). Depending on size and data rate just get a PCI CAN card for the server and connect it up, use something like DeviceNet as your protocol layer for server to AP communications. This can be expanded by using CAN switches and repeaters. CAN is used all the time in industrial automation, a little googling can find you example of tens of thousands of nodes used in some manufacturing plants.
There are small TCP/IP stacks, for example LwIP.
You didn't mention the amount of data to be communicated, or bandwidth considerations?
A 3rd party TCPIP stack targeted at the 8051 would simplify all the networking issues with connecting 100 units. You probably will still end up with a proprietary protocol that sits on top of the tcpip stack but then it is just simple point-to-point communication between the server and each end point.
What all would be the requirements for the following scenario:
A GSM modem connected to a PC running
a web based (ASP.NET) application. In
the application the user selects a
phone number from a list of phone nos.
When he clicks on a button named the
PC should call the selected phone
number. When the person on the phone
responds he should be able to have a
conversation with the PC user.
Similarly there should be a facility
to send SMS.
Now I don't want any code listings. I just need to know what would be the requirements besides asp.net, database for storing phone numbers, and GSM modem.
Any help in terms of reference websites would be highly appreciated.
I'll pick some points of your very broad question and answer them. Note that there are other points where others may be of more help...
First, a GSM modem is probably not the way you'd want to go as they usually don't allow for concurrency. So unless you just want one user at the time to use your service, you'd probably need another solution.
Also, think about cost issues - at least where I live, providing such a service would be prohibitively expensive using a normal GSM modem and a normal contract - but this is drifting into off-topicness.
The next issue will be to get voice data from the client to the server (which will relay it to the phone system - using whatever practical means). Pure browser based functionality won't be of much help, so you would absolutely need something plugin based.
Flash may work, seeing they provide access to the microphone, but please don't ask me about the details. I've never done anything like this.
Also, privacy would be a concern. While GSM data is encrypted, the path between client and server is not per default. And even if you use SSL, you'd have to convince your users trusting you that you don't record all the conversations going on, but this too is more of a political than a coding issue.
Finally, you'd have to think of bandwidth. Voice uses a lot of it and also it requires low latency. If you use a SIP trunk, you'll need the bandwidth twice per user: Once from and to your client and once from and to the SIP trunk. Calculate with 10-64 KBit/s per user and channel.
A feasible architecture would probably be to use a SIP trunk (they optimize on using VoIP as much as possible and thus can provide much lower rates than a GSM provider generally does. Also, they allow for concurrency), an Asterisk box (http://www.asterisk.org - a free PBX), some custom made flash client and a custom made SIP client on the server.
All in all, this is quite the undertaking :-)
You'll need a GSM library. There appear to be a few of these.
e.g. http://www.wirelessdevstudio.com/eng/
Have a look at the Ekiga project at http://www.Ekiga.org.
This provides audio and or video chat between users using the standard SIP (Session Initiation Protocol) over the Internet. Like most SIP clients, it can also be used to make calls to and receive calls from the telephone network, but this requires an account with a commercial service provider (there are many, and fees are quite reasonable compared to normal phone line accounts).
Ekiga uses the open source OPAL library to implement SIP communications (OPAL has support for several VoIP and video over IP standards - see www.opalvoip.org for more info).