Soundy

There's no need to use a baudrate over 2400, or at most 9600 (I've run into a couple older PTZs that are 9600-only) - a lower rate will be less prone to data corruption from interference. Also, ensure the rest of the port settings match (8N1 - 8 data bits, No parity, 1 stop bit, an no flow control).

A DNS server is not used to host videos, it's used to give your system a "human-friendly" named address for outside access. As VST_Man suggests, a dynamic-DNS service is what you want - that will allow her (or you) to connect to her system from a remote location, through her internet connection, using a simple name like "momsplace.no-ip.com" (providing either you have client software for the DVR, or it has a web-based remote viewer). Ignore nocturnal59's post, it's irrelevant to your question and will only serve to confuse you.

100 % agree with Soundy What I done few times NTSC standard signal Gen in place of the camera and Oscilloscope at the DVR then u can have some data to play and analyse Since I use a portable DVD player as my field monitor, I made a DVD with various looped test signals - color bars, alignment grids, grey scales, etc. Don't need to use it very often, and I wouldn't really trust any of them for laboratory-grade signal analysis, but it's handy to carry around. It's easy to look at the player's screen to compare, too. Maybe I should look into a USB/software oscilloscope for my laptop

I use a USB-to-serial adapter on my laptop, and HyperTerminal (yeah, just the little basic terminal bundled with Windows), to view incoming serial data. I made an "adapter" using a DB-9F solder-on connector, with short wires to pins 2 (TX), 3 (RX), and 5 (ground), and small alligator clips on the other end. In this case, you'd connect pins 3 and 5 on such an adapter to the wires from your DVR, set your baud rate and protocols to match the DVR's serial ports (probably 2400 or 9600, 8N1, no flow control), and fire up HyperTerm connected to the USB serial port.... then start driving the PTZ controls on the DVR and watch for garbage to show up on HyperTerm. If you want to get more in-depth, you can use serial capture/analysis software to see what data the DVR is actually sending... this package, for example, even includes a tutorial on their web page for reading and understanding the control codes it's seeing: http://www.232analyzer.com/RS232_Examples/CCTV/Pelco_D_Pelco_P_Examples_Tutorial.HTM Finally, if you're using RS-232 (vs. RS-422 or 485), there's a little trick I've found works sometimes: with the camera off, connect the wires with the proper polarity, then fire up the camera, and switch the wires (so the GND wire on the DVR goes to the RX+ input on the camera, and pin 2 on the DVR goes to the RX- on the camera). Often, it will just start working after that!

Ah, that sort of tester is known as "a VCR and your eyes" The problem is, the tester has no idea what kind of signal the camera is generating, so it has no way of knowing what the "quality" of that signal is. It needs its own, known-quality signal source at the other end, so it can compare the signal it's receiving against what it knows the signal SHOULD look like. Simply taking a "snapshot" of the camera's signal at one point and using that as a comparison later won't work either, because again, the tester has no way of knowing whether the camera itself is failing - all it's supposed to be testing is the cable. It could show a FAIL when the cable is perfectly fine, because the camera is having issues. No, such a tester MUST be a two-part unit.

Yeah, support and free upgrades probably expire in a year, but I can't see the software itself expiring and not working anymore after a year. Most with a "demo" mode like that will be 14-30 days or something.

When we cabled the new campus at the digital-arts school I used to work at, we bought so much Cat-5e, the supplier loaned us a really nice Fluke tester - it tested, measured and logged the length of each run on a room-by-room basis so we could pull it into a computer later. There were probably 15-16 rooms with 16 or 24 runs to each one, that according to the sum of all the cable cataloged in the tester, came to nearly 30km(!!!) of cable. The tester we were using, they told us, sold for about $3000...

Don't have any suggestions for you offhand, but having used that type of tester for network runs, I can tell you right now, it's gonna be pretty spendy.

