PeteCress

Thanks... it's coming back to me now. Bottom Line: There is probably no camera that will get than kind of resolution/shutter speed at a 4mm focal length and zooming in is the way to do it. That being the case, I need to forget about this because license plate recognition (especially in just one part of the lot) is only part of the requirement. The main requirement being to see what is going on in general at the given (4mm) field of view. Sounds like somebody serious about this would have two cameras: - Fixed 4mm for the big picture - Auto PTZ with software to acquire, track, and zoom on moving objects. Have I got it right?

Strictly an effort at due diligence. People keep asking me about my IP cam setups and I keep saying that the only thing I know is Blue Iris - and would recommend it as long as the person is willing to cope with technical details and provide a PC with enough horsepower for the number of cams they plan to use. The IP-cam-only approach occurred to me the other day while I was exploring the UI on a new cam..... And I thought I had better have a reason for recommending that somebody spend sixty bucks on BI and, maybe, whatever it costs for a dedicated PC instead of just using the camera's built-in functionality. So far, my little experiments have been limited by the cam's motion detection: haven't figured out how to get a useful degree of sensitivity - getting too many trigger events regardless of sensitivity setting specified. The other solution that I have had in the back of my mind since bringing a previous PC to it's knees with too many cams on BI is ACTi's cam server: only works with ACTi cams, but claims to offload all the heavy lifting (mainly motion detection, I guess) to the cams making it usable (they claim) with more cams on less PC.

I have seven IP cams at two remote sites. Their main function is to let customers of a windsurfing shop check on conditions themselves instead of constantly calling the shop owner. But a couple of the cams also serve a security function off-hours. I have become partial to having my cams take 5-minute clips back-to-back 24-7 and also having the the cams that serve a security function take still snapshots at on-second intervals when motion is detected. This works for me because: BlueIris FTPs the Snapshots to my home PC where I can use JPegView to quickly review them and, if I want more info, I can view the relevant clip remotely. . Shop customers can peruse the Clips online to see what's been happening in prior hours . If something happens at the site where Snapshots/Clips are being generated (as vandalism or a repeat of hurricane Sandy) testing suggests that I will get snapshots right up to the last moment - whereas there may be some doubt about getting the current 5-minute Clip especially if the Clip is terminated by the vandalism or the vandalism includes cutting the Cat5 between cameras and the radio that links them to the server a kilometer away (which has already happened once). Right now, both Clips and Snapshots are 1280x720 - which gives acceptable detail/motion without kicking the brains out of bandwidth (other people are watching the cams remotely). The HikVision DS-2CD2032-I cams are served by Blue Iris and the other viewers use Blue Iris's web interface to see the cams. What would be attractive is keeping the Clips at 1280x720, but having the snapshots taken at some higher rez - the higher the better. Is this just a matter of buying the right cams and setting them up properly? Or would I trying to fool Mother Nature?

One thing I am hoping for (only hoping...and not too much...) is that the eyeball cam's placement of IR emitters next to the lens instead of in a circle around same may mitigate the spider problem - at least a little bit....

Interesting. I had glanced at those but, because of how they looked, just assumed they were indoor cams and did not even read the specs. It looks like the IR source is concentrated in that little square instead of being distributed in a circle around the lens. Any idea of how that looks at night? i.e. is the red glow significantly brighter than the glow of the circular LEDs? Clearly easier to adjust - and with no concerns about leaving finger prints on the dome. Can somebody who is using these chime in? Edit 2015 04-27 11:16: Oops! Looks like there is already a thread: viewtopic.php?f=19&t=39148&start=15 Edit 2015 04-27 12:41: Just pulled the trigger on two 2.8's from NewEgg and one 4.0 from AliExpress.

