Page has been tested for compliance with INDUSTRY (not MS-only) standards, using the free, publicly accessible validator at validator.w3.org. Mostly passes.This page is a "leaf" on a tree with information about remote sensing. It is a leaf of the branch about putting an IP camera (a bit like a webcam, or CCTV) on your LAN, either for local viewing, or, if you want to "open the doors", viewing from afar across the internet.
If you are just getting started with using IP cams, you may want to visit an overview of using IP cams I have provided.
Ad from sponsor, only distantly related to viewing images from afar:
My basic FarWatch system only requires a PC which you are willing to leave running and an internet connection. For about $40 you can add hardware to monitor temperature at the premises. That is just a start. With FarWatch, you can monitor many, many things. And my ArduServer lets you do similar things for even less, if you can "drive" an Arduino.
But! Back to the point of this page: Information about a specific IP cam. (IP cams are like webcams, but they connect to a LAN via TCP as opposed to connecting to a single PC, e.g. via USB). Here you will find information specific to one camera... see my page with more general points about setting up IP cams.
I'm afraid that I am less than enthusiastic about this camera... and will not be putting as much effort into the final "polishing" of this page as I try to put into most of my pages.
I wrote "less than enthusiastic" at the start of generating this page from some rough working notes which were written as I "played" with the camera for the first time. I have to admit that there are numerous things that TP-Link got right. I saw that, as I wrote the review below. But I still feel that the camera is disappointing. I don't expect "top of the line" at $40... but I am still irked by nuisances, and omissions which seem sheer pettiness.
Price. I bought one new for $40 (8/16)
Image: Pretty good. Very good, at $40 for a new unit. And it offers IR illumination WITH an electromechanical "IR cut out" filter... so you get good results in the dark AND good colors by day.
It does... barely... what it says on the tin. Not a universal fact with IP cams... especially if you buy from some of the strange "no-rep" companies which come and go. TP-Link is a well established, "big", "recognised" company. Which is why the shortcomings of the camera were particularly disappointing. I might as well buy from the "no name" companies, who do... sometimes... delight with unexpected good performance. (I should add that one of my favorite cameras DOES come from TP-Link... the SC-3171G. What I've written in a page similar to this about the 4171G, a 3171G with pan and tilt, should show you that I like them.)
If I buy an old model, or one from a "no name" source, I buy with a certain amount of built in pessimism. Anything that works is a bonus.
I was surprised and delighted to find a TP-Link camera, new, at only $40. Perhaps I expected too much for the price.
I should have remembered the world we live in. Is it possible that TP-Link turned out this disappointing midget as a "teaser" to tempt newbies into the market? Give them a painfully basic camera, get them started, add a customer for TP-Link's "bigger" cameras to the books?
Or maybe there was a spat between the hardware and software divisions at TP-Link... I mostly like what I see of the hardware. Nicely styled (though a bit "delicate", but that might appeal to you. (And, unless there was a mistake in the mfg of my particular unit, you can't unscrew the "ball" of the ball and socket joint connecting the camera to the TP-Link supplied stand. (To attach it to the stand of YOUR choice.) An example of what I am seeing as a pattern of limitations designed into the "give them a taste... but no more than can be helped" device.)
As I said: Good image (at this price level... or in a camera costing twice what this did). Fixed focus lens. Reasonably sharp, even at 30cm. The electro-mechanical IR cut is, my view, important.
But... while the software does (just) meet the specs promised, there almost seems to have been a deliberate policy of excluding any "frill" that could be left out.
(In passing, more earned compliments: They supply an "extension cord" for the power supply. A "frill"! The basic power converter unit's cable is 140cm long... hardly stingy, but the "extension cord" gives you another 240cm. Good.... extending low voltage lines is safer than using extension cords with "household" voltages. The power supply accepts 100-240v AC, 50-60Hz. Another good!) Speaking of power: Note that this cam runs on NIVE volts (DC), not the 12v you might expect. (Pin positive. PSU supplied was rated 0.6A.)
In a major exception to the "no frills" charge, the camera offers a built in WiFi extender. (I haven't tested this feature.)
You may have guessed that I am irked by this purchase. Why the ire? The main reason is the failure of anyone at TP-Link to address a question I posted at the TP-Link forum...
http://forum.tp-link.com/showthread.php?90187-Snapshot-URL-for-NC220
I'm disappointed that the common feature, if present, wasn't explained in the generally good user guide. But it's a free world, and if TP-Link wishes, once, to sell me a lightweight camera, that's their right. But to not answer a simple question, save a customer struggles, while still their right, does nothing to build my affection for the brand.
The examples which follow assume that your camera is not using your LAN's DHCP server, but rather has a fixed local address of 192.168.0.254
Much can be done, just using your LAN. Certainly get all LAN based things working before you go on to attempt WAN access. When you are ready for that, the text here assumes that your router has an external, WAN, IP address which is known to the internet generally by means of, say, MyRouter.dyndns.org, by the magic of DDNS, or some other "dynamic directory name server" service.
If you have only one http server on your LAN, it can be at the standard port, 80, and you do not need to explicitly specify it. For the sake of the examples, we will assume that you camera has been put on port 81, so explicitly specifying a port can be illustrated. Just drop the ":81" which appears in many of the lines below if you are using the default port 80... or use ":80"... it will do no harm, and remind you to put the port in, if you go beyond one server. Which you would do if you added another camera, for example.
Default admin user name and password: admin/ admin. As helpfully noted on label on underside of stand.
Multiple accounts allowed, although I could find no significance in what group a user is in. Perhaps ordinary users can't change settings. Perhaps those opportunities are only available to "the" admin user. (I couldn't find a way to add any users to the "admin" group, or change the name of "the" admin user. I could, whew, change the administrator's password). I could find no way to allow simple viewing without log-in.
The NC220 I was using in September 16, when I went into System/ Mgmnt, told that a firmware upgrade was avail....
nc220_1.1.12_Build_160321_Rel.27531.bin
... it found it itself. A little worrying. I am quite capable of going places to look for firmware updates. I don't appreciate my camera going places without asking first.
But at least the process went smoothly.
Downloaded, installed over wired connection. Took maybe 5 minutes. Good "progress" bar to reassure me during process. Rebooted itself, asked for user and password.
The settings i'd made previously were intact! Hurrah!
Speaking of settings: There were two that seemed to be absent... typical of the "give them as little as possible" policy that seems to apply...
Suppose you don't want to use the built in microphone or IR illumination LEDs? Most cameras with that hardware give you a way to say "don't use these elements of the camera" in the software. If available in the NC-220, I couldn't find the option.
Petty? IR LEDs burn out, and they consume power, stressing the power supply. So if I don't need the night vision, I think turning them off "important". As for the mike: If I can't turn that off, I suspect that some of my LAN's bandwidth is being wasted on data I don't want.
More worrying... while you can say you don't want to use the cloud server or motion detection, even after you have "turned them off", the camera's log file still has entries like "Device disconnected with cloud server." and "Motion detection, get setting success". Hmmm.
(Forgive the random jumble of facts?....)
I'm pleased to say that everything I tried to do worked under Firefox... if it worked at all. I was thwarted in some areas, but fared no better with IE in those. Both need to download "stuff" (two sets of stuff) before they will work.
The first time you access the device with Firefox, you get a message: "The TP-LINK camera plugin is required. Please download and install the camera plugin and manually refresh the page or restart the browser. If the installed plugin doesn't work, please set your browser security settings to allow plugins." And a "A plugin is needed to display this content" message where you should eventually see your live view of what the camera sees. Unless you have paid close attention to the first message, you may be a little lost. Admittedly, you do have to click the "Download" button to proceed. Then, if you are alert, you will notice that Firefox has started a download. On 18 Sep 16, shortly afterwards, I found...
nonie_plugins_x86-2.7.6.msi
... in my download folder. That has to be run by you, by hand, and prompts responded to. I LIKED that the installer asked me WHERE I wanted to install the plug-in, even if I did allow it to use the default folder. (I've done this on a Windows XP and a Win7 box, by the way.) The plug in seems to be "signed" by TP-Link, another welcome thing. And then you may need to close and restart Firefox... or it may only be a matter of responding to a "do you want to allow this" question. And saying "Allow now" (but not in future, without new permission) or "Allow always", i.e. allow now, and don't ask again.
Particularly during setup tasks, I frequently got "Connection Error" in red in the LiveView pane. This was often cured just by refreshing the page. When I left the camera running... on a wired connection... it ran "propely" for days at a time.
Setting up the connection to the wireless network was (mostly) well implemented... It can be found on the Advanced/ Wireless Connection page. There's a button for WPS, but I haven't tried that. The camera scans for locally available WiFi, and presents a list. You then click on a service... and sit there wondering "what next?"... unless you notice the scrollbar, and move down the page to where you can enter the network password. (I THINK it will work via 64-bit, "open" authentication PSK-WEP. (On the Advanced/ Status page, I see a report that my connection is WEP protected.))
The first time I set the camera up to operate wirelessly, all went well. The second time I tried, on a different LAN, I got as far as clicking "connect" after selecting the WiFi service, and entering password, but then went into an extended "doing that" stage... nice little "things happening" icon in middle of screen... but it didn't go further. And getting back to a simple wired connection to the camera's innards was tedious... multiple power cycles, etc, needed.
When I eventually got "in" again, wired, I accidentally gave the wrong password for the WiFi... and got an "instant" message to that effect. Put RIGHT password in, and, this time, in less than 5 seconds, was told wireless set up. The camera has a nice(?) feature... if a LAN cable is plugged in, the camera talks to the LAN that way. And if you unplug it, the camera tries to switch over to using the WiFi.
I had a good Live View (over wired) running. Unplugged LAN cable. Image froze for about 5 seconds, and then, without even the usual "refresh" being needed, I had my Live View back again, over the wireless channel. This on a Win7 system.
Access across WAN...
You of course need DynDns set up. (The camera has a client for that, by the way, if you have no better way to keep your DynDns service appraised of your WAN IP address. (see other!)
In my NAT, I told the router about the device. (I put it on a port OTHER than 80, as I have several web-servers available to the WAN.) I specified TCP only)
That went smoothly. Can it be that I am FINALLY getting the hang of these things? If you haven't "played" with them previously, don't be down-hearted! There are a LOT of "bits" to get right. And one typo, anywhere... Sigh.
Worked fine over LAN. (Apart from being slow (20 seconds?) to deliver "live view" at first, almost every time I re-established a connection.)
Over WAN... got "in" to camera easily enough... but had trouble establishing connection for live-view. Kept getting "connection error"... or just a black panel, until I scrolled a bit, at which point red "connection error" appeared in middle of black panel. Tried MANY things to fix this... on first system I tried it on: no joy. And, to date, several things on a second system. Both systems with many other IP cams of various brands working just fine.
A welcome exception to my "no software frills" complaint: The camera can access a timeserver, to reset its internal time- of- day (and date) "clock" when it comes up after a power interruption.
Offers on-screen device ID (user spec'd text) and date/time stamp... you set these on the "Advanced/ Video" page. I've not yet played with the FTP and email options... I hope the added text appears in the images sent by those means.
Two things- motion or sound- are supposed to be able to trigger one or both of two results: The FTP'ing or the emailing of images. You tell the camera what to do when a trigger is "pulled" on the Advanced/ Notification Delivery page. (A theme is developing here, I hope you notice: The interface seems to have been worked on by people who are fluent users of English. The same is true of the supplied "getting started" guide, and the online "manual"... which is a pretty dull tour through the menus... but "dull" mainly because the menus are pretty clear anyway.)
I had a glance at the setup page for email... it's on "Advanced/ Notification Deliver". Put a tick in the "email" as a delivery channel and sensible fields appear. Thing is, I don't know who can get into my IP cam, and I don't have a "throw-away" email account to play with at the moment, so I haven't tested that option.
I do, however, have a non-critical FTP server on the LAN the camera is on, so I set up an account for it on the FTP server.
Once the new user was set up on the FTP server (Filezilla), I tried to configure the camera to send to that...
Most things I did what seemed "obvious" to me.
For "Path", I specifiec "/ByMot", as I was going to use the camera's motion detection to trigger FTP events. (The folder did not yet exist... I wanted to see if the camera could trigger the creation of it.)
The "passive mode" box was not ticked, I left it thus.
The camera... thank you, TP-Link, has a "Test" button as part of the FTP setup. Tried that. Got "FTP server authority limits. Please check your server", a helpful message. (This was one of several good "that didn't work" messages I saw over the course of hours of trying to make this work.) Made me think that my assumption that it would be best to create the /ByMot folder by hand, at the FTP server, was correct... but also suggested that the camera might have created the folder for me, if the user wasn't one of limited authority.
After providing the system with the folder, the response the first time I clicked the "Test" button was....
FTP server settings updated successfully.
... (the only poor feedback message I encountered) and a file called "test_xxxx" was created in the folder on the FTP server, where "xxxx" was a date/time stamp, based on the camera's idea of "now". (Which was wrong, which was disappointing, as the "fetch and set time from server" feature worked in the other environment I tried this camera in. 0.pool.ntp.org worked from a physical address in the USA, 9/16, but not from one in the UK. Changing the server to time.nist.gov (saving that, and rebooting the camera) worked no better. Nor did time.windows.com work from a UK location. Happily, you can, unlike some cameras, enter URLs not provided for in the convienent pull down of some of the servers out there. When I set the URL to 130.88.200.4 (currently, and for some time to come, I hope, the IP address of a public time server at the University of Manchester, one of the cradles of the Computer Age.) The test file was an image taken by the camera.
(A little aside, which doesn't apply to this camera: Some camera's test routine saves a file with a fixed name. If you haven't given the FTP user authority to delete files, the test will not succeed a second time, until you, by some other means, delete the first test file. Nor do cameras always safe an image when "merely" testing the FTP settings.
Now that an FTP service was available, I went to the camera's Advanced/Motion Detection settings page. Alas, I could only get into the FTP server if I used a LAN address... 192.168..., not via a perfectly good WAN address managed by a reliable DynDNS service.
Even masking can be set up via FireFox... good! Puts this camera ahead of the pack of older cameras I am more familar with. (They often require you to use Internet Explorer for setting masks).
You should see what the camera is currently seeing, divided into 12 rows of 16 columns. Probably it will look as if the scene is "foggy". Drag with the mouse, and some squares can be made to give a clear view of what's there. These will be the squares in the scene NOT "watched" by the software... motion in the "foggy" (cyan tinted) squares will trigger an FTP capture.
Besides area masking, you can choose one of three levels of sensitivity.
There doesn't seem to be any way to "watch" the motion detection, to see when motion is detected. (Other than, of course, watching the folder on the FTP server to see if images arrive.)
Here's a cute little "gotcha", "thank you" (ironic) TP-Link. You must give the FTP user authority to create folders within the "destination" folder, because: It starts a new folder each day, and within that a new folder each half hour of the day. (I got a folder named "0030" when the camera's time was between 00:30 and 01:00 at the time the saves took place, a folder called 2000 for images from between 20:00 and 20:29, etc.) This "folders in folders" behaviour is not explained in the manual. I don't think you can turn this off. I don't find the proliferation of folders a helpful feature, and in fact it will prevent me from using the camera with a program I use with many other cameras which periodically fetches the newest image from a camera's folder- singular.
I don't think you can send the images to a static filename, continually over-writing any older image. The camera seems to send a "burst" of 4 images to the server if motion is detected. You can't say "only watch for motion between 17:30 and 07:30 (when the shop is closed), or at weekends.") you can't say "If you've recorded 10 images in the past 60 seconds, "go to sleep for xx minutes before taking more".
Yes... to ask for ALL of these in a budget camera is unreasonable. Is it too much to ask to have at least SOME of them present?? These things are just software matters, and not "new" ideas.
Here and elsewhere, be careful to save the settings you specify, as you go along, using the "save" buttons provided. The TP-Link interface gives feedback, e.g. "Settings Saved". Thank you TP-Link.
I haven't played with the sound detection yet
Half of me is feeling a little guilty for being so negative about the camera. I have to admit that the interface is "clean", "intuitive", and gives good feedback, by and large. And I have to admit, it does have a few features beyond the barest minimum. But I also still feel that it really doesn't deliver what it should, even as a budget camera. Worse... I will be hard pressed to use it for much in the wider context of how I use my IP cams. This latter fact isn't entirely TP-Link's fault... but some of the choices they made in "locking down" lots of options present in many cameras, both older and cheaper, has left it a poor choice for my wants, sadly.
The reluctance of Live View to "deliver", until the URL has been accessed a few times, or until about 20 seconds after initial "contact" remains a common problem. Perhaps a coincidence, but while working on this essay, with the NC-220 running in Firefox, I have repeatedly been refused access by my web hosting service when I try to use Filezilla (Client) to upload changed pages. (The Filezilla SERVER which receives the images from the NC-220 (and many other cameras) is running on a different machine on the LAN.))
This camera does not, as far as I recall... do tell me, if I am wrong!... offer digital inputs or outputs. (Some cameras can be made to take a picture, store it, send it, etc, upon a signal from some external device. Another things some have is a digital output, to, say, turn on an alarm bell if motion is detected. I offer a page on the general considerations of digital inputs and outputs on webcams.
Page has been tested for compliance with INDUSTRY (not MS-only) standards, using the free, publicly accessible validator at validator.w3.org. Mostly passes.
AND passes...
