Jump to content

PeteCress

Members
 View Profile  See their activity

  • Content Count

    186

  • Joined

  • Last visited

Posts posted by PeteCress

  1. Posted

    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?

  2. Posted

    Bullets tend to have better IR and a better image because they are not looking though curved glass (easier to focus) . Also they tend to stay cleaner in our experience.

    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....

  3. Posted · Edited by Guest

    An alternative to the dome is the Hik turret, DS-2CD2332-I, which has many of the advantages of domes but no IR issues..... they're all IP66 rated, I think.

    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.

  4. Posted

    I have been buying HikVision DS-2CD2032-I bullet cams: http://tinyurl.com/kg3xzrq

     

    They are plenty good for my use, but now I have occasion to buy a few more and it has dawned on me that the same specs are available in a dome-type cam as HikVision DS-2CD3132-I (http://tinyurl.com/pgpcqgm)

     

    First thing that comes to mind is that a bullet cam is more difficult for the mentally-challenged to grab and rip off the side of a building (been there, had it done...).

     

    Second thing is that once they are aimed, they seem more likely to stay aimed.

     

    OTOH, I wonder if the dome becomes an issue under certain weather conditions - as in high wind/salt water environment.

     

    Can anybody elucidate on the tradeoffs?

  5. Posted

    Also, not sure about Blue Iris compression rates or iframe interval, but a 60 frames of video at 1fps should come in smaller in size than 60 frames of .jpg shot at 1fps. Video compression uses I frames which only alter portions of the shot that have changed. Perhaps a very busy scene wouldn't have much difference in file size, but a living room while everyone is away could be considerably less.

     

    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.... -)

  6. Posted

    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?

  7. Posted

    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?

  8. Posted

    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.

  9. Posted

    So, the Hikvision camera's have issues but the Trendnet does not?
    Yes.
    Are the Hikvision camera's on longer cable lengths then the Trendnet?
    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).

     

    What brand/model is the switch?
    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.

     

    And are you able to confirm that it drops pings locally? Or only when going over the wireless?
    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.

     

    Turn on logging on the Nanostations and attach the logs with the time of when the problem happens.
    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.

  10. Posted

    OTOH, it would seem to beg the question of why the camera's good/bad responses are so well synchronized.

    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.

  11. Posted

    The silicone based stuff will peal right off with your finger nail with very little effort but holds up to just about anything. I don't necessarily fill the connectors, they just get a heavy coating of the stuff; think of it more like putting on a jacket instead of stuffing your clothes with newspaper.

    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.

  12. Posted

    If the end goal is just to weather/environment proof the connection, I would be asking why dielectric grease instead of something like a silicone based sealant.

     

    I don't see a downside, but from what I understand of dielectric grease, I don't really see an upside either.

    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.

  14. Posted

    run "ping -t 10.0.0.147" to see if there is a pattern on the ping/no ping timeframes.

    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.

  15. Posted

    run "ping -t 10.0.0.147" to see if there is a pattern on the ping/no ping timeframes.

     

    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

  16. Posted

    Could you give more detail about the network configuration on your windows? Multiple NICs? Multiple IPs?

    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.

  17. Posted

    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>

  18. Posted

    What do you want the sensor to do? Trigger a light, trigger camera recording?

    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.

  19. Posted

    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?

  20. Posted

    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.

  21. Posted

    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.

  22. Posted

    I will try but I don't think it will be enough light. I have 5000 lumens from 2 CFL bulbs on my 20x30 driveway and its not enough. They need to have a reflector behind them directing the light instead of wasting it all over the place. I think you are right about washing out the faces... but I have to try to make sure. Maybe I will get 2 spots and 2 floods instead.... Hmmm i think the floods might annoy my neighbors though... we will see.

     

    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.

  23. Posted

    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.

  25. Posted

    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?

×