Got it..... But the scenario is a break-in where the first thing the perpetrators see is the old laptop that is serving as a cam server, walk over to it, yank the power cord and steal it. This would be mitigated at least in part by the laptop's having a functional battery, being connected to the LAN via WiFi, and therefore having some more time to do it's thing even while being stolen. In that case, my little fantasy is that the laptop's cam (one of the three cameras in use) gets a series of snapshots of the guy's face reasonably close-up. Putting a stopwatch on the FileZilla FTPs, I get .JPGs within seconds of the trigger, but when I force MP4's because of their larger size, can take up to several minutes - dependent, of course, on the length of the clip. The bottom line being to have FTP's of at least a few clips before the laptop goes offline. This will all become moot if/when I establish that BlueIris really cannot FTP Clips... only Alerts.... -)

Setting up BlueIris for a friend's house, I was trying to figure out why BI was FTP-ing Alert .JPGs a-ok, but not FTP-ing video Clips at all. But then it started to dawn on me that a bunch of .JPG Alerts snapped every second were pretty much all one could ask for from a surveillance perspective. Just open up something like JPEGView, hold a finger on PageDown, and you've basically got a 1 FPS (assuming that's how the clips are timed) video. That being true, why even bother with video Clips? What is the flaw in my thinking?

I've been through a few of Home Depot's bundled lights/motion sensors and the quality seems spotty. A couple are unduely sensitive to cold - tripping for no apparent reason when the temp drops. Others, same make/model, are OK in one unit and non-functional in another. I'm thinking maybe buy separate sensors and put together my own light/sensor systems. I am guessing there are other options that have better quality control and are not cold-sensitive, but are they realistic for the homeowner?

A couple of HikVision DS-2CD2032-I's. When I ping and/or do a NetScan, they seem to be there one minute and not the next. Also, they should be exposing ports - which NetScan says are not being exposed. Devoid of any real knowledge, the best I can come up with is dirty connections (salt-water environment) and I'm going to drive down there on Wednesday with a ladder, some contact cleaner and a tube of dielectric grease. Until then, can anybody hazard another guess? Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved. C:\Windows\system32>ping 10.0.0.145 Pinging 10.0.0.145 with 32 bytes of data: Reply from 10.0.0.145: bytes=32 time=4ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Ping statistics for 10.0.0.145: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 1ms, Maximum = 4ms, Average = 1ms C:\Windows\system32>ping 140.0.0.146 Pinging 140.0.0.146 with 32 bytes of data: Reply from 202.73.96.125: TTL expired in transit. Reply from 202.73.96.125: TTL expired in transit. Reply from 202.73.96.125: TTL expired in transit. Reply from 202.73.96.125: TTL expired in transit. Ping statistics for 140.0.0.146: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), C:\Windows\system32>ping 10.0.0.146 Pinging 10.0.0.146 with 32 bytes of data: Request timed out. Request timed out. Request timed out. Request timed out. Ping statistics for 10.0.0.146: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved. C:\Windows\system32>ping 10.0.0.145 Pinging 10.0.0.145 with 32 bytes of data: Request timed out. Request timed out. Reply from 10.0.0.145: bytes=32 time=1008ms TTL=64 Reply from 10.0.0.145: bytes=32 time=3ms TTL=64 Ping statistics for 10.0.0.145: Packets: Sent = 4, Received = 2, Lost = 2 (50% loss), Approximate round trip times in milli-seconds: Minimum = 3ms, Maximum = 1008ms, Average = 505ms C:\Windows\system32>date The current date is: Mon 12/15/2014 Enter the new date: (mm-dd-yy) C:\Windows\system32>time The current time is: 16:28:00.93 Enter the new time: C:\Windows\system32>ping 10.0.0.145 Pinging 10.0.0.145 with 32 bytes of data: Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.145: bytes=32 time=4ms TTL=64 Ping statistics for 10.0.0.145: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 4ms, Maximum = 4ms, Average = 4ms C:\Windows\system32>time The current time is: 16:28:20.73 Enter the new time: C:\Windows\system32>ping 10.0.0.146 Pinging 10.0.0.146 with 32 bytes of data: Reply from 10.0.0.146: bytes=32 time=5ms TTL=64 Reply from 10.0.0.146: bytes=32 time=2ms TTL=64 Reply from 10.0.0.146: bytes=32 time=1ms TTL=64 Reply from 10.0.0.146: bytes=32 time=4ms TTL=64 Ping statistics for 10.0.0.146: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 1ms, Maximum = 5ms, Average = 3ms C:\Windows\system32>time The current time is: 16:28:42.58 Enter the new time: C:\Windows\system32>ping 10.0.0.146 Pinging 10.0.0.146 with 32 bytes of data: Reply from 10.0.0.146: bytes=32 time=3ms TTL=64 Reply from 10.0.0.146: bytes=32 time=1ms TTL=64 Reply from 10.0.0.146: bytes=32 time=1ms TTL=64 Reply from 10.0.0.146: bytes=32 time=10ms TTL=64 Ping statistics for 10.0.0.146: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 1ms, Maximum = 10ms, Average = 3ms C:\Windows\system32>time The current time is: 16:28:59.34 Enter the new time: C:\Windows\system32>ping 10.0.0.145 Pinging 10.0.0.145 with 32 bytes of data: Request timed out. Request timed out. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.33: Destination host unreachable. Ping statistics for 10.0.0.145: Packets: Sent = 4, Received = 2, Lost = 2 (50% loss), C:\Windows\system32>