I haven't worked with those cameras specifically, but I've used a lot of that TYPE of design... there simply isn't room in there for a varifocal lens. However, there are a wide range of fixed lenses that you should be able to swap into it - common lengths are 2.6mm, 3.8mm and 8mm (models of National Electronics domes we used to use included all three with every camera).

Do keep in mind the relatively limited range of WiFi - 300' line-of-sight for 11b/g unless you go with repeaters and/or high-gain antennas... and the closer your get to the far end of that range, the weaker your signal and the lower your bandwidth.

With VGA, PAL/NTSC video standards don't apply. Bingo! If you connect the original cameras to your TV, you'll probably find a similar effect to what you had connecting the PAL cameras to your DVR. Your DVR may require a reset to "factory settings" before it will re-detect the format used. There may also be the ability to manually set the video standard used (either through a menu option, or through a switch inside the DVR).

Not knowing that specific DVR, my expectation would be that it will do one or the other, but not both at the same time. The two video standards are based on the AC power frequency - in North America and a few other areas, our power is 60Hz, and NTSC standard is 30 frames per second; in most of the rest of the world, the power is 50Hz and PAL standard is 25fps. As for what it has to do with television, well... what are you going to watch the DVR on? It needs to output video using whichever format your monitor uses, which if your power is 50Hz, is probably PAL as well. Try disconnecting the original cameras and fire up the DVR with only the new PAL cameras connected... see if it switches to PAL then.

It really comes down to one simple thing: design priorities. A home-theater PVR's design priorities are video quality and easy of use for one, or maybe two video streams. Retention amount is not a main concern. With surveillance DVRs, the priority is usually maximum retention, for SEVERAL video sources - in some cases up to 16 or 32. The software interface is also generally far more advanced than your basic PVR recorder, which equates to higher development costs. And of course, you have the economy of scale: the market for satellite and cable PVRs is probably 100 to 1000 times larger than that for CCTV recorders... thus it can be sold far cheaper.

A DVR with alarm-trigger outputs could do it - the Vigils I work with are able to do it with a number of different models of output modules. The problem with this idea is that if it's too dark to begin with, the camera may not catch the motion, especially if the intruder is dressed all in dark clothing. Standard motion-sensing lights may still be preferable.

