Soundy

Sure the POS system can run a report... that doesn't make going back and forth from one machine to the other looking up individual transactions a more efficient process, that just helps you determine who or what to look for. You're still talking about two different functions.

My first question would be, do they know WHY they want a PTZ, or is it just because they think it's cool and hi-tech? PTZs are great if there's someone there to control it... otherwise they can still only see a limited area at any given time. Even on a tour or pattern, once it sweeps past an area, you're not going to see that area again until it gets back there in its program. (Unless, of course, you get into some fancy auto-tracking stuff, but then you're really looking at spending the big money!) Vandal-resistant domes are probably your best bet in most cases, although the license plate cam will probably need to be a box cam in an environmental housing, to accommodate a longer lens. I count 11 or 12 "aisles" you'd need to cover along the sides of the buildings, so that falls within your count... best bet would probably be to put a camera for each one at the highest point at one corner of the building...

Have you actually USED the feature? Depending on how the DVR handles timeline searches, it could make a HUGE difference. You look at the POS database, find the time you want, go to the DVR, enter the time... depending on the DVR, you may have to enter a start AND end time... then you hit search and view the results. And this only works "easily" if the DVR and POS clocks are precisely synchronized. Or you just look at the line of POS data... click it, and there's the video. Consider the other feature of using data captured on the DVR: as you play the video, the relevant data is highlighted. You watch the cashier scan an object... and instantly the corresponding line item is highlighted. Very handy if, for example, you suspect someone is scanning fake barcodes.... or if they're ringing through one item when there are actually two. Sure you could do it the other way, looking at the POS itself... but it's nowhere near as efficient. That pretty generalized... what if you need to see that what was shows up on the POS was what was actually scanned? Pretty simple trick - pull a stick-on barcode off a cheap item, stick it on a more expensive item...

Not necessarily true. Most till printers are just simple ASCII printers - that WILL be plain text, with CRs/LFs and possibly TABs in appropriate places. Ditto with Polewatcher outputs, since a Polewatcher display just accepts and displays plain text. The main issue with logging it to a DVR is that the software needs to understand the layout of the information - ie. register number, transaction number, item name, item price, etc., to sort and store them in the right columns. The output itself is perfectly legible, in most cases. As noted above though, a printer output is not generally good for live data capture, because it doesn't usually send data until the transaction is complete (and sometimes not until PRINT is specifically selected). A Polewatcher output is preferable because it's generally realtime - item is entered/scanned, item displays immediately. yes pole display and printer get the same data. what i do not understand is how the op is going to see the data without a pos box or text overlay box (both of which converts the data to text) he could use UTP but his dvr does not allow that. for him to say he is going to just monitor his data out on a monitor is only going to give him binary. Serial communications are simply a series of voltage or current changes which are translated into the binary equivalents of 1 or 0s. After a series of this data is received, the computer reconstructs the serial data into its original binary format for computation. Ummm.... I think you're over-thinking this. Most POS printers and polewatcher displays connect via serial. You hook the register's serial output to the DVR's serial port, and capture the data from there. The register sends plain ASCII text - you can view it using HyperTerm or any other terminal app that lets you access the serial port - it just shows up as regular alphanumeric info. It's really not that complex - it's just like talking to a modem.

I don't know exactly what the transfer specs are on the Enhance and QNAP boxes we've been using, but they're all working fine using RAID5 and connected to the DVR via GbE... most with 16-20 analog cameras and 4-5 MP cameras. I haven't seen any performance issues with any of them writing to the NAS vs. the internal drives.

Oooo, that sounds like a challenge!

What type of camera is it? What lens? List exact brand and models, if possible...

Umm, that's really kind of unclear. I can ASSUME from the list of equipment, that you want motion detected on the cameras to trigger an alarm siren?