Does anybody keep track of numbers for the purpose of evaluating performance and assisting in resolving problems when they occur? In this case, there is a radio link involved. I'm thinking: Date/Time of observations (Duhhhhh....) . FPS for each camera . A one-word description of how the motion is (Poor, Fair, Good, Excellent) . Results of running LAN Speed Test from the remote/camera site to the server site. (LAN Speed Test being a utility that reads/writes data across a network and comes up with average speeds for Reads and Writes) . Signal Strength from the perspective of remote site's radio . A couple of "Quality" numbers from the radio link software (Ubiquiti Nano Loco M5). Bottom Line: If you track numbers, what do you track?

It was the radio link (Ubiquiti Nanostation Loco M5's). Fooled around changing bandwidth from 30 back to 40, raised/lowered the signal strengths... managed to lose the connection totally a couple of times... Finally came back to original settings and re-booted the AP radio. All cams now online. Lessons Learned: Radio link problems *can* be camera-specific. I have no clue why, but that seems to be the case. . One of the first things to do in a case like this is to re-boot the radio links. Kind of like troubleshooting a Windows PC issue: when in doubt, re-boot.

Yes. Yes and no. Two are longer, the other's is about the same as the TrendNet's. But, to cut to the chase, when I connect the switch directly to my laptop, no problems. The ping Replies just keep rolling down the window - as opposed to http://tinyurl.com/l4fsv3x (the one on the right being the TrendNet). TrendNet (not tb confused w/cam of same name) Model TPE-S44 (4 POE ports, 4 regular ports). I swapped it out for a more recent model whose power supply is 1.5 amps instead of the TPE-S44's .8 amps thinking I had struck gold when I noticed the diff in power.... but no change. I am now pretty sure that it's only over the wireless because of the direct-connect-to-laptop described above. But there's a zinger: when I got down there all 3 cams were running A-OK. This seems coincident with my having somehow provoked the Comcast cable modem into putting the camera server on a "Parental Control | Managed Devices" list as a blocked device - which took it offline WAN-wise, but left it working on the LAN. Again, I thought I had struck gold..... but after flipping that setting back-and-forth a few times, I have been unable to replicate the situation. All I see on the Nano setup is Services | System Log | Enable, but when I set Enable = True, all I get by clicking Main | Log are these 3 very old entries: System Log May 28 12:55:15 system: Start May 28 12:55:16 FileSystem: Start check... May 28 12:55:34 FileSystem: End check. I will let it cook for a few hours - or even overnight - and post anything that turns up. an Edit (3 hours later): Same 3 log entries. I am guessing there is another logging facility that I have not found yet.

I have to retract that statement. After watching pings to all 3 cams in parallel for about 20 minutes, I see that the patterns are similar - with 30-33 Replies interspersed with a few "Timed outs" and "Unreachables".... So the lists align every so often and then slowly precess out of phase depending on 30 or 33 Replies and minor variations in # of Timed Outs and Unreachables.... eventually drifting back into synch or near-synch every so often. viz: http://tinyurl.com/nz8oq3x http://tinyurl.com/l4fsv3x So it looks to me like we are back to the idea of the cams re-booting and the boot sequences being the same in terms of Replies/Timed Outs/Unreachables. Next time I go down, I'm going to blindly swap out the POE switch - without worrying about why the TrendNet is not showing any problems.

You have convinced me. I was missing the immersion-vs-jacket concept. Got a problem installation where cleaning every contact and adding the grease got 3 cams back online..... for about 3 hours..... and now they're offline again. Next time I get down there, I will swap out the POE switch, clean the grease off the plugs, and try sealing each port with silicone.

I'm coming around to thinking that, in a seashore environment - even indoors - it's a no-brainer to fill every RJ-45 receptacle with dielectric grease. Aside from the messiness and cost of the grease, is there a downside to this?

Hoping to stave off recurrences of the likes of this: http://tinyurl.com/ppahkcp by virtue of the salt air not being able to get to the contacts because of the grease. Silicone seems like a one-shot deal: once it's done, that receptacle isn't going to be used again. Also I do not know if it would interfere with the contacts touching electrically.... OTOH with dielectric grease electrical contact is generally assumed to be OK and I'm thinking that maybe there's some hope of re-use with enough CRC cleaner and TLC.

Thanks for that one!.... the -t is *really* useful. Went down there today, did the -t thing locally to take the radio link out of the picture and they just ticked along.....no problem. OOPS!.... how could a radio link problem be camera-specific??? So I did it again, only with the radio link in the picture.... -t on the cam server PC a half mile away instead of on the shop PC. Oops again... It also worked perfectly, ping-after-ping on both cams. I'm pretty sure my mistake was forgetting to do the shop/server ping comparison before wiggling cables. Bottom line, I cleaned every connection and slathered it with dielectric grease and all seems to be well. In fact, a couple of the RJ-45 plugs were so nasty that I just cut them off and re-terminated. For the sake of people searching for info about use of dielectric grease at later times, I will start a separate thread with that in the subject line. Edit 2014 12-17: After about three hours of running A-OK, three of the cams have reverted to being intermittently unreachable - although the pings look much, much better than they did before all this. Long runs of "Reply from.....with 1-2ms times". And, what's probably informative is that the Replies/timeouts/unreachables seem to be in some sort of synch between all 3 problem cams: I've got three console windows open with a Ping... -T running against each camera and the Replies, Timeouts, and Unreachables are pretty much in parallel. It's as if something in the POE switch or above is injecting something harmful to communication into the system. But what's boggling my mind is that a fourth camera - on the same POE switch - is getting 100% good replies.... viz: http://tinyurl.com/ouqrd95. So much for the "injecting something harmful hypothesis".... Now I'm *really* confused.... I think it's time for Yours Truly to dig into the POE (802.3af) thing and see if maybe the problem cameras (HikVision DS-2CD2032-I's) are one standard and the "Good" camera (TrendNet TV-IP67wP) is the other standard. On one hand, the theory about the cams' rebooting bco faulty connections seems supported by the improvement (but not total cure) following connection cleanup/retermination. OTOH, it would seem to beg the question of why the camera's good/bad responses are so well synchronized.... unless that's pointing to a connection problem further upstream than the camera/POE switch connections.... some common element like the POE switch's connection to the radio... or even the server end's connection it it's radio.... ??? Edit 2014 12-17 19:56: Nope... looks to me like both the problem and "Good" cams are 802.3af.

