hardwired

Until one of us steps up to the plate and purchases a true analysis package for this purpose (http://www.imatest.com/home, or something like it), all of our observations about resolution will only be subjective. Granted, some differences are more easily visible than others, but the effects of different processing and compression schemes often create more effect on the final image usability as does differences in the native image quality coming off the imager. Machine vision camera manufacturers regularly provide a wealth of information about native image sensor sensitivities, resolutions, etc. that CCTV manufacturers do not, because their users demand it. Among other CCTV market problems, manufacturers that do not inflate their standards risk being compared poorly to those that greatly exaggerate their specs, because less discerning buyers will make purchasing decisions solely from those specifications, rather than any objective comparisons. I think that the greatest advantage of the "lines of resolution method" is that it did allow the observation of a whole package (lens, camera, and compression) in operation. Pixel-based approaches are lacking in that regard. I can have a nice looking 2048X1536 pixel image that I can make out great detail, faces, plates, etc.. or I can have a 2048X1536 pixel image with the iris shut too far, compression at maximum, and out of focus.... Still the same "resolution" image. We need manufacturers to comply to an industry standard (anyone expect that anytime soon?), or a reasonably effective test bench configuration and testing methods, to really objectively compare cameras. Who among us is going to step up to the bench, and help hold manufacturers feet to the fire on this subject?

Should work, but I'd start around 9 volts or so, a lot of lenses were 9 volt, plus the fact that a lot of unregulated transformers are quite a few volts higher than their rating when they are lightly loaded. A replacement automotive power window switch would fit the bill for the momentary DPDT configuration, they are usually internally cross-wired in the same way you need, too.

Take a look at this lens http://fujinon.com/ProductDocs/D8x7.8A-SE2.pdf or others on their site, might be close enough.

The lens will require a controller of some type, it does not have a way to be directly connected to data control lines. Something like the Pelco IRD2000 receiver, http://www.pelco.com/global/en/products/camera-solutions/range-presentation.page?p_function_id=9510&p_family_id=10231&p_range_id=2924 , would be what you need to convert the data signal to the DC lens control voltage (and pan/tilt control, if you have a pan/tilt assembly)

In many of my IP camera system installs, there has seemed to be a split between setting IP addresses to static in the cameras, or leaving them on DHCP, and setting them up through the DHCP server scope. There are definite advantages for DHCP (central management, quicker camera replacement) and disadvantages (DHCP server down=no cameras accessible, needing access to a DHCP server) Which approach do you guys use most frequently, and why?

I agree that static addressing is often simpler, for the reasons a lot of you have already listed. However, in larger environments (schools, factories, etc.) the IT folks prefer to manage IP addresses through the reservation scope on their servers. This does raise an issue in that for service, I either need access to their DHCP server for managing the MAC addresses, or rely on their people to manage it in a timely fashion (doesn't work well, sometimes). How many instances have you guys had of this, and how well has it worked for you?

In situations like this for IP cameras, I've used SDSL extenders on twisted pair out to several thousand feet. One model I use will do full 100Mbps full duplex to 1000', and asymmetrical 3/30 Mbps out to 4200'. Nice solution, especially where there is existing CAT3 phone cable in place already. I did a farming operation like this with several existing runs of CAT3, over 2000' each, with multiple cameras at each endpoint, coming back to a central multiport DSLAM concentrator. Works quite well, and the customer was also able to add Ethernet connectivity to his scale-houses for scale data collection.

Evidently, he has a POS system that only has a VGA output, and no serial or printer outputs (how do they get a receipt?). He has to try and get that output into Milestone NVR software, which he is now doing with a VGA-composite converter and then an encoder.

Almost no client software other than the one for your specific unit is likely to work. If you can post some pictures of the DVR, screenshots of the web viewer, or any other identifying information from your unit, maybe someone here can help you further.

It is not so much an attack on anyone in particular, as it is an almost "knee jerk" reaction to that kind of product, that you are seeing. Myself, and almost everyone here (except the spammers) have some pretty strong feelings about recommending product of that type to anyone (see, we were actually trying to be nice to you, we just came off a little harsh!) My recommendation would be to try and find a good used name brand PTZ, (Pelco, etc),before I would consider some of that offshore no-name stuff, if your budget is really fixed at that price.

According to the Arecont folks I talked to at the ISC show, they are due to release a D/N version of the 8185/8365 that also allows you to gimbal the cams somewhat, within a few months... But then again, they announced the 10MP cam at ISC West 2009, and had one showing at ISC west 2010, but still no announced shipping date..... So you might not want to hold your breath. Depending on the application, and the NVR software you are using, you might also want to look at Immervision lenses http://www.immervision.com/en/home/index.php they have a 360 view lens that will work on a number of megapixel cams, and with quite a few different NVR platforms.

Well, if you are using Milestone, you are going to be limited by their compatibility list, and I don't see much there that would do what you are asking. Is there any possibility of working with the POS company to provide a serial or Ethernet data output?

I've used a lot of the NW-484S cams, and they are indeed a very good cam. Along with the very good WDR capability, they have a internal dehumidification system, and a pretty foolproof mounting system that keeps you from piping conduit water directly into the cam (I've seen a lot of Pelco and others domes turned into fishbowls by that). If you want to move up to megapixel, the 502 dome would be a great choice. It needs a little more light, but the images are outstanding (the cam is up to 3 megapixel, but only has WDR and H.264 compression at 1.3 megapixel). Not the cheapest, but you really do get an outstanding camera for your money.

Does any part of the HDcctv spec address transmission over twisted pair? I did not see much in that regard, and most casinos (the most likely user of it, at this point) seem to have at last some of their signal path over twisted pair.

Did you add a NAT entry (srcnat) with the interfaces in and out, to get it going? Or was it something else? Seen you on the other forums, too.. Sharing knowledge is good! And yes, I've had fun with the IT guys too... Just take them out into the sunlight, I think they might have a vitamin D deficiency

150' should be fine for Coaxitron, you only get into issues with it at about 750' or so (on RG59). Your idea of using the power pair for the RS422 signal would probably work, too. Specifications for RS422 control cable call for shielded, twisted pair.... But, I've used just about anything short of fence wire and had it work......Actually, I had a discussion on another forum about using fence wire for power and signals, but that's another story....

That's one of those "why not try it" kind of things. The cable probably does not have any twist, so noise/interference could be an issue.... But if it can be tested easily enough, why not... Let us know if it works! ***********EDIT********** You could use a set of these http://www.fmsystems-inc.com/cw/Details.cfm?ProdID=95&category=4 ,Pretty expensive, though. I have used them, and they do work.

You are correct about the transmission over the coax. Pelco D or P protocols are separate protocols, used over separate twisted pairs, as you said. Coaxitron is its own protocol, over the same cable as the video signal (it transmits the signal to the camera during the vertical blanking interval, between individual fields of video). Coaxitron is limited to using over coax cable, or PASSSIVE twisted pair converters, it will not pass through amplified baluns, or media converters like fiber optic, etc. How far, and over what type of cable, are you trying to transmit your signal?

Got the Q1 used for $500, not too bad for what it does, still a little hard to see in the sun. Loads XP faster than a full size Sony laptop I have does with Vista (yeah, I know, that's not saying much) Still occasionally have to throw a jacket over my head like those photographers from the 1920's.....

Sounds all about right, one thing I would add is to use a internal static IP that is not in the scope of the DHCP range, but still in the same subnet (eg. 192.168.1.90, if the DHCP range is 192.168.100-192.168.1.250)

This is my setup tool, Samsung Q1 and the Nitek IPT148 ...Running XP and Explorer, so all the STUPID plugins work...Sorry was I shouting ? Manufacturers need to get away from those plugins........

Take the time to work with Exacq, if you can..... It's really pretty nice. It has become my first choice of NVR platform, even over Milestone, in some cases (Milestone's pricing is getting a little absurd). Milestone/ONSSI is still probably the nicest, if your customer is willing to pay for it.

Preset 95 is what calls the setup menu in Pelco PTZ's, guess they are following Pelco protocols REALLY closely?

Exactly. A few DVR software packages support different cards (Vigil, Luxriot, and a few others), but the hardware requirements will probably require a complete hardware rebuild, whereas Exacq, especially, has a very low processor load because you are offloading the encoding work into the Acti (or other) encoder box.

It would be better to start a new thread on your subject. Anyway, the problem could be associated either with operational ports that are blocked by the satellite ISP, or timeouts caused by the extremely high latency that the satellite service has. You could try and see if you can change the operation port number on the DVR to one that is not blocked by the ISP. Satellite services often employ a lot of "tricks" to the packet information to make the latency seem less than it really is (forged syn/ack packets, etc) and these can affect operation, also.