I dunno, looks like it's essentially a KVM switch, without the K or M. Dunno why that wouldn't work. You could always try a standard KVM, although it could be tricky finding one that will work properly without actually being connected to a PC's keyboard/mouse inputs. That unit does have USB ports, so a USB KVM may work. Short of that, you could try one of these: http://www.rpelectronics.com/ts-m2k-manual-vga-monitor-2-position.html. They're not great (it's just a big mechanical-contact switch) but it removes all the electronics from the process and so may just do the trick. My ideal solution for this would be a monitor with two inputs. For two VGA inputs, that may require a small TV rather than a monitor, or one that accepts VGA on the DVI input (aka DVI-A).

And what, exactly, are you trying to do with all this?

Welcome aboard! Just remember: no selling allowed in the forums!

Hmmm, hasn't really changed that much. IP is becoming more popular (and a LOT cheaper than 2 years ago). Computers are more powerful. Storage space is WAY cheaper. HDcctv is finally starting to hit the market (it was probably "RSN" when you were still working in the industry ) Technology has improved, but overall isn't all that different.

Can't say for this one in particular, but a lot of PC-based DVR systems require you disable hyperthreading for proper operation... you might try that (look in the system BIOS).

Not necessarily true. Most till printers are just simple ASCII printers - that WILL be plain text, with CRs/LFs and possibly TABs in appropriate places. Ditto with Polewatcher outputs, since a Polewatcher display just accepts and displays plain text. The main issue with logging it to a DVR is that the software needs to understand the layout of the information - ie. register number, transaction number, item name, item price, etc., to sort and store them in the right columns. The output itself is perfectly legible, in most cases. As noted above though, a printer output is not generally good for live data capture, because it doesn't usually send data until the transaction is complete (and sometimes not until PRINT is specifically selected). A Polewatcher output is preferable because it's generally realtime - item is entered/scanned, item displays immediately.

Erron, you are exactly correct. I'd much rather buy from someone who understands the big picture than the someone who is just trying to make a sale and move on. I'll give you a call. Thanks Glad I could help. Now where's my commission? If you have a solid understanding of TCP/IP basics (IP ranges, subnet masks, default routes, etc.) you should have no problem with IP cameras. Advanced training on things like VLANs and Layer 3 management will help once you start getting into larger systems with numerous cameras, but isn't really critical for the first half-dozen or so cameras.

As long as its an IP camera There's other wireless technology available for regular CCTV cameras. Or you could add video-to-IP servers to put your analog cameras on the network...

Whether that's a problem kinda depends on how the DVR displays the data. Vigil shows your entire search results in a multi-line grid, so you can view the surrounding transactions at a glance - it would be fairly clear if a customer changed his order, especially as the highlighted data line scrolls in sync with the video. This isn't really a failing of the DVR, though... it's entirely a factor of what data the POS sends. The DVR can (or should) be able to log and display anything sent to it. In your example above, many POS systems will have a function to "hold" the current transaction and allow the clerk to move on the next one; as long as it's sending that information to the DVR, it would show up as such in the log. Again, it should be capable of capturing anything the POS sends it... it's only as good as the data it's given.

I don't know about your DVR specifically, but almost all of them have alarm inputs that you can use to trigger various behaviors... often recording priority (for a given input trigger, a defined camera would switch to high-res, high-quality, high-FPS recording for a set period of time), but most would also be able to simply log that input as an event. Your doorbell could easily be configured as such an input trigger. This is far simpler and more do-able than attempting to receive and decipher text from the alarm panel.

Yeah, I wondered that too, but it appears as though the registration is already off a bit. Too bad it can't "learn" to improve registration. Over the next decade, I expect we will see some very impressive auto tracking. Best, Christopher As opposed to running a tour or pattern or auto-scan 24/7?

BTW, nothing wrong with this idea... helped us steal one of our larger clients from a competitor, when they wanted to go to megapixel, and the competitor didn't want to bother learning anything about it. (Not the only reason, mind you, but the main one that got our foot in the door). What I would suggest, is getting a little training in IP networking. Nothing too extreme, you don't need a CNA or anything. Despite what some would have you believe, a university degree is NOT required to deal with IP cameras. A basic understanding of how TCP/IP works will take you a long way.

Chris, we've been dealing with 3xLogic (formerly CamAcc) for at least 6-7 years now... their Vigil systems match your above criteria perfectly. All their DVR/hDVR/NVR machines use the same server software and work with the same client and VCM/VMS system. Even their small "mobile" systems use the same software. They also have an "HD Viewer" product for displaying multiple IP cameras on additional VGA/DVI displays, built-in analytics, their own line of external RAID storage, extensive POS support, and various other specialized features. Their tech support has also been very good, on the whole. We've done a fair bit of work with them developing some customized modules for one of our larger customers. Maybe Erron S. will chip in here, he's a 3xLogic rep who stops by now and then

The issue could be with the DVR as well - what make and model is it?

Pimpin'!

not here, $250+ for a 2TB drive, almost $200 for a 1 TB drive. Paid $130 for a 500GB drive the other day.