The "Active/Passive" is above my current pay grade... but I will dig in to it later. Hopefully cleaning contacts tomorrow will resolve this. Dunno if "Pattern" is too strong a word, but there is a certain repetitious nature to the Ping responses: C:\Windows\system32>ping -t 10.0.0.145 Pinging 10.0.0.145 with 32 bytes of data: Request timed out. Request timed out. Request timed out. Request timed out. Request timed out. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.33: Destination host unreachable. Request timed out. Reply from 10.0.0.145: bytes=32 time=1003ms TTL=64 Reply from 10.0.0.145: bytes=32 time=2ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=3ms TTL=64 Reply from 10.0.0.145: bytes=32 time=4ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=2ms TTL=64 Reply from 10.0.0.145: bytes=32 time=3ms TTL=64 Request timed out. Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=3ms TTL=64 Reply from 10.0.0.145: bytes=32 time=2ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=3ms TTL=64 Reply from 10.0.0.145: bytes=32 time=2ms TTL=64 Reply from 10.0.0.145: bytes=32 time=2ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=5ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=6ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=2ms TTL=64 Reply from 10.0.0.145: bytes=32 time=2ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=3ms TTL=64 Request timed out. Request timed out. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.145: bytes=32 time=2001ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=2ms TTL=64 Reply from 10.0.0.145: bytes=32 time=2ms TTL=64 Reply from 10.0.0.145: bytes=32 time=2ms TTL=64 Reply from 10.0.0.145: bytes=32 time=4ms TTL=64 Reply from 10.0.0.145: bytes=32 time=3ms TTL=64 Reply from 10.0.0.145: bytes=32 time=2ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=2ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=2ms TTL=64 Reply from 10.0.0.145: bytes=32 time=2ms TTL=64 Reply from 10.0.0.145: bytes=32 time=2ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=2ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=2ms TTL=64 Reply from 10.0.0.145: bytes=32 time=3ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=2ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=2ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=3ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Request timed out. Request timed out. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.145: bytes=32 time=1004ms TTL=64 Reply from 10.0.0.145: bytes=32 time=2ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=2ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=2ms TTL=64 Reply from 10.0.0.145: bytes=32 time=2ms TTL=64 Reply from 10.0.0.145: bytes=32 time=2ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=2ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=2ms TTL=64 Reply from 10.0.0.145: bytes=32 time=3ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=2ms TTL=64 Reply from 10.0.0.145: bytes=32 time=2ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=2ms TTL=64 Reply from 10.0.0.145: bytes=32 time=2ms TTL=64 Reply from 10.0.0.145: bytes=32 time=3ms TTL=64 Reply from 10.0.0.145: bytes=32 time=2ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Request timed out. Request timed out. Reply from 10.0.0.33: Destination host unreachable. Request timed out. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.145: bytes=32 time=2005ms TTL=64 Reply from 10.0.0.145: bytes=32 time=2ms TTL=64 Reply from 10.0.0.145: bytes=32 time=5ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=5ms TTL=64 Reply from 10.0.0.145: bytes=32 time=2ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1131ms TTL=64 Reply from 10.0.0.145: bytes=32 time=2ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=2ms TTL=64 Reply from 10.0.0.145: bytes=32 time=2ms TTL=64 Reply from 10.0.0.145: bytes=32 time=2ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=2ms TTL=64 Reply from 10.0.0.145: bytes=32 time=2ms TTL=64 Reply from 10.0.0.145: bytes=32 time=2ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=3ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=2ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=2ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=2ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Request timed out. Request timed out. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.145: bytes=32 time=1993ms TTL=64 Reply from 10.0.0.145: bytes=32 time=2ms TTL=64 Reply from 10.0.0.145: bytes=32 time=2ms TTL=64 Reply from 10.0.0.145: bytes=32 time=3ms TTL=64 Reply from 10.0.0.145: bytes=32 time=2ms TTL=64 Reply from 10.0.0.145: bytes=32 time=2ms TTL=64 Reply from 10.0.0.145: bytes=32 time=3ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=2ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=2ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=2ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=2ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=213ms TTL=64 Reply from 10.0.0.145: bytes=32 time=3ms TTL=64 Reply from 10.0.0.145: bytes=32 time=2ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=4ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=2ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=3ms TTL=64 Reply from 10.0.0.145: bytes=32 time=1ms TTL=64 Reply from 10.0.0.145: bytes=32 time=3ms TTL=64 Reply from 10.0.0.145: bytes=32 time=201ms TTL=64 Request timed out. Request timed out. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.33: Destination host unreachable. Reply from 10.0.0.145: bytes=32 time=4ms TTL=64