Ah, but that's MY point - BEFORE you spend a lot of time on it, give him a nice BIG ballpark number that immediately accounts for what it will cost YOU for such a short-term rental... then offer him price breaks over longer terms. If the camera's going to cost you, say, $400... tell him a two-month rental will be $600... six-month, tell him $800... full year for $1000... or tell him he can buy it outright for $500 (not a big markup, but just as an example - if he's buying it, it does save you the extra hassle of the rental contract, etc.). Naturally, make the point that any other equipment and installation costs are on top of that... Of course, if you've already spent a lot of time on it, well... can't help you there This strategy works best to weed out the cheapskates before you invest a lot of time - hit'em right away with a high-scale estimate of what it's going to be and see if they still want to go through with it. If so, then you can make your final quote a little less, and they'll be even more impressed. My boss was asked to bid on one job (small retail outlet)... the guy told him that we'd come highly recommended by a friend (another customer of ours) and that he wanted a price from us, but noted that he'd be going with the lowest price he got. My boss said straight out that we could give him a GOOD system for a good price, but he could also guarantee we wouldn't be the cheapest... then he thanked the guy for his time and left. Sometimes you just gotta know when to cut and run

Despite a "star" topology being "not recommended", I have done it, and/or seen it done on sites I've "inherited", on numerous occasions, and never had a problem with it. Look at it this way, you have nothing to lose by trying - it will either work or it won't, and if it does, it may save you some wiring.

The catch with #1 is that YOU have to buy it, and after the customer is done renting it, you're stuck with it. The solution is easy: make sure the rental per-month is about half the cost of the camera, so after two months, it's paid off anyway. Better yet, make the monthly rental about 75% of the value of the thing, so you can offer the customer the option of either buying it outright, or paying half again as much to rent it. If he still wants to go for the latter, you end up with a "free" covert camera and a few extra bucks in your pocket. From the sound of it, if you're lucky, he'll just decide it's not worth the cost.

PoE actually uses TWO pairs - 10/100 uses only the orange and green pairs (assuming standard 568a or 568b wiring), leaving the blue and brown pairs free. And actually, PoE spec DOES allow for power to be run over signal pairs, even with 10/100... see the diagrams near the bottom of the page here: http://www.joejava.com/poe.htm - the picture on the right is actually exactly the same way "phantom power" works for microphones and other phantom-powered audio gear. Given that, there's no reason it won't work over gigabit either.

I think you'll find most cameras are only 10/100, as there's not (at least with current technology) a lot of benefit, if any, to using gigabit on a camera, other than "just because we can". A single camera simply doesn't need the bandwidth, so there's no justification for the added expense. And if, as ver2go posits, gigabit and PoE are mutually exclusive functions, I suspect you'll find PoE winning out almost every time when it comes to these sorts of devices.

This is what I've been using most often - 8-port 10/100/PoE for the cameras, with two gigabit uplink ports, one for the DVR and one for the NAS... been pretty happy with this unit so far: http://a-power.com/product-6481 http://a-power.com/product-5428 "SRW2024P Managed Ethernet Switch PoE with WebView" "24 x RJ-45 10/100/1000Base-T LAN" http://a-power.com/product-6485 "SGE2000P 24-Port Gigabit Managed Ethernet Switch with PoE" Exactly how they do it, I don't know... consider that phantom-powered microphones run the power over the same wires as the signal, and have for decades - it's not a totally foreign concept It could also be as ver2go suggests, the switch auto-senses and runs either GB, or reverts to 10/100+PoE as needed. I would expect, if you look up the PoE spec, methods of handing either scenario would be documented there.

One of the main benefits of a switch vs. a hub (which are largely obsolete now anyway) is that every port can operate at a different speed without affecting the speed of the others. All gigabit devices that are connected to the switch will work at gigabit speeds, regardless of what other 10 or 100Mbit devices may be connected.

Yeah, different-color Cat-5 for each application is a great idea too, although if you need to, say, re-use a phone run for network or something, it kinda blows your color scheme A better idea is just to make sure everything is labeled properly - the aforementioned site I was on, every workstation was numbered, every jack at the workstation was numbered, and every bix section was numbered to match as well. (They also had only Cat-3 to a lot of stations in the more remote field offices, and yes we successfully ran ethernet over that in most cases - it had been running token-ring before, which was nowhere near as picky). Of course, in theory your CCTV runs will be completely separate from any workstation network/phone runs, so two separate colors for those purposes is still a good idea!

1. Depending on the specific balun type and manufacturer claims, video over balun-and-cat-5 is good for anywhere from 1000' to over a mile. 2. Sure. I'd be sure to keep all of them well away from any EMI sources, and especially away from parallel runs with AC wiring, but that's just good practice any time. 3. That's an excellent idea. One company I used to work in, their head office had a huge panel of BIX terminals in every floor's comm closet, a bundle of runs from there to each workstation, and a single- or dual-gang box at each workstation with interchangeable comm jacks - each station could be given any combination of phone, ethernet, or token-ring (yeah, this was quite a while ago) that was needed, with the appropriate patching done via the BIX panel. Need to add another network drop? Just plug in the appropriate jack insert at the desk and punch down the appropriate wiring between the station terminus and the network patchbay. They used a similar setup at every one of several dozen "field offices" as well. It was a really effective and flexible system.

Were these time-lapse units recording multiple cameras via a quad or multiplexor? If so, it will have to play back through the same (or same model) multiplexor to get the different streams "in sequence".

Sure it's the camera and not the monitor itself? Looks like it might be a bad power supply in the monitor.