Single NIC, single IP: http://tinyurl.com/mkfmvcx Zero problems with the "Parking Lot" cam and various bandwidth/speed tests are OK - so I do not think it's an issue with the radio link. Going down there tomorrow with a ladder, a can of contact cleaner, and a tube of dielectric grease.... so maybe I'll have something useful to say that evening.

I would settle for Trigger A Light. Had not thought about triggering a camera recording but, now that you have mentioned it, I think I recall something in BlueIris that can respond to outside triggers.... which might be useful if the hardware could ignore things like falling snowflakes and swirling fog but still pick up on small animals.

I've had one of these cams working for years.... so long that I have forgotten how to get to it's setup page. All I can remember is that it is non-standard. i.e. it's not just the HTTP port.... Tried the "Config Tool" that came with the cam, but the interface is rudimentary and not what I'd call a camera setup page. This particular cam's IP addr is 10.0.0.141. have it's RTSP port as 1411, and that responds - and BlueIris reads it a-ok. I have it's HTTP port set to 1410 - and that shows up when I do a network scan... but 10.0.0.141:1410 in a browser window throws "Page not found"..... Can somebody refresh my failing memory? Edit 2012 12-11 15:32: I think the cam's wacked. Downloaded the latest (v1.0.5) config tool , finally realized that I had to right-click on the cam and select "Open Device Web".... but it's still saying "This page can't be displayed". Looks like it's trying to go at it via port 80, so I tried 1410.... but still nothing.... and the net scanner I use says that cam is not (as expected) exposing port 80, but is exposing port 1410.

Got a couple of cams at a remote site that keep dropping offline. My money is on the salt water environment's working on Cat5 connections, but it will be awhile before I can get down there. Meanwhile, I have to wonder about the strange login screen they are throwing when they do come back online. My instance of BI cannot see the cams, but when I go to login via a browser here's what I get http://tinyurl.com/on3c9q5 Not the usual login.... Anybody else seen this? I guess I'm grasping at straws - hoping it's something with the firmware instead of the probable bad connections.

These things have been working for me for about a week: http://tinyurl.com/q8l7hz5 I was half expecting them to fail because of water penetration and/or temperature, but they're still hanging in there. 9,500 lumens, 500 watts.... replacement bulbs @$3.50 per.

When my motion-triggered floods come on and there's a little snow on the ground, I get a very nice transition to Daytime mode: colors, much better definition. viz: But without the snow to help out, I never get that transition when the floods come on. Configuration | Day/Night Switch | Sensivity = 7 (max allowed), ...Filtering Time = 5 (min allowed). I guess some more watts in the floods is in order, but I'm thinking maybe there's a back door. Has anybody played around with other settings like Backlight, White Balance, or Image Enhancement in an effort to get a NightTime => DayTime transition with less light?

I think I have something that works: http://tinyurl.com/q8l7hz5 9,500 lumens, 500 watts, $30 per...... set to turn for one minute per trigger event. Cam's transition to color takes about 10 seconds as per http://youtu.be/1rpGPaXmxeI. (seems to take forever to load... but maybe that's my inner Type-A talking...) Replacement bulbs are about $3.50 each. They come in lower wattages/lumens and I might try a 300-watt just to see if it still